Phase Zero: Clearing Inherited Trust Liabilities Before Building Authority

Buying or inheriting a domain with history means inheriting whatever the last operators published in your name. On our auto-finance rebuild the previous stack carried fabricated review markup, hidden text, four contradictory approval-rate claims live at once, and a copy-pasted Terms page — and all of it was cleared before the apex ever routed to a single new page [our data].

This is the phase nobody wants to pay for, because its entire output is subtraction. It is also the phase that decides whether everything built afterward stands on anything.

What was the situation?

An existing business with real lead flow that could not be interrupted, a WordPress funnel that could not be frozen for a rebuild, and a new static content library that needed to take over the knowledge surface without touching conversions [our data]. The migration machinery — a Worker on the apex routing to the new library with WordPress fallback, staged inert on day 1 so cutover risk never blocked content velocity — is a separate story.

The problem this page is about surfaced before any of that mattered. The pre-build audit was supposed to inventory content. It came back with a liability list instead.

What did the pre-build audit find?

Five distinct classes, each a claim the site was making that could not be defended [our data]:

The two that mattered most were the review markup and the approval rates, for the same underlying reason: both are the kind of claim an answer engine can lift verbatim and repeat under your brand's name.

Why does fabricated review markup matter more than it looks?

Because structured data is a statement, and this one was false in the format built for machines to trust. schema.org defines AggregateRating as a rating based on a collection of reviews or ratings of an item — the vocabulary presumes the reviews exist. Google documents structured data as a way to describe your page's content so search can understand what the page is about (Google, structured data introduction). Markup describing reviews that were never collected is not aggressive optimization; it is a fabricated fact, published in the most quotable form on the page.

The same logic applies to the hidden text. Google's Search Essentials sets out the spam policies a site must not violate, and content served to crawlers that people never see is the class of practice those policies exist to cover. We did not attempt to quantify the risk — nobody outside Google can, and the honest reason to remove it was simpler: we were about to spend months telling this market that our client's numbers could be trusted.

Worth being precise about what removal buys, though. Markup is not a citation lever in either direction — the evidence that adding schema does not cause AI citations is laid out in does schema markup help AI citations. Removing fabricated markup does not earn anything. It stops a liability from compounding.

What did we change?

The sweep ran as a checklist, and every item was completed before the apex pointed at new content [our data]:

1. Fabricated AggregateRating markup removed from the templates that emitted it.
2. Hidden-text blocks removed from the pages carrying them.
3. The four contradictory approval-rate claims replaced by one figure, published with a methodology page explaining how it is calculated and what it covers.
4. The consent defect in the lead flow fixed.
5. Sitemap junk purged so submitted URLs matched pages that should exist.

Item 3 is the one worth copying. Deleting three of four numbers would have left a fourth number with no more support than the others had. Publishing the methodology alongside the surviving figure is what converted a marketing claim into a checkable one — which is the same move the wider evidence discussion in E-E-A-T and AI search argues for on every claim a site wants quoted.

What was the outcome?

The liabilities were gone before publication began, and the build proceeded on a domain whose live claims it could defend [our data]. That is the entire reportable result, and the limits are worth stating plainly.

We have no traffic or ranking outcome to attribute to this phase, and we would not believe one if someone showed it to us: the changes were removals on a live site during a period when the content library was also being built, and nothing in that arrangement isolates an effect. What we can report is that zero fabricated claims from the previous stack survived into the new library, and that the audit habit caught a second pre-cutover problem entirely unrelated to content — an infrastructure default blocking AI crawlers on a domain that thought it was allowing them, documented in the robots.txt we never wrote.

What is the generalizable rule?

Liabilities poison an authority build, so trust repair is a prerequisite rather than an option. New pages do not launch onto a clean surface — they inherit the domain's existing claims, and a fabricated one discovered later devalues everything published on top of it.

Against our own interest: this phase produces no new pages, no new rankings, and nothing a client can show anyone. It is days of billable subtraction, and the obvious question is whether it can run in parallel with publishing. Our answer is no, for one practical reason — the moment new content starts pointing at the old claims, removing them stops being cleanup and becomes a migration of its own.

The inherited-domain checklist that falls out of it is short: inventory every machine-readable claim the site makes, find every metric stated more than once, look for text served only to crawlers, verify the consent flow matches its own copy, and check what the sitemap is actually submitting. Do all of it before the first new page ships — that ordering is the cheapest part of building a library engines can quote, and the only part that gets more expensive every day it waits.