Globaprom.

Meertalig CMS: content beheren over alle talen heen

Een meertalig CMS bewaart en toont content in elke taal: gelokaliseerde velden of aparte sitebomen, headless-opties en automatische hreflang.

31 jul 2026 · 8 min leestijd
Flat vector illustration of a globe at the center connected by flowing lines to abstract interface panels and speech-bubble shapes, suggesting one system serving many regions

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 zijn het makkelijke deel. Het lastige deel, en de reden dat generieke setups worstelen, is de content zelf: de 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.

Content is waar een meertalige site slaagt of stilletjes faalt. Een vertaalmanagementsysteem verplaatst de woorden; het CMS bepaalt hoe ze gemodelleerd, opgeslagen en getoond worden. Onze praktijk voor ontwikkeling van meertalige software leunt bij elk project op deze beslissingen, en dit zijn de beslissingen die ertoe doen: hoe een CMS content per taal weergeeft, of je gelokaliseerde velden of aparte sitebomen kiest, waar headless past, en hoe je URL's en hreflang goed krijgt.

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.

Een echt meertalig CMS modelleert content zo dat één artikel één identiteit heeft en meerdere taalversies, allemaal met elkaar verbonden. Die verbinding zorgt ervoor dat het systeem correcte links tussen talen genereert, een nieuwe taal publiceert zonder de hele contentboom te dupliceren, en een vertaler precies vertelt welke stukken ontbreken of verouderd zijn. Een zwakke opzet slaat elke taal op als een losgekoppelde kopie, en de koppelingen die automatisch zouden moeten zijn, worden een spreadsheet die iemand met de hand bijhoudt. De manier waarop de tool vertaalbare content (de woorden) scheidt van structurele data (de opmaak, de relaties) is het teken dat het verraadt. Goede tools houden de structuur gedeeld en variëren alleen de taalspecifieke delen. Dit rust op hetzelfde principe van internationalisatie (i18n) dat de code beheerst: scheid wat per taal verandert van wat niet verandert.

Gelokaliseerde velden of aparte sitebomen

Er zijn twee hoofdmanieren om meertalige content te structureren, en de keuze bepaalt alles wat erna komt.

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. Dit houdt vertalingen strak gekoppeld, maakt van "wat ontbreekt er in het Spaans?" een vraag die het systeem kan beantwoorden, en past bij content die van markt tot markt structureel identiek is. Het is het model waarop onze eigen site draait.

Aparte sitebomen geven elke taal zijn eigen volledige site, in de praktijk parallelle kopieën die aan de bovenkant gekoppeld zijn. Dit past bij gevallen waarin markten sterk uiteenlopen, waar Duitsland andere pagina's, een andere structuur en andere producten nodig heeft dan Frankrijk, niet alleen vertaalde. De prijs is drift: parallelle bomen raken uit sync tenzij iemand ze actief op één lijn houdt.

De meeste softwareproducten willen gelokaliseerde velden, omdat hun content zich netjes van taal naar taal laat projecteren. Sites waar markten echt verschillen in structuur neigen naar aparte bomen. De verkeerde keuze is duur om terug te draaien, en daarom hoort ze thuis in de architectuurfase, niet na de lancering.

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 gaat het verschil verder dan architecturale smaak.

Headless past goed bij meertalige levering, omdat één schone content-API een website, een mobiele app en een interface in het product kan voeden, elk vragend om de taal die het nodig heeft. Dezelfde Nederlandse productbeschrijving bedient elk kanaal zonder opnieuw te worden ingevoerd, en de front-end regelt de taalrouting en de opmaak. Traditionele platforms zijn sneller op te zetten voor een eenvoudige website en dragen een groot ecosysteem van kant-en-klare plugins; WordPress alleen al draait meer dan 40% van alle websites (W3Techs, 2026), een groot deel daarvan meertalig via volwassen vertaalplugins. De afweging is flexibiliteit tegen gemak. Wij bouwen op een headless CMS omdat onze klanten meestal content op meer plekken nodig hebben dan één website, maar een traditionele stack op basis van plugins is het juiste, goedkopere antwoord voor een site die nooit meer dan een site wordt.

Het CMS koppelen aan een vertaalworkflow

Een meertalig CMS zonder route naar vertalers is een set lege taalvakken. De contentlaag en de vertaallaag moeten met elkaar verbinden, anders eindigt iemand met tekst plakken tussen een spreadsheet en het beheerpaneel.

De verbinding werkt in beide richtingen. Content die in het CMS wordt aangemaakt of gewijzigd, zou automatisch naar vertalers moeten stromen, en hun afgeronde vertalingen zouden terug moeten komen in het juiste taalvak zonder kopieer-plakstap. Volwassen meertalige 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. De gewoonte die je moet afdwingen: bepaal hoe een net gepubliceerde pagina een vertaler bereikt voordat je de eerste publiceert, zodat geen enkele taal stilletjes achterop raakt. 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.

Twee dingen moeten kloppen, en beide zouden automatisch uit het CMS moeten komen. Ten eerste hreflang (in het Engels): de HTML-annotatie die zoekmachines vertelt welke taalversie van een pagina ze aan welke gebruiker moeten tonen. Omdat een meertalig CMS elke taalversie van een pagina al kent, kan het hreflang programmatisch genereren, wat de enige betrouwbare manier is; met de hand onderhouden hreflang drijft fout zodra er een pagina wordt toegevoegd. Ten tweede de URL-structuur: vertaalde slugs onder een duidelijk pad per taal (/nl/tarieven/, niet /nl/pricing/) geven de taal aan bezoekers én zoekmachines door en lezen als eigen in plaats van erbij geplakt. Onze eigen site genereert zijn hreflang en taalalternatieven uit de gepubliceerde talen van elke pagina, nooit met de hand, juist omdat handmatige invoer de plek is waar meertalige SEO breekt.

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 een workflow om het te volgen, verrotten talen in stilte.

De functies die dit beheersbaar houden zijn statusregistratie per taal (welke versies gepubliceerd, in concept of verouderd zijn), een duidelijk signaal wanneer een bronpagina verandert en de vertalingen bijgewerkt moeten worden, en rechten zodat een Nederlandse redacteur in het Nederlands kan werken zonder aan het Engelse origineel te komen. Het faalscenario om te vermijden is vertalingen behandelen als "publiceren en vergeten": één keer vertaald bij de lancering, daarna nooit meer bijgewerkt terwijl de bron evolueert, totdat de Nederlandse site een product beschrijft dat de Engelse site niet meer verkoopt. Een CMS dat "deze vertaling loopt nu achter op zijn bron" laat zien, verandert dat stille verval in een zichtbare taak.

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 projecteren. 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 op basis van plugins is sneller en goedkoper voor een site die nooit meer dan een website wordt. De keuze is flexibiliteit tegen gemak.

Hoe gaat een meertalig CMS om met hreflang?

Een goed CMS genereert het automatisch, omdat het elke taalversie van elke pagina al kent. Die programmatische aanpak is de enige betrouwbare; met de hand onderhouden hreflang drijft fout 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 →

Verder lezen

Software nodig die vanaf dag één elke markt spreekt?

Vertel ons wat je wilt laten bouwen. Je krijgt een vaste scope, een vaste prijs en een opleverdatum in weken.

Vertel ons wat je wilt laten bouwen