Common Schema Markup Mistakes That Keep You Out of AI Answers

You added the markup. You checked the box. Your pages still do not show up when buyers ask ChatGPT or Perplexity about your category.

That gap is where most schema markup mistakes live, and almost all of them are fixable in an afternoon. This guide is for marketing leads who already have schema on the site and cannot work out why it is doing nothing. By the end, you will be able to look at any page and tell whether its markup is helping an AI engine understand you or quietly teaching it not to trust you.

Get your expectations right before you debug anything

Let's clear something up first, because it saves you weeks of chasing the wrong fix.

Schema is not a citation lever you pull. Google's own guidance on AI features says structured data is not required to be eligible for generative AI search, and that there is no special schema.org markup you need to add for AI features. Google goes further and warns against over-focusing on structured data as a strategy.

The field data agrees. Ahrefs ran a matched study of 1,885 pages that added schema between August 2025 and March 2026, compared against 4,000 control pages. AI Overviews citations went down 4.6%, a statistically significant drop. AI Mode citations rose 2.4% and ChatGPT citations rose 2.2%, but neither was distinguishable from zero. Adding schema to a page did not, on its own, buy more citations.

Here is the twist in that same study. Pages with schema are roughly three times more common among AI-cited pages than among pages that never get cited. Both things are true at once, and the reason matters: sites that already do the hard work tend to also ship schema. The schema rides along with the quality. It does not manufacture it.

So does any of this reach the models? Yes, and there's good evidence. In February 2026, Mark Williams-Cook built a fake company called "DUCKYEA t-shirts" and placed its address only inside the JSON-LD, never in the visible content. Both ChatGPT and Perplexity repeated that address back in their answers. The models read structured data the same way they read the rest of your page.

Put those together and you get the mental model for everything below. Schema helps an AI engine parse a page it already has reason to trust. It cannot conjure trust out of nothing. And because engines read your markup as content, wrong markup is not neutral. It is a second, contradictory version of your page.

Nearly all schema markup problems sort into four buckets:

1. Mismatch. The markup says something the page does not.
2. Wrong type. The markup describes the wrong kind of thing.
3. Missing required properties. The markup is incomplete, so it is skipped.
4. Spammy or hidden markup. The markup is there to game, not to describe.

The seven steps below walk each page through those four buckets in the order that finds problems fastest.

Step 1: Confirm the page is eligible to be cited at all

Before you touch a single property, check that the page can be seen.

Schema errors are not always where the story starts. A page has to be crawlable, indexable, and carrying real content before any markup on it matters. If the URL is blocked in robots.txt, carries a noindex tag, or is canonicalized to a different page, your markup is decoration on something nobody is reading.

What to do: run an indexability check on the URL. Confirm it is not blocked, not noindexed, and not pointing its canonical elsewhere. Then read the page as a stranger and ask whether it has a clear primary topic in plain text.

How to tell it is done: the URL passes an indexability check, and you can say in one sentence what the page is about using only what is visible on it.

Where people go wrong: adding schema to a thin page and expecting it to compensate. It never does. Schema describes substance, it does not replace it. If a page has nothing to say, no amount of markup fixes that, and this is the single most common reason smart teams keep asking why is my schema not working.

Take a breath here. If a few pages fail this step, that is normal, and you just found a bigger win than schema was ever going to give you.

Step 2: Name the page's primary entity before you pick a type

Most wrong-type problems come from picking the type first and rationalizing after.

Flip the order. Write one plain sentence describing what the page actually is. "This page is a product detail page for our billing plan." "This page is a comparison article between two tools." Then find the most specific schema.org type that matches that sentence.

What to do: write the sentence, then match it to a type. Article is a fallback for when nothing more specific fits. It is not a default.

How to tell it is done: the type matches the page's primary entity, not the secondary stuff on it. A blog post that mentions your product is still an Article, not a Product.

Where people go wrong: defaulting to Article on everything because Article is the type everyone knows. The confusion pairs that show up over and over:

• FAQPage versus QAPage. FAQPage is for a page that is itself a list of questions and answers you own. QAPage is for a single question with answers from multiple users, like a forum thread. Using FAQPage on user-submitted content is a direct policy violation.
• Article versus NewsArticle. NewsArticle pulls in stricter news policies and signals a different content category. Do not reach for it because it sounds more authoritative.
• Recipe versus HowTo. Recipe is for food. Full stop. General procedural content is HowTo.
• Product versus Article. A product detail page is Product. A review or comparison is an Article, with a nested Product where it genuinely fits.
• Organization versus LocalBusiness. LocalBusiness expects a physical address and hours. Using it for an online-only business fails validation and signals inaccuracy about who you are.

Common mistake: stacking Recipe, FAQPage, and Product on the same page to "cover" every rich result type. Engines do not read that as thorough. They read it as a page that cannot say what it is.

Step 3: Audit the required properties, then the recommended ones

This is the step where invalid schema markup usually hides, because incomplete markup fails silently. Nothing turns red on your site. The block just gets skipped.

Every type Google surfaces has required properties and recommended ones. Miss a required property and validation fails. Miss the recommended ones and the signal gets weaker without ever breaking.

What to do: open the documentation for your chosen type. List every required property. Confirm each one is present with a real value, not a placeholder. Then do the same pass for the recommended properties and fill what you actually have data for.

How to tell it is done: every required property holds a genuine, non-empty value that corresponds to something on the page.

Where people go wrong: the same handful of gaps, again and again:

• aggregateRating without ratingValue, reviewCount or ratingCount, and bestRating.
• An Offer inside Product with no price or priceCurrency.
• availability left blank, which defaults to OutOfStock and removes your shopping eligibility.
• acceptedAnswer inside an FAQPage Question with no text.
• An author with no name, or an author left as a plain string instead of a Person object with a name and url.
• An image set to a relative URL, or pointing at a blocked or hotlink-protected CDN path.
• duration, thumbnailUrl, or uploadDate missing from a VideoObject.
• Breadcrumb position starting at 0 or skipping numbers.

A few syntax traps belong in the same sweep, because they kill the whole block rather than one field. JSON has no comments, so a comment inside your JSON-LD breaks parsing. Single quotes are invalid. A trailing comma after the last property is invalid. Dates must be ISO 8601, so "2026-01-15" works and "January 15 2026" does not. And @context must be exactly "https://schema.org", because a misspelling there silently disables everything inside it.

Step 4: Match every markup claim to what a reader can see

If you only fix one thing this month, make it this one.

The rule from Google's structured data guidelines is that your markup must represent the main content of the page as the user sees it. Their own worked examples call out a sports streaming site labeling broadcasts as local events, and a woodworking site labeling instructions as recipes.

Remember the DUCKYEA test. AI engines treat your JSON-LD as page content. So when the markup claims things the page never says, you have handed the engine two versions of the same page that disagree. That is not a missing signal. It is a contradiction, and contradictions cost you trust.

What to do: render the page with JavaScript disabled, or look at the static HTML. Walk every field in the JSON-LD and find its visible counterpart on the page.

How to tell it is done: no field in the markup lacks something a human reader can see.

Where people go wrong: ratings, prices, review counts, and author bios that live only in the JSON-LD. Also these:

• FAQPage on a product page with no visible Q&A block.
• Recipe on a non-food how-to article.
• Product markup on a category page or a blog post.
• Article markup on a homepage or a tag page where the real article lives elsewhere.
• LocalBusiness on a national brand with no storefront.

If a field has no visible counterpart, the field is wrong. Delete it, or put the information on the page. Both are fine. Leaving it is not.

This is also the point where a page-by-page audit stops being realistic. Checking five pages by hand is a morning. Checking two hundred is a project nobody finishes. This is where DeepSmith's sitemap module helps: it brings your published pages in and classifies each one by topic, type, angle, and buyer stage, so you can see in bulk which pages are marked up as something they are not, instead of clicking through them one at a time.

Step 5: Strip out stacked, hidden, and fabricated markup

Google's structured data spam policies treat four things as violations: markup that does not represent the main content, markup irrelevant to the page, markup meant to deceive users or search engines, and review markup that is not genuine.

The patterns that trigger enforcement are specific:

• Markup hidden with display:none, off-screen positioning, or zero-size containers.
• Markup injected only by client-side JavaScript that crawlers may never execute.
• Aggregate ratings with no underlying reviews visible anywhere on the page.
• Reviews imported from unrelated products or other sites.
• Multiple top-level types where only one describes the primary content.
• Markup on pages blocked by robots.txt or noindex.

The consequences are real. Google can ignore structured data on the offending page or across the whole site, and manual actions can be filed. As of May 2026, the spam policies officially cover AI Overviews and AI Mode, so these violations follow you onto AI surfaces too. Fabricated reviews carry a second layer of exposure in the United States, where the Federal Trade Commission enforces prohibitions on fake reviews. That one is not just an SEO problem.

What to do: confirm one primary @type fits the page. Confirm every aggregateRating traces back to real reviews a visitor can read. Confirm the markup parses from the static HTML, not only after JavaScript runs.

How to tell it is done: nothing stacked, nothing irrelevant, nothing invented, and no markup describing content the user cannot see.

Where people go wrong: treating this as a gray area. It is not. If the markup exists to influence a machine rather than describe the page, it is the kind of schema markup problems that get structured data ignored site-wide.

Step 6: Validate, and take the warnings seriously

Now run it through the tools. Schema Markup Validator checks your markup against the schema.org vocabulary. Google's Rich Results Test checks it against Google's rich result eligibility rules. They answer different questions, so run both.

What to do: run the URL through both. Work through every error, then every warning.

How to tell it is done: zero errors and zero warnings on both tools.

Where people go wrong: two places. First, treating warnings as optional. Warnings are often just policy changes that have not landed yet, and they become errors later. Second, and this is the bigger one, assuming that passing validation means the markup is working. It does not. Validation confirms your markup parses and is well-formed. It says nothing about whether the markup describes your page honestly, and nothing about whether any engine will use it. A page can pass every validator and still be marked up as the wrong thing entirely. That is why validation comes at step six and not step one.

Worth knowing: valid markup does not guarantee a rich result either. Several types have restricted eligibility. FAQ rich results, for instance, are limited to specific government and authoritative sites, so most teams will never see them display no matter how clean the markup is. The markup can still earn its keep as a clarity signal for retrieval.

Step 7: Re-check after every template or content change

Schema breaks quietly. That is what makes it so annoying.

A theme update, a CMS migration, a redesigned template, a new content block: any of these can drop a field, break a date format, or orphan an author object. Nothing on the page looks different. The markup just stops being right, and you find out months later.

What to do: re-run validation on a representative page from each template after any change to the CMS, theme, or content template. Put a quarterly audit on the calendar for everything else.

How to tell it is done: re-validation passes on a sample from each template, and the audit cadence exists somewhere other than your memory.

Where people go wrong: shipping template changes without re-validating, and letting brand details drift. Any markup that references your company (Organization, sameAs links, author entities) has to keep matching the live site. This is the other place DeepSmith earns its spot: Deep IQ holds your brand, product, and entity context in one place, and the writing pipeline builds schema markup, headings, internal links, and metadata in during creation rather than bolting them on afterward. New pages start aligned instead of needing a cleanup pass.

The pre-publish checklist

Keep this next to you. One line per bucket, with the fastest way to catch it.

What to do next

Do not audit the whole site. Pick your five most important pages, the ones you actually want cited when a buyer asks about your category, and run them through the seven steps.

You will probably find the same two schema errors repeating across every template. Fix the template once and you have fixed every page it renders. That is the leverage here, and it is why this work is smaller than it looks from the outside.

Then set the cadence: validate on template change, audit quarterly. That's it. That is the whole discipline.

If the constraint is that you have more pages than hours, that is a production problem rather than a schema problem, and it is worth naming as one. DeepSmith is built for that side of it, keeping markup, structure, and metadata aligned with live content as you publish. You can start a free trial and see it against your own pages before you decide anything.

Your markup does not need to be perfect. It needs to be honest. Get that right and the rest is maintenance.