Author bio page and Person schema: what to build

An author bio page is a single page on your site about one named person, linked from every piece that person signs and marked up as a profile. It gives search engines a clearer way to tell one person from another: one address to associate with the name, a visible byline that matches it, and a short list of other profiles that belong to the same person.

Google's documentation covers each of those pieces, and it also draws a line around them: valid markup does not ensure a rich result, and the pages read for this guide do not say that author markup improves ranking. This guide covers the byline-and-bio-page case only: which properties the documentation lists, what it leaves unsaid, how to keep a name identical across articles and profiles, and how to choose between a real name, a working name and a desk byline.

The short version

Build one bio page per author, about that person only, and link every byline on the site to it.
Mark it up as a profile page with the person as main entity. Google lists two required properties: the main entity and a name (an alternate name can stand in if no name is available).
Use sameAs only for pages that unambiguously describe the same person, and spell the name identically in the byline, the page and the markup.
Nothing in the documentation promises a ranking or a feature from this markup. Treat it as disambiguation, not as a lever.

What a bio page has to settle for search engines

A bio page has to answer one question for a crawler: which person is this name, and which pieces of writing are theirs. Everything else on the page supports that answer.

A byline is usually just text. "A. Morgan" on one site, "Alex Morgan" on another and "Alexander J. Morgan" on a conference page look like three people to a machine, and sometimes to a reader. A dedicated page gives the byline somewhere to point. Once every byline on a site links to one address, and that address says who the person is, the site has made its own claim about identity in a form that can be read automatically.

Three jobs sit inside that page:

Identification. The name, a recognizable photo and one or two sentences on what the person does.
Attribution. The work signed on this site, with the articles linking back.
Corroboration. Pointers to other profiles that describe the same person, which is where sameAs does its work.

Google's helpful content guidance frames the gap as self-assessment questions: is it self-evident to visitors who authored the content, do pages carry a byline where one might be expected, and do bylines lead to further information about the author? Those are questions for the site owner, not a ranking checklist.

What Google documents for Person, ProfilePage and author markup

Google documents the profile page type, the author properties inside Article markup, and the general structured data rules that apply to both. It does not present a standalone Person feature, and it says plainly that valid markup does not ensure anything will appear. The pages below were read for this guide, and the guide describes them as read on its publication date.

ProfilePage

The ProfilePage documentation says the page's primary focus must be one person or organization affiliated with the site. Its valid uses include an author page on a news site, an "About Me" page on a blog and an employee page on a company website. A store's home page is listed as invalid.

Two properties are required: mainEntity on the ProfilePage (a Person, or an Organization) and name on that entity. If name is not available, alternateName can satisfy the requirement. Real names go in name and social handles go in alternateName. The recommended properties are dateCreated, dateModified, description (a byline or relevant credential), identifier, image, alternateName and sameAs, plus interaction statistics for community platforms. The dateModified value should ideally reflect only human-edited profile changes. The image should be a real profile image, not a default, icon or placeholder.

Article author properties

The Article documentation says an author can be a Person or an Organization, and that the type should match. For author name it asks for the name only: no publisher name, job title, honorific or "posted by". It describes author url as a link to a page that uniquely identifies the author, such as a bio page, and recommends that an internal profile page be marked up with profile page structured data. It treats sameAs as an alternative to url that Google can use to disambiguate authors. Each author goes in a separate entry. It also says there are no required Article properties.

General rules

The general structured data guidelines say markup must be a true representation of the page content, must not describe content readers cannot see and must not be misleading. They state that valid markup does not ensure a rich result and that Google recommends JSON-LD.

Twoproperties Google lists as required for a profile page: main entity and name

Zerorequired properties for Article markup, author included

Oneperson or organization as the primary focus of a profile page

Counts from Google Search Central's ProfilePage and Article structured data pages, as read for this guide.

Page elements against what the documentation supports

Most advice on author pages mixes three kinds of claim: what Google documents, what is plausible practice, and folklore about rankings. The table separates them, using only the pages named above. "Not stated" means the pages read do not say it, which is different from saying it is false.

Page element	Where documented	What the source says	Support
Visible byline on each article	Helpful content guidance	Asks whether authorship is self-evident and a byline present where expected	Self-assessment question
Byline linked to a bio page	Helpful content guidance, Article markup	Asks whether bylines lead to further information about the author; author url can point to a bio page	Documented
Profile page, person as main entity	ProfilePage markup	Main entity and name are the two required properties	Documented
Real name in name, handle in alternateName	ProfilePage markup	Real names in name, social handles in alternateName	Documented
sameAs links to other profiles	ProfilePage and Article markup	Recommended; usable to disambiguate authors	Recommended
Real profile photo	ProfilePage markup	Recommended; no default, icon or placeholder	Recommended
Modified date tracking human edits	ProfilePage markup	dateModified should ideally reflect only human-edited changes	Recommended
Job title in the author name	Article markup	Name only; titles belong in jobTitle	Documented
Invented creator profile	Helpful content guidance	Fabricated creator profiles, including made-up names and false credentials, are called deception	Documented as a warning
Better rankings from a bio page	None of the pages read	No statement that author markup improves ranking	Not stated
A knowledge panel from a bio page	None of the pages read	No statement that a bio page produces a panel	Not stated

The job-title row is a small, common error: a name field reading "Dr. Alex Morgan, Head of Research" breaks the instruction to put only the name there. The last two rows are where commercial advice goes beyond its sources. Commercial advice on this topic often describes ranking benefits that these pages do not state. We take the narrower reading: the markup is documented, the benefit is not.

Choose sameAs links that identify you, not links that decorate you

Use sameAs for pages that are unambiguously about you, and only those. Schema.org defines sameAs as the URL of a reference web page that unambiguously indicates the item's identity. That definition is the whole test.

A link passes when a stranger opening it would conclude, with no other context, that it describes the same person as the bio page. It fails when it is merely related: a company page listing twenty people, a podcast episode where you were a guest, a directory page mixing you with namesakes. Those can sit on the bio page as ordinary links, but they do not identify you.

What belongs. Profiles you control that carry your name, such as a professional network profile, a publisher's contributor page, a speaker page or a research profile. Reference entries about you, if they already exist. Your own other sites that name you.

What does not belong. Pages for someone with a similar name. Dead links and profiles that now show another person. Abandoned profiles with an old title, which are contradictions waiting to be found. Accounts you would rather not tie to your public name: a sameAs link is a public statement that two pages are the same person.

Each listed profile should name you the same way and, where the platform allows, link back to the bio page. The documentation does not say this reciprocal link is required; it is ordinary good practice, because a reader or crawler can confirm the claim from either end. A short list of profiles that agree on name, role and photo beats a long one that disagrees.

Keep the byline identical everywhere it appears

Consistency of the name string is the cheapest and most overlooked part of the job. The bio page can be perfect and still fail if the same name appears in four forms across your own articles.

Fix one canonical form and use it, character for character, in the visible byline, the bio page heading, the name in the profile markup, the author name in each article's markup, the display name on every sameAs profile, and the credit line you give publishers and event organizers.

Variants are not forbidden. People publish as "Alex Morgan" and are known as "Al". Put the canonical form in name and the others in alternateName, which schema.org defines as an alias for the item. What causes confusion is using variants without a declared main form.

Names usually drift in the same ways: a middle initial that comes and goes, titles slipping into the byline, a transliterated spelling, guest posts credited differently, and company bylines mixed with personal ones. The Article documentation allows an Organization as author, so a post signed by the brand and one signed by you are different attributions, and the markup should say which is which.

A worked scenario

This scenario is invented. A consultant has forty articles on her own site, ten guest pieces on three trade sites and a conference talk. Her site shows "Jo Carter" on older posts and "Joanna Carter" on newer ones, the guest pieces say "J. Carter", and the conference lists "Joanna M. Carter, PhD". A machine reading each page separately sees four strings and no rule linking them.

The fix is small. She chooses "Joanna Carter" as canonical, rewrites her own bylines, puts "Jo Carter" in alternateName, asks the trade sites and the conference to correct the credit and link to her bio page, and lists the four profiles that now match in sameAs. She does not rewrite history on pages she does not control. She makes the pages she controls agree, and gives the others a clear route to correct themselves.

Connect every article to the bio page

The connection must run in both directions: each article points to the bio page, and the bio page points to the articles.

From article to bio page. Make the visible byline a link to the bio page, and use the same address as the author url in the article's markup. The Article documentation recommends profile page markup for an internal profile page, and that recommendation ties the two types together: the article names the author and gives the profile address, and the profile describes the author. Check that the author type is Person, that the name holds only the name, and that each author appears as a separate entry rather than "A and B" in one field.

From bio page to articles. The ProfilePage documentation says that when a profile shows recent activity, such as articles, those items can be marked up with hasPart, each pointing back to the main entity through a matching identifier. In practice that means a list of recent pieces on the page. We would not try to list everything: the latest ten or twenty is a reasonable scope.

Keep the visible page and the markup in agreement. The general guidelines say not to mark up content readers cannot see, so a photo, title or profile list in the markup should also be on the page.

Two page-level details are easy to miss. A "meet the team" page listing everyone is not a profile page for any one person, so each author needs their own. And the ProfilePage documentation warns against blocking the page with robots.txt, noindex or a login requirement, so check that the bio page is reachable and keep its address stable through redesigns.

Decide between a real name, a working name and a desk byline

The documentation tells you to use real names in name and handles in alternateName. It does not discuss pseudonyms, and it does not say a byline must be a legal name. Its helpful content guidance does say that fabricating creator profiles, such as with AI-generated headshots, made-up names or false credentials, is deception. We read the practical line as running between a public identity that is genuinely used and a persona built to mislead; that reading is our judgment, not a documented rule.

For people who must keep a legal name out of search for safety, employment or privacy reasons, this is a real decision. The table compares the common choices.

Byline choice	Bio page and markup	What the documentation supports	Main risk
Real name, public identity	Person profile with name, photo, sameAs	The fully documented pattern	Personal details exposed on a public page
Consistent working name	Same structure; working name in name, other forms in alternateName	Not addressed; the guidance on made-up names makes honest use essential	Credentials that cannot be tied to the name
Working name with invented credentials	Profile with a fabricated background	Fabricated profiles and false credentials are called deception	Loss of trust, policy exposure
Organization byline	Organization as author, an about page for the organization	Article author may be an Organization	No accountable person behind the content
One author, several outlets	One bio page, a sameAs entry per contributor page	sameAs is documented for disambiguation	Outlets crediting you differently

The second row is our judgment, not a documented rule. It holds only where the working name is the one the person genuinely publishes and works under, used openly and consistently, with a real photo and a biography that states only what is true. The aim is not to hide a person from search but to give search a stable name to attach the work to. A name created only for the page, with no real work behind it, falls on the wrong side of the guidance. The rule that matters is in the third row: never attach a background that does not exist.

A bio page also publishes information on purpose, so decide what to leave out before building: a home address, a date of birth, a personal phone number, a family member's name, a city narrower than you need. None of these help identification, and all are hard to retract once copied. If a page already exposes more than you want, our private audit starts by listing what is public and what is correctable.

Build the page in seven steps

The order matters: names and links first, markup last, because markup describes a page that already exists and agrees with itself.

Building an author bio page that identifies one person

Fix the canonical nameChoose one spelling, with or without a middle initial, and no titles. List the aliases you want to keep.
Audit existing bylinesList every place the name appears on pages you control and on the main outside pages carrying your work. Note each variant and who can change it.
Write the bio pageOne person, one address: name, a real photo, two or three plain sentences on what you do, the role or employer if public, and a list of recent pieces. Leave out private details.
Link every byline to itMake the byline on each article a link to the bio page, and use the same address as the author url in each article's markup.
Add the profile markupMark the page as a profile page with the person as main entity. Include name, description, image, alternateName where you use aliases, sameAs for profiles that pass the identity test, and dateModified tied to real edits.
Align the outside profilesMake name, photo and title on each sameAs profile match the bio page, and link back to it where the platform allows.
Test, then check what Google foundRun the page through the Rich Results Test and, as a second opinion, the Schema Markup Validator from schema.org. Fix errors, then check the live page with the URL Inspection tool.

A realistic timeline, from experience and not a promise: steps one to four take a few hours on a small site, and a couple of weeks if you must ask publishers to correct credits. The markup takes an hour once the page exists. The ProfilePage documentation says Google may take several days to find and crawl newly published pages. Outside publishers change on their own schedules and some never update, so plan for the pages you control and treat the rest as a bonus.

Check the markup, and know what it will not do

Validate before publishing, then confirm what Google has found. Google's documentation names the Rich Results Test for development, the rich result status report for monitoring after deployment and the URL Inspection tool to confirm the structured data was found. Schema.org also offers a Schema Markup Validator, which can serve as a second opinion when something looks off. Re-check after every template change: a redesign that drops the byline link, or a plugin update that rewrites the author markup, is the usual way a working setup stops working unnoticed.

What the markup will not do matters as much as what it does:

It will not make a thin page authoritative. If the bio says nothing checkable, the markup describes nothing checkable.
It will not stop a namesake from appearing for the same name. It gives search engines a clearer picture of you and removes no one else.
It can cause harm if it misleads. The general guidelines say not to mark up misleading content, and that a structured data manual action removes eligibility for rich results. Describe only the person on the page.

Next step: audit your bylines before you touch the markup

Open the ten most visible pages that carry your work, copy the exact byline from each, and count the forms. That count tells you whether the job is a markup task or a consistency task.

If your name is split across profiles you cannot sort out

If bylines, profiles and a namesake are tangled together, we can map what search engines and AI assistants show for your name and what to fix first. See how we build an owned page one on the personal brand page.

Read the sources themselves, since documentation changes: Google's ProfilePage structured data, its Article structured data, the helpful content guidance, the general structured data guidelines and the schema.org definition of Person. This guide describes them as read on its publication date. Reputation Partners works from the same pages when we advise on a name.

Questions people ask

Does an author page need Person markup to work?

No. The Article documentation lists no required properties, and a bio page is useful to readers without any markup. The markup adds a machine-readable statement of who the page is about. If you add it, the ProfilePage documentation asks for the main entity and a name. Add it once the page, the bylines and the profiles already agree with each other.

Can a bio page rank for my own name?

It can appear, as any page can, if it is indexable, clear and about you. None of the documentation read for this guide says the markup improves ranking, and results for a name depend on competing pages and namesakes. Build the page to make the identity clear, and treat any position it earns as a side effect.

Do contributors on a multi-author site each need their own page?

If you want each byline to identify its author, yes. The Article documentation asks for each author as a separate entry and says an internal profile page should carry profile page markup. A shared "our authors" list does not meet the one-person focus of a profile page, but it can link to each individual page.

Can I change my byline later?

Yes, but treat it as a migration. Choose the new canonical form, update the pages you control, keep the old form in alternateName, keep the old bio address working with a redirect, and ask outside publishers to update their credits. Expect a mixed picture for a while, since outside pages change on their own schedules.