Meertalige website bouwen die echt werkt

Je hebt een Duitse versie van je website gelanceerd. Of een Franse. Je hebt geld uitgegeven aan vertalingen, de navigatie bijgewerkt en misschien zelfs iemand de teksten laten nakijken.

Zes maanden later is het organisch verkeer uit Duitsland vlak. Je opent Google Search Console en ontdekt dat je Duitse pagina's niet geïndexeerd zijn. Of erger - ze zijn geïndexeerd, maar Google toont je Engelse content aan Duitse zoekers.

Dit is de stille faalmode van de meeste meertalige websites. Vanuit het dashboard ziet alles er goed uit. In werkelijkheid werkt niets.

Waarom de meeste meertalige sites niet presteren

De problemen vallen in drie categorieën: verkeerde URL-structuur, kapotte hreflang-implementatie en vertaalkwaliteit die zowel zoekmachines als gebruikers herkennen.

Technische faalmode 1: machinevertaling zonder bewerking

DeepL en Google Translate zijn sterk verbeterd. Maar onbewerkte machinevertaling leest nog steeds als onbewerkte machinevertaling. Native speakers merken het binnen twee zinnen. Belangrijker nog: zoekmachines meten engagement-signalen - bouncepercentage, verblijfstijd, scroll-diepte - en slechte tekstkwaliteit verslechtert alle drie.

Technische faalmode 2: kapotte hreflang

Hreflang is het HTML-attribuut dat Google vertelt welke versie van een pagina aan welke gebruiker te tonen. Het is ook het meest verkeerd geconfigureerde SEO-element op meertalige websites. Ontbrekende zelf-referentiële tags, niet-overeenkomende URL's, onvolledige sets - elk van deze fouten breekt het hele systeem.

Technische faalmode 3: JavaScript-rendered taalwisseling

Sommige sites detecteren de browsertaal in JavaScript en wisselen content aan de clientzijde. Googlebot ziet vaak alleen de standaardtaal. Je Nederlandse content is onzichtbaar voor Google's Nederlandse crawlers. Je hebt een meertalige website gebouwd die Google indexeert als alleen-Engels.

URL-structuur: het fundament dat je later niet meer kunt wijzigen

Voordat je ook maar één vertaling aanraakt, moet je beslissen hoe je meertalige URL's worden gestructureerd. Deze beslissing is moeilijk terug te draaien. Later corrigeren vereist een volledige redirect-migratie.

Voor de meeste bedrijven is de submap-structuur de juiste keuze. Domeinautoriteit blijft geconsolideerd. Je beheert één domein. Hreflang is eenvoudiger te implementeren. Hostingkosten blijven voorspelbaar.

Landdomeinen (voorbeeld.nl, voorbeeld.de) zijn alleen zinvol als lokaal marktvertrouwen een kritieke conversiefactor is - gebruikelijk in financiële diensten of gezondheidszorg, waar gebruikers actief zoeken naar lokale registratiesignalen.

Hreflang: het attribuut dat alles breekt als het fout is

Hreflang-tags vertellen zoekmachines: "deze pagina in het Nederlands is het equivalent van die pagina in het Engels". Zonder hen raadt Google. En raadt meestal verkeerd.

De vier meest voorkomende hreflang-fouten

• Ontbrekende zelf-referentiële tag - elke pagina moet zichzelf refereren in zijn eigen hreflang-set. Laat dit weg en Google kan de hele set negeren.
• Niet-overeenkomende URL's - als je hreflang wijst naar voorbeeld.com/nl/pagina/ maar de werkelijke URL is voorbeeld.com/nl/pagina (geen afsluitende slash), is het kapot.
• Onvolledige sets - als je Engelse pagina een Nederlandse versie refereert, moet die Nederlandse pagina ook de Engelse versie refereren. Eenzijdige tags worden behandeld als fouten.
• Verkeerde taalcodes - `nl` betekent Nederlands wereldwijd. `nl-NL` betekent Nederlands voor Nederland specifiek. `nl-BE` betekent Nederlands voor België. De verkeerde code gebruiken betekent dat Belgische Nederlandstaligen jouw voor Nederland gerichte pagina te zien krijgen.

Een geldige hreflang-implementatie voor een drietalige site ziet er zo uit: elke pagina in elke taal heeft een volledige set tags die wijzen naar alle drie versies, inclusief zichzelf. Dat zijn drie tags per pagina per taal - voor 50 pagina's in drie talen zijn dat 450 hreflang-declaraties. Alle moeten consistent zijn.

Handmatig beheer op schaal is hoe fouten ontstaan. Automatisering op framework-niveau is hoe je ze vermijdt.

Vertaalkwaliteit: wat echt het verschil maakt

Niet alle vertalingen zijn gelijk. De juiste aanpak hangt af van het paginatype, de markt en je budget.

De fout die de meeste bedrijven maken: ze passen ruwe machinevertaling uniform toe op de hele site en vragen zich dan af waarom hun Nederlandse homepage niet converteert. Een homepage is een verkoopdocument. Het heeft native copywriting nodig.

Een blogpost op positie 8 voor een niche-zoekwoord kan wegkomen met machine-plus-bewerking. Je primaire servicepagina niet.

Culturele aanpassing: wat vertaaltools niet kunnen

Dezelfde zin kan correct zijn in het Nederlands en toch niet converteren. Cultureel register, argumentatiestijl en vertrouwenssignalen variëren sterk tussen Europese markten.

Nederland

Nederlanders zijn direct en prijstransparant. Ze haten corporate fluff. Als je Nederlandse tekst klinkt als een persbericht, presteert het ondermaats. Wees specifiek over wat iets kost en wat je ervoor krijgt. Noem concrete cijfers. Abstracte beloftes werken niet.

DACH (Duitsland, Oostenrijk, Zwitserland)

Duitstalige markten verwachten formeel register en technische diepgang. Vage claims zoals 'de beste oplossing' zijn actief contraproductief - onderbouw alles met specifieke data. Gegevensbescherming (DSGVO/AVG) is een vertrouwenssignaal: toon het prominent.

Frankrijk

Frans publiek verwacht formaliteit en een demonstratie van expertise voordat vertrouwen wordt verleend. Casestudies en referenties tellen. Vermijd al te informele tekst - dat oogt onprofessioneel.

Spanje en Latijns-Amerika

Spaanstalige markten zijn warmer en relatiegericht. Vertrouwen wordt evenzeer gebouwd door toon als door referenties. Spanje en Latijns-Amerika zijn echter afzonderlijke markten - vocabulaire, idiomen en formaliteitsnormen verschillen aanzienlijk.

Polen

Poolse B2B-kopers zijn waardegericht. ROI-argumenten landen goed. De markt is prijsgevoeliger dan West-Europa, maar kwaliteitssignalen tellen mee. Vermijd dat je Poolse content aanvoelt als een nabedachte vertaling.

Het WordPress meertaligheid-probleem

De meeste bedrijven die meertaligheid op WordPress willen, grijpen naar WPML of Polylang. Beide zijn volwassen plugins. Beide hebben echte problemen op schaal.

Performance-overhead

WPML voegt extra database-queries toe bij elke pagina-lading om de juiste taalversie te bepalen en te serveren. Op een site met 10.000 berichten in 5 talen wordt deze overhead meetbaar. Je verergert een al performance-beperkte architectuur.

Complexiteit van vertalingsbeheer

Vertalingen beheren in WordPress betekent parallelle berichtshiërarchieën synchroon houden. Update je Engelse servicepagina en je moet elke taalversie handmatig markeren en opnieuw laten vertalen. Vergeet er één en je serveert verouderde content aan echte bezoekers.

Hreflang-fouten

WPML en Polylang genereren hreflang automatisch - maar hun output is zo goed als je vertaalvolledigheid. Als een Nederlandse vertaling ontbreekt, is de hreflang-set voor elke Engelse pagina die ernaar verwijst onvolledig. Plugin-gegenereerde hreflang vereist plugin-perfecte vertaaldekking.

Plugin-afhankelijkheidsrisico

Je volledige meertalige infrastructuur hangt aan een derde-partij plugin die compatibel moet blijven met WordPress core, je thema en je andere plugins. WPML-updates hebben sites al kapot gemaakt. Als het breekt, vallen alle taalversies tegelijk uit.

De Next.js-aanpak voor meertaligheid

Next.js verwerkt internationalisatie op framework-niveau, niet op plugin-niveau. Het verschil is architecturaal.

Routing op framework-niveau

In Next.js zijn `/nl/diensten` en `/en/services` first-class routes. Het framework kent ze bij build-tijd. Er is geen taalwisseling aan de clientzijde, geen runtime-detectie - Google crawlt elke URL als een volledig onafhankelijke pagina met eigen content.

Automatische hreflang-generatie

Met een correcte Next.js i18n-setup worden hreflang-tags gegenereerd vanuit je route-configuratie. Voeg een nieuw locale toe en elke pagina krijgt automatisch de juiste tags. Verwijder een locale en verweesde referenties worden opgeruimd. Geen handmatig beheer, geen stille fouten.

Consistente performance over alle locales

Het toevoegen van Nederlandse en Franse versies aan een Next.js-site voegt geen database-queries, plugin-overhead of PHP-complexiteit toe. Elk locale is een set statische bestanden geserveerd vanuit een CDN-edge. Een Nederlandse gebruiker in Amsterdam krijgt zijn pagina van een Amsterdamse edge-node in onder 50ms - ongeacht hoeveel talen de site ondersteunt.

Gestructureerde content - geen plugin-risico

Vertaalcontent leeft in JSON-bestanden of een headless CMS. Geen plugin om te updaten, te breken of voor te betalen. Geen database-schema-wijzigingen bij het toevoegen van een taal. Content is samen met de code versiebeheerd.

Pre-launch checklist voor meertalige websites

Voordat je een nieuwe taalversie live zet, werk je deze lijst door.

• Test in de Google van het doelland - gebruik een VPN of de URL-inspectietool van Google Search Console om te verifiëren dat de juiste taalversie wordt geretourneerd voor zoekopdrachten vanuit dat land
• Valideer hreflang met een dedicated tool - Screaming Frog of Ahrefs Site Audit toont verkeerd geconfigureerde of ontbrekende hreflang-tags over je volledige URL-set
• Meet PageSpeed voor elk locale onafhankelijk - een Nederlandse pagina met een zwaarder lettertypepakket of andere afbeeldingen kan anders scoren dan je Engelse baseline
• Native speaker review voor launch - niet alleen voor typefouten, maar voor toon, register en of de tekst een lokale klant echt zou overtuigen
• Juridische pagina's lokaliseren - DACH-markten vereisen een Duitstalig Impressum en een DSGVO-conforme privacyverklaring. Nederland heeft AVG-vereisten. Dit zijn wettelijke verplichtingen, geen optionele extras
• Controleer taaldetectie bij directe URL-toegang - als een gebruiker rechtstreeks naar /nl/diensten navigeert, moet hij Nederlands krijgen, niet een doorverwijzing naar Engels op basis van zijn browserinstellingen

Wat 'werkt' echt betekent

Een meertalige website die werkt heeft verschillende organische rankings in elke doelmarkt. Google Search Console toont vertoningen en klikken die vanuit de juiste landen komen op de juiste taalpagina's. Bouncepercentages zijn vergelijkbaar over locales - niet significant hoger op vertaalde versies. En als een Nederlandse gebruiker je doelzoekwoord intypt in Google.nl, vindt hij je Nederlandse pagina, niet je Engelse.

Dat resultaat vereist: de URL-structuur van het begin af aan goed kiezen, hreflang foutloos implementeren, vertaalkwaliteit afstemmen op paginabelang, en een technische stack gebruiken waar al dit automatisch in plaats van handmatig wordt onderhouden.

De meeste bedrijven bereiken dit niet bij de eerste poging. Het gebruikelijke patroon: vertaalde site lanceren, geen resultaten zien, aannemen dat de markt het product niet wil, internationale expansie opgeven.

De markt wil het product meestal wel. De site was alleen niet gebouwd om hem te bereiken.

Ontvang een gratis website-gezondheidsrapport

Als je meertalige website niet presteert - of als je er een plant en de architectuur vanaf het begin goed wilt hebben - auditen we je huidige setup gratis.

Ons gratis website-gezondheidsrapport dekt hreflang-implementatie, URL-structuur, PageSpeed per locale en vertaalkwaliteitssignalen. Je krijgt een specifieke, uitvoerbare analyse van wat kapot is en wat je als eerste moet aanpakken.

Vraag je gratis rapport aan op webvise.io/wp-health-report. Geen salesgesprek vereist.