Hoe je een website naar tien talen vertaalt: mijn systeem met WordPress, Polylang, een eigen plugin en veel AI

Een van de eenvoudigste manieren om meer organisch verkeer te krijgen, is een website vertalen.

Dat is logisch: meer URL’s, meer zoekintenties; als de content goed is, levert dat meer verkeer op.

Natuurlijk lijkt het met AI makkelijk. En op kleine websites is het dat ook.

Bij middelgrote en grote websites wordt het ingewikkelder, tenminste als je het goed wilt doen.

Want het gaat niet alleen om een Spaans artikel pakken, in ChatGPT plakken en om vijf versies vragen. 

Dat werkt voor een test, maar een echte website heeft categorieën, tags, SEO, afbeeldingen, aangepaste velden, interne links, menu’s, archiefpagina’s, homepages, slugs, datums, hreflang en redactionele structuur. 

Om nog maar niet te spreken van het feit dat elk artikel vetgedrukte tekst, lijsten en cursief bevat die je idealiter in de vertaling behoudt.

En alles moet vertaald zijn.

Wat ik deze week op mijn website heb gedaan, is een systeem bouwen om van een Spaanse website naar een meertalige website in tien talen te gaan: Engels, Frans, Portugees, Italiaans, Duits, Nederlands, Zweeds, Pools en Noors, met de plugin Polylang, een zelfontwikkelde plugin en een paar aangepaste GPTs.

Het resultaat is dat ik de website nu in tien talen heb, met de volledige structuur van categorieën en tags en meerdere gepubliceerde artikelen al vertaald.

En met een systeem dat tussen de 5 en 10 extra minuten toevoegt aan elk Spaans artikel om het in deze tien talen te vertalen, wat mij meer dan redelijk lijkt.

Ik vertel je het hele proces voor het geval je het wilt herhalen.

1. Het eerste probleem: artikelen vertalen was niet genoeg

Toen ik de ontwikkeling begon te analyseren, ontdekte ik dat ik in mijn geval, naast de artikelen zelf, dit allemaal moest vertalen:

• Categorieën.
• Tags.
• Slugs.
• Metabeschrijvingen.
• SEO-titels.
• Uitgelichte afbeeldingen.
• Alt-teksten.
• ACF-velden.
• Interne blokken.
• Links tussen artikelen.
• Archiefpagina’s.
• Vaste teksten van het thema.
• Homepagemodules.
• CTAs.
• Formulieren.
• Inhoudsopgaven.
• Gerelateerde artikelen.
• Datums en notities behouden.
• …

Veel copy daar en veel te veel talen om dat één voor één te doen.

Maar het moest vertaald worden, want als een van die onderdelen in het Spaans blijft, blijft de vertaling half af.

Daarom was het doel niet “content vertalen”, maar een complete en schaalbare meertalige architectuur maken, voor het geval ik morgen meer talen wil toevoegen.

En dat is precies wat er gebeurde: ik begon alleen met vijf talen (Engels, Portugees, Frans, Duits en Italiaans) en voegde de andere vier onderweg toe. En meteen kon ik controleren dat het systeem kon opschalen zoals ik nodig had.

2. De basis: WordPress, Polylang en lokale kopie

Het project vertrekt vanuit een WordPress-website met Genesis-thema, eigen magazineachtig ontwerp en meerdere aangepaste templates.

Omdat het iets van enige omvang was en veel tests zou vereisen, werkte ik met een lokale kopie met LocalWP. Het idee was om dingen zonder angst kapot te kunnen maken, imports te testen, taxonomieën te controleren en te valideren dat Polylang elke vertaling goed koppelde.

Trouwens, ik gebruikte deze plugin als basis omdat hij al alles genereert wat nodig is om een site in meerdere talen te hebben. Op basis daarvan maakte ik mijn plugin door hem aan te vullen en aan te passen aan wat ik nodig had: snel de websitestructuur en artikelen in meerdere talen maken.

Ook in deze eerste fase optimaliseerde ik LocalWP omdat de omgeving in het begin te traag was en ik een plek nodig had waar ik soepel kon exporteren, importeren, verwijderen, herhalen en valideren..

3. Het systeem: eigen plugin plus GPTs

Ik had een standaardoplossing voor automatische vertaling kunnen gebruiken, maar het doel was een ander.

Eenvoudige vertaling van elke post

Met de vertaling van de posts was ik ZEER ambitieus, want ik wilde een systeem waarin GPTs die hiervoor gemaakt waren de content van elke post vertaalden met behoud van:

• Mijn stijl persoonlijk.
• De zelfde structuur van het oorspronkelijke artikel.
• Officiële titels van films, series of boeken in elke taal (dat wil zeggen: als het werk Spaans is, moest de vertaling de titel gebruiken waaronder het bijvoorbeeld in Italië is uitgebracht.
• Schone slugs.
• Afbeeldings-alt vertaald.
• Yoast met volledig vertaalde velden, inclusief description.
• Aangepaste ACF-velden, zodat ik kon kiezen of ze wel of niet geëxporteerd worden, of ze vertaald worden of blijven zoals ze waren (zoals bijvoorbeeld de score die ik elk werk in mijn recensies geef).
• HTML-fragmenten zonder ze kapot te maken: lijsten, vetgedrukte tekst, codeblokken… zodat ze behouden blijven en de noodzakelijke delen onvertaald blijven (zoals codescripts).
• Interne links van de artikelen: zodat ze naar de URL van elke taal wijzen, en niet altijd naar het origineel.
• Publicatiedatum: de oorspronkelijke datum van de Spaanse post moet behouden blijven.

Zoals je ziet is de logica hierachter niet “vertalen en klaar”. Er zitten veel tests achter en zelfs een paar dingen die ik heb uitgesloten, zoals het schema dat voorlopig alleen in het Spaans blijft.

En bovendien wilde ik dat het een gratis systeemzou zijn, met GPTs in plaats van de API van OpenAI of Claude. Meer handwerk, maar lagere kosten.

De oplossing die ik koos omvat deze stappen:

1. Ik publiceer zoals gewoonlijk een artikel in het Spaans.
2. Ik gebruik mijn plugin om een gestructureerde JSON te exporteren, met alle inhoud van de post opgesplitst voor vertaling.
3. Een GPT vertaalt die JSON naar de negen talen en geeft mij negen JSON terug (één per taal).
4. De plugin importeert de negen vertaalde JSON-bestanden.
5. Polylang koppelt elke vertaling aan het origineel.
6. De artikelen worden als concept aangemaakt.
7. Ik controleer en/of publiceer.
8. Ik repareer interne links (automatisch) indien nodig.

Daarnaast was er een eerste stap: de structuur in meerdere talen maken. Dit doe je alleen de eerste keer dat er nieuwe talen zijn; in mijn geval gebeurde dat twee keer: eerst voor de vijf oorspronkelijke talen en daarna voor de andere vier.

Als we die eerste taak weglaten eenmalige, voegt het proces dat ik heb ontworpen ongeveer vijf minuten extra toe aan het maken van elke post alleen maar, terwijl ik de nuttige content van mijn website met negen vermenigvuldig.

Niet slecht.

De meertalige structuur

Laten we kijken:

• Website tot het uiterste aangepast.
• Met interfacecopy.
• Een homepage die bijna al haar teksten in code bewaarde.
• 23 categorieën en subcategorieën, met hun modulekoppen, meerdere copies in maatwerkvelden en hun SEO-variabelen.
• 24 tags met vergelijkbare kenmerken.
• Meerdere maatwerkmodules.
• Plugins die standaard geen meertaligheid toestaan.

En ik weet niet of ik nog iets vergeet.

Dit alles moest één keer per taal vertaald worden. En dat zou me, geen idee, minstens vier uur per geval hebben gekost. En dat aangenomen dat ik al die talen zou kennen, wat niet zo is.

Geen sprake van.

Wat heb ik gedaan?

Nou, dit proces:

1. Alle copies omzetten naar variabelen, in code en in custom fields van ACF..
2. Een functionaliteit in de plugin maken die al deze variabelen van elke categorie of tag als JSON exporteert.
3. Een GPT maken die die JSON vertaalt naar de taal die ik nodig heb.
4. Een importeerfunctie toevoegen aan de plugin die de vertaalde JSON oppakt en de volledige taxonomiestructuur in de nieuwe taal maakt.
5. Het proces herhalen met elke taal.
6. De teksten wijzigen die nog openstonden.

Er waren verschillende punten die lastig deden, zoals de slugs in de taxonomieën, omdat de basisversie van Polylang niet toestaat om twee gelijke slugs te maken (alleen met Pro).

Dat wil zeggen: de tag “comic” in het Spaans kon in het Engels niet als “comic” worden aangemaakt, maar moest “comic-en” of iets dergelijks zijn.

Ik ontwikkelde de plugin zodat dit kon, met behoud van dominio.com/comic in het Spaans en dominio.com/en/comic in het Engels.

Yaarp (de plugin die ik gebruikte voor gerelateerde artikelen) gaf ook problemen, dus ik heb hem uitgeschakeld omdat hij artikelen uit andere talen aanbeval. Waarschijnlijk maak ik er in de toekomst een functie voor die taal prioriteit geeft boven de rest van de variabelen in zijn aanbevelingen.

De inschrijving op de lijst in andere talen heb ik voor de lancering ook geschrapt. Misschien besluit ik in de toekomst mijn nieuwsbrief vertaald te versturen, maar voorlopig doe ik dat niet, dus heb ik geen nieuwe lijsten gemaakt in Acumbamail.

4. De al bestaande content: stap voor stap

Alles wat ik je heb verteld werkt geweldig voor nieuwe artikelen, maar wat gebeurt er met de meer dan tweehonderd die ik al heb gepubliceerd?

Ik zou je graag vertellen dat ik een functie heb gemaakt die hun vertaling automatiseert, maar dat is niet zo.

Het verst dat ik ben gekomen, is een functie die mij JSON-exporten in batches van meerdere artikelengenereert, maar toen ik probeerde meerdere artikelen tegelijk in negen talen te vertalen, verwerkt GPT het slechter. Dus voorlopig één voor één.

Aangezien ik ongeveer drie minuten per artikel nodig heb, is het vrij eenvoudig om er tien per dag te vertalen, waardoor ik in minder dan een maand de hele website in de tien talen zou hebben.

Dat past.

Ik heb ook gedacht aan het opzetten van een Hermes en te testen of het dit handmatig doet, maar omdat ik op dit moment geen haast heb en dit me geen geld oplevert, geef ik liever niet meer tokens uit dan nodig.

Het resultaat

Voorlopig ben ik tevreden. Ik heb al meer dan tien artikelen vertaald in tien talen. Dat wil zeggen dat mijn website in een week met 33% is gegroeid.

Voorlopig forceer ik geen indexering. Ik wil wachten tot ik minstens 50 of 60 artikelen heb. Maar als het geïndexeerd wordt, maak ik me ook geen zorgen. Dit is voor de lange termijn.

Wat ik je kan zeggen is dat ik tevreden ben met het resultaat. 

Ik denk dat het systeem dat ik heb gebouwd behoorlijk robuust is — met zijn waarschijnlijke verbeteringen, natuurlijk — maar zelfs in mijn stoutste dromen van een jaar geleden kon ik me niet voorstellen dat ik een meertalige website met dit volume aan content zou beheren.

Nu, zoals ik altijd zeg, kijken waar dit me brengt.

Lessen uit het proces en conclusie

De belangrijkste conclusie — die ik al verwachtte — is dat een website vertalen met AI niet gaat over “teksten vertalen”, maar over een systeem ontwerpen.

AI is super nuttig als het schone input krijgt en gecontroleerde output teruggeeft. Maar als je het een enorm blok geeft, zonder structuur en zonder regels, krijg je iets moois terug dat niet bruikbaar is om te importeren.

Geloof me, dat is me in het begin vaak overkomen.

De sleutel was een systeem bouwen waarin elk onderdeel doet wat het moet doen:

• WordPress is het hart van alles.
• Polylang koppelt content.
• De plugin exporteert en importeert.
• GPT vertaalt.
• Ik neem de redactionele beslissingen.

Duidelijk weten waar elk stuk past en waarom het dat doet en niet iets anders, is wat mij heeft toegestaan om een echt systeem te creëren om een website te schalen met AI-vertaling als hefboom.

Als je mijn systeem leuk vond en wilt dat ik iets toelicht, laat je vragen achter in de reacties en ik antwoord je.