AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.
Three of our own published articles failed the same gate, for the same reason, and had been failing it since the day they went live. We found them by pointing our own content audit skill at ebizapple.com — our product, our site, no client to blame. The uncomfortable part was not the count. It was that all three had cleared three separate layers of review before publication. Nobody had been careless. Every reviewer had looked at the right thing, at a moment when the thing was still right.
We assumed a preflight covered this
Our pre-publish check governs the same house rules. It reads a draft, applies the thresholds, and refuses anything that violates them. It had worked on all three of these articles. So our first theory was that the gate had a hole in it, and we went looking for the missing rule.
There was no missing rule. The preflight and the sweep agreed on every threshold. What they disagree about is when they look.
A preflight sees one draft once; a catalog keeps moving
A preflight examines a single draft at the instant it is written, and after it returns PASS it never sees that page again. The page, however, goes on having a life. Somebody edits it. A template changes underneath it. An internal working note — a reference code, a scenario identifier, a filesystem path, a word from the team’s own working vocabulary — survives an edit and ends up in public copy. And rules change: ours did, after roughly half the catalog was already published, which means half the catalog was gated against a standard that no longer exists and no gate will ever re-ask.
None of that is a defect in the preflight. It is the category of thing a preflight structurally cannot know, because the defect did not exist when the preflight ran. A content audit is the retrospective counterpart: the same rules, asked again, of pages nobody is currently writing. Grouping the findings by check rather than by page is what turned three articles into one root cause instead of three coincidences — by page, a systematic defect reads as a run of unrelated bad luck.
The trap we walked into: the content audit measured its own data model
Then we built the checker, and the checker was wrong in a way that is worth more than the three findings it was built to catch.
Our first version read the stored content — what the content API returns — and applied the title rule to that. It passed a page whose stored title was 60 characters against a 60-character limit. The page rendered at 72. A twelve-character suffix is appended by the rendering layer on some pages and overridden on others, so the stored value and the emitted value are simply different strings, and the rule governs the emitted one.
What made this land was who caught it. On 15 August 2026 we ran the same task with a plain agent carrying no checker at all. It fetched the live page and measured the title the page actually emits, and it found the defect our instrumented run had measured past. The unequipped agent looked at the reader’s surface because it had nothing else to look at. Ours had a convenient internal representation and trusted it.
That is the mechanism, and it generalises well past titles: a content audit that does not measure what the reader actually sees is measuring its own data model. It will be confident, fast, reproducible, and describing a document no visitor has ever loaded. A checker in that state is worse than no checker, because it also produces a clean report that stops anyone from looking.
Some things the stored text cannot express at all
The stored representation does not merely transform some values; for others it holds nothing at all. Image weight, lazy-loading behaviour, schema markup as it is finally emitted, sitemap freshness — none of these are recoverable from the editable content, at any level of cleverness. They are properties of a rendered page and of a running site.
The honest move is to declare them out of scope. The dishonest move, and the tempting one, is to derive a plausible proxy from what the store does hold and report it in the same voice as a measurement. A reader cannot tell those apart, which is exactly why they must be labelled apart: a value measured directly is a finding, and a value that depends on something the system never recorded is an inference and must arrive carrying the link needed to confirm it. Reporting an inference as a measurement is the same error one level down from the one we already made.
What follows if you are auditing your own catalog
Establish empirically, on one live page, whether the rendering layer transforms the value your rule governs, before you trust a single length or presence result. Say what fraction of the catalog you swept, because a clean sweep of part of a catalog is not a clean catalog and the sentence that blurs the two is the one that does the damage. Compare what you analysed against the collection total the system reports, so a failed fetch page surfaces as a shortfall instead of vanishing into a confident remainder. And run the thing against a deliberately broken record first: a check that has never refused anything is not evidence of health, it is an untested claim.
The runnable procedure — scoping, paging, where the rendered comparison goes, and how findings are split by certainty — lives in the member library.
How we know
What Google’s documentation says about the page a crawler sees
Google’s own documentation draws the same line we tripped over: there is the HTML a server sends, and there is the page after it has been processed. Its JavaScript guide explains that Google handles JavaScript web apps in three main phases, crawling, rendering and indexing. When resources allow, a headless Chromium renders the page and executes the JavaScript, and Google then uses the rendered HTML to index the page. A check that reads only stored content is reading something earlier in that chain than search does.
Titles are a good example of why the final output matters. Google’s title link guide says to make sure every page on your site has a title specified in the title element, but it also says that generation of title links on the Google Search results page is completely automated. The element you emit is an input, not a guarantee.
Meta descriptions have a similar rule about repetition. Google’s snippet documentation warns that identical or similar descriptions on every page of a site are not helpful when individual pages appear in results. That is a property of the whole catalog, which only a sweep across many pages can test.
Google’s guidance on helpful content adds questions that read like audit criteria. It asks whether content provides original information, reporting, research, or analysis, and it asks site owners whether they are changing the date of pages to make them seem fresh when nothing of substance changed. Neither question can be settled at the moment of writing. Both depend on what the page looks like months later.
How this matches what our sweep found
The three articles in our self-audit had passed every layer of review before publication. The documentation explains why that was not enough. A preflight sees one draft once, while the page keeps changing, and our house rules changed after roughly half the catalog was live.
Our first checker passed a title at 60 stored characters that rendered at 72. Google’s description of rendering is the general version of that mistake: the value that counts is the one produced at the end, not the one sitting in storage. The plain agent that fetched the live page found it because it measured the emitted title tag.
We also declared image weight, lazy loading, emitted schema and sitemap freshness out of scope for a store-only check. The JavaScript guide supports that call. Those are properties of a rendered page and a running site, and a proxy derived from stored text should be labelled as an inference.
A short audit checklist
- Fetch one live page and compare its emitted title with the stored title before trusting any length result.
- Do the same for the meta description, then check the whole set for duplicates.
- Record how many pages you swept against the total the system reports.
- Group findings by rule, not by page, so a shared cause shows up as one finding.
- Label each result as measured or inferred, and attach the link needed to confirm an inference.
- Re-run the sweep after any rule change, since older pages were gated against the old rule.
- Run the checker against a deliberately broken record first and confirm it fails.
More questions
Can I audit titles from my CMS export alone?
Only if you have confirmed that the rendering layer does not change them. In our case it appended a suffix on some pages, so the stored value and the emitted value were different strings. Check one live page first.
How often should a catalog be audited?
Our rule of thumb from this run: whenever the rules change, and whenever templates change. A rule change leaves every earlier page checked against a standard that no longer exists, and no preflight will ask again.
Grounded in: our own live self-audit of ebizapple.com, where three published articles failed the same gate for the same unnoticed reason after passing three layers of review, and the 15 August 2026 run in which an unequipped baseline agent caught a title defect this checker’s first version was measuring past. Verified: two records swept from a collection reporting a total of two; one blocking finding at 62 stored characters against a 60-character limit; one warning at 60 stored characters against 72 rendered, confirmed by fetching the live page and measuring the emitted title tag; and the checker shown to fail against a deliberately broken record before the run. The runnable procedure lives in the member library.