Why technical debt costs you AI citations
Technical debt: the silent AI killer
Technical debt. Everyone knows it. Nobody wants it. And yet almost every website has it.
It is the sum of all the short-term decisions you ever made to make something work quickly rather than properly. That plugin that seemed handy and was never removed. The HTML someone hacked together because the deadline was tight. The WordPress version that is two years behind because the update "might break something".
Each decision on its own? Understandable. The accumulation? That is where the problem lies.
In twenty years I have never seen a website irreparably damaged by one bad decision. I have seen many websites that, through hundreds of small bad decisions, had become so complex and fragile that nobody dared work in them anymore. That is technical debt at its most destructive.
During an audit last year at a law firm we found a WordPress installation with 74 plugins. Actively in use: 12. The remaining 62 were remnants of old campaigns, tests and forgotten functionalities. Homepage weight: 11.4 MB. AEO score: 18 out of 100. Ouch.
How technical debt sabotages AI readability
Broken HTML: the chaos nobody sees
HTML validators are boring. I know. I am not going to pretend otherwise. But a broken DOM is a serious problem for AI crawlers.
Unclosed tags. Incorrectly nested elements. Duplicate ID attributes. Browsers largely compensate for these (thanks, Chrome). But parsers and AI crawlers? They are far less tolerant. The structure you intend is not the structure the machine sees.
At a retailer last year we found 340 HTML validation errors on the homepage. Three hundred and forty. The heading hierarchy was completely broken because the WordPress theme used H1 tags for decorative elements. AI models could not make sense of it.
The JavaScript avalanche
Every plugin adds JavaScript. Every JavaScript file potentially blocks rendering. Ten unnecessary plugins? That can be 800 KB of extra JavaScript.
AI crawlers that do not execute JS see an incomplete page. AI crawlers that do execute JS wait a long time for an agonizingly slow page. Either way: you lose.
- Audit your plugins annually. Everything not actively used: remove it.
- Measure JavaScript payload via Chrome DevTools or WebPageTest.
- Use Asset CleanUp or Perfmatters to disable unnecessary scripts per page.
- Consider a static HTML version for critical pages that always loads quickly.
- Defer render-blocking JavaScript using defer or async.
Outdated CMS: missed opportunities
WordPress 5.x had no good support for many modern schema.org patterns. WordPress 6.x makes it significantly easier to generate structured data. An outdated CMS is not just a security risk. It also limits your ability to be AI-ready.
I understand why people postpone updates. Updates sometimes break things. That is annoying. But the price of not updating is higher than the price of updating carefully. Do it in a staging environment. Test thoroughly. And push through.
The AEO cost in numbers
Based on our Kobalt audits I recognize a pattern. Technical debt does not affect one or two AEO checks. It affects the majority.
- Broken HTML degrades your heading hierarchy score by an average of 15-25 points.
- Bloated JavaScript increases TTFB and costs 10-20 points on page speed.
- Outdated CMS versions limit your schema.org capabilities: 10-15 points lost.
- Non-optimized images (result of missing processes) increase your page size.
- Technical chaos leads to inconsistent canonical tags and duplicate content. AI models no longer know which version is authoritative.
Tackling it: three phases
You do not solve technical debt in a weekend. But you can systematically reduce it. At Kobalt we work in three phases.
Phase 1: measure and prioritize. Map out the debt. Not everything has the same impact. Focus first on what harms AEO most: broken HTML, render-blocking JavaScript, the biggest performance bottlenecks.
Phase 2: structurally clean up. Plan a fraction of time for debt reduction in every sprint. Ten percent. Realistic and measurable. Remove unnecessary plugins. Fix HTML errors. Update dependencies.
Phase 3: prevention. Set quality thresholds for new code. HTML validation in your deployment pipeline. Treat technical debt for what it is: a debt that earns interest the longer it remains. Sometimes you just need to lay down a bunt instead of swinging for a home run. Start small, but start.
Use the W3C Markup Validation Service (validator.w3.org) to validate your HTML. Every error there is a potential problem for AI crawlers. Aim for zero errors on your most important pages.
Frequently asked questions
How do I know how much technical debt my website has?
A combination of tools gives a good picture. W3C Markup Validator for HTML errors, Lighthouse for performance and best practices, Screaming Frog for technical SEO issues and your own CMS dashboard for outdated plugins. More than 50 Lighthouse warnings or more than 100 HTML errors? Then the debt is serious.
Is it better to rebuild or improve the existing site?
Depends on the severity and migration costs. If every improvement is hindered by the complexity of the existing code, a rebuild may be more efficient. But in most cases, structural cleanup is the better choice. You retain your SEO history, your link profile and your content. That is valuable.
Does technical debt affect all AI models equally?
The impact differs per system and per type of debt. Broken HTML affects all crawlers. Render-blocking JavaScript hits crawlers that execute JS harder than those that do not. Outdated CMS versions primarily limit your structured data capabilities. The common thread: the worse the technical quality, the more negative the impact on all AI models.
Technical debt is like a leaky bucket. You can keep refilling it, but as long as the leaks are there, you lose more than you put in. Fix the leaks first.
How does your website score on AI readiness?
Get your AEO score within 30 seconds and discover what you can improve.
