Evidence-rich content: the difference between pages and sources

A source does more than restate the category

Thin pages summarize information already available elsewhere. A source contributes something identifiable: a method, definition, dataset, specification, policy, tested example, expert interpretation, or clearly bounded comparison.

The distinction is visible in miniature on almost any page claiming expertise. A returns-policy page that says “we make returns easy” is restating the category — every competitor's page says something equivalent. A returns-policy page that states the actual window, the actual condition for a full refund versus store credit, and the actual exception for one named product category is a source: a reader or a retrieval system can extract a specific, checkable fact and act on it. Nothing about the second version required new research. It required writing down what the business already knows instead of the adjective it usually reaches for.

Google's own quality guidance describes exactly this gap

This is not a house opinion about content quality; it is close to a direct restatement of Google's published guidance for what its ranking systems are designed to reward. Google's help documentation on creating helpful, reliable, people-first content asks creators to check whether a page “provides original information, reporting, research, or analysis,” and, if it draws on other sources, whether it “avoids simply copying or rewriting” them in favor of “substantial additional value and originality.” The same guidance names the opposite pattern directly: “mainly summarizing what others have to say without adding much value” is listed as a warning sign of search-engine-first content — the failure mode this whole discipline exists to avoid.

Google packages the underlying quality signal as E-E-A-T — experience, expertise, authoritativeness, and trust — evaluated through its Search Quality Rater Guidelines. Of the four, Google states trust is the load-bearing one: “untrustworthy pages have low E-E-A-T no matter how Experienced, Expert, or Authoritative they may seem.” The other three exist to support trust rather than stand in for it, which is why a page can be highly expert and still rated poorly if it reads as unreliable, and why a forum post from someone with direct, first-hand experience can outscore a polished page with none.

Google also offers a concrete self-check for expertise: is the content “written or reviewed by an expert or enthusiast who demonstrably knows the topic well,” and would someone researching the site “come away with an impression that it is well-trusted or widely-recognized as an authority on its topic.” Both questions are checkable without any tooling; they just require being honest about whether the answer is yes.

Build an expertise inventory before a content calendar

Interview product, sales, support, engineering, and operations. Review documentation, tickets, demonstrations, policies, product data, and customer questions. Record which facts are public, which need review, and which must remain private.

Google frames a related discipline as three questions worth asking about every piece of content before it is published: who created it, how it was created, and why. “Who” means a page should make its authorship self-evident, ideally with a byline that leads to real background on the author. “How” means being transparent about process — for a product review, how many units were tested and by what method; for AI-assisted content, whether and how automation was used. “Why” is the question that actually separates a source from a doorway page: content made primarily to be useful to an existing audience passes; content made primarily to attract search or AI-citation traffic does not, regardless of how well it is written.

In practice the inventory step surfaces three different categories of material, and they need different handling. Facts already stated publicly somewhere — a spec sheet, a help doc, a sales deck — mostly need to be relocated to where a reader or a retrieval system can find them, not created from scratch. Facts known internally but never published — why a policy exists, what a support team actually sees go wrong, what a specification trade-off costs — are the highest-value material, because no competitor's page can replicate them. Facts that cannot be published — customer data, unreleased pricing, anything under NDA — should be flagged and excluded at this stage rather than discovered as a problem after a draft is written.

Keep claims traceable

Each material claim should connect to a source, owner, date, and approval state. That evidence may be visible on the page or retained in the editorial record depending on the claim. Traceability makes refreshes, corrections, and regulated review safer.

Traceability is also what makes a refresh cheap instead of a rewrite. A claim recorded with its source, owner, and date can be re-verified in minutes when the underlying fact might have changed — a price, a policy, a specification. A claim with no recorded origin has to be re-researched from nothing, which is the reason stale pages accumulate: nobody remembers where the number came from, so nobody is confident correcting or removing it.

What the research on generative-engine visibility actually found

The academic study that named this category is worth reading directly rather than through secondhand summaries. Researchers from Princeton University and the Indian Institute of Technology Delhi formalized “Generative Engine Optimization” (GEO) as a research problem in a 2023 paper later presented at KDD 2024, built a 10,000-query benchmark spanning 25 domains, and tested nine ways of rewriting content to see which changed a page's prominence in a generative engine's synthesized answers. Their own abstract states the finding plainly: the tested methods “can boost visibility by up to 40% in generative engine responses,” with the caveat, also in their own reporting, that the effect size varied substantially by domain and was not uniform across every method or topic.

The direction of that finding lines up with the rest of this page rather than contradicting it: the interventions that helped were adding relevant statistics, adding citations to credible sources, and adding quotations from people with standing to speak on the topic — evidence, in other words, not phrasing tricks. The intervention that reliably failed was keyword stuffing, which the researchers found provided little to no benefit and in their real-world test on Perplexity.ai performed measurably worse than doing nothing. Specificity and sourcing moved the needle; density of a target phrase did not.

Some claims need more scrutiny than others

Not every claim carries the same risk if it is wrong, and Google's own guidance makes this explicit rather than implicit. Content on topics that could significantly affect a reader's health, financial stability, safety, or society's welfare — what Google's quality guidance calls “Your Money or Your Life” topics, or YMYL — is held to a stricter E-E-A-T bar than a general-interest page, because the guidance states its systems give the concept even more weight there. A blog post about a hobby can get away with a looser sourcing standard than a page about tax obligations, medical dosing, or financial eligibility.

This has a direct operational consequence for the traceability discipline above: not every claim needs the same approval path, but some do. A specific number, eligibility rule, or safety instruction that would cause real harm if wrong should carry a named reviewer and a visible last-checked date, not just an owner in an internal record. Treating a YMYL-adjacent claim as casually as a stylistic preference is the kind of gap that costs trust with both readers and the ranking and generative systems reading the same page.

Publish into a connected architecture

An isolated article is not a strategy. Connect buyer-question pages to relevant category and product pages, related evidence, authors, and definitions. Verify that the final rendered links and structured relationships match the plan.

Verification here is the same discipline as verification everywhere else on this page: check the rendered page, not the plan. A link that exists in a content brief but was never actually added to the shipped template does not connect anything, and a structured-data relationship that references a page which got renamed or removed creates the exact ambiguity this whole approach is meant to eliminate.