Structured Data: Which Schema Types Actually Earn Rich Results

JSON-LD, microdata or RDFa

Three syntaxes express the same vocabulary. Use JSON-LD, for three practical reasons.

Google states a preference for it. It lives in a single <script> block rather than being woven through your HTML attributes, so a redesign does not silently destroy your markup. And it can be injected by a template or tag manager without touching page structure.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your headline here",
  "author": { "@id": "https://example.com/#jane" }
}
</script>

Microdata — attributes like itemprop sprinkled across your markup — still works, and if you have inherited it there is no urgency to migrate. Just do not start there. RDFa is rarely worth considering for a marketing site.

Place JSON-LD in the <head> or the <body>; both are fine. Head is tidier. If your framework injects it client-side, verify it appears in the rendered HTML, since server-rendered is strictly safer.

Tier 1: types that render rich results

These can change how your result looks in search. This is where markup effort pays visibly.

Rich result support genuinely changes over time — Google has narrowed FAQPage and HowTo display significantly. Check current documentation before planning work around any single one, and never build a content strategy whose only justification is a rich result that might be withdrawn.

Tier 2: types Google reads but does not render

No visible change, real value. These are how Google understands what your site and its entities are.

• Organization — who publishes this site. Carries your logo, contact points, service area and sameAs. Foundational.
• Person — the author or the individual behind the business. The core of any entity work.
• WebSite — names the site as a whole. Feeds the site-name feature in search results.
• WebPage and its subtypes — AboutPage, ContactPage, ProfilePage, CollectionPage. Tells Google what kind of page this is.
• Article / BlogPosting / NewsArticle — authorship, dates, publisher. Rarely renders outside news surfaces, but it is how article-ness is established.
• Service — what you offer, where. Useful for service businesses with no products to mark up.

If you are a consultancy or service business, tier 2 is where nearly all your value sits. There is no rich result for “being a credible consultant”, and that is fine — the goal is being understood correctly, and that shows up in name queries, snippet quality and AI answers rather than in a visual treatment.

Tier 3: types that do nothing visible

Valid schema.org types with no rich result and little evidence of use. Marking them up is harmless and mostly pointless:

• SiteNavigationElement for your menu.
• WPHeader, WPFooter, WPSideBar for page furniture.
• SpeakableSpecification outside the narrow news programme it was built for.
• ImageObject on every decorative image.

Some SEO plugins emit all of this by default, which is why so many sites have enormous schema blocks doing very little. Volume of markup is not a signal. A short, correct, connected graph is better than a long one padded with furniture.

Connect your nodes with @graph

The most common structural mistake is emitting several independent blocks that never reference each other. Google then has an article, a person and an organisation on one page with no stated relationship between them.

Use @graph and stable @ids so the nodes point at one another:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/post/#article",
      "headline": "...",
      "author":    { "@id": "https://example.com/#jane" },
      "publisher": { "@id": "https://example.com/#brand" },
      "isPartOf":  { "@id": "https://example.com/#website" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#jane",
      "name": "Jane Smith",
      "worksFor": { "@id": "https://example.com/#brand" }
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#brand",
      "name": "Example Studio",
      "founder": { "@id": "https://example.com/#jane" }
    }
  ]
}

Now it is one connected graph: a post, written by a person, who runs the organisation, that publishes the site. Every reference resolves. Compare that with three orphan blocks and the difference in what Google can conclude is substantial.

Keep the @ids permanent. Changing them creates new entities and discards accumulated confidence.

The rules that get markup ignored

1. Markup must reflect visible content. Marking up an FAQ that is not on the page, or a rating nobody left, violates Google’s structured data policies and can trigger a manual action.
2. Do not mark up content behind interaction only. Content inside an accordion is fine because it is in the HTML. Content loaded only after a click may not be.
3. Required properties are required. Missing one usually disqualifies the item from a rich result entirely rather than degrading gracefully.
4. Be specific with types. Product beats Thing. The more specific the type, the more Google can do with it.
5. Do not mark up the same thing twice with conflicting values. Two Article blocks with different headlines on one page is a contradiction, not redundancy.
6. Dates must be ISO 8601. 2026-09-01, not 1 September 2026.
7. Self-serving reviews do not count. AggregateRating on your own site about your own business, with no genuine review source, is the single most reliable way to earn a penalty here.

Validating properly

Use two tools, because they answer different questions:

• Google’s Rich Results Test tells you whether Google considers the page eligible for a rich result, and which type. This is the one that reflects what Google actually does.
• The Schema Markup Validator checks your markup against the schema.org vocabulary generally, including types Google ignores. Use it to catch structural errors and broken @id references.

Then check Search Console’s Enhancements reports, which show errors Google found on real crawls of your live site — the only source that reflects your whole site rather than one URL.

Two habits worth building. Test the rendered HTML, not your template source, especially with client-side injection. And after any template change, re-test one page of each type; a broken loop in a template can strip schema from a thousand pages silently.

Where to start

That is perhaps a day of work on a normal site, and it covers essentially all of the available value. The temptation is to keep going — more types, more properties, more nested nodes. Resist it. The goal is a small graph that is completely correct, not a large one that is mostly plausible.

FAQ