SEO Internazionale e Checklist Hreflang

La SEO internazionale rende i contenuti equivalenti scopribili e utili in diverse lingue o regioni. Questa checklist controlla il sistema alla base di quelle pagine: URL, localizzazione, segnali alternativi, valuta, reindirizzamenti, scopribilità e misurazione.

Checklist: prontezza internazionale e hreflang. Timebox: 2–4 giorni lavorativi per un template e fino a cinque mercati; aggiungi un giorno per ogni checkout, regime legale o CMS sostanzialmente diverso. Responsabile: responsabile SEO internazionale, con un ingegnere web e un revisore di contenuti per mercato linguistico. Autorità di rilascio: il responsabile SEO internazionale e il responsabile del prodotto o mercato congiuntamente.

Questa non è una revisione di bozze. Decide se le persone e i motori di ricerca possono raggiungere l’URL di mercato corretto e completare il percorso localizzato.

Perché questa checklist esiste e perché viene eseguita qui

L’implementazione internazionale consuma gli output precedenti del processo SEO: mercati e obiettivi prioritari, accesso ad analytics e Search Console, la baseline tecnica, la ricerca di query a livello di mercato, l’architettura dell’informazione e l’inventario delle pagine che meritano equivalenti. Senza di essi, i team traducono in blocco e creano URL per mercati che l’azienda non può supportare.

Eseguita dopo le decisioni su mercato e template ma prima che gli URL localizzati vengano rilasciati o inviati. Prima rende il modello URL speculativo; dopo espone a crawler canonical contraddittorie, tag di ritorno incompleti, reindirizzamenti forzati e traduzioni scadenti.

La ricerca di mercato decide dove competere; l’inventario decide cosa necessita di un equivalente; questa checklist decide come ogni equivalente viene affrontato, collegato, localizzato e verificato. Una modifica riapre ogni controllo dipendente.

Input e output

Gli output sono il contratto per ingegneria, contenuti, analytics e QA. “Hreflang completo” non è sufficiente.

La checklist

Ogni elemento ha una ragione, una regola, un metodo, uno strumento e una condizione di completamento osservabile. Registra PASS (SUPERATO), FAIL (FALLITO) o N/A (NON APPLICABILE) con evidenza per ogni elemento.

1. Conferma il contratto mercato-pagina

Perché: lingua e paese differiscono. Lo spagnolo può servire Spagna, Messico o un pubblico globale, mentre un paese può aver bisogno di più lingue. Un codice locale non è una strategia di mercato. Cosa: definisci il pubblico e le capacità per ogni lingua, poi raggruppa solo pagine con scopo equivalente. Come: mappa lingua, regione, intento, offerta, prezzo, evasione ordini, responsabile legale e canale di supporto; segna le pagine sostanzialmente diverse come “nessun equivalente”. Strumento: brief di mercato, ricerca query, catalogo, requisiti legali e inventario. Completato quando: ogni URL ha un pubblico e un responsabile, ogni cluster ha un intento equivalente e nessuna cella vuota diventa una traduzione presunta.

2. Scegli una struttura URL deliberatamente

Perché: il modello di instradamento controlla il consolidamento dell’autorità, l’infrastruttura, la reportistica, l’indipendenza operativa e il rischio di migrazione per anni. Cosa: scegli domini di primo livello con codice paese (ccTLD, come example.de), sottodomini (come de.example.com) o sottocartelle (come example.com/de/) basandoti sulle conseguenze piuttosto che sulle preferenze.

Come: valuta i tre modelli in base a proprietà, vincoli legali, hosting, CMS, analytics, link equity, migrazione, autonomia di rilascio e costo operativo a cinque anni. Non utilizzare parametri query come struttura locale primaria perché sono facili da eliminare, duplicare e gestire male in canonical e link. Strumento: documento di decisione architetturale, inventario DNS e CMS, piano analytics e modello di reindirizzamento. Completato quando: un modello e una grammatica di instradamento sono approvati, ogni eccezione ha un responsabile e gli URL campione per homepage, categoria, articolo, prodotto e stati di pagina non disponibile si risolvono senza ambiguità.

3. Localizza l’esperienza, non solo le frasi

Perché: la traduzione cambia le parole; la localizzazione rende l’esperienza accurata e naturale per un mercato. L’output automatico letterale può mancare intento, terminologia, unità di misura, linguaggio fiscale, segnali di fiducia o call to action. Cosa: adatta il percorso completo, utilizzando la traduzione automatica solo come bozza dove le policy lo consentono. Come: un revisore del mercato locale verifica query, metadati, copia, media, date, unità di misura, prezzi, affermazioni legali, moduli, validazione, checkout e supporto. Ricerca parole chiave locali invece di tradurle. Strumento: guida locale, ricerca di mercato, memoria di traduzione, browser di staging e scheda di accettazione. Completato quando: zero frammenti nella lingua originale rimangono, le affermazioni sono valide localmente, il revisore completa un percorso di conversione e il suo nome, data e risultato sono memorizzati.

4. Costruisci cluster hreflang completi

Perché: un segnale alternativo unidirezionale è ambiguo; la destinazione deve confermare la relazione. Hreflang è l’attributo HTML che identifica alternative linguistiche o lingua-regione, non un’istruzione di reindirizzamento e non un sostituto della localizzazione. Cosa: fai sì che ogni membro indicizzabile elenchi se stesso e ogni altro membro valido, con un tag di ritorno corrispondente da ogni destinazione. Usa i codici lingua ISO 639-1 dove disponibili, seguiti da un codice regione ISO 3166-1 alpha-2 opzionale, come en, en-GB o pt-BR; non usare mai solo il paese. Come: genera i tag dal manifesto del cluster invece di modificare manualmente i template. Confronta gli URL assoluti finali come set e valida stato, sintassi del codice, autoreferenzialità e reciprocità. Strumento: generatore di manifesto, crawler, HTML renderizzato, client HTTP e validatore hreflang. Completato quando: il 100% dei membri indicizzabili del cluster restituisce 200, elenca lo stesso set di membri, include se stessi, utilizza codici validi e ha zero tag di ritorno mancanti o in conflitto.

5. Allinea canonical, indicizzabilità e segnali alternativi

Perché: hreflang associa alternative, mentre una canonical cross-lingua le consolida. Insieme, queste istruzioni sono in conflitto. Un URL canonico identifica il duplicato preferito; l’indicizzabilità significa che una pagina è idonea per l’indice di ricerca. Cosa: assegna a ogni pagina localizzata una canonical autoreferenziale e raggruppa solo URL 200 indicizzabili. Come: confronta la canonical dichiarata e quella selezionata da Google, le direttive robots, lo stato, la destinazione finale e la destinazione alternativa. Rimuovi URL noindex, reindirizzati, bloccati, soft-404 e non canonical finché non vengono corretti. Strumento: crawler, header, sorgente, tester robots e ispezione URL. Completato quando: ogni membro è crawlabile e indicizzabile con una canonical autoreferenziale, e nessuna alternativa reindirizza, presenta errori o canonicalizza altrove.

6. Usa x-default solo per un vero fallback

Perché: gli utenti non corrispondenti necessitano di una destinazione stabile, ma inventare un predefinito può inviare i motori di ricerca a un mercato commerciale arbitrario. x-default è un valore hreflang per un selettore di lingua, una pagina globale o un fallback che non è mirato a una lingua elencata. Cosa: aggiungi esattamente un x-default per cluster solo quando tale pagina di fallback esiste realmente. Come: scegli il selettore globale o il fallback neutro deliberatamente, includilo reciprocamente nel cluster e verifica che non costringa i visitatori ad andare avanti prima che possano scegliere. Strumento: manifesto del cluster, HTML renderizzato, browser con cookie puliti e crawler. Completato quando: ogni cluster applicabile ha un x-default reciproco con uno scopo documentato; i cluster senza un fallback valido non ne hanno nessuno.

7. Rendi coerente la scoperta delle lingue

Perché: i tag alternativi non sostituiscono i percorsi di crawling. Una pagina che esiste solo in un tag o in un controllo di modulo può rimanere difficile da scoprire per persone e crawler. Una XML sitemap è un elenco di URL leggibile dalle macchine, mentre la crawlabilità significa che i crawler possono raggiungere e leggere quegli URL. Cosa: esponi le alternative linguistiche attraverso link crawlabili e invia URL canonical completi nelle sitemap. Usa un unico metodo di implementazione per hreflang — HTML, header HTTP per file non HTML o XML sitemap — a meno che il team non possa dimostrare che più metodi rimangono identici. Come: esegui il crawling da ogni homepage di mercato, ispeziona i selettori come link ordinari, confronta le sitemap con il manifesto e verifica che la navigazione non elimini mai la pagina equivalente corrente inutilmente. Strumento: crawler, parser sitemap, browser senza JavaScript e grafo dei link. Completato quando: ogni URL localizzato prioritario ha almeno un percorso interno crawlabile, ogni voce della sitemap è canonical e restituisce 200, e tutte le fonti hreflang implementate dichiarano cluster identici.

8. Mantieni la valuta separata dal targeting linguistico

Perché: lingua, destinazione e valuta sono correlate ma non intercambiabili. Cosa: mostra la valuta e i termini corretti senza usare la sola valuta per creare o cambiare un URL locale. Come: definisci l’inclusione fiscale, il listino prezzi o il tasso di cambio, l’arrotondamento, il tempo di aggiornamento e il comportamento per prodotti non disponibili. Mantieni uno stato di prezzo crawlabile stabile per mercato; tratta la valuta selezionata dall’utente come presentazione a meno che non rappresenti un mercato distinto. Strumento: catalogo, servizio di determinazione prezzi, regole fiscali, dati strutturati e test di acquisto. Completato quando: la valuta è esplicita, pagina e checkout concordano, i qualificatori di tasse e consegna appaiono, i dati strutturati corrispondono e il cambio di valuta non modifica l’identità canonical o hreflang.

9. Sostituisci i reindirizzamenti geolocalizzati forzati con una scelta

Perché: la posizione tramite Protocollo Internet (IP) e la lingua del browser sono indizi imperfetti. I reindirizzamenti forzati possono intrappolare i crawler su un mercato, impedire a viaggiatori e utenti multilingue di scegliere, creare loop di reindirizzamento e rendere inaccessibile un URL condiviso direttamente. Cosa: mantieni ogni URL locale direttamente raggiungibile e offri un suggerimento di mercato eliminabile invece di reindirizzare esclusivamente in base all’IP o ad Accept-Language. Come: testa sessioni pulite da diverse località, stati con login e senza login, user agent dei crawler, cookie disabilitati e una preferenza esplicita memorizzata. Preserva l’instradamento equivalente della pagina corrente quando un utente cambia mercato; se non esiste alcun equivalente, spiega il fallback. Strumento: test di localizzazione del browser, client HTTP, regole edge/CDN, log del server e test di reindirizzamento automatizzati. Completato quando: una prima richiesta a ogni URL localizzato restituisce la sua pagina 200 prevista, i bot non vengono reindirizzati in base alla geografia, le scelte esplicite persistono, gli utenti possono annullarle e non si verificano loop o catene a più salti.

10. Valida template e URL rappresentativi prima del passaggio alla scala

Perché: una homepage corretta prova solo un template. I difetti internazionali spesso si nascondono in paginazione, varianti di prodotto, traduzioni mancanti, percorsi facetati e pagine non disponibili in un mercato. Cosa: testa ogni template distinto e stato limite prima del rilascio in blocco. Come: seleziona almeno 10 URL per mercato, inclusi homepage, pagine a più alta domanda, ogni template, un prodotto o servizio non disponibile, un percorso paginato o filtrato dove applicabile e un URL senza alternativa. Confronta sorgente, rendering, risposta, canonical, hreflang, navigazione, lingua del contenuto e percorso di conversione. Strumento: crawling di staging, browser, diff del manifesto, client HTTP e scheda dei casi di test. Completato quando: ogni template distinto e stato limite richiesto è rappresentato, tutti gli URL campionati superano ogni regola applicabile e qualsiasi fallimento a livello di template blocca tutti gli URL generati da quel template.

11. Stabilisci la misurazione a livello di mercato

Perché: il traffico aggregato può aumentare mentre un mercato target perde visibilità, e una nuova cartella può sembrare sana solo perché la lingua predefinita la domina. Cosa: crea dimensioni di reporting per mercato, percorso linguistico, directory, paese, dispositivo, conversione e fatturato prima del lancio. Come: verifica le visualizzazioni di pagina e gli eventi analytics in staging, collega ogni proprietà Search Console o proprietà di dominio richiesta, annota l’ora di lancio e salva una baseline per lo stesso periodo e set di query. Strumento: debugger analytics, Search Console, report paese e directory di AmICited e registro di lancio. Completato quando: le sessioni di test appaiono sotto il mercato e il percorso previsti, le conversioni mantengono mercato e valuta, tutte le proprietà sono accessibili al responsabile e una baseline datata esiste prima del rilascio.

12. Esegui la verifica in produzione e mantieni la responsabilità

Perché: lo staging non può provare DNS, CDN, reindirizzamenti in produzione, canonical finali o ciò che Google seleziona dopo la scoperta. Cosa: ripeti i controlli critici immediatamente dopo il deployment e assegna il monitoraggio invece di considerare il lancio come completamento. Come: esegui il crawling del campione in produzione, invia le sitemap aggiornate, ispeziona gli URL prioritari, verifica log e analytics, quindi pianifica controlli dopo la scoperta e dopo la prima finestra di reporting significativa. Strumento: crawler di produzione, AmICited, Search Console, log del server e tracker degli incidenti. Completato quando: la produzione corrisponde al manifesto approvato, non rimangono fallimenti bloccanti, ogni osservazione ha un timestamp e ogni controllo dati differito ha un responsabile e una data invece di un “monitora” senza scadenza.

Strumenti in AmICited

AmICited fornisce evidenze da Search Console per scoperta, lancio e monitoraggio. Non sostituisce un revisore del mercato locale o un crawling completo dei tag reciproci.

1. Apri Paesi e Dispositivi all’ report paesi e dispositivi. Analizza i paesi con impressioni ma posizione o percentuale di clic debole prima di presupporre l’assenza di domanda.

2. Usa Directory di Google Search al report directory per confrontare le cartelle delle lingue e approfondire i template deboli.

3. Apri Sitemap e Indicizzazione al report sitemap e indicizzazione. Conferma il download senza avvisi o errori, quindi richiedi l’indicizzazione per gli URL prioritari. Le richieste non possono rendere indicizzabili URL bloccati.

4. Controlla gli URL rappresentativi in Ispezione URL al report ispezione URL. Confronta le canonical dichiarate e quelle selezionate da Google. La sua lista di copertura è un campione, non un audit hreflang.

Regole decisionali

“Grave” è una condizione che blocca il rilascio o richiede correzione, non un’opinione sulla qualità della traduzione.

I divari nella percentuale di clic e nella posizione sono diagnostici, non fallimenti automatici. Confronta pagine e periodi simili; nessuna percentuale universale prova un difetto di localizzazione.

Consegnabile: il pacchetto di lancio internazionale

Consegna una cartella con versioni o un bundle di ticket con questi contenuti minimi:

01-modello-url.md
- Decisione, alternative scartate, grammatica dell'instradamento, responsabili, migrazione e rollback

02-matrice-mercato-pagina.csv
- mercato, lingua, regione, URL sorgente, URL localizzato, intento, disponibilità, revisore

03-manifesto-hreflang.csv
- URL, codice, canonical autoreferenziale, alternative, x-default, stato, indicizzabilità, risultato

04-accettazione-localizzazione.csv
- URL, campo/percorso, revisore, risultato, evidenza, eccezione

05-specifica-reindirizzamenti-selettore.md
- logica di suggerimento, scelta esplicita, persistenza, comportamento bot, comportamento senza equivalente

06-verifica-lancio.csv
- URL, data di deployment, risultato crawling, stato sitemap, stato ispezione, evidenza analytics, responsabile

Decisione: SUPERATO — RILASCIA | FALLITO — BLOCCA
Prossima data di revisione e responsabile indicato:

Riconcilia il manifesto con la produzione. Archivia le eccezioni con motivazione, rischio, approvatore, scadenza e responsabile della correzione. Un modello URL, template, set di lingue, canonical o policy di reindirizzamento modificati riapre i controlli interessati.

Cosa va storto

• Ogni pagina sorgente viene tradotta automaticamente. Pagine senza domanda locale, prodotti non disponibili e affermazioni non supportate vengono pubblicate perché la traduzione è stata scambiata per selezione di mercato.
• La lingua predefinita diventa canonical ovunque. I motori di ricerca ricevono istruzioni di consolidamento e alternative contemporaneamente; gli URL localizzati scompaiono o viene selezionato l’URL sbagliato.
• Solo la pagina sorgente elenca le alternative. I tag di ritorno mancanti rendono il cluster incompleto anche se un template appare corretto.
• I codici paese vengono usati come lingue. Valori come UK o BR non esprimono una coppia lingua-regione; esempi validi sono en-GB e pt-BR.
• x-default punta al mercato più grande. Una pagina commerciale nazionale viene etichettata come fallback neutro e riceve utenti che non può servire adeguatamente.
• Il selettore è solo JavaScript. Gli utenti vedono un menu a discesa, ma i crawler non hanno link ordinari per scoprire le alternative.
• La posizione IP forza l’instradamento. Crawler e viaggiatori non possono mantenere un URL richiesto direttamente, le cache variano per località e compaiono loop di reindirizzamento tra le regole edge e applicative.
• La valuta crea URL di lingua duplicati. Parametri o percorsi si moltiplicano mentre contenuti, canonical e prezzi strutturati discordano.
• L’homepage supera e si passa alla scala. I template di prodotto, categoria, paginazione e senza equivalente emettono set di tag diversi su migliaia di URL.
• La reportistica inizia dopo il lancio. Nessuna baseline o annotazione esiste, quindi i team non possono separare gli effetti dell’implementazione da stagionalità, domanda di marca o rilasci non correlati.

Fase successiva

Questa checklist consegna il suo pacchetto di lancio alla checklist QA pre-pubblicazione. Il QA necessita del modello URL, del candidato di produzione, del manifesto, delle approvazioni di localizzazione, delle modifiche a sitemap e reindirizzamenti, del set di test, dell’autorità di rilascio e delle eccezioni. Verifica questi documenti prima del rilascio.

Dopo il lancio, il responsabile SEO internazionale mantiene il manifesto. Nuove pagine, prodotti rimossi, aggiunte di lingue, migrazioni di instradamento e modifiche alle canonical sono modifiche al cluster, non modifiche isolate alle pagine. Rivaluta i cluster interessati, aggiorna le sitemap, ispeziona gli URL prioritari e annota la reportistica ogni volta.

FAQ

Domande frequenti

Rendi misurabile il primo lancio internazionale

Usa il report paesi e dispositivi per acquisire la baseline del mercato, poi rilascia solo quando il modello URL, il record di localizzazione, il manifesto del cluster, i reindirizzamenti, la sitemap e il campione rappresentativo in produzione superano tutti i controlli. Il CTA di chiusura del layout academy fornisce il percorso successivo in AmICited.