Sådan implementerer du hreflang-tags til et flersproget WordPress
Du har oversat hele din WordPress-side til seks sprog. .po-filerne er rene, .mo-filerne er kompileret, hver streng gengives perfekt på fransk, tysk og japansk. Alligevel, uger efter lanceringen, tjekker du Google Search Console og finder noget forvirrende: din franske side rangerer for tyske søgninger, din spansk-mexicanske side vises til søgende i Spanien, og to af dine sprogversioner kannibaliserer stille og roligt hinanden i placeringerne. Indholdet er fint. Problemet er, at Google ikke aner, hvilken version der tilhører hvilket publikum.
Dette er præcis, hvad hreflang WordPress-tags er designet til at løse. Hreflang er signalet, der fortæller søgemaskiner, hvilken sprog- og regional version af en side der skal vises til hvilken bruger. Gør du det forkert, lider du under udvanding af duplikeret indhold, resultater på forkert sprog og spildt crawl-budget. Gør du det rigtigt, når hver oversat side ud til det publikum, den blev skrevet til. Denne guide dækker syntaksen, forskellen mellem sprog- og sprog-regionskoder, den obligatoriske x-default, reciprocitet for retur-tags og tre praktiske måder at implementere det på i WordPress.
Hvad hreflang faktisk gør
Hreflang oversætter intet. Det er et relationskort. Når du har den samme side på flere sprog, fortæller hreflang-annotationer Google "denne URL er den engelske version, denne er den tyske version, denne er for spansktalende i Mexico." Google bruger det kort til at vise den korrekte version i søgeresultater baseret på brugerens sprogindstillinger og placering.
Annotationen findes i din HTML's <head> som et sæt <link>-elementer. Hvert element angiver en målside og det sprog (og eventuelt region), den betjener. Her er et korrekt sæt hreflang-tags for en side tilgængelig på amerikansk engelsk, britisk engelsk og mexicansk spansk, med et standard fallback:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Hver side i sættet bør udskrive den samme blok, der angiver alle alternativer inklusive sig selv. Dette sidste punkt forvirrer de fleste, og vi vender tilbage til det.
Hvorfor dette er vigtigt for SEO
Uden hreflang behandler Google dine oversatte sider som næsten-duplikater, der konkurrerer om de samme søgeord. Resultatet er udvanding: rangeringssignaler opdeles på tværs af versioner i stedet for at blive konsolideret. Med korrekt hreflang arver hver version autoriteten fra hele sættet og vises til de rigtige søgende. Dette er et af de mest indflydelsesrige SEO-træk, et flersproget websted kan foretage, og det supplerer snarere end erstatter den faktiske indholdsoversættelse i dine .po-filer. Vi dækker indholdssiden i dybden i vores guide til hvordan oversættelse af PO-filer påvirker Google-placeringer.
Sprog- vs. Sprog-regionskoder
Hvilken skal du bruge, en eller en-GB? Brug den enkleste kode, der er sand. Hvis dit engelske indhold er generisk, og du ikke vedligeholder separate britiske og amerikanske versioner, skal du kun bruge en. Tilføj kun en regions-subtag, når du reelt serverer forskelligt indhold til forskellige lande.
Hreflang-værdier følger formatet language eller language-region. Sprogedelen er en ISO 639-1-kode (en, es, de, pt). Den valgfrie region er en ISO 3166-1 Alpha 2 landekode (US, GB, MX, BR). Således:
enmålretter alle engelsktalende uanset land.en-GBmålretter engelsktalende i Storbritannien.esmålretter alle spansktalende.es-MXmålretter specifikt spansktalende i Mexico.
En kritisk detalje: regions-subtag'en er et land, ikke en sprogvariant. es-MX betyder ikke "mexicansk spansk dialekt", det betyder "spansk, vist til brugere i Mexico." Google viser den stadig baseret på brugerens placering. Hvis du opretholder regionale dialekter i dine oversættelser, er regionskoden den måde, du dirigerer dem på. Vi dykker ned i den sproglige side af dette i vores guide til regionale spanske og portugisiske varianter.
Et almindeligt forkert eksempel
Her er en ødelagt hreflang-blok, vi konstant ser:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Tre fejl. en-uk er ugyldig, fordi landekoden for Storbritannien er GB, ikke UK. sp er slet ikke en sprogkode; spansk er es. Og pt-PT_BR blander to regioner med en understregningstegn, der ingen betydning har i hreflang. Søgemaskiner ignorerer stiltiende fejlformede værdier, så du får ingen fejl og ingen fordel, kun timer med fejlfinding, hvor du undrer dig over, hvorfor intet ændrede sig.
Bemærk, at hreflang bruger en bindestreg (en-GB), mens WordPress-lokalefiler bruger en understregning (en_GB). Kopier ikke dine .po-filnavnskoder direkte ind i hreflang-tags.
x-default og return-tag reciprocitet
To regler forårsager flere stiltiende hreflang-fejl end noget andet: den manglende x-default og brudt reciprocitet.
x-default-værdien fortæller Google, hvilken side der skal vises, når ingen andre sprog matcher brugeren. Det er din fallback, typisk din sprogvælger eller din primære markedsforside. Det er ikke strengt obligatorisk ifølge specifikationen, men i praksis bør du altid inkludere den. Uden den får en portugisisk-talende besøgende, for hvem du ingen portugisisk version har, et tilfældigt valg i stedet for en bevidst standard.
Return-tag reciprocitet er ikke til forhandling. Hver side i et hreflang-sæt skal pege tilbage til alle andre sider, inklusive sig selv. Hvis din engelske side angiver tysk som et alternativ, skal din tyske side angive engelsk som et alternativ. Hvis den tyske side udelader returreferencen, mistror Google hele relationen og ignorerer annotationerne.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
Selvreferencen (de pegende på den tyske side, mens den tyske side vises) er påkrævet, ikke valgfri. Et sæt af fem sprogversioner betyder, at hver af de fem sider udskriver alle fem <link>-tags plus x-default.
Tre måder at implementere hreflang i WordPress
Du har tre praktiske muligheder, lige fra fuld manuel kontrol til fuldt automatiseret.
Metode 1: Manuel via wp_head
For et lille statisk sæt sider kan du injicere hreflang-tags direkte via wp_head-handlingen i dit temas functions.php:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Dette giver dig præcis kontrol, men skalerer ikke. At opretholde reciprocitet manuelt på tværs af hundredvis af indlæg er en vedligeholdelsesfælde.
Metode 2: Et flersproget plugin
Hvis du bruger Polylang, WPML eller TranslatePress, genereres hreflang automatisk baseret på dine oversættelsesrelationer. Dette er den rigtige løsning for de fleste websteder, da plugin'et allerede ved, hvilket indlæg der er oversættelsen af hvilket, så reciprocitet og x-default håndteres for dig. Omkostningen er den runtime-overhead, disse plugins tilføjer, hvilket er det kompromis, vi undersøger i vores sammenligning af manuelle versus AI-oversættelsesmetoder.
Metode 3: XML Sitemap med xhtml:link
I stedet for at placere hreflang i hver sides <head>, kan du erklære relationerne i dit XML sitemap ved hjælp af xhtml:link-navnerummet. Hver <url>-post lister alle dens sprogalternativer:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Dette holder din sides HTML slank og centraliserer sprogkortet i én crawlbar fil, som Google gladeligt læser. De fleste SEO-plugins kan generere dette automatisk.
hreflang supplerer oversættelse, det erstatter den ikke
Her er det punkt, alle overser: hreflang er værdiløst, hvis de underliggende sider faktisk ikke er oversat. Tag'et fortæller Google "dette er den tyske version," men hvis den tyske URL stadig viser engelske plugin-strenge, uoversatte kasselabels eller halvfærdige .po-filer, har du simpelthen bedt Google om at levere ødelagt indhold til tyske brugere med fuld tillid.
Ægte flersproget SEO består af to lag. Indholdslaget er dine oversatte .po-, .pot-, .json- og .xliff-filer, der driver hver tema- og plugin-streng ind i målsproget. Signallaget er hreflang, der dirigerer hver færdige version til sit publikum. Begge skal være solide. Et uberørt hreflang-sæt ovenpå et 40-procent-oversat websted garanterer blot en dårligere oplevelse hurtigere.
Det er her, det betyder mest at holde oversættelseslaget rent. Når du oversætter dine interfacefiler, skal pladsholdere som %s, %1$s og {name} overleve intakte, ellers vil din "oversatte" tyske side gengives med bogstavelige %s-tokens, der ser ødelagte ud for både brugere og søgemaskiner. En gettext-bevidst oversættelsespipeline med Syntax Locking beskytter automatisk disse tokens, så hver alternativ side, du peger hreflang på, er ægte produktionsklar. Fordi den kører i skyen med Smart Batching, kan du skubbe et helt multi-lokalt websted igennem den uden at installere oversættelsesplugins, der forøger den runtime, der betjener netop disse sider.
Få indholdet rigtigt først, og lad derefter hreflang gøre sit arbejde. De to sammen er det, der konsoliderer rangeringssignaler, eliminerer resultater på forkert sprog og placerer hver oversat side foran de mennesker, der kan læse den.
Klar til at rette søgeresultater på forkert sprog ved kilden? Prøv SimplePoTranslate gratis — intet kreditkort påkrævet. Oversæt dine
.po-,.pot- og.json-filer på gratisniveauet, og peg derefter dine hreflang-tags på sider, der faktisk er klar til hvert marked.