680 of 684 pages were worthless — auditing and rebuilding an AI-generated site

Months of work produced 684 pages. A mechanical audit found that roughly four of them were worth anything. This is the record of making the AI confront that fact, and of the rebuild that followed.

The problem

An AI news site I run had been operating an automated article pipeline for several months. The working assumption was the usual one: publish volume, then grow whatever lands. The page count reached 684. Organic search traffic barely moved, and kept not moving no matter how much was added.

The awkward part was that the symptom was vague — “somehow not growing”. Looked at individually, each page appeared presentable enough. Working out which pages were the problem, or what was broken site-wide, was not something one person could establish by opening 684 pages one at a time. A manual audit alone would have consumed days, and would still have missed things.

The diagnosis

So I had Claude Code inventory every page and score it mechanically, with no subjective judgement involved. Four axes: word count, duplication, index status, internal link structure.

The result was unambiguous. More than 680 of the 684 pages were thin auto-generated stubs. Average length was 564 words, and the content was close to the same template reused. Google Search Console then showed something worse: the hub pages that should have been the core of the site had never been crawled at all. Crawl budget was being consumed by 680 worthless pages.

The audit turned up a second, deeper fault. Chasing down why H1 titles were breaking, it emerged that the CDN’s email obfuscation feature was rewriting the ”@” inside version strings into HTML and destroying the titles. That is close to impossible to find by eye — and exactly the kind of thing that gets found when the design is “have the AI suspect every page”.

What was done

1. Removed 258 thin pages from search (noindex) so crawl budget concentrated on the 92 pages that mattered
2. Rewrote the pages worth keeping from an average of 564 words to around 1,120 words — resolving duplicate H1s, adding FAQ structured data, redesigning internal links
3. Resubmitted the sitemap and requested indexing for the key pages individually
4. Fixed the “stop producing new, lift the existing” policy into a scoring rubric — 30 points process, 40 quality, 30 data, anything under 70 sent back

The outcome

• 258 pages that search was never going to reward were removed in a single cycle
• Key pages were rebuilt at the 1,120-word level and the H1-breaking bug was fixed at the root
• All content production now passes through a scoring gate — under 70 and it is returned automatically, before publication
• Recovery in search traffic is still being tracked. How far it recovers depends on conditions specific to the site, so I am not claiming a figure here

What this means for your business

Producing volume with AI has become easy. What is hard is continuing to verify the quality of what you produced without spending a person on it. What this audit actually built was a mechanism where the AI scores every page against a standard and anything below it is returned automatically.

The same mechanism transfers directly to repetitive work in your business. “We produced a lot and nothing came of it” is usually not a production problem — it is a missing inspection step. That is the part I build with you, through to the end.