Person schema markup for personal brand: sameAs rules
Person schema markup for personal brand, done honestly: which fields to state, which profiles belong in sameAs, and the mistakes that make it backfire.
Person schema markup for a personal brand is a block of structured data on your own site that states who you are in a form software can read: your name, role, the organizations you work for and, through the sameAs property, the other pages that are also you. It does not make a page rank higher on its own, and the search engines that document it say so. What it does is remove guesswork, which matters most when your name is shared, common or already tied to a result you do not want.
Most guides on this topic hand you a template to paste and a promise about knowledge panels. This one starts from a narrower question that matters in reputation work: when a search engine or an AI assistant sees your name on a dozen pages, which of those pages does it have good reason to treat as the same person, and which does it not? Markup is one way to answer that, and a careless answer is worse than none, because a wrong sameAs link attaches your identity to a page that belongs to someone else.
The scope is the decisions inside the markup itself: what to state, what to link, what to leave out, where each block goes, and how to keep it true. Fields are described in plain terms and tables rather than pasted code, because the choices matter more than the syntax.
- Person markup states facts that are already visible on the page. Google documents that markup must describe content visitors can see, and that correct markup does not promise any search feature.
- Pick one canonical page for yourself, give the Person one stable identifier, and reuse that identifier wherever the person appears on your site.
- sameAs is an identity claim, not a list of mentions. Link only profiles you control or that are clearly yours, with the same facts, and never a namesake, an article about you or a page you cannot vouch for.
- Use ProfilePage with a Person as the main entity on your about page. Do not put it on a home page that is mostly navigation.
- Review the markup whenever your role, name or profiles change. Stale markup is the most common way it hurts.
What Person markup states, and what it cannot do
Person markup is a set of statements in the schema.org vocabulary, a shared list of types and properties that search engines read. The Person type carries name, alternateName, description, image and url, inherited from the general Thing type, plus Person-specific ones such as jobTitle, worksFor and knowsAbout. It also has sameAs, which schema.org defines as the URL of a reference web page that unambiguously indicates the item's identity. The knowsAbout property is described as indicating a topic someone knows about, suggesting possible expertise but not implying it. Those two definitions are the useful ones: sameAs asks for proof of identity, and knowsAbout asks for modesty.
Related readSuppress negative results for a company nameThe format Google recommends is JSON-LD, a block of data that sits in a script element of type application/ld+json, separate from the visible text. Google's introduction to structured data says JSON-LD is usually the easiest to implement and maintain, that it can be injected by a CMS or by JavaScript, and that the markup should sit on the page it describes and reflect content visible to users. It adds that you should not create empty pages to hold structured data.
Now the limits. Google's intro page describes required properties as what makes a page eligible for enhanced display in Search, which is a condition, not a promise of display. Google's general structured data guidelines add that a structured data problem can lead to a manual action, which removes a page's eligibility for rich results and, per the same page, does not affect the page's ranking in web search. Read both sides of that. Honest markup will not lift you above a damaging article, and dishonest markup will not drop you in the blue links; it will cost you the features that read it.
Decide the job of the markup before you write any of it
Every block does one of three jobs. The first job is stating: your name, role and description, matching the page. The second is linking: telling a reader or a machine that this page, that profile and that database entry are one person. The third is separating: helping the system keep you apart from a person who shares your name. A shared-name case needs all three, and a unique name usually needs only the first two.
Related readSuppress Outdated News After a Resolved CaseThe table below maps each field to its job, what to put in it and the rule that keeps it honest. It stands in for a code sample: in the markup, each row is one property with one value.
| Field | Job and what to put | Match against | Common mistake |
|---|---|---|---|
| name | Stating. Your name as it appears on the page and in your bio. | The page heading | A different spelling on each page |
| alternateName | Separating. A handle or a variant you really use. Google recommends name for real names and alternateName for handles. | Profiles you list | Invented nicknames nobody uses |
| url | Linking. Your canonical page about yourself. | The address you want people to reach | A redirect or a staging address |
| sameAs | Linking. Pages that identify you, one address each. | The profile itself | Namesakes, articles, dead accounts |
| jobTitle | Stating. Your current title as a plain label. | The bio | A title the visible page does not show |
| worksFor | Stating and separating. The organization you work for, with its own url. | The employer's page | Past employers listed as current |
| description | Separating. One factual sentence on who you are and what you do. | The first line of your bio | Adjectives and claims you cannot show |
| image | Stating. A portrait that is on the page. | The page photo | A different photo from the one visible |
| knowsAbout | Stating. Two to five topics you can show work on. | Published work | A keyword list |
Leave out any field you cannot match to something visible. Do not add a birth date, home address, phone number or family details, even though the vocabulary has properties for them. Markup is public and permanent in the way a published page is, and a reputation file is a place to reduce exposure.
Pick one canonical page and one identifier for the person
Before any markup, choose the single page on your own site that is the home of the Person. For most people this is the about page. It is the address that goes in the url property, the page the other pages point back to and the page your profiles link to when they have a website field. If you have not yet settled this, do that first; a site that offers three bio pages gives the markup three candidates to disagree about.
Then give the Person a stable identifier. JSON-LD lets a described thing carry an id of its own, commonly written as a web address with a fragment, for example the about page address followed by a hash and the word person. Google's ProfilePage page uses the same mechanism, linking items to their author by id. The W3C JSON-LD specification says an identifier, written as @id, uniquely identifies a node and is an IRI or a blank node identifier, and that a relative reference is resolved against the document's base IRI. Its section on fragments could not be read for this guide, so check it before you choose a format. Other markup on the site can then refer to that identifier instead of repeating the whole description. In practice that means the article author on your blog, the speaker on your talks page and the Person on your about page all point to one record. If the description changes, you change it in one place.
Related readDoes search suppression work? An honest testUse one identifier per person, spelled identically everywhere, and update every reference at once if the address changes. This is the part most template generators skip. They create a fresh, self-contained Person on every page, which gives a search engine many slightly different records of you and no sign that they are one. The reputation cost is real: a stale copy on a forgotten page can contradict the current one for years.
Which profiles belong in sameAs, and which never do
sameAs is where Person markup carries most reputation risk, because it is where you assert that something outside your site is you. Google's organization markup documentation defines the property, for organizations, as the URL of a page on another website with additional information about the organization, with social media and review site profiles as examples. Its ProfilePage page, covered below, describes sameAs as URLs to other external profiles or home pages for the same entity. Schema.org sets the higher bar: a page that unambiguously indicates the item's identity. Use the stricter reading.
A profile passes if all four conditions hold: you control it or it is plainly yours; the name and role on it match your canonical page; it is active enough that it will not be taken down or reassigned; and you would be content for it to be the first thing a stranger saw after your site. The table sorts the usual candidates.
| Candidate | In sameAs? | Why | Risk if wrongly added |
|---|---|---|---|
| Your own professional profile, kept current | Yes | You control it and it repeats your facts | Low |
| An author page on a publication you write for | Yes, if it names you and your role | It confirms a real affiliation | Low |
| An entry in an open database you are listed in | Yes, if it is correct and is you | It is an identity record | Medium: you inherit its errors |
| Social accounts you do not use | No | Dormant pages drift out of date | Medium |
| An article or interview about you | No | It is a mention, not an identity page, and you do not control it | Medium |
| A page about a namesake | Never | It ties your record to someone else | High |
| People-search and data broker listings | Never | They are the exposure you may be trying to reduce | High |
| A fan page or unverified account you do not run | No | You cannot vouch for it | High |
Two further rules. First, symmetry: a profile that you list in sameAs should link back to your site, in its website field or bio. Without that return link, the claim runs in one direction only, and an observer cannot tell whether the profile is really yours. Second, keep the list short. Three to eight well-chosen profiles carry more weight than twenty, and every extra entry is one more thing to keep accurate.
Related readCommon name reputation search results: a planUse ProfilePage for the canonical page, Person everywhere else
Person describes who someone is. ProfilePage describes a page whose subject is a person, so the right setup is a ProfilePage on the canonical page with the Person as its main entity, and plain Person references on other pages.
Google's ProfilePage documentation sets out the rules. The one required property is mainEntity, which must be a Person or an Organization, with Person as the default when the creator is not clearly an organization. The Person must carry a name, though alternateName can stand in when a name is unavailable. Recommended properties include dateCreated and dateModified, and description, identifier, image and sameAs for the person. Google's identifier is an ID used within your site, such as an internal database ID, which is separate from the web-address identifier above. The guidelines add that the main focus of the page must be one person or organization affiliated with the website. Valid examples are forum user profiles, news author pages, blog "About Me" pages and employee pages. A store home page and an organization review site that is not affiliated with the reviewed organization are listed as not valid.
Two consequences follow for a personal brand.
- Your about page is a valid ProfilePage. Your home page is valid only if it is itself a short profile of you. If it is a menu to services, posts and a contact form, leave ProfilePage off it.
- Your dateModified should move only when a person edits the page, not when a template rebuilds. Google says it should reflect human-edited profile changes. Faking freshness is the quickest way to make the markup untrustworthy.
Google's page states that it does not guarantee structured data will produce a rich result. Treat the markup as a statement of record, not a lever.
Handle a shared name, a pseudonym or a name change
The cases where Person markup earns its place are the ones where the plain text is ambiguous. Each has its own rule.
A shared name. The markup cannot make a search engine choose you over a namesake. It can give the system more separating facts to work with: your jobTitle, your worksFor organization with its own url, your alternateName if you use a middle initial or full form, and a description that includes your field and location at the level you are willing to publish. Say the same things in the same words on the visible page.
Related readSuppress negative results for a unique nameA pseudonym or professional alias. Use the name you publish under as the name, and be consistent. Google's ProfilePage page recommends name for real names and alternateName for handles. If you work under a name that is not your legal one, there is no need to publish the legal one, and the markup should not. What you must not do is describe a person who does not exist as a real professional or borrow the standing of someone else. Google's general guidelines say not to impersonate any person or organization and not to misrepresent ownership or affiliation. A pseudonym is acceptable. An invented credential is not.
A name change. Keep the canonical address, update the name and add the former name as an alternateName for a transition period only if you want old references to resolve to you. Then update every profile in your sameAs list before you update the markup, so the profiles and the page are never in conflict.
A damaging result under your name. Markup does not push it down, and it never belongs in sameAs. Its narrow job is to make your owned pages read as one record; the ranking comes from the pages themselves.
Implement it in a working order, then validate
The order below keeps the facts ahead of the code. A reasonable first pass takes an afternoon for a small site.
- Write the fact sheet firstList your name, role, employer, one-sentence description, portrait and profiles on a note. Every markup value comes from this sheet, and every one must also be visible on the page.
- Choose the canonical page and identifierDecide which page is the home of the Person, and fix the identifier you will reference from other pages.
- Select the sameAs listApply the four conditions to each profile. Open each one and confirm it links back to your site. Drop any that fail.
- Add ProfilePage and Person to the about pagePut the ProfilePage with the Person as main entity in a JSON-LD block on that page only. Add dateModified and set it to the date a person last edited the page.
- Reference the identifier elsewhereOn article and talk pages, refer to the Person by identifier. Do not repeat the full record.
- Validate and inspectRun the page through Google's Rich Results Test, then the URL Inspection tool to confirm the page is crawlable and the markup is found. A page blocked by robots.txt or noindex cannot be read.
- Record it and set a review dateAdd the markup and its sameAs list to your fact sheet with a review date, so changes to your role or profiles trigger an update.
Google names the Search Console rich result reports as the way to catch breakage after a template change, and says indexing after publishing can take several days. If your CMS or an SEO plugin already writes markup, find out what it writes first: two competing Person records on one page are worse than one imperfect one. Keep a single source.
Related readSuppress negative review site results: a planMistakes that make the markup hurt
Most damage comes from a handful of repeatable errors. They are listed with the signal that gives each away.
- Markup that the page does not show. A jobTitle, award or image in the code but not on the page. Google's guidelines tell you to mark up only visible content. Detected by comparing the code to the page, line by line.
- A copied template left half-filled. Placeholder text, a generic image or someone else's profile list still in the record. Detected by reading the finished markup aloud against the page.
- sameAs to the wrong person. A namesake's page, a data broker listing or an old account. The result is an identity claim you cannot defend. Detected by opening every link and asking whether it is unmistakably you.
- Different records on different pages. One name spelling here, another there; one job title from three years ago. Detected by searching your own site for the earlier title.
- Freshness theater. An automatic dateModified on a page that did not change.
- An inflated knowsAbout list. Twenty keywords, each a claim. Detected by asking whether you could point to published work on each topic.
- Markup on a page that is not about you. A home page that is a menu, or a services page with a Person block pasted in. Google lists a store home page among invalid ProfilePage uses for this reason.
The rule behind most of these is the same: the markup is a statement about the visible page. If the statement and the page diverge, one of them is wrong, and a reader will find out which.
A worked scenario and a realistic timeline (invented)
Take an invented consultant with a common name, shared by two other professionals; one of them has an unflattering news result on page one. The consultant has an about page, a professional profile, a conference speaker page and a blog. There is no knowledge panel, and an AI assistant sometimes answers with a blend of two careers.
The assumptions: the facts on the site are accurate and current, the consultant is happy to publish an employer and a city, and no legal dispute is involved. The goal is not to remove the other person's result, which belongs to someone else, but to make the consultant's own pages read as one unambiguous record.
The consultant writes a fact sheet, and notices three versions of the job title across profiles. The profiles are corrected first. The about page then gets a ProfilePage with a Person as main entity: name as published, the current title, the employer with its own address, a one-sentence description naming the field and city, and the portrait that is on the page. Four profiles go into sameAs, each checked for a link back. Two dormant social accounts and the conference page are left out, the first because they are unused and the second because it is a mention, not a profile. The blog posts refer to the Person by identifier. The consultant checks the pages in the Rich Results Test and URL Inspection and sets a quarterly review date.
Related readSuppress negative social media posts in search results| When | What the consultant does | What usually happens |
|---|---|---|
| Week 1 | Fact sheet, canonical page, profile fixes | Nothing visible; this is the groundwork |
| Week 2 | Markup on the about page, identifier references on other pages, validation | Search tools read the page after crawling, often within days |
| Weeks 3 to 6 | Back-links from profiles, conference and publisher author pages updated to match | The owned pages begin to agree with each other |
| Weeks 6 to 12 | Check name searches and AI answers on a fixed set of queries | Often a modest gain in how consistently the right pages appear; not a certainty |
| Quarterly | Review sameAs, title, employer, dateModified | Prevents the slow drift that undoes the work |
The honest reading of the outcome is limited. The markup will not move the namesake's news result. It may reduce the chance of the consultant's facts being mixed with another career, and it gives the consultant a solid base for the pages that do the ranking.
Next step: audit what your pages say about you
If a search engine or an AI assistant is mixing your name with someone else's, look at what your own pages state before touching code. Reputation Partners starts with a private audit that shows which pages disagree and which one should be your canonical record.
Questions people ask
Does Person schema help me rank higher for my name?
Not directly. Google says correct structured data does not promise any search feature, and the technical guidance describes markup as a way to help it understand a page. What it can do is support clarity: consistent facts and identity links across your pages. Ranking for a name still comes from the pages themselves, the links to them and the wider signals.
How many profiles should I put in sameAs?
Usually between three and eight. The number matters less than whether you could defend each link as unmistakably yours. A short list of active profiles that link back to your site is stronger than a long list with dormant or doubtful entries. Each profile you add is one more page to keep consistent.
Should I use JSON-LD, Microdata or RDFa?
Google supports all three and recommends JSON-LD, because it is separate from the visible text and generally easier to maintain. For a personal site, JSON-LD in the about page is the usual choice. If your CMS or a plugin already produces markup in another format, check what it writes before adding a second version.
Can I use Person markup if I work under a pseudonym?
Yes, if you describe a real working identity honestly. Google's ProfilePage page recommends name for real names and alternateName for handles. You do not need to publish a legal name. What you must not do is claim credentials you do not hold or present yourself as someone else.
Does the markup need to match the visible page exactly?
Every value should be visible to readers or clearly derived from what they see. Google's guidelines say markup must describe content that is on the page and warn against hidden or misleading markup. A title, image or employer in the code that the page does not show is the most common reason markup becomes a liability.
Will adding markup get me a knowledge panel?
There is no source I read for this guide that says it will. Google's organization page notes that some properties, such as a logo, can influence visual elements in Search including a knowledge panel, and says it does not guarantee that features using structured data will appear. Google's own knowledge panel help page could not be read for this guide. Treat a panel as the result of independent coverage and clear identity, with markup as one small supporting input.
