To add sameAs schema to an employee or expert profile page, identify the person with a Person node, give that node a stable @id, and add a sameAs array containing only external URLs that clearly represent that same individual. On a dedicated biography page, connect the Person to a ProfilePage through mainEntity. Publish the JSON-LD in the page’s HTML, then check the rendered page and verify every identity link.

The distinction that matters most is person versus company. An employee’s LinkedIn profile may belong in that employee’s sameAs array. The employer’s homepage does not: use worksFor to describe employment instead. At Rank For AI Search, we treat this as an identity-matching exercise, not a way to collect as many links as possible. Accurate markup can clarify relationships among people, businesses, and published work, but it cannot guarantee a search ranking or an AI recommendation.

What `sameAs` means on a person profile

sameAs is a Schema.org property for URLs that identify the same entity. When the entity is a Person, each URL should point to a page or account that identifies that person, not merely a page that mentions them. A professional association profile with the individual’s name and matching career details is a plausible identity reference. A company service page quoting the individual is related content, but it is not necessarily another identity page.

The property is one piece of structured data. A useful employee biography also explains the person’s current role and relevant experience in visible text. The JSON-LD should describe that page faithfully. If a claim about a license or qualification cannot be verified, adding it to schema does not make it credible.

For a broader explanation of the property at the business level, see our guide to sameAs and brand identity. The underlying identity principle is the same, but the URLs on an employee page must identify the individual, not the organization.

When an employee or expert needs a dedicated profile

A permanent profile URL is particularly useful when a person has a meaningful public role: they author technical articles, explain services in videos, lead projects, hold relevant credentials, or appear in professional directories. A home improvement company might prioritize its owner, installation director, designer, or named specialist who answers homeowners’ questions. There is no need to manufacture a public biography or external accounts for every employee.

Before writing markup, make the profile genuinely helpful to a visitor. Include the person’s name, current job title, employer, specific areas of responsibility, and relevant work the business can substantiate. Where appropriate, add a photograph, articles they wrote, projects they can discuss, and links to their actual professional profiles. Obtain permission before publishing personal information or connecting personal accounts to an employer’s site.

A team directory can introduce several people, but a dedicated page gives an important expert a consistent URL to reference from articles and other parts of the site. If the site has no individual profile page, do not pretend a general team page is a biography of one person.

A practical workflow for adding `sameAs`

1. Choose the person’s canonical profile page

Start with the public page you intend to maintain as the person’s biography on your site. Use its final, preferred URL consistently, including the same trailing-slash convention in your page URL, canonical link, and structured data. Check that visitors can open it without logging in and that the page actually focuses on the named individual.

If an expert writes for your site, link their byline to this page. That gives readers somewhere to evaluate who wrote the material and makes it easier to reuse the same identity in article markup. A profile should remain useful even to someone who never inspects its schema.

2. Audit external identity URLs

Ask of each candidate URL: Would a reader recognize this as another profile of the same person? Check the name along with distinguishing information such as photograph, employer, specialty, professional history, or location. A shared name alone is not enough, especially for common names.

Potentially appropriate: an individual LinkedIn account, an official association member profile, an author biography at a publication, a personal portfolio, or a relevant professional identifier that belongs to the person.
Usually inappropriate: the company homepage, a generic department page, a directory category, a customer review page, a service page, or someone else’s account.
Needs closer inspection: an outdated directory entry, a profile with little identifying information, an account using a nickname, or a page that redirects somewhere unexpected.

There is no required number of sameAs links. One verified external identity page is more useful than a longer array padded with doubtful matches. If none can be confirmed, omit sameAs for now and publish an accurate Person profile without it. Do not create accounts simply to fill a schema field.

3. Give the person a stable `@id`

An @id is a machine-readable identifier for the entity within your structured-data graph. A practical convention is the profile URL followed by a fragment, such as #person. Unlike sameAs, this identifier refers to the person you define on your site. The exact fragment label matters less than using the same identifier whenever you refer to that person elsewhere.

For instance, an article by the expert can reference the existing person’s @id instead of creating an unrelated author node with only a name. Stable IDs help you express relationships consistently. They do not, on their own, establish someone’s qualifications.

4. Connect the page and the person in JSON-LD

On a page devoted to one individual, ProfilePage can identify the page and mainEntity can point to the Person. The person node can contain name, jobTitle, worksFor, and the verified sameAs URLs. Include optional fields only when they are accurate and supported by the visible profile.

The following is an illustrative template, not a real employee or a set of live profile links. Every token in square brackets must be replaced with a verified value before publication. If you have no verified external identity URL, remove the sameAs property.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "ProfilePage",
      "@id": "[EXACT_PROFILE_URL]#profilepage",
      "url": "[EXACT_PROFILE_URL]",
      "mainEntity": {
        "@id": "[EXACT_PROFILE_URL]#person"
      }
    },
    {
      "@type": "Person",
      "@id": "[EXACT_PROFILE_URL]#person",
      "name": "[VERIFIED_FULL_NAME]",
      "url": "[EXACT_PROFILE_URL]",
      "jobTitle": "[CURRENT_JOB_TITLE]",
      "worksFor": {
        "@type": "Organization",
        "name": "[CURRENT_EMPLOYER_NAME]"
      },
      "sameAs": [
        "[VERIFIED_EXTERNAL_PERSON_PROFILE_URL]"
      ]
    }
  ]
}
</script>

This template shows the relationships, not a copy-and-paste deployment. Square-bracket tokens are not URLs, and the finished script must contain real values, valid JSON, and no unverified claims. If your site already defines an organization with a stable @id, you can reference that existing organization node in worksFor rather than describing a separate version of the employer. Our guide to connecting organization and service schema explains why consistent identifiers matter across a business site.

5. Publish the script once and inspect the rendered page

Add the JSON-LD through the page template, a structured-data-capable CMS field, or another method your site supports. The installation method matters less than the final output: the script must be present on the public page, attached to the right person, and free of contradictions with markup generated by a theme or plugin.

Inspect the rendered HTML after publishing. Some sites already generate Person or ProfilePage markup automatically. Multiple nodes are not inherently a problem when they refer to the same entity consistently, but competing names, roles, or IDs make the page harder to interpret. Where possible, update the existing schema output rather than adding a second, conflicting biography.

6. Test syntax and verify meaning

Run the published page through the Schema Markup Validator to inspect the structured data. Google’s Rich Results Test can also reveal what it recognizes for supported search features, but a lack of a dedicated sameAs rich result is not evidence that the property is invalid. Neither test can confirm that a LinkedIn account truly belongs to your employee. A person must check the identity claim.

Does the rendered page contain the intended ProfilePage and Person nodes?
Do mainEntity and the person node use the same @id?
Does the name and current role agree with the visible biography?
Do the external URLs open the intended individual profiles?
Is there a conflicting person node elsewhere in the page output?
Can visitors and permitted crawlers access the public profile page?

For a more detailed testing routine, see our structured-data testing guide. Validation is necessary, but factual review is just as important: syntactically valid JSON-LD can still describe the wrong person.

Which schema property should describe each relationship?

A common implementation error is to put every related URL in sameAs. That collapses different relationships into an inaccurate identity claim. We use a simple rule at Rank For AI Search: first decide what the linked thing is, then choose the property. An employer, an article, and another profile of the employee are different things.

What you need to express	Appropriate approach	Why
This external profile identifies the individual	`Person.sameAs`	It asserts that both URLs represent the same person.
The person works for the company	`Person.worksFor`	An employee and employer are related, not identical.
This page is principally the person’s biography	`ProfilePage.mainEntity` pointing to `Person`	It separates the web page from the individual it describes.
The person wrote an article	`Article.author` referencing the person	Authorship is a role, not an identity URL.
The person reviewed content	An appropriate reviewer relationship where supported and accurate	Reviewing and writing should not be treated as the same contribution.

Likewise, do not use an organization’s social account as sameAs for an employee because that employee appears in its posts. If the business needs its own identity references, keep those on the organization node. The separation helps prevent a profile page from confusing the person with the brand.

Connect articles to the correct expert

If the employee actually writes an article, make their byline visible and link it to their profile. In the article’s structured data, the author can reference the stable Person @id from that profile. A schematic version looks like this:

{
  "@type": "Article",
  "author": {
    "@id": "[EXACT_PROFILE_URL]#person"
  }
}

This fragment illustrates an author reference, not a complete article schema block. Use the person’s actual role in the content. Do not label an executive as the author of every technical post simply because their profile is the strongest on the site. If an article has a separate writer and technical reviewer, represent those contributions accurately where your markup supports them, and make the visible page clear about who did what.

For home improvement businesses, this matters when articles explain complicated decisions such as moisture diagnosis, roofing materials, or installation processes. A named professional’s biography gives readers context for the advice. The quality and accuracy of that advice still matter far more than the presence of an author ID.

Best practices for contractor and expert profiles

Make expertise specific and supportable

Describe what a professional actually does. “Oversees roof inspections and installation training” tells a reader more than “industry-leading expert.” If the profile lists a license, confirm the holder, jurisdiction, and current status before publishing it. Do not use structured data to imply a person holds a credential that belongs to the company or another employee.

Keep public information proportionate

Professional visibility does not require a home address, personal phone number, or private social accounts. Ask which details help customers evaluate relevant experience, get the person’s approval, and link only to profiles suitable for public association with the business. An expert who prefers not to publish external accounts can still have a useful biography.

Make off-site references consistent where you can

Check whether the person’s external professional profiles reflect the same current employer and role when those details are displayed. Small variations in a title can be legitimate; a page claiming the person works for a different company deserves investigation. Rank For AI Search’s broader approach combines entity reconciliation with website and off-site signal alignment rather than treating JSON-LD as an isolated fix.

Review profiles after changes, not just at launch

Role changes, new profile URLs, company departures, and site redesigns can make previously correct markup inaccurate. Assign someone to update both the visible biography and its schema when those events occur. If a former employee’s articles remain published, preserve truthful authorship while reviewing whether the biography, employment statement, and external links still reflect the current situation. Do not silently rewrite authorship to another employee.

Worked scenario for a home improvement website

Imagine a home improvement company publishing a profile for the employee who explains its inspection process in homeowner education articles. This is a hypothetical workflow, not a customer result. The company first writes a public biography that accurately describes the employee’s current responsibilities. It then confirms that an external professional profile belongs to that employee and that the information on it is compatible with the company biography.

Next, the company assigns a stable person ID based on the biography page URL. Its ProfilePage points to that Person; worksFor links the person to the employer; sameAs contains only the verified individual profile. On articles the employee actually wrote, the company connects the visible byline and Article.author to that same person ID. Finally, it tests the published HTML and checks for markup already supplied by its CMS.

The benefit of this process is clarity, not a promised ranking change. A reader can see who provided the advice, and a system interpreting the structured data has a consistent description of the person and their relationships. If the external profile cannot be verified, the company leaves out sameAs rather than making an uncertain identity claim.

Common mistakes to avoid

Linking the company as the person: Put the employer under worksFor, not the employee’s sameAs.
Matching by name alone: Check distinguishing details before linking an account belonging to a person with a common name.
Adding articles to sameAs: An article about an expert is not necessarily another profile of that expert.
Using unsupported credentials: Verify qualifications and describe them accurately in visible content before considering structured data.
Changing the person ID on every page: Reuse the profile’s established @id when referencing the same individual.
Ignoring generated schema: Inspect your final page for overlapping theme, plugin, and custom markup.
Assuming validation proves effectiveness: Testing can identify technical problems, but it does not certify identity, expertise, indexing, or AI visibility.

Frequently asked questions

Can I add `sameAs` without a `ProfilePage` node?

Yes. sameAs is a property you can use on a Person node. ProfilePage is a useful way to describe a page primarily about that person, but it is not a prerequisite for expressing verified identity URLs.

How many external profiles should I include?

Include the profiles you can verify, not a target number. A single accurate identity URL is preferable to several weak matches. If there are no suitable external profiles, omit the property.

Should the employee’s company website go in `sameAs`?

Not when the URL is a general company page. It identifies the organization, not the individual. The employee’s own biography URL belongs in Person.url, while worksFor can connect the person to the business.

Can a social account count if it has little professional information?

Possibly, if you can confidently establish that it belongs to the individual and it serves as an identity page. If ownership is unclear or the account is private, omit it. Relevance and correct identity matter more than using a particular social network.

Do I need to show external links in the biography?

Visible links help readers inspect the sources you associate with an expert, so they are a good practice when appropriate. Do not publish a personal link without the individual’s approval. Whether or not you display it, a sameAs URL must still accurately identify the same person.

Does `sameAs` make an expert eligible for a rich result or guarantee an AI citation?

No. The property states an identity relationship. Search features and AI answers depend on factors beyond this markup, including whether a system can access a page and whether it considers the content useful and reliable. Treat schema as a clarity measure, not a promise of placement.

What if an employee leaves the business?

Update the visible profile and employment markup so they no longer state that the person currently works for the company. Review external identity links for accuracy. If the person genuinely authored existing content, retaining an accurate byline is usually more truthful than assigning that work to a replacement employee.

Build an identity record you can maintain

The soundest implementation starts with an accurate biography, verifies external identities, uses a stable Person ID, and keeps employment and authorship relationships distinct from sameAs. Test the published markup, then revisit it whenever the person’s public role changes. For contractors, this gives homeowners a clearer way to understand who is providing advice while making the site’s information more consistent for systems that read it.

If your team profiles, article authors, and off-site references do not line up, request a consultation with Rank For AI Search. We help home service businesses examine structured data, content clarity, and off-site identity signals together, so the information presented about their people and company is accurate and easier to interpret.

What sameAs means on a person profile