Schema Markup Guide: JSON-LD, Types and Testing

Schema markup, or structured data, is machine-readable information that describes what a page is about: this page is an article by this author, this product costs this much, this business is open these hours. Search engines use it to understand content more precisely, and Google uses it to decide whether a page is eligible for rich results such as product stars, breadcrumbs or event listings. This guide covers formats, the types worth using, how to structure markup cleanly, and how to test it.

What structured data does and doesn't do#

Two points get lost in most discussions:

• Markup makes a page eligible for rich results. It doesn't guarantee them. Google says it does not guarantee that structured data will show up in results, even when the markup is correct.
• Rich results are features, not rankings. Structured data helps Google understand and display a page. It isn't a shortcut to a higher position.

Structured data also has uses outside Google. Other search engines, social platforms and various applications read schema.org vocabulary, so accurate markup still has value when a particular rich result doesn't exist.

JSON-LD vs Microdata vs RDFa#

There are three ways to embed schema.org data in HTML.

JSON-LD is a JSON block inside a <script> tag, separate from the visible HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Co",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png"
}
</script>

Microdata adds attributes to existing HTML elements:

<div itemscope itemtype="https://schema.org/Organization">
  <a itemprop="url" href="https://example.com/"><span itemprop="name">Example Co</span></a>
</div>

RDFa works in a similar way with attributes such as vocab, typeof and property.

Google supports all three but recommends JSON-LD where your setup allows it, describing it as the easiest to implement and maintain at scale. JSON-LD keeps data separate from layout, so a design change doesn't silently break your markup, and a CMS or template can generate it in one place.

Common types worth knowing#

schema.org defines hundreds of types. Google supports rich results for a much smaller subset, and each one has its own documentation. The types most sites use:

• Organization: name, logo, URL and official profiles (sameAs). Belongs on the home page or about page.
• WebSite: site name, which Google can use in the site name shown in results.
• Article / BlogPosting / NewsArticle: headline, author, dates and images for editorial content.
• BreadcrumbList: the page's position in the site hierarchy.
• Product with Offer, and Review or AggregateRating where you have real reviews: price, availability and ratings.
• LocalBusiness: address, opening hours and phone number for physical locations.
• Event, Recipe, VideoObject, JobPosting, SoftwareApplication: each tied to a specific rich result with its own requirements.

Required and recommended properties#

Each Google feature lists required properties, which you must include to be eligible, and recommended properties, which add detail. Google's guidance says it's better to supply fewer recommended properties that are complete and accurate than to fill in every possible property with incomplete or inaccurate data.

A practical approach:

1. Open Google's documentation for the specific feature you want.
2. Implement every required property.
3. Add recommended properties only where you have reliable data, for example a real priceValidUntil or an actual author.url.
4. Don't invent values just to clear a warning. A warning about a missing recommended property doesn't block eligibility.

Connecting entities with @graph and @id#

Many pages need several related objects: the organization, the website, the page and the article. Instead of separate unconnected blocks, put them in one @graph and link them with @id references:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": ["https://www.linkedin.com/company/example-co"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Co",
      "publisher": { "@id": "https://example.com/#org" }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/schema-guide/#article",
      "headline": "Schema Markup Guide",
      "datePublished": "2026-09-11",
      "dateModified": "2026-09-11",
      "author": { "@type": "Person", "name": "Jane Doe" },
      "publisher": { "@id": "https://example.com/#org" },
      "isPartOf": { "@id": "https://example.com/#website" },
      "mainEntityOfPage": "https://example.com/blog/schema-guide/"
    }
  ]
}

The @id values are identifiers, not pages that need to exist. Using a URL plus a fragment (#org) keeps them unique and stable. Define the organization once, then refer to it by @id everywhere else, instead of repeating its details with slight variations on different pages.

Follow Google's structured data guidelines#

Google's general structured data guidelines come down to one principle: markup must describe what the reader actually sees. In practice:

• Don't mark up content that isn't visible on the page.
• Don't mark up irrelevant or misleading content, such as fake reviews or ratings for something the page doesn't offer.
• Keep values current. A product price in markup that doesn't match the price on the page is a classic error.
• Put the markup on the page it describes. A review snippet belongs on the reviewed product's page, not on a category page.

Violations can lead to a structured data manual action, which removes the affected pages' eligibility for rich results.

FAQ and HowTo: what changed#

Many older guides still recommend FAQ and HowTo markup for extra space in search results. That advice is out of date:

• In 2023, Google limited FAQ rich results to well-known, authoritative government and health websites and stopped showing HowTo rich results. Google's documentation changelog records that HowTo results are no longer shown on desktop or mobile.
• In May 2026, Google deprecated the FAQ rich result entirely. The Google Search Central documentation changelog records that the feature is no longer shown in Google Search results.

FAQPage and HowTo remain valid schema.org types, and other consumers may still read them. But don't add them expecting a Google rich result, and don't sell them to clients as a visibility tactic.

How to test your markup#

Use two different tools, because they answer two different questions.

1. Google's Rich Results Test checks whether a live URL or a code snippet is eligible for Google's rich results. It shows which features were detected, plus errors and warnings. It renders the page, so it also catches markup that JavaScript injects.
2. The Schema Markup Validator checks markup against the full schema.org vocabulary, whether or not Google supports a rich result for that type. Use it for types Google doesn't feature, and for general correctness.

Our Schema Markup Validator tool is a quick way to extract and review the structured data a page serves. For ongoing monitoring, the enhancement reports in Google Search Console show errors across all pages of a given type, which matters more than testing one URL.

A workflow that catches most problems:

1. Test one example of each template (product, article, category) before release.
2. Fix errors first. Only address warnings where you have real data.
3. Check that each value in the markup matches the visible page.
4. After deployment, watch Search Console's enhancement reports for new errors.

Common mistakes#

• Several conflicting Organization blocks, often added by different plugins.
• Markup copied from another page and never updated, so the headline and dates are wrong.
• Review stars with no visible reviews on the page.
• JSON syntax errors, such as trailing commas or unescaped quotes, that invalidate the whole block.
• Relative URLs in url, image or logo fields. Use absolute URLs.
• Markup that exists only on the desktop template when the mobile template omits it.

Structured data is one part of a healthy page. Run an SEO Checker pass for the rest, and see meta tags for SEO for the head elements that sit alongside your JSON-LD.