Schema markup explained

Schema markup mattered enough in the 2010s that an enormous amount of effort went into it; in 2025 it still matters but the calculus is more nuanced. Google has reduced the visibility of some rich-result types over time, particularly the ones most prone to manipulation, and AI-generated answers in search results increasingly synthesize information directly rather than surfacing structured-data driven rich results. None of this means schema is dead, it remains the cleanest way to tell search engines explicitly what each entity on the page is, but it does mean the investment should be proportional to the realistic upside. We deploy schema where the rich-result types are still well-supported and the entity disambiguation matters, and we do not over-invest in schema for entity types where the visible payoff is no longer there.

Schema doesn't directly improve rankings. What it does is help search engines understand entities and relationships on your page, which in turn unlocks rich result eligibility, the more visually rich treatments you see in search results: product cards with price and rating, recipe cards, FAQ accordions, breadcrumb trails, video thumbnails, event listings, organization knowledge panels, and so on.

Rich results don't always appear, even when you're eligible. Google decides per query whether to surface the rich treatment. But you can't appear in a rich result without being eligible, and eligibility almost always requires schema markup.

• Organization / LocalBusiness, for the site as a whole. Confirms your brand identity to search engines and supports knowledge panels.
• WebSite + SearchAction, for the homepage. Eligible for the sitelinks search box.
• BreadcrumbList, to surface clean breadcrumb trails in search results.
• Article / NewsArticle / BlogPosting, for original content.
• Product / Offer / AggregateRating, for product pages with reviews and pricing.
• FAQPage, only when the page genuinely is a FAQ. Misuse is one of the most common reasons Google removes rich result eligibility.
• Recipe, Event, Course, Video, Person, JobPosting, domain specific types worth implementing where relevant.

1. Pick the right type. Use the most specific type that accurately describes your content. Don't use Product schema on a non product page; don't use FAQPage if there isn't a real FAQ.
2. Write JSON-LD. Add a <script type="application/ld+json"> block in the page head with the structured data. JSON-LD is preferred over Microdata or RDFa because it doesn't tangle with markup.
3. Validate. Use Google's Rich Results Test and the schema.org validator. Both will flag missing required properties and structural issues.
4. Keep it accurate. The data in your schema must match what's visible on the page. Hidden or misleading schema can result in manual actions.
5. Monitor. Search Console reports rich result eligibility per type. Track impressions and clicks for the rich treatments you've enabled.

• FAQ schema on non-FAQ pages. Google has tightened FAQ eligibility significantly; misuse is penalized.
• Marking up content not visible to users. Violates Google's structured data guidelines.
• Stale or inconsistent data. Reviews schema with old aggregate ratings, products with outdated prices.
• Wrong type. Using BlogPosting for product pages, Product for category pages, etc.
• Adding schema and ignoring validation errors. Errors mean the markup probably isn't being used at all.

For most sites, basic schema (Organization, Website, BreadcrumbList) is high value, low effort, and worth doing. Domain-specific schema (Product, Article, Recipe, Event) is worth doing when your business actually has those entities. Aggressive schema implementation on every possible type isn't worth it, you're spending engineering hours for diminishing returns and increasing the surface area for errors.