--- title: "E-E-A-T for answer engines: authors, dates and sources that machines can verify" subtitle: "What Experience, Expertise, Authoritativeness and Trust look like when the reader is a retrieval system, and how to encode them so they can be checked." canonical: https://citable.wiki/guides/eeat-for-answer-engines category: content author: "Endrit Krasniqi" date_published: 2026-04-27 date_modified: 2026-04-27 license: CC BY 4.0 --- # E-E-A-T for answer engines: authors, dates and sources that machines can verify *What Experience, Expertise, Authoritativeness and Trust look like when the reader is a retrieval system, and how to encode them so they can be checked.* ## Short answer E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) is Google's description of a reliable source, and it is not a ranking factor. For answer engines it translates into signals a machine can verify: a named author with a profile page and Person markup, visible published and updated dates that match the structured data, outbound links to primary sources with a citation list, first-hand evidence, and an About page that says who is responsible. ## Key takeaways - Google states that E-E-A-T is not a specific ranking factor; it describes what its systems try to reward, with trust as the central quality. - A retrieval system cannot judge quality like a human rater, so it leans on what it can check: author, dates, sources and site identity. - Name the author, give them a profile page, and connect the two with Person markup that carries url and sameAs. - Visible dates and datePublished/dateModified must match, and dateModified must come from an editorial field, never from build time. - Link primary sources where claims are made and emit the same list as schema.org citation; research on generative engines rewards it. - An About page with Organization markup answers the rater's question of who is responsible, and gives every article a publisher entity. ## What E-E-A-T means when the reader is a retrieval system E-E-A-T stands for Experience, Expertise, Authoritativeness and Trustworthiness. Google introduced the four-letter form on 15 December 2022, when its Search Central blog announced that "E-A-T is gaining an E for experience" in an update to the Search Quality Rater Guidelines. Those guidelines are the document Google gives to the human raters who evaluate its ranking systems. Two clarifications from Google's own documentation come first. The "Creating helpful, reliable, people-first content" page states that "E-E-A-T itself isn't a specific ranking factor", and that raters "have no control over how pages rank". The same page says that of the four qualities "trust is most important" and that content "doesn't necessarily have to demonstrate all of them". E-E-A-T is a description of what a good source looks like, not a score you can move. The description is useful for answer engines precisely because a retrieval system cannot judge quality the way a rater can. It fetches a passage, inspects a few properties of the page around it, and decides whether the passage is safe to quote. The properties it can actually inspect are the machine-readable shadow of E-E-A-T: is there a named author it can resolve to an entity, when was the page published and last changed, what does the page cite, and who is responsible for the site. Google's [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) documentation says there are "no additional requirements to appear in AI Overviews or AI Mode" and that you "don't need to create new machine readable files, AI text files, or markup" for them. The existing fundamentals apply, including the helpful-content guidance where E-E-A-T is described. The rest of this guide is about making those fundamentals legible to a machine. > **Definition: E-E-A-T** > > Experience, Expertise, Authoritativeness and Trustworthiness: the four qualities Google's Search Quality Rater Guidelines ask human raters to assess when deciding whether a page and its author are a reliable source on the page's topic. Trust is the central member; the other three are evidence for it. ## Authors a machine can resolve A byline that reads "Staff" or "Admin" is an absent author to a retrieval system. What a machine needs is a **named person, a profile page, and markup that connects the two**. Google's Article structured data documentation asks that "all the authors that are presented as authors on the web page are also included in markup", that `author.name` should "only specify the name of the author" with no job titles or honorifics, and that `author.url` be "a link to a web page that uniquely identifies the author of the article". It also states that Google understands both `sameAs` and `url` for disambiguating authors. The JSON-LD on an article page therefore looks like this: ```json { "@context": "https://schema.org", "@type": "TechArticle", "headline": "E-E-A-T for answer engines", "datePublished": "2026-04-27", "dateModified": "2026-04-27", "author": { "@type": "Person", "@id": "https://example.com/authors/endrit-krasniqi#person", "name": "Endrit Krasniqi", "url": "https://example.com/authors/endrit-krasniqi", "sameAs": ["https://github.com/Endrit-seek"], "knowsAbout": ["Answer Engine Optimization", "Structured data", "Next.js"] } } ``` The profile page itself should carry `ProfilePage` markup with the same `Person` as its `mainEntity`. Google's ProfilePage documentation describes the type as intended for sites "where creators (either people or organizations) share first-hand perspectives", and recommends `name`, `sameAs`, `description` and `image` on the entity. Reuse the `@id` so that every article on the site points at one node rather than a fresh anonymous person per page. schema.org defines `sameAs` as the "URL of a reference Web page that unambiguously indicates the item's identity", such as a Wikipedia page, a Wikidata entry or an official website. An existing GitHub, LinkedIn or ORCID profile is a stronger identity anchor than prose on your own site. `knowsAbout` is a newer schema.org property, defined as indicating "a topic that is known about - suggesting possible expertise but not implying it"; use it to declare subject areas, not to boast. ### Consistent entity names across the site Language models and knowledge graphs resolve people and organisations by name. If the byline says "E. Krasniqi", the author page says "Endrit K." and the JSON-LD says "Endrit Krasniqi", a machine sees three weak entities where you meant one strong one. Pick the canonical form, store it once in the CMS, and render the byline, the profile page, `Person.name` and the `/llms.txt` entry from that single field. The same rule applies to the site's own name and to any product you write about. ## Dates that are honest A date is the cheapest trust signal on a page and the easiest to corrupt. Google's [publication dates](https://developers.google.com/search/docs/appearance/publication-dates) guidance asks for a visible, labelled date ("Published February 4, 2019", "Last updated: Feb 14, 2018"), for `datePublished` and `dateModified` in `Article` markup, and that "the date (and optional time and timezone) match between the equivalent user-visible and structured values". It also says not to specify future dates or the date of the action described on the page, and advises removing other dates from the page if Google keeps picking the wrong one. The common failure is not missing dates but dishonest ones. A `dateModified` equal to the build timestamp tells a retrieval system that every page on the site changed today, which is the same as telling it nothing. A `dateModified` bumped on a cosmetic edit invites a model to prefer a stale page over a genuinely newer one, and to attach the wrong year to a fact it quotes from you. Derive both dates from CMS fields that an editor has to change deliberately, never from the clock: ```ts // lib/seo/article-dates.ts export function articleDates(story: { published_at: string; updated_at?: string }) { const datePublished = story.published_at; // Fall back to published_at, never to `new Date()`. const dateModified = story.updated_at || story.published_at; return { datePublished, dateModified }; } ``` Render the same two values into the visible byline and into the JSON-LD from that one function, so they cannot drift. On this site `updated_at` moves only when the substance of a guide changes; correcting a typo does not count. ## Sources a machine can follow Authoritativeness, to a rater, is reputation. To a retrieval system it is closer to **provenance**: can the claims in this passage be traced somewhere outside it? Two practices make provenance visible. The first is outbound links to primary sources at the point where a claim is made, rather than a "further reading" list of secondary posts. Link the vendor documentation, the standard, the paper. Quote it where the wording matters, as this guide does, so that a model comparing your passage with its source finds agreement rather than paraphrase. The second is a citation list the machine can read without parsing prose. schema.org's `citation` property, available on any `CreativeWork`, is defined as "a citation or reference to another creative work, such as another publication, web page, scholarly article, etc." Emit it from the same source list that renders at the bottom of the page: ```json "citation": [ { "@type": "WebPage", "name": "Creating helpful, reliable, people-first content", "url": "https://developers.google.com/search/docs/fundamentals/creating-helpful-content", "publisher": { "@type": "Organization", "name": "Google Search Central" } }, { "@type": "ScholarlyArticle", "name": "GEO: Generative Engine Optimization", "url": "https://arxiv.org/abs/2311.09735" } ] ``` There is evidence that this pays off inside generated answers. The GEO study by Aggarwal et al. tested content modifications against generative engines and reports that adding citations, quotations from sources and statistics were among the best-performing methods; its abstract states that GEO "can boost visibility by up to 40% in generative engine responses". The paper also notes that effectiveness varies by domain, so treat the figure as an upper bound from one benchmark rather than a promise. **up to 40%** — visibility boost in generative engine responses reported for the best-performing GEO methods, which include adding citations, quotations and statistics (Source: [GEO: Generative Engine Optimization (arXiv)](https://arxiv.org/abs/2311.09735)) ### First-hand evidence Experience is the hardest of the four to encode, because it lives in the content rather than around it. Google's 2022 post describes it as whether content was produced with "actual use of a product, having actually visited a place or communicating what a person experienced". For technical writing that means working code you ran, output you observed, numbers from your own logs and screenshots you took, each labelled as such. A passage that says "on this site, X produced Y" is more quotable and harder to fabricate than one that says "experts recommend X". > **Warning: Do not manufacture signals** > > Invented author personas, borrowed credentials, `dateModified` bumps and citation lists padded with links nobody consulted are detectable by the same consistency checks that make honest signals valuable. Google's helpful-content guidance frames the question as who created the content, how, and why. If the honest answer is unflattering, the fix is the content, not the markup. ## An About page and a site-level entity The Search Quality Rater Guidelines include a section on finding who is responsible for a website and who created the content on a page, and treat the absence of that information as a negative signal on topics where it matters. A retrieval system runs a cruder version of the same check: does the site declare an organisation, and does that organisation resolve to something beyond the site itself? Google's Organization structured data documentation recommends placing organisation markup "on your home page, or a single page that describes your organization, for example the about us page", with `name`, `url`, `logo` and `sameAs`. This site's [About page](/about) carries that node, and every guide's `publisher` points at it by `@id`: ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://example.com/#organization", "name": "Citable", "url": "https://example.com/", "logo": "https://example.com/logo.png", "sameAs": ["https://github.com/Endrit-seek"] } ``` Keep the About page in plain HTML: who runs the site, what it covers, how content is produced, and how to reach you. Its job is to answer "who is behind this" for a rater and a model alike. **E-E-A-T signals a machine can verify** - [ ] Every page has a named author, a byline linking to a profile page, and Person markup with url and sameAs - [ ] One canonical spelling of each author, organisation and product name, stored once and rendered everywhere - [ ] Visible published and updated dates that match datePublished and dateModified exactly - [ ] dateModified derived from an editorial field, never from build time or trivial edits - [ ] Outbound links to primary sources at the claim, plus a citation list emitted as schema.org citation - [ ] First-hand evidence labelled as such: code you ran, data you collected, behaviour you observed - [ ] An About page with Organization markup, and publisher on every article pointing at it - [ ] No signal in markup that is not also visible on the page > **Tip: Where to go next** > > The markup in this guide is generated from CMS fields; [Structured data for AI answers](/guides/structured-data-for-ai-answers) shows the full Article, Person and FAQPage graph and how to keep it in sync with the visible text. For the writing side, [How to write answer-first content](/guides/how-to-write-answer-first-content) covers the passage structure that these trust signals wrap around. ## Frequently asked questions ### Is E-E-A-T a ranking factor for AI Overviews or ChatGPT? No. Google's helpful-content documentation states that E-E-A-T itself is not a specific ranking factor, and its AI features documentation says there are no additional requirements to appear in AI Overviews or AI Mode. Other answer engines publish no equivalent. E-E-A-T is useful as a checklist of the trust signals a retrieval system can verify, not as a score to optimise. ### Do I need a real named author on every page? For content you want cited, yes. A byline that resolves to a profile page and to Person markup with url and sameAs gives a machine an entity to attach the page to. Pages by an organisation rather than a person can use Organization as the author, but it should still resolve to an About page and external profiles. ### Should I update dateModified whenever I touch a page? Only when the substance changes. Google asks that visible and structured dates match and warns against dates that do not reflect when the page was published or updated. A dateModified set from the build clock, or bumped for typo fixes, tells a retrieval system that nothing on the site is stable and can attach the wrong date to your facts. ### What counts as a primary source? The document closest to the fact: vendor documentation, a standard, a published paper, an official announcement, or your own measured data. A blog post summarising one of those is secondary. Link primary sources at the point of the claim, quote them where the wording matters, and list them in a citation block that is also emitted as schema.org citation. ### How do I show Experience on a technical page? Include evidence that you did the thing: code you ran, output you observed, numbers from your own logs, screenshots you took, each labelled as yours. Google's 2022 update describes Experience as content produced with actual use of a product or first-hand involvement. Passages of the form 'on this site, X produced Y' are both more quotable and harder to fabricate. ## Sources 1. [Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) — Google Search Central (2025) 2. [Our latest update to the quality rater guidelines: E-A-T gets an extra E for Experience](https://developers.google.com/search/blog/2022/12/google-raters-guidelines-e-e-a-t) — Google Search Central Blog (2022) 3. [Search Quality Rater Guidelines (PDF)](https://static.googleusercontent.com/media/guidelines.raterhub.com/en//searchqualityevaluatorguidelines.pdf) — Google (2025) 4. [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) — Google Search Central (2025) 5. [Article (Article, NewsArticle, BlogPosting) structured data](https://developers.google.com/search/docs/appearance/structured-data/article) — Google Search Central (2025) 6. [GEO: Generative Engine Optimization](https://arxiv.org/abs/2311.09735) — Aggarwal et al., KDD 2024 (arXiv) (2023) ## Related guides - [Structured data for AI answers: the schema.org types that matter](https://citable.wiki/guides/structured-data-for-ai-answers) - [How to write answer-first content that LLMs can quote](https://citable.wiki/guides/how-to-write-answer-first-content) - [What is Answer Engine Optimization (AEO)?](https://citable.wiki/guides/what-is-answer-engine-optimization) --- Source: https://citable.wiki/guides/eeat-for-answer-engines Author: Endrit Krasniqi More: https://citable.wiki/llms.txt