Dit is geen hypothetisch scenario. Het is precies wat een van onze klanten meemaakte. Voor hen zette Red Factory al die 110 artikelen om naar correcte Gutenberg blocks, met behulp van AI-automatisering. Niet in weken, maar in een fractie van de tijd.
In dit artikel leg ik uit wat de WordPress Gutenberg editor precies inhoudt, waarom die omzetting loont, en hoe AI dat soort werk ineens haalbaar maakt voor een MKB-budget.
Inhoudsopgave
Wat is de WordPress Gutenberg editor?
De WordPress Gutenberg editor is de standaard editor, ingevoerd met versie 5.0 in december 2018. De naam verwijst naar Johannes Gutenberg – de uitvinder van de drukpers – wat een beetje pretentieus is, maar de kern klopt: het veranderde hoe content in WordPress wordt samengesteld.
Het idee is simpel. In plaats van een grote lap tekst in een klassieke tekstverwerker, werk je met losse bouwstenen: “blocks”. Een alinea is een block. Een kop is een block. Een afbeelding, een quote, een lijst – allemaal aparte blocks die je versleept, aanpast en herschikt zonder aan de onderliggende HTML te hoeven zitten.
Voor redacteuren die gewend zijn aan tools als Word of Google Docs voelt dat intuïtief. Je ziet precies wat je doet. Je kunt een block verplaatsen zonder iets te breken. Je kunt een kop omzetten naar een ander niveau zonder naar de broncode te kijken.
Dat klinkt vanzelfsprekend, maar voor wie jarenlang werkte met de klassieke editor van WordPress – of met pagebuilders als Elementor, Divi of Visual Composer – is het een flinke omschakeling. De classic editor plugin is nog steeds beschikbaar voor wie terug wil, maar WordPress investeert alle nieuwe ontwikkeling in het block-systeem. De richting is duidelijk.
Waar het voor dit artikel om gaat: als jouw bestaande artikelen zijn opgebouwd in de classic editor of een pagebuilder, staan ze niet als Gutenberg blocks in de database. Ze zijn opgeslagen als één grote woordsalade, en dat is precies het probleem.
Het probleem met oude WordPress-content
Bijna elke WordPress-site die al een paar jaar meedraait, heeft dit: een archief vol artikelen die ooit met zorg zijn geschreven voor Gutenberg WordPress, maar sindsdien technisch verouderd zijn.
Shortcodes en losse HTML: niemand durft er meer aan
Pagebuilders slaan content op in een formaat dat werkt met hun eigen plugin. Een artikel dat in Elementor is gebouwd, bevat in de WordPress-database geen nette HTML – het bevat shortcodes, inline stijlen en soms letterlijk duizenden regels gegenereerde markup. Als de plugin-versie verandert of de plugin wordt verwijderd, krijg je een wirwar aan symbolen te zien in plaats van een artikel.
Zelfs zonder dat dramatische scenario: als redacteur zie je een groot grijs vlak in de editor als je zo’n artikel opent. Je kunt de tekst niet aanpassen zonder de volledige pagebuilder te starten – wat langzaam laadt, onhandig werkt en constant instortingsgevaar creëert. Kleine aanpassing, grote schade.
Het gevolg is dat niemand er meer aan komt. De artikelen blijven staan zoals ze zijn. Soms zelfs jaren.
Slechte SEO-structuur als bijvangst
Rommelige content heeft ook een SEO-prijs bij WordPress Gutenberg editor-migraties. Pagebuilders voegen vaak heading-levels toe op basis van hoe iets er visueel uitziet, niet op basis van logische documentstructuur. Je krijgt een H3 als eerste kop, een H1 halverwege de pagina, of helemaal geen kopenstructuur. Google probeert er wat van te maken, maar een consistente heading-hierarchie – H1 voor de paginatitel, H2 voor hoofdsecties, H3 voor subsecties – is een van de eenvoudigste SEO-verbeteringen die je kunt doorvoeren.
Daarbij komt de HTML-ballast. Pagebuilders voegen wrapper-divs, inline stijlen en onnodige classes toe. Dat vergroot de pagina, vertraagt het laden en maakt het lastiger voor zoekmachines om de daadwerkelijke inhoud te extraheren.
Je hebt content die technisch gezien niet meer werkt, niet meer bewerkbaar is zonder risico, en die ook nog eens minder goed scoort dan hij zou kunnen.
Wat een Gutenberg-migratie concreet oplevert
Na de migratie naar WordPress Gutenberg editor blocks ziet hetzelfde artikel er voor de redacteur heel anders uit.
Wat er concreet verandert:
- Bewerkbaarheid – Elke alinea, elke kop, elke lijst is een aparte block die je direct kunt aanklikken en bewerken. Geen pagebuilder nodig, geen risico op breuk.
- Consistente opmaak – Alle artikelen volgen dezelfde block-structuur. Geen artikel met drie verschillende lettertypes omdat drie verschillende mensen drie verschillende instellingen gebruikten.
- Correcte heading-hierarchie – H1 voor de paginatitel, H2 voor hoofdsecties, H3 voor subsecties. Consistent, logisch, en beter leesbaar voor zoekmachines.
- Schone HTML-output – Gutenberg genereert strakke, semantisch correcte HTML zonder onnodige ballast. Dat is sneller en duidelijker voor Google.
Lees meer over de technische kant in ons artikel over WordPress SEO: de instellingen die echt verschil maken.
Voor de content marketing is het misschien wel het meest tastbare voordeel: artikelen die je kunt bijwerken. Een artikel uit 2019 dat kwalitatief goed is maar verouderde informatie bevat, kun je nu eindelijk updaten zonder dat je een developer nodig hebt. Dat geeft je archief waarde terug.
Wat een Gutenberg-migratie niet oplost: de kwaliteit van de tekst zelf. Als een artikel verouderd, oppervlakkig of slecht geschreven is, verandert de technische conversie daar niets aan. De migratie maakt artikelen bewerkbaar – wat je daarna doet met die bewerkbaarheid is aan jou.
Waarom je dit niet handmatig doet
Stel dat je besluit om 110 artikelen handmatig om te zetten naar Gutenberg blocks. Wat is daarvoor nodig?
Per artikel moet je de bestaande HTML-inhoud analyseren, de structuur begrijpen (koppen, alinea’s, lijsten, afbeeldingen), elk element omzetten naar het juiste Gutenberg block-type, controleren of de tekst intact is, en de opmaak testen in de editor.
Voorzichtig geschat kost een gemiddeld artikel – met wat zoekwerk, kopieerwerk en controle – al snel 20 tot 40 minuten. Bij 110 artikelen is dat minimaal 36 uur puur handmatig klikwerk. Monotoon, foutgevoelig en frustrerend. Want halverwege ga je inconsistenties introduceren. Artikel 70 wordt anders verwerkt dan artikel 3, omdat je halverwege een andere aanpak hebt gevonden, moe bent geworden, of het niet meer precies weet.
Dat is precies het soort werk waarbij projecten blijven liggen. Je start, doet 10 artikelen, merkt dat het meer tijd kost dan gedacht, en schuift het door naar “later”. Later komt niet.
Hoe AI de migratie overneemt
De aanpak die Red Factory gebruikte voor de WordPress Gutenberg editor-migraties, bestaat uit twee lagen: een AI-skill die de workflow orkestreert, en een AI-agent die het technische werk uitvoert.
Nieuwsgierig naar wat AI-automatisering concreet oplevert? Bekijk onze kennisbank over AI-automatisering voor meer voorbeelden.
De skill heeft een helder doel: zorg dat elk artikel wordt verwerkt, houd bij welke al klaar zijn, en gooi de juiste taken naar de agent op het juiste moment. Zo’n skill is een gestructureerde werkinstructie voor AI – een recept dat elke keer op dezelfde manier wordt uitgevoerd.
De agent is de uitvoerder. Die krijgt per artikel de opdracht om:
- De bestaande content op te halen uit de WordPress-database
- De structuur te analyseren: welke koppen zitten er in, welke alinea’s, zijn er lijsten of afbeeldingen?
- Een PHP-script te schrijven dat de content omzet naar correcte Gutenberg block-notatie
- Dat script uit te voeren via de WordPress server
- Te controleren of de originele tekst volledig aanwezig is in het resultaat. De ratio moet exact 1:1 zijn.
Die laatste stap – integriteitscontrole – is geen bijzaak. Als de AI een woord mist, een zin verkort of een alinea laat vallen, merkt de redacteur dat pas als iemand het artikel leest. De controle vergelijkt de tekst voor en na de conversie op tekensniveau. Als er iets niet klopt, wordt het artikel geflagd voor handmatige inspectie in plaats van stilzwijgend door te gaan.
Het proces is deterministisch: de AI detecteert automatisch de structuur in bestaande content, converteert die naar WordPress block-markup (het JSON-gebaseerde formaat dat Gutenberg gebruikt), en slaat het resultaat op. De tekst zelf wordt nooit herschreven – alleen de technische omhulling verandert.
Wat AI hier onderscheidt van een eenvoudig conversie-script: het kan omgaan met inconsistentie. Artikel 1 heeft een andere structuur dan artikel 60. De ene heeft afbeeldingen, de andere heeft geneste lijsten, de derde heeft shortcodes van een plugin die al jaren niet meer actief is. Een statisch script faalt op elk afwijkend geval. De agent past zijn aanpak aan op basis van wat hij tegenkomt.
De uitkomst: 110 artikelen, een fractie van de tijd
Wat de klant uiteindelijk had: 110 artikelen die allemaal openen in de WordPress Gutenberg editor. Geen grijs vlak, geen shortcode-rommel, geen “dit artikel kan niet worden bewerkt”-melding.
Ter vergelijking: bij handmatige conversie kost een gemiddeld artikel al snel 20 tot 40 minuten. Voor 110 artikelen loopt dat op tot minimaal 36 uur puur handmatig werk. De AI-aanpak verwerkte hetzelfde volume in een fractie van die tijd, consistent en zonder incrementele fouten.
De heading-structuur is in elk artikel consistent. De HTML-output is schoon. En de redactie kan eindelijk weer aan de slag: verouderde informatie bijwerken, artikelen samenvoegen, interne links toevoegen, of content hergebruiken voor social media en nieuwsbrieven.
Dat laatste is misschien het meest concrete voordeel. Dit bedrijf had een archief vol kwalitatief goede artikelen over hun vakgebied – jaren aan kennis – die onbenut lagen. Na de migratie is dat een actief geworden in plaats van een last.
Wat eerlijk is om te zeggen: de migratie loste niet alle problemen op. Sommige artikelen hadden inhoudelijk een update nodig. Een aantal bleek toch dunner dan verwacht als je de opmaak weghaalt. Dat is normaal. De technische conversie maakt het archief bewerkbaar – de content review is een aparte stap die daarna volgt.
Gutenberg of een page builder?
Als je overweegt om te migreren, kom je onvermijdelijk bij de vraag: moet ik dan ook stoppen met mijn pagebuilder?
Dat is genuanceerder dan een simpel ja of nee. Gutenberg is de native editor van WordPress: lichter, zonder extra afhankelijkheden, en de richting waar WordPress naartoe beweegt. Pagebuilders als Elementor of Divi zijn nog altijd populair — Elementor alleen al draait op ruim 12 miljoen WordPress-sites en heeft een marktaandeel van circa 43% onder actieve pagebuilder-gebruikers (bron: W3Techs, 2026). Ze bieden meer designvrijheid, maar voegen ook complexiteit toe: een plugin die je moet onderhouden, updaten en betalen.
De wordpress block editor vs elementor-discussie komt neer op dit: als je primair tekst-gedreven content publiceert (artikelen, kennisbankpagina’s, blogposts), is Gutenberg meer dan voldoende. Als je complexe marketingpagina’s bouwt met specifieke layoutwensen, biedt een pagebuilder nog steeds meerwaarde.
Wat steeds vaker voorkomt: bedrijven gebruiken Gutenberg voor content, en een pagebuilder alleen voor specifieke landingspagina’s. Dat is een pragmatische middenweg die lock-in beperkt en tegelijk designflexibiliteit behoudt.
De classic editor plugin wordt nog steeds ondersteund maar krijgt geen nieuwe features. Als je daar nu op draait, is dat prima voor bestaande sites – maar voor nieuwe content is overstappen naar Gutenberg blocks de logische keus.
Is dit relevant voor jouw WordPress-site?
Niet voor elke WordPress-site is een Gutenberg-migratie zinvol. Hier zijn eerlijke indicatoren.
Dit is waarschijnlijk relevant voor jou als:
- Je een archief hebt van 20 of meer artikelen die zijn gebouwd in een pagebuilder of classic editor die je niet meer actief gebruikt
- Je een contentteam hebt dat vastloopt bij het bewerken van bestaande artikelen
- Je actief aan content marketing doet en je archief wil hergebruiken of bijwerken
- Je SEO serieus neemt en merkt dat oude artikelen technisch ondermaats presteren
Het is minder relevant als:
- Je site heeft maar een handvol pagina’s en weinig of geen blog/artikel-content
- Je geen actieve contentstrategie hebt en dat ook niet van plan bent
- Je pagebuilder goed werkt en je redactie er tevreden mee is
De eerlijke vraag is: hoeveel waarde zit er in je bestaande archief? Als het antwoord is “eigenlijk best veel, maar niemand komt er aan” – dan is dat het startpunt van het gesprek.
Maak je archief bewerkbaar, geef je redactie de ruimte om te werken, en zet je bestaande content weer aan het werk. Dat is wat deze klant deed. En het was een investering die zichzelf razendsnel terugverdiende.
Hulp nodig bij het omzetten van jouw WordPress-content naar Gutenberg? Of ben je benieuwd wat AI-automatisering voor jouw site kan betekenen? Neem contact op met Red Factory en ontdek wat we voor jou kunnen doen.