Slik konfigurerer du Hreflang riktig på WordPress (og feilene som ødelegger det)

Kort svar: for å sette opp hreflang riktig på WordPress, trenger alle språkversjoner av en side et komplett sett med hreflang-tagger som:

1. peke på seg selv,
2. peker til alle alternative versjoner
3. peker tilbake på hverandre, og
4. inkludere en x-standard reserve, alle bruker gyldige språkkoder og absolutte URL-er.

Hvis du tar feil av én av disse, ignorerer søkemotorene hele settet. Selv om det er en krevende prosess, er den reneste måten å gjøre det på med en plugin som genererer taggene automatisk. Likevel er det verdt å kjenne reglene slik at du kan sjekke resultatet selv.

La oss gjøre én ting klart: å legge til hreflang-tagger og å legge dem til riktig er to forskjellige jobber. WordPress legger ikke til hreflang alene, så de fleste bruker en plugin eller en snippet , se tagger vises i kildekoden, og anta at de er ferdige. Noe som, hvis du har brukt en godt bygget plugin, burde være greit.

Men hvis du plutselig ser at trafikken fra en oversatt versjon begynner å bli flat, og feil språk vises i søkeresultatene, er det gode indikatorer på at du bør dobbeltsjekke hreflang-implementeringen din.

Vanligvis er merkelappene der; det er bare en god sjanse for at de er ødelagt på en av mange forutsigbare måter – men det er ingenting du ikke kan fikse selv.

Denne veiledningen dekker hva «riktig» egentlig betyr, feilene folk flest gjør, og hvordan du bekrefter oppsettet ditt. Hvis du vil ha en fullstendig gjennomgang av alle metodene for å legge til hreflang i WordPress (plugins, SEO-verktøy og manuell kode), dekker vår komplette veiledning til hreflang på WordPress den siden i dybden.

Hva «korrekt» Hreflang egentlig betyr

Hreflang er et HTML-attributt som forteller søkemotorer hvilket språk og, eventuelt, hvilken region en side er ment for, slik at de kan vise riktig versjon til riktig person (en-US for en amerikansk besøkende, en-GB (for en britisk). Google behandler et sett med hreflang-tagger som én enkelt klynge, og en klynge er bare gyldig hvis alle disse reglene gjelder samtidig.

1. Hver side refererer til seg selv

Hver språkversjon må inneholde en hreflang-tag som peker til sin egen URL, sammen med tagger for alle de andre versjonene. Den engelske siden viser engelsk (i seg selv), fransk, tysk og x-standard. Det er ikke mulig å inkludere selvreferansen; ellers er klyngen ufullstendig, og du vil umiddelbart støte på hreflang-feil.

2. Taggene er gjensidige (returtagger)

Hvis den engelske siden din peker til den franske versjonen, må den franske versjonen peke tilbake til den engelske. Disse kalles returtagger, og de må gå begge veier på hver side i klyngen. Når en returtagg mangler, kan Google droppe annoteringen helt i stedet for å gjette.

3. Det finnes en x-standard

De x-standard Taggen er reservekoden for besøkende hvis språk eller region du ikke eksplisitt målretter deg mot. Den peker vanligvis til hovedsiden din eller en språkvelgermeny. Alle modeller og SEO-verktøy flagger denne koden, og med god grunn: uten den har søkemotorer ingen standard å falle tilbake på.

4. Språk- og regionkodene er gyldige

Språkkoder følger ISO 639-1-standarden (en, fr, de, es, zh). Den valgfrie regionkoden følger ISO 3166-1 Alpha-2 (US, GB, FR), og de to kombineres som språk-REGION, som en-GB. En regionkode alene er ikke gyldig; språket kommer alltid først.

Vær forsiktig med å anta språkkoder, og sjekk alltid listen på forhånd. Hvis du for eksempel vil angi siden din som britisk engelsk, er koden en-GB heller enn en-UKHele koden er ugyldig; Storbritannia er språkkoden for ukrainsk (og landskoden er UA), så formatet til denne koden er i hovedsak språk-språk snarere enn språk-region.

5. URL-ene er absolutte

Hreflang-URL-er trenger hele adressen inkludert protokollen (https://example.com/fr/page/), ikke en relativ sti som /fr/page/. Relative URL-er er en av de vanligste stille feilene.

6. Den kanoniske tag-serien

Hver versjons kanoniske tagg skal peke til seg selv, ikke til originalspråket. En kanonisk tagg som peker den franske siden tilbake til den engelske siden, forteller Google at den skal ignorere den franske versjonen, noe som kansellerer hreflang-arbeidet ditt og gir feil siderangering for et søkeord på feil språk. Det er derfor selvrefererende kanoniske tagger og selvrefererende hreflang går hånd i hånd.

Et riktig eksempel

Et gyldig sett ser slik ut i <head> av en engelsk side som også finnes på fransk, med en x-standard reserve:

<link rel="alternate" hreflang="en" href="https://example.com/page/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

Den franske versjonen kl. https://example.com/fr/page/ bærer de samme 3 taggene, som peker til de samme URL-ene. Denne symmetrien er det som gjør klyngen gyldig. Velg ett sted å plassere taggene (den <head>, et XML-nettstedskart eller HTTP-overskrifter) og forbli konsistente. På WordPress, <head> er det vanligste valget.

Feil som ødelegger din hreflang

De fleste ødelagte hreflang-oppsett feiler på en av disse, selv om taggene ser fine ut i kildekoden hele tiden.

• Manglende returkoder. Side A peker til B, men B peker ikke tilbake. Mangelen på resiprokkoder er den vanligste grunnen til at Google ignorerer et ellers korrekt oppsett.
• Ingen selvreferanse. En side viser alternativene sine, men glemmer å inkludere seg selv i settet. Litt som å telle hvor mange dere er i gruppen for en middagsreservasjon og glemme å telle dere selv.
• Relative URL-er. /fr/side/ i stedet for https://example.com/fr/page/. Selv om det ser rimelig ut, fungerer det rett og slett ikke.
• Ugyldige koder. en-UK i stedet for riktig en-GB, understrek i stedet for bindestreker (en_US), eller koder som ikke finnes. Dobbeltsjekk alltid kodene dine; det er den enkleste måten å unngå feil.
• Kanoniske konflikter. En oversatt sides kanoniske innhold peker mot originalspråket, noe som forteller søkemotorer at oversettelsen ikke er siden som skal indekseres.
• To metoder samtidig. En flerspråklig plugin sender ut hreflang, og en separat SEO-plugin eller manual snippet sender ut et andre, motstridende sett. Du vil ende opp med dupliserte eller uoverensstemmelser i taggene som forvirrer robotsøkeprogrammene. Bruk bare én metode.
• Ingen x-standard. Har ingen reserve for språk og regioner som ikke matcher.

Hvis du legger til hreflang manuelt på flere sider, skaleres hver av disse med sideantallet, og det er derfor manuell oppsett raskt blir skjørt.

Slik bekrefter du at oppsettet ditt er riktig

Bekreft at taggene er gyldige før du stoler på dem, ikke etter at rangeringene har endret seg.

En kjapp merknad først: Google pensjonerte den dedikerte rapporten om internasjonal målretting i Search Console tilbake i 2022 , så det gamle rådet om å «sjekke hreflang-rapporten i Search Console» gjelder ikke lenger. Google støtter og leser fortsatt hreflang fullt ut; rapporteringen er nettopp flyttet et annet sted. Verktøyene som fungerer nå:

• URL-inspeksjon Google Search Console . Sjekk at alternative URL-er returnerer statusen 200, blir indeksert og ikke overstyres av en uventet kanonisk URL.
• Screaming Frog SEO Spider. Den trekker ut hreflang-klynger, følger alternative URL-er og rapporterer manglende returkoder, ugyldige koder og inkonsekvenser på tvers av hele nettstedet. Den raskeste måten å revidere i stor skala.
• En dedikert hreflang-validator (som vår). Flere gratisverktøy sjekker en enkelt URLs klynge for gjensidighet og kodegyldighet, nyttig for stikkprøvekontroller.
• Ahrefs- eller Sitebulb-nettstedsrevisjoner. Begge inkluderer internasjonale kontroller som flagger hreflang-feil som en del av en bredere teknisk gjennomgang.

Kjør en sjekk etter enhver stor publisering eller malendring, siden det er da klynger har en tendens til å bryte sammen.

Den raskeste måten å få det riktig på: La en plugin håndtere det

Hver regel ovenfor kan gjøres for hånd, og på et lite nettsted er det helt rimelig. Problemet er at det er lett å få 90 % riktig med hreflang og fortsatt få det til å mislykkes, fordi reglene er gjensidig avhengige og komplekse å holde oversikt over. Én manglende returtag ødelegger en ellers perfekt klynge, og å finne synderen betyr å møysommelig sile gjennom koden din – og hvem vil bruke sin dyrebare tid på å gjøre det?

Derfor bruker de fleste WordPress-nettsteder en flerspråklig plugin som genererer hreflang automatisk. Med Weglot , taggene opprettes og holdes synkronisert etter hvert som du legger til språk og publiserer innhold: selvrefererende tagger, gjensidige returtagger, x-standard, gyldige koder og absolutte URL-er, i henhold til de flerspråklige SEO-praksisene som Google har angitt. På den måten vedlikeholder du ikke en klynge på tvers av hver side manuelt; plugin-modulen gjør det og oppdaterer det når innholdet ditt endres.

Uansett hvilken vei du velger, endres ikke reglene. En plugin håndhever dem bare for deg, slik at en manglende returtag aldri koster deg et marked.

Å sette opp hreflang riktig avhenger av en håndfull regler som brukes konsekvent på tvers av hver side, og feilene er forutsigbare når du vet hva du skal se etter. Hvis du heller ikke vil overvåke disse klyngene manuelt etter hvert som nettstedet ditt vokser, Weglot genererer og synkroniserer dem automatisk for deg. Start din 14-dagers gratis prøveperiode , og få et flerspråklig, søkeklart nettsted på få minutter.