How We Keep AI-Generated Website Content From Becoming a Second Source of Truth

Marketing and content teams adopted AI faster than most of their publishing processes could absorb. Drafts appear in minutes. Product pages get rewritten overnight. Support answers get paraphrased into FAQ copy. The speed is useful, but it creates a quieter problem: the official website, the help center, and the files sitting in shared drives start to disagree with one another.

Once that happens, search results, sales conversations, and any AI assistant built on top of the site all inherit the conflict. Visitors see one version of a policy. Staff quote another. The model retrieves both and treats them as equally current.

We treat AI-generated copy as a draft that has not earned a place in the system of record. The rest of this post describes the controls we put around that rule.

Provenance matters more than output volume

Most organizations already have more than one place where "official" wording lives. A web CMS holds public pages. A document library holds board-approved policies. A ticketing tool holds the phrasing support agents actually use. AI does not invent that split. It multiplies it.

A writer asks a model to "make this friendlier" and pastes the result into a landing page without updating the policy page that legal reviewed last quarter. Another writer generates a new service description because the old one felt dated, then never marks the old page as retired. Six months later an assistant answers a customer with language that no longer matches the contract.

Banning generation is usually the wrong response. The useful work is to decide, in writing, which system owns each class of content and what an AI draft is allowed to do before it lands there.

Decide ownership before you generate anything

We start every content-and-AI engagement by mapping sources of truth. The map is simple on purpose.

• Public web pages: owned by marketing or communications, with legal review on regulated topics
• Policies, fees, eligibility, and medical or program rules: owned by the department that is accountable for them
• Product or service facts: owned by operations or the product owner
• Support resolutions: owned by support leadership, and promoted into documentation only after review
• AI prompts, skills, and retrieval sources: owned by the team that operates the assistant

If two groups claim the same page type, we stop and resolve that before any generation workflow goes live. An AI pipeline cannot repair unclear ownership. It will only publish the confusion faster.

Generation happens in a workspace, not in the CMS

Writers still use models to outline, tighten, translate, and propose variants. They do that in a drafting workspace that is deliberately separate from production pages. The workspace can be a restricted CMS collection, a document library with a "draft AI" content type, or an editorial tool that writes back through an API. The important part is the label. Every generated artifact carries:

• the source page or document it was based on
• the date and version of that source
• the model or skill that produced the draft
• the prompt or skill version
• the human who requested it
• a status of draft, in review, approved, or rejected

That metadata sounds fussy until the first dispute about a published sentence. Then it is the only way to reconstruct what happened.

We also keep the raw model output. Editors almost always rewrite. If you only store the polished version, you cannot tell whether a later error came from the model, the editor, or a stale source.

Review is specific, not ceremonial

A generic "please review this AI draft" request does not work. Reviewers need to know what they are checking. We use a short checklist that changes by content type.

For a public service page, the reviewer confirms that names, hours, fees, eligibility, and contact paths match the current source document. For a health or government page, a subject-matter owner confirms that the draft did not soften a requirement or invent a next step. For a support article, an experienced agent confirms that the steps still match the live system.

The reviewer is not asked to judge whether the writing "sounds good." Tone can be adjusted after the facts are locked. If a draft fails the factual check, it is rejected and the source document is updated first when the source itself was wrong. That order matters. Updating the web page and leaving the policy stale is how a second source of truth gets created.

Publishing writes one record, then retires the rest

Approved copy is written into the designated system of record. Related pages that would now conflict are redirected, unpublished, or marked historical in the same change. We do not leave "old but still indexed" versions sitting around because someone might want the wording later. Archives belong in version history, not in the public information architecture.

Where an assistant reads the site, the publish event should refresh the retrieval index for that page and remove the prior chunk. If the index lags by a week, the assistant becomes a third source of truth even when the CMS is clean.

Prompts are not allowed to invent durable facts

A recurring failure mode is a prompt that says "include typical hours" or "add common eligibility notes" when those facts were not in the source. Models will fill the gap with plausible language. That language then gets edited for style and published as if someone had verified it.

We constrain generation skills so they can rephrase, restructure, and suggest headings, but they cannot introduce hours, prices, phone numbers, clinical claims, legal conditions, or deadlines that were absent from the source packet. If the source is incomplete, the skill returns a list of missing facts instead of a finished page. Editors find that less magical and much safer.

Measure drift, not just output speed

Teams like to report how many pages AI helped produce. That number is incomplete. We also track:

• how many published pages were later corrected for factual drift
• how often the assistant cited a page that conflicted with the current policy document
• how long a change in the source of truth takes to appear on the public page and in retrieval
• how many drafts were rejected because the source itself was stale

Those figures tell you whether the workflow is protecting the record or just accelerating entropy.

What this looks like in practice

On a recent content program, the client's public site, PDF guides, and call-center scripts described the same program with three different eligibility sentences. The team had been using a general-purpose model to "refresh" web copy each quarter. Each refresh made the pages more readable and slightly less accurate.

We paused generation and rebuilt the packet for that program: one approved fact sheet, one public page, and one support article, all pointing at the same statements. The model was then allowed to propose a clearer layout and a shorter introduction. It was not allowed to touch the eligibility block. After publish, the older PDFs were replaced with links to the page, and the assistant's index dropped the retired files.

The writing improved. More importantly, the three channels stopped arguing with each other.

A rule we keep repeating

Treat the model as a drafting aid that sits in front of the records system. If a sentence needs to be true next month, it needs an owner, a source, a review, and a single place where the current version lives. Generation can accelerate that process only when it does not replace it.