E-E-A-T for AI: authorship, sourcing, dates
Crawlmind Engineering··5 min read
E-E-A-T is the framework Google uses to judge content quality, standing for Experience, Expertise, Authoritativeness, and Trust, and answer engines now reward a machine-readable version of the same inputs a human rater would look for: who wrote it, what it cites, and when it was last true. Google added the second E, for Experience, to its rater guidelines in December 2022, with Trust sitting at the center of the model (see the Google Search Central announcement). The framework was built for human quality raters reading the Search Quality Rater Guidelines, not for algorithms. The shift in 2026 is that LLM answer engines apply a related judgment automatically, at crawl time, on whatever signals they can extract from your HTML. That changes E-E-A-T from a writing philosophy into a markup problem.
This post covers the three signals that translate most cleanly into something a crawler can read: authorship, sourcing, and dates. Each one has a concrete implementation, and most sites get at least one of them wrong.
#Authorship: make the byline resolvable
A byline that reads "by the Marketing Team" tells an engine nothing. The signal an engine can use is an author it can resolve to a real person with a track record. The practical unit here is Person schema attached to the article and pointed at the wider web.
Google's own Article structured data guidance recommends the author property, and it is specific about how to fill it: use the Person type for an individual (not a generic type), put only the person's name in author.name without job titles or honorifics, list multiple authors in separate author fields rather than jamming them into one string, and include a url or sameAs pointing to something that identifies the author off your site.
That last field is the one that matters most for AI trust. A sameAs link to a LinkedIn profile, a personal site, or an ORCID record gives the engine a way to corroborate that the author exists and knows the subject. Here is the minimum shape:
{
"@type": "Article",
"author": {
"@type": "Person",
"name": "Jane Okoro",
"url": "https://example.com/authors/jane-okoro",
"sameAs": ["https://www.linkedin.com/in/janeokoro"]
}
}
Two things to get right. First, the author's on-site bio page (url) should carry its own Person markup and describe real, specific experience, because that is where Experience and Expertise become legible. "Jane has run technical SEO for three B2B SaaS companies" is a signal. "Jane is a passionate content creator" is noise. Second, keep the byline consistent across every post that author writes, so the engine can accumulate a track record under one stable identity rather than three slightly different name strings.
#Sourcing: cite the primary source, and be one
Sourcing is the signal that separates firsthand knowledge from rewritten summaries, and it works in two directions.
Outbound, link to primary sources rather than to other blogs that link to primary sources. When you cite a statistic, link the study, the filing, or the documentation, not a listicle that mentions it. Answer engines deduplicate aggressively and try to reward the origin of a claim, so a page that routes readers to originals reads as more trustworthy than one that launders numbers through intermediaries.
Inbound, being the primary source is the strongest sourcing signal you have. This is where authority concentration matters. In an analysis of roughly 1.2 million ChatGPT responses and nearly 98,000 citations, Kevin Indig found that 67% of citations on a topic went to just 30 domains, with the top 10 domains capturing 46% of citations on product comparison topics. You cannot out-authority Wikipedia on general knowledge. You can own the citation slot for a narrow claim that only you can make, because you measured it.
The content-strategy implication is blunt: publish original data. A short post reporting a number you produced, with the method stated plainly, is more citable than a long guide that synthesizes numbers everyone else already has. The engines were trained on the originals, so a better-written copy earns nothing. Sourcing, in the AI-trust sense, means either pointing at the origin of a fact or being it.
#Dates: tell the engine when the page was last true
Freshness has become a load-bearing signal, and it is the easiest of the three to implement and the easiest to get quietly wrong. Google's Article guidance asks for both datePublished and dateModified in ISO 8601 format. The dateModified value is the one AI engines lean on to decide whether a page is current.
The magnitude is worth stating. One 2026 analysis found that about half of all AI-cited content is less than 13 weeks old, and pages under 30 days old earn an estimated 3.2 times more AI citations than older pages, with roughly a one-year half-life on citation potential. For evergreen topics that decay is frustrating. For anything with a year in the query, or anything about a fast-moving product category, it is decisive.
Three rules keep dates honest:
- Only bump
dateModifiedwhen you actually changed the substance of the page. Touching a template and republishing a hundred URLs with today's date is the kind of pattern that erodes trust rather than building it. - Make the visible date match the structured date. A page that says "Updated July 2026" in the byline but carries a
dateModifiedof 2024 in its JSON-LD sends a mixed signal, and the mismatch itself reads as neglect. - Put real change behind the new date. Refresh the statistics, re-check the claims, note what changed. A date is a promise that the content is still true as of then. Keep the promise.
#The through line
All three signals are the same request restated: give the engine something verifiable. A resolvable author it can corroborate. A primary source it can trace, or an original fact only you hold. A modification date it can trust because the content behind it actually moved. E-E-A-T started as guidance for humans reading carefully. The version that decides AI citations rewards the sites that made those same signals easy for a machine to read, and most of that work is markup you can ship this week.
Related field notes
July 3, 2026 · 5 min
How to brief writers for GEO
A content brief that pushes writers toward citable answers instead of keyword density, so posts get quoted by AI engines.
June 30, 2026 · 4 min
llms.txt explained: what belongs in it
What llms.txt is, what the spec says belongs inside it, and an honest look at whether AI engines actually read it in 2026.
June 29, 2026 · 5 min
Answer-engine-ready docs, without dumbing down
Making documentation quotable by AI assistants is a structure problem, not a reading-level problem. Here is how to do it without cutting depth.
Share or discuss
New posts, no spam. Roughly monthly. Unsubscribe with one click.