Schema Markup for SEO: What Google Supports and How to Validate It

The Two Tests Every Schema Decision Needs

Structured data is a standardised, machine-readable way to describe information on a page. Most Google Search structured data uses Schema.org vocabulary, while formats such as JSON-LD, Microdata and RDFa determine how that information is placed in the page.

Google’s structured data documentation makes an important distinction: Schema.org contains more types and properties than Google Search uses for documented search features. For Google Search behaviour, Google Search Central is the reference to check.

It helps to separate three ideas that are often bundled together as ‘schema’:

• Schema.org vocabulary: types and properties used to describe things such as Article, Product, Organization and FAQPage.
• Structured data implementation: the code placed on the page, commonly JSON-LD.
• Google Search feature: a documented use of structured data that can make eligible content available for a richer search appearance.

Even then, eligibility is not a promise of display. Google’s general structured data guidelines state that correctly marked-up content may still appear as an ordinary text result. They also state that a structured data manual action removes rich result eligibility without, by itself, changing the page’s ranking in Google web search.

So structured data should not be treated as a direct ranking switch. Its practical job is to represent the page accurately and, where Google supports the feature, make that page eligible for the relevant search treatment.

Choose Markup From the Page Purpose, Not From a Schema List

Browsing Schema.org for types that could be added is an easy way to create unnecessary markup. Start with the page instead. Identify its main purpose, then check the current Google Search structured data gallery and the documentation for the feature you intend to use.

This is deliberately not a ‘top schema types’ list. Search features, requirements and availability change. The feature-specific Google documentation is more useful than a long checklist copied once and left untouched.

FAQPage Shows Why Support Status Matters

FAQPage is a useful example because the vocabulary and the search feature moved in different directions. The Schema.org type still describes a page containing frequently asked questions. Google, however, recorded the FAQ rich result deprecation on 8 May 2026, with the feature no longer appearing from 7 May, and removed its FAQ rich result documentation on 15 June 2026.

That does not make an FAQ section useless. It means the SEO reason for maintaining FAQPage has changed. If another system consumes that vocabulary, there may still be a non-Google reason to use it. If the only purpose was a Google FAQ rich result, that purpose no longer exists.

QAPage Is Not the Replacement

Google still documents QAPage structured data, but the rules are narrow. The page should focus on one question followed by its answers, and users must normally be able to submit alternative answers. Google explicitly lists a site-written FAQ with no user-submitted alternatives as an invalid use case.

Changing an editorial FAQ from FAQPage to QAPage would therefore solve the wrong problem. The markup has to follow the page model, not the search feature a site would prefer to have.

Implement Only What the Page Can Support

Good structured data is usually smaller than teams expect. The objective is not to mark up every entity that can be named. It is to represent the main page purpose clearly, then add other relevant items only when the visible content supports them.

Start With the Main Entity

Ask what the page is actually about. A blog article, product detail page, local business location, recipe and user Q&A page each have a different primary entity. Google also advises using the main structured data type that reflects the main focus of the page.

If the page is an editorial article that happens to mention a product, turning the page into a Product page in structured data would misrepresent it. The visible content decides the markup, not the commercial value of a possible search feature.

Make the Markup Agree With Visible Information

Google’s quality guidelines require structured data to represent the page. Do not insert ratings that users cannot see, a stale product price, an author who is absent from the byline, or business details for a different location. A validator can approve syntax and still miss a misleading implementation.

This is where structured data meets on-page SEO. The title, headings, author, dates, images and factual claims should not tell one story to readers while the structured data tells another.

Use the Format Your Site Can Maintain Reliably

Google supports JSON-LD, Microdata and RDFa. It generally recommends JSON-LD because it is often easier to implement and maintain, but the other two formats are also supported when implemented correctly. Replacing valid Microdata or RDFa solely because JSON-LD is more fashionable is not much of an SEO project.

A Small JSON-LD Example

This simple Article example shows the shape of the markup. It is not a universal template. Production markup should contain only properties that genuinely apply to the article and should be checked against the current Google feature documentation.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A Practical Guide to Structured Data",
  "image": "https://example.com/images/structured-data-guide.jpg",
  "datePublished": "2026-09-01T09:00:00+00:00",
  "author": {
    "@type": "Person",
    "name": "Alex Example",
    "url": "https://example.com/authors/alex-example"
  }
}

More properties are not automatically better. Fewer accurate fields are preferable to a large object padded with stale, inferred or irrelevant values.

Validate at Three Different Levels

A green result from one testing tool answers only one part of the problem. A useful validation workflow separates Google feature eligibility, Schema.org validity and the page Google can actually access.

1. Test the intended Google feature. Use the Rich Results Test for a currently supported Google search feature. Fix critical errors and interpret non-critical issues against the feature guide rather than treating every warning as equally important.
2. Check broader Schema.org markup where needed. The Schema.org Markup Validator can inspect Schema.org-based JSON-LD, RDFa and Microdata. Passing it does not create Google rich result eligibility.
3. Inspect the rendered live page. Compare the final markup with what users can see. After deployment, use URL Inspection where appropriate to check how Google accesses the page, especially after template, plugin, CMS or JavaScript changes.

Then monitor the relevant Search Console rich result or enhancement report where Google provides one. A valid item count is useful, but it still does not mean Google must show a rich result for every eligible page.

Treat Structured Data as Maintained Page Data

Many structured data failures are maintenance problems rather than coding problems. A plugin can continue outputting an old type, a product feed can disagree with the visible price, an author URL can change, or two templates can emit conflicting entities on the same page.

Recheck structured data when any of these conditions changes:

• the page’s main purpose or template;
• prices, availability, opening hours, ratings, event details or other time-sensitive values;
• author, organisation, location or publisher information;
• the CMS, SEO plugin, theme, JavaScript or product feed that generates markup;
• Google’s documented support or policy for the feature being targeted.

Also look for duplicated entities generated by more than one system. A theme and an SEO plugin can each produce valid JSON-LD while still disagreeing about the main entity, author, dates or organisation details. Validation should therefore compare the complete rendered output, not just the settings screen of one plugin.

The durable rule is quite modest: describe the page honestly, check that Google still supports the feature you are targeting, validate with the tool that answers that question, and revisit the markup when either the page or the search feature changes.