What it is: Your JSON-LD says one thing; the page shows another. The classic example is price: "price": "29.99" in your schema while the page displays £49.99 after a recent price change. Or "ratingValue": "4.8" in schema while reviews on the page average to 3.9.

Why it’s fatal: Google explicitly defines this as a potential basis for a Spammy Structured Markup manual action. A human reviewer from Google’s Webspam Team can flag the discrepancy — and when they do, the structured data on the entire page is ignored. The page can still rank, but it loses all rich result eligibility until you file and receive a successful reconsideration request.

How to detect it

This is not caught by the Rich Results Test. You need a human audit or a crawl-based comparison. Use Screaming Frog’s Custom Extraction to pull key schema fields (price, ratingValue, datePublished) and compare them column by column against rendered page content. Any mismatch is a liability.

The fix

Make schema the final step in your content publishing workflow, not the first. If a price, rating, or date is dynamic, your schema must pull from the same data source — not be hardcoded in a template. This is a systems problem, not a copy-paste problem.

What it is: Schema drift happens when your content is updated — new prices, removed FAQs, expired event dates, changed authors — but the schema markup isn’t touched. The page looks fine to users. The schema silently becomes wrong.

Why it’s so common: Writers and editors rarely think about schema. Developers set it up once and move on. Six months later, a product page has three FAQs in schema that were deleted from the page in a redesign. An event schema still lists dates from last year. An article schema says it was authored by someone who left the company.

How to prevent it

Build schema into your content update checklist. Every time key content changes — prices, dates, reviews, authors, FAQs — schema must be reviewed as part of the same task. The most reliable way to enforce this is to have schema pull dynamically from the same data source as the page content, rather than being a separate static block.

Monitor the Enhancements tab in Google Search Console. It reports errors and warnings on structured data. A sudden spike in warnings on a specific content type often traces to a content update that forgot schema.

What it is: Adding fake reviews, non-existent FAQs, inflated star ratings, or schema for events or products that don’t exist or aren’t accurately described. A subset of this is adding FAQ schema with questions and answers that aren’t actually on the page — sometimes inserted purely to get the FAQ drop-down rich result.

Why it’s tempting: FAQ rich results can dramatically increase SERP real estate and CTR. The temptation to add FAQ schema with optimized Q&A even when the page body doesn’t include them is real — and some guides have even recommended it.

The rule is absolute: Every piece of data in your schema must be visible on the page. If it’s not visible to a user reading the page, it cannot be in schema. Not as an optimization tactic. Not “sort of” visible. Actually on the page.

What it is: Extracting schema markup from a competitor’s page and implementing it wholesale on your own. This sounds efficient. It’s often a mistake that compounds at scale — especially if the competitor’s schema itself has problems you haven’t spotted.

The hidden problem: Schema.org types have context. A competitor might use Product schema on a category page because their CMS auto-generates it — and it works marginally, or triggers a Search Console warning they’ve learned to ignore. You copy it across 200 pages without understanding that Product schema belongs on individual product pages, not listing pages.

What to do instead

Use competitor schema for inspiration and to understand what types are being used. Then rebuild from the schema.org documentation for your specific page type. Validate context, not just syntax.

What it is: Applying a schema type that doesn’t match what the page actually is. Product schema on a service page. Review schema on a category page. Event schema on an evergreen informational page. Article schema on a page that’s clearly a lead generation form.

Why it fails beyond validation: The Rich Results Test may accept any syntactically valid markup. But Google’s quality layer evaluates intent: does this markup serve users by accurately describing the page, or does it exist to game a rich result? Mismatch consistently fails the second question.

The rule of thumb: Use the most specific subtype that accurately describes the page. Google recommends, for example, using OnlineStore rather than OnlineBusiness for ecommerce sites, and LocalBusiness subtypes (like Restaurant or MedicalBusiness) rather than the generic parent.

What it is: Implementing schema that passes syntax validation but omits required properties for the specific rich result you’re targeting. The markup is technically valid JSON-LD. It just doesn’t qualify for the enhanced appearance you want.

The most painful case in the real world: A team implements schema across 80 pages. No errors appear in Search Console. No one checks the Enhancement report for warnings. Months later, zero rich results have appeared — because a single required field was missing on every page. All that work, nothing to show for it.

Frequently missed required fields

• Product: name is required; offers with price and priceCurrency are required for price snippets
• Review: itemReviewed and reviewRating are both required
• Event: name, startDate, and location are required
• Recipe: name and image are required; missing image disqualifies from most rich results
• HowTo: name and at least one step are required

What it is: In 2025, Google retired seven structured data features including Book Actions, Course Info (with estimated salary), Claim Review (from SERP appearance), and others. Sites that had spent time implementing these schema types now have markup that Google simply ignores — it no longer powers any visual rich result.

The fix

Audit your existing schema implementation against Google’s current Structured Data Search Gallery. If a type you’re using isn’t listed, it’s either not eligible for rich results or has been deprecated. You don’t need to rush to remove deprecated code — Google ignores it — but removing it is good housekeeping and prevents future confusion.

What it is: Optimizing schema exclusively for Google rich results while ignoring how structured data influences AI systems like Google’s AI Overviews, Bing Copilot, Perplexity, and ChatGPT’s search feature.

Why this is rapidly becoming a serious gap: AI Overviews now appear on roughly 30% of searches, according to Ofcom data from 2025. Pages with FAQPage schema appear in AI Overviews 3.2 times more often than pages without structured data. AI-referred sessions for schema-enhanced content grew substantially in the first half of 2025. This isn’t speculative — the search team confirmed it at Google’s April 2025 update.

Schema types that matter most for AI visibility

• FAQPage: Helps LLMs parse questions and surface concise answers — the format AI prefers
• HowTo: Numbered steps are easy for LLMs to assemble and quote
• Article with author Person schema: Signals E-E-A-T, which both Google and AI systems use as a credibility signal
• Organization with sameAs links: Connects your entity to Knowledge Graph nodes — critical for entity disambiguation in LLMs
• Product with detailed attributes: Used by AI for comparison synthesis

The strategy shift: schema should now be designed with two audiences in mind — Google’s rich result system and AI answer engines. These two audiences want the same thing: accurate, complete, machine-readable descriptions of what you do and say. The difference is that AI systems are less forgiving of ambiguity.