Meertalige webplatforms bouwen: routing, content en SEO

Meertaligheid is een architectuurbeslissing, geen vertaalklus

De meeste teams behandelen meertaligheid als een contenttaak die na de lancering wordt ingepland. In de praktijk zitten de beslissingen die een meertalig platform maken of breken — URL-structuur, contentmodellering, fallbackgedrag — diep in de architectuur, en ze achteraf rechtzetten behoort tot de duurste migraties die een webplatform kan doormaken. Wij bouwen regelmatig drietalige en grotere platforms, en het patroon is consistent: teams die hun locale-strategie in week één vastleggen, openen nieuwe markten binnen enkele dagen, terwijl teams die deze later toevoegen een kwartaal kwijt zijn aan het ontwarren van routing-, caching- en SEO-regressies.

Kies één URL-strategie en houd u eraan

Zoekmachines en CDN's willen hetzelfde van u: één stabiele, crawlbare URL per locale. Drie strategieën domineren, en ze mengen is slechter dan welke afzonderlijke keuze dan ook.

• Padprefixen (/de/leistungen): één domein, één certificaat, één deployment. hreflang, analytics en caching blijven eenvoudig — dit is onze standaard.
• Subdomeinen (de.example.com): gerechtvaardigd wanneer markten door aparte teams of aparte infrastructuur worden gerund, ten koste van extra DNS, certificaten en versnipperde analytics.
• Landendomeinen (example.de): het sterkste geosignaal en de hoogste beheerkosten — alleen redelijk wanneer een markt op zichzelf een businessunit is.

Wat u ook kiest: varieer content nooit op basis van de Accept-Language-header of een cookie op dezelfde URL — caches én crawlers straffen het af. Taaldetectie hoort thuis in één redirect vanaf de kale root, en de expliciete taalkeuze van de gebruiker moet de gok altijd overrulen.

Vertaalworkflows die het releasetempo overleven

Hardcoded strings zijn de manier waarop meertalige platforms wegrotten. Elke string die de gebruiker ziet, leeft in een catalogus met sleutels per locale, en de sleutelset is een contract dat in CI wordt afgedwongen: een build met ontbrekende of verweesde sleutels faalt, precies zoals een falende typecheck. Die ene gate elimineert de meest voorkomende productiebug in meertalige systemen — een stille Engelse fallback midden op een Duitse pagina.

De tweede valkuil is vertalen behandelen als woord-voor-woordconversie. Sterke taalversies zijn adaptaties: juridische copy volgt in het Duits andere conventies voor toon en zinslengte dan de Engelse bron. Geef vertalers context — screenshots, tekenlimieten, omliggende copy — in plaats van losse spreadsheetregels, en laat elke locale vóór de release door een native reviewer beoordelen.

hreflang is onverbiddelijk, dus genereer het

hreflang kent één regel waar teams telkens over struikelen: annotaties moeten wederkerig zijn. Als de Engelse pagina een Duits alternatief declareert, moet de Duitse pagina de Engelse terug declareren — anders verwerpen zoekmachines het hele cluster en kiezen ze zelf de winnaars.

• Genereer de alternates voor elke locale plus x-default vanuit de single source of truth van de routinglaag; handmatig onderhouden hreflang drift altijd weg.
• Lokaliseer slugs (/de/leistungen, niet /de/services) en houd per entiteit een slug-mapping bij, zodat alternatieve URL's oplosbaar blijven.
• Laat de canonical van elke locale naar zichzelf wijzen en vermeld de alternates in de sitemap, zodat crawlers het volledige cluster in één keer ontdekken.

Performance: een locale mag geen extra round trip kosten

De locale in de URL betaalt zich uit bij het CDN: de cachesleutel is de URL zelf, dus elke gelokaliseerde pagina kan statisch worden gerenderd of aan de edge worden gecachet zonder Vary-header-acrobatiek. Splits messagecatalogi per route zodat een bezoeker nooit drie talen downloadt om er één te lezen, en subset fonts per schriftsysteem — Albanese diakrieten en Duitse umlauten mogen niet elke bezoeker een volledig uitgebreid Latin-font opdringen. Vermijd bovenal client-side taaldetectie die eerst de ene taal rendert en die daarna door een andere vervangt: dat is tegelijk een layout shift en een vertrouwensprobleem.

Modelleer de database translation-first

De schemabeslissing weegt het zwaarst. Verbreed tabellen nooit met kolommen als title_en en title_de — modelleer elke vertaalbare entiteit als een basisrij met identiteit, relaties, media en publicatiestatus, plus een vertaaltabel met entiteit en locale als sleutel, die naam, slug, body en SEO-velden draagt.

• Een locale toevoegen wordt een data-operatie, geen schemamigratie.
• Een unique constraint op (locale, slug) geeft elke taal schone, botsingvrije URL's.
• Het fallbackbeleid wordt expliciet en per contenttype bevraagbaar: toon de standaardtaal, of verberg het item totdat de vertaling er is.

Goed uitgevoerd is meertaligheid onzichtbaar: elke markt krijgt een platform dat native aanvoelt, lokaal rankt en identiek presteert. Dat is de standaard die het engineeren waard is — drie talen die zich als één platform gedragen.