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.