SEO voor meertalige websites: hreflang uitgelegd zonder technisch gedoe

Een bezoeker uit België die op je Nederlandse pagina belandt, haakt sneller af dan veel site-eigenaren denken. Niet omdat je aanbod slecht is, maar omdat de verkeerde versie wordt getoond. Bij meertalige websites zit de winst vaak in dat soort ogenschijnlijk kleine details.

Daar komt hreflang om de hoek kijken. Het is een technische aanwijzing voor zoekmachines die helpt om de juiste taal- of regioversie van een pagina te tonen. Handig voor internationale SEO, maar vooral ook gewoon praktisch: minder verwarring voor Google én voor je bezoeker.

Wat hreflang doet

Met dit attribuut geef je aan welke versie van een pagina bedoeld is voor welke taal of regio.

Heb je bijvoorbeeld:

• een Nederlandse pagina
• een Engelse pagina
• of aparte versies voor Nederland en België

dan kun je dat expliciet meegeven. Zoekmachines krijgen zo een extra signaal over welke URL het best past bij welke gebruiker.

Belangrijk detail: het is een hint, geen harde instructie. Google volgt die aanwijzing vaak, maar niet altijd.

Wanneer het zin heeft

Deze instelling is relevant zodra je site meer dan één taal of markt bedient. Denk aan:

• een website in het Nederlands en Engels
• een webshop met aparte pagina’s voor Nederland en België
• dienstpagina’s in meerdere talen
• een WordPress-site met een meertalige plugin

Ook als de taal gelijk blijft, maar de regio verschilt, kan het nuttig zijn. nl-nl en nl-be zijn daar een logisch voorbeeld van. Hetzelfde geldt voor en-us en en-gb.

Heb je maar één taalversie en richt je je niet op meerdere landen? Dan is dit meestal niet iets waar je tijd in hoeft te steken.

Zo werkt het in de praktijk

De techniek erachter hoeft niet ingewikkeld te zijn als je de basis snapt. Er zijn eigenlijk drie regels die bijna altijd terugkomen.

Verwijs naar alle varianten, ook naar jezelf

Elke taal- of regioversie van een pagina hoort te verwijzen naar:

• zichzelf
• de andere alternatieven

Heb je een Nederlandse en Engelse versie van dezelfde pagina, dan moeten beide URL’s naar elkaar verwijzen. En ook naar zichzelf. Dat laatste wordt vaak vergeten.

Daarnaast moeten die verwijzingen wederzijds zijn. Als de Nederlandse pagina de Engelse noemt, moet de Engelse versie ook terugverwijzen.

Gebruik de juiste codes

Voor talen gebruik je standaard taalcodes, en voor landen standaard regiocodes. In de praktijk betekent dat vooral: neem de notatie precies over zoals die hoort.

Een paar veelgebruikte voorbeelden:

• nl voor Nederlands
• en voor Engels
• nl-nl voor Nederlands in Nederland
• nl-be voor Nederlands in België
• en-us voor Engels in de Verenigde Staten
• en-gb voor Engels in Groot-Brittannië

Een bekende fout is en-uk. Dat lijkt logisch, maar hoort en-gb te zijn.

De volgorde is ook vast: eerst taal, dan land.

Kies één manier van implementeren

Je kunt deze tags op verschillende manieren toevoegen:

• in de HTML-head
• via de HTTP-header
• in een XML-sitemap

Voor kleinere sites is de HTML-head vaak prima. Bij grotere websites met veel taalvarianten is een XML-sitemap vaak overzichtelijker. Zeker als je met veel pagina’s werkt of als de site technisch wat complexer is.

Door elkaar heen werken kan, maar maakt het sneller foutgevoelig. Eén methode kiezen en die netjes uitvoeren is meestal de veiligste route.

Een simpel voorbeeld

Stel: je hebt twee versies van dezelfde dienstpagina.

• voorbeeld.nl/dienst
• example.com/service

Dan wil je dat zoekmachines begrijpen dat dit alternatieven van elkaar zijn, niet twee losse pagina’s die toevallig op elkaar lijken.

Heb je daarnaast ook nog:

• voorbeeld.nl/be/dienst

dan kun je ook het verschil tussen Nederland en België aangeven. Dat is vooral handig als prijzen, tone of voice of aanbod net anders zijn.

Voor meertalige SEO is dat vaak precies het verschil tussen “Google snapt het wel ongeveer” en “Google snapt het goed”.

De rol van x-default

Niet elke gebruiker past netjes in één taal- of landvariant. Daarvoor is x-default bedoeld.

Met x-default wijs je een fallback-pagina aan voor bezoekers die niet duidelijk onder een specifieke taal of regio vallen. Dat kan bijvoorbeeld zijn:

• een taalkeuzepagina
• een internationale homepage
• een algemene Engelstalige versie

Dat maakt de ervaring netter. Zonder fallback kan een bezoeker op een versie terechtkomen die niet logisch voelt.

Hreflang en canonical: niet hetzelfde

Deze twee worden vaak op één hoop gegooid, maar ze lossen een ander probleem op.

hreflang gebruik je om taal- en regioversies aan elkaar te koppelen.
canonical gebruik je om aan te geven welke URL de voorkeursversie is als content sterk overeenkomt.

Die twee moeten wel met elkaar stroken. Verwijs je met taal-tags naar een pagina, maar staat de canonical ergens anders naartoe, dan stuur je gemengde signalen. Zoekmachines moeten dan gaan gokken, en dat wil je juist voorkomen.

Een praktische vuistregel: laat de verwijzingen aansluiten op de canonieke URL’s van de betreffende pagina’s.

Veelgemaakte fouten

Juist omdat het onderwerp technisch oogt, gaan de missers vaak in de details zitten. Dit zijn de bekendste:

• verkeerde taal- of landcodes gebruiken
• geen wederzijdse verwijzingen instellen
• de eigen pagina niet meenemen in de set
• relatieve URL’s gebruiken waar absolute URL’s veiliger zijn
• taal- en landcode omdraaien
• x-default vergeten terwijl er wel een algemene fallback is
• tags combineren met conflicterende canonical-instellingen
• deze markup gebruiken op pagina’s met noindex
• het inzetten voor compleet andere content die geen echte variant is

Vooral die laatste komt vaker voor dan je zou denken. Dit systeem is bedoeld voor vergelijkbare pagina’s in andere talen of regio’s, niet voor willekeurige alternatieven binnen dezelfde taal.

Wat het kan opleveren

Bij websites die meerdere landen of talen bedienen, kan een goede implementatie duidelijk verschil maken. Niet omdat er een magische SEO-knop wordt omgezet, maar omdat zoekmachines minder hoeven te raden.

Dat kan leiden tot:

• betere aansluiting tussen zoekopdracht en landingspagina
• minder verwarring tussen taalversies
• meer zichtbaarheid in andere markten
• een prettigere gebruikerservaring

Hoe groot dat effect is, verschilt sterk per site. Verwacht dus geen vaste procenten. Zie het liever als een technische basisvoorwaarde voor internationale vindbaarheid.

Zo controleer je of het goed staat

Een eenmalige check is niet genoeg. Zeker bij websites die regelmatig worden uitgebreid of aangepast, sluipen fouten er makkelijk in.

Handige tools en routes om te controleren:

• Google Search Console voor indexeringssignalen en algemene controle
• Screaming Frog voor een technische crawl
• Sitebulb voor visuele audits
• Ahrefs of SEMrush als je toch al met een site-audit werkt
• Merkle, TechnicalSEO.com of Aleyda Solis’ checker voor losse validatie

Werk je in WordPress, dan is het slim om niet blind te vertrouwen op een plugin. WPML, Polylang en TranslatePress kunnen veel automatiseren, maar automatisch is niet hetzelfde als foutloos. Even nalopen blijft verstandig.

Praktische aanpak voor zzp en mkb

Geen zin in een technisch project dat blijft liggen? Pak het dan klein en logisch aan.

1. Maak eerst een overzicht per pagina

Zet per belangrijke pagina op een rij:

• welke taalversies er zijn
• welke regioversies er zijn
• welke URL bij elke variant hoort

Dat voorkomt dat je halverwege ontdekt dat sommige pagina’s wel vertaald zijn en andere niet.

2. Controleer of elke variant een eigen URL heeft

Zonder aparte URL’s kun je weinig duidelijk maken aan zoekmachines. Een taalwisselaar die alleen tekst op dezelfde URL vervangt, is hiervoor meestal niet genoeg.

3. Koppel alle varianten aan elkaar

Elke versie moet verwijzen naar:

• zichzelf
• alle andere relevante alternatieven

Doe dat consequent. Eén ontbrekende schakel kan de hele set minder betrouwbaar maken.

4. Kijk kritisch naar je codes

Controleer vooral de notatie. Kleine fouten, zoals en-uk in plaats van en-gb, zijn snel gemaakt en lastig te spotten als je er niet bewust op let.

5. Kies een implementatiemethode

Voor de meeste mkb-sites zijn dit de logische opties:

• HTML-head: handig bij een kleinere site of maatwerkpagina’s
• XML-sitemap: vaak prettiger bij grotere sites
• plugin-oplossing: praktisch bij WordPress, mits goed gecontroleerd

6. Voeg een fallback toe als dat logisch is

Heb je een algemene internationale pagina of een taalkeuze? Dan is x-default vaak een nette aanvulling.

7. Test na livegang

Controleer niet alleen of de code er staat, maar ook of de set klopt. Een validator of crawltool laat vaak sneller zien waar iets ontbreekt dan handmatig nakijken.

Veelgestelde vragen

Wat is het verschil tussen hreflang en canonical?

De eerste helpt bij taal- en regiotargeting. De tweede wijst de voorkeurs-URL aan bij sterk vergelijkbare of dubbele content. Ze vullen elkaar aan, maar doen niet hetzelfde.

Moet ik dit ook gebruiken voor dezelfde taal in verschillende landen?

Ja, dat kan juist heel nuttig zijn. Denk aan nl-nl en nl-be, of aan Engelstalige pagina’s voor verschillende markten.

Waar plaats je hreflang?

Dat kan in de HTML-head, via HTTP-headers of in een XML-sitemap. Kies bij voorkeur één aanpak en voer die consequent door.

Hoe controleer ik of alles goed staat?

Gebruik bijvoorbeeld Google Search Console, Screaming Frog, Sitebulb of een losse validator zoals Merkle of TechnicalSEO.com.

Is een plugin genoeg voor WordPress?

Vaak kom je een heel eind met WPML, Polylang of TranslatePress. Toch blijft een controle nodig, zeker als je meerdere domeinen, submappen of regioversies gebruikt.