Un founder SaaS sceglie uno schema di URL per il blog multilingue il primo giorno e ne sopporta le conseguenze per anni. Se sbagliate, Google tratta ogni articolo tradotto come una pagina separata e con autorita' inferiore. Se scegliete bene, gli stessi articoli ereditano l'autorita' del dominio del sito di marketing che gia' condividono. La scelta e' piccola nel codice, enorme nell'effetto cumulativo.
Questo articolo e' la decisione strutturata. Quattro schemi sono in gioco: sottocartella (kamaan.io/es/blog/slug), sottodominio (es.kamaan.io/blog/slug), ccTLD (kamaan.es/blog/slug) e parametro di query (kamaan.io/blog/slug?lang=es). Tre di essi funzionano in casi ristretti. Uno e' lo standard per i blog SaaS nel 2026. L'argomentazione e' qui sotto.
Punti chiave rapidi
- Le sottocartelle (/es/blog/slug) ereditano l'autorita' del dominio radice e sono lo standard per i blog SaaS. La configurazione e' banale, l'hreflang e' pulito e il blog viaggia sullo stesso equity SEO del sito di marketing.
- I sottodomini (es.kamaan.io) hanno senso solo quando ogni regione necessita di uno stack separato, di una proprieta' separata o di isolamento legale. Il sottodominio tradotto accumula autorita' lentamente perche' Google lo tratta come un host distinto.
- I ccTLD (kamaan.es) sono per operazioni veramente multi-paese con entita' locali. Il segnale geografico piu' forte, il costo di configurazione piu' alto e l'accumulo di autorita' piu' lento.
- I parametri di query (?lang=es) rompono la semantica del crawl, frammentano l'hreflang e producono segnali di contenuto duplicato. Da evitare per qualsiasi contenuto indicizzabile.
- Auto-Multilingual Delivery di Kamaan usa di default URL a sottocartella (/es/blog/, /de/blog/, /fr/blog/, /it/blog/) con hreflang corretto emesso lato server, quindi la decisione viene presa e implementata in un solo passaggio.
I quattro schemi di URL a colpo d'occhio
Ogni schema e' una risposta diversa a un'unica domanda: dove, nell'URL, vive la lingua? Le quattro risposte, con le conseguenze strutturali che ognuna porta con se':
Sottocartella. kamaan.io/es/blog/slug. La lingua sta come segmento di percorso tra l'host e il resto dell'URL. Dal punto di vista di Google, questo e' lo stesso host di kamaan.io. PageRank, segnali di trust e backlink verso kamaan.io fluiscono verso la sottocartella. L'hreflang e' lineare: ogni versione linguistica e' un URL alternativo sullo stesso host. Il blog viaggia sull'autorita' del sito di marketing.
Sottodominio. es.kamaan.io/blog/slug. La lingua e' parte dell'host. Dal punto di vista di Google, si tratta di un host distinto. L'autorita' non fluisce automaticamente tra host. Il sottodominio spagnolo parte da zero autorita' di dominio e costruisce la propria. L'hreflang funziona comunque, ma ogni versione linguistica deve accumulare segnali separatamente.
ccTLD. kamaan.es/blog/slug. Il paese e' l'intero dominio. Il segnale di targeting geografico piu' forte possibile. Ogni ccTLD e' un sito completamente separato che deve essere gestito, ospitato e posizionato per conto proprio. L'autorita' si accumula per paese, lentamente. La configurazione comporta DNS separati, SSL separati, spesso entita' legali separate.
Parametro di query. kamaan.io/blog/slug?lang=es. La lingua e' un parametro dell'URL. Google spesso, ma non sempre, tratta ?lang=es come la stessa pagina dell'URL base. Le annotazioni hreflang su URL parametrizzati sono fragili. Parametri diversi possono produrre segnali canonical conflittuali. La maggior parte dei CDN rimuove o ignora i parametri quando esegue il caching. La storia del crawl e' confusa nella migliore delle ipotesi.
Perche' le sottocartelle vincono per i blog SaaS
Tre ragioni, in ordine di importanza.
Eredita' di autorita'. Un sito di marketing SaaS e' un singolo dominio con un singolo profilo di autorita'. Il blog fa parte di quel profilo, non e' un'entita' separata. Le sottocartelle mantengono il blog dentro quel profilo. I backlink verso la homepage di kamaan.io, le pagine prodotto e gli articoli di blog esistenti contribuiscono tutti all'autorita' di /es/blog/slug perche' si trova sullo stesso host. La versione spagnola parte con qualunque potere di ranking la versione inglese abbia gia' nei registri di Google.
Semplicita' operativa. Una voce DNS. Un certificato SSL. Una configurazione CDN. Un host per la sitemap. Una proprieta' di Search Console che copre tutto. Aggiungere una nuova lingua e' un cambio di routing nel frontend, non un nuovo host da provisionare. Per un piccolo team SaaS questa e' la differenza tra spedire il multilingue in un pomeriggio e spedirlo in uno sprint.
Pulizia dell'hreflang. Le annotazioni hreflang sono piu' semplici quando tutte le versioni di una pagina sono sullo stesso host. L'hreflang tra host funziona ma e' piu' soggetto a errori. L'hreflang sullo stesso host e' qualcosa che gli strumenti di Google verificano in pochi minuti. Meno archi tra domini ci sono nel grafo hreflang, meno occasioni ci sono per l'implementazione di andare alla deriva.
John Mueller di Google ha dichiarato ripetutamente che la differenza tra sottocartelle e sottodomini e' piccola da un punto di vista puramente di ranking. Sono gli argomenti operativi e di eredita' di autorita' dove le sottocartelle prendono effettivamente il vantaggio per il SaaS.
Quando un sottodominio e' la scelta giusta
Tre casi legittimi per i sottodomini, e poco altro.
Stack tecnici separati per regione. Il sito di marketing tedesco gira su una piattaforma diversa dal resto dell'azienda perche' la filiale tedesca lo ha ereditato attraverso un'acquisizione. Forzarlo in una sottocartella richiederebbe una ripiattaformatura che nessuno vuole finanziare. Un sottodominio isola lo stack tecnologico senza spezzare il brand.
Proprieta' o autonomia legale separate. Ogni regione e' gestita da un team diverso, a volte da un'entita' legale diversa. I team vogliono pieno controllo sui propri contenuti e infrastrutture senza dover coordinare un host condiviso. I sottodomini permettono a ogni team di operare in modo indipendente pur condividendo il brand madre.
Esperimenti SEO regionali aggressivi. I sottodomini sono il modo piu' pulito per fare A/B test di strategie SEO che toccano la struttura del sito senza inquinare i segnali del sito principale. Da usare solo quando il programma di test e' maturo.
In ogni altro caso il sottodominio vi costa l'eredita' di autorita' e non vi guadagna nulla. L'equity di marketing di kamaan.io non si trasferisce a es.kamaan.io. La versione spagnola deve guadagnarsi i ranking da zero.
Quando i ccTLD sono effettivamente necessari
I ccTLD sono la scelta giusta quando l'azienda opera come business separati in ogni paese. Catalogo diverso, prezzi diversi, termini legali diversi, possibilmente brand diversi. Amazon fa cosi': amazon.de, amazon.co.uk, amazon.fr operano ognuno come storefront a se' stante con cataloghi specifici per paese.
Per un prodotto SaaS, i ccTLD sono raramente la risposta giusta. Il prodotto e' lo stesso ovunque. Il prezzo e' in una sola valuta o con una conversione chiara. La struttura legale e' un'unica entita'. Suddividere il sito di marketing tra ccTLD crea da quattro a quindici siti separati che hanno tutti bisogno della propria autorita', delle proprie campagne di backlink, delle proprie content ops. Il beneficio di targeting geografico e' reale ma l'overhead operativo e' enorme.
Un test utile: se non riuscite a nominare tre cose che sono genuinamente diverse nell'operazione tedesca rispetto a quella inglese (oltre alla traduzione), non vi serve un ccTLD.
Perche' i parametri di query rompono la storia dell'indicizzazione
L'approccio a parametro di query e' attraente perche' richiede quasi nessun cambiamento infrastrutturale. Il framework gia' instrada kamaan.io/blog/slug; aggiungere ?lang=es e' una singola riga di codice. Il problema e' cosa fa Google con quell'URL.
Il trattamento di default di Google per i parametri di query e' considerarli lo stesso URL canonical a meno che qualcosa di esplicito non gli dica diversamente. La variante ?lang=es potrebbe non essere indicizzata affatto. Anche se viene indicizzata, le annotazioni hreflang su URL parametrizzati non sono affidabili: molte implementazioni di hreflang nel head non sopravvivono alla logica di parsing dei parametri del crawler di Google. I CDN a volte cachano versioni con i parametri rimossi, restituendo il contenuto inglese ai lettori che hanno cliccato il link spagnolo. Le analytics vengono frammentate tra le combinazioni di parametri.
Per preferenze non indicizzabili (il toggle di lingua dell'interfaccia per utenti loggati, per esempio), i parametri di query vanno bene. Per il blog di marketing pubblico dove l'indicizzazione di Google e' l'intero scopo, non vanno bene. L'albero decisionale e' breve: se volete che Google posizioni una versione tradotta, l'URL deve essere un percorso pulito e privo di parametri.
Cosa emette Kamaan di default
La funzionalita' Auto-Multilingual Delivery di Kamaan usa di default lo schema a sottocartella. Quando pubblicate un articolo in inglese su kamaan.io/blog/auto-translate-blog-posts, le versioni spagnola, tedesca, francese e italiana vanno in live su kamaan.io/es/blog/auto-translate-blog-posts, kamaan.io/de/blog/auto-translate-blog-posts, kamaan.io/fr/blog/auto-translate-blog-posts e kamaan.io/it/blog/auto-translate-blog-posts. Lo slug viene traslitterato in ASCII quando la focus keyword viene tradotta, cosi' i caratteri accentati non rompono mai l'URL.
Le annotazioni hreflang su ogni versione puntano a ogni altra versione, se stessa inclusa. La sitemap.xml include ogni URL tradotto con l'annotazione hreflang corretta. L'URL canonical su ogni versione punta a quella versione, non all'originale inglese.
Quella e' l'intera decisione. Non scegliete uno schema di URL; il CMS pubblica nello schema che e' stata la risposta giusta almeno dal 2017 e resta la risposta giusta nel 2026.
Due flussi di lavoro reali
Un founder SaaS bootstrapped scrive un articolo in Kamaan, preme pubblica in inglese e ha rapidamente URL live su kamaan.io/blog/..., kamaan.io/es/blog/..., kamaan.io/de/blog/..., kamaan.io/fr/blog/..., kamaan.io/it/blog/.... Search Console rileva gli alternate entro 48 ore. Il founder non ha configurato DNS, non ha impostato proprieta' aggiuntive di Search Console, non ha scritto una singola riga di logica di routing.
Un'agenzia gestisce tre clienti SaaS su schemi a sottocartella da un singolo account Kamaan. Ogni cliente ha il proprio dominio. Ogni cliente ha le proprie quattro lingue target. Dodici set di URL vanno in live ogni settimana. L'operatore dell'agenzia non tocca mai i DNS per nessuno di loro: il frontend di ogni cliente e' gia' configurato per instradare /lang/blog/ e Kamaan si occupa del resto.
FAQ
La decisione tra sottocartella e sottodominio e' ancora rilevante nel 2026?
Si. La meccanica tecnica non e' cambiata dalla fine degli anni 2010 e le linee guida pubblicate da Google trattano ancora sottocartelle e sottodomini come host distinti. L'argomento dell'autorita' che si compone, che favorisce le sottocartelle, e' diventato in realta' piu' forte poiche' gli aggiornamenti core dell'algoritmo hanno reso il trust a livello di dominio piu' importante rispetto ai segnali a livello di pagina.
Posso passare dai parametri di query alle sottocartelle in seguito?
Si, con redirect 301 da ogni vecchio URL parametrizzato al nuovo URL a sottocartella. Il problema e' che probabilmente i vecchi URL con parametri non erano ben indicizzati in partenza, quindi la migrazione recupera pochissima autorita'. La sistemazione di solito significa rimettere a zero il timer SEO sulle versioni tradotte.
E le variazioni regionali della stessa lingua, come es-MX vs es-ES?
Se il contenuto e' genuinamente diverso per regione, usate un percorso regione-e-lingua come /es-mx/blog/ e /es-es/blog/. Se il contenuto e' lo stesso, usate il percorso solo lingua /es/blog/ e lasciate che sia Google a capire quale regione servire. La maggior parte dei blog SaaS non ha contenuto spagnolo specifico per regione.
Kamaan supporta sottodomini o ccTLD se ne ho bisogno?
Kamaan emette URL a sottocartella di default perche' e' la risposta giusta per quasi ogni blog SaaS. Se un deployment specifico necessita di sottodomini, la REST API consegna i contenuti con campi di locale che potete instradare sotto qualsiasi struttura di sottodominio operiate. L'operazione su ccTLD richiede di gestire un sito separato per paese ed e' al di fuori del flusso di default.
Come gestisce Kamaan le annotazioni hreflang?
Ogni versione tradotta emette tag link hreflang nel head che puntano a ogni altra versione linguistica, incluso un riferimento a se stessa. Le stesse annotazioni compaiono nella sitemap.xml. Le annotazioni vengono ri-propagate automaticamente quando modificate la versione inglese e le traduzioni vengono ripubblicate.
Google mi penalizzera' se cambio schema di URL in seguito?
Non direttamente. Google pubblica linee guida per le migrazioni di sito e una migrazione ben eseguita con redirect 301 completi preserva la maggior parte dell'autorita'. Il costo nascosto sono i mesi che servono ai redirect per assestarsi e ai segnali di freshness per ritornare in linea. Scegliere lo schema giusto all'inizio costa molto meno che migrare in seguito.
Correlati su Kamaan
- Come costruire un blog multilingue: una guida completa per prodotti SaaS. La guida di setup completa in cui questo articolo si inserisce: architettura, workflow di contenuto, sitemap e hreflang.
- SEO multilingue: cos'e', perche' conta e come farlo bene. Il contesto SEO piu' ampio: ccTLD vs sottodominio vs sottocartella nel panorama del SEO internazionale.
- Tag hreflang spiegati: il modo giusto di configurarli per un blog. La meccanica dell'hreflang nel head HTML, nella sitemap.xml e negli header HTTP.
- Tradurre automaticamente i post del blog: cosa funziona, cosa si rompe e cosa fa Kamaan al suo posto. Il pezzo companion sul motore di traduzione che riempie gli URL che avete appena scelto.
Inizia con Kamaan
URL a sottocartella, hreflang corretto, voci in sitemap, tutto gestito al momento della pubblicazione
Kamaan vi da una dashboard unica per tutti i blog dei vostri prodotti, tradotti automaticamente in oltre 99 lingue ad ogni pubblicazione. Gli URL vengono spediti su /lang/blog/slug sul vostro dominio esistente. Un account copre siti illimitati a 19 dollari al mese, flat. Primo mese gratuito.
