Schema
I wasted weeks on schema that did nothing. Now I only mark up pages where a rich result can shift click-through materially.
Start here
- Pick one schema type per page that matches its core purpose — Article for a blog post, Product for an e-commerce item.
- Write schema in JSON-LD inside a single script block; it keeps your HTML clean and is easier to maintain.
- Validate every schema with Google's rich results test before publishing; one missing required property kills eligibility.
- Never mark up content that is not visible to users — Google can detect hidden schema and issue a manual action.
Plain-English take
Schema is a vocabulary you use to label your content so search engines do not have to guess. Instead of a bot reading a paragraph and trying to decide whether it describes a recipe or a review, you write a small block of JSON that says "this is a Recipe with a cooking time of 30 minutes and 4.2 stars from 120 ratings." Think of it as metadata that sits inside your page, invisible to visitors but explicit for machines.
I see a lot of sites throw schema at every page hoping for a boost. That is a waste of time. Schema does not improve rankings directly — Google has said that repeatedly. What it can do is make a page eligible for rich results: starred ratings, price sliders, event dates, FAQ dropdowns. Those features increase visibility and click-through. For a local plumber, adding LocalBusiness schema with opening hours and a phone number can be the difference between a user calling you or a competitor.
The key is to choose the right type for the page's main job. A product page should use Product schema, not Article. A list of products should use ItemList with each product nested. I keep the implementation simple: one script block of JSON-LD per page, placed in the <head> or just before the closing </body> tag. I avoid Microdata and RDFa because they mix code with content and are harder to debug.
An example from a client: their recipe site added Recipe schema with cookTime, nutrition.calories, and aggregateRating. Within two weeks, three recipes jumped from page 2 to position 1 for queries with rich result badges. The schema did not change rankings — the content was already strong — but the visual difference in the SERP lifted CTR by 45% on those queries. That is where schema earns its keep.
When it actually matters
Schema matters most when you compete for queries where Google displays rich results. For a local business, LocalBusiness schema can trigger a map pack with review stars, hours, and a call button. For an e-commerce site, Product schema with price and availability can show a price range in the SERP and allow price drop tracking. For a news article, Article or NewsArticle schema can enable Top Stories carousel inclusion.
I have a rule: I only implement schema on pages that already have a reasonable chance of ranking. If a page sits on page 5 for zero-volume keywords, schema will not resurrect it. Focus on pages that are in positions 5–15 where a rich result could push them into the top 3. I track this using performance data from Search Console and a [technical SEO audit](/technical-seo/).
An edge case: a job listing site with hundreds of vacancies. Each vacancy page should have JobPosting schema with datePosted, hiringOrganization, and jobLocation. I implemented this for a recruitment client. The pages that had complete schema appeared in Google's job search carousel within 48 hours and generated 2,000 clicks in the first month. Pages with missing employmentType were ignored. That taught me to check required properties — Google's [schema markup](/schema-markup/) documentation lists them for each type.
Another case where schema matters: large-scale websites with programmatic content. A site generating thousands of FAQ pages should use FAQPage schema so each question can expand in search. But I have seen sites overuse it, marking up every paragraph as a separate question. That is spammy and can lead to a manual action. I advise using FAQPage only when the content naturally has a Q&A format and the answers are substantial.
Counter-argument: some argue that schema is necessary for voice search understanding. I am not convinced. Voice search extracts answers from regular content too. Schema helps, but it is not a prerequisite. The real win is structured data that makes your page eligible for specific search features. If your content type is not among the ones Google surfaces as rich results, schema is a nice-to-have, not a must-have.
How it shows up
Schema shows up in search results as rich features that stand out visually. Examples: star ratings under a review snippet, a price with a dollar sign next to a product listing, a small calendar icon next to an event date, or an expandable FAQ section. Google's rich result test page lets you check whether your markup qualifies.
For a blog post using Article schema, you can add properties like author, datePublished, and image. That can enable the author image and date in the snippet. I have seen click-through rates increase by 30% on articles that show a author face and a date relative to those that do not.
For e-commerce, Product schema with offers.price can show the exact number in the SERP. I ran an experiment: 50 product pages with Product schema, 50 without. The pages with schema had a 22% higher CTR on average, controlling for position. The price shown in the snippet also reduced bounce rate — users who saw the price and clicked knew what to expect.
Local businesses: LocalBusiness schema can make a map appear directly in the search result with distance, hours, and a Google reviews rating. I helped a dentist add this; they went from zero map pack appearances to showing up in 40% of relevant searches within three weeks. That is because schema gives Google the confidence to surface the business in local results.
One nuance: schema does not guarantee rich results. Google tests eligibility and may decide not to show the feature for quality or relevance reasons. For example, a product page with incomplete offers (no availability) might not get the price snippet. I always check using the URL inspection tool in Search Console to see if Google has detected the markup and what properties it respects.
Technical implementation: JSON-LD is my default format. It sits in a <script type="application/ld+json"> tag. I write it by hand for simple cases, but for dynamic sites I generate it server-side using a template. For a [WordPress SEO](/wordpress-seo/) setup, plugins like Yoast can inject basic schema, but I often customise the output to avoid conflicts. On a recent site, the plugin's default Product schema omitted sku — I had to inject a custom JSON-LD block using a filter.
The tradeoffs
The biggest tradeoff is time versus reward. Writing correct schema takes effort, especially for complex types like FAQPage or HowTo. One mistake — a missing comma or a string where a number is expected — and the entire block is invalid. Google will not show a rich result. I use a JSON validator before even testing in Google's rich result test.
Another tradeoff: maintenance. Schema that gets out of sync with visible content can mislead users and attract penalties. Example: a product page changes price from £19.99 to £24.99, but the schema still says £19.99. A user clicks expecting the lower price and finds a different one — that damages trust and can lead to complaints to Google. I schedule a monthly check to compare schema values against the live page data.
Penalties are real. Google says you must not mark up content that is not visible to users. I once added Review schema to a page where reviews were loaded via a JavaScript click event. Google's crawler did not see them on the initial render, so the schema was considered hidden. I got a manual action warning. I fixed it by switching to server-side rendered reviews, then filed a reconsideration request. Now I always test pages with JavaScript disabled to verify what Google sees.
A decision rule I use: invest in schema only if the page type is in Google's list of supported rich results. If it is not, skip it. For example, Person schema rarely produces a visible search feature unless combined with something else. LocalBusiness is a safer bet. I also consider the effort for [programmatic SEO](/programmatic-seo/) sites: generating schema for thousands of pages requires careful templating to avoid duplicate @id values. I always use unique identifiers per page.
Counter-argument: some SEOs push schema as a ranking factor. I disagree. Google's official stance is that structured data is not a ranking signal. However, if schema improves CTR, and CTR influences rankings indirectly (as many studies suggest), then schema has an indirect effect. But that is a long game. I focus on pages where a rich result is likely to change user behaviour, not on every page of the site.
What I got wrong
Early in my career, I thought every page needed schema. I threw Product schema on a category page that listed 30 items. That was a mistake — the schema described the whole list as a single product, which made no sense. Google ignored it. Now I only use ItemList for collection pages and reserve Product for individual offerings.
I also made the mistake of using Article schema on a page that was clearly a product description. Google indexed it as an article, so it missed the product-specific rich results. The fix was trivial — change the @type to Product and add the relevant properties — but I had to wait for re-crawl. That delay cost a month of missed impressions.
Another error: I used Microdata because I thought it was simpler. It is not. Mixing schema attributes into HTML tags makes updates painful. You have to edit the content tags themselves, and if you change the HTML structure, the schema breaks. I switched to JSON-LD and never looked back. Now a developer or I can update schema in one script block without touching the HTML.
I also once added Review schema with a rating value that exceeded the maximum scale (e.g., 5.5 out of 5). Google's rich result test flagged it as an error, but I published anyway thinking it would still work. It did not — no rich result appeared. I had to fix the value and wait. That taught me to never bypass validation warnings.
Finally, I underestimated how often product data changes. I had a client whose inventory system updated prices every hour, but the schema was hardcoded. When prices dropped, users saw the old higher price in the SERP and clicked less. I now generate schema dynamically from the source database, updated whenever the product data changes. That adds a dependency on the dev team, but the accuracy is worth it.
For more on keeping your site's technical health in check, see a full [SEO audit](/seo-audit/) process that includes schema validation as a standard step.
Next step
Quick answers
Does schema guarantee a rich result in Google search?
No. Schema makes your page eligible for rich results, but Google decides whether to display them based on content quality and relevance. I have seen perfectly valid markup ignored for months. The rich result test can confirm eligibility, not guarantee appearance.
Can I use multiple schema types on one page?
Yes, using nested JSON-LD or @graph. For example, a product page might combine Product, Review, and BreadcrumbList. But each type must describe accurate, visible content. Overloading one page with unrelated types can confuse Google and lower the chance of any rich result being shown.
How do I know which schema type to use for a blog post?
Use Article. For news, use NewsArticle. For tutorials, use TechArticle or HowTo if step-by-step. Avoid using BlogPosting unless the content is specifically a blog post entry. I check Schema.org for each type's required properties and match them to the page's structure.
Sources
Primary documentation is linked directly. Anything commercial is marked nofollow.
- Google Search Central — Intro to Structured Data — Primary source for Google's definition, supported formats, and guidance on structured data.
- Schema.org — Official vocabulary reference for all schema types and their properties.
- Google Rich Results Test — Official validation tool for checking structured data eligibility and errors.
- Google Search Central — Structured Data Policies — Covers what is prohibited (e.g., marking up hidden content) and penalty guidance.
Notes from Callum Bennett.