ResurserSå här implementerar du hreflang-taggar för flerspråkig WordPress

Så här implementerar du hreflang-taggar för flerspråkig WordPress

SimplePoTranslate Team31 maj 2026

Du har översatt hela din WordPress-webbplats till sex språk. .po-filerna är rena, .mo-filerna är kompilerade, varje sträng återges perfekt på franska, tyska och japanska. Ändå, veckor efter lanseringen, kontrollerar du Google Search Console och upptäcker något förbryllande: din franska sida rankar för tyska sökningar, din spanska-mexikanska sida serveras till sökare i Spanien, och två av dina språkversioner kannibaliserar tyst varandra i rankningarna. Innehållet är bra. Problemet är att Google inte har någon aning om vilken version som tillhör vilken målgrupp.

Det är precis vad hreflang WordPress-taggar är utformade för att åtgärda. Hreflang är signalen som talar om för sökmotorer vilken språk- och regionversion av en sida som ska visas för vilken användare. Om du gör fel lider du av utspädning av dubblettinnehåll, resultat på fel språk och bortkastad genomsökningsbudget. Om du gör rätt når varje översatt sida den målgrupp den skrevs för. Denna guide täcker syntaxen, skillnaden mellan språk- och språk-regionskoder, den obligatoriska x-default, retur-tagg-reciprocitet och tre praktiska sätt att implementera det i WordPress.

Vad hreflang faktiskt gör

Hreflang översätter ingenting. Det är en relationskarta. När du har samma sida på flera språk talar hreflang-annotationer om för Google "denna URL är den engelska versionen, denna är den tyska versionen, denna är för spansktalande i Mexiko." Google använder den kartan för att visa rätt version i sökresultaten baserat på användarens språkinställningar och plats.

Annotationen finns i <head> på din HTML som en uppsättning <link>-element. Varje element namnger en målsida och det språk (och eventuellt region) den betjänar. Här är en korrekt uppsättning hreflang-taggar för en sida som finns tillgänglig på amerikansk engelska, brittisk engelska och mexikansk spanska, med en 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/" />

Varje sida i uppsättningen bör mata ut samma block, som listar varje alternativ inklusive sig själv. Den sista punkten ställer till det för de flesta, och vi kommer att återkomma till den.

Varför detta är viktigt för SEO

Utan hreflang behandlar Google dina översatta sidor som nästan-duplikat som konkurrerar om samma sökord. Resultatet är utspädning: rankningssignaler delas upp mellan versioner istället för att konsolideras. Med korrekt hreflang ärver varje version auktoriteten från uppsättningen som helhet och visas för rätt sökare. Detta är en av de mest effektiva SEO-åtgärderna en flerspråkig webbplats kan göra, och det kompletterar snarare än ersätter den faktiska innehållsöversättningen i dina .po-filer. Vi behandlar innehållssidan i detalj i vår guide om hur översättning av PO-filer påverkar Google-rankningar.

Språk- kontra språk-regionskoder

Vilken ska du använda, en eller en-GB? Använd den enklaste koden som stämmer. Om ditt engelska innehåll är generiskt och du inte upprätthåller separata brittiska och amerikanska versioner, använd bara en. Lägg bara till en region-undertagg när du verkligen serverar olika innehåll till olika länder.

Hreflang-värden följer formatet language eller language-region. Språkdelen är en ISO 639-1-kod (en, es, de, pt). Den valfria regionen är en ISO 3166-1 Alpha 2-landskod (US, GB, MX, BR). Alltså:

en riktar sig till alla engelsktalande oavsett land.
en-GB riktar sig till engelsktalande i Storbritannien.
es riktar sig till alla spansktalande.
es-MX riktar sig specifikt till spansktalande i Mexiko.

En viktig detalj: region-undertaggen är ett land, inte en språkvariant. es-MX betyder inte "mexikansk spansk dialekt", det betyder "spanska, visas för användare i Mexiko." Google visar det fortfarande baserat på användarens plats. Om du upprätthåller regionala dialekter i dina översättningar är regionkoden hur du dirigerar dem. Vi fördjupar oss i den språkliga sidan av detta i vår guide om regionala spanska och portugisiska varianter.

Ett vanligt felaktigt exempel

Här är ett felaktigt hreflang-block som vi ser hela tiden:

<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 fel. en-uk är ogiltig eftersom landskoden för Storbritannien är GB, inte UK. sp är ingen språkkod överhuvudtaget; spanska är es. Och pt-PT_BR blandar två regioner med ett understreck som inte har någon betydelse i hreflang. Sökmotorer ignorerar tyst felaktigt formulerade värden, så du får inget fel och ingen nytta, bara timmar av felsökning där du undrar varför inget ändrades.

Observera att hreflang använder ett bindestreck (en-GB), medan WordPress-lokaliseringsfiler använder ett understreck (en_GB). Kopiera inte dina .po-filnamnskoder direkt till hreflang-taggar.

x-default och retur-tagg-reciprocitet

Två regler orsakar fler tysta hreflang-fel än något annat: den saknade x-default och bruten reciprocitet.

Värdet x-default talar om för Google vilken sida som ska visas när inget annat språk matchar användaren. Det är din fallback, vanligtvis din språkvalssida eller din startsida för primärmarknaden. Det är inte strikt obligatoriskt enligt specifikationen, men i praktiken bör du alltid inkludera det. Utan det får en portugisisktalande besökare, för vilken du inte har någon portugisisk version, en slumpmässig sida istället för en avsiktlig standard.

Retur-tagg-reciprocitet är icke-förhandlingsbar. Varje sida i en hreflang-uppsättning måste peka tillbaka till varje annan sida, inklusive sig själv. Om din engelska sida listar tyska som ett alternativ, måste din tyska sida lista engelska som ett alternativ. Om den tyska sidan utelämnar returreferensen, misstror Google hela förhållandet och ignorerar annotationerna.

<!-- 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/" />

Självreferensen (de som pekar till den tyska sidan när den tyska sidan visas) är obligatorisk, inte valfri. En uppsättning med fem språkversioner innebär att var och en av de fem sidorna matar ut alla fem <link>-taggar plus x-default.

Tre sätt att implementera hreflang i WordPress

Du har tre praktiska alternativ, från fullständig manuell kontroll till helt automatiserat.

Metod 1: Manuell via wp_head

För en liten statisk uppsättning sidor kan du injicera hreflang-taggar direkt via wp_head-aktionen i ditt 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 )
        );
    }
} );

Detta ger dig exakt kontroll men skalar inte. Att upprätthålla reciprocitet för hand över hundratals inlägg är en underhållsfälla.

Metod 2: Ett flerspråkigt plugin

Om du använder Polylang, WPML eller TranslatePress genereras hreflang automatiskt baserat på dina översättningsrelationer. Detta är det rätta svaret för de flesta webbplatser eftersom pluginet redan vet vilket inlägg som är översättningen av vilket, så reciprocitet och x-default hanteras åt dig. Kostnaden är den körningskostnad dessa plugins lägger till, vilket är den avvägning vi undersöker i vår jämförelse av manuella kontra AI-översättningsmetoder.

Metod 3: XML-webbplatskarta med xhtml:link

Istället för att placera hreflang i varje sidas <head>, kan du deklarera relationerna i din XML-webbplatskarta med hjälp av xhtml:link-namnrymden. Varje <url>-post listar alla dess språkalternativ:

<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>

Detta håller din sid-HTML slimmad och centraliserar språkmappningen i en enda genomsökbar fil, som Google gladeligen läser. De flesta SEO-plugins kan generera detta automatiskt.

hreflang kompletterar översättning, det ersätter den inte

Här är poängen alla missar: hreflang är värdelöst om de underliggande sidorna inte faktiskt är översatta. Taggen talar om för Google "detta är den tyska versionen", men om den tyska URL:en fortfarande visar engelska plugin-strängar, oöversatta kassamärkningar eller halvfärdiga .po-filer, har du helt enkelt sagt till Google att servera trasigt innehåll till tyska användare med fullt förtroende.

Verklig flerspråkig SEO består av två lager. Innehållslagret är dina översatta .po-, .pot-, .json- och .xliff-filer som driver varje tema- och plugin-sträng till målspråket. Signallagret är hreflang som dirigerar varje färdig version till dess publik. Båda måste vara solida. En orörd hreflang-uppsättning ovanpå en 40-procentigt översatt webbplats garanterar bara en sämre upplevelse snabbare.

Det är här det är viktigast att hålla översättningslagret rent. När du översätter dina gränssnittsfiler måste platshållare som %s, %1$s och {name} överleva intakta, annars återges din "översatta" tyska sida med bokstavliga %s-token som ser trasiga ut för både användare och sökmotorer. En gettext-medveten översättningspipeline med Syntaxlåsning skyddar dessa token automatiskt, så att varje alternativ sida du pekar hreflang mot är genuint produktionsredo. Eftersom den körs i molnet med Smart Batching kan du skjuta en hel webbplats med flera språk genom den utan att installera översättningsplugins som tynger ner körningen som serverar just dessa sidor.

Få innehållet rätt först, låt sedan hreflang göra sitt jobb. De två tillsammans konsoliderar rankningssignaler, eliminerar resultat på fel språk och placerar varje översatt sida framför de personer som kan läsa den.

Redo att fixa sökresultat på fel språk vid källan? Prova SimplePoTranslate gratis — inget kreditkort krävs. Översätt dina .po-, .pot- och .json-filer på gratistjänsten, och peka sedan dina hreflang-taggar mot sidor som faktiskt är redo för varje marknad.

Relaterade Ämnen

#WordPress #Lokalisering #Prestanda

Dela den här artikeln

Facebook X (Twitter)LinkedIn Reddit WhatsApp Email

På denna sida

Översätta en stor fil?

Undvik att förstöra din webbplats med syntaxfel. Använd vår AI för att hantera variabler och HTML säkert.

Börja Översätta Gratis

Inget kreditkort krävs