How to Build Content Google and AI Search Can Both Understand

Google and an AI search engine understand the same page when every claim on it can be traced: what kind of claim it is, who is making it, where it came from, and as of when it was true. Structure gets a page parsed, and both readers already parse well-made HTML. What they cannot do is trust a fluent sentence that carries no proof, and automated pages are full of them. This guide is the method we use to fix that: map the claims, name the source in the sentence, declare the same sources in the markup, and date the claims that go stale.

What does content Google and AI search can both understand look like?

Content for Google and AI search is content where every claim can be traced: a reader can see what kind of claim it is, who is making it, where it came from and when it was last true. That is the whole difference between a page that gets read and a page that gets trusted. A retrieval system quotes passages rather than pages, so the proof has to travel inside the passage, not sit in a reference list three screens below it.

Google has been plain that there is no separate recipe for its AI features. John Mueller's May 2025 post on how content performs well in Google's AI experiences on Search asks for "unique, non-commodity content" and for markup whose content is also visible on the page, and says that meeting the technical requirements covers search generally, AI formats included. ChatGPT reaches the web through its own crawler: OpenAI's overview of its crawlers says OAI-SearchBot is the one used to surface websites in ChatGPT's search features, and robots.txt decides whether it may. Neither describes a special format.

Two parts of this subject we have already written up, and we will not argue them again here. Putting the answer first when preparing content for AI search is about where a section's answer sits, and how entities and citations split AEO from GEO is about resolving who is speaking. Our view of how AI search is changing SEO covers the wider shift. This post is about the layer underneath all three: the claim-to-source layer on a published page, the part a pipeline can skip without a single check going red.

The test for that layer is four questions, asked of every sentence that could be wrong. What kind of claim is this? Who is making it? Where did it come from? As of when was it true? A page that answers all four for every claim that matters reads the same to a person, a crawler and a model, and that is what an SEO content system that keeps its sources attached is built to produce.

Why are automated pages understood but not trusted?

Automated pages are usually understood perfectly well and trusted very little, because a pipeline produces fluent claims far faster than anyone can source them. We call the result the unattributed page. It has clean headings, a direct answer under each one, valid schema and a tidy FAQ, and not one sentence a reader could check. Every structural test passes, and the page still gives a careful reader, or a model choosing between candidate passages, no reason to prefer it.

Research on generative search shows how thin the trust layer can be, even on the engines' own side. Liu, Zhang and Liang's 2023 study Evaluating Verifiability in Generative Search Engines found that "a mere 51.5% of generated sentences are fully supported by citations", and that only 74.5% of citations supported the sentence they were attached to. Those figures describe the engines' answers at that time, not anyone's pages, but the direction matters to a publisher. An answer is assembled from passages, and the passage whose claim arrives already attached to its source is the easier one to stand behind.

Inside a pipeline the cause is mechanical. A model drafting from a brief writes what is usually true about a subject, in the confident register of someone who checked. Nothing in the draft marks the difference between a fact it was given, a fact it inferred and a fact it made up. In most workflows fact checking is one step after drafting, so it receives a page with no map of what needs checking. Our guide to how LLMs use content describes the reading side of this problem; this is the writing side.

The fix is not a few more sources sprinkled at the end. It is a map, made before publication, of every claim and what it rests on, kept beside the page for as long as the page is live. The four steps below build that map and then make the page say what the map says.

Step one: split the draft into claims, and give each a type

The first step is to read the draft sentence by sentence, list every claim it makes, and give each one a type, because the type decides what the page owes its reader. A claim is any sentence that could be wrong. "Most teams publish less than they planned to" is a claim; "here is how we run it" is not. Five types cover almost everything a business publishes, and each carries a different standard of proof, a different signer and a different shelf life.

The settled fact needs the least: a definition, a widely known mechanism, something any reference would confirm. The third-party figure needs the most, because it is the claim most often copied from a copy. A number travels from a survey to a news story to a blog post, losing its sample and its date at every step.

Our position and our own test are the two types automated pages leave out, and they are the reason a page is worth citing at all. A position is something the business believes and will defend; an own test is something it built, ran or watched happen itself. Google's guidance on creating helpful, reliable, people-first content asks whether a page provides "original information, reporting, research, or analysis", and these two types are where that original information lives. They need a label rather than a link, so the reader can tell the business is speaking from its own work.

The list lives in a file beside the post, the claim map, with one row per claim: the sentence, its type, its source, the date the source was last opened and the person who signed it. The way we turn business knowledge into content starts from facts that each carry an ID and a source, so for a new post the claim map is mostly a lookup. It also gives the content scoring that evaluates quality something concrete to score.

Step two: name the source in the sentence, and put the evidence beside it

Attribution belongs inside the sentence that makes the claim, not in a footnote or a list at the bottom, because the sentence is the unit that gets quoted. "Pew Research Center found in 2024 that…" survives being lifted out of the page; a small number pointing to reference seven does not. Name the publisher, name the document where that helps, and link the page that says the thing: the specific page, never the homepage. The named source serves every reader who never clicks.

Google's helpful-content questions put this in a reader's terms. They ask whether a page presents information "in a way that makes you want to trust it, such as clear sourcing", and whether it is "self-evident to your visitors who authored your content". Both are answered by writing that says who says what, and neither by markup alone, because a reader never sees the markup.

Evidence goes beside the claim it supports, and it goes in text: the quotation, the figure with its year and what it measured, the step of our own process, the screenshot described in words. Every figure on this site is built in HTML rather than saved as an image for the same reason, since a caption a model can read is evidence and a picture of a chart is not. Where a number has no source the writer can open, it becomes a direction such as "most", "rarely" or "more than half the time", or it is cut.

Quote the source's own words where the exact wording matters, paraphrase where it does not, and never paraphrase a number. The paper that introduced the term, GEO: Generative Engine Optimization by Aggarwal and colleagues, reports that its methods "can boost visibility by up to 40% in generative engine responses". Written that way, a reader knows it is the paper's claim, measured on its own benchmark. Written as "citing sources boosts AI visibility by 40%", it becomes exactly the kind of unattributed number this method exists to remove.

Step three: declare the same sources in the markup

The third step is to declare, in the page's structured data, exactly the sources the body names and links, no more and no fewer, so the markup is a second copy of the claim map rather than a separate story. Schema.org gives a creative work two properties for this. Its citation property is defined as "a citation or reference to another creative work, such as another publication, web page, scholarly article", and its mentions property says the work "contains a reference to, but is not necessarily about a concept". A cited page goes in citation; a tool or organisation the page names goes in mentions, with a sameAs pointing to its official site.

The rule that keeps this honest is symmetry. Every outbound link in the body is declared, and every declaration is linked from the body. On this site a script enforces both directions on every post, and when it was first switched on it found real drift: declaration blocks copied from post to post, naming tools the body never linked. That is our own build, and it is why we trust the rule. A markup block written separately from the prose drifts away from it, and no reader notices.

Markup does not earn a citation on its own, and Google needs no special schema for its AI features; its May 2025 post asks only that what is in the markup also be visible on the page. The value of citation is that it states, in a form no machine has to infer, which documents the page rests on. The broader basics are in our section on structured data when preparing content for AI search. This step is narrower than either: one list of sources, written once, rendered twice.

Step four: date the claims that can go stale, and never move the page date

The fourth step is to put an "as of" date on every claim that can change, such as a platform rule, a law, a price or a tool's feature, and to leave the page's publication date alone. Moving the page date on every edit makes an archive look newer than it is and says nothing about which sentence changed. "As of October 2026", written beside the one volatile claim, tells them exactly what was checked and when.

Volatile rules are the fifth type in the claim map, and they are the claims a model is most likely to get wrong on your behalf, because it drafts from whatever was true when it was trained. When the date is old, the fix is one sentence rather than a rewrite. Our routine for that is the content refresh loop, which re-checks dated claims on a schedule and leaves the publication date where it is.

Sources go stale as well, and faster than most people expect. Pew Research Center's 2024 study When Online Content Disappears found that "38% of webpages that existed in 2013 are no longer accessible a decade later", and that 23% of news webpages contained at least one broken link. Tim Berners-Lee made the case for the W3C in 1998, in Cool URIs don't change, that a good address is one that never changes; plenty still do. So the claim map records each URL and the date it was last opened, and a dead source is found by a scheduled check rather than by a reader.

When a source dies, the claim does not quietly keep its link. Find the publisher's new page for the same document, or rewrite the claim as a direction, or cut it. A link that leads nowhere is a claim of evidence the page can no longer make.

What the pipeline checks, and what a person signs

The pipeline can do almost all the clerical work of a traceable page, and a person has to sign the claims, because only a person can be accountable for them. Automation splits the draft into sentences, flags the ones that read as claims, proposes a type for each, looks for a matching fact in the knowledge base, checks that every link in the body is declared and every declaration is linked, and re-opens every source on a schedule. That is pattern work, and a machine does it more consistently than a tired editor.

What stays human is judgement about truth and about position. Whether a source really says what the sentence claims. Whether a third-party figure is fit to repeat at all. Whether "our position" is one the business will defend on a sales call. A named person reads the claim map, not only the prose, and signs it, and the map keeps that read short because it lists only the sentences that could be wrong.

There is a tempting middle step: ask a model to verify the sources itself. It is useful as a first filter. It cannot be the last word, for the reason the verifiability study found engines attaching citations that did not back their claims. A machine check that the source supports the claim is evidence for the signer, never a replacement for one. For the rest of the machine-and-editor split across a whole search pipeline, the SEO playbook for a Content OS covers what this section leaves out.

A worked example: a probation-period guide, traced claim by claim

Here is the method on an illustrative page: an employment-law consultancy's guide to probation periods, drafted by a pipeline from the firm's own notes. The firm and the page are invented for this example; the mechanics are the ones we build. The draft comes back long, fluent and well structured, with a direct answer under every heading. It reads like a firm that knows its subject, which is why it needs tracing.

A subagent in Claude Code, a separate worker with its own instructions and its own tools, splits the draft into sentences and builds the claim map. It finds statutory rules about notice and reviews during probation, which are volatile rules needing the government's own page and an as-of date. It finds the firm's advice to hold a review before the period ends, which is a position and is labelled as the firm's view. It finds a pattern the partners see in their own disputes, labelled as their experience and given no number because nobody counted. And it finds a survey figure about failed probations that the draft had picked up from a news article.

The survey figure is the instructive one. Traced back, the news article had rounded it and dropped the survey's date, and the survey itself had measured something narrower than the sentence claimed. The rule decides what happens next: the page quotes the original with its publisher and year, or it says "a minority" and links nothing. The firm chose the second. Anthropic's citations feature for Claude makes this kind of trace faster, since a model handed the source document returns the exact passage behind each claim. The trace still ends with a partner reading that passage.

Then the markup is written from the map rather than from the prose: every linked source in citation, the firm's own review framework named in about. A scheduled workflow in n8n opens every cited URL each week through n8n's HTTP Request node, set to return the status code, and sends any source that stopped answering, along with any as-of date older than the firm's review interval, to the person who owns the guide. A partner signs the map before publication and again whenever a statutory claim is updated. The guide is no longer than the draft was, and every sentence that could be wrong now says who says so.

What a traceable page costs, mostly in research time

A traceable page costs research time up front, claim by claim, and very little to keep once the map exists. The expensive part is the first pass on a page drafted without one: finding the primary source for a figure that was copied, deciding what the business really believes, and cutting what nobody can stand behind. That time is real, and it falls on the person who knows the subject rather than the person who formats the page.

The cost drops sharply once claims start life in a business content knowledge base instead of in a draft. If every fact the business publishes already carries its source and the date it was checked, the map for a new post is mostly a lookup, and the signer reads only the claims that are new. Upkeep becomes a weekly link check and a periodic re-read of the dated claims.

What it buys is harder to measure and easy to overstate. No method guarantees that Google ranks a page or that an AI engine cites it, and we do not promise either. What a traceable page does guarantee is that whoever reads it, a person deciding whether to trust you or a system choosing which passage to quote, can check every claim on it. If you would rather have this built into how your articles are produced than do it by hand, it is part of the website blog writing system, which we quote separately because the scope depends on the site.

Frequently asked questions

What makes content understandable to both Google and AI search?

Content is understandable to both when it is well structured and every claim on it can be traced: the type of claim, who makes it, where it came from and when it was true. Google says its AI features need no special format beyond normal search requirements, so structure is shared. Traceable claims are what make a passage trustworthy enough to quote, for a person and for a retrieval system alike.

Does naming sources make an AI engine more likely to quote a page?

Naming sources makes a page easier to trust, but no one can promise it will be quoted. Research on generative engine optimization reports visibility gains on its own benchmark, and Google rewards clear sourcing as a sign of helpful content. Treat attribution as making every claim checkable, which is worth doing for readers anyway, rather than as a lever that guarantees a citation.

Which claims on a page need a source, and which do not?

Third-party figures and volatile rules always need a source, named in the sentence and linked to the original page, with a date for anything that changes. Your own positions and your own tests need a clear label instead of a link. Settled facts, such as definitions any reference would confirm, need nothing extra unless a reader is likely to want the original.

Should a page's citation markup list every link on the page?

Citation markup should list the sources the body cites, no more and no fewer, so it matches what a reader can see. Pages the content rests on go in citation, and tools or organisations it only names go in mentions with a sameAs to their official site. Internal links and navigation do not belong there. Keeping the two lists symmetrical stops the markup drifting away from the prose.

How should a page show that a fact was true at a certain date?

Write an "as of" date inside the sentence that carries the volatile fact, such as "as of October 2026", and link the source it was checked against. Leave the page's publication date alone, because moving it on every edit tells a reader nothing about which claim changed. When the as-of date is old, the refresh is one sentence, not a rewrite of the page.

Can an AI model check the sources on a page by itself?

A model can help check sources but should not be the last word. Given a source document, it can find the passage that supports a sentence, or say that none does, which makes a first pass much faster. It can still be wrong about whether a source backs a claim, so a named person should read the passage and sign the claim before the page goes live.

What should happen when a cited source disappears?

When a cited source disappears, find the publisher's new page for the same document, or rewrite the claim as a general direction, or cut it. Never leave a dead link in place, because it claims evidence the page no longer has. A scheduled check that opens every cited link and reports the ones that stopped answering finds this before a reader does.

Where to start

Start with the three pages that bring in the most readers, not the whole site. Print each one, or paste it into a document, and mark every sentence that could be wrong. Give each mark one of the five types, then count how many of the third-party figures and volatile rules name their source in the sentence. That count is your baseline.

Fix those three pages by hand before automating anything, because doing it once teaches you which claims your business makes over and over. Those repeat claims are the first entries in the knowledge base the pipeline will later draft from. For the rest of what we have written on the subject, every guide on SEO and AI search is collected in one place.

Keep reading

• SEO vs AEO vs GEO for Automated Content — the three readers of the same page, and where entities and citations split them.
• How to Automate Content Refreshes — the loop that re-checks dated claims without moving the page's date.
• How to Turn Business Knowledge Into Content — where the facts a claim map looks up come from in the first place.