Fourteen years of schema audits has given me a fairly short list of mistakes that account for most of the problems I find. They repeat across industries and CMS platforms because they come from the same handful of habits — copying an example without adapting it, adding markup once and never revisiting it, or letting more than one tool manage the same schema type without anyone noticing the overlap.

Duplicate Schema Blocks

This is the single most common issue I find on audits. A site has an SEO plugin generating Organization schema, a theme that also outputs Organization schema by default, and a developer who added a third block manually at some point and never removed it. All three validate individually. Together, they tell Google there are three different organizations, or contradictory data about the same one. Before adding any new schema, search your page source for every existing application/ld+json block and confirm you are not about to create a fourth version of something that already exists three times.

Markup That Contradicts Visible Content

Google’s guidelines are explicit that structured data must reflect what is actually on the page. The mismatch I see most often: a product page marked as in stock in the schema while the visible page shows a sold-out badge, because the schema was hardcoded at launch and nobody wired it to update alongside inventory. Same issue with review counts, prices, and event dates — any value that changes over time needs to pull from the same source the visible page pulls from, not a separate hardcoded copy. Mismatches like this are one of the more common reasons rich results get pulled even when the JSON-LD itself validates without a single error.

Missing Required Properties

Every schema type has a small set of properties Google treats as required for rich result eligibility, and a larger set marked recommended. Skipping a required property does not just produce a warning — it disqualifies the whole block from that rich result. The fix is mechanical: check the specific type’s requirements against your markup every time, rather than assuming a template that worked for one type will work identically for another. FAQPage and Product schema, in particular, have requirements that trip people up because they seem similar to other types but are not identical.

Wrong Data Types

JSON-LD is strict about types in a way plain text content never has to be. A price needs to be a number, not a string with a currency symbol attached. A date needs ISO 8601 format, not whatever date format your CMS displays to visitors. I see this constantly in hand-typed schema where someone wrote 'price': '$49.99' instead of 'price': '49.99' with currency handled by a separate priceCurrency field. The validators catch this reliably, which is exactly why validating your markup before publishing is not an optional step.

Schema That Never Gets Revisited

Markup that was accurate at launch drifts as the site changes. A staff directory schema still lists someone who left eighteen months ago. An Organization block still references a phone number the company stopped using after an office move. None of this throws an error in a validator, because the validator has no way to know the phone number is wrong — it only checks structure, not truth. The only real defense is a maintenance habit: revisit schema whenever the underlying content it describes changes, not just when someone remembers the schema exists.

Treating Schema as a Ranking Hack

I get asked, more than I would like, whether adding more schema types will directly boost rankings. It will not, and treating it that way leads to padding pages with schema for content types that are not actually present — marking up a FAQ section that does not visibly exist on the page, for instance, purely to try to win the rich result. Google has cracked down on exactly this pattern with manual actions against sites using hidden or fabricated FAQ and HowTo markup. Schema should describe what is genuinely on the page, not what you wish were there.

Injecting Schema Where It Cannot Be Reliably Read

Schema injected via client-side JavaScript that fires late, or that depends on a third-party tool loading successfully — Google Tag Manager is the common example — can end up invisible to crawlers or delayed well past when you would expect a rich result to appear. This is not automatically wrong, but it means testing needs to happen against the live, rendered page, not just the code you wrote, and you need a fallback plan for what happens if the injection method fails.

Skipping Validation Entirely

The most avoidable mistake on this list: publishing schema without running it through the Rich Results Test and Schema.org’s validator first. Both tools are free, take under a minute, and catch the majority of the specific errors above before they ever reach a live page. There is no good reason to skip this step, and it is the fastest way to catch nearly everything else on this page before it becomes a months-long problem nobody notices until a rich result quietly disappears.

Copy-Pasted Boilerplate Nobody Adapted

A large share of broken schema I find traces back to an example copied from a tutorial or a plugin’s default template and never edited for the actual site. The telltale sign is placeholder data still sitting in production — a phone number of 555-0100, an address of 123 Main Street, a business name that reads Your Company Name. These pass validation cleanly because validators check structure, not whether the values make sense, so this mistake can sit live on a site for years without triggering any warning. Whenever I inherit a new client site, checking every schema value against the actual visible content is one of the first things I do, specifically because this happens so often.

One Schema Type Standing in for Another

Choosing the closest-sounding type instead of the correct one is a subtler version of the same problem. I have seen local businesses marked up as the generic Organization type when LocalBusiness — or a more specific subtype like Restaurant or Dentist — would unlock properties like opening hours, price range, and geo-coordinates that the generic type does not support at all. Schema.org’s type hierarchy is deep on purpose. Spend the extra few minutes finding the most specific applicable type before defaulting to whichever one you already have example code for.