Schema Markup Examples: What Great Schema Markup Looks Like
Great schema markup shares a specific set of traits regardless of page type: every property is accurate to what’s visibly on the page, entities reference each other instead of duplicating data, and the markup captures enough detail to actually earn a rich result rather than the bare legal minimum. The examples below walk through five common page types and show what separates markup that merely validates from markup that performs.
- Example 1: A Local Service Business Page
- Example 2: A Genuine Review Rich Result
- Example 3: FAQ Markup That Earns the Accordion
- Example 4: Course Markup With Real Structure
- Example 5: Author and Organization Markup That Builds E-E-A-T
- What Separates the Weak Examples From the Strong Ones
- How to Audit Your Own Examples Against This Standard
These are illustrative patterns drawn from the kind of work we do at Salterra, not copy-paste templates — the specific property values will always depend on your real content. But the structure and the reasoning behind each choice transfers directly to your own implementation.
Example 1: A Local Service Business Page
A weak version of this markup lists LocalBusiness with just a name, address, and phone number. It validates. It also leaves enormous value on the table, because it stops at the bare required fields instead of the properties that actually influence how the listing appears and how confidently AI systems can describe the business.
A strong version uses the more specific subtype — ProfessionalService, Plumber, Dentist, whatever accurately matches the business — rather than the generic LocalBusiness type. It adds geo coordinates, structured openingHoursSpecification (not a plain text string), a priceRange, an areaServed array naming the specific cities or regions covered, and a genuine aggregateRating pulled from real, verifiable reviews with the review count included. It also nests a sameAs array linking to verified profiles — Google Business Profile, Facebook, industry directories — which strengthens the entity’s credibility signal across the web, not just on this one page.
The difference in outcome: the weak version might validate cleanly and never earn a rich result because Google has nothing distinctive to display. The strong version is eligible for star ratings in the SERP and gives AI Overviews enough structured detail to accurately summarize the service area, hours, and reputation without guessing from unstructured page copy.
Example 2: A Genuine Review Rich Result
The most common mistake we see with Review and AggregateRating markup is not a technical error — it’s an accuracy problem. Sites add star ratings to product or service pages that have no visible reviews on the page itself, which violates Google’s structured data guidelines and risks the rich result being suppressed entirely, or worse, a manual action for misleading markup.
A great example does the opposite: the visible page shows genuine customer reviews — name, date, review text, and star rating — and the schema simply describes what a visitor can already see and verify. The AggregateRating block includes an accurate ratingValue, reviewCount, and bestRating/worstRating scale, and each individual Review nested underneath references the author as a real name, not “Anonymous” or a placeholder.
- Do: only mark up reviews that are visibly present and attributable on the page.
- Do: keep the aggregate rating current — update it as new reviews come in rather than letting it go stale for months.
- Don’t: pull an aggregate score from a third-party platform (like Google Business Profile) and apply it to your own site’s schema unless that exact data is also displayed on the page.
Example 3: FAQ Markup That Earns the Accordion
A passable FAQPage implementation has a mainEntity array of questions and answers that technically validates. A great one is built from questions that visitors would genuinely ask — often sourced directly from real customer emails, sales call transcripts, or “People Also Ask” data — with answers that are complete and self-contained, not a one-line teaser that pushes the reader to click through for the real answer.
The strongest FAQ examples we build keep the visible on-page Q&A content and the schema in lockstep — the schema’s acceptedAnswer text matches, word for word or very close to it, what’s actually rendered on the page. Google’s guidelines are explicit that FAQ schema must reflect visible content, and mismatches are one of the fastest ways to lose eligibility for the rich result even when the JSON itself is syntactically flawless.
A Pitfall Worth Naming
Applying FAQPage markup to every blog post sitewide, regardless of whether the post actually contains a genuine Q&A section, is a pattern Google has cracked down on. It used to be a cheap way to gain SERP real estate; now overuse without genuine Q&A content is treated as a spam signal. Reserve FAQ schema for pages that earn it with real, substantive question-and-answer content.
Example 4: Course Markup With Real Structure
A thin Course implementation includes just a name and description — technically valid, practically invisible in terms of differentiation. A strong example nests a hasCourseInstance array describing the actual delivery format (self-paced, instructor-led, in-person cohort), courseMode, and where applicable, real offers with accurate pricing and currency.
It also references the provider as the same Organization entity used sitewide, via @id, rather than duplicating a fresh Organization block on every course page — a pattern that keeps the entity graph coherent across dozens of course listings instead of creating dozens of slightly different, unlinked “organizations” in Google’s eyes. Where the course has a defined length, timeRequired uses proper ISO 8601 duration format rather than a plain-text guess, which is the single most common formatting error we catch in course schema audits.
Example 5: Author and Organization Markup That Builds E-E-A-T
This is the example category we care about most at SEO University, because it directly supports the credibility signals Google’s quality raters are trained to look for. A weak implementation lists author: “Admin” or omits the author property entirely on expertise-driven content. A strong implementation gives every substantive article a genuine Person entity: full name, a url pointing to a real bio page, a jobTitle or credential where relevant, and a sameAs array linking to verifiable profiles like LinkedIn.
That Person entity should also connect back to the site’s Organization block, ideally via worksFor or a similar relational property, so the entity graph shows a named, credentialed human tied to a named, verifiable business — exactly the kind of structured signal that helps both traditional quality evaluation and AI-mediated citation decide whether your content is trustworthy enough to surface.
What Separates the Weak Examples From the Strong Ones
Across all five categories, the pattern repeats. Weak schema hits the bare minimum required properties and stops. Strong schema adds the recommended properties that unlock richer display, keeps every value accurate to visible page content, and connects entities to each other instead of treating each page as an island.
- Weak: generic types (LocalBusiness instead of a specific subtype) chosen for convenience rather than accuracy.
- Strong: the most specific applicable Schema.org type, chosen deliberately.
- Weak: duplicated Organization or Person blocks with slightly different data on every page.
- Strong: a single canonical entity referenced by @id everywhere it applies.
- Weak: schema describing something not actually visible or verifiable on the page.
- Strong: schema that is a faithful, checkable mirror of the visible content.
How to Audit Your Own Examples Against This Standard
Pull up your top five pages by organic traffic and run each through the Rich Results Test. For each one, ask three questions: does the schema use the most specific type available, does every property value match something a visitor can actually see and verify on the page, and does any entity in this block also appear elsewhere on the site — if so, is it referenced consistently rather than duplicated with drift?
Most sites pass the technical validation check and fail the specificity and consistency checks. That gap — valid but generic — is exactly where the difference between passable and great schema markup lives, and it’s the gap worth closing first before adding schema to new page types.
Frequently Asked Questions
What makes schema markup "great" instead of just technically valid?
Great schema uses the most specific applicable type, includes recommended (not just required) properties, keeps every value accurate to visible page content, and references shared entities like Organization or Person consistently across the site rather than duplicating them with slight variations.
Is it okay to add star ratings to a page that has no visible reviews?
No — Google's guidelines require that Review and AggregateRating markup reflect content that is actually visible and verifiable on the page; adding ratings without visible supporting reviews risks the rich result being suppressed or, in more serious cases, a manual action for misleading structured data.
Should every blog post have FAQPage schema?
No — reserve FAQPage markup for pages with genuine, substantive question-and-answer content that's actually visible on the page; applying it sitewide regardless of content, purely to chase SERP real estate, is a pattern Google has specifically cracked down on.
Why does referencing entities by @id matter instead of just repeating the same block?
Referencing a canonical Organization or Person entity by @id across pages keeps the entity consistent and builds a coherent knowledge graph that search engines and AI systems can resolve confidently; repeating slightly different versions of the same entity on different pages fragments that signal instead of reinforcing it.
What is the most common formatting mistake in Course schema?
Entering timeRequired as a plain-text guess like "4 hours" instead of the required ISO 8601 duration format (PT4H); it's a small syntax detail, but it's flagged as an invalid value by the Rich Results Test and is one of the most frequent errors caught in course schema audits.
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.