Waarom je CMS je AI-score bepaalt

Bij Kobalt open ik regelmatig de broncode van klantwebsites. Soms moet ik echt even ademhalen. De content is uitstekend. De HTML die het CMS ervan maakt? Een ramp. En als ik er al moeite mee heb na twintig jaar webdevelopment, verwacht dan niet dat een AI-crawler de structuur begrijpt.

WordPress: krachtig maar rommelig zonder discipline

Laat ik beginnen met de olifant in de kamer. WordPress draait op 43% van het web. Dat is indrukwekkend en ook een beetje angstaanjagend.

De vrijheid van WordPress is zijn kracht en zijn zwakte. Iedereen kan een plugin installeren, een pagebuilder toevoegen en markup genereren die geen enkel systeem begrijpt. Ik heb WordPress-sites gezien met 47 actieve plugins. Zevenenveertig. Daar word ik een beetje stil van.

• Gutenberg genereert redelijk schone HTML, mits je er niet te veel plugins overheen stapelt.
• Elementor, Divi en WPBakery zijn performance- en markup-rampen. Bergen inline CSS, geneste divs, shortcodes. Ik word er niet vrolijk van.
• Yoast en Rank Math maken Schema.org toegankelijk, maar de output is generiek en soms overbodig.
• Themes varieren enorm. Een premium theme van een goede ontwikkelaar is een wereld van verschil met een gratis theme van onbekende herkomst.
• Caching-plugins zijn noodzaak, geen luxe. Zonder cache is WordPress bijna altijd te traag voor AI-bots.

Mijn conclusie over WordPress: het kan prima. Maar je hebt discipline nodig. Gebruik de blok-editor, geen pagebuilders. Kies een lichtgewicht theme. Installeer alleen noodzakelijke plugins. Valideer je HTML-output regelmatig. Dat klinkt als een checklist, maar het is meer een levenshouding.

Headless CMS: de belofte en de valkuil

Contentful, Sanity, Strapi: de developer-community is er gek op. Content in een gestructureerde API, frontend volledig in eigen hand. Schone HTML, snelle builds, volledige controle.

In theorie perfect voor AI-leesbaarheid. In de praktijk zie ik twee valkuilen waar teams keer op keer intrappen.

1. Next.js en andere React-frameworks renderen standaard client-side. Geen SSR of static generation geconfigureerd? Dan krijgen AI-crawlers een lege HTML-shell. Je bent dan slechter af dan met WordPress. Laat dat even tot je doordringen.
2. De vrijheid van headless betekent dat Schema.org, Open Graph tags en robots.txt volledig handmatig moeten worden gebouwd. Teams zonder sterke SEO-kennis vergeten dit regelmatig. En dan heb je een prachtige frontend die voor AI-modellen een lege doos is.

Laravel en custom oplossingen: de bovenkant van het spectrum

Ik ben bevooroordeeld, dat geef ik toe. Bij Kobalt bouwen we veel op Laravel. Maar er zijn inhoudelijke redenen die verder gaan dan "dit kennen we het beste".

Een Laravel-applicatie met Blade-templates genereert standaard server-rendered HTML. Geen JavaScript-framework dat per ongeluk je content achter een hydration-muur plaatst. Je schrijft de HTML die je wilt, en dat is wat crawlers zien. Schema.org implementeer je precies zoals jij het wilt. Geen plugin die het "voor je regelt" op een manier die je niet helemaal begrijpt.

Het nadeel is evident: custom development kost meer. Voor een marketingsite van een klein bedrijf is dat niet altijd te rechtvaardigen. Maar voor organisaties waar AI-zichtbaarheid serieus meetelt in de funnel? Dan is die investering in schone, beheersbare code absoluut de moeite waard.

De beste CMS-keuze is de keuze waarbij je team de discipline kan opbrengen om schone HTML te produceren. Een perfect geconfigureerde WordPress-site verslaat een slordig gebouwd Laravel-project. Altijd. Wil je weten hoe schoon jouw HTML is? Doe de gratis AEO-scan.

Veelgestelde vragen