Schema Markup: Which Structured Data Still Earns Rich Results

Structured data has a reputation as an SEO shortcut: add some JSON, get stars and dropdowns in search results. The reality is narrower and more useful. It tells search engines what a page is, and for a limited set of page types it makes the page eligible for an enhanced result. It is not a ranking boost, and a lot of the markup that tutorials still recommend no longer produces any visible result.

What structured data does

Structured data is a machine-readable description of a page, written in the vocabulary at schema.org. Google says it recommends the JSON-LD format, which sits in a single <script type="application/ld+json"> block and does not touch the visible HTML.

It does two things:

• It helps a search engine interpret the page. A string that looks like a date becomes a publication date. A name next to a logo becomes an organisation.
• It makes the page eligible for rich results, for the specific features Google supports. Eligibility is not a guarantee, and the feature may never appear even when the markup is perfect.

It does not make a page rank higher. A page with no markup and good content will outrank a page with perfect markup and thin content.

The change that surprised everyone: FAQ

In August 2023, Google announced that FAQ rich results from FAQPage markup would only be shown for well-known, authoritative government and health websites. For nearly every other site, the markup no longer produces the expandable questions in the results.

This is worth remembering when an older guide tells you to add FAQ schema to every page for extra search real estate. It will not. The markup is still valid, and describing a page's questions and answers accurately does no harm, which is why this site still includes it on tool pages. But it is there to describe the page, not because it earns a result.

The wider lesson: Google decides which features exist, and it changes them. Check the current structured data gallery before investing effort in any type.

The types worth adding

For most sites, a small set covers almost everything that matters:

Others, such as Event, Recipe, LocalBusiness and JobPosting, matter a great deal if that is what you publish and are irrelevant otherwise.

One caution about SoftwareApplication, the type for web apps and tools: its enhanced result needs genuine ratings or reviews. Without them the markup is only a description. Never add rating values you cannot back up. Invented ratings are exactly what structured data policies exist to catch.

Rules that get sites into trouble

• Mark up what users can see. Structured data must reflect the visible content of the page. Marking up a review that is not shown, or a price that differs from the page, violates Google's guidelines.
• Do not mark up everything as an article. Use the type that matches the page.
• Do not duplicate and conflict. A theme adds one set of markup, a plugin adds another, and now two Organization blocks disagree. Search the page source for application/ld+json and read what is there.
• Use ISO 8601 dates and absolute URLs. 2026-10-19, not "last Monday", and https://example.com/image.png, not /image.png.
• Escape < inside string values. A value that contains </script> would end the block early. Writing the character as < in the JSON is valid and prevents it.

The block can sit in the <head> or the <body>. Google can also read JSON-LD that JavaScript adds after the page loads, but markup in the HTML your server sends is the simplest and most dependable choice.

Connecting the pieces with @graph

Instead of several unconnected blocks, one @graph can hold every entity on the page and link them by @id:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/post/#post",
      "headline": "Post title",
      "datePublished": "2026-10-19",
      "author": { "@type": "Person", "name": "Author Name" },
      "publisher": { "@id": "https://example.com/#organisation" }
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organisation",
      "name": "Example",
      "url": "https://example.com"
    }
  ]
}

The post points at the publisher by @id rather than repeating it. Include the referenced entity in the same graph on every page. A crawler reading one page should not need another page to resolve a reference.

Validate before you ship

Two tools answer different questions. Google's Rich Results Test tells you whether a page is eligible for Google's features. The Schema Markup Validator checks the markup against schema.org generally, with no Google-specific rules.

A surprising number of failures are plain JSON mistakes, a trailing comma or an unclosed quote, and no schema validator will point at the line for you. Paste the block into the JSON formatter first. It reports the exact line and column of the problem.

The schema markup generator builds Article, FAQPage, BreadcrumbList and other common types from a form, so you are not writing the JSON by hand. Add the basics from the table above, validate them, and stop. The returns on markup beyond that are small. If you are also preparing how your pages look when shared, Open Graph tags are the other half of that job.