Ik heb onlangs een WordPress-site met 3.000+ berichten gecontroleerd. De klant wilde hun inhoud in een AI-tool voeren om samenvattingen te genereren en een aanbevelingsengine mogelijk te maken. Dat zou eenvoudig moeten zijn, toch? Inhoud exporteren, doorsturen, klaar.

Maar dat was het niet. Elk bericht was een verwarde puinhoop van HTML -- shortcodes van plugins die niet meer bestonden, inline-stijlen van de klassieke editor, Gutenberg-blokcommentaren verspreid als landmijnen, en gecodeerde entiteiten die parsers deden stikken. Het "content"-veld in de database was helemaal geen inhoud. Het was een set rendereringinstructies die alleen WordPress zelf kon interpreteren. Het AI-model produceerde rommel. De klant was razend. En ik moest iets uitleggen waar meer teams naar moeten luisteren: de manier waarop je je inhoud opslaat bepaalt wat je ermee kunt doen, niet alleen vandaag, maar voor elk geval dat je nog niet hebt bedacht.

Dit is het verhaal van gestructureerde inhoud versus HTML-blobs, waarom het in 2025 belangrijker is dan ooit, en hoe het migratiepad er werkelijk uitziet.

Inhoudsopgave

Wat zijn HTML-blobs en waarom gebruikt WordPress deze

Open phpMyAdmin op een WordPress-site en kijk naar de wp_posts-tabel. Zoek naar de post_content-kolom. Wat je ziet is een enkel tekstveld met alles -- koppen, alinea's, afbeeldingen, embeds, shortcodes, blokopmaak, inline CSS -- allemaal samengeperst in één lange tekenreeks.

Hier ziet een typisch Gutenberg-bericht in de database eruit:

<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">Onze diensten</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>We bieden <strong>premium consulting</strong> voor bedrijven.</p>
<!-- /wp:paragraph -->

<!-- wp:shortcode -->
[contact-form-7 id="1234" title="Contact"]
<!-- /wp:shortcode -->

<!-- wp:image {"id":5678,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large">
<img src="/wp-content/uploads/2024/03/hero.jpg" alt="" class="wp-image-5678"/>
</figure>
<!-- /wp:image -->

Dit is een HTML-blob. Het is presentatie en inhoud verweven. De database weet niet dat "Onze diensten" een kop is, dat de afbeelding een hero-afbeelding is, of dat het contactformulier een CTA-component is. Het is allemaal gewoon... tekst in een veld.

WordPress doet dit omdat het in 2003 als blogplatform werd ontworpen. Het mentale model was eenvoudig: een bericht heeft een titel en een hoofdtekst. De hoofdtekst is HTML. Je schrijft het, WordPress rendert het. Dat model werkte prachtig voor blogs. Het breekt catastrofaal af voor moderne content-operaties.

De Gutenberg-verbetering die niet was

Gutenberg (de blok-editor) zou dit moeten oplossen. En eerlijk gezegd voegde het enige structuur toe -- die HTML-opmerkingen coderen bloktypen en kenmerken als JSON. Maar hier is het kritieke falen: die structuur leeft in de HTML-blob zelf. Het is niet opvraagbaar. Het is niet getypeerd. Het is niet gevalideerd. Je kunt de database niet vragen "geef me alle berichten waar de hero-afbeelding X is" of "vind elk bericht dat een prijstabel-blok bevat."

De blokgegevens zijn in feite metagegevens die als opmerkingen in een tekstveld zijn gecodeerd. Dat is geen structuur. Dat is een hack.

Wat gestructureerde inhoud werkelijk betekent

Gestructureerde inhoud scheidt wat iets is van hoe het eruitziet. In plaats van een HTML-blob op te slaan, definieer je een content model met discrete, getypeerde velden.

Hier ziet dezelfde inhoud eruit als gestructureerde gegevens in een headless CMS zoals Sanity:

{
  "_type": "servicePage",
  "title": "Onze diensten",
  "heroImage": {
    "_type": "image",
    "asset": { "_ref": "image-abc123" },
    "alt": "Team werkt samen aan een project"
  },
  "sections": [
    {
      "_type": "textBlock",
      "heading": "Premium Consulting",
      "body": [
        {
          "_type": "block",
          "children": [
            { "_type": "span", "text": "We bieden " },
            { "_type": "span", "text": "premium consulting", "marks": ["strong"] },
            { "_type": "span", "text": " voor bedrijven." }
          ]
        }
      ]
    },
    {
      "_type": "ctaForm",
      "formType": "contact",
      "placement": "inline"
    }
  ]
}

Merk het verschil op. Elk stukje inhoud heeft een type. De afbeelding heeft expliciete alt-tekst als een verplicht veld. Rijke tekst wordt in een draagbaar formaat opgeslagen -- niet HTML -- dat naar elke uitvoer kan worden weergegeven. Het CTA-formulier is een getypeerde verwijzing, geen shortcode-tekenreeks die breekt wanneer je een plugin deactiveert.

Dit is wat headless CMS-platforms zoals Sanity, Contentful, Storyblok en Strapi bieden. En dit is waarom ze bestaan.

Het Portable Text-voordeel

Het Portable Text-formaat van Sanity (en vergelijkbare benaderingen in andere headless CMS) slaat rijke tekst op als een reeks getypeerde objecten. Dit betekent dat je het kunt:

  • Renderen als HTML voor het web
  • Renderen als Markdown voor documentatie
  • Renderen als platte tekst voor AI-verwerking
  • Renderen als JSX voor React-componenten
  • Renderen als SSML voor spraakassistenten

Een HTML-blob geeft je één uitvoerformaat: HTML. En niet eens schone HTML -- WordPress-achtige HTML met al zijn eigenaardigheden.

Waarom AI je WordPress-inhoud niet kan lezen

Dit is het gedeelte dat in 2025 urgent wordt. AI-aangedreven tools -- van ChatGPT en Claude tot Google's AI Overviews en interne RAG-systemen (Retrieval-Augmented Generation) -- moeten je inhoud semantisch begrijpen. Ze moeten weten wat dingen zijn, niet alleen hoe ze er in een browser uitzien.

Het parse-probleem

Wanneer je proberen betekenisvolle inhoud uit een WordPress HTML-blob te extraheren, stoot je onmiddellijk op deze problemen:

  1. Shortcodes worden buiten WordPress nergens opgelost. [gallery ids="1,2,3"] is zinloos zonder de PHP-functie die het uitbreidt.
  2. Blokcommentaren zijn niet-standaard. <!-- wp:columns --> is geen webstandaard. AI-parsers weten niet wat ermee te doen.
  3. Inline-stijlen en klassen dragen geen semantische betekenis. Een <div class="wp-block-group has-background"> vertelt je niets over het doel van de inhoud.
  4. Geneste HTML-structuren zijn dubbelzinnig. Is die geneste div een zijbalk? Een callout? Een indelingscontainer? Er is geen manier om dat programmatisch te weten.
  5. Door plugins gegenereerde opmaak is onvoorspelbaar. Elke plugin injecteert zijn eigen HTML-patronen, vaak conflicterend met elkaar.

Wat dit betekent voor AI Overviews en LLMs

Google's AI Overviews (de AI-gegenereerde samenvattingen bovenaan zoekresultaten) trekken inhoud uit pagina's die gemakkelijk kunnen worden gepareerd en begrepen. Volgens onderzoek van Authoritas in begin 2025 worden pagina's met duidelijke inhoudshiërarchieën en schema-opmaak 2-3 keer vaker aangehaald in AI Overviews dan pagina's met gelijkwaardige inhoudskwaliteit maar slechte structuur.

LLMs verwerken je inhoud beter wanneer deze schoon is. Punt. Als je inhoud in opmaaksoep begraven ligt, daalt de signaal-ruis-verhouding. Het model moet raden wat inhoud en wat decoratie is. Soms raadt het fout.

RAG-systemen en interne AI-tools

Veel bedrijven bouwen in 2025 interne AI-tools die hun eigen inhoud moeten opnemen -- kennisbanken, productdocumentatie, marketingmateriaal. Als die inhoud in WordPress leeft, ziet de extractiepijplijn er als volgt uit:

  1. Query de WordPress REST API of database
  2. Ontvang HTML-blobs
  3. Strip HTML-tags (verlies alle structuur)
  4. Of parse HTML (krijg ruis gemengd met signaal)
  5. Chunk de tekst voor embeddings
  6. Hoop het beste

Met gestructureerde inhoud van een headless CMS is het:

  1. Query de API
  2. Ontvang getypeerde, gestructureerde JSON
  3. Selecteer exact de velden die je nodig hebt
  4. Chunk schoon op inhoudstype
  5. Genereer hoogwaardige embeddings

Het verschil in uitvoerkwaliteit is dramatisch. Ik heb gezien dat RAG-nauwkeurigheid met 30-40% verbeterde alleen door over te schakelen van HTML-geëxtraheerde inhoud naar gestructureerde inhoud als bron.

De werkelijke kosten van ongestructureerde inhoud

Laten we het hebben over de kosten die niet op een factuur verschijnen, maar je budget over de tijd absoluut vernietigen.

Kostenfactor WordPress HTML-blobs Gestructureerde inhoud (Headless CMS)
Inhoud hergebruiken over kanalen Handmatig kopiëren, opnieuw opmaken API-aangestuurd, automatisch
AI/ML-inhoudsverwerking Vereist parsing-pijplijn, foutgevoelig Directe JSON-consumptie
Redesign/replatform-inspanning Inhoud gekoppeld aan thema, veel inspanning Inhoud ontkoppeld, wissel frontends vrij uit
Ondersteuning voor meerdere talen Invoegtoepassing-afhankelijk, fragiel Ingebouwd, lokalisering op veldniveau
Content governance Beperkte veldvalidatie Schema-afgedwongen inhoudstypen
Mobiele app-inhoud REST API retourneert HTML-tekenreeksen Schone JSON, klaar voor native
Onboarding van ontwikkelaars Thema- en invoegtoepassing-ecosysteem-leerproces API-documentatie + inhoudsschema
Inhoudsmigratie naar nieuw platform Pijnlijk HTML-parsing Gestructureerde JSON exporteren

Elke rij in die tabel vertegenwoordigt echte uren en echt geld. Ik heb aan WordPress-naar-headless-migraties gewerkt waarbij 60% van het projectbudget ging naar inhouddtransformatie -- niet omdat het nieuwe systeem moeilijk was, maar omdat het extraheren van betekenis uit de oude HTML-blobs agoniserend was.

Headless CMS versus WordPress: Een eerlijke vergelijking

Ik ga niet pretenderen dat WordPress overal verschrikkelijk is. Dat is het niet. Laten we eerlijk zijn over wat elke aanpak goed doet.

Waar WordPress nog steeds wint

  • Omvang ecosysteem. 60.000+ invoegtoepassing. Er is een invoegtoepassing voor alles. Kwaliteit varieert wildly, maar de breedte is ongeëvenaard.
  • Vertrouwdheid van niet-technische redacteuren. De meeste content-redacteuren hebben WordPress gebruikt. De leercurve voor basistaken is bijna nul.
  • Alles-in-één eenvoud. Voor een basic brochuresite of blog krijgt WordPress je sneller van nul naar gepubliceerd dan wat dan ook.
  • Ingangskosten. Gedeeld webhosting voor 5 euro per maand, een gratis thema, en je bent live.

Waar Headless CMS wint

  • Inhoudsstructuur en modellering. Dit is het hele punt van dit artikel. Headless CMSs laten je precies bepalen hoe je inhoud als gegevens eruitziet.
  • API-eerste levering. Inhoud gaat naar websites, apps, kiosken, spraakassistenten -- overal waar een HTTP-verzoek kan worden gedaan.
  • Prestaties. Gekoppeld met een framework zoals Next.js of Astro, krijg je statische generatie, edge-caching en laadtijden onder de seconde.
  • Veiligheid. Geen PHP-uitvoering op de frontend. Geen wp-login.php om brute force aan te vallen. Het aanvalsoppervlak krimpt dramatisch.
  • AI-gereedheid. Gestructureerde inhoud is oorspronkelijk bruikbaar door AI-tools, zoekmachines en automatiepijplijnen.
  • Developer experience. Modern gereedschap, TypeScript-ondersteuning, samenwerking in realtime, versiebeheer voor inhoud.

De nuance die meeste artikelen missen

WordPress kan via WPGraphQL of de REST API als headless CMS worden gebruikt. Sommige teams doen dit. Maar je slaat nog steeds HTML-blobs op -- je serveert ze alleen via een API in plaats van ze met PHP te renderen. Het fundamentele probleem is niet veranderd. Je inhoud is nog steeds ongestructureerd.

WordPress met ACF (Advanced Custom Fields) komt dichter bij gestructureerde inhoud. Je kunt aangepaste velden maken die getypeerd en opvraagbaar zijn. Maar ACF is een invoegtoepassing die aan een systeem is geplakt dat er niet voor was ontworpen. De UX van content-modellering is onhandig, prestaties dalen met complexe veldgroepen, en je bent nog steeds afhankelijk van het WordPress-ecosysteem voor hosting, updates en veiligheid.

WordPress-beperkingen die in de loop der tijd samenvoegen

Dit zijn geen theoretische problemen. Dit zijn dingen die ik op echte projecten heb zien breken.

Invoegtoepassing-afhankelijkheidshel

Een typische WordPress-site gebruikt 20-40 invoegtoepassing. Elk ervan kan conflicteren met anderen. Elk ervan moet worden bijgewerkt. Elk ervan is een potentieel veiligheidsprobleem. Wanneer een invoegtoepassing wordt verlaten (wat voortdurend gebeurt), zit je vast met shortcodes in je inhoud die als letterlijke tekst worden weergegeven.

Ik controleerde vorig jaar een site die [tabs] shortcodes in 800 berichten had. De tabsinvoegtoepassing was sinds 2021 niet meer bijgewerkt. De inhoud werd gegijzeld door dode code.

De monolithische architectuurtaks

WordPress behandelt routering, rendering, inhoudopslag, authenticatie, mediabeheer en invoegtoepassing-uitvoering in één PHP-proces. Dit betekent:

  • Je kunt de content-API niet onafhankelijk van de beheerdersinterface schalen
  • Een verkeerspiep hit dezelfde server die editor-sessies afhandelt
  • Databasequery's voor inhoudsopvraging concurreren met invoegtoepassing-bewerkingen
  • Je kunt frontend-wijzigingen niet implementeren zonder de WordPress-server aan te raken

Moderne headless CMS-architecturen scheiden deze zorgen volledig. De content-API schaalt onafhankelijk. De frontend implementeert naar edge-netwerken. Redacteuren werken in een toegewijde studio die geen resources deelt met openbaar verkeer.

Content Lock-In waarover niemand spreekt

Hier is het vuile geheim: WordPress-inhoud is theoretisch draagbaar maar praktisch vergrendeld. Zeker, je kunt XML exporteren. Maar die XML bevat HTML-blobs met shortcodes, plugin-specifieke opmaak en WordPress-interne verwijzingen. Verplaatsen naar een ander systeem vereist een parse- en transformatie-inspanning die lineair met inhoudvolume en -complexiteit schaalt.

Gestructureerde inhoud in een headless CMS exporteert als JSON. Schone, getypeerde, voorspelbare JSON. Overschakelen van Sanity naar Contentful (of vice versa) vereist inhoudstypemapping, geen HTML-parsing.

Het migratiepad: Van blobs naar structuur

Als je op een WordPress-site zit en dit artikel maakt je ongemakkelijk, prima. Laten we het hebben over wat we gaan doen.

Stap 1: Controleer je inhoud

Voordat je iets aanraakt, begrijp wat je hebt. Voer query's uit tegen je database:

-- Vind alle shortcodes in gebruik
SELECT DISTINCT
  REGEXP_SUBSTR(post_content, '\\[[a-zA-Z_-]+') AS shortcode,
  COUNT(*) AS usage_count
FROM wp_posts
WHERE post_status = 'publish'
  AND post_content REGEXP '\\[[a-zA-Z]'
GROUP BY shortcode
ORDER BY usage_count DESC;

Documenteer elke shortcode, elk aangepast blok, elke ACF-veldgroep. Deze inventaris stuurt je contentmodel-ontwerp.

Stap 2: Ontwerp eerst je content model

Kies geen CMS en bereken dan je model. Ontwerp het model op basis van je inhoudbehoeften, kies dan de CMS die het beste ondersteunt.

Stel jezelf deze vragen:

  • Wat zijn de verschillende inhoudstypen? (Blogbericht, casestudy, productpagina, teamlid...)
  • Welke velden heeft elk type nodig?
  • Wat zijn de relaties tussen typen?
  • Wie moet wat bewerken?
  • Waar moet deze inhoud verschijnen? (Web, app, e-mail, AI-tools...)

Stap 3: Bouw de transformatie-pijplijn

Dit is waar het zware werk gebeurt. Je moet HTML-blobs in gestructureerde gegevens omzetten. Tools die helpen:

  • Aangepaste Node.js-scripts met cheerio of unified/rehype voor HTML-parsing
  • Sanity's migratiegereedschap voor het importeren van gestructureerde inhoud
  • Contentful's CLI voor migratie voor programmatisch content-maken
  • OpenAI of Claude-API's voor AI-ondersteunde inhoudsclassificatie (serieus -- gebruik AI om je inhoud tijdens migratie in te delen en te categoriseren)
// Voorbeeld: WordPress HTML converteren naar Portable Text
import { htmlToBlocks } from '@sanity/block-tools'
import { Schema } from '@sanity/schema'

const defaultSchema = Schema.compile({ /* jouw schema */ })
const blockContentType = defaultSchema
  .get('post')
  .fields.find(field => field.name === 'body').type

const blocks = htmlToBlocks(
  '<p>Jouw <strong>WordPress</strong> HTML hier</p>',
  blockContentType
)

Stap 4: Draai parallel

Voer geen big-bang-migratie uit. Voer WordPress en je nieuwe headless CMS parallel uit. Migreer inhoud in batches. Valideer elke batch. Bouw de nieuwe frontend tegen de headless CMS-API terwijl de oude site live blijft.

Dit is de aanpak die we gebruiken op onze headless CMS-projecten. Het is meer werk vooraf, maar reduceert het risico dramatisch.

Stap 5: Redirect en deactiveer

Zodra de nieuwe site live is en gevalideerd, stelt u 301-omleidingen in, controleert u 404's en sluit u WordPress af. Bewaar een databaseback-up voor altijd -- je weet nooit wanneer je naar oude inhoud moet verwijzen.

De juiste Headless CMS kiezen

De markt is aanzienlijk gerijpt. Hier ziet de vergelijking van de grote spelers in 2025 eruit:

CMS Content-modellering Prijsstelling (begin) Het beste voor AI-functies
Sanity Uitstekend -- code-gedefinieerde schema's Gratis laag, dan €99/mnd (Growth) Aangepaste content-modellen, developer-teams Sanity AI Assist ingebouwd
Contentful Sterk -- UI-gebaseerde modellering Gratis laag, dan €300/mnd (Team) Enterprise content-operaties Voicetoepassing voor AI-content-generatie
Storyblok Goed -- focus op visueel bewerken Gratis laag, dan €106/mnd (Business) Marketing-teams die visuele voorvertoning nodig hebben AI-aangedreven content-creatie
Strapi Goed -- zelf-gehost flexibiliteit Gratis (zelf-gehost), Cloud vanaf €29/mnd Teams die volledige controle willen Community-plugins
Payload CMS Uitstekend -- code-first, TypeScript-native Gratis (zelf-gehost), Cloud komt 2025 Developer-zware teams, Next.js-projecten Uitbreidbaar via plugins

Er is geen universele beste keuze. Het hangt af van je team, je content-complexiteit en je budget. Als je hulp nodig hebt bij het evalueren van opties, hebben we deze analyse voor tientallen teams gedaan.

Veelgestelde vragen

Wat is gestructureerde inhoud en waarom is het belangrijk voor SEO? Gestructureerde inhoud slaat informatie op als getypeerde, gelabelde gegevensvelden in plaats van onbewerkte HTML. Voor SEO is dit belangrijk omdat zoekmachines -- vooral Google's AI-aangedreven systemen -- gestructureerde inhoud nauwkeuriger kunnen begrijpen en aanhalen. Pagina's die zijn gebouwd op gestructureerde inhoud hebben meestal schonere HTML-uitvoer, juiste koppiëhiërarchieën en consistentere schema-opmaak, allemaal rankingsignalen in 2025.

Kan WordPress als headless CMS worden gebruikt? Technisch gezien ja. WordPress heeft een REST API en kan met WPGraphQL worden uitgebreid. Maar het kernprobleem blijft: je inhoud wordt nog steeds in de database als HTML-blobs opgeslagen. Het gebruik van WordPress headless geeft je API-toegang tot ongestructureerde inhoud. Je krijgt de headless-architectuurvoordelen (frontend-flexibiliteit, betere prestaties) zonder de voordelen van gestructureerde inhoud. Voor sommige teams is dat een acceptabele afweging. Voor de meeste niet.

Hoeveel kost het om van WordPress naar een headless CMS te migreren? Het varieert enorm op basis van inhoudvolume en -complexiteit. Een kleine site met 50-100 pagina's schone inhoud kan 2-4 weken ontwikkelingsinspanning kosten. Een grote site met duizenden berichten, aangepaste berichttypes, ACF-velden en shortcode-zware inhoud kan 2-4 maanden duren. Het werk voor inhouddtransformatie -- het omzetten van HTML-blobs in gestructureerde gegevens -- is meestal 40-60% van de totale inspanning. Controleer onze prijspagina voor globale ramingen op headless CMS-projecten.

Zal AI Overviews mijn WordPress-site lager rangschikken? Niet rechtstreeks -- Google straft WordPress-sites niet. Maar AI Overviews en vergelijkbare functies geven de voorkeur aan inhoud die gemakkelijk kan worden gepareerd en begrepen. Sites met schone, goed gestructureerde HTML (wat gestructureerde inhoud natuurlijk oplevert) worden vaker aangehaald. Een rommelige WordPress-pagina met door-plugin gegenereerde opmaak, inline-stijlen en verbroken shortcodes is voor elk AI-systeem moeilijker betrouwbaar te verwerken.

Wat gebeurt er met mijn WordPress-inhoud als ik een invoegtoepassing deactiveer? Alle shortcodes van die invoegtoepassing worden als letterlijke tekst in je berichten weergegeven. Als je bijvoorbeeld een galerij-invoegtoepassing deactiveert, zien je bezoekers [gallery ids="1,2,3"] als platte tekst op de pagina. Invoegtoepassing-gebaseerde blokken kunnen achter gebroken HTML of lege containers achterlaten. Dit is een van de meest voorkomende -- en meest frustrerende -- WordPress-inhoudsproblemen. Gestructureerde inhoud in een headless CMS heeft dit probleem niet omdat inhoud en presentatie volledig gescheiden zijn.

Wordt Gutenberg (de WordPress-blok-editor) als gestructureerde inhoud beschouwd? Het is een stap naar structuur, maar het voldoet niet. Gutenberg-blokken coderen typeinformatie in HTML-opmerkingen in de post_content-blob. Deze metagegevens worden niet in afzonderlijke databasevelden opgeslagen, zijn niet opvraagbaar via SQL en zijn niet gevalideerd tegen een schema. Het is meer gestructureerd dan de klassieke editor, maar fundamenteel anders van ware gestructureerde inhoud zoals geïmplementeerd door headless CMSs zoals Sanity of Contentful.

Welke headless CMS is het best voor Next.js-projecten? Sanity en Payload CMS zijn de sterkste opties voor Next.js-ontwikkeling in 2025. Sanity biedt uitstekende realtime-voorvertoningsfuncties en een volwassen ecosysteem. Payload CMS is vooral interessant omdat het TypeScript-native is en in een Next.js-toepassing zelf kan worden uitgevoerd. Contentful en Storyblok hebben ook solide Next.js-integraties. De "beste" keuze hangt af van of je prioriteit geeft aan flexibiliteit in content-modellering, visueel bewerken, zelf-hosting of enterprise-functies.

Hoe maak ik mijn inhoud AI-gereed zonder volledige migratie? Als een volledige migratie nu niet haalbaar is, kunt u stappen ondernemen. Voeg JSON-LD-gestructureerde gegevens toe aan je WordPress-pagina's met behulp van een invoegtoepassing zoals Yoast of RankMath. Ruim shortcode-gebruik op -- vervang deze waar mogelijk door native Gutenberg-blokken. Bouw een content-API-laag met ACF en WPGraphQL die belangrijke velden als gestructureerde gegevens beschikbaar stelt. Deze stappen geven je geen echte gestructureerde inhoud, maar verbeteren wel AI-leesbaarheid terwijl je een juiste migratie plant.