The Bugs We Found by Auditing Our Own Site

If you sell website audits, your own site is the one audit you cannot fail. That is the obvious reason, and it is the less interesting one. The useful reason is that an audit tool pointed at a site nobody controls can be wrong for months without anyone noticing: a false finding looks exactly like a true one until someone who knows the answer reads it.

We know the answer for exactly one site. So a scheduled job runs the real 18-analyzer pipeline against webauditsuite.com every Monday morning and fails the build if it reports anything at medium severity or worse that we have not written down a reason for carrying. The allowlist it checks against lives in the repository, one entry per finding, each with a reason and a date. It is a record of what we accept, not a mute button: an entry with no reason does not pass review, and the job reports every allowed finding by name on every run.

The job catches two different things at once, which is the part worth copying. When our site regresses, the finding is true and we fix the site. When our analyzers regress, the finding is false and we fix the product — and because we can see the source of the page being audited, we are the only people in a position to tell the difference. Three times now the answer has been the second one.

The first dogfood run, on 6 July 2026, said our home page was missing Organization schema, missing FAQ schema, and missing an organization logo. All three were in the page source. We could open the tab and read them.

Our structured data is emitted the way most sites emit it: one application/ld+json block containing a @graph array, with the Organization, SoftwareApplication and FAQPage entities inside it. The analyzer read the @type at the top level of each block. At the top level of a @graph document there is no @type at all — it is a container, not an entity — so the analyzer saw a block it could not identify and concluded the entities were absent.

That container is not an unusual choice. It is what Yoast SEO emits by default on WordPress; Yoast's own developer documentation describes rendering a @graph object in JSON-LD as the core of their approach. Which means the false finding was not about us. Every Yoast-shaped site we had audited would have been told to add structured data it already had.

The fix flattens syntactic containers — a @graph, or a top-level array — before looking for entities, and stops short of nested properties, so "has Organization schema" keeps meaning what it says rather than matching an Organization mentioned inside something else. Array-valued types like ["Organization", "LocalBusiness"], which had been crashing the type comparison outright, got handled in the same pass. It shipped the same afternoon as 9c7921e with nine regression tests, and the AI-readiness findings on our own site dropped from five to two. The two that remained were true.

The same run reported a duplicate title on our home page. There is only one home page, so this one was quicker to diagnose and had a wider blast radius.

The crawler seeded its queue with the URL as typed, then normalised every link it discovered afterwards through the browser's own URL resolution. Type webauditsuite.com and the seed stays webauditsuite.com, while the logo in the header — a link to / — resolves to webauditsuite.com/. Two strings, one page, crawled twice, and the second copy has the same <title> as the first.

Any site whose header logo links home would have collected that finding, which is close to every site there is. dc1fd0c normalises the seed exactly the way discovered links are normalised, applies the same treatment to URLs read out of a sitemap, and pins it with a regression test. The lesson we took from it is narrower than "normalise your URLs": the bug existed because two code paths that had to agree were written in different places, and only one of them was ever tested.

The most recent one is a day old at the time of writing, and we caused it ourselves.

On 2 August 2026 we shipped a free AI-visibility checker. Its page explains what a crawler reads, and to make that concrete it links to our own robots.txt. Reasonable page. The next self-audit came back with eleven findings, one of them the first high-severity finding our own site had ever produced.

Five of the eleven were about /robots.txt: it had no title (high), no meta description, no canonical tag, no Open Graph tags, and it was not listed in our sitemap. Every one of those is true. None of them is a defect. It is a text file, and text files are not supposed to have title tags.

The crawler followed the link, got a 200 OK, and filed the response as a page without ever looking at the Content-Type header. Everything downstream did its job correctly on a document that should never have reached it — which is the shape of most analyzer bugs worth finding, and the reason the fix belongs at the crawl boundary rather than in five different checks.

The guard is four lines: if the response is not text/html or application/xhtml+xml, the URL is a link but not a page. It stays in the link graph, so a broken PDF link is still reported as a broken link; it just never reaches the analyzers that ask about titles. Two deliberate exceptions: a response with no Content-Type at all is treated as HTML, because omitting the header is a misconfiguration rather than evidence of a binary, and the URL the operator actually typed is always analysed, because handing the analyzers an empty crawl is a worse failure than handing them a bad one. Same-day fix, pinned by tests for the guard and for every content type it has to judge, and the run went from eleven findings to six with no high-severity finding left.

A case study that ends at zero findings is a case study that stopped being honest somewhere in the middle. The run on 2 August 2026 — the same run described above, after the crawl fix — reported six findings. None is high severity. Two are medium, and we are carrying both on purpose.

The first is a warning that the site uses a lot of inline styles: 58 of them on that run. They come from the animation library and from React style props, which is how the framework works, and moving them to a stylesheet would mean giving up the animation. The finding is a fair description of the page. We disagree with the recommendation, and the allowlist entry says so.

The second is that our navigation links to five paths our own robots.txt disallows — sign-in, the audit workspace, the account page, password reset, and the developer route that redirects into signup. That is a real signal and worth reporting: a link a crawler can see but not follow is usually a mistake. Here it is not. Those pages are behind authentication or redirect somewhere else, so crawl budget spent on them is wasted, and the alternative — putting rel="nofollow" on every navigation link — buys nothing. It failed our own build the first Monday it appeared, which is exactly what the job is for; we read it, decided, and wrote the reason down.

The four low-severity findings are the ordinary tail: no X-XSS-Protection header, which modern browsers ignore in favour of a content-security policy; two oversized images on the home page; two legacy app-icon tags we do not emit; and a low readability score on marketing copy, which is what marketing copy scores. They are on the list. They are not urgent, and the report is right that they exist.

The three bugs above have one thing in common: none of them could have been found by testing the analyzers against fixtures we wrote ourselves. Each needed a real site whose correct answer we already knew. That is the whole argument for auditing yourself on a schedule, and it is cheap — ours is one scheduled job and an allowlist file.

If you want the AI-readiness half of it without an account, the free AI-visibility checker runs the same analyzer this page keeps talking about: how your robots.txt treats each AI crawler, whether you serve an llms.txt and a sitemap, and what your structured data declares. One URL, no signup. If you want to know what it is checking before you run it, how to check if your site is AI ready walks through every step by hand, and the 18 checks we run documents the full audit, scoring formulas included.

And if it tells you something about your site that is wrong, we would genuinely like to know. Three of the fixes described here started exactly that way.