Sottodominio o sottocartella: dove mettere blog e shop

Sottodominio o sottocartella non è una domanda di gusto: cambia dove Google mette la fiducia che il sito principale ha già costruito. La risposta breve, per un blog o uno shop collegati a un sito esistente, è quasi sempre la sottocartella (sito.it/blog, sito.it/shop): eredita più facilmente l'autorità accumulata, condivide la stessa proprietà in Search Console e non richiede una seconda infrastruttura da mantenere.

Ma "quasi sempre" non è "sempre". Ci sono situazioni tecniche reali - un fornitore SaaS per l'help center, una piattaforma e-commerce che non si integra nel CMS principale, un'app con requisiti di sicurezza diversi - in cui il sottodominio non è una scelta pigra ma l'unica opzione disponibile, oppure quella corretta. Il resto di questo articolo spiega cosa cambia davvero a livello tecnico, quali costi di gestione porta ciascuna opzione, e come riconoscere i casi in cui vale la pena pagare il prezzo del sottodominio.

Cosa vede Google: host distinti, non autorità automaticamente condivisa

Un sottodominio (blog.sito.it) e una sottocartella (sito.it/blog) sono trattati in modo diverso soprattutto per un motivo tecnico: un sottodominio può puntare a un server, un CMS e persino un certificato SSL diversi dal dominio principale, mentre una sottocartella vive per definizione nello stesso host. Google non ha una regola fissa che dichiari che i sottodomini partono sempre da zero, ma tratta ogni host come un contesto a sé finché non emergono segnali chiari di collegamento: link reciproci, lo stesso brand nei tag title, una navigazione condivisa.

Con una sottocartella questo problema non si pone: il grafico di link interni del sito - homepage, menu di navigazione, articoli correlati - raggiunge il nuovo contenuto attraverso gli stessi percorsi che già portano autorità alle pagine esistenti. Con un sottodominio i link interni contano comunque, ma il nuovo host deve costruire nel tempo la propria base di segnali esterni (backlink, comportamento degli utenti, cronologia di scansione) prima che Google smetta di trattarlo come un sito nuovo appoggiato a uno vecchio.

• La sottocartella eredita il contesto di fiducia del dominio in modo diretto, perché fa parte dello stesso grafico di link.
• Il sottodominio parte con margini di cautela propri e li supera solo accumulando segnali autonomi nel tempo.
• Nessuna delle due opzioni è preclusa dall'indicizzazione: cambia la velocità con cui accumulano fiducia, non se vengono scansionate.

Il blog aziendale: la sottocartella è quasi sempre la scelta giusta

Il caso più semplice è anche il più comune: un blog che pubblica contenuti informativi per portare traffico verso le pagine di prodotto o servizio. Qui l'obiettivo esplicito è che blog e sito principale si rafforzino a vicenda tramite link interni, e questo funziona meglio quando condividono lo stesso host. Un articolo del blog che linka a una pagina prodotto, e una pagina prodotto che linka a un articolo di approfondimento, restano nello stesso grafico di autorità: non c'è un salto di host da giustificare, né una seconda proprietà da monitorare in Search Console.

Il motivo per cui alcuni team scelgono comunque blog.sito.it è quasi sempre organizzativo, non tecnico: il blog gira su un CMS diverso (per esempio WordPress) mentre il sito principale è su un framework custom, ed è più veloce puntare un sottodominio a un server separato che integrare i due sistemi sotto lo stesso path. È un compromesso legittimo se il tempo di sviluppo è la priorità, ma si sta scambiando velocità di lancio contro un'eredità di autorità più lenta - meglio deciderlo consapevolmente che scoprirlo un anno dopo confrontando il rendimento del blog con quello delle pagine di prodotto.

L'e-commerce: il caso in cui la scelta pesa di più

Per uno shop il conflitto tra velocità tecnica e beneficio SEO è più acuto, perché il catalogo prodotti è spesso il valore economico diretto delle pagine da posizionare. Molte piattaforme e-commerce - soluzioni SaaS di terze parti, o un carrello separato dal CMS del sito - offrono nativamente solo un sottodominio: shop.sito.it è una semplice configurazione DNS, mentre sito.it/shop richiede che qualcosa - un reverse proxy, una CDN configurata per riscrivere i percorsi, o un'integrazione nativa nel CMS - inoltri le richieste al sistema che gestisce il negozio, preservando certificato e header coerenti.

Quella riscrittura di percorso è lavoro tecnico reale, non una casella da spuntare: bisogna decidere chi genera i redirect per i prodotti esauriti e come si comportano parametri di tracciamento e filtri di categoria attraverso il proxy. Se il team del sito e il team dello shop sono organizzazioni diverse - un'agenzia, un fornitore SaaS - la sottocartella richiede coordinamento continuo; il sottodominio lo richiede soprattutto una tantum, alla configurazione iniziale.

• Sottocartella: costo quasi nullo se il CMS la supporta nativamente; costo alto e ricorrente se il carrello è un sistema esterno dietro un proxy.
• Sottodominio: attivo in poche ore via DNS, ma isola il catalogo dal grafico di link del sito principale finché non accumula segnali propri.
• In entrambi i casi, i link interni verso lo shop - menu, footer, articoli del blog - restano il fattore che aiuta di più la parte più debole.

Help center e portali di terze parti: spesso la sottocartella non è disponibile

Gli strumenti di help desk più diffusi - piattaforme di ticketing, basi di conoscenza in hosting SaaS, forum di community - quasi sempre offrono solo un sottodominio personalizzato come opzione di collegamento, non una vera sottocartella. Il motivo è lo stesso della sezione precedente, portato all'estremo: il fornitore gestisce un'infrastruttura condivisa tra migliaia di clienti e non espone un modo per instradare un percorso del vostro dominio verso i suoi server senza un livello di proxy che dovreste costruire e mantenere voi.

In questo caso la domanda utile non è sottodominio o sottocartella, perché la seconda opzione spesso non esiste senza un investimento infrastrutturale specifico, ma se vale la pena costruire quel proxy. Per contenuti di supporto molto cercati - articoli su come annullare un abbonamento, o come reimpostare una password - che intercettano ricerche reali e non solo utenti già clienti, la risposta può essere sì; per un help center consultato quasi solo da chi arriva da un link interno all'app, il beneficio SEO di forzare la sottocartella è marginale e spesso non giustifica il lavoro di manutenzione del proxy.

I costi di gestione che il confronto dimentica

La discussione su sottodominio e sottocartella si concentra quasi sempre sull'effetto SEO e trascura i costi operativi che restano per tutta la vita della proprietà, non solo al momento del lancio.

• Certificato SSL: un sottodominio ne richiede uno proprio o un wildcard configurato correttamente; se scade, quella parte del sito diventa irraggiungibile o segnalata come non sicura.
• Search Console: con proprietà a prefisso URL, un sottodominio è una proprietà separata da verificare a parte (una proprietà Dominio invece lo include); se nessuno la verifica, quel pezzo di sito naviga senza dati di indicizzazione o errori di scansione.
• Sitemap e robots.txt: vanno mantenuti per ciascun host; un robots.txt dimenticato sul sottodominio può bloccare la scansione per mesi senza che nessuno se ne accorga.
• Analytics: il passaggio tra dominio principale e sottodominio richiede cross-domain tracking configurato, altrimenti le sessioni si spezzano o si duplicano nei report.
• Cookie e autenticazione: un cookie impostato sul dominio principale non è automaticamente leggibile su un sottodominio se non è configurato sul dominio radice; incide su login e personalizzazione.
• Manutenzione infrastrutturale: un sottodominio spesso significa un secondo stack da aggiornare e mettere in sicurezza, anche quando il contenuto che ospita è minimo.

Migrare da sottodominio a sottocartella è un progetto, non un redirect

Quando un blog o uno shop nato su sottodominio dimostra il proprio valore e si decide di consolidarlo sotto il dominio principale, l'operazione va trattata come una migrazione a tutti gli effetti, con lo stesso rigore di un cambio di dominio: non basta un redirect generico dalla vecchia root alla nuova.

Le migrazioni raffazzonate - un redirect wildcard dalla root del sottodominio alla root della sottocartella, senza mappare i singoli percorsi - sono la causa più comune di perdita di traffico: un crawler che arriva su blog.sito.it/articolo-x e viene rediretto genericamente su sito.it/blog invece che su sito.it/blog/articolo-x non trova il contenuto specifico, e non associa quella pagina alla nuova posizione corretta.

• Mappare ogni URL del sottodominio al suo equivalente nella sottocartella con un redirect 301 uno a uno, non un redirect generico verso la home.
• Aggiornare i tag canonical interni e i link nel menu, nel footer e negli articoli che puntavano al vecchio host.
• Generare e inviare la nuova sitemap sotto la property del dominio principale, lasciando attiva la vecchia property solo per verificare i redirect.
• Mettere in conto un periodo di assestamento in cui Google ricollega i segnali del vecchio host al nuovo percorso.
• Aggiornare i link esterni aggiornabili - profili social, directory - perché un link diretto al nuovo URL resta preferibile a un redirect.

Quando il sottodominio è davvero giustificato

Al netto della preferenza di default per la sottocartella, ci sono situazioni in cui il sottodominio è la scelta corretta, non solo quella più comoda.

La scelta tra sottodominio e sottocartella per le versioni internazionali di un sito - per esempio it.sito.com contro sito.com/it - risponde a una logica diversa, legata a hreflang e targeting geografico, e non rientra in questo confronto: qui l'attenzione resta sulle sezioni funzionali di un singolo sito in una singola lingua, non sulle sue versioni per paese.

• Vincolo tecnico reale del fornitore: il servizio (ticketing, community, area riservata) non offre alcuna opzione di sottocartella, e un reverse proxy costerebbe più del beneficio SEO atteso.
• Requisiti di sicurezza o conformità diversi: un'area che richiede un dominio proprio per l'isolamento dei cookie, per policy di Content Security Policy specifiche, o per certificazioni che il resto del sito non ha.
• Pubblico ed editoriale radicalmente diversi: una documentazione tecnica per sviluppatori, con un proprio team, pensata per non competere nelle stesse ricerche del sito marketing.
• Un'applicazione web autenticata - dashboard cliente, portale utenti - che non deve essere indicizzata insieme ai contenuti pubblici.
• Vincoli organizzativi permanenti: due team con stack e proprietà del codice separati in modo strutturale, non solo perché nessuno ha ancora integrato i due sistemi.

Errori comuni da evitare

Alcuni errori tornano più spesso di altri in questa decisione, ed è più facile evitarli in anticipo che correggerli dopo che il sito è già in produzione.

Nessuno di questi errori riguarda la scelta in sé - sottodominio e sottocartella sono entrambe opzioni valide in contesti diversi - riguardano la mancanza di manutenzione una volta presa la decisione. La domanda da farsi non è quale opzione sia più SEO in astratto, ma quale infrastruttura il team è realmente in grado di mantenere nel tempo, senza che nessuno se ne occupi in modo esplicito.

• Scegliere il sottodominio per abitudine, senza un vincolo tecnico reale, perdendo l'effetto di internal linking senza alcun beneficio in cambio.
• Lanciare una landing di campagna su un sottodominio temporaneo e dimenticarsene: resta indicizzata per anni come contenuto orfano, senza link interni e senza manutenzione.
• Non verificare mai la property del sottodominio in Search Console, scoprendo mesi dopo che mancano dati di indicizzazione e di errori di scansione per quella parte del sito.
• Configurare un reverse proxy per una sottocartella senza preservare header e canonical corretti, generando contenuto duplicato accessibile sia dal vecchio host sia dal nuovo.
• Eseguire una migrazione da sottodominio a sottocartella con redirect generici invece che mappati uno a uno, perdendo il valore specifico accumulato da ogni singola pagina.