Meertalig CMS: content beheren over alle talen heen

Een meertalig CMS is een contentmanagementsysteem dat gebouwd is om dezelfde site in meer dan één taal op te slaan en te tonen, zodat een redacteur een pagina in het Nederlands publiceert samen met de Engelse en Spaanse versies vanuit één plek, en elke bezoeker automatisch de juiste krijgt.

De interfaceteksten vertalen is het makkelijke deel. Dat kan elk framework. Waar het misgaat is de content: artikelen, productbeschrijvingen en paginateksten die in elke taal moeten bestaan, aan elkaar gekoppeld moeten blijven als versies van elkaar, en de zoekmachines correct moeten bereiken. Een vertaalmanagementsysteem verplaatst de woorden. Het CMS bepaalt hoe ze gemodelleerd, opgeslagen en getoond worden, en dat zijn precies de beslissingen die onze praktijk voor ontwikkeling van meertalige software bij elk project neemt. Sla je ze mis, dan kan het toevoegen van een markt aanzienlijk meer werk en onderhoud veroorzaken dan verwacht, als de contentrelaties en vertaalworkflow niet goed zijn gemodelleerd.

Wat maakt een CMS meertalig

Veel tools claimen meertalige ondersteuning en bedoelen er heel verschillende dingen mee. De vraag die je moet stellen is of het CMS een vertaling behandelt als een gekoppelde versie van één stuk content, of als een losstaande tweede pagina die toevallig hetzelfde zegt.

Eén identiteit, meerdere taalversies, allemaal met elkaar verbonden. Die verbinding zorgt ervoor dat het systeem correcte links tussen talen genereert, een nieuwe taal publiceert zonder de contentboom te dupliceren, en een vertaler precies vertelt welke stukken ontbreken of verouderd zijn. Slaat het systeem elke taal op als een losgekoppelde kopie, dan worden die koppelingen een spreadsheet die iemand met de hand bijhoudt, slecht, totdat er niemand meer naar omkijkt.

Kijk dus naar hoe de tool vertaalbare content scheidt van structurele data. De woorden aan de ene kant, de opmaak en de relaties aan de andere. De structuur gedeeld houden en alleen de taalspecifieke delen laten variëren is hetzelfde principe van internationalisatie (i18n) dat ook de code beheerst.

Gelokaliseerde velden of aparte sitebomen

Twee manieren om meertalige content te structureren. De keuze is duur om terug te draaien, dus ze hoort thuis in de architectuurfase en niet na de lancering.

Gelokaliseerde velden houden één contentitem aan met een vertaalbare waarde per taal voor elk veld. Eén product, één identiteit, met een titel en beschrijving die elk een Nederlandse, Engelse en Spaanse waarde bevatten. Voeg een taal toe en elk item krijgt een nieuw vak, klaar om te vullen. Vertalingen blijven strak gekoppeld, "wat ontbreekt er in het Spaans?" wordt een vraag die het systeem kan beantwoorden, en content die van markt tot markt structureel identiek is past er vanzelf in. Het is het model waarop onze eigen site draait.

Aparte sitebomen geven elke taal zijn eigen volledige site, parallelle kopieën die aan de bovenkant gekoppeld zijn. Gebruik ze waar markten echt uiteenlopen, waar Duitsland andere pagina's, een andere structuur en andere producten nodig heeft dan Frankrijk, niet alleen vertaalde. De keerzijde is drift. Parallelle bomen raken uit sync tenzij iemand ze actief op één lijn houdt, en die taak staat zelden op iemands naam.

De meeste softwareproducten willen gelokaliseerde velden, omdat hun content zich netjes van taal naar taal laat overzetten.

Headless of traditioneel CMS voor meertalige content

Een traditioneel CMS slaat de content op en rendert de pagina's zelf, template en al. Een headless CMS slaat de content op en serveert die via een API, en laat de presentatie over aan een aparte front-end.

Voor meertalig werk wordt dat verschil snel praktisch. Eén schone content-API kan een website, een mobiele app en een interface in het product voeden, elk vragend om de taal die het nodig heeft, zodat dezelfde Nederlandse productbeschrijving elk kanaal bedient zonder ergens opnieuw te worden ingevoerd. De front-end regelt de taalrouting en de opmaak.

Traditionele platforms winnen op opzettijd en op ecosysteem. Volgens W3Techs gebruikte WordPress op 19 augustus 2026 40,7% van alle websites en 59,0% van de websites waarvan het CMS bekend was; die statistiek zegt niet welk deel van die sites meertalig is, noch hoe lang vertaalplugins daar al in productie draaien, maar veel ervan draaien via bewezen vertaalplugins. Wij bouwen op een headless CMS omdat onze klanten meestal content op meer plekken nodig hebben dan één website. Voor een site die nooit meer dan een site wordt is een stack op basis van plugins goedkoper en beter, en dat zeggen we er ook bij.

Het CMS koppelen aan een vertaalworkflow

Een meertalig CMS zonder route naar vertalers is een set lege taalvakken. Iemand eindigt met tekst plakken tussen een spreadsheet en het beheerpaneel, meestal degene die daar de minste tijd voor heeft.

De verbinding moet in beide richtingen lopen. Content die in het CMS wordt aangemaakt of gewijzigd, stroomt naar vertalers zonder dat iemand eraan hoeft te denken, en afgeronde vertalingen komen terug in het juiste taalvak zonder kopieer-plakstap. Volwassen platforms stellen dit beschikbaar via een API of een vertaalconnector, zodat een vertaalmanagementsysteem de broncontent kan ophalen, vertaalgeheugen en woordenlijsten kan toepassen, en het resultaat kan terugsturen.

Bepaal hoe een net gepubliceerde pagina een vertaler bereikt voordat je de eerste publiceert. Wacht je daarmee, dan loopt er al een taal achter. Of een bepaalde markt volledige vertaling of diepere lokalisatie nodig heeft, is een aparte budgetvraag, behandeld in lokalisatie of vertaling.

hreflang en URL's goed krijgen vanuit het CMS

De laatste stap van een meertalig CMS is de zoekmachine. Content in vijf talen publiceren helpt niemand als Google de verkeerde versie aan de verkeerde bezoeker toont.

hreflangis de HTML-annotatie die zoekmachines vertelt welke taalversie van een pagina ze aan welke gebruiker moeten tonen. Het CMS kent elke taalversie van elke pagina al, dus het kan die annotaties programmatisch genereren. Google raadt aan om voor elke taalversie een afzonderlijke URL te gebruiken en hreflang-annotaties toe te voegen, zodat Google de juiste taalversie in de zoekresultaten kan tonen. Elke taalversie moet zichzelf en alle andere relevante taalversies vermelden; de alternatieve URL's moeten volledig gekwalificeerd zijn en de verwijzingen moeten wederzijds zijn om door Google te worden verwerkt. Programmatische generatie kan het onderhoud van hreflang-annotaties helpen stroomlijnen, maar de implementatie moet worden gevalideerd op volledigheid, correcte URL's en wederzijdse verwijzingen. Met de hand onderhouden hreflang loopt makkelijker uit de pas zodra er een pagina bij komt, en dat kan maandenlang onopgemerkt blijven.

De URL-structuur is de andere helft. Vertaalde slugs onder een duidelijk pad per taal (/nl/tarieven/, niet /nl/pricing/) geven de taal aan bezoekers én zoekmachines door en ogen als volwaardig onderdeel in plaats van erbij geplakt. Een taalspecifieke URL-structuur kan de taal- of regioversie duidelijk maken, maar Google bepaalt de taal niet uitsluitend op basis van de URL; zichtbare paginacontent en expliciete signalen zoals hreflang spelen eveneens een rol. Onze eigen site genereert zijn hreflang en taalalternatieven uit de gepubliceerde talen van elke pagina, nooit met de hand, precies om de reden hierboven.

De redactionele workflow als elke pagina versies heeft

Meertalige content vermenigvuldigt het redactiewerk. Eén gepubliceerde wijziging in de brontaal wordt een vertaaltaak in elke andere taal, en zonder manier om dat te volgen verouderen talen ongemerkt.

Drie functies houden het beheersbaar: status per taal, zodat je ziet welke versies gepubliceerd, in concept of verouderd zijn; een signaal wanneer een bronpagina verandert en de vertalingen erop achterlopen; en rechten zodat een Nederlandse redacteur in het Nederlands kan werken zonder aan het Engelse origineel te komen.

"Publiceren en vergeten" is het faalscenario. Eén keer vertaald bij de lancering, daarna nooit meer bijgewerkt terwijl de bron doorloopt, totdat de Nederlandse site een product beschrijft dat de Engelse site twee jaar geleden uit de verkoop haalde. Een CMS dat "deze vertaling loopt nu achter op zijn bron" laat zien, verandert dat stille verval in een taak die iemand kan zien.

Veelgestelde vragen over een meertalig CMS

Wat is een meertalig CMS?

Een meertalig CMS is een contentmanagementsysteem dat dezelfde site in meerdere talen opslaat en toont, waarbij elke vertaling gekoppeld blijft als versie van één stuk content. Het laat redacteuren elke taalversie vanuit één plek publiceren en beheren, en toont de juiste aan elke bezoeker automatisch.

Wat is het verschil tussen gelokaliseerde velden en aparte sitebomen?

Gelokaliseerde velden houden één contentitem aan met een vertaalbare waarde per taal voor elk veld, ideaal als content zich netjes van markt tot markt laat overzetten. Aparte sitebomen geven elke taal zijn eigen volledige site, beter als markten echt andere structuur en pagina's nodig hebben. Gelokaliseerde velden blijven strak gekoppeld; aparte bomen dreigen uit elkaar te lopen.

Moet ik een headless CMS gebruiken voor een meertalige site?

Gebruik headless wanneer content meer dan één kanaal moet voeden (een website, een mobiele app, een interface in het product), omdat één content-API per taal ze allemaal bedient. Een traditioneel CMS met passende plugins kan voor een site die nooit meer dan een website wordt een pragmatische keuze zijn; snelheid en totale kosten hangen af van de vereisten, het ecosysteem en het onderhoud. De keuze is flexibiliteit tegen gemak.

Hoe gaat een meertalig CMS om met hreflang?

Een goed CMS kan hreflang programmatisch genereren, omdat het elke taalversie van elke pagina al kent, maar de betrouwbaarheid hangt af van een correcte en gecontroleerde implementatie; Google vereist onder meer volledige en wederzijdse verwijzingen. Met de hand onderhouden hreflang loopt makkelijker uit de pas zodra er een pagina wordt toegevoegd of verwijderd. Het zou ook vertaalde URL-slugs onder een duidelijk pad per taal moeten produceren.

Hoe komen vertalingen in een meertalig CMS terecht?

Via een koppeling met een vertaalworkflow: de broncontent stroomt automatisch naar vertalers, en de afgeronde vertalingen komen terug in het juiste taalvak zonder handmatig kopiëren en plakken. Volwassen platforms stellen dit beschikbaar via een API of connector, zodat een vertaalmanagementsysteem er vertaalgeheugen en woordenlijsten tussen kan toepassen.

Bouw een contentsysteem dat de taal van elke markt spreekt

Vertel ons in hoeveel talen je content moet leven, en waar die moet verschijnen (website, app, in het product). We bakenen het contentmodel, de vertaalkoppeling en de hreflang-configuratie af als één ontwikkeling met vaste prijs, opgeleverd in weken, zodat geen enkele taal ooit achterop raakt op zijn bron. Je ziet het aan het werk in onze e-commerce-ontwikkeling op maat.

Vraag een offerte met vaste prijs aan →