E-E-A-T When Everyone Publishes AI Content

When a model can produce fluent prose on any topic in eight seconds, the parts of E-E-A-T that still separate pages are the parts a model cannot generate: something you did that nobody else did, a number you measured yourself, and a name attached to the claim that can be publicly wrong. Google's own documentation is narrower than the folklore around it. E-E-A-T is not a ranking factor, AI authorship breaks no rule, and what actually gets marked down is content made with little effort, little originality and little added value.

Here is the part I did not expect. I put 20 of my own drafts through an adversarial audit: every number checked against the source named beside it, every statement about my own code checked against the file. All 20 came back with findings — 221 defects, 68 of them source-fidelity failures, 14 serious enough to block publication. This post was in the batch and carried four of the 68. Every one of them read perfectly.

What Google's documentation actually says

I checked this against the live pages rather than from memory, because most of what circulates about E-E-A-T is downstream of a blog post someone half-remembered.

From Creating helpful, reliable, people-first content, the sentence that kills the most common claim: "While E-E-A-T itself isn't a specific ranking factor, using a mix of factors that can identify content with good E-E-A-T is useful." The same page ranks the four letters unevenly — trust is the one that matters most, and the others feed it. Content does not have to demonstrate all four.

That page also carries the self-assessment questions grouped under Who, How and Why. Four sentences in the "How" group speak to AI disclosure. Three are questions: "Is the use of automation, including AI-generation, self-evident to visitors through disclosures or in other ways?", "Are you providing background about how automation or AI-generation was used to create content?" and "Are you explaining why automation or AI was seen as useful to produce content?" The fourth is the guidance they build to: "Overall, AI or automation disclosures are useful for content where someone might think 'How was this created?' Consider adding these when it would be reasonably expected."

An earlier draft of this post cut that first question off at "disclosures" and called it the only sentence Google publishes on the subject. Both halves were false, and both errors leaned towards the reading that suited my argument. Nothing here mandates a label. The fourth sentence recommends one wherever a reader would reasonably wonder how a page was made, which for anything carrying a number is most of the time.

The spam policies page defines the actual violation: "Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users," with "Using generative AI tools or other similar tools to generate many pages without adding value for users" listed as an example. The generation method sits in the example. The intent and the missing value sit in the definition.

The Search Quality Rater Guidelines run to 182 pages. Section 4.6.6 is the part people quote at each other, usually with its opening clause removed. In full: "The Lowest rating applies if all or almost all of the MC on the page (including text, images, audio, videos, etc) is copied, paraphrased, embedded, auto or AI generated, or reposted from other sources with little to no effort, little to no originality, and little to no added value for visitors to the website."

Delete "all or almost all of the MC on the page" and the rule stops describing a page that is almost entirely low-effort filler and starts describing any page with an AI-drafted paragraph in it. That is the version I have seen circulate, and it is the version an earlier draft of this post printed. The same document closes the method question outright: "the use of Generative AI tools alone does not determine the level of effort or Page Quality rating. Generative AI tools may be used for high quality and low quality content creation."

That earlier draft also claimed I could not parse the PDF, and cited a trade-press summary instead. The PDF resolves, opens in a single call, and yields section 4.6.6 verbatim. I had never tried. Routing a primary source through a secondary one, on a premise the primary source disproves, is the exact failure this post exists to describe, committed in the paragraph that claims to be careful about it.

One source I genuinely could not get: the February 2023 Search Central post on AI-generated content. Two fetches returned the blog archive shell rather than the article body, so it is absent here instead of paraphrased from memory.

The folklore, briefly

Three claims I see repeated that the documentation does not support:

• —"Your site has an E-E-A-T score." There is no score. The docs describe a mix of signals used to identify content with those qualities.
• —"Add an author bio box and E-E-A-T is handled." The question asked is whether it is self-evident who created the content, and whether that person has a background a reader can recognise. A widget in the footer of a page anyone could have written does not answer it.
• —"Google detects AI writing and penalises it." The documented trigger is effort, originality and value. A model-drafted post carrying measurement nobody else has is not what those clauses describe.

The audit that made me stop trusting fluent drafts

Twenty drafts went through a claim-by-claim check. All 20 came back with findings, 221 in total. Three classes account for most of them.

Source fidelity, 68 findings. The number was real. The source named beside it was the wrong source, or the quote had been trimmed until it said something its source does not say. This is the hardest class to catch, because a fact-check that stops at "is the number true" passes it. Four of the 68 were in this post, in the section above.

False first-person claims about my own codebase. The worst asserted that my agent system never writes to the database. The truth is narrower and more useful. getDb() in lib/agent-tools.ts builds its client from the service-role key, which bypasses row-level security and can write to every table in the schema. The restriction lives in the tool surface rather than the credential. Sixteen tools are defined; six of them create things, and all six insert into a pending_actions queue for a human to approve. No tool function anywhere contains an insert into a business table. The one direct write is write_agent_memory, which upserts agent_memory. The guarantee holds, but it holds because the function does not exist, and it breaks the day somebody adds one. Removing a function is the control; restricting the key was never doing that work. I wrote the runner and still shipped a draft that described it wrongly. The corrected architecture is in the approval queue post.

Arithmetic that fails subtraction. Six of the twenty carried a version of the same slip: a published-post count, an unpublish count, and a difference between them that followed from neither. A reader with a calculator catches these in seconds, which is the whole argument for putting numbers in a post and also the whole risk.

Fluent errors are the expensive ones

An error that reads badly gets caught by the reader. An error that reads well gets quoted. Generated prose is optimised for the second kind by construction — it produces the sentence that sounds most like the sentences around it, and a confident attribution sounds exactly like a correct one.

Nothing about that is unique to AI. I have made the same mistake by hand at 1am. What changed is throughput: I can now produce more claims per hour than I can verify per hour, and that ratio is the real risk in AI-assisted publishing.

The signals, and how a reader checks them

Every row here is something a reader or a rater can attempt to falsify. That is my test for whether a signal is real.

The last row is the one almost nobody does, and it is the cheapest trust signal available. A visible correction is evidence that somebody is checking.

Experience is produced before it is written

My own Search Console data makes this concrete in a way I did not enjoy. Over the 85 days to 3 September 2026, this site took 22 clicks from 4,553 impressions across roughly 390 indexed URLs — a 0.48% CTR. Inside that, the split by post type was stark. Build-log posts and posts with worked arithmetic in them ranked between positions 2.8 and 15.5. Generic "[industry] content marketing" posts ranked between 46 and 81. Same author, same domain, same quarter. 111 of 182 ranking pages earned five or fewer impressions.

The generic posts were not badly written. They were fluent and they were about nothing that happened. The full teardown is in 389 pages, 22 clicks, and the pattern matches what I found reading 50 B2B blogs that actually work: the posts that hold position carry an artefact.

Instrument before you write

You cannot report a number you never recorded. Before a build or a campaign I now write down what I will measure: the start state, the tool versions, the wall-clock time, what broke, and what I had to undo. Most of that never appears in the post. The one line that does is the line no model can produce, because it did not happen to anyone else.

Run a claim ledger over the draft

This does not verify anything. It enumerates every sentence carrying a number or a first-person capability claim, so you have a finite list to check by hand instead of a vibe. Python standard library, no dependencies:

import re
from dataclasses import dataclass

NUMERIC = re.compile(r"\b\d[\d,]*(?:\.\d+)?%?")
FIRST_PERSON = re.compile(
    r"\b(?:I|we)\s+(?:built|shipped|ran|measured|tested|deployed|wrote)\b", re.I)
CITED = re.compile(r"\[[^\]]+\]\(https?://[^)]+\)")


@dataclass
class Claim:
    line_no: int
    kind: str
    text: str
    cited: bool


def extract_claims(md: str) -> list[Claim]:
    out, in_code = [], False
    for i, line in enumerate(md.splitlines(), 1):
        if line.lstrip().startswith("~~~"):   # fence marker for your own files
            in_code = not in_code
            continue
        if in_code or line.lstrip().startswith(("|", ">")):
            continue
        for sentence in re.split(r"(?<=[.!?])\s+", line):
            if FIRST_PERSON.search(sentence):
                kind = "first-person"
            elif NUMERIC.search(sentence):
                kind = "numeric"
            else:
                continue
            out.append(Claim(i, kind, sentence.strip(), bool(CITED.search(sentence))))
    return out


def _self_check() -> None:
    md = "\n".join([
        "Open rates rose 34% after the rewrite.",
        "I shipped the agent runner in March.",
        "Nothing numeric or personal in this line.",
        "~~~",
        "x = 99  # inside a code block, ignored",
        "~~~",
        "Traffic rose 300% per [Ahrefs](https://ahrefs.com/blog/).",
    ])
    claims = extract_claims(md)
    kinds = [(c.kind, c.cited) for c in claims]
    assert ("numeric", False) in kinds, kinds
    assert ("first-person", False) in kinds, kinds
    assert ("numeric", True) in kinds, kinds
    assert all(c.line_no != 5 for c in claims), "code block leaked"
    assert len(claims) == 3, kinds
    print(f"{len(claims)} claims, {sum(1 for c in claims if not c.cited)} unsourced")


if __name__ == "__main__":
    _self_check()

It prints 3 claims, 2 unsourced on the self-check. Swap the fence marker for triple backticks when you point it at real markdown. On a live draft the useful output is the unsourced count: if a 1,600-word post has 14 numeric claims and 11 of them carry no link in the same sentence, that is 11 things to check before it ships. Every one of my source-fidelity failures was on that list. The script found none of them itself. It made the list short enough that a human reading it would.

The check that actually catches a misattributed statistic is a person reading the draft against the source it names. When that person cannot be you, that is what a content audit is for.

What named accountability cost me to fix

Trust is infrastructure as much as editing. In September 2026 I found that my site emitted a different anonymous Person entity on every page — structurally, "who created this" had no consistent answer for any machine reading it. A 404 at /for was orphaning all 20 persona pages. 164 of 453 built pages shipped with no og:image. Then 32 broken internal links turned up on the live site afterwards, 22 of them because a seed file had been committed and never run against the database.

None of that is glamorous, and all of it is the Who question from Google's docs expressed as infrastructure. I cut the published count from 267 to 103 in the same pass — the scoring model behind that is in the content pruning post, and the indexing bug that preceded it is in the canonical hostname write-up.

Every one of those fixes is checkable by a reader with view-source. That is the point. A claim about experience that cannot be inspected is a claim about tone.

FAQ

Does Google penalise AI-generated content?

Not for being AI-generated. The spam policy names scaled content abuse: many pages generated primarily to manipulate rankings without adding value for users. The rater guidelines put low-effort AI content and low-effort copied content in the same clause, both conditioned on little effort, little originality and little added value.

Is E-E-A-T a ranking factor?

No. Google's helpful-content documentation states plainly that E-E-A-T itself is not a specific ranking factor, while a mix of signals identifying content with good E-E-A-T is useful. Optimising for the acronym directly is not a thing you can do.

Do I have to disclose that I used AI to write a blog post?

Google's documentation asks, as one of its self-assessment questions, whether the use of automation is self-evident to visitors through disclosures. It does not mandate a label. My own rule is narrower and easier to keep: disclose the method whenever the method affects whether a reader should trust a number.

How do I show experience if I have no client results yet?

Measure your own operation. My best-ranking pages split between build logs about this site and posts with worked arithmetic in them: position 2.8 for a deploy-pipeline write-up, 5.2 for a float-breakage model, 6.1 for a loyalty-card maths post. None was a case study when I wrote it. If you can teach a model your voice but have nothing first-hand to say, voice is the last thing that will help.

Publishing faster than you can verify? The 221 findings across my last 20 drafts were all fluent, and nearly all catchable in one pass with the source open beside the claim. Get a content audit or get in touch.