Authors, About pages and editorial policy: showing who is behind your content

Why trust pages matter

Google suggests judging your content by three questions: Who created it, How it was created, and Why. The first two are answered almost entirely by a handful of pages and page elements that many sites treat as an afterthought: the byline, the author page, the About page, the contact page and the editorial policy.

These pages are where a sceptical reader goes to check you. Quality raters are trained to do the same, and Google's own self-assessment questions point there directly, asking whether readers get “background about the author or the site that publishes it, such as through links to an author page or a site's About page”. If someone searches for your writer's name or your company and finds nothing, or finds something that contradicts your pages, no amount of markup fixes that.

The concept behind all of this, experience, expertise, authoritativeness and trust, is covered in the lesson “E-E-A-T: the four pillars”. This lesson is the practical build: what to put on each page, where to link it from and how to mark it up.

What Google officially says

The “Who” section of Google's guide to helpful content asks three questions about authorship:

• “Is it self-evident to your visitors who authored your content?”
• “Do pages carry a byline, where one might be expected?”
• “Do bylines lead to further information about the author or authors involved, giving background about them and the areas they write about?”

The same section is just as clear about the opposite. “However, avoid using deceptive authorship information.”

Two more lines frame the rest of this lesson. Google asks: “Is this content written or reviewed by an expert or enthusiast who demonstrably knows the topic well?” And of the four E-E-A-T aspects, “trust is most important.”

Bylines: where they go and what they link to

A byline is the visible line that names who wrote the piece. It is the entry point to everything else in this lesson, so get the basics right.

• Position. Directly under the H1, before the body text, where readers look for it. A byline hidden in the footer or only at the end of a long article is easy to miss.
• A real, consistent name. “By Jane Doe, Senior Editor”. Use the same spelling of the name in every byline, on the author page and in the markup.
• A link. The name links to the author's page on your site, for example https://example.com/authors/jane-doe/. Google's question is whether bylines “lead to further information about the author”; a plain-text name does not.
• Several authors. Name and link each one: “By Jane Doe and John Smith”.
• Reviewers. For health, money, legal or safety topics, a separate line such as “Medically reviewed by Dr Ana Ruiz” with its own link tells readers an expert checked the piece. Only use it when the review really happened.
• Organisation as author. For unsigned content written by a team, such as product documentation or company news, the byline can name the organisation: “By the Example Energy team”, linked to the About page. Do not invent a person to fill the slot.
• Dates beside the byline. Show “Published” and, when the content has been substantially revised, “Updated”, with real dates. The section on dates below covers the rules.

Not every page needs a byline. Google's question says “where one might be expected”: articles, guides, reviews and news yes; a product page, a category page or a pricing page usually no. Those pages earn trust through the About and contact pages instead.

Author pages: the anatomy

An author page is the destination of every byline. It should answer, in a minute of reading, who this person is, why they know the topic and where else you can check them. Each author gets one stable, indexable URL, linked from every byline and listed in your sitemap.

Name and photo

Use the same name as in the bylines and a real, recent photo of that person. A stock photo or an AI-generated face presented as the author is exactly the kind of fabricated profile Google calls deception. If an author does not want a photo published, leave it out rather than substitute one.

Role and a specific bio

One short paragraph, usually 80–150 words, that is specific to what this person covers on your site: their job, what they have done in the field and why that qualifies them. “Jane is a passionate writer who loves helping people” says nothing. “Jane has carried out home energy audits since 2014 and writes our heat pump and insulation guides” says a lot.

Experience and credentials

List real roles, qualifications and memberships that a reader could check: a professional registration, a degree, a previous employer, a book. Link to the issuing body or an external profile where you can. Do not inflate titles; one false credential undermines every true one.

Topics covered

Name the areas this author writes about. It sets expectations for readers and connects the person to a subject rather than to the whole site.

A list of their articles

A paginated list of everything the author has written or reviewed, with normal links. It shows a track record and gives crawlers a path to that work.

Profiles and contact

Links to the author's profiles elsewhere (a professional network, a personal site, a university page) and a route to reach them or the editors. These are the same URLs you will put in sameAs.

One URL per author

Keep a single canonical address per person, such as /authors/jane-doe/. Do not let the CMS create separate author archives for /author/jdoe/ and /author/jane/, and do not noindex or block the author pages you want people to find. If an author leaves, keep the page and their articles; mark them as a former contributor rather than deleting the history.

Marking up authors in Article structured data

Article structured data (types Article, NewsArticle or BlogPosting) can say who wrote the page. Google says of Article markup: “There are no required properties; instead, add the properties that apply to your content.” For authors, it publishes a short list of best practices. Each of these is a direct quote:

• “Make sure that all the authors that are presented as authors on the web page are also included in markup.”
• “When specifying multiple authors, list each author in their own author field”, and “Don't merge multiple authors in the same author field”.
• “To help Google better understand who the author is, we strongly recommend using the type and url (or sameAs) properties.”
• “In the author.name property, only specify the name of the author.”
• “Use the Person type for people, and the Organization type for organizations.” And: “Don't use the Thing type, and don't use the wrong type (for example, using the Organization type for a person).”

What does not belong in author.name: the publisher (“The name of the publisher. Instead, use the publisher property.”), the job title (use jobTitle), honorifics (use honorificPrefix or honorificSuffix) and introductory words such as “posted by”.

For author.url, Google wants “A link to a web page that uniquely identifies the author of the article. For example, the author's social media page, an "about me" page, or a bio page.” When that page is on your own site, Google adds: “If the URL is an internal profile page, we recommend marking up that author using profile page structured data.” You can use sameAs as well or instead, because “Google can understand both sameAs and url when disambiguating authors.” For an organisation as author, “If the author is an organization, you could link to the organization's home page.”

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to size a heat pump",
  "datePublished": "2026-03-04",
  "author": {
    "@type": "Thing",
    "name": "By Jane Doe, Senior Editor, and John Smith | Example Energy"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to size a heat pump",
  "image": ["https://example.com/img/heat-pump-16x9.jpg"],
  "datePublished": "2026-03-04T08:00:00+00:00",
  "dateModified": "2026-09-18T10:30:00+00:00",
  "author": [{
    "@type": "Person",
    "name": "Jane Doe",
    "jobTitle": "Senior Editor",
    "url": "https://example.com/authors/jane-doe/"
  },{
    "@type": "Person",
    "name": "John Smith",
    "url": "https://example.com/authors/john-smith/"
  }],
  "publisher": {
    "@type": "Organization",
    "name": "Example Energy",
    "url": "https://example.com/"
  }
}

A few practical points around that example:

• Dates. For both datePublished and dateModified, Google says: “We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot.”
• Reviewers are not authors. If an expert reviewed the piece but did not write it, do not add them to author. Show the reviewer line on the page; schema.org has a reviewedBy property on WebPage, but Google's Article documentation does not list it, so treat it as optional extra description, not as a feature switch.
• Organisation authors. For team content, use "@type": "Organization" with your organisation's name and home page as url.
• No guarantees. Google is explicit that it “does not guarantee that features that consume structured data will show up in search results.” Markup describes; it does not create trust that the page itself lacks.

ProfilePage structured data for author pages

“ProfilePage markup is designed for any site where creators (either people or organizations) share first-hand perspectives.” It describes a page whose subject is one person or organisation, which makes it the natural markup for an author page.

The key content rule: “The primary focus of the page must be a single person or organization that is affiliated with the overall website.” Google's valid examples include “An author page on a news site”, “An "About Me" page on a blog site” and “An employee page on a company website”. Among the invalid ones is “The main home page of a store (usually contains lots of non-profile info)”.

The required property is mainEntity, “The person or organization that this profile page is about.” Inside it, name is required. Recommended properties include:

On https://example.com/authors/jane-doe/ that looks like this. Note that the page URL is the same one used as author.url in the Article markup above, and the name is spelled identically:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "dateCreated": "2024-03-11T09:00:00+00:00",
  "dateModified": "2026-09-02T14:20:00+00:00",
  "mainEntity": {
    "@type": "Person",
    "name": "Jane Doe",
    "jobTitle": "Senior Editor",
    "description": "Chartered engineer, writes about heat pumps and insulation",
    "image": "https://example.com/authors/img/jane-doe.jpg",
    "sameAs": [
      "https://janedoe.example.com/",
      "https://social.example.com/janedoe"
    ]
  }
}
</script>

jobTitle is a standard schema.org Person property; it is not on Google's ProfilePage list, so it adds description but no feature. The same markup works on an About page that is about one person, such as a personal blog.

The About page: what to include

The About page answers “who is behind this site” for the whole site, the way an author page does for one writer. A slogan and a stock photo of a meeting room do not answer it. Link the About page from the footer of every page, and from the main navigation if trust is central to what you sell.

Write it for people. A local plumber's About page with the owner's name, photo, trade registration and service area is more convincing than a 1,000-word brand story. A publisher's About page should name the editor-in-chief and explain how the newsroom works, then link to the editorial policy for the detail.

Organization structured data

Organization markup tells Google the administrative facts about the business behind the site and helps it “disambiguate your organization in search results”. Where to put it, in Google's words: “We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don't need to include it on every page of your site.”

Google also recommends “using the most specific schema.org subtype of Organization that matches your organization”, for example OnlineStore rather than OnlineBusiness for a shop. A restaurant, clinic or physical store should use the matching LocalBusiness subtype and follow the Local business documentation as well.

Notes on individual properties from the same page: for name, “Use the same name and alternateName that you're using for your site name.” For url, “This helps Google uniquely identify your organization.” For vatID, “This is an important trust signal for users (for example, users can look up your business in public VAT registries).” As with Article, “There are no required properties”.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Energy",
  "legalName": "Example Energy Ltd",
  "url": "https://example.com/",
  "logo": "https://example.com/img/logo.png",
  "foundingDate": "2014",
  "email": "[email protected]",
  "telephone": "+44-20-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Example Street",
    "addressLocality": "London",
    "postalCode": "EC1A 1AA",
    "addressCountry": "GB"
  },
  "sameAs": ["https://social.example.com/exampleenergy"]
}

Every value must match what the About and contact pages show. If the footer says one phone number, the markup another and the contact page a third, you have created exactly the inconsistency trust pages are meant to remove. Put the block once, on the home page or About page, rather than letting a plugin print slightly different versions on every template.

The contact page

A contact page proves that there are people you can reach. What it should contain:

• Real channels. An email address or form, a phone number if you offer phone support, and a postal address for businesses.
• Routing. Which address handles what: support, press, corrections, partnerships. A dedicated corrections address shows you expect to fix mistakes.
• Expectations. Opening hours or typical response time, if you can keep to them.
• Consistency. The same name, address and phone as the About page, the footer and the Organization markup.

A contact page that is only a form, with no organisation name or address anywhere on the site, leaves the “who” unanswered. For shops and services, Google's Organization documentation also covers contactPoint for listing several support channels.

Editorial policy: what it should cover

The editorial policy answers Google's “How” question for the whole site. Google's examples of “How” include product reviews, where trust grows when readers “understand the number of products that were tested, what the test results were, and how the tests were conducted”, and automation: “Is the use of automation, including AI-generation, self-evident to visitors through disclosures or in other ways?” and “Are you providing background about how automation or AI-generation was used to create content?” On when to disclose, Google says: “Consider adding these when it would be reasonably expected.”

A useful policy is specific and short enough to read. The outline below works for most publishers, review sites and company blogs.

Link the editorial policy from the About page, from the footer and, on reviews and YMYL content, from near the byline (“How we test”). A policy copied from a large publisher and never followed is worse than none: the first reader who compares it with your pages will notice. On AI use specifically, the lesson “AI-assisted content without scaled content abuse” covers where disclosure ends and scaled content abuse begins.

Last-updated dates done honestly

Dates are part of “How”, and they are easy to abuse. Google lists this among the warning signs of search engine-first content: “Are you changing the date of pages to make them seem fresh when the content has not substantially changed?”

• Show both dates when they differ. “Published 4 March 2026 · Updated 18 September 2026” near the byline.
• Change the updated date for real changes only. New data, revised advice, a rewritten section. Not a typo fix, a new image, a changed affiliate link or a new year typed into the title.
• Keep the visible date and the markup in sync. datePublished and dateModified in the Article markup should be the same dates readers see, with a time zone.
• Do not let the CMS fake it. Some themes print the current date or the last save time on every page. Check that the date you show comes from the content, not from the template.
• Say what changed on pages where it matters, for example a short update note on a guide whose recommendations changed.

Common mistakes

• ✕Invented authorsPersonas with made-up names, credentials or AI-generated headshots. Google calls this deception.
• ✕Stock photos as author photosA face that belongs to someone else, findable with any reverse image search.
• ✕Generic or copied biosThe same “passionate writer” paragraph on every author page, with nothing about what the person actually knows.
• ✕Bylines that go nowhereA plain-text name, “admin” or “Staff”, or a link to a thin archive with no bio.
• ✕Author pages hidden from searchnoindex, blocked in robots.txt, duplicated across several CMS URLs, or deleted when a writer leaves.
• ✕Broken author markup“By” or a job title in author.name, several authors in one string, the wrong type, no url.
• ✕Markup that disagrees with the pageA different author, date, address or phone in JSON-LD than readers see.
• ✕An About page with no factsA slogan and values, but no names, no company, no address, no way to reach anyone.
• ✕A policy nobody followsAn editorial policy copied from elsewhere, promising fact-checking and corrections that never happen.
• ✕Fake freshnessUpdated dates changed with no real change to the content.

FAQ

Sources

• Google Search Central — Creating helpful, reliable, people-first content
• Google Search Central — Article structured data
• Google Search Central — Profile page (ProfilePage) structured data
• Google Search Central — Organization structured data

Quotes checked against the official pages on 30 October 2026.