Trust & Authority Signals

Why this matters more to an answer engine than to a search engine

Start with the difference in what each system is on the hook for.

A ranking system orders ten links by likely usefulness and hands the list to a person. If the third result is wrong, the person is the one who acted on it. The search engine's liability is diffuse — it presented options, and presenting a bad option among good ones is a ranking miss, not a false statement.

An answer engine does something categorically different. It reads sources, extracts claims, and restates them as prose in its own voice. When it tells a user "the renewal window is 30 days," that sentence is now the assistant's assertion, not a link the user chose to follow. If your page was wrong, the assistant was wrong. Every generative answer is a small act of vouching.

That gives the system a structural reason to prefer sources that show their work — a reason a pure ranking system does not have to the same degree. Not because any vendor has published a "trust score," but because a source that names its author, names its own sources, and dates its claims is cheaper to verify and cheaper to be wrong about. If the assistant repeats a claim that a page attributes to a named study, the failure is legible and shared. If it repeats an unattributed assertion from an anonymous page, it owns the error alone.

There is a second, more mechanical reason. Generative answers are typically produced by grounding: the model is given retrieved passages and instructed to answer from them, often with instructions to cite. A passage that already contains its own provenance — "Ahrefs' 2026 analysis found…" — is trivially citable. A passage that says "studies show" forces the system either to drop the claim or to assert it barehanded. Attribution inside the sentence is not a courtesy; it is what makes a sentence liftable.

Authorship, done properly

Most sites treat the byline as a formality. It is the single cheapest place to convert an anonymous assertion into a checkable one, and the majority of B2B content still ships under "Team" or the company name.

The author page matters more than people expect. A byline is a claim; the author page is where the claim becomes checkable. It should list the person's actual work — what they do, where, for how long, and what they have published — and it should link outward to profiles that exist independently of you. An author page that says nothing a stranger could verify is a byline with extra steps.

On credentials, the rule is that they should be specific enough to be falsifiable. "15+ years of experience" is not a credential; it is an adjective. A board certification, a professional licence, a named degree from a named institution, a maintainer role on a named project — those are statements someone can go and check, which is exactly what makes them worth something.

Person markup that says something

Everything in the markup below should also be visible on the rendered page. Structured data is a restatement of what the reader sees, never a place to assert credentials the page does not show. Replace the bracketed placeholders with your real values — they are template slots, not example people.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/#/schema/person/[author-slug]",
  "name": "[Full Name]",
  "givenName": "[First]",
  "familyName": "[Last]",
  "jobTitle": "[Specific Role]",
  "description": "[One sentence of what this person actually does, not adjectives.]",
  "url": "https://example.com/authors/[author-slug]",
  "image": "https://example.com/img/authors/[author-slug].jpg",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  },
  "knowsAbout": [
    "[Narrow topic 1]",
    "[Narrow topic 2]"
  ],
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "[Institution]",
    "sameAs": "https://www.wikidata.org/wiki/[Q-number]"
  },
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "[Credential name, e.g. Board Certification in Internal Medicine]",
      "credentialCategory": "certification",
      "recognizedBy": {
        "@type": "Organization",
        "name": "[Issuing body]",
        "url": "https://[issuing-body-domain]/"
      }
    }
  ],
  "sameAs": [
    "https://www.linkedin.com/in/[handle]",
    "https://github.com/[handle]",
    "https://orcid.org/[0000-0000-0000-0000]"
  ]
}
</script>

<!-- Wrong: hasCredential is not a text property -->
<li itemprop="hasCredential">PhD Computer Science, MIT</li>
<li itemprop="hasCredential">15+ years database engineering</li>

"hasCredential": {
  "@type": "EducationalOccupationalCredential",
  "name": "PhD, Computer Science",
  "credentialCategory": "degree",
  "educationalLevel": "Doctorate",
  "recognizedBy": {
    "@type": "CollegeOrUniversity",
    "name": "[Institution]",
    "sameAs": "https://www.wikidata.org/wiki/[Q-number]"
  }
}

Entity linking: the highest-value item on this page

Before any system can decide whether to trust you, it has to decide who you are. That step is called entity resolution, and it happens whether or not you participate in it.

Consider what a retrieval system faces. Your company is called Atlas. So is a mapping startup, a defunct logistics firm that used to own a similar domain, a Marvel character, and a mountain range. Your author is called J. Rivera — so are a cardiologist, a footballer, and roughly nine hundred LinkedIn accounts. Any reputation the system has accumulated about "Atlas" or "J. Rivera" is worthless to you unless it is attached to the right node. Reputation that cannot be resolved to an entity cannot be applied to you.

sameAs is how you hand over the answer instead of hoping for a good guess. It is an assertion that this thing and that identifier are the same thing. Point it at identifiers that knowledge graphs are actually keyed on and you are supplying a primary key rather than requesting a fuzzy string match.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "[Organization Name]",
      "legalName": "[Legal Entity Name]",
      "url": "https://example.com/",
      "description": "[The same one-line description used on every third-party profile.]",
      "sameAs": [
        "https://www.wikidata.org/wiki/[Q-number]",
        "https://en.wikipedia.org/wiki/[Article_Title]",
        "https://www.linkedin.com/company/[handle]",
        "https://github.com/[org]",
        "https://www.crunchbase.com/organization/[slug]"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#/schema/person/[author-slug]",
      "name": "[Full Name]",
      "url": "https://example.com/authors/[author-slug]",
      "worksFor": { "@id": "https://example.com/#organization" },
      "sameAs": [
        "https://orcid.org/[0000-0000-0000-0000]",
        "https://www.linkedin.com/in/[handle]",
        "https://github.com/[handle]"
      ]
    }
  ]
}
</script>

Consistency is the part people skip

Declaring sameAs is half the job. The other half is making sure the profiles you point at agree with each other. If your site says "Acme Robotics, Inc.", LinkedIn says "Acme Robotics", Crunchbase says "ACME Robotic Systems", and each describes a different business in a different vocabulary, you have supplied contradictory evidence about your own identity and made resolution harder rather than easier.

• Pick one canonical name string and one canonical one-line description. Use them verbatim everywhere — your own site, every social profile, every directory, every conference bio.
• Keep the same logo and the same primary URL across profiles. Visual and URL consistency are cheap corroboration.
• Make the links bidirectional where the platform allows it. A LinkedIn company page that links back to your domain closes the loop; a one-way assertion is weaker.
• Audit the profiles you have forgotten about. An abandoned account with a three-year-old description and a former address is contradicting you right now.
• Do the same for authors. The role in the JSON-LD, the role on the author page, and the role on LinkedIn should be the same role.

Two limits worth stating plainly. First, sameAs is not a link-building field — every URL in it must be a profile of this entity, controlled by you or unambiguously about you. Stuffing it with directories you do not own dilutes the signal and, at scale, reads as manipulation. Second, you cannot shortcut Wikidata or Wikipedia. Creating a self-referential entry for an organization nobody independent has written about tends to get reverted, and the underlying requirement — that someone else has taken you seriously in public — is the thing being measured. See schema markup for how to wire these entities together with @id so they form one graph rather than a pile of disconnected blocks.

E-E-A-T, described accurately

E-E-A-T stands for Experience, Expertise, Authoritativeness and Trust. It comes from Google's Search Quality Rater Guidelines — the manual used by human contractors who rate sample results to evaluate whether Google's systems are working. The first "E", Experience, was added in December 2022 to capture first-hand involvement: has the person writing about a product actually used it, been to the place, had the condition.

Why should any of it transfer to answer engines, which are not running Google's rater programme? For mechanical reasons rather than doctrinal ones. The properties E-E-A-T names happen to be the properties that make a source cheap to verify and safe to restate: a named author is a resolvable entity, a named source is a checkable claim, first-hand specifics are corroborable against other pages, and a site that is transparent about its identity is easier to fit into a knowledge graph. Any system building a grounded answer has an interest in those properties whether or not it has ever heard of the acronym. The framework is a useful checklist precisely because it enumerates things that are independently mechanically useful — not because an answer engine is secretly scoring you against it.

Citation quality

How you cite matters as much as whether you cite, and the reason is specific to extraction: a lifted sentence loses the link but keeps the words.

When a passage from your page is pulled into a retrieval pipeline, it is usually converted to plain text first. The anchor tag becomes bare words. If the only place you identified your source was inside the hyperlink — "bot traffic has grown significantly" — the resulting passage is an unattributed claim, and an unattributed claim is one a careful system will either drop or restate without confidence. Name the source in the sentence and the attribution survives the conversion.

Rules that hold up

• Primary over secondary. Cite the study, the filing, the specification, the vendor's own changelog — not the article about it. Every hop adds a chance the number was rounded, the caveat dropped, or the population misdescribed. If you can only find the secondary source, say so: "as reported by X, citing Y" is honest and still useful.
• Name the source in the prose. Organization, document title, and year, in the sentence or the sentence next to it. The hyperlink is for humans who want to go there; the words are for everything else.
• Give the magnitude and the period. "Grew significantly" is unusable. "Rose from roughly 76% to roughly 38% between the two measurement windows" can be checked, compared and quoted.
• Make links resolvable and keep them that way. Deep-link to the specific document, not the publisher's homepage. Run a link checker on a schedule — a citation that 404s is worse than no citation, because it advertises that nobody has read this page since it shipped.
• Date the claim, not just the page. "As of the June 2026 release" tells a reader in 2028 exactly how much to discount. An undated statistic silently ages into a falsehood.
• Describe the method when it changes the meaning. Sample, population, and measurement window are frequently the difference between a finding and a factoid.
• Cite your own limits. If a number is your own internal telemetry, say that. Self-reported data is legitimate evidence when it is labelled as self-reported and misleading when it is dressed up as research.

Dates: three different facts

Most sites render one date and call it "Updated." There are three distinct facts here, and collapsing them destroys information a reader — human or otherwise — needs.

The distinction between modified and reviewed is worth the extra field. "Last modified March 2024" on a page about a fast-moving subject implies neglect. "Reviewed August 2026; no changes required" says something entirely different about the same underlying text: a person looked, and it held up. In regulated and medical contexts a named reviewer is standard practice for exactly this reason.

<!-- Visible on the page, machine-readable, and derived from the same CMS fields
     that populate the JSON-LD, so the two cannot drift apart. -->
<div class="content-dates">
  <p>
    Published
    <time datetime="2026-01-15">15 January 2026</time>
    &middot; Last substantive update
    <time datetime="2026-06-02">2 June 2026</time>
  </p>
  <p>
    Reviewed <time datetime="2026-08-11">11 August 2026</time>
    by <a href="/authors/[author-slug]" rel="author">[Reviewer Name]</a>,
    [Role] &mdash; no changes required.
  </p>
</div>

"datePublished": "2026-01-15T09:00:00-08:00",
"dateModified": "2026-06-02T11:30:00-07:00",
"reviewedBy": {
  "@type": "Person",
  "@id": "https://example.com/#/schema/person/[reviewer-slug]"
}

Freshness is one of the few things here with public measurement behind it. Ahrefs' 2026 analysis of AI search overlap found that URLs cited in AI answers skew roughly 25.7% fresher than the web at large (Ahrefs, 2026). That is a correlation, not an instruction — recency is entangled with topic, coverage and competition — but it is enough to say that a page which is genuinely current has an advantage over one that is not.

A worked rewrite

Everything above compounds in a single paragraph. Here is an unremarkable piece of marketing prose — the kind that exists on tens of thousands of product pages — and the same claim rewritten so that it can be attributed, verified, and lifted intact.

Note what the rewrite does not do: it does not invent a percentage to sound more rigorous. If you do not have the measurement, the honest move is to describe what you did measure and link the artifact — not to manufacture a number. A fabricated statistic is the one failure mode that gets worse the more successfully your content spreads.

Trust theatre to avoid

Several popular tactics are the appearance of a trust signal without the substance. They are worth naming because they are easy to ship and they actively cost you.

Related reading: schema markup covers the machine-readable half of this — how to express these entities so they form one connected graph. What gets cited covers what is actually known about citation selection, and the glossary defines the vocabulary used here.