Stable Identifier
A durable URI given to a node in structured data so other nodes can reference it instead of repeating it.
What it means
Without identifiers, each block of markup is an island describing something in isolation. With them, an Article node points at its own WebPage node, which points at the Organization that published it. The whole set describes one connected thing.
The part a short definition leaves out
The identifier only helps if it stays the same. Regenerating identifiers on every build or tying them to a URL that changes with every redesign gives you the syntax without the benefit. A stable identifier names the entity. It does not need to open as a separate page.
What changes when identifiers connect the graph
Two nodes can repeat the same organization name and still look like two separate claims. A shared @id tells the reader that both references point to the same organization.
| Without a shared identifier | With a shared identifier |
|---|---|
| The Article contains a fresh copy of the publisher name. | The Article points to one Organization node. |
| The WebPage contains another fresh copy. | The WebPage points to that same Organization node. |
| A parser must decide whether the copies mean the same thing. | The relationship is explicit and no guess is needed. |
A connected JSON-LD example
{
"@context": "https://schema.org",
"@graph": [
{
"@id": "https://example.com/#organization",
"@type": "Organization",
"name": "Example Company"
},
{
"@id": "https://example.com/article/#webpage",
"@type": "WebPage",
"isPartOf": { "@id": "https://example.com/#website" },
"about": { "@id": "https://example.com/#organization" }
},
{
"@id": "https://example.com/article/#article",
"@type": "Article",
"mainEntityOfPage": { "@id": "https://example.com/article/#webpage" },
"publisher": { "@id": "https://example.com/#organization" }
}
]
}The graph reads as one set of relationships:
Article #article
publisher -> Organization #organization
mainEntityOfPage -> WebPage #webpage
WebPage #webpage
isPartOf -> WebSite #websiteFour common identifier failures
- A different
@idin every script block. The page now describes duplicate Organizations or WebPages instead of one connected entity. - A random value on every build. The entity gets a new name each time the site is generated.
- Two URL forms for one entity. Mixing
www, bare domains, trailing slashes, and old domains splits one thing into several identifiers. - An identifier with no references. Adding
@idto a node helps little if the Article, WebPage, WebSite, and Organization still repeat embedded copies instead of pointing to it.
How to validate the repair
- Choose one canonical identifier for each Organization, WebSite, WebPage, Article, and other real entity.
- Use the exact same string wherever another node refers to that entity.
- Search the rendered HTML for the identifier and confirm it does not name two competing nodes of the same type.
- Check several page templates so the identifier does not change between routes or builds.
- Run the QuickRankAI inspection. The stable-identifier check should pass, then the publisher and page-type checks should confirm the connected nodes still say what they are.
Where this comes from
See whether this is costing you anything
The inspection reports on this signal directly, alongside thirty-seven others, and tells you whether it is a quick fix on your site or something deeper.