Schema (Structured Data) Guide: JSON-LD, @id Graphs and Testing Tools

Structured data (schema) means labelling the information on your page with the schema.org vocabulary so machines can read it. A person looking at a page sees the price, the author or the address instantly; a search engine reads that information explicitly through structured data instead of inferring it.

This guide covers the method I use in practice, from choosing a format to building an @id-linked schema graph and testing the markup. Structured data belongs inside a technical SEO audit; on its own it is not a ranking trick.

Short answer: Schema is structured data that labels page information with the schema.org vocabulary, and JSON-LD is the format Google recommends. Correct markup makes a page eligible for some rich result types, but whether a rich result appears is Google's decision, and the markup must match the visible content of the page.

JSON-LD, Microdata or RDFa: which schema format should you use?

Google supports all three formats but recommends JSON-LD. On new projects I almost never see a reason to use anything else.

The real advantage of JSON-LD is that it is independent of the template: redesigns don't break it, and it can be generated automatically from your database. Google can read JSON-LD injected with JavaScript, but I still prefer to render it server-side in the HTML so other systems can see it reliably too.

Which schema type belongs on which page?

The most common mistake I see is stamping the same generic markup on every page. Each type has a natural home:

On product pages, price, currency and availability must match what the page shows; I cover variants and out-of-stock products in the e-commerce SEO guide. For physical businesses, pick a more specific subtype such as Dentist or Restaurant where one fits, and match address and phone details exactly with your Google Business Profile listing; the full picture is in the local SEO guide.

One caveat: reviews a business shows about itself on its own site (self-serving reviews) are not eligible for star rich results for LocalBusiness and Organization. Adding aggregateRating to your home page brings no benefit, and if the reviews are not visible on the page it also breaks the guidelines.

How do you build a schema graph with @id?

On many sites each plugin outputs its own isolated block: an Organization in one place, the author's name as plain text in another, and a differently spelled company name as the article's publisher. The search engine has to guess that these are the same entity. @id solves this.

An @id is a stable, unique identifier you assign to an entity, usually the canonical URL of a page plus a fragment. You define the entity fully once and only reference that identifier elsewhere. In the example below, the article's author and publisher point to the Person and Organization nodes in the same graph:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Consulting",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": ["https://www.linkedin.com/company/example-consulting"]
    },
    {
      "@type": "Person",
      "@id": "https://example.com/about/#person",
      "name": "Jane Doe",
      "jobTitle": "SEO Consultant",
      "worksFor": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/sample-post/#article",
      "headline": "Sample Post Title",
      "datePublished": "2026-09-01",
      "dateModified": "2026-10-10",
      "author": { "@id": "https://example.com/about/#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "mainEntityOfPage": "https://example.com/blog/sample-post/"
    }
  ]
}
</script>

• Keep it stable: set @id values once and don't change them; the same entity should use the same @id on every page.
• Base it on the canonical URL: the home page for Organization and the profile page for Person are the most logical anchors.
• Use a single source: define the Organization fully in one place; other pages connect to it only through @id.
• Use sameAs correctly: list only the official profiles of the brand or person.

Because this structure describes who the brand is consistently, it is also the technical foundation of the entity clarity work described in the GEO implementation guide.

What is the rich result status of FAQPage and HowTo schema?

A lot of outdated advice still circulates here, so let me be clear. In August 2023 Google limited FAQ rich results to well-known, authoritative government and health websites; since May 7, 2026 it no longer shows FAQ rich results in Google Search at all, and it removed the feature's documentation in June 2026. HowTo rich results were removed in 2023. For a dated list, see the Google updates log.

I add FAQPage markup when the page has questions and answers that users actually see, because it clarifies the content's structure for machines. But I don't pitch it to clients as a way to take up more space in search results. Being a health site is not enough on its own either; the healthcare SEO guide covers the priorities for those sites separately.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "When are orders shipped?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Orders are shipped within two business days."
    }
  }]
}

Google periodically trims the rich result types it supports; FAQ and HowTo are the best-known examples. Before implementing a type, check the current structured data gallery on Google Search Central.

How do you test and monitor schema markup?

Testing answers two different questions: is the markup valid schema.org, and does it meet Google's rich result requirements? That is why I use two tools together.

• Test a few samples from each page template before launch
• Check that price, date, author and address on the page match the markup
• Look for duplicate blocks of the same type in the source code
• Monitor Search Console reports for a few weeks after launch
• Retest after theme, plugin or platform updates

The most common schema mistakes

Most errors I find in audits are not technical; they come from a mismatch between the content and the markup:

• Marking up invisible information: marking up reviews, ratings or FAQs that are not on the page violates Google's guidelines and can lead to a structured data manual action.
• Conflicting plugins: the theme and the SEO plugin each output an Organization, with two different logos and names.
• Mismatched product data: the sale has ended but the markup shows the old price, or a sold-out product is marked InStock.
• Date games: updating dateModified without changing the content, or leaving the old date after a major update.
• Copied templates: foreign URLs and @id values left over from an example taken from another site.
• Placeholder values: filling required fields with empty or dummy values such as “example”.

Structured data also tends to disappear quietly during migrations and platform changes, so add a structured data test to your site migration SEO checklist. If you want an expert review of the markup on your own site, see my SEO consulting service or reach out through the contact page.