What is @id in JSON-LD?

In JSON-LD, @id assigns a node its identity — a stable URI such as https://magrios.com/#organization. Other nodes reference that URI instead of re-describing the entity, so a site's markup declares one organization rather than an anonymous copy per page. The identifier semantics are part of the JSON-LD standard; how aggressively engines merge on it is their implementation.

Should every page carry my full schema graph?

No. Serve the full Organization, WebSite, and product graph on the pages that describe the company — home, product, pricing, FAQ. On pages whose primary markup is their own type, like articles, include one compact Organization node sharing the same canonical @id. Engines can merge it with the full graph instead of minting a duplicate entity.

Is it acceptable to leave sameAs empty?

Yes — empty is the correct state until real profiles exist. sameAs is a factual claim about where your organization lives off-domain, and an invented URL points at a 404 or someone else's profile, undermining the agreement entity resolution depends on. Magrios ships sameAs empty by design and populates it only from verified profile URLs.

@id interlinking: one entity across every page

Guide · SEO / AEO / GEO · 3 min read · last verified 2026-07-23

Reviewed before publication Editorial board Independent commercial review

In shortOne canonical @id anchor per real-world thing, referenced by every other schema node, lets engines merge a site's markup into a single entity. The build rules from Magrios's shipped implementation — where refusing to fabricate sameAs…

@id interlinking: one entity across every page — Magrios diagram — A Magrios diagram — every element states a product fact.

@id interlinking gives your organization one canonical identifier — ours is `https://magrios.com/#organization` — and makes every JSON-LD node on every page reference that identifier instead of re-describing the company. Engines can then merge everything your site says into a single entity, rather than minting a fresh anonymous organization for each page they crawl. We shipped this across the Magrios surface on 2026-07-22; the rules below are the ones our code actually enforces, including the two places where refusing to fabricate is the whole design.

What problem does @id interlinking solve?

Without it, each page ships its own anonymous Organization blob. An engine crawling fifty of your pages meets fifty similar-but-unlinked descriptions and has to guess whether they are the same company. With it, there is one node per real-world thing, and every other node points at it.

The confidence split matters here. In JSON-LD, `@id` is the node's identity — that is the standard itself, not interpretation. That engines merge interlinked nodes into one entity is the format's documented design intent and the reasonable reading of search vendors' guidance, but we treat it as exactly that: their claim, not our measurement. What we control is whether our markup makes merging possible or forces guessing.

How is the Magrios graph structured?

Three anchored nodes describe the three real things: `/#organization` (the company), `/#website` (the site), `/#software` (the product). They reference each other instead of duplicating each other:

{

"@type": "WebSite",

"@id": "https://magrios.com/#website",

"name": "Magrios",

"publisher": { "@id": "https://magrios.com/#organization" }

}

The product node's `provider` points at the same organization anchor. The full graph is served on the pages that describe the company — home, product, FAQ, pricing. Pages whose primary markup is their own type, such as an Article or a CollectionPage, do not repeat the whole graph; they carry one compact Organization node that shares the canonical `@id`, so an engine merges it with the full graph instead of minting a second entity. That compact node is five keys — type, `@id`, name, url, logo — plus `sameAs` when real profile URLs exist to fill it.

What goes in sameAs — and what must never?

`sameAs` is a factual claim about where your organization exists off your domain. In our implementation it is configuration that defaults to empty: real profile URLs appear when they exist, and until then the key is dropped from the output entirely.

That refusal is the story. An invented-but-plausible LinkedIn or Crunchbase URL is not harmless filler — it points at a 404 or at someone else's profile, and either way it teaches engines that your self-description cannot be trusted. Entity resolution runs on agreement between sources; a fabricated profile is manufactured disagreement. Empty and honest beats populated and wrong.

Which build rules keep the graph honest?

| Rule | How it is enforced | What it prevents |

|---|---|---|

| Prices come from the plan model | Schema reads the same pricing objects the pricing page renders; tests pin the agreement | A stale hand-edited price being quoted back at you by an assistant |

| No URL is ever invented | Absolute URLs render only when the site origin is configured; otherwise the keys are dropped | Guessed domains and dead links in the entity record |

| `sameAs` holds real profiles only | Defaults to empty; populated from configuration, never authored inline | Fabricated corroboration that damages entity resolution |

| FAQPage mirrors the visible page | Questions and answers are extracted from the page's own markup at render time | Schema describing content a visitor cannot see |

The common thread: every value in the graph is either observable on the page or derived from the single source of truth that renders the page. Nothing is typed twice, so nothing can disagree. That is the same discipline we argue for in evidence-first AI, applied to our own markup.

Does a clean entity graph guarantee AI visibility?

No — we are the measured counterexample. With this graph live on every page, our locked-benchmark AI-visibility audit still scored 0/100, twice — both runs recorded, the method itself published. The graph is declaration infrastructure: it makes your entity unambiguous to machines that already have a reason to look at you. Getting them to look — corroboration on pages you do not control, the third-party sources assistants actually draw on — is a separate and harder job, and your own site rarely wins those citations. Do the graph work because it is cheap, permanent, and removes ambiguity. Do not expect it to be the whole answer.