Schema markup in 2026: build the entity graph, not the plugin output

Islands versus a graph

Here is the drawer of cables, as a typical plugin emits it: an Organization block on the homepage with a logo; an Article block on each post with an author that is a bare string; a FAQPage block wherever the editor ticked a box; a BreadcrumbList everywhere. Four types, no relationships. The author string does not point at the organisation. The organisation does not list the site's profiles. Nothing has an @id, so nothing can be referred to.

Here is the graph. One Person or Organization is the root, with a stable @id such as https://example.com/#org. The WebSite names it as publisher. Every Article names the same @id as author and publisher. Every Service or Product names it as provider or brand. The root carries sameAs links to the profiles that say the same thing elsewhere: LinkedIn, the company register, the industry body. Now a machine reading any page can walk to the entity behind it, and from there to everything else the site says, and check that it all agrees.

The difference is not cosmetic. When three small businesses on three platforms came to me with "schema issues", the fix on each was the same: delete the islands, write one connected graph, validate to zero errors. Framer, Elementor and Beaver Builder each needed a different way of injecting the script. The graph itself was identical in shape.

What the markup must never do

Describe what is not on the page. A Product price the page does not show, an aggregateRating with no reviews a human can see, a FAQPage whose questions appear nowhere in the copy. Google's guidelines call this out, the validators cannot catch it, and the AI engines increasingly cross-check. Markup that contradicts the page is worse than no markup, because it gives a machine a reason to distrust everything else you say.

Disagree with itself. One founding year in the Organization, another in the about page, a third in the footer. A Person whose jobTitle says one thing and whose LinkedIn says another. The sites being deposed by agents, which I wrote about earlier this year, fail on exactly this kind of inconsistency.

Stack types for the sake of it. Twelve blocks on a homepage is not thoroughness. A machine spends its effort reconciling them and finds nothing to reconcile them to.

A graph you can copy

The site you are reading serves this on every page, in one script in the head. Simplified:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://jamiemckaye.com/#jamie",
      "name": "Jamie McKaye",
      "jobTitle": "Technical SEO consultant & full-stack developer",
      "url": "https://jamiemckaye.com",
      "address": { "@type": "PostalAddress", "addressLocality": "Hersham", "addressRegion": "Surrey", "addressCountry": "GB" },
      "sameAs": ["https://www.linkedin.com/in/jamieseo", "https://x.com/jamiemckaye", "https://medium.com/@jmckaye"]
    },
    {
      "@type": "WebSite",
      "@id": "https://jamiemckaye.com/#site",
      "url": "https://jamiemckaye.com",
      "name": "jamiemckaye.com",
      "publisher": { "@id": "https://jamiemckaye.com/#jamie" }
    }
  ]
}

Each piece of writing then adds an Article whose author and publisher are { "@id": "https://jamiemckaye.com/#jamie" }, and each service page adds a Service whose provider is the same reference. Nothing is repeated; everything points home. Pages that genuinely answer questions add a FAQPage built from the same question list the page renders, so the two cannot drift apart.

If you are on WordPress, the better plugins can be configured to emit something close to this; the worse ones cannot, and a short custom snippet in the theme's head beats them. On Shopify and most builders, a theme-level script with the root entities and per-template additions does the job. The platform is rarely the obstacle. The decision to have one graph is.

How to check it, honestly

1. Validate. The schema.org validator for correctness, Google's Rich Results Test for eligibility. Zero errors, and read the warnings.
2. Read it against the page. Every fact in the markup should be visible on the page. Every important fact on the page should be in the markup. The exercise takes ten minutes and finds the price that changed in March.
3. Walk the graph. From any page, can you follow @id references to the root entity and from there to the profiles? If a reference points at an @id that no block defines, the graph is broken, and the validators will not tell you.
4. Fetch it as a machine. The JSON-LD has to be in the HTML the crawler receives. A plugin that injects it with JavaScript after load serves it to browsers and to Google's renderer eventually, and to the AI crawlers never. Check the raw response.
5. Grade it. The Agent-Ready Grader on this site reads structured data as one of its weighted categories and is specific about dangling references and islands. It is free, and it is the same instrument I run for clients.

Why this matters more than it did

For a decade, structured data was a rich-results feature with a modest ceiling: do it right and get stars; do it wrong and get nothing. The answer engines moved the ceiling. ChatGPT, Perplexity and Google's own AI features decide what to cite by working out who is behind a page and whether the page can be trusted, and a connected graph is the cheapest, clearest way a site has of answering both questions. The sites that treat it as a plugin checkbox are legible to a 2019 crawler. The sites that treat it as the entity's description of itself are legible to whatever reads them next.