Schema markup is code that tells search engines what a page is about in a form machines can read without guessing. To add it, pick the schema.org type that matches the page, write it as JSON-LD, place it in the page's HTML, and test it before you ship. This guide walks through each step, with working code, the mistakes that cause errors, and the checks we run ourselves.
TL;DR
- Schema markup does not directly raise rankings. It makes a page eligible for rich results such as product details, ratings and breadcrumbs.
- Use JSON-LD. Google recommends it for most sites because it sits in one block, apart from your visible HTML.
- Mark up only what visitors can see on the page, and use the most specific type available.
- Test with two tools: one for Google's rich result eligibility, one for generic schema.org validity.
- Treat schema as maintenance. When prices, availability or page content change, the markup has to change with them.
Table of Contents
- What schema markup is, and what it is not
- Is schema still worth adding?
- The formats: JSON-LD, Microdata and RDFa
- How to add schema to your website: step by step
- Best practices that keep you out of trouble
- Common errors and how to fix them
- Our perspective
- Check your markup with Pingfloat
- FAQ
- Sources
What schema markup is, and what it is not
Schema.org is a shared vocabulary of types (Article, Product, Organization, Event) and properties (name, price, datePublished). Schema.org says it can be written in several encodings, including RDFa, Microdata and JSON-LD. "Schema markup" is the practice of using that vocabulary on your pages. "Structured data" is the broader term, and in practice people use the two interchangeably.
Google uses structured data to understand the content of a page and to gather information about the things it mentions, such as people, books or companies. When your markup meets a feature's requirements, the page can become eligible for a richer search appearance, called a rich result.
Three things it is not:
- Not a ranking factor. Google's documentation describes structured data as enabling rich results. It does not promise higher positions. The gain comes from a more informative listing that can earn more clicks.
- Not a guarantee. Valid markup makes you eligible. Whether Google shows a rich result depends on the query, the user and the page.
- Not a substitute for content. The markup describes the page. If the page is thin, the markup cannot fix that.
Is schema still worth adding?
Yes, with realistic expectations. Without structured data a page cannot qualify for the enhanced appearances that rely on it, and the markup also gives any system that reads your page an explicit statement of what it contains. Google's gallery of supported features is the place to check what is currently available, because the list changes.
It does change. In 2023 Google announced that FAQ rich results would only be shown for well-known government and health sites, and no longer regularly for everyone else. Anyone who added FAQ markup purely for the search appearance lost that benefit. That is the practical lesson: choose markup that accurately describes your page, and treat any rich result as a bonus.
The formats: JSON-LD, Microdata and RDFa
Google supports three formats and says all are fine as long as the markup is valid and implemented per the feature's documentation. It still points to JSON-LD as the one it recommends in most cases.
| Format | Where it lives | Main trade-off |
|---|---|---|
| JSON-LD | A separate script block in the head or body | Easy to maintain and inject by script or tag manager; must be kept in sync with visible content |
| Microdata | Attributes inside your visible HTML tags | Tied directly to the content, but it clutters templates and breaks easily when markup changes |
| RDFa | Attributes inside your visible HTML tags | Powerful, rarely needed for ordinary sites |
If you inherit a site that already uses Microdata and it validates, there is no need to rewrite it. For anything new, write JSON-LD.
How to add schema to your website: step by step
1. Match the page to a type
Start from what the page is, not from what you hope to win. Common pairings:
- Home or about page:
Organization - Blog post or news article:
Article(orBlogPosting) - Product page where a visitor can buy:
Productwith anOffer - Page with a trail of parent pages:
BreadcrumbList - Page for a physical business: the most specific
LocalBusinesssubtype, such asRestaurant, not the generic parent
Browse the supported features list to see which types lead to a Google appearance. Types outside that list are still valid schema.org and can still describe your content, but they will not produce a Google rich result.
2. Read the feature's required and recommended properties
Each Google feature has its own documentation page listing required properties (needed for eligibility) and recommended ones (which improve the result). Fill in every required property as a minimum. Google's general guidelines add that supplying more recommended properties increases the chance of a high-quality result.
3. Write the JSON-LD
Here is a minimal Article block. Replace the values with your own:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema Markup Guide",
"datePublished": "2026-10-20",
"author": {
"@type": "Person",
"name": "Jane Doe"
},
"image": "https://example.com/images/schema-guide.jpg"
}
</script>
And a Product with an offer, which is where most stores start:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Trail Running Shoe",
"image": "https://example.com/shoe.jpg",
"description": "Lightweight shoe with a rock plate.",
"offers": {
"@type": "Offer",
"price": "89.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}
</script>
The values here are placeholders, not recommendations. The price and availability in your markup must be the ones a visitor sees on the page.
A JSON typo is the most common reason a block fails to parse. Paste the block into a JSON formatter and validator first. A missing comma or an unescaped quote shows up in seconds, before you spend time reading schema warnings that are really syntax errors.
4. Place it in the page
JSON-LD can go in the head or the body. Put it in the template that renders the page so each URL gets its own block with its own values. Do not paste one site-wide Product block into every page.
Three ways to deploy:
- Hand-written in templates. Most control, best for developers with a small set of page types.
- CMS plugin or theme setting. Fine for WordPress and similar systems, as long as you review what the plugin outputs rather than trusting defaults.
- Tag manager or script injection. Works, but test that the markup appears in the rendered page and not only in your container.
For a walkthrough aimed at business owners rather than developers, this implementation guide covers the same steps from the WordPress side.
5. Test before and after you publish
Google describes two testing routes: the Rich Results Test, to see which Google rich results a page can generate, and the Schema Markup Validator, to check any schema.org type for generic validity. They answer different questions, so run both. A block can be valid schema.org and still be ineligible for a Google feature because a required property is missing.

We built a schema markup validator for the quick pass: paste a URL or a block of JSON-LD and see what was found and what is wrong. If your results are confusing, our posts on running two structured data tests and fixing schema validation errors, syntax first explain how to read them.
6. Monitor after launch
The Search Console enhancement reports show errors that appear after deployment, such as a template change that dropped a required field. Check them after every release that touches templates.
Best practices that keep you out of trouble
Google's general structured data guidelines are the reference. In practice, five rules matter most.
Mark up what people can see. If a price, review or FAQ answer is not visible on the page, it does not belong in the markup. Google's guidelines treat markup that misrepresents the page as a violation that can lead to a manual action, which removes your eligibility for rich results.
Be specific. Use Restaurant instead of LocalBusiness, NewsArticle instead of Article when it is news. A specific type carries more meaning.
Do not mark up everything. More schema is not better. Describe the main content of the page accurately, fill in the required properties, then add recommended ones that you can keep correct.
Follow the feature's own policy. Merchant listings, job postings and events each carry their own requirements on top of the general rules.
Keep it current. Prices change, items sell out, events pass. Where inventory moves fast, generate the markup from the same data source that renders the page, so the two cannot drift apart.

Product pages: snippets versus merchant listings
Google separates product snippets, for pages such as reviews where you cannot buy directly, from merchant listings, for pages where you can. Merchant listing markup asks for more detail, including availability, shipping and return policy. If your product page has a Buy button, you want the merchant listing version.
Common errors and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| "Unparsable structured data" | Broken JSON: trailing comma, smart quotes, unescaped characters | Run the block through a JSON formatter, then retest |
| Missing field warnings | Required property absent for the chosen feature | Add the property from the feature documentation |
| Valid markup, no rich result | Eligibility is not a guarantee; page quality or policy issue | Recheck guidelines, content quality and indexing |
| Markup missing from rendered page | Script injected late or blocked | Inspect the rendered HTML, not only the source |
| Page not indexed at all | A stray noindex | Check for unexpected noindex |
For a deeper look at structured data wins beyond the basics, this overview of rich result types is a useful companion read.
Our perspective
We run a set of developer tools, including a schema checker, an HTML validator and a meta tag checker, so we see how often schema trouble starts somewhere that is not schema. A page returns a 500 to the crawler. A noindex slips in with a deploy. The JSON has a trailing comma. The markup says one price and the page says another. The schema vocabulary is rarely the problem.
So our advice is to work from the outside in. Confirm the page loads and is indexable. Confirm the HTML is sound with an HTML validator. Confirm the JSON parses. Only then argue about whether Article or BlogPosting is the better type.
We also think teams over-invest in chasing rich result types. Write markup that truthfully describes each page and keep it in sync with the content. If a feature you were targeting is later restricted, as FAQ results were, you lose a cosmetic benefit and keep a well-described site.
Last, put the check in the pipeline. A validator you run once at launch will not catch the template change three months later. That is why we also offer schema validation for AI agents, so a coding assistant can validate JSON-LD as part of a change.
— Andreas
Check your markup with Pingfloat
Pingfloat is a free suite of web tools for developers and IT professionals. For schema work, start with the schema markup validator, then use the JSON formatter and HTML validator for the layers underneath. Core tools need no installation or account, and you can see everything else on the Pingfloat home page. If you want to script checks, there is also a public API.
FAQ
How do you do schema markup?
Choose the schema.org type that matches the page, write its required and recommended properties as JSON-LD, and place the block in the page template. Then test it with a rich results tester and a generic schema validator. Make sure every value in the markup matches what visitors see on the page.
Is schema still relevant?
Yes. It does not change how a page ranks in ordinary web results, but it is how pages become eligible for rich results, and Google's documentation says it uses structured data to understand content. Some features, such as FAQ rich results, have been restricted, so check the current supported features before building around one.
What are the best practices for schema markup?
Use JSON-LD, pick the most specific type, include all required properties and mark up only visible content. Follow the specific policy for each feature, and keep the markup updated as your content changes. Avoid marking up every entity on a page.
Can you give me an example of schema markup?
The Article and Product blocks earlier in this guide are working examples. Copy one, change the values to match your page, and run it through a validator before you publish it.
Sources
- Introduction to structured data markup in Google Search
- General Structured Data Guidelines
- Structured data markup that Google Search supports
- Changes to HowTo and FAQ rich results
- Product structured data
- Merchant listing structured data
- Testing your structured data
- Schema.org
