Wednesday, September 2, 2026
Always Evolving SEO
SEO Tips

A No-Nonsense Schema Markup Checklist for 2026

By Paul Lovell · April 22, 2026 · 4 min read

Structured data has quietly become more important as search results have gotten richer and AI-driven features increasingly rely on machine-readable content to generate summaries, answer boxes and citations. Here's what's actually worth prioritising.

Start with what Google explicitly supports

Not every Schema.org type unlocks a visible feature in search results. Focus first on types with documented support in Google's structured data search gallery:

  • Article / NewsArticle for news and blog content — required for several publisher-focused features.
  • Product and Review for e-commerce, particularly for star ratings in search results.
  • FAQPage and HowTo, used more selectively than in previous years but still valuable when genuinely applicable.
  • Organization and LocalBusiness for entity clarity and knowledge panel eligibility.
  • BreadcrumbList for clean breadcrumb display in search results.

Everything else is optional. Marking up types with no documented Google support isn't harmful, but it won't produce a visible result — so don't let it displace work that would.

Use one @graph, not a dozen script tags

This is the single most common structural mistake I see, and it's invisible in most validators.

If your Organization, Person, WebSite, Article and Breadcrumb markup each sit in their own separate <script type="application/ld+json"> block, they are separate, unconnected graphs. References between them by @id won't resolve, and you lose the entity relationships that are the entire point of doing this properly.

Put every node for a page inside one @graph array, in one script tag, and connect them with @id references:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example" },
    { "@type": "WebSite", "@id": "https://example.com/#website",
      "publisher": { "@id": "https://example.com/#organization" } },
    { "@type": "NewsArticle", "@id": "https://example.com/post/#article",
      "publisher": { "@id": "https://example.com/#organization" },
      "isPartOf": { "@id": "https://example.com/#website" } }
  ]
}

Every @id referenced should be defined somewhere in the same graph. A reference pointing at an @id that isn't defined on the page is a dangling reference — valid JSON-LD, but it asserts nothing useful.

Stable @ids are what make entities work

Give every meaningful entity a stable, absolute @id — a URL with a fragment, like https://example.com/#organization — and reuse it consistently across every page.

This is what lets search engines understand that the Organization on your homepage, the publisher of your articles, and the employer in your author's profile are all the same entity, rather than three separate things that happen to share a name. Anonymous nodes repeated on each page don't achieve that.

If you run multiple related sites, sameAs is how you link a Person or Organization entity across them. It's weaker than a shared @id but it's the correct tool when the sites are genuinely separate properties.

Common mistakes worth fixing

  1. Marking up content that isn't visible to users. Structured data must reflect what's actually on the page — Google's guidelines are explicit, and mismatches can lead to manual actions.
  2. Duplicate or conflicting schema. Sites using multiple plugins that each inject their own schema often end up with contradictory markup on the same page — two different Organization nodes with different names is a classic.
  3. Over-marking every possible type "just in case." More schema isn't inherently better. Irrelevant markup adds maintenance overhead without adding value.
  4. Fabricated review or rating data. Self-serving aggregateRating on your own organisation is a policy violation and a reliable way to lose rich results entirely.
  5. Letting dates go stale. dateModified that never changes, or that updates on every build regardless of whether content changed, are both worse than useless.

A quick audit process

Run your key templates — homepage, product/service pages, blog posts — through Google's Rich Results Test, which shows what Google can actually parse and which features you're eligible for.

Then run the same pages through the Schema.org validator, which checks vocabulary correctness rather than Google feature eligibility. The two catch different problems: Google's tool won't flag an invalid property if it doesn't affect a feature, and Schema.org's won't tell you whether you qualify for rich results.

Check Search Console's Enhancements reports monthly. Structured data breaks silently when a CMS update changes field names or a developer removes a "redundant-looking" field — a regular audit catches this before it accumulates across thousands of URLs.

Sources

More in SEO Tips