You can pass a schema validator and still have broken schema markup mistakes sitting on your service pages right now. Validators check syntax, not truth. They confirm that your JSON-LD parses correctly, not that it describes what's actually on the page, and that gap is where most of the damage happens. In my experience auditing service business sites, the schema markup mistakes that cost the most are never the ones that throw an error. They're the ones that validate cleanly while quietly telling Google something false, stale, or contradictory about the page.
What schema markup mistakes actually cost you
The direct cost of bad schema is usually a lost rich result: no star rating in the snippet, no FAQ dropdown, no breadcrumb trail in the SERP. That's real, and it matters for click-through rate. But the bigger cost is trust at the entity level. Structured data is one of the signals Google uses to build a model of what your business is, what it does, and where it operates. When your markup contradicts your visible content, you're not just losing a rich result. You're feeding a coherent, machine-readable business profile with contradictions that never get flagged by a human, because nobody manually reviews JSON-LD the way they review a homepage headline.
I've watched this play out on sites that looked otherwise well-optimized. The visible page was solid, the copy was clear, the site loaded fast. And buried in a script tag was a schema block describing a different service, a different city, or a rating that hadn't been touched in two years. None of it threw a validation error. All of it was quietly working against the page.
Markup that describes a page nobody can see
The most common version of this: schema data that doesn't match the visible content on the page. Google's structured data guidelines are explicit that markup should describe content a visitor can actually see and verify. A Service schema block listing five services when the page only describes three, or a price range in the markup that doesn't appear anywhere in the visible copy, creates a mismatch between what the page says and what the code says.
This happens most often after a redesign. The visible page gets rewritten, trimmed, restructured. The schema block, sitting in a template file or a plugin setting nobody remembers configuring, doesn't get touched. Six months later the page describes one thing to a visitor and a different, older version of the business to a crawler. I've seen this specifically with service lists and staff bios: the team page gets updated, the Person schema still lists someone who left the company a year earlier.
Work With John
Your site should be your best salesperson. If it is not, that is a fixable problem.
I work with US service businesses and B2B brands to build SEO systems that produce consistent, compounding leads. I will tell you exactly what is broken. No pitch.
Book a free strategy callCopy-pasted schema from a template that never got customized
The second pattern shows up on sites built from a theme or an SEO plugin with schema baked in. The plugin ships a LocalBusiness template with placeholder-adjacent values: a generic business type, an address that got copied from a competitor example in a tutorial, an aggregateRating block with a 4.8 out of 5 average sourced from nowhere. The site owner never wrote a single line of that schema, so nobody ever considers it something that needs auditing.
This is the schema markup mistake I flag most often on new client sites: an aggregateRating or review schema block with numbers that don't trace back to any actual review platform. Google's guidelines require that review markup reflect real reviews the business collected, not a placeholder or an estimate. A business running fabricated rating markup risks a manual action, and even short of that, the numbers are frequently wrong in ways that undersell a business's actual reputation, since the fabricated 4.8 sits lower than what the business's real Google Business Profile reviews show.
Stacking multiple business types without a primary type
A different failure mode: sites that apply @type as an array with five or six schema types stacked together, hoping one of them sticks. LocalBusiness, ProfessionalService, Service, Organization, and a custom type all layered onto the same JSON-LD block. Schema.org does support type inheritance, and some combinations are legitimate, but stacking unrelated types with no clear primary description does not give Google more information. It gives Google an ambiguous entity to parse, and ambiguous entities get deprioritized in favor of markup that makes a clear, single claim about what the business is.
I go into the mechanics of choosing the right type in a separate look at Service schema versus LocalBusiness schema, because that decision alone resolves most of the stacking problem. Pick the type that actually matches the business model, populate its required and recommended properties fully, and resist the urge to add more types "just in case."
Review and rating markup that violates Google's guidelines
Beyond fabricated numbers, review schema has a narrower set of legitimate uses than most site owners assume. Google will not display review rich results for a business's own self-serving review of its own service or product; the review markup needs to be a third party reviewing the business, sourced honestly, and ideally verifiable. Markup that aggregates testimonials pulled from a testimonials page, without a clear third-party review platform behind them, sits in a gray area that has gotten multiple sites' rich results suppressed over the past few years as Google has tightened enforcement.
The safer pattern, and the one I recommend, is pulling review schema directly from a verified source: an integration with your actual review platform, whether that's Google, a niche industry review site, or a widget that syncs real collected reviews rather than typed-in testimonial quotes. If you don't have a genuine, ongoing review collection process, the honest move is skipping review schema entirely rather than manufacturing the appearance of one. This ties into a broader credibility question I cover in what E-E-A-T actually measures: fabricated signals tend to surface eventually, and the fix costs more than never adding them.
A worked example: diagnosing a service page that stopped getting rich snippets
Say a service page had a star rating snippet in search results for over a year, and then it disappeared with no site changes that anyone remembers making. The diagnostic sequence I use: pull the page through Google's Rich Results Test first, not a generic schema validator, because it reports eligibility, not just syntax validity. If the test shows the schema is technically valid but the rich result isn't eligible, the next step is checking whether the aggregateRating count or value changed, since Google periodically re-evaluates whether markup still matches a plausible pattern of authentic reviews.
In a case like this, the actual cause is often upstream of the code: a review platform integration silently stopped syncing months earlier, so the schema kept serving a static, aging rating count that no longer matched the platform. Google's systems compare structured data against other signals about the business over time, and a rating that stops updating while a business's actual review count keeps growing elsewhere is exactly the kind of staleness that erodes eligibility. The fix wasn't touching the JSON-LD at all. It was fixing the integration feeding it, then letting the schema pick up accurate numbers again on its own.
How to actually validate schema so mistakes don't reach production
Google's Rich Results Test and the Schema Markup Validator serve different jobs, and using only one leaves gaps. The validator confirms your JSON-LD is syntactically correct schema.org vocabulary. The Rich Results Test confirms Google can actually render a rich result from it, which is the test that catches missing required properties and type mismatches the generic validator won't flag. Run both, on the live page, not a staging copy, since staging environments frequently carry different data than production.
Beyond the two testing tools, the actual discipline that prevents recurring mistakes is treating schema as content that needs the same review cycle as the page's visible copy. When a service page gets updated, the schema block tied to it should be part of that same review, not a separate task that falls to whoever manages the CMS templates. Most of the mistakes I've described here didn't happen because nobody knew the rules. They happened because schema lives in a part of the codebase that nobody revisits when the visible page changes, which is exactly the kind of gap I dig into more broadly in how the technical work nobody sees decides whether a page performs.
I also keep a simple running log for clients: page URL, schema type, date last verified, and the source of any numeric values like ratings or price ranges. It takes minutes to fill in and it turns "has anyone checked this lately" from a guess into an answer. When a redesign or a CMS migration is on the calendar, that log is the first thing I pull, because migrations are the single most reliable way schema gets orphaned. A developer moves the visible template to a new component structure, tests that the page renders correctly, ships it, and the JSON-LD generation logic, written by someone who left the project two versions ago, keeps outputting values tied to fields that no longer exist in the new data model. The page looks fine. The schema is quietly broken, and it stays that way until someone runs a Rich Results Test for an unrelated reason and notices the eligibility warning.
If schema on your site hasn't been audited since it was first added, it's worth treating as due, the same way you'd treat a sitemap or a robots.txt file you haven't looked at in a year. For a broader diagnostic pass across crawlability, indexing, and markup issues together, that's the kind of audit I run as part of SEO consulting engagements, and it's also worth reading alongside does schema markup actually help you rank, since knowing what schema can and can't do changes how much time is worth spending fixing it. More technical SEO breakdowns like this one live in the Technical SEO archive.
Schema markup mistakes rarely announce themselves. They sit in a script tag, pass a syntax check, and quietly misrepresent the business to the one audience that reads every line of it. Auditing schema the way you'd audit any other piece of content on your site, on a schedule, against what a visitor can actually verify, is the only reliable way to catch them before they cost you a rich result you didn't even notice was gone.
