Waarom technische schuld je AI-citaties kost

Technische schuld: de stille AI-killer

Technische schuld. Iedereen kent het. Niemand wil het hebben. En toch heeft bijna elke website het.

Het is de optelsom van alle kortetermijn-beslissingen die je ooit hebt genomen om iets snel te laten werken in plaats van goed. Die plugin die handig leek en nooit meer is verwijderd. De HTML die iemand in elkaar heeft geknut omdat de deadline krap was. De WordPress-versie die twee jaar achterloopt omdat de update "misschien iets zou breken".

Elke beslissing op zich? Begrijpelijk. De stapeling? Daar zit het probleem.

Ik heb in twintig jaar nog nooit een website gezien die door één slechte beslissing onherstelbaar beschadigd was. Ik heb wél vele websites gezien die door honderden kleine slechte beslissingen zo complex en fragiel waren dat niemand er meer in durfde te werken. Dat is technische schuld op zijn destructiefst.

Hoe technische schuld AI-leesbaarheid saboteert

Gebroken HTML: de chaos die niemand ziet

HTML-validators zijn saai. Ik weet het. Ik ga er geen feestje van maken. Maar een gebroken DOM is voor AI-crawlers een serieus probleem.

Niet-gesloten tags. Verkeerd genestelde elementen. Dubbele ID-attributen. Browsers compenseren daar grotendeels voor (bedankt, Chrome). Maar parsers en AI-crawlers? Die zijn een stuk minder tolerant. De structuur die jij bedoelt is niet de structuur die de machine ziet.

Bij een retailer vonden we vorig jaar 340 HTML-validatiefouten op de homepage. Driehonderdveertig. De heading-hiërarchie was volledig kapot doordat het WordPress-theme H1-tags gebruikte voor decoratieve elementen. AI-modellen konden er geen chocola van maken.

De JavaScript-lawine

Elke plugin voegt JavaScript toe. Elke JavaScript-file blokkeert potentieel de rendering. Tien onnodige plugins? Dat kan 800 KB aan extra JavaScript zijn.

AI-crawlers die geen JS uitvoeren zien een onvolledige pagina. AI-crawlers die wel JS uitvoeren wachten lang op een pagina die tergend langzaam laadt. Hoe je het ook wendt of keert: je verliest.

• Audit je plugins jaarlijks. Alles wat niet actief gebruikt wordt: eruit.
• Meet de JavaScript-payload via Chrome DevTools of WebPageTest.
• Gebruik Asset CleanUp of Perfmatters om overbodige scripts per pagina uit te schakelen.
• Overweeg voor kritieke pagina's een statische HTML-versie die altijd snel laadt.
• Stel render-blocking JavaScript uit via defer of async.

Verouderd CMS: gemiste kansen

WordPress 5.x had geen goede ondersteuning voor veel moderne schema.org-patronen. WordPress 6.x maakt het aanzienlijk eenvoudiger om structured data te genereren. Een verouderd CMS is niet alleen een beveiligingsrisico. Het beperkt ook je mogelijkheden om AI-gereed te zijn.

Ik begrijp waarom mensen updates uitstellen. Updates breken soms dingen. Dat is vervelend. Maar de prijs van niet-updaten is hoger dan de prijs van zorgvuldig updaten. Doe het in een staging-omgeving. Test grondig. En zet door.

De AEO-kosten in cijfers

Op basis van onze audits bij Kobalt herken ik een patroon. Technische schuld raakt niet één of twee AEO-checks. Het raakt de meerderheid.

1. Gebroken HTML degradeert je heading-hiërarchiescore met gemiddeld 15-25 punten.
2. Opgeblazen JavaScript verhoogt de TTFB en kost 10-20 punten op paginasnelheid.
3. Verouderde CMS-versies beperken je schema.org mogelijkheden: 10-15 punten kwijt.
4. Niet-geoptimaliseerde afbeeldingen (gevolg van ontbrekende processen) verhogen je paginagrootte.
5. Technische chaos leidt tot inconsistente canonical tags en duplicate content. AI-modellen weten niet meer welke versie de gezaghebbende is.

Aanpakken: drie fasen

Je lost technische schuld niet op in een weekend. Maar je kunt hem systematisch terugdringen. Bij Kobalt werken we in drie fasen.

Fase 1: meten en prioriteren. Breng de schuld in kaart. Niet alles heeft dezelfde impact. Focus eerst op wat AEO het meest schaadt: gebroken HTML, render-blocking JavaScript, de grootste performance-bottlenecks.

Fase 2: structureel schoonmaken. Plan elke sprint een fractie van de tijd voor schuld-reductie. Tien procent. Realistisch en meetbaar. Verwijder onnodige plugins. Fix HTML-fouten. Update dependencies.

Fase 3: preventie. Stel kwaliteitsdrempels in voor nieuwe code. HTML-validatie in je deployment-pipeline. Behandel technische schuld als wat het is: een schuld die rente oplevert naarmate hij langer blijft staan. Soms moet je gewoon een bunt leggen in plaats van een homerun slaan. Begin klein, maar begin.

Veelgestelde vragen

Technische schuld is als een lekke emmer. Je kunt blijven bijvullen, maar zolang de lekken er zijn, verlies je meer dan je erin stopt. Fix de lekken eerst.