Meertalige websites goed opzetten: hreflang, adressen, valkuilen
Een tweede taal is de goedkoopste manier om bereik te winnen – de inhoud ligt er immers al. Het is ook de plek waar de meeste technische fouten ontstaan, omdat vier dingen tegelijk moeten kloppen en er drie van onzichtbaar zijn.
Het belangrijkste kort
- Onderliggende mappen (
/en/) zijn voor de meeste bedrijven de juiste keuze – eenvoudiger dan eigen domeinen, doeltreffender dan parameters. - hreflang moet wederzijds zijn: elke versie verwijst naar alle andere, naar zichzelf en naar een standaardversie.
- Adressen horen mee vertaald te worden. Een Engelse tekst onder een Nederlands adres is een halve vertaling.
- Automatisch doorsturen op basis van de browsertaal is de vaakst voorkomende zware fout – het sluit crawlers en gebruikers buiten.
Het technische deel van een meertalige site is te overzien als je het één keer goed opzet – en bewerkelijk als je het achteraf corrigeert. Daarom loont het halve uur vooraf.
De adresstructuur
| Variant | Voorbeeld | Geschikt voor |
|---|---|---|
| Onderliggende map | voorbeeld.ch/en/ | vrijwel iedereen – één domein, één kracht |
| Subdomein | en.voorbeeld.ch | gescheiden systemen of beheerders |
| Eigen landendomein | voorbeeld.de | zelfstandige marktpresentaties met eigen team |
| Parameter | voorbeeld.ch/?lang=en | niets – vermijden |
Onderliggende mappen winnen vrijwel altijd, omdat alle taalversies profiteren van de kracht van hetzelfde domein. Eigen landendomeinen vragen dat elk ervan afzonderlijk wordt opgebouwd – dat loont pas met een team per markt.
hreflang goed instellen
Vier regels die samen moeten gelden. Wordt er één geschonden, dan wordt de hele groep vaak genegeerd.
- Wederzijds. Als de Nederlandse versie naar de Engelse verwijst, moet de Engelse ook naar de Nederlandse verwijzen. Eenzijdige gegevens worden verworpen.
- Zelfverwijzing. Elke pagina verwijst ook naar zichzelf. Wordt vaak vergeten en is niet optioneel.
- Standaardversie opgeven. Eén
x-defaultvoor alle talen die niet gedekt zijn. - Absolute adressen. Volledig met protocol en domein, geen relatieve paden.
nl voor Nederlands algemeen, nl-BE voor Nederlands in België. Wie maar één Nederlandse versie heeft, neemt nl – niet nl-BE. Anders krijgen Nederlandse bezoekers de versie niet toegewezen.
Zes fouten die een meertalige site onzichtbaar maken
1. Automatisch doorsturen op browsertaal
De zwaarste fout. Crawlers komen meestal met een Amerikaanse taalinstelling en zien dan nooit de andere versies. Ook gebruikers komen niet meer waar ze naartoe wilden.
Goed: een melding tonen met een suggestie, maar niet omleiden. De keuze onthouden.
2. Adressen niet vertaald
/en/colofon/ in plaats van /en/legal-notice/. Het oogt als een halfafgemaakte versie – en verspilt de zoekterm in het adres.
Goed: adressegmenten per taal vertalen, blijvend vastleggen en niet meer wijzigen.
3. Canonical wijst naar de hoofdtaal
Als de Engelse pagina als canonieke adres de Nederlandse opgeeft, zeg je: deze pagina is een duplicaat, neem de andere. Ze verdwijnt uit de index.
Goed: elke taalversie is haar eigen canonieke adres.
4. Ontbrekend lang-attribuut
<html lang="nl"> ontbreekt of staat in alle versies gelijk. Dat raakt niet alleen zoekmachines, maar ook voorleesprogramma's – daar leidt het tot onverstaanbare uitspraak.
Goed: per versie de passende code, automatisch gezet.
5. Eén sitemap voor alles, zonder taalgegevens
Zonder hreflang-gegevens in de sitemap ontbreekt de verbinding tussen de versies precies op de plek waar die het eenvoudigst herkend zou worden.
Goed: hreflang ofwel in de sitemap, ofwel in de <head> – consequent op één plek.
6. Half vertaalde pagina's
Koppen vertaald, lopende tekst nog in de oorspronkelijke taal. Voor zoekmachines is dat een pagina zonder duidelijke taal – en voor bezoekers een vertrouwensprobleem.
Goed: liever minder pagina's volledig dan alle half.
Wist je dat?
Vertalen alleen volstaat niet – vier dingen moeten worden aangepast aan het land, niet alleen aan de taal: bedragen in de landsvaluta, de geldende rechtssituatie, plaatselijk gangbare voorbeelden en datumnotaties.
Een Engelse versie die Zwitserse frank en de herziene Zwitserse wet op de gegevensbescherming noemt, is geen versie voor de Britse markt, maar een vertaling van de Zwitserse site. Dat kan bewust zo bedoeld zijn – maar het zou een beslissing moeten zijn en geen vergissing.
Het onderhoud is het eigenlijke probleem
De opbouw is een eenmalige inspanning. Het onderhoud is blijvend – en daar stranden meertalige sites vaker op dan op de techniek.
Na een jaar ziet het gebruikelijke beeld er zo uit: de hoofdtaal heeft 40 pagina's, de tweede 31, de derde 22. Wijzigingen zijn in de hoofdtaal doorgevoerd en in de andere vergeten – en niemand weet nog welke versie actueel is.
Daartegen helpt alleen een structurele beslissing: een wijziging geldt pas als klaar zodra ze in alle talen is nagetrokken. Wie dat niet kan volhouden, zou minder talen moeten aanbieden – drie onderhouden versies verslaan acht verouderde ruimschoots.
Controlelijst vóór de start
- Elke pagina verwijst via hreflang naar alle versies, naar zichzelf en naar x-default
- Elke versie is haar eigen canonieke adres
<html lang>is per versie correct gezet- Adressegmenten zijn vertaald en blijvend vastgelegd
- Geen automatisch doorsturen op basis van de browsertaal
- De taalkeuze is zichtbaar en werkt zonder JavaScript
- Bedragen, juridische gegevens en voorbeelden zijn aangepast, niet alleen vertaald
- Er is een vast proces dat wijzigingen in alle talen natrekt
Toets de meertalige inrichting van mijn website. Gegevens: - Domein: [adres] - Talen: [lijst met taalcodes] - Adresstructuur: [onderliggende map / subdomein / eigen domein] - hreflang-blok van een voorbeeldpagina: [blok invoegen] - Canonical-opgave van dezelfde pagina: [invoegen] - lang-attribuut van dezelfde pagina: [invoegen] - Is er een automatische doorverwijzing op browsertaal? [ja / nee] - Zijn de adressegmenten vertaald? [voorbeeld per taal] Opdrachten: 1. Toets de vier hreflang-regels: wederzijds, zelfverwijzing, x-default aanwezig, absolute adressen. Noem elke schending afzonderlijk. 2. Toets of de taalcodes goed zijn gekozen – vooral of een regio-aanduiding te eng is opgevat. 3. Toets canonical en lang-attribuut op tegenspraak met de taalversie. 4. Noem de punten uit mijn opgave die een taalversie onzichtbaar kunnen maken, gesorteerd op zwaarte. 5. Geef me het gecorrigeerde hreflang-blok volledig terug. Verzin geen adressen – markeer ontbrekende als [aan te vullen].
Conclusie
Technisch beslist een meertalige site zich op vier plekken: adresstructuur, wederzijdse hreflang, een eigen canoniek adres per versie, geen automatisch omleiden. Kloppen die vier, dan werkt de rest.
De eigenlijke vraag is daarna een organisatorische: lukt het jullie om elke wijziging in alle talen na te trekken? Zo niet, dan zijn minder talen de betere beslissing.
Veelgestelde vragen
Welke adresstructuur is voor meertalige websites het beste?
Onderliggende mappen zoals /en/ voor vrijwel alle bedrijven: alle taalversies profiteren van de kracht van hetzelfde domein, en het beheer blijft eenvoudig. Eigen landendomeinen lonen pas bij zelfstandige marktpresentaties met een eigen team; taalparameters in het adres kun je beter vermijden.
Waar moet je bij hreflang op letten?
Op vier regels tegelijk: de gegevens moeten wederzijds zijn, elke pagina moet ook naar zichzelf verwijzen, er is een x-default nodig voor niet-gedekte talen, en alle adressen moeten absoluut zijn opgegeven. Wordt één regel geschonden, dan wordt vaak de hele groep genegeerd.
Moet je bezoekers automatisch naar hun taal doorsturen?
Nee. Crawlers komen meestal met een Amerikaanse taalinstelling en zien dan nooit de andere versies; gebruikers belanden niet waar ze naartoe wilden. Goed is een melding met een suggestie die de gemaakte keuze onthoudt – zonder automatische omleiding.
Moeten de adressen worden vertaald?
Ja. Een Engelse tekst onder een Nederlands adres oogt halfafgemaakt en verspilt de zoekterm in het adres. De adressegmenten zouden per taal vertaald en daarna blijvend vastgelegd moeten worden – latere wijzigingen kosten de opgebouwde zichtbaarheid.
Hoeveel talen zijn zinvol?
Zoveel als er blijvend onderhouden kunnen worden. De meest voorkomende toestand na een jaar zijn verschillend volledige versies waarbij niemand meer weet welke actueel is. Drie onderhouden talen werken duidelijk beter dan acht verouderde – doorslaggevend is een vast proces dat elke wijziging in alle versies natrekt.
Marketing die zichzelf opzet
De bèta van de Studio Engine is open. Reserveer je plek en denk vanaf het begin mee.
Deelnemen aan de bèta →