Internationell SEO och Hreflang-checklista

Internationell SEO gör motsvarande innehåll upptäckbart och användbart över språk och regioner. Denna checklista styr systemet bakom dessa sidor: URL:er, lokalisering, alternativsignaler, valuta, omdirigeringar, upptäckbarhet och mätning.

Checklista: international och hreflang-beredskap. Tidsram: 2–4 arbetsdagar för en mall och upp till fem marknader; lägg till en dag för varje väsentligt annorlunda kassa, rättslig regim eller CMS. Ägare: internationell SEO-ansvarig, tillsammans med en webbutvecklare och en innehållsgranskare per språk på marknaden. Lanseringsmyndighet: den internationella SEO-ansvariga och produkt- eller marknadsägaren gemensamt.

Detta är inte korrekturläsning. Det avgör om människor och sökmotorer kan nå rätt marknads-URL och genomföra den lokaliserade resan.

Varför denna checklista finns och varför den körs här

Internationell implementation använder tidigare resultat från SEO-processen : prioriterade marknader och mål, analys- och Search Console-åtkomst, den tekniska grundlinjen, marknadsnivåns sökordsforskning, informationsarkitektur och inventeringen av sidor som förtjänar motsvarigheter. Utan dem översätter team i bulk och skapar URL:er för marknader som verksamheten inte kan stödja.

Kör den efter marknads- och mallbeslut men innan lokaliserade URL:er släpps eller skickas in. Tidigare gör URL-modellen spekulativ; senare exponerar motsägelsefulla kanoniska taggar, ofullständiga retur-taggar, tvingade omdirigeringar och tunna översättningar för sökrobotar.

Marknadsundersökning avgör var du ska konkurrera; inventeringen avgör vad som behöver en motsvarighet; denna checklista avgör hur varje motsvarighet adresseras, kopplas, lokaliseras och verifieras. En förändring återöppnar varje beroende kontroll.

Indata och utdata

Utdata är kontraktet för teknik, innehåll, analys och kvalitetssäkring. “Hreflang klar” är inte tillräckligt.

Checklistan

Varje objekt har en anledning, en regel, en metod, ett verktyg och ett observerbart slutförandevillkor. Anteckna GODKÄNT, UNDERKÄNT eller EJ TILLÄMPLIGT med bevis för varje objekt.

1. Bekräfta marknad-sid-kontraktet

Varför: språk och land skiljer sig åt. Spanska kan betjäna Spanien, Mexiko eller en global publik, medan ett land kan behöva flera språk. En lokalkod är inte en marknadsstrategi. Vad: definiera målgruppen och kapaciteten för varje lokalkod, klustra sedan endast sidor med motsvarande syfte. Hur: kartlägg språk, region, intention, erbjudande, pris, uppfyllelse, juridisk ägare och supportväg; markera väsentligt olika sidor som “ingen motsvarighet”. Verktyg: marknadsbeskrivning, sökordsforskning, katalog, juridiska krav och inventering. Klar när: varje URL har en målgrupp och en ägare, varje kluster har motsvarande intention och ingen tom cell blir en antagen översättning.

2. Välj en URL-struktur medvetet

Varför: vägmodellen styr auktoritetskonsolidering, infrastruktur, rapportering, operativt oberoende och migrationsrisk i flera år. Vad: välj toppdomäner med landskod (ccTLD, såsom example.de), underdomäner (såsom de.example.com) eller undermappar (såsom example.com/de/) baserat på konsekvenser snarare än preferens.

Hur: poängsätt de tre modellerna mot ägarskap, juridiska begränsningar, hosting, CMS, analys, länkkapital, migration, releasesjälvständighet och femårig driftskostnad. Använd inte frågeparametrar som primär lokalkodsstruktur eftersom de är lätta att tappa, duplicera och hantera felaktigt i kanoniska taggar och länkar. Verktyg: arkitektur-beslutspost, DNS- och CMS-inventering, analysplan och omdirigeringsmodell. Klar när: en modell och väggrammatik är godkänd, varje undantag har en ägare, och exempel-URL:er för startsida, kategori, artikel, produkt och sidor som inte är tillgängliga löses entydigt.

3. Lokalisera upplevelsen, inte bara meningarna

Varför: översättning ändrar ord; lokalisering gör upplevelsen korrekt och naturlig för en marknad. Bokstavlig maskinutmatning kan missa intention, terminologi, enheter, skattespråk, förtroendesignaler eller uppmaningar till handling. Vad: anpassa hela resan, använd maskinöversättning endast som utkast där policy tillåter. Hur: en granskare på marknaden kontrollerar sökfrågor, metadata, text, media, datum, enheter, priser, juridiska påståenden, formulär, validering, kassa och support. Forska efter lokala sökord istället för att översätta dem. Verktyg: lokalkodsguide, marknadsundersökning, översättningsminne, staging-webbläsare och godkännandeblad. Klar när: noll fragment på källspråk återstår, påståenden är giltiga lokalt, granskaren genomför en konverteringsväg och deras namn, datum och resultat lagras.

4. Bygg fullständiga hreflang-kluster

Varför: en envägs-alternativsignal är tvetydig; destinationen måste bekräfta relationen. Hreflang är HTML-attributet som identifierar språk- eller språk-regionalternativ, inte en omdirigeringsinstruktion och inte en ersättning för lokalisering. Vad: få varje indexerbar medlem att lista sig själv och varje annan giltig medlem, med en matchande retur-tagg från varje destination. Använd ISO 639-1 språkkoder där tillgängliga, följt av en valfri ISO 3166-1 alpha-2 regionkod, såsom en, en-GB eller pt-BR; använd aldrig ett land ensamt. Hur: generera taggar från klustermanifestet istället för att manuellt redigera mallar. Jämför de slutgiltiga absoluta URL:erna som set och validera status, kodsyntax, självhänvisning och ömsesidighet. Verktyg: manifestgenerator, sökrobot, renderad HTML, HTTP-klient och hreflang-validerare. Klar när: 100 % av indexerbara klustermedlemmar returnerar 200, listar identisk medlemsuppsättning, inkluderar sig själva, använder giltiga koder och har noll saknade eller motstridiga retur-taggar.

5. Justera kanoniska taggar, indexerbarhet och alternativsignaler

Varför: hreflang associerar alternativ, medan en tvärspråklig kanonisk tagg konsoliderar dem. Tillsammans motsäger dessa instruktioner varandra. En kanonisk URL identifierar den föredragna dubbletten; indexerbarhet innebär att en sida är kvalificerad för sökindex. Vad: ge varje lokaliserad sida en självkanonisk tagg och klustra endast indexerbara 200-URL:er. Hur: jämför deklarerad och Google-vald kanonisk tagg, robots-direktiv, status, slutdestination och alternativdestination. Ta bort noindex, omdirigerade, blockerade, soft-404 och icke-kanoniska URL:er tills de åtgärdats. Verktyg: sökrobot, headers, källa, robot-testare och URL-inspektion. Klar när: varje medlem är genomsökbar och indexerbar med en självkanonisk tagg, och inga alternativ omdirigerar, har fel eller kanoniserar någon annanstans.

6. Använd x-default endast för en verklig reservsida

Varför: användare som inte matchas behöver en stabil destination, men att uppfinna en standard kan skicka sökmotorer till en godtycklig kommersiell marknad. x-default är ett hreflang-värde för en språkväljare, global sida eller reservsida som inte är riktad till en specificerad lokalkod. Vad: lägg till exakt en x-default per kluster endast när en sådan reservsida verkligen finns. Hur: välj den globala väljaren eller neutrala reservsidan medvetet, inkludera den ömsesidigt i klustret och verifiera att den inte tvingar besökare vidare innan de kan välja. Verktyg: klustermanifest, renderad HTML, webbläsare med rena cookies och sökrobot. Klar när: varje tillämpligt kluster har en ömsesidig x-default med dokumenterat syfte; kluster utan giltig reservsida har ingen.

7. Gör lokalkodsupptäckt konsekvent

Varför: alternativtaggar ersätter inte genomsökningsvägar. En sida som bara finns i en tagg eller ett formulärelement kan förbli svår för människor och sökrobotar att upptäcka. En XML-webbplatskarta är en maskinläsbar lista över URL:er, medan genomsökbarhet innebär att sökrobotar kan nå och läsa dessa URL:er. Vad: exponera lokalkodsalternativ genom genomsökbara länkar och skicka in fullständiga kanoniska URL:er i webbplatskartor. Använd en implementeringsmetod för hreflang — HTML, HTTP-huvuden för icke-HTML-filer eller XML-webbplatskartor — om inte teamet kan bevisa att flera metoder förblir identiska. Hur: genomsök från varje marknads startsida, inspektera väljare som vanliga länkar, jämför webbplatskartor med manifestet och verifiera att navigering aldrig tappar bort den aktuella motsvarande sidan i onödan. Verktyg: sökrobot, webbplatskarttolk, webbläsare utan JavaScript och länkgraf. Klar när: varje prioriterad lokaliserad URL har minst en genomsökbar intern väg, varje webbplatskartepost är kanonisk och returnerar 200, och alla implementerade hreflang-källor deklarerar identiska kluster.

8. Håll valuta separat från lokalkodsinriktning

Varför: språk, destination och valuta är relaterade men inte utbytbara. Vad: visa korrekt valuta och villkor utan att använda valuta ensamt för att skapa eller växla en lokalkods-URL. Hur: definiera skatteinkludering, prislista eller växelkurs, avrundning, uppdateringstid och beteende för ej tillgänglig produkt. Håll ett stabilt genomsökbart prisstatus per marknad; behandla användarvald valuta som presentation om den inte representerar en separat marknad. Verktyg: katalog, prissättningstjänst, skatteregler, strukturerad data och köptest. Klar när: valuta är explicit, sida och kassa överensstämmer, skatte- och leveranskvalificerare visas, strukturerad data matchar och valutaväxling ändrar inte kanonisk eller hreflang-identitet.

9. Ersätt tvingade geolokaliseringsomdirigeringar med ett val

Varför: IP-plats och webbläsarspråk är ofullkomliga ledtrådar. Tvingade omdirigeringar kan fånga sökrobotar på en marknad, hindra resenärer och flerspråkiga användare från att välja, skapa omdirigeringsloopar och göra en direkt delad URL otillgänglig. Vad: håll varje lokalkods-URL direkt nåbar och erbjud en avvisningsbar marknadsrekommendation istället för att omdirigera enbart från IP eller Accept-Language. Hur: testa rena sessioner från flera platser, inloggade och utloggade tillstånd, sökrobot-användaragenter, inaktiverade cookies och ett explicit sparat val. Bevara den aktuella sidans motsvarande väg när en användare byter marknad; om ingen motsvarighet finns, förklara reservvalet. Verktyg: webbläsarplatstestning, HTTP-klient, edge/CDN-regler, serverloggar och automatiska omdirigeringstester. Klar när: en första begäran till varje lokaliserad URL returnerar sin avsedda 200-sida, robotar omdirigeras inte baserat på geografi, explicita val består, användare kan ångra dem och noll loopar eller flerstegskedjor förekommer.

10. Validera mallar och representativa URL:er före skalanvändning

Varför: en korrekt startsida bevisar bara en mall. Internationella defekter gömmer sig ofta i paginering, produktvarianter, saknade översättningar, fasetterade vägar och sidor som inte är tillgängliga på en marknad. Vad: testa varje unik mall och gränstillstånd före bulkdistribution. Hur: välj minst 10 URL:er per marknad, inklusive startsida, sidor med högst efterfrågan, varje mall, en otillgänglig produkt eller tjänst, en paginerad eller filtrerad väg där tillämpligt och en URL utan alternativ. Jämför källa, rendering, svar, kanonisk tagg, hreflang, navigering, innehållsspråk och konverteringsväg. Verktyg: staging-genomsökning, webbläsare, manifest-diff, HTTP-klient och testfallsblad. Klar när: varje unik mall och nödvändigt gränstillstånd är representerat, alla sample-URL:er klarar varje tillämplig regel och eventuella mallfel på mallnivå blockerar alla URL:er som genereras av den mallen.

11. Etablera mätning på marknadsnivå

Varför: aggregerad trafik kan öka medan en målmarknad tappar synlighet, och en ny mapp kan se frisk ut bara för att standardspråket dominerar den. Vad: skapa rapporteringsdimensioner för marknad, språkväg, katalog, land, enhet, konvertering och intäkt före lansering. Hur: verifiera analys-sidvisningar och händelser på staging, koppla varje nödvändig Search Console-tillgång eller domäntillgång, annotera lanseringstid och spara en baslinje för samma period och frågeuppsättning. Verktyg: analysfelsökare, Search Console, AmICited lands- och katalograpporter och lanseringsregistret. Klar när: testsessioner visas under avsedd marknad och väg, konverteringar behåller marknad och valuta, alla tillgångar är tillgängliga för ägaren och en daterad baslinje finns före distribution.

12. Kör live-verifiering och behåll ägarskap

Varför: staging kan inte bevisa DNS, CDN, produktionsomdirigeringar, slutgiltiga kanoniska taggar eller vad Google väljer efter upptäckt. Vad: upprepa kritiska kontroller omedelbart efter distribution och tilldela övervakning istället för att behandla lansering som slutförd. Hur: genomsök produktionssamplet, skicka in uppdaterade webbplatskartor, inspektera prioriterade URL:er, verifiera loggar och analys, schemalägg sedan kontroller efter upptäckt och efter första meningsfulla rapporteringsfönstret. Verktyg: produktionssökrobot, AmICited, Search Console, serverloggar och incidenthanterare. Klar när: produktion matchar det godkända manifestet, noll blockerande fel återstår, varje observation har en tidsstämpel och varje uppskjuten datakontroll har en ägare och ett datum istället för en öppen “övervaka”.

Verktyg i AmICited

AmICited tillhandahåller Search Console-bevis för upptäckt, lansering och övervakning. Det ersätter inte en granskare på marknaden eller en fullständig genomsökning av ömsesidiga taggar.

1. Öppna Länder och enheter på land- och enhetsrapporten . Undersök länder med visningar men svag position eller klickfrekvens innan du antar att efterfrågan saknas.

2. Använd Google Search-kataloger på katalograpporten för att jämföra lokalkodsmappar och granska svaga mallar.

3. Öppna Webbplatskartor och indexering på webbplatskarte- och indexeringsrapporten . Bekräfta nedladdning utan varningar eller fel, begär sedan indexering för prioriterade URL:er. Förfrågningar kan inte göra blockerade URL:er indexerbara.

4. Kontrollera representativa URL:er i URL-inspektion på URL-inspektionsrapporten . Jämför deklarerade och Google-valda kanoniska taggar. Dess täckningslista är ett exempel, inte en hreflang-granskning.

Beslutsregler

“Dåligt” är ett tillstånd som blockerar distribution eller utlöser korrigering, inte en känsla om översättningskvalitet.

Klickfrekvens- och positionsgap är diagnostiska, inte automatiska fel. Jämför likvärdiga sidor och perioder; inget universellt procenttal bevisar en lokaliseringsdefekt.

Leverans: det internationella lanseringspaketet

Överlämna en versionshanterad mapp eller biljettpaket med minst dessa innehåll:

01-url-model.md
- Beslut, alternativ som förkastats, väggrammatik, ägare, migration och återställning

02-market-page-matrix.csv
- marknad, språk, region, käll-URL, lokaliserad URL, intention, tillgänglighet, granskare

03-hreflang-manifest.csv
- URL, kod, självkanonisk, alternativ, x-default, status, indexerbarhet, resultat

04-localization-acceptance.csv
- URL, fält/resa, granskare, resultat, bevis, undantag

05-redirect-selector-spec.md
- rekommendationslogik, explicit val, beständighet, robotbeteende, beteende vid ingen motsvarighet

06-launch-verification.csv
- URL, distribuerad tid, genomsökningsresultat, webbplatskartestatus, inspektionsstatus, analysbevis, ägare

Beslut: GODKÄNT — DISTRIBUERA | UNDERKÄNT — HÅLL
Nästa granskningsdatum och namngiven ägare:

Stäm av manifestet mot produktion. Lagra undantag med anledning, risk, godkännare, utgångsdatum och korrigeringsägare. En ändrad URL-modell, mall, lokalkodsuppsättning, kanonisk tagg eller omdirigeringspolicy återöppnar berörda kontroller.

Vad går fel

• Varje källsida översätts automatiskt. Sidor utan lokal efterfrågan, otillgängliga produkter och ostödda påståenden publiceras eftersom översättning misstogs för marknadsurval.
• Standardspråket blir kanoniskt överallt. Sökmotorer får konsoliderings- och alternativinstruktioner samtidigt; lokaliserade URL:er försvinner eller fel URL väljs.
• Endast källsidan listar alternativ. Saknade retur-taggar gör klustret ofullständigt även om en mall verkar korrekt.
• Landskoder används som språk. Värden som UK eller BR uttrycker inte ett språk-regionpar; giltiga exempel är en-GB och pt-BR.
• x-default pekar på den största marknaden. En kommersiell landssida märks som neutral reserv och får användare den inte kan betjäna korrekt.
• Väljaren är endast JavaScript. Användare ser en rullgardinsmeny, men sökrobotar har inga vanliga länkar för att upptäcka alternativ.
• IP-plats tvingar vägen. Sökrobotar och resenärer kan inte behålla en direkt begärd URL, cacheminnen varierar beroende på plats och omdirigeringsloopar uppstår mellan edge- och applikationsregler.
• Valuta skapar duplicerade lokalkods-URL:er. Parametrar eller sökvägar multipliceras medan innehåll, kanoniska taggar och strukturerade priser inte överensstämmer.
• Startsidan godkänns och skalanvändning börjar. Produkt-, kategori-, paginerings- och mallar utan motsvarighet genererar olika tagguppsättningar över tusentals URL:er.
• Rapportering startar efter lansering. Ingen baslinje eller anteckning finns, så team kan inte separera implementationseffekter från säsongsvariationer, varumärkesefterfrågan eller orelaterade distributioner.

Nästa fas

Denna checklista överlämnar sitt lanseringspaket till checklistan för kvalitetssäkring före publicering . Kvalitetssäkring behöver URL-modellen, produktionskandidaten, manifestet, lokaliseringsgodkännanden, webbplatskarte- och omdirigeringsändringar, testsviten, lanseringsmyndigheten och undantag. Den verifierar dessa dokument före distribution.

Efter lansering behåller den internationella SEO-ägaren manifestet. Nya sidor, borttagna produkter, språktillägg, vägmigreringar och kanoniska förändringar är klusterförändringar, inte isolerade sidredigeringar. Omvalidera berörda kluster, uppdatera webbplatskartor, inspektera prioriterade URL:er och annotera rapportering varje gång.

FAQ

Vanliga frågor

Gör första internationella lanseringen mätbar

Använd land- och enhetsrapporten för att fånga marknadens baslinje, släpp sedan endast när URL-modellen, lokaliseringsprotokollet, klustermanifestet, omdirigeringar, webbplatskarta och representativt produktionssamplet alla är godkända. Akademi-layoutens avslutande CTA ger nästa väg in i AmICited.