Entity Consistency Checker: Cross-Page Schema @id & sameAs

By Linus Li · Updated 2026-10-05 · Free, runs in your browser

Rate this toolNo ratings yet

Enter the pages where one person or company appears, on one site or several. The tool lines up the Person and Organization entities from each page’s JSON-LD, lists every mismatch in @id, properties and sameAs, and writes the merged markup you should use.

Key takeaways

The tool reads 2 to 10 pages at once and lines up the Person and Organization entities from each page’s JSON-LD, listing every mismatch in @id, properties and sameAs.
It treats two descriptions as the same entity when they share an @id or a profile link in url or sameAs; a matching name alone does not join two different @id values.
Each check carries an evidence level. Google has not said whether it merges the same @id across pages, so those checks are level D.
There is no overall score; the results include the merged markup you should use.

What an entity is, and why check across pages

In structured data, an entity is a thing that can be identified on its own: an author, a company, a brand. Google records entities in its Knowledge Graph, and AI search products such as ChatGPT and Perplexity also have to work out which entity is meant before they answer “who is this person” or “is this brand trustworthy”.

An author usually appears in many places: the about page of their own site, the author of every article, an author page on their employer’s site, and profiles on LinkedIn, GitHub and other platforms. Each page carries its own description, and over time they drift. A new job title gets updated in one place, an old photo stays on older pages, or the employer’s author page uses a different @id. A single-page checker cannot see any of this, because every page looks fine on its own.

This tool reads 2 to 10 pages at once and puts every description of the same entity in one table. It treats two descriptions as the same entity when they share an @id or a profile link in url or sameAs. A matching name only counts when it does not join two different @id values: two people with the same name and their own @id stay separate, and the tool lists them as a hint.

How to use it

Enter one URL per row: typically the entity home (about or author page), an article page and an author page on another site. You can paste several URLs at once and the tool splits them into rows.
If a page injects its structured data with JavaScript or needs a login, click “Paste code” and paste the JSON-LD or the full page source. The URL then only labels the page. The bookmarklet in the Schema Visualizer copies the JSON-LD as the browser renders it.
Click “Check entities”. Each row shows its fetch progress and how many JSON-LD blocks were found.
Switch between four views:
- Issues: severity, evidence level and sources for each finding; expand it for the reason, the fix and code you can copy.
- Entity comparison: one table per entity, one column per definition on a page, with differing rows highlighted.
- Cross-page graph: pages on the left, entities on the right, lines showing which page defines or references which entity.
- Recommended markup: the merged full definition and the reference each page should keep.

No data at hand? Try the two examples. “Linus Li author entity” fetches this site’s about page, an article and the author page on the Jindouyun SEO site; “common mistakes” is a fictional data set that triggers most checks.

Checks and evidence levels

There is no overall score. Each check carries an evidence level that says whether Google has said anything about it:

A Confirmed: Google Search Central documentation or a public statement.
B Documented: court testimony, rulings or leaked documents whose use is unknown. No check in this tool is currently at level B.
C Patented: patents or papers, which do not prove anything is live. No check in this tool is currently at level C.
D Speculative: industry practice or inference; Google has not said.

A separate “Spec” tag marks rules that come from the JSON-LD or schema.org specifications rather than from Google. For example, JSON-LD compares @id values as strings, which is certain; whether Google merges identical @id values across pages is not documented.

Check	How it is decided	Evidence
One entity, different `@id` values	Shared `url` or `sameAs` profile, different `@id`	D, Spec
Same name, different `@id`	No shared link, so the tool keeps them apart and only gives a hint	D, Spec
Inconsistent `@id` spelling	Differs only by http/https, www, case or trailing slash	D, Spec
Relative `@id`	`"#person"` resolves to a different identifier on each page	D, Spec
Conflicting properties	`name`, `jobTitle`, `url`, `image` or `logo` differ for one entity	D, Spec
Values that follow page language	Pages declare different `inLanguage` and each language uses one `name` or `url` (e.g. a Chinese and an English about page). Shown as a note, not a conflict	D
`worksFor` points to different organizations	The employer `@id` or name differs between pages	D
Inline definition without `@id`	Other pages give the entity an `@id`, this one redefines it without	D
Plain-text author, or no `url` / `sameAs`	The article `author` is just a name	A
ProfilePage without `mainEntity`	Google lists it as required	A
ProfilePage does not match the entity	A profile page listed in `sameAs` uses another `@id` as `mainEntity`	D
Invalid `sameAs`, platform home page or non-profile page	e.g. `https://www.linkedin.com/` or a GitHub repository	A
Duplicate `sameAs`, or the entity’s own `url` in `sameAs`	The same address listed twice	D
Referenced `@id` never defined	No input page defines it	D
One-way cross-site links	The same entity on two sites, linked in one direction only	D
No Wikidata or Wikipedia	No knowledge base link in `sameAs`	D

For practitioners: sources for each check and how the merge works

Sources

Google Article structured data, author markup best practices: author.url is “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”; the page adds that Google can understand both sameAs and url when disambiguating authors. The section does not mention @id.
Google ProfilePage structured data: mainEntity is required and must be a Person or Organization; sameAs is “the URL to other external profiles or home pages for the profile”.
Google Organization structured data: sameAs is “the URL of a page on another website with additional information about your organization”, such as a social media or review site profile.
JSON-LD 1.1 node identifiers: @id is an IRI; nodes with the same @id in one document are the same node; relative IRIs resolve against the document base.
schema.org sameAs: a reference web page that unambiguously indicates the item’s identity, e.g. a Wikipedia page, Wikidata entry or official website.

Merge rules

Same entity: both are Person, or both are Organization, and they share a normalized @id, or a valid sameAs profile or url link (for a Person, a url that is only a site home page does not count here).
A name or alternate name (ignoring case and spaces), or a Person url that is only a site home page, merges descriptions only when the merge does not join two different @id values. Otherwise they stay separate and the tool reports “same name, different @id“.
Blank node identifiers (_:b0) and relative @id values in pasted code without a URL only identify nodes on their own page. A relative @id is resolved against @context @base when one is set, otherwise against the page URL.
Recommended @id: the most frequent spelling. If no @id exists, the tool builds one from the entity home’s domain plus /#person or /#organization and labels it as a suggestion.
Other properties: definitions that use the recommended @id take priority, then the most frequent value wins. alternateName collects every alias and other spelling of the name; sameAs is the union of valid links without duplicates, platform home pages or pages on the entity’s own site.
The recommendation only merges values found in the input and never adds information. Conflicting properties are listed so you can confirm them.

Common mistakes and fixes

The article repeats the author without an @id. The about page has a full Person, but the article author only has a name:

1	"author": { "@type": "Person", "name": "Jane Doe" }

Reference the same @id and keep name and url, so the author is still identifiable through url if a search engine does not merge @id across pages:

"author": {
  "@type": "Person",
  "@id": "https://example.com/#person",
  "name": "Jane Doe",
  "url": "https://example.com/about/"
}

The author page on another site uses another @id. The personal site uses https://example.com/#person, while a partner site’s author page writes "@id": "#author". The relative value resolves against that page’s URL and becomes a different identifier. Both Person definitions should use the same absolute URL, and the author page’s ProfilePage.mainEntity should point to it.

sameAs lists a platform home page or a post. https://www.linkedin.com/ or https://github.com/username/some-repo does not say who the person is. Use profile URLs such as https://www.linkedin.com/in/username/ and https://github.com/username.

The same person has two employers. The personal site’s worksFor references https://example.com/#organization, but the company’s author page inlines an Organization with no @id and a different name. If they are the same company, pick one @id and move the other names into the organization’s alternateName.

When an author publishes on both a personal site and an employer’s site, a reliable setup is:

Put the full Person definition on the personal site’s about page with a fixed @id, e.g. https://yourdomain/#person, and mark the about page up as a ProfilePage.
On the company site, use the same @id in the author page’s ProfilePage.mainEntity and in every article author, together with name, url and sameAs whose values match the personal site word for word.
Link both ways: the personal site’s Person.sameAs lists the company author page, and the company site’s url or sameAs points to the personal site.

Click the “Linus Li author entity” example to see the live markup on this site and on the Jindouyun SEO site, and the differences the tool finds between them.

FAQ

Does Google merge identical @id values across pages?

Google has not said (D Speculative). The JSON-LD specification only says that nodes with the same @id in one document are one node. Google’s Article documentation says it uses the author’s url and sameAs to tell authors apart (A Confirmed), so the tool recommends keeping name and url at every reference instead of a bare @id.

Do I need @id? Is url plus sameAs enough?

url and sameAs alone meet Google’s documented recommendations. @id lets several descriptions share one identifier: nodes on the same page merge directly, and across pages it removes some of the guesswork of matching by name. You can use both together.

What format should @id use? Does it have to resolve?

@id is an identifier and does not need to load. A common pattern is the home page plus #person, or the about page URL plus #person. It must be an absolute URL, and it must not change once chosen, or old and new pages become two entities again.

What belongs in sameAs?

The entity’s own profiles: LinkedIn, GitHub, X, Crunchbase and similar pages, an author page on another site, and an existing Wikidata or Wikipedia entry. Leave out platform home pages, single posts and other people’s pages. Pages on your own site belong in url.

Will a personal site and a company site be treated as two different people?

When both use the same @id, name, job title and sameAs, and link to each other, they are more likely to be recognized as one person. Google has not published its entity reconciliation rules (D Speculative), so what the tool can do is surface every visible inconsistency.

Why can’t the tool fetch the JSON-LD of a URL?

Our server fetches the raw HTML and returns only the JSON-LD in it. Structured data injected by JavaScript, pages behind a login and sites that block server requests cannot be read; paste the code instead. Fetching is rate limited to 30 requests per IP per hour, and server-side cache hits count towards it too. Within one page view the tool reuses URLs it already fetched successfully, so checking again after editing one row does not spend the quota again. If the limit is reached during a check, the remaining rows are not fetched and their paste boxes open.

Does the tool store my data?

Pasted code is processed in your browser and never uploaded. The URLs and code you enter are saved in your own browser’s local storage so you can pick up where you left off; “Clear” removes them.