A schema markup checklist gives you a systematic way to implement structured data correctly — ensuring every property matches visible content, every required field is present, and your markup actually earns rich results rather than triggering manual actions. Schema markup is JSON-LD (or microdata) added to your page so search engines and AI systems can parse meaning, not just text. Done right, it unlocks rich snippets, feeds knowledge graph entities, and signals credibility to AI Overviews, Perplexity, and ChatGPT — all of which pull structured signals when assembling answers.
- Use JSON-LD Over Microdata (and Here's Why)
- Match Every Property to Visible Page Content
- Know Required vs. Recommended Properties for Each Type
- Use @id for Entity Linking and Knowledge Graph Signals
- Nest Related Types Correctly
- Validate Before Every Deploy
- Avoid Spammy and Misleading Markup
- Checklist Summary: Before You Deploy Schema
At Salterra, we run every client page through a structured checklist before pushing schema live. The difference between markup that earns rich results and markup that gets ignored — or penalized — almost always comes down to discipline on a handful of fundamentals. This guide walks through the non-negotiables.
Use JSON-LD Over Microdata (and Here's Why)
Google, Bing, and every major AI crawler prefer JSON-LD for structured data. JSON-LD lives in a <script type=”application/ld+json”> block — usually in the <head> or just before </body> — which means it’s completely decoupled from your HTML structure. You can add, edit, or remove it without touching your layout or design. Microdata requires annotating each individual HTML element with itemscope, itemtype, and itemprop attributes, which creates tight coupling and makes templates brittle.
Microdata is still technically supported, but it’s a maintenance liability. JSON-LD can be injected server-side, via a CMS plugin, or via Google Tag Manager — which makes it far easier to version-control and test. On client projects at Salterra, we always ship JSON-LD as a standalone block. Mixing formats on a single page is allowed by the spec but creates debugging confusion; standardize on JSON-LD site-wide.
Match Every Property to Visible Page Content
This is the single rule that causes the most manual actions: your structured data must reflect what a user actually sees on the page. If your Product schema shows a price of $49, that price must be visible on the page. If your Review schema claims a ratingValue of 4.8, that rating must appear in the rendered page content. Google’s Structured Data guidelines explicitly prohibit marking up content “not visible to users.”
The practical checklist item: after implementing schema, view the live page (not just source), then cross-reference every property value in your JSON-LD against what you can actually read on screen. A quick audit with the Rich Results Test will also flag mismatches. For e-commerce pages, pay particular attention to price, availability, and priceValidUntil — these go stale fastest and cause the most rich-result drops.
Know Required vs. Recommended Properties for Each Type
Schema.org defines dozens of types, but Google’s Rich Results documentation specifies a narrower subset of required and recommended properties per type. Required properties are the minimum to qualify for a rich result. Recommended properties expand eligibility and improve the richness of the result. Skipping required properties means your markup silently fails — it won’t error, it just won’t surface.
- Article: Required — headline, image, datePublished. Recommended — author, dateModified, publisher.
- Product: Required — name. Recommended — image, description, sku, brand, offers (with price, priceCurrency, availability).
- FAQPage: Required — mainEntity array of Question objects, each with name (the question) and acceptedAnswer containing text.
- LocalBusiness: Required — name. Recommended — address, telephone, url, openingHoursSpecification.
- BreadcrumbList: Required — itemListElement array with position, name, and item (URL) for each crumb.
Always validate against Google’s Rich Results Test, not just schema.org — the two specifications diverge on what’s required for a rich result to actually fire.
Use @id for Entity Linking and Knowledge Graph Signals
The @id property is how you tell search engines “this thing described in my schema is the same entity as that thing.” Without @id, every page describing your organization creates a new, anonymous entity in the crawler’s mental model. With consistent @id URIs, you build a persistent entity across your entire site — which is a meaningful knowledge graph signal.
The convention is to use a stable, canonical URL as the @id. For your organization, something like “@id”: “https://yourdomain.com/#organization” is common. For a person (author), “@id”: “https://yourdomain.com/#terry-samuels”. Use that exact string consistently on every page that references that entity. When you link your Article‘s author to an @id that matches your Person block, crawlers can merge those signals and build a more confident entity representation — which matters increasingly in the AI search era where entity confidence drives answer attribution.
Sitewide Organization Block
Every site should have a sitewide Organization (or LocalBusiness) block on the homepage — at minimum — with a stable @id, name, url, logo, and sameAs pointing to verified social profiles. This anchors your entity. All other pages that reference your organization should point back to that same @id rather than repeating the full organization object inline.
Nest Related Types Correctly
Schema.org allows nesting — an Article can contain an author who is a Person, who has a jobTitle, url, and sameAs. Nesting is what makes schema expressive. But incorrect nesting is a common source of validation errors that are hard to spot without a tool.
The most common nesting mistakes: putting an Offer object directly at the top level when it should be inside a Product‘s offers property; listing multiple schemas as an array at the top level (valid) but accidentally nesting a second type inside the first (usually wrong); and placing a BreadcrumbList inside an Article instead of as a sibling top-level type. The rule: if two types are independent (Article and BreadcrumbList), put them as separate objects inside a top-level JSON-LD array. If one type is a property of another (Offer is a property of Product), nest it correctly under the parent.
Validate Before Every Deploy
Schema validation should be part of your deployment checklist, not an afterthought. Three tools cover the full surface:
- Google Rich Results Test (search.google.com/test/rich-results) — shows which rich result types your page qualifies for and lists required/recommended property warnings.
- Schema Markup Validator (validator.schema.org) — validates against the full schema.org spec, not just Google’s subset. Use this to catch type errors and unknown properties.
- Google Search Console → Enhancements reports — shows validation errors at scale across your crawled pages, categorized by schema type. This is the ongoing monitoring layer after deployment.
Validate on every meaningful content change, not just at initial launch. A product price update that doesn’t match the schema, or an author change that breaks the @id reference, can silently drop rich results without any visible error on the page.
Avoid Spammy and Misleading Markup
Google explicitly prohibits several practices that trigger manual spam actions. Understanding what counts as manipulative markup protects you from penalties that are difficult to reverse.
- Fake reviews: Do not add AggregateRating markup to pages where no genuine reviews exist, or inflate ratingValue beyond what actual user reviews support.
- Irrelevant rich result types: Marking up a generic informational article as an Event or a non-recipe page as a Recipe to chase a richer result is against policy.
- Keyword stuffing in schema fields: The description or name fields in your JSON-LD must match the actual content intent — not be padded with keyword variations that don’t appear in the visible content.
- Hidden content: Marking up content in structured data that is deliberately hidden from users via CSS or JavaScript tricks violates the visible-content rule.
The guiding principle: structured data should describe what’s on the page, not market what you wish the page were. When in doubt, if you’d be uncomfortable showing that markup to a Google quality rater who’s also looking at your rendered page, don’t publish it.
Checklist Summary: Before You Deploy Schema
Run through this before pushing any structured data live:
- Format: Using JSON-LD (not microdata) as a standalone script block.
- Visibility match: Every property value appears verbatim or functionally in visible page content.
- Required properties: All required fields per Google’s Rich Results spec are present for each type used.
- @id consistency: Organization, Person, and other recurring entities use stable, site-consistent @id URIs.
- Nesting: Independent types are sibling objects in an array; nested types are correctly placed under parent properties.
- Validation: Passed Rich Results Test with no errors (warnings for recommended properties are acceptable).
- No manipulative patterns: No fake reviews, no irrelevant type assignments, no keyword-stuffed fields.
- Search Console monitoring: Enhancement reports are checked after the next crawl cycle.
This checklist is exactly what the SEO University team uses on production client deployments. Structured data done correctly is a compounding asset — it feeds rich results today and entity confidence in AI search tomorrow.
Frequently Asked Questions
Is JSON-LD better than microdata for schema markup?
Yes — JSON-LD is Google's preferred format because it lives in a standalone script block, decoupled from your HTML, making it easier to add, edit, and validate without touching page layout; microdata requires annotating individual HTML elements and is far harder to maintain at scale.
What happens if my schema markup doesn't match the visible page content?
Google treats mismatches as policy violations — your rich results may be demoted or removed, and repeated violations can result in a manual action against your structured data, which requires a reconsideration request to lift.
Do I need schema on every page of my site?
No — prioritize pages where structured data unlocks a specific rich result (product pages, articles, FAQs, local business listings, events); purely informational pages with no applicable type get little incremental benefit and don't require forced markup.
What is @id used for in schema markup?
The @id property assigns a stable, canonical URI to an entity so crawlers can recognize it as the same thing across multiple pages — linking your author, organization, or product entity into a consistent knowledge graph node rather than treating each page mention as a separate unknown entity.
How do I know if my schema is working?
Use Google's Rich Results Test immediately after deployment to confirm eligibility and spot errors, then monitor the Enhancements section in Google Search Console over the following weeks — it shows validation errors and impression data for each schema type across your crawled URLs.
Can too much schema markup hurt my site?
Spam patterns can — specifically fake reviews, irrelevant type assignments, or schema properties that don't match visible content; simply having many correctly implemented schema types on a page is not penalized, so focus on accuracy and relevance rather than limiting quantity.
Terry has 30+ years in software and SEO. He’s the founder of Salterra Digital Services and SEO Spring Training, host of the Roundtable SEO Mastermind, and lead instructor at SEO University — teaching the exact tactics his team uses on client work.
Continue learning
Ready to master this?
This guide is one lesson from the Advanced Schema course. Get every lesson, framework and checklist — plus the full 38-course catalog — inside SEO University.
Practitioner-focused training across the full digital marketing stack — from technical SEO to conversion optimization and the AI search era. By Salterra Digital Services, since 2011.