Fixing Missing Author and Trust Signals for AI Crawlers

Five questions a machine asks about your page

Answer engines have to decide which pages to draw on and which to credit. Their providers say little in public about exactly how they weigh sources, so nobody can promise that an author box earns a citation. What is certain is that a system cannot use information it cannot find. When a crawler has your page, it is effectively trying to answer five questions from the markup alone:

1. Who wrote this? A named person, in text, near the headline.
2. Who is that person? A page at a stable address that describes them, and links to places elsewhere that confirm the same identity.
3. Who published it? An organisation or individual with a name, an about page and contact details.
4. When? A published date and, where it changed materially, an updated date, both machine-readable.
5. Based on what? Links to the sources behind the claims, so the statements can be traced.

This guide is about the machine side of those answers: where they sit in the HTML and structured data, and how to keep them consistent. The human side, such as reviews, guarantees and the wording of bios, is covered by the E-E-A-T trust signals guide and the author bios guide.

Where each signal has to appear

Each fact should exist in two forms: as visible text on the page and as structured data that states the same thing. When both agree, a crawler has nothing to guess. When they disagree, or when one is missing, the machine has to choose, and it may choose badly.

A byline a crawler can actually read

The byline is the first place a crawler looks, and the most common place it goes missing. Designers sometimes remove it for a cleaner look; some themes render it from a script after the page loads; others print only a first name or a team name. Put the full name in the server-rendered HTML, next to the headline, and link it to the author page.

<article>
  <h1>How to size a heat pump for a three-bedroom house</h1>
  <p class="byline">
    By <a href="/team/morag-ellison/" rel="author">Morag Ellison</a>,
    heating engineer at Northfield Heating
    &middot; Published <time datetime="2026-04-02">2 April 2026</time>
    &middot; Updated <time datetime="2026-08-19">19 August 2026</time>
  </p>
  ...
</article>

A few details make this easier for machines:

• Inside the article. Placing the byline inside <article> ties it to that piece of content rather than to the site in general.
• A real link. An ordinary <a href> to the author page lets a crawler follow it. The rel="author" value is a standard HTML link type that labels the link's purpose; it does no harm and costs nothing.
• Machine-readable dates. The datetime attribute gives an unambiguous date in ISO format, whatever the visible wording.
• The same name everywhere. Use one spelling of the name on the byline, the author page and the structured data. "M. Ellison" on one page and "Morag Ellison" on another look like two people to a simple matching system.

Test it by fetching the page with curl and searching for the author's name. If it is not in the response, it is not in the byline a non-rendering crawler receives.

Author pages that confirm identity

A byline names someone; an author page tells the machine who they are. Each writer needs one page at an address that will not change, even if the site is redesigned. On that page:

• The full name as the main heading, matching the byline exactly.
• Their role and the organisation they write for.
• A few sentences of relevant background, written as plain text rather than in an image or a slider.
• The subjects they cover, which helps a machine connect the person to a topic.
• Links to profiles elsewhere that belong to the same person, such as a professional body listing, a university page or a professional networking profile.
• A list of their articles with real links.

The outward links matter for identity. When the author page and a profile on another site both describe the same person and point at each other, a system has independent confirmation that the name refers to someone real. Only link profiles the person controls or that genuinely describe them, and remove links when someone leaves.

Joining author, article and publisher in JSON-LD

Structured data turns the visible facts into statements a machine can parse without guessing. The pattern that works best is a single graph in which each entity is described once, given an @id, and referred to by that identifier wherever it is needed. The article points to the author and the publisher; the author page describes the person fully.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://www.example.co.uk/guides/heat-pump-sizing/#article",
      "headline": "How to size a heat pump for a three-bedroom house",
      "datePublished": "2026-04-02T09:00:00+01:00",
      "dateModified": "2026-08-19T14:30:00+01:00",
      "mainEntityOfPage": "https://www.example.co.uk/guides/heat-pump-sizing/",
      "author": { "@id": "https://www.example.co.uk/team/morag-ellison/#person" },
      "publisher": { "@id": "https://www.example.co.uk/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://www.example.co.uk/team/morag-ellison/#person",
      "name": "Morag Ellison",
      "url": "https://www.example.co.uk/team/morag-ellison/",
      "jobTitle": "Heating engineer",
      "worksFor": { "@id": "https://www.example.co.uk/#organization" },
      "sameAs": [
        "https://directory.example.org/members/morag-ellison"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://www.example.co.uk/#organization",
      "name": "Northfield Heating Ltd",
      "url": "https://www.example.co.uk/",
      "logo": "https://www.example.co.uk/images/logo-512.png"
    }
  ]
}
</script>

Points that commonly go wrong:

• Put only the name in name. Google's Article guidance asks for the author's name alone, without job titles or "Posted by". Put the role in jobTitle.
• Use a Person for people. If a real person wrote the article, do not name the company as the author. Use Organization as author only where content genuinely has no individual writer.
• Keep identifiers stable. If the @id changes with each redesign, previous references stop meaning the same entity.
• Print it on the server. JSON-LD injected by a tag manager may be seen by Google, which renders JavaScript, but many AI crawlers read only the initial HTML.

The JSON-LD coverage guide explains how to extend the same graph to other page types.

Making the publisher identifiable

Even a well-marked author is only half the answer. A machine also wants to know which organisation stands behind the site, and whether it can be contacted. For a small business this does not require much, but it has to be findable from every page in plain HTML links.

• An about page that states the legal or trading name, what the business does, where it is based and who runs it.
• A contact page with a postal address or service area, a phone number or email address, and ideally the company registration number for a limited company.
• An editorial or review policy for sites that publish advice: who writes, who checks, how errors are corrected.
• Footer links to all three, as ordinary links in the server HTML, so a crawler can reach them from any page.

Describe the organisation once in structured data, on the home page or about page, with its name, address, logo and profiles, and point every article's publisher at it by @id. The name in the structured data should match the name in the footer and on the about page exactly, including "Ltd" or its absence.

Sources a machine can follow

Claims that link to where they came from are easier to check, for people and for systems that compare sources. A bibliography in plain text at the bottom of a page is better than nothing, but a crawler cannot follow it.

• Link the claim, not the page footer. Put the link on the sentence that makes the claim, with anchor text that says what the source is: "the Met Office climate averages for Sheffield", not "here".
• Prefer primary sources. Link the official guidance, standard or dataset itself rather than an article summarising it.
• Date figures. Say when a statistic or price applies, because answer engines may quote the sentence long after you wrote it.
• Mark quotations. Use <blockquote cite="…"> or <q> for quoted material and name the speaker in text.

If you want to declare sources in structured data, schema.org's citation property accepts a URL or a CreativeWork. It is optional, and the visible links matter more.

The fix, step by step

Awkward cases

Ghostwritten and edited content

If an agency drafts articles and your staff expert reviews and approves them, name the person who takes responsibility for the content. A separate "Reviewed by" line with its own link, and a matching reviewedBy property on the WebPage in structured data, is an honest way to show both roles.

Content produced with AI help

Google's guidance on helpful content suggests explaining how content was produced where readers would reasonably want to know, including the use of automation. A short note on the editorial policy page, plus a named human who checked the piece, is clearer than an anonymous byline.

Writers who leave

Keep the author page and their articles attributed to them; the work was still theirs. Update the page to say they previously wrote for you, and remove the worksFor link and any contact details that no longer apply.

Pen names

A consistent pen name with an author page is better than no name, but do not invent credentials, photos or external profiles for it. A fictional identity with made-up qualifications is exactly the kind of signal that erodes trust once discovered.

Several authors on one piece

List each name in the byline and give author an array of Person references in the same order.