Een meertalige website vraagt meer dan een taalvlaggetje

Een meertalige website biedt bezoekers een samenhangende versie van je informatie in hun taal. Daar horen ook navigatie, formulieren, bevestigingen en de praktische voorwaarden bij. Begin daarom niet met automatisch alle pagina’s vertalen, maar met de markt die je wilt bedienen en de route die een bezoeker daar moet kunnen afmaken.

Een extra taal is ook een beheerafspraak. Zodra je een dienst, voorwaarde of proces wijzigt, moet iemand weten welke vertalingen opnieuw aandacht nodig hebben. Zonder dat eigenaarschap kunnen de taalversies na de eerste publicatie uit elkaar gaan lopen.

Kies eerst welke taalversie werkelijk nodig is

Onderzoek bestaande vragen uit sales en support, de herkomst van relevante aanvragen en gesprekken met potentiële klanten. Een taal en een land zijn niet hetzelfde. Nederlandstalige bezoekers in België kunnen andere leveringsvoorwaarden hebben dan bezoekers in Nederland. Omgekeerd kan één Engelstalige uitleg voldoende zijn voor een internationale oriëntatie, zolang je geen lokale dienstverlening suggereert die je niet kunt leveren.

Schrijf per taal of regio op welke diensten beschikbaar zijn, wie aanvragen beantwoordt en welke informatie moet afwijken. Als je team alleen in het Nederlands kan opvolgen, moet de website daar eerlijk over zijn. Een vertaalde voorkant zonder passende opvolging maakt de klantreis niet compleet.

Inventariseer de volledige inhoud

Neem naast de zichtbare pagina’s ook paginatitels, omschrijvingen voor zoekresultaten, afbeeldingsbeschrijvingen, menu’s, zoekmeldingen, foutmeldingen en e-mails op. Controleer downloads en teksten in afbeeldingen. Een vertaald aanvraagformulier met een Nederlandstalige foutmelding is een aanwijzing dat alleen de hoofdtekst is meegenomen.

Maak een begrippenlijst met productnamen, vaktermen en woorden die bewust niet worden vertaald. Laat machinevertalingen inhoudelijk controleren door iemand die zowel de taal als de dienst begrijpt. Let vooral op beloften, technische eenheden, datumnotatie en voorwaarden: een vloeiende zin kan inhoudelijk nog steeds het verkeerde zeggen.

Geef taalversies een eigen bereikbare URL

Gebruik een consistente structuur, bijvoorbeeld een Nederlandse pagina op /diensten/ en de Engelse tegenhanger onder /en/services/. Dit zijn illustratieve paden, geen aanwijzing dat SiteJob deze taalversies aanbiedt. Bepaal vooraf hoe de standaardtaal, vertaalde slugs en eventuele regioversies worden ingericht.

Laat bezoekers zelf van taal wisselen en behoud waar mogelijk de overeenkomstige pagina. Google adviseert verschillende URL’s voor taalversies en waarschuwt voor inhoud die alleen op basis van een vermoedelijke taal of locatie wordt gewisseld. Een gedwongen IP-omleiding kan bovendien de verkeerde bezoeker in de verkeerde versie zetten. Zie Google over meertalige en multiregionale sites.

Heeft een artikel geen vertaling, stuur iemand dan niet ongemerkt naar een inhoudelijk andere pagina. Maak duidelijk welke versie beschikbaar is en bied een begrijpelijke uitweg. Gebruik taalnamen zoals Nederlands en English; een vlag alleen laat taal en land onnodig samenvallen.

Gebruik hreflang voor echte overeenkomstige versies

hreflang helpt Google begrijpen welke URL’s taal- of regiovarianten van dezelfde inhoud zijn. Elke groep moet naar zichzelf en de andere varianten verwijzen, met volledige URL’s en wederkerige verwijzingen. Je kunt dit via HTML, HTTP-headers of een sitemap aangeven; kies een methode die je betrouwbaar kunt onderhouden. x-default kan een algemene terugvalbestemming aanduiden. De Google-documentatie voor taalvarianten werkt deze regels uit.

Een hreflang-vermelding is geen garantie op indexering of een positie in een land. Controleer ook of de pagina inhoudelijk echt in de bedoelde taal is, bereikbaar blijft en geen conflicterende canonical heeft. Een volledig vertaalde pagina is niet uitsluitend vanwege die vertaling duplicate content. Laat de gegenereerde verwijzingen beoordelen op de echte paginagroepen, niet alleen op het aanwezig zijn van een tag.

Kies de CMS-inrichting op de vertaalworkflow

Vraag in een CMS-demonstratie om een brontekst te wijzigen en de betreffende vertaling terug te vinden. Kan een vertaler een concept voorbereiden zonder per ongeluk een andere taal te publiceren? Blijven relaties tussen diensten, projecten en media behouden? Wie ziet dat een vertaling na een bronwijziging moet worden bijgewerkt?

Webflow Localize werkt met een primaire locale en aanvullende locales die standaard inhoud en presentatie erven. Per taalversie kun je daarvan afwijken. Sommige mogelijkheden zijn plan-afhankelijk en Localize ondersteunt volgens de actuele documentatie geen Ecommerce Site plan-functies. Controleer dit vóór je een meertalige webshop toezegt. Zie Webflow Localize. Bij een voorgestelde WordPress-oplossing moet dezelfde proef aantonen hoe de gekozen meertalige inrichting werkt; de platformnaam alleen is geen specificatie.

Maak een inhoudelijke en technische taaltest

Laat een taalreviewer de pagina niet alleen lezen, maar een taak uitvoeren: de juiste dienst vinden, de voorwaarden begrijpen en een testaanvraag indienen. Controleer vervolgens of de ontvanger de gekozen taal kent en de juiste bevestiging is verstuurd.

• Controleer lange vertalingen in knoppen, menu’s en mobiele layouts.
• Volg taalwissels vanaf onderliggende pagina’s, niet alleen vanaf de homepage.
• Controleer paginatitels, metadata, canonicals en de wederkerigheid van taalverwijzingen.
• Test ontbrekende vertalingen, downloads, zoekresultaten en foutmeldingen.
• Wijzig een brontekst en controleer de afgesproken route naar een bijgewerkte vertaling.

Publiceer pas wanneer zowel de taalinhoud als de verwerking erachter klopt. Begin zo nodig met een kleinere complete set diensten in één extra taal. Dat is beheerbaarder dan een volledige tweede site waarvan niemand de actualiteit bewaakt. De bredere afweging van platform en beheer vind je in Webflow versus WordPress.