← Back to Blog

Most sites add a few blocks of schema markup, run them through a validator and move on. Going beyond the basics in 2026 is less about adding more types and more about three things: connecting your markup into one consistent graph, knowing which rich results Google still shows, and dropping the markup that no longer pays off. This guide covers all three, based on Google’s own documentation, linked throughout.

If you are new to structured data, start with what structured data is and how to add schema markup, then come back here.

What schema markup does, and what it does not

Google describes structured data as explicit clues about the meaning of a page. It does two jobs: it helps Google understand the page, and it makes the page eligible for rich results such as product prices, review stars, breadcrumbs or event dates.

Three limits are worth knowing before you invest time in it:

Build one graph, not separate blocks

The most common gap on sites that already use schema is that every block stands alone: an Organization block in the footer, an Article block from a plugin, a BreadcrumbList from the theme, each describing the same entities in slightly different ways. The cleaner approach is one JSON-LD graph per page, where each entity has a stable @id and the others refer to it.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#org",
      "name": "Example Ltd", "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": ["https://www.linkedin.com/company/example"] },
    { "@type": "WebSite", "@id": "https://example.com/#website",
      "url": "https://example.com/", "name": "Example",
      "publisher": { "@id": "https://example.com/#org" } },
    { "@type": "Person", "@id": "https://example.com/team/jane#person",
      "name": "Jane Smith", "url": "https://example.com/team/jane",
      "worksFor": { "@id": "https://example.com/#org" } },
    { "@type": "BlogPosting", "@id": "https://example.com/blog/post#article",
      "headline": "Post title", "datePublished": "2026-10-03",
      "author": { "@id": "https://example.com/team/jane#person" },
      "publisher": { "@id": "https://example.com/#org" },
      "isPartOf": { "@id": "https://example.com/#website" } }
  ]
}

Why this helps:

Organization: your identity, defined once

Google says adding Organization markup to your home page can help it understand your organisation’s administrative details and disambiguate it in search results. Some properties work behind the scenes, while others can influence visual elements, such as which logo is shown in search results and in your knowledge panel. Merchants can influence more, such as return policy, address and contact details.

Article and author: name the people behind the content

Google’s Article documentation has no required properties, but it gives clear best practices for authors:

Pair the markup with a visible byline and an author page or bio on the site. Markup describes what is on the page; it is not a substitute for it.

Rich results that are still worth the work

These types can still change how a result looks in Google, depending on your site:

Google’s search gallery is the authoritative list of what is currently supported, with the required properties for each.

Find the pages missing schema, or carrying broken schema. Daylytix checks structured data on every crawled page and recommends a type for each. Free for 7 days.
Try it free →

Markup that no longer pays off

Several types that were standard advice a few years ago now produce little or nothing in Google:

If you are deciding where to spend time, these are the ones to skip. Leaving existing markup in place is harmless.

Errors that cost you rich results

Google’s general structured data guidelines list the reasons markup gets ignored or penalised:

Violations can lead to a structured data manual action. Google notes that such an action removes the page’s eligibility for rich results; it does not affect how the page ranks in web search. Check the Manual Actions report in Search Console if rich results disappear across the site.

Tip: Google says JSON-LD, Microdata and RDFa are all equally fine as long as the markup is valid, and recommends JSON-LD because it is usually the easiest to implement and maintain.

Where to start on your own site

A practical order for a site that already has some markup:

  1. Inventory what is there. Crawl the site and list, per template, which types each page outputs and where they come from: theme, plugin, tag manager or hand-written code. Most problems show up here as duplicates from two sources.
  2. Choose one source per template. Decide which system owns the markup for each page type and switch off the others.
  3. Define the shared entities once. Organization and WebSite with stable @id values, and a Person for each author with a real author page.
  4. Map templates to rich results. Product pages to Product, articles to Article or BlogPosting, locations to LocalBusiness, every page to BreadcrumbList. Check the required properties for each in the search gallery.
  5. Remove what misleads. Self-serving review stars, markup for content that is not on the page, and types that describe something the page is not.
  6. Validate, ship, then watch Search Console for a few weeks: the rich result reports show whether Google accepts the markup across the site, not just on the URL you tested.

Validating and monitoring at scale

For the rest of a technical review, see the technical SEO audit checklist.

Related tool
Schema Markup Generator →

Generate valid JSON-LD for common page types, ready to copy into your site.