Sottodomini o sottocartelle? Come ho riorganizzato una dozzina di siti

Per anni ho dato a ogni progetto il suo sottodominio: quiz.portale3d.it, varco.portale3d.it, intercity.portale3d.it e così via. È la scelta più naturale quando un progetto nasce: cartella nuova, indirizzo nuovo, nessun conflitto con il resto. Poi un giorno il pannello dell'hosting mi ha detto che avevo esaurito gli slot per i sottodomini. Dovevo decidere: comprare un piano più grande o cambiare struttura.

Ho cambiato struttura. In questa guida ti racconto il ragionamento e i passaggi pratici, così puoi applicarli ai tuoi siti.

Il dilemma in breve

Le due strade sono:

• sottodomini: progetto.miosito.it, ognuno trattato quasi come un sito a sé;
• sottocartelle: miosito.it/progetto/, tutto sotto lo stesso dominio.

Tecnicamente funzionano entrambe. La differenza sta in tre aree: come li vede Google, come gestisci il login degli utenti e quanto ti costa mantenerli.

SEO: cosa cambia davvero

Google ha ripetuto più volte che sa gestire bene sia sottodomini sia sottocartelle. Nella pratica, però, un sottodominio viene spesso trattato come una proprietà a parte: i link che arrivano a quiz.miosito.it aiutano meno il dominio principale, e viceversa.

Per un sito personale con tanti piccoli progetti questo conta. Nessuno dei miei giochi aveva abbastanza link da reggersi da solo; messi insieme sotto un unico dominio, invece, si rafforzano a vicenda.

Prima di decidere ho guardato i dati veri: le statistiche delle visite e Google Search Console. Il traffico organico verso i vecchi sottodomini era quasi nullo. Questo mi ha permesso di non preoccuparmi dei redirect da ogni vecchio indirizzo: è bastato aggiornare i link interni e indicare l'URL canonico giusto in ogni pagina.

Prima di riorganizzare, controlla i dati. Se un vecchio indirizzo riceve traffico da Google o da link esterni, serve un redirect 301. Se non lo riceve, puoi risparmiarti la fatica.

La struttura che ho scelto

Ho diviso tutto in tre gruppi, secondo il tipo di contenuto:

I giochi sono l'unica eccezione: tengono un sottodominio, ma uno solo per tutti. Hanno esigenze diverse (sessioni separate, classifiche comuni, header di sicurezza più permissivi per gli iframe) e averli tutti insieme sotto un unico indirizzo li rende comunque un sito coerente.

Un solo login per tutto

Il vantaggio più concreto delle sottocartelle non è la SEO: è il login. Con un sottodominio per progetto, ognuno aveva il suo sistema di accesso, la sua tabella utenti, il suo cookie. Sotto lo stesso dominio, invece, un cookie di sessione vale per tutte le cartelle.

Ho scritto una piccola libreria comune che fa tre cose: avvia la sessione, legge l'utente da una tabella centrale e mostra un menu uguale ovunque. Ogni app la include con una riga:

require_once $_SERVER['DOCUMENT_ROOT'] . '/core/auth.php';
$utente = p3d_user();   // utente collegato oppure null

Le app vecchie non le ho riscritte. Ognuna controlla se la libreria comune esiste: se sì la usa, altrimenti continua con il suo login di prima. Così il passaggio è stato graduale, un progetto alla volta.

Attenzione però: stessa origine significa anche stessi rischi. Se tutte le app vivono su miosito.it, una vulnerabilità in una può toccare le altre. Per questo le regole diventano più severe: cookie HttpOnly e Secure, token CSRF sui form, niente token di accesso nel localStorage e chiavi del localStorage sempre con un prefisso per app.

Spostare senza copiare: i link simbolici

Molte app vivevano in cartelle fuori dal sito principale, con le loro configurazioni. Spostarle fisicamente voleva dire rischiare di rompere percorsi e permessi. Su un hosting condiviso che li supporta, la soluzione è un link simbolico: la cartella resta dov'è e il sito principale la "vede" a un nuovo indirizzo.

C'è un dettaglio da sapere: dentro l'app, __DIR__ in PHP restituisce il percorso reale, non quello del link. Se l'app deve raggiungere file del sito principale, deve passare dalla radice del sito ($_SERVER['DOCUMENT_ROOT']) e non da percorsi relativi alla sua cartella.

Il nemico nascosto: i percorsi assoluti

Una app nata su un sottodominio dà per scontato di essere alla radice. Nel codice trovi ovunque cose come /assets/style.css o fetch('/api/salva.php'). Spostata in una sottocartella come /varco/, quella barra iniziale punta alla radice del dominio, cioè al posto sbagliato.

Quando ho migrato il gioco di carte Varco ho trovato più di novanta riferimenti del genere, sparsi tra pagine PHP, JavaScript e CSS. E non solo nel codice: anche nel database, dove ogni carta aveva il percorso della sua immagine salvato con la barra iniziale.

La regola che funziona: percorsi relativi ovunque. Togli la barra iniziale e lascia che il browser risolva l'indirizzo rispetto alla pagina. Nel CSS, ricorda che i percorsi sono relativi al file .css, non alla pagina. Prima di toccare i dati nel database, fai sempre un backup della tabella.

La checklist che userei di nuovo

1. Guarda i dati di traffico e decidi quali vecchi indirizzi meritano un redirect.
2. Definisci la struttura delle cartelle prima di spostare qualsiasi cosa.
3. Costruisci la libreria comune (login, menu) e uniscila da sola, prima delle app.
4. Migra un progetto alla volta e verificalo nel browser: pagine, chiamate API, immagini, console senza errori.
5. Cerca i percorsi assoluti nel codice e nel database.
6. Aggiorna l'URL canonico di ogni pagina e i link interni.
7. Togli i vecchi sottodomini solo quando il nuovo indirizzo funziona da qualche giorno.

In conclusione

Le sottocartelle non sono magiche, ma per un sito personale con tanti piccoli progetti hanno vinto su tutta la linea: un solo dominio da far crescere, un solo login da mantenere, un solo menu che collega tutto. E lo spazio esaurito sull'hosting, alla fine, è stato l'occasione per fare ordine.

Pubblicato il 7 ottobre 2026.