Back to News & Insights
Web Development September 25, 2026 · 5 min read

I Built a Website Intelligence Engine Instead of Another SEO Checklist

What I learned while building AuditForge AI: why crawling, rendering, shared resource intelligence,...

I Built a Website Intelligence Engine Instead of Another SEO Checklist

What I learned while building AuditForge AI: why crawling, rendering, shared resource intelligence, evidence, and root-cause analysis matter more than a long list of SEO checks. Most website auditors give you a checklist.

Then you get a long list of warnings and have to figure out what actually matters.

What if a website auditor tried to understand the website before deciding what is wrong with it?

A website issue rarely exists by itself Consider a JavaScript-heavy page. A basic auditor might report several separate problems: content is not present in the initial HTML indexability may be uncertain structured data may not match the rendered page accessibility checks based only on static HTML may miss something the page may also have a performance problem Those warnings are not necessarily five independent problems. They can be different symptoms of the same underlying condition. That led me toward a different model:

The goal is not to hide individual findings. It is to understand their relationships. From individual checks to a shared pipeline The architecture gradually became closer to:

The important part is that the engines are not supposed to behave like completely isolated tools. They share evidence. That matters because the crawler may know something that the schema engine needs, or the resource layer may know something that the indexability engine needs. Static HTML is not always enough One of the biggest decisions was separating static analysis from browser analysis. Static HTML can tell us a lot. But it cannot reliably answer every question about a JavaScript application. So the system has separate rendering modes:

This kind of provenance is important. Otherwise an audit can accidentally present a browser-derived conclusion as though it came from the original HTML response. A website is more than its HTML A serious audit may need to understand resources such as:

Instead of letting every engine rediscover the same resources independently, I wanted a shared site-resource intelligence layer. The basic idea is:

This makes reconciliation possible. A resource should also have a useful state. For example:

That is more useful than a simple found: true. Crawlability and indexability are different This was another important lesson. A page can be crawlable without being indexable. For example:

Those are two different signals. Likewise, a 200 response does not automatically mean a page should be considered a healthy indexable page. The system therefore treats indexability as a state derived from several pieces of evidence. The model uses states such as:

The goal is to avoid reducing a complicated website state to a single boolean. Context matters One of the easiest ways for an auditing tool to create noise is to apply every check to every page. A homepage, an article, a login page, a checkout flow, a utility page, and a legal page do not necessarily have the same expectations. That means a finding should be able to distinguish between:

This principle affects SEO, accessibility, content, structured data, and AI visibility. A missing signal is not automatically a failure. Findings should contain evidence A useful finding should answer more than: "Your page has a problem." It should answer:

This is also important for AI-assisted development. An AI coding assistant has much more useful information when it receives:

than when it receives: "Improve accessibility." Scoring should follow evidence Another thing I learned is how easy it is for a scoring system to become misleading. Suppose a browser-only metric cannot be measured. That should not automatically mean:

Likewise, an optional improvement should not automatically behave like a hard failure. I prefer score changes to require stronger evidence:

Everything else should remain clearly distinguishable as advisory or informational. A clean website should be able to reach a clean score without being penalized simply because an unavailable measurement was unavailable. Performance needs measured evidence Performance analysis creates a similar problem. There is a big difference between:

is much weaker if that saving has not actually been measured. So an audit system should be explicit about evidence quality:

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation