What Our AI Rewriter Removed, and How We Stopped It

I spent part of this week rebuilding one of our AI writing tools.

The first version looked like it worked. The prose was clean, the grammar was right, the length matched what we asked for.

Then I diffed the output against the original.

A product name was gone. A city had become "the area." Two internal links had vanished. A service description had been compressed until it no longer described the service.

The rewrite was easier to read and less true.

The problem was not that an AI touched the content. The problem was that we were measuring fluency and never checking fidelity.

Google does not penalize content for being AI-assisted

Let us get this out of the way, because the usual version of this article gets it wrong.

Google's guidance is about whether content is accurate, useful, original, and made for people. Using AI in an editorial process is not itself a ranking problem. Mass-producing pages with automation and no added value violates its scaled-content-abuse policy, but a human can write a generic, useless page just as easily.

The production method is not the standard. The finished page is.

Our rewriter failed that standard for a boring reason: it changed information we needed to keep.

Specificity went first

Say a page states that DeepAudit audits JavaScript-rendered sites for businesses in Las Cruces.

A generic rewrite turns that into something about helping local companies improve their online presence. Smoother. Also, the reader no longer knows which product, what kind of sites, where you work, or what makes any of it different.

I am not going to claim that deleting one instance of a city name makes you "invisible to entity-based ranking." That is keyword superstition, and I have seen it in enough SEO decks to be tired of it. Pronouns are fine. Repetition is annoying. Exact-match phrasing often makes a page sound like it was written for a crawler.

The rule is narrower and more defensible:

Do not generalize a passage until it stops saying what the business actually does.

"SEO tool" and "JavaScript SEO scanner for React applications" are not the same claim. The first names a category with thousands of entrants. The second names a function and an audience. That is worth protecting because it is *accurate*, not because a keyword tool put it in a spreadsheet.

The links were an architecture bug, not a writing bug

Our early workflow handed the model the article and asked for a rewritten version. That gave it authority over the words *and* the document structure. When it rewrote the linked sentence, the hyperlink sometimes went with it.

In hindsight that is entirely predictable. We asked a text model to regenerate a structured document from memory, and it did exactly that.

The fix was not another sentence in the prompt.

We stopped letting the model regenerate the links at all. The application parses the article first. Links, URLs, citations, headings, code blocks, and protected facts stay in the application layer. The model rewrites approved text spans, and the system reinserts them into the existing structure.

It can propose better anchor wording. It cannot silently delete a destination, because it never holds the destination.

That is the whole lesson, really: reduce what the model is allowed to change, and you stop needing a validator to catch what it broke.

Structured data has to agree with the page, not match it word for word

A second failure showed up when a rewrite removed a visible fact while the JSON-LD still declared it.

Structured data should describe the page and correspond to what a visitor can actually see. But the prose does not have to echo the schema verbatim. A page can say "projects begin at $2,500" while the markup expresses the same pricing in machine-readable form. Those agree.

The break happens when the rewrite deletes or contradicts the underlying fact. So the validation compares facts, not strings.

And I want to be careful here: valid schema does not guarantee a rich result or a ranking benefit. It just needs to be true.

Three layers, not one rule

Our first instinct was to reject any rewrite that lost a protected phrase. That is too blunt. Some of those losses are improvements.

So the contract has three layers now.

Hard invariants. Cannot change without explicit approval: link destinations, names of people and businesses and products and places, prices, quantities, dates, credentials, technical specs, contact details, direct quotes, citations, legal qualifiers, and any fact the structured data declares.

Structural invariants. Must survive, though wording or position can move: internal links, the question each section answers, the heading hierarchy, required lists and tables and code, the primary call to action.

Soft targets. Fair game when the rewrite genuinely improves the piece: sentence length, repetition, transitions, tone, paragraph order, examples, anchor phrasing.

A changed price is rejected automatically. A different anchor phrase goes to a human. A redundant fourth mention of the city can just go.

A prompt is not a validator

We still tell the model what to preserve. We simply stopped believing it.

Every rewrite is diffed against the original afterward: are the URLs still there, did a number or date change, did a named product or person or place disappear, did it invent a new factual claim, does the visible content still support the schema, did the conclusion change, did the CTA survive.

A failed check does not mean the output is garbage. It determines what happens next: reject, retry with the specific failed constraint, restore the element programmatically, or send it to a person.

The thing I am not going to claim

The honest version of this post has to include what I cannot prove.

During one client audit we found a rewritten paragraph that had replaced several named services and locations with generic filler, and the page's search performance had declined over a period that also contained multiple other content changes. Other things shipped. Competitors moved. Google updated.

I cannot isolate the rewrite as the cause of that decline, so I am not going to tell you it was. What I can verify is that the new version conveyed materially less information than the one it replaced. That is a good enough reason to fix it. The article does not need a ranking drop to justify itself, and reaching for one would be exactly the kind of unearned causal story this blog has been cutting for weeks.

What I still owe you

I have not measured this system yet, which is the real gap.

The test set is straightforward to build: representative passages carrying internal links, named companies, locations, dates, prices, technical terms, quotations, legal qualifiers, and schema-backed facts. Run each version of the rewriter across it and report link-destination retention, named-entity retention, numeric and date accuracy, contradiction rate, unsupported-claim rate, human readability, and the share accepted with no manual correction.

Then I can tell you whether moving the links out of the model actually fixed anything, instead of asserting that it did.

That is the next post, and I would rather promise it than fake it.

What we check before publishing

Compare the rewrite against the original, directly. Inspect every changed fact. Confirm every link and destination. Check names, places, products, dates, prices, credentials. Ask whether specific service language went generic. Confirm the visible facts still agree with the structured data. Read it as a customer rather than a keyword counter. Reject claims the source did not support. Keep changes only where they fix an identifiable problem. Record who approved it.

The goal was never to keep AI away from the article. It is to know exactly what changed, and why.

The lesson

AI did not secretly drain some invisible substance called "SEO" out of our content.

We handed a probabilistic writing model more authority than it needed and then graded it on the wrong thing. It optimized what we measured. Fluency went up. Fidelity was never checked.

We fixed it by keeping the document structure outside the model, defining what could not move, validating every rewrite against the original, and leaving a person responsible for the call.

The best rewrite is not the one AI barely touched. It is the smallest set of changes that improves the piece without damaging its facts, its purpose, or its structure.

Before you publish an AI-assisted rewrite, diff it against the original and walk the checklist above. That is the step that catches this.

Afterward, a technical audit will confirm that the links, headings, schema, and rendered content actually survived deployment. It cannot tell you what the rewriter took out, so do not ask it to.