Hoe hreflang-tags te implementeren voor meertalig WordPress
Je hebt je hele WordPress-site in zes talen vertaald. De .po bestanden zijn schoon, de .mo bestanden zijn gecompileerd, elke string wordt perfect weergegeven in het Frans, Duits en Japans. Toch, weken na de lancering, controleer je Google Search Console en ontdek je iets verbijsterends: je Franse pagina rankt voor Duitse zoekopdrachten, je Spaans-Mexico pagina wordt getoond aan zoekers in Spanje, en twee van je taalversies kannibaliseren elkaar stilletjes in de rankings. De inhoud is prima. Het probleem is dat Google geen idee heeft welke versie bij welk publiek hoort.
Dit is precies wat hreflang WordPress-tags moeten oplossen. Hreflang is het signaal dat zoekmachines vertelt welke taal- en regionale versie van een pagina aan welke gebruiker moet worden getoond. Doe je het verkeerd, dan lijdt je onder verwatering door dubbele content, resultaten in de verkeerde taal en verspild crawlbudget. Doe je het goed, dan bereikt elke vertaalde pagina het publiek waarvoor het geschreven is. Deze gids behandelt de syntaxis, het verschil tussen taal- en taal-regio codes, de verplichte x-default, de wederkerigheid van return-tags, en drie praktische manieren om dit in WordPress te implementeren.
Wat hreflang precies doet
Hreflang vertaalt niets. Het is een relatiekaart. Wanneer je dezelfde pagina in meerdere talen hebt, vertellen hreflang-annotaties aan Google "deze URL is de Engelse versie, deze is de Duitse versie, deze is voor Spaanstaligen in Mexico." Google gebruikt die kaart om de juiste versie in de zoekresultaten weer te geven op basis van de taalinstellingen en locatie van de gebruiker.
De annotatie bevindt zich in de <head> van je HTML als een set <link>-elementen. Elk element benoemt een doelpuntpagina en de taal (en optioneel regio) die het bedient. Hier is een correcte set hreflang-tags voor een pagina die beschikbaar is in Amerikaans Engels, Brits Engels en Mexicaans Spaans, met een standaard terugvaloptie:
<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/" />
Elke pagina in de set moet hetzelfde blok uitvoeren, waarbij elke alternatieve pagina, inclusief zichzelf, wordt vermeld. Dat laatste punt struikelt de meeste mensen over, en daar komen we op terug.
Waarom dit belangrijk is voor SEO
Zonder hreflang behandelt Google je vertaalde pagina's als bijna-duplicaten die strijden om dezelfde zoekwoorden. Het resultaat is verwatering: rankingsignalen worden over versies verdeeld in plaats van geconsolideerd. Met de juiste hreflang erft elke versie de autoriteit van de hele set en verschijnt deze aan de juiste zoekers. Dit is een van de meest effectieve SEO-bewegingen die een meertalige site kan maken, en het vult de eigenlijke inhoudsvertaling in je .po bestanden aan in plaats van deze te vervangen. We behandelen de inhoudskant uitgebreid in onze gids over hoe het vertalen van PO-bestanden de Google-rankings beïnvloedt.
Taal- versus taal-regio codes
Welke moet je gebruiken, en of en-GB? Gebruik de eenvoudigste code die waar is. Als je Engelse inhoud generiek is en je geen aparte Britse en Amerikaanse versies onderhoudt, gebruik dan alleen en. Voeg alleen een regio-subtag toe als je daadwerkelijk verschillende inhoud aan verschillende landen aanbiedt.
Hreflang-waarden volgen het formaat language of language-region. Het taalgedeelte is een ISO 639-1 code (en, es, de, pt). De optionele regio is een ISO 3166-1 Alpha 2 landcode (US, GB, MX, BR). Dus:
enricht zich op alle Engelstaligen, ongeacht het land.en-GBricht zich op Engelstaligen in het Verenigd Koninkrijk.esricht zich op alle Spaanstaligen.es-MXricht zich specifiek op Spaanstaligen in Mexico.
Een cruciaal detail: de regio-subtag is een land, geen taalvariant. es-MX betekent niet "Mexicaans Spaans dialect," het betekent "Spaans, getoond aan gebruikers in Mexico." Google serveert het nog steeds op basis van de locatie van de gebruiker. Als je regionale dialecten in je vertalingen onderhoudt, is de regiocode hoe je ze routeert. We duiken dieper in de taalkundige kant hiervan in onze gids over regionale Spaanse en Portugese varianten.
Een veelvoorkomend verkeerd voorbeeld
Hier is een gebroken hreflang-blok dat we constant zien:
<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/" />
Drie fouten. en-uk is ongeldig omdat de landcode voor het Verenigd Koninkrijk GB is, niet UK. sp is helemaal geen taalcode; Spaans is es. En pt-PT_BR mengt twee regio's met een underscore die geen betekenis heeft in hreflang. Zoekmachines negeren stilzwijgend verkeerd opgemaakte waarden, dus je krijgt geen foutmelding en geen voordeel, alleen urenlang debuggen terwijl je je afvraagt waarom er niets veranderd is.
Merk op dat hreflang een koppelteken gebruikt (en-GB), terwijl WordPress locale bestanden een underscore gebruiken (en_GB). Kopieer je .po bestandsnaamcodes niet direct naar hreflang-tags.
De x-default en wederkerigheid van return-tags
Twee regels veroorzaken meer stille hreflang-fouten dan iets anders: de ontbrekende x-default en gebroken wederkerigheid.
De x-default waarde vertelt Google welke pagina moet worden getoond wanneer geen andere taal overeenkomt met de gebruiker. Het is je terugvaloptie, meestal je taalkiezer of je homepage voor de primaire markt. Het is niet strikt verplicht volgens de specificatie, maar in de praktijk zou je het altijd moeten opnemen. Zonder dit krijgt een Portugees sprekende bezoeker waarvoor je geen Portugese versie hebt een willekeurige pagina in plaats van een bewuste standaard.
De wederkerigheid van return-tags is niet onderhandelbaar. Elke pagina in een hreflang-set moet terugverwijzen naar elke andere pagina, inclusief zichzelf. Als je Engelse pagina Duits als alternatief vermeldt, moet je Duitse pagina Engels als alternatief vermelden. Als de Duitse pagina de terugverwijzing weglaat, wantrouwt Google de hele relatie en negeert de annotaties.
<!-- 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/" />
De zelfreferentie (de verwijzend naar de Duitse pagina bij het bekijken van de Duitse pagina) is vereist, niet optioneel. Een set van vijf taalversies betekent dat elk van de vijf pagina's alle vijf <link>-tags plus x-default uitvoert.
Drie manieren om hreflang in WordPress te implementeren
Je hebt drie praktische opties, variërend van volledige handmatige controle tot volledig geautomatiseerd.
Methode 1: Handmatig via wp_head
Voor een kleine statische set pagina's kun je hreflang-tags direct injecteren via de wp_head actie in de functions.php van je thema:
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 )
);
}
} );
Dit geeft je precieze controle, maar schaalt niet. Handmatig wederkerigheid onderhouden over honderden berichten is een onderhoudsvalkuil.
Methode 2: Een meertalige plugin
Als je Polylang, WPML of TranslatePress gebruikt, wordt hreflang automatisch gegenereerd op basis van je vertaalrelaties. Dit is het juiste antwoord voor de meeste sites, omdat de plugin al weet welk bericht de vertaling is van welk bericht, dus wederkerigheid en x-default worden voor je afgehandeld. De kosten zijn de runtime overhead die deze plugins toevoegen, wat de afweging is die we onderzoeken in onze vergelijking van handmatige versus AI-vertaalmethoden.
Methode 3: XML Sitemap met xhtml:link
In plaats van hreflang in de <head> van elke pagina te plaatsen, kun je de relaties declareren in je XML-sitemap met behulp van de xhtml:link namespace. Elke <url>-vermelding somt al zijn taalalternatieven op:
<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>
Dit houdt de HTML van je pagina slank en centraliseert de taalmap in één crawlbaar bestand, wat Google graag leest. De meeste SEO-plugins kunnen dit automatisch genereren.
hreflang vult vertaling aan, het vervangt het niet
Hier is het punt dat iedereen mist: hreflang is waardeloos als de onderliggende pagina's niet daadwerkelijk zijn vertaald. De tag vertelt Google "dit is de Duitse versie," maar als de Duitse URL nog steeds Engelse pluginstrings, onvertaalde afrekenlabels, of halfafgemaakte .po bestanden toont, heb je Google simpelweg verteld om kapotte inhoud met vol vertrouwen aan Duitse gebruikers te leveren.
Echte meertalige SEO bestaat uit twee lagen. De inhoudslaag zijn je vertaalde .po, .pot, .json en .xliff bestanden die elke thema- en pluginstreng in de doeltaal sturen. De signaallaag is hreflang die elke voltooide versie naar zijn publiek routeert. Beide moeten solide zijn. Een perfecte hreflang-set bovenop een voor 40 procent vertaalde site garandeert alleen maar sneller een slechtere ervaring.
Dit is waar het schoon houden van de vertaallaag het meest telt. Wanneer je je interfacebestanden vertaalt, moeten placeholders zoals %s, %1$s en {name} intact blijven, anders wordt je "vertaalde" Duitse pagina weergegeven met letterlijke %s tokens die er kapot uitzien voor zowel gebruikers als zoekmachines. Een gettext-bewuste vertaalpijplijn met Syntax Locking beschermt die tokens automatisch, zodat elke alternatieve pagina waarnaar je hreflang verwijst, echt klaar is voor productie. Omdat het in de cloud draait met Smart Batching, kun je er een complete multi-locale site doorheen duwen zonder vertaalplugins te installeren die de runtime opblazen die diezelfde pagina's serveert.
Zorg eerst dat de inhoud klopt, en laat dan hreflang zijn werk doen. De twee samen consolideren rankingsignalen, elimineren resultaten in de verkeerde taal en plaatsen elke vertaalde pagina voor de mensen die het kunnen lezen.
Klaar om zoekresultaten in de verkeerde taal bij de bron aan te pakken? Probeer SimplePoTranslate gratis — geen creditcard nodig. Vertaal je
.po,.pot, en.jsonbestanden op de gratis laag, en wijs dan je hreflang-tags naar pagina's die daadwerkelijk klaar zijn voor elke markt.