The most damaging schema markup mistakes aren’t syntax errors — they’re structural misunderstandings that produce markup Google and AI engines can’t trust or use. Schema tells machines what your content means, which entities it involves, and whether they can rely on it. Get it wrong and you don’t just miss rich results; you actively confuse the knowledge graph that AI Overviews, ChatGPT, and Perplexity use to build their world models.
- Mistake 1: Marking Up Content That Isn't Visible on the Page
- Mistake 2: Using the Wrong Schema Type for the Content
- Mistake 3: Leaving Required Properties Empty or Missing
- Mistake 4: Broken JSON-LD Syntax
- Mistake 5: Fake Reviews and Ratings Markup Against Google's Guidelines
- Mistake 6: Never Validating After Deployment or Site Changes
- Mistake 7: Orphaned Entities With No Supporting Context
At Salterra, we’ve audited dozens of sites where schema was present but broken in subtle ways — the Rich Results Test passed, but the markup was describing content that didn’t exist, using the wrong type for the context, or leaving required properties blank. These are fixable problems once you know what to look for.
Mistake 1: Marking Up Content That Isn't Visible on the Page
Google’s structured data guidelines are explicit on this point: your schema markup must describe content that a user can actually see on the page. If you’re adding FAQPage schema with questions and answers that don’t appear in the visible HTML, or including a review/ratingValue that exists only in the JSON-LD and nowhere in the body copy, that’s a violation — not just a best-practice miss.
This mistake shows up most often when developers copy-paste schema templates and fill in values in the script block without updating the on-page content to match. The schema says the article is authored by a named expert with a specific bio, but the page has no author byline. The schema describes an aggregate rating of 4.8 stars, but there are no reviews visible to the reader. Google calls this “misleading structured data” and has taken manual actions against sites that do it at scale.
The fix: Before deploying any schema, do a one-to-one audit — every field in your markup should correspond to something a human reader can see and verify on the page. If the content isn’t there, add it. If you can’t add it, don’t mark it up. The rule is simple: structured data describes visible content; it doesn’t replace it.
Mistake 2: Using the Wrong Schema Type for the Content
Schema.org has hundreds of types, and picking the wrong one is surprisingly common. A recipe page marked up as Article, an FAQ section using HowTo steps, a local business service page marked as a Product — these mismatches confuse search engines and AI systems that rely on type signals to categorize and surface content correctly.
The more subtle version of this mistake is using a parent type when a more specific child type exists and is better supported. Marking a news article as generic CreativeWork instead of NewsArticle, or marking a how-to guide as plain Article instead of HowTo, leaves rich result eligibility on the table. Google’s rich results are tied to specific supported types — if your type doesn’t map to a supported feature, you won’t get the enhancement regardless of how clean your markup is.
The fix: Start with Google’s rich results gallery and identify which supported types match your actual content. Then cross-reference schema.org to make sure you’re using the most specific applicable type. When in doubt, err toward specificity — LocalBusiness > AutoRepair is better than LocalBusiness alone.
Mistake 3: Leaving Required Properties Empty or Missing
Every schema type has recommended and, in Google’s implementation, effectively required properties. Article schema without author, datePublished, and headline is nearly useless. Product schema without name and at least one of offers, aggregateRating, or review won’t trigger any rich results. LocalBusiness without address and telephone fails basic knowledge panel eligibility.
The issue is that invalid or incomplete schema often passes basic syntax checks. A JSON-LD block can be structurally valid — no syntax errors, no malformed properties — while still being semantically useless because the critical properties are absent. Developers who generate schema with tools or templates and don’t fully populate the fields create this problem routinely.
We commonly see this on local business pages where the Person schema for an author has a name but no sameAs links to LinkedIn, an author bio page, or any entity-establishing references. That author is a floating label, not an entity Google can verify. In the E-E-A-T era, unverifiable authorship is nearly as bad as no authorship.
The fix: Pull Google’s documentation for each type you’re implementing and check every recommended property. For Article: fill in author with a full Person object including sameAs. For Product: always include offers with price and priceCurrency. For LocalBusiness: include address, telephone, openingHoursSpecification, and geo. Don’t guess — check the spec.
Mistake 4: Broken JSON-LD Syntax
JSON-LD is the preferred format for schema markup because it’s easy to implement without touching your HTML. It’s also easy to break silently. A trailing comma after the last property in an object, an unescaped quotation mark inside a string value, a missing closing brace — any of these produce invalid JSON that parsers reject entirely. The entire block is ignored, not just the broken property.
This is more common than it sounds on dynamic sites where schema is generated server-side or through plugins. A content management system that generates the headline property dynamically might produce valid JSON 99% of the time — but if a page title contains a double quote or an ampersand that isn’t properly escaped, the whole block breaks on that page. Plugin-generated schema also frequently introduces duplicate @type declarations or conflicting nested objects that create parsing errors without triggering any visible warning.
How to catch JSON-LD errors before they cost you
- Paste every schema block into JSONLint before deployment — pure syntax validation, no Google dependency.
- Run the Schema.org Validator for semantic completeness checks.
- Use Google Search Console’s Rich Results report post-deploy and set up email alerts for structured data errors.
- If schema is generated dynamically, add an automated test in your CI pipeline that validates the JSON output for critical page templates on every deploy.
The fix: Treat schema validation as a non-optional step in your publishing workflow, not an afterthought. A one-time template fix prevents a class of errors from ever reaching production again.
Mistake 5: Fake Reviews and Ratings Markup Against Google's Guidelines
This is the mistake that triggers manual actions, not just missed rich results. Google’s guidelines prohibit using AggregateRating or Review schema to mark up ratings that are self-serving, unverified, or fabricated — first-party ratings with no independent basis, testimonials repackaged as reviews, or numerical scores that a business assigned to itself without any real review mechanism.
The most common violation is adding aggregateRating to a product or local business page with a high star value when there is no actual review platform feeding those numbers. Sometimes site owners pull ratings from Google My Business or Yelp and hard-code them into schema — which is problematic both because those platforms own that data and because the numbers quickly go stale. Other sites pull testimonials from their own CRM, assign a five-star value, and call it an aggregate rating. None of these meet Google’s standards.
The fix: Only implement AggregateRating and Review schema when you have a genuine, independent review mechanism — a verified third-party platform, or an on-site review system that meets Google’s criteria. If you don’t have real reviews, don’t mark up ratings at all. The short-term SERP appeal of star ratings is not worth the risk of a manual penalty that can take months to recover from.
Mistake 6: Never Validating After Deployment or Site Changes
Schema breaks silently. A theme update, a plugin conflict, a CMS migration, or a change to your site’s header template can wipe out or corrupt your structured data without triggering any visible error on the page. We’ve seen clients who implemented solid schema a year earlier and assumed it was still working — until an audit revealed that a WordPress plugin update had rewritten the <head> template and dropped the JSON-LD blocks entirely.
Google Search Console’s Rich Results report shows errors and warnings, but it operates on crawl schedules — you may not see a new error for days or weeks after a breaking change. If you’re only checking schema at implementation time, you have a significant blind spot in your technical SEO monitoring.
This matters more now that AI search relies so heavily on structured data signals. Google AI Overviews, Bing’s AI answers, and systems like Perplexity use schema to disambiguate entity types, verify author credentials, and confirm business information. If your markup silently broke three months ago, your AI visibility has been degrading since then without any obvious signal in your analytics.
The fix: Add schema validation to your ongoing monitoring stack, not just your launch checklist. Run the Rich Results Test on your highest-value page templates monthly. Set up a Google Search Console integration that alerts you to structured data error spikes. If you’re running a site at any meaningful scale, automate schema spot-checks with tools like Screaming Frog or a custom Python script against the Schema.org Validator API.
Mistake 7: Orphaned Entities With No Supporting Context
Entity markup without supporting entity context is schema that the knowledge graph can’t anchor. You can mark up an author as a Person with a name, but if there are no sameAs links to authoritative profiles — LinkedIn, a Wikipedia page, a Google Knowledge Panel URL, a Wikidata entry — Google has no way to disambiguate that person from every other individual with the same name. The entity is orphaned: present in the markup, invisible in the knowledge graph.
The same applies to organizations. A LocalBusiness schema with a name and address but no sameAs reference to the Google Business Profile, no url pointing to a verified domain, and no identifier properties is harder for AI systems to connect to their existing knowledge of that entity. You’re giving the machine a label without giving it the thread to tie that label to what it already knows.
This is a particularly important mistake to fix in the AI Overviews era. When Google or Perplexity decides whether to cite your content in an AI-generated answer, entity confidence plays a real role. A clearly identified, verified author entity — someone whose expertise can be confirmed through off-site signals — carries meaningfully more weight than a floating name in a markup block.
Building entity context that sticks
- For authors: include sameAs arrays with links to LinkedIn, Twitter/X, a personal site, and any Wikipedia or Wikidata entries.
- For organizations: link to Google Business Profile, Crunchbase, Bloomberg, or industry directories in the sameAs property.
- Create a dedicated author bio page for each bylined contributor — this gives the entity a canonical home on your domain that schema can reference.
- Use knowsAbout and hasCredential on Person entities to give AI systems additional topical signals about expertise scope.
The fix: Every entity in your schema — authors, organizations, locations — should have at least two to three off-site sameAs references to authoritative, machine-readable sources. If an entity can’t be verified off-site, build that presence first, then mark it up.
Frequently Asked Questions
How do I know if my schema markup is actually working?
Use Google's Rich Results Test for immediate validation of any URL, then check Search Console's Enhancements reports under the Rich Results section for site-wide coverage and error data. For AI search specifically, manually query your topic in Google AI Overviews and Perplexity and note whether your site is cited — that's a proxy signal for how well your structured data and entity markup are being processed.
What's the difference between a schema error and a schema warning in Search Console?
Errors in Search Console's Rich Results report indicate that Google found a required property missing or a property with an invalid value — these make the page ineligible for the specific rich result. Warnings flag recommended (but not required) missing properties; the page may still qualify for rich results, but you're leaving enhancement quality on the table. Fix errors first; then work through warnings systematically.
Can schema markup hurt my rankings if I implement it incorrectly?
Incorrect schema on its own is unlikely to cause ranking drops, but it will prevent you from earning rich results, and certain violations — specifically fake or misleading review markup — can trigger manual actions that do harm rankings and visibility. The bigger risk of poor schema is opportunity cost: you're investing time in markup that returns nothing, while a properly built competitor earns star ratings, FAQs, and AI citations that yours doesn't.
Is JSON-LD always the right format, or should I use Microdata or RDFa?
JSON-LD is Google's recommended format and the easiest to maintain because it lives in a separate script block and doesn't require modifying your HTML element by element. Microdata and RDFa work and are processed by Google, but they tightly couple your markup to your HTML structure, making updates and debugging significantly more complex. For new implementations, always use JSON-LD unless a specific platform constraint requires otherwise.
How often should I update my schema markup?
Review schema on any page whenever its content changes significantly — new author, updated pricing, added reviews, changed business hours. Beyond that, run a site-wide schema audit at least twice a year, and immediately after any major CMS update, theme change, or plugin upgrade that touches your site's header or template files. Schema is not set-and-forget; it requires the same maintenance discipline as your internal links or meta tags.
Do AI Overviews and LLMs actually use schema markup?
Yes — Google's AI Overviews are built on the same indexing infrastructure that processes structured data, so schema signals absolutely inform which content gets surfaced and how it's attributed. Third-party AI systems like Perplexity crawl the live web and process structured data to disambiguate entities and understand content type. Well-implemented schema — especially Article, FAQPage, Person, and Organization — makes your content significantly more machine-readable for all of these systems, not just traditional Google search.
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.