1 16/10/2026 12 min

Matomo self-hosted su cPanel funziona bene se tratti l’installazione come un piccolo progetto applicativo, non come una semplice app da caricare via File Manager. I punti che fanno davvero la differenza sono quattro: versione PHP coerente con Matomo, database MySQL/MariaDB dedicato, cron eseguito con regolarità e URL in HTTPS senza salti di dominio o redirect strani. Se uno di questi tasselli è fuori posto, l’interfaccia può sembrare avviata ma i dati non arrivano, i tracker perdono eventi o l’aggiornamento si rompe al primo cambio di versione.

Su cPanel conviene lavorare con un approccio reversibile: backup del sito e del database, directory separata per Matomo, utente database dedicato e, se possibile, sottodominio dedicato tipo analytics.dominio.tld. Così limiti il raggio d’azione, tieni pulito il document root principale e riduci il rischio di conflitti con CMS, cache, regole ModSecurity o plugin del sito pubblico.

Scelta dell’architettura su cPanel

La scelta più solida è installare Matomo in una sottocartella o, meglio, in un sottodominio dedicato. Il sottodominio separa document root, cookie scope e policy SSL; la sottocartella è più rapida da mettere in piedi ma tende a diventare più fragile quando cambi rewrite, applici redirect o migri il sito principale. Se devi gestire più siti, Matomo resta unico e usa un solo archivio dati; quello che separi è l’accesso web, non il motore di raccolta.

Prima di toccare i file, verifica tre cose nel pannello: versione PHP assegnata al dominio, estensione pdo_mysql disponibile e accesso a cron jobs. Matomo recente richiede una versione PHP moderna; se il dominio è ancora fermo su una release vecchia per compatibilità con altri script, è meglio spostare Matomo su sottodominio con handler PHP più aggiornato, lasciando il sito legacy dov’è.

Prerogative minime: PHP, database, spazio e SSL

In cPanel controlla il percorso reale della document root e la versione PHP assegnata. Con CloudLinux o MultiPHP, il nome del selettore cambia poco: conta la versione effettiva esposta al dominio e le estensioni abilitate. Matomo lavora bene se hai mysqli o pdo_mysql, mbstring, json, curl, zip, gd e, idealmente, intl. Se una di queste manca, non improvvisare: o la abiliti dal selettore PHP del pannello oppure chiudi il gap con il provider.

Il database va creato separato dal resto. In cPanel apri MySQL® Databases, crea database e utente dedicati, poi assegna all’utente tutti i privilegi sul solo database Matomo. Non riutilizzare l’account del sito principale: se un plugin o un file PHP viene compromesso, hai appena regalato accesso anche alla telemetria. Tieni nota del nome completo del database, spesso prefissato dal nome utente cPanel.

Lo spazio disco è un vincolo sottovalutato. Matomo archivia log, archivi aggregati, eventuali backup locali e cache. Se il quota del pacchetto hosting è stretto, il primo sintomo è spesso un sito che smette di registrare visite prima ancora di mostrare errori evidenti. Controlla anche il certificato SSL del sottodominio: senza HTTPS il tracking moderno perde affidabilità e il browser può bloccare richieste o cookie in scenari reali.

Preparazione del dominio e del sottodominio

Se usi un sottodominio, crealo da cPanel in Domains o Subdomains e punta la document root a una directory pulita, ad esempio /home/utente/public_html/analytics. Attiva il certificato con AutoSSL o con il sistema del provider; l’obiettivo è avere https://analytics.dominio.tld funzionante prima ancora di caricare Matomo. Se il provider usa proxy o CDN, verifica che il certificato copra il nome host effettivo e che il redirect HTTP→HTTPS non introduca loop.

Se preferisci una sottocartella, ad esempio https://dominio.tld/analytics, controlla che il CMS principale non abbia regole rewrite che intercettano tutto. WordPress, Joomla e altri sistemi possono riscrivere URL in modo aggressivo; in quel caso la sottocartella rischia di essere trattata come una rotta applicativa del CMS invece che come un’app autonoma. In pratica: sottodominio se vuoi meno attrito, sottocartella solo se sai già come isolare il routing.

Download e deploy dei file

Scarica il pacchetto ufficiale di Matomo sul tuo PC o in una directory temporanea sul server, poi estrailo nella document root scelta. In ambiente hosting condiviso, la via più pulita è caricare il file compresso via File Manager o con SFTP e decomprimerlo lato server se il pannello lo consente. Se hai SSH, il deploy è più controllabile.

cd /home/utente/public_html/analytics
wget https://builds.matomo.org/matomo.zip
unzip matomo.zip
rm -f matomo.zip

Dopo l’estrazione, la directory deve contenere file come index.php, config/, core/, plugins/ e vendor/. Se il pacchetto è annidato in una cartella extra, correggi la struttura prima di avviare il setup. È uno degli errori più banali: il browser mostra una directory listing, oppure il web server cerca il file nel path sbagliato e restituisce 403 o 404.

Imposta i permessi con criterio. In hosting condiviso non serve aprire tutto a scrittura; basta che il processo PHP possa scrivere nelle directory richieste da Matomo. In molti casi i permessi standard sono 755 per le directory e 644 per i file, con eccezioni puntuali per cartelle di log o cache quando richiesto dal setup. Se devi fare un cambio, mantienilo minimo e reversibile.

Installazione guidata e parametri iniziali

Apri l’URL del sito Matomo e segui il wizard. La sequenza corretta è: verifica requisiti, configurazione database, creazione utente amministratore, definizione del sito da tracciare e generazione del codice di tracking. Non saltare la fase di controllo requisiti: se il wizard segnala estensioni mancanti o limiti PHP, fermati lì e correggi prima di andare avanti.

Per la connessione al database usa i dati del database dedicato creato in cPanel. Di solito host e porta restano localhost e 3306, ma alcuni provider usano socket o host interni differenti. Se il wizard fallisce con errore di connessione, non insistere a caso: verifica il nome completo del database e dell’utente, inclusi i prefissi automatici del pannello.

# esempio di parametri che devi avere pronti, non da lasciare in chiaro nei file pubblici
DB_NAME=utente_matomo
DB_USER=utente_matomo
DB_HOST=localhost

Durante la creazione dell’admin scegli una password robusta e, se il provider lo consente, abilita MFA appena l’installazione è stabile. Non lasciare l’account iniziale come unico superuser operativo: crea un secondo profilo amministrativo nominativo e conserva l’account iniziale solo come recovery, con accesso ristretto e password ruotata. I segreti non vanno mai scritti in file pubblici o condivisi in chiaro.

Configurazione del tracking sul sito principale

Il codice di tracking va inserito nel sito che vuoi misurare, non nel pannello Matomo. Il posizionamento ideale è prima della chiusura del tag </head> o in una posizione coerente con il template del sito, purché carichi in tutte le pagine. Se il sito usa un CMS, preferisci il campo dedicato al codice globale o un plugin ufficiale, non un incolla-e-spera nel template principale.

Il frammento base si presenta così:

<!-- Matomo -->
<script> var _paq = window._paq = window._paq || []; _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="https://analytics.dominio.tld/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', '1']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })();
</script>
<!-- End Matomo Code -->

Se vuoi ridurre l’esposizione del tracking a blocchi esterni o ad ad blocker, puoi valutare un dominio dedicato e coerente con il tuo setup DNS, ma evita soluzioni creative senza misurare l’impatto su cache, cookie e CORS. L’obiettivo non è “nascondere” Matomo, è farlo funzionare in modo stabile e legalmente coerente con la tua policy cookie e con il banner consenso, se presente.

Cron jobs per l’archiviazione

Su Matomo il cron è la parte che separa una demo da un sistema realmente utile. Senza archiviazione pianificata, il sito diventa lento appena crescono visite e siti monitorati, perché le elaborazioni vengono fatte al volo. In cPanel apri Cron Jobs e pianifica l’esecuzione di console core:archive con frequenza adeguata al traffico. Per installazioni piccole, ogni ora è spesso sufficiente; per volumi più alti, serve una finestra più frequente e un controllo dei tempi di esecuzione.

/usr/local/bin/php -d memory_limit=512M /home/utente/public_html/analytics/console core:archive --url=https://analytics.dominio.tld/

Il path del binario PHP cambia da hosting a hosting. In alcuni ambienti è /opt/cpanel/ea-phpXX/root/usr/bin/php, in altri un wrapper diverso. Se il cron non parte, controlla prima il log dei cron del provider o l’output email del job: spesso il problema è banalmente il path sbagliato del binario, non Matomo. Il comando deve girare con l’utente corretto e con permessi di lettura sulla directory applicativa.

Hardening minimo su hosting condiviso

Su cPanel non hai sempre il controllo totale dello stack, quindi conviene blindare ciò che puoi. Limita l’accesso all’area admin con password robusta, MFA e, se disponibile, protezione IP o autenticazione aggiuntiva. Evita directory listing e verifica che i backup non finiscano in un path pubblico. Se il provider espone mod_security aggressivo, monitora eventuali falsi positivi prima di disabilitare regole a caso.

Controlla i file di configurazione di Matomo, in particolare la directory config/ e il file config/config.ini.php. Questo file contiene parametri operativi delicati; non va pubblicato, non va lasciato con permessi larghi e non va salvato in repository aperti. Se devi fare un cambio, esporta una copia locale o nel sistema di backup del pannello, non in un file accessibile via web.

Per i log, tieni d’occhio i log del web server e gli errori PHP del dominio. In cPanel spesso li trovi nella sezione Metrics o nel file error_log della document root. Se Matomo mostra schermate bianche o warning di sessione, il primo posto da guardare è il log PHP, non il database. La maggior parte dei problemi iniziali è lì: estensione mancante, memory limit troppo basso, permessi sbagliati o timeout.

Verifiche funzionali dopo il go-live

Dopo l’installazione, fai almeno queste verifiche: caricamento dell’interfaccia, ricezione di una visita di test, archiviazione cron, SSL valido e assenza di errori nel log. Una prova rapida è aprire il sito che stai tracciando, aspettare qualche minuto e controllare in Matomo se compare almeno una visita. Se il dato non arriva, non dare per scontato che sia Matomo: verifica che il codice sia davvero presente nel sorgente HTML e che il browser stia scaricando matomo.js e chiamando matomo.php.

curl -I https://analytics.dominio.tld/matomo.js
curl -I https://analytics.dominio.tld/matomo.php

Le risposte attese sono 200 o, in alcuni casi, un 304 se entra in gioco la cache del browser. Se ottieni 403, il problema è di permessi o regole di sicurezza; se ottieni 404, il path è sbagliato; se ottieni redirect infiniti, il problema è quasi sempre di URL base, proxy o HTTPS non allineato. La diagnosi giusta si fa dal layer HTTP, non dalla dashboard.

Backup, aggiornamenti e manutenzione

Prima di ogni aggiornamento salva due cose: database e directory applicativa. Il database è la parte più critica perché contiene visite, configurazioni e utenti; i file contengono codice, plugin e configurazione. Se il provider offre backup automatici giornalieri, bene, ma non usarli come unica strategia. Ti serve almeno un punto di ripristino verificato.

Un ciclo di manutenzione sano è questo: controlli log, controlli spazio, verifichi che il cron abbia girato, applichi update quando disponibili, poi riesegui una visita di test. Se usi plugin aggiuntivi, tieni conto che sono la parte più fragile dell’installazione. Ogni plugin amplia la superficie d’attacco e introduce dipendenze che possono rompersi con l’upgrade. Installa solo ciò che serve davvero.

Se vuoi ridurre il rischio operativo, documenta tre cose in un file interno non pubblico: URL dell’istanza, versione Matomo, versione PHP e procedura di restore. Bastano poche righe, ma quando il pannello cambia interfaccia o un collega deve intervenire, quel promemoria evita errori banali e tempi morti.

Errori tipici su cPanel e come leggerli

Schermata bianca: quasi sempre memory limit basso o errore PHP. Controlla il log errori del dominio e la versione PHP assegnata.

Installazione bloccata al database: credenziali errate, prefisso cPanel non incluso o host DB diverso da localhost.

Tracking assente ma dashboard ok: codice non presente nelle pagine, blocco CSP, ad blocker, URL del tracker errato o mismatch tra http e https.

Archiviazione lenta: cron assente, job troppo raro o hosting sottodimensionato. In questo caso il sintomo è spesso un backend lento più che un frontend rotto.

Aggiornamento fallito: permessi insufficienti su file o directory, spazio disco finito, o plugin incompatibile. Qui la verifica più utile è leggere il log dell’upgrade e confrontare la versione PHP con i requisiti della release.

Quando conviene non usare cPanel puro

Se il volume è alto, il numero di siti monitorati cresce o ti serve controllo fine su cron, cache e PHP-FPM, cPanel condiviso può diventare stretto. In quel caso la soluzione più pulita è spostare Matomo su VPS o server dedicato e lasciare su cPanel solo il sito pubblico che invia i dati. Non è una bocciatura del pannello: è una questione di carico, isolamento e prevedibilità operativa.

Per un’installazione piccola o media, invece, cPanel resta una piattaforma pratica: hai provisioning rapido, SSL gestito, cron semplice e un percorso di manutenzione comprensibile anche a chi entra nel sistema dopo di te. La chiave è non trattarlo come un wizard da finire in cinque minuti: Matomo rende bene solo se il deployment è ordinato e il tracking viene verificato con metodo.