Is Your Schema Markup an AI Spam Risk? What Changed in May 2026

On May 15, 2026, Google updated its Search spam policy to explicitly cover "attempting to manipulate generative AI responses in Google Search," putting AI Overviews and AI Mode under the same enforcement framework that's always governed traditional rankings. Schema markup itself isn't the target of this change and isn't newly prohibited. But if your structured data asserts anything your page doesn't genuinely support, you're now operating under a policy that names AI manipulation directly, not just a general best-practice suggestion to keep markup accurate.

This matters more than it might sound like it does. A lot of schema advice over the past two years has nudged site owners toward markup that's technically valid but generous with the truth: inflated ratings, borrowed credentials, facts asserted in JSON-LD that never made it onto the visible page. Under the old framework, that was a policy violation with a vague, general consequence. Under the May 2026 update, it's manipulation of a specifically named surface, with the same enforcement Google uses for classic ranking spam: algorithmic demotion, manual actions, and in serious or repeated cases, removal from results.

This post covers exactly what changed, what still counts as normal, honest schema implementation, the specific practices that now carry more risk than they used to, and how to audit what you've already got. It's a companion to our broader answer on whether schema markup helps with AI search, that post covers what schema does and doesn't do for AI visibility; this one covers what can get you penalized while trying.

What actually changed on May 15, 2026

Before this date, Google's spam policy defined spam as techniques used to deceive users or manipulate Search systems into ranking content highly. That's it, ranking was the named target.

The updated definition reads: spam refers to techniques used to deceive users or manipulate Search systems "into featuring content prominently, such as attempting to manipulate Search systems into ranking content highly or attempting to manipulate generative AI responses in Google Search." That clause is the entire change, and it's a small edit with a specific consequence: AI Overviews and AI Mode are no longer an ambiguous gray zone sitting outside the spam framework. They're explicitly inside it.

Google didn't publish a separate enforcement date or a distinct penalty mechanism for this clause, it's a clarification layered onto the existing spam system, not a new one. Enforcement uses the same tools Google has always used: automated algorithmic demotions and manual spam actions, applied as violations are identified. Reporting at the time also noted this applies retroactively, content published before May 2026 that fits the updated definition isn't grandfathered in just because it predates the policy text.

The practical read: tactics that were already borderline against Google's spirit, biased comparison content designed to get quoted, "recommendation poisoning," schema that overstates what's on the page, no longer have to be argued about as edge cases. They're now squarely inside a policy that names the exact surface (generative AI responses) they're targeting.

Does this mean schema markup itself is against the rules?

No, and it's worth being precise here, because the update doesn't touch schema's legitimacy at all. Structured data remains explicitly recommended by Google for rich-result eligibility, and nothing about the spam policy update changes that. Accurate, matched, well-implemented markup is exactly as safe on May 16, 2026 as it was on May 14.

What changed is the consequence of the one thing Google has always required of structured data: it has to reflect what's genuinely on the page. That requirement predates this update by years, it's the same rule behind the "self-serving reviews" restriction and the general prohibition on markup describing content users can't see. What's different now is that violating it can be framed, and enforced, as an attempt to manipulate a generative AI response specifically, rather than a generic structured-data policy breach.

So the honest summary: if your schema has always matched your visible content, this update changes nothing for you. If you've been treating JSON-LD as a place to quietly assert things your page doesn't actually say, the ground under that practice just got firmer.

The specific schema practices that now carry more risk

Four patterns are worth auditing specifically, because each one is a place schema commonly drifts from truth, and each is exactly the kind of thing "manipulating generative AI responses" is aimed at.

Ratings and review counts that don't match the page. AggregateRating values that exceed, understate, or simply don't correspond to reviews a visitor can actually see and count. This was already the single most common reason star ratings vanish from search, Google rechecks eligibility on every crawl and drops the snippet when markup and visible content disagree. Now it also sits inside a policy explicitly covering AI-response manipulation, since an inflated rating misrepresented in an AI answer is a direct version of the harm the policy names. Our guide to earning star ratings covers the eligibility rules in full, including the self-serving-reviews trap that's closely related to this one.

Authorship and credentials asserted in markup but not demonstrated on the page. Person schema claiming credentials, affiliations, or expertise that the visible content doesn't back up. If an AI system extracts "written by a licensed [credential]" from your JSON-LD and that claim doesn't hold up, you've manipulated the answer it gave someone, whether or not that was the intent.

Facts stated in schema that never appear on the page. Prices, availability, specifications, dates, any fact present in structured data but absent from what a visitor actually sees. This is the plainest form of the violation, and it's also the easiest one to catch accidentally: a price that updates on the page but not in a hardcoded schema block, for instance, drifts into exactly this category without anyone intending it.

Manufactured or padded sameAs and third-party validation signals. Links asserting connections to profiles, directories, or knowledge bases that don't genuinely represent your entity, added purely to inflate apparent external validation. Real sameAs networks are a legitimate and valuable part of an entity profile, the risk is specifically in fabricating or padding that network rather than building it honestly.

None of these are new mistakes. What's new is the specific enforcement lens they now sit under.

This isn't a new rule, it's an old rule with sharper teeth

It's worth being clear that Google isn't asking anything of schema implementers in 2026 that it wasn't already asking. The structured-data general guidelines have always stated that markup must represent the content of the page, not describe content that isn't there. That's not new, and this update doesn't add a technical requirement on top of it.

What the update changes is the framing and the stakes. Before, "your schema doesn't match your page" was a structured-data-specific violation, evaluated mostly against rich-result eligibility, the consequence was usually just losing the snippet. Now that same mismatch, when it touches how an AI system represents you, can be evaluated as an attempt to manipulate a generative AI response, a spam violation with the broader consequences that category carries, up to demotion or removal, not just a lost rich result.

Same underlying rule. Different, more serious category of consequence when your markup and your page disagree.

What enforcement actually looks like

Google hasn't described a separate penalty flow for this clause, it uses the existing spam-enforcement machinery: automated systems that detect patterns algorithmically and demote affected content, and manual actions applied by human reviewers for clearer or more serious cases, visible in Search Console's Manual Actions report if one is applied to your site.

Reporting around the update has focused on tactics like biased listicles engineered specifically to be quoted in AI answers, and "recommendation poisoning," content built to game which source an AI system cites rather than to genuinely inform a reader. Schema-specific violations weren't the headline example, but they fit the same definition: content (including its structured data) built to make a generative AI system say something that isn't accurate or genuinely supported.

One practical note worth flagging: showing up in AI Overviews or AI Mode isn't itself a violation, and being cited isn't an endorsement Google is retroactively second-guessing. The policy targets active attempts to manipulate what gets surfaced or what an AI response says, not passive inclusion because your content happened to be a good, accurate match.

A safe-implementation checklist

Run through this whenever you add or update schema, and you stay comfortably clear of the update regardless of how enforcement evolves:

Every number in your markup has a visible match on the page. Ratings, counts, prices, dates, if it's in the JSON-LD, a visitor should be able to find the same value on the page itself.

Every credential or affiliation claimed in Person schema is genuinely demonstrated, not just asserted for effect.

Every sameAs link points to a real, controlled, accurate profile, not a padded list built to look more established than the entity actually is.

Nothing in your schema exists solely to shape how an AI system might phrase something about you. If you're asking "will this make the AI say something more flattering," that's the exact question the policy is aimed at.

Markup updates when the page updates. Drift between the two, a rating that changes on the page but not in the schema, a price that updates in one place and not the other, is the most common way honest sites end up accidentally out of compliance.

Common mistakes that carry more weight now

Hardcoded ratings that don't track real reviews. A static AggregateRating block set once and left alone while actual reviews change is the single most common source of markup-visible mismatch, and it's rarely deliberate, it's just neglect. Neglect isn't a defense the spam framework distinguishes from intent when the mismatch is discovered.

Copy-pasted Person schema across authors. Reusing one author's credentialed schema block as a template and swapping the name, without updating the actual credentials, quietly attaches real qualifications to people who don't have them.

Schema surviving a redesign that the visible page didn't. A common and usually accidental pattern: a site redesign updates visible content but leaves old JSON-LD templates untouched, so the markup describes a version of the page that no longer exists.

Treating sameAs as a checklist to pad rather than a genuine network to build. Adding links to profiles that don't meaningfully represent the entity, purely to look more externally validated than the brand actually is.

How to audit your existing schema for this risk

Pull up your live pages and compare markup to visible content directly. View source (not the browser's rendered DOM) on your key pages, extract the JSON-LD, and check every asserted fact against what a visitor can actually see and count.

Run Google's Rich Results Test on pages with ratings, reviews, or other numeric claims, and compare the parsed values against the page.

Check Search Console's Manual Actions report periodically, not just after something looks wrong, catching an issue before it's flagged is always better than requesting reconsideration after.

Prioritize pages where schema and content are maintained separately. Anywhere a developer hardcoded JSON-LD in a template while content editors update the page through a CMS is a structural risk for drift, regardless of anyone's intent.

Implementing this safely on WordPress

The core problem this update makes more consequential is one WordPress sites hit constantly: schema and content live in different places and get updated by different people at different times, so they drift apart quietly.

A hand-maintained JSON-LD block is accurate on the day it's written and increasingly inaccurate every day after, as prices change, reviews accumulate, authors change roles, or a page gets redesigned around it. That's not a spam attempt, it's neglect, but under the May 2026 policy, the outcome (markup that misrepresents your page to a generative AI system) looks the same regardless of intent.

This is the exact problem AI Schema Gen is built to solve structurally rather than through discipline: it generates schema from your actual, current page content, so ratings, facts, authorship, and other claims stay matched to what's genuinely there as your content changes, instead of drifting out of sync the way a static block does. It won't help you assert anything your content doesn't support, that's the wrong kind of help to want under this policy, but it removes the accidental version of the problem, which is the version most honest sites are actually at risk of. See our guide to connecting entities in your knowledge graph for how the connected, matched-to-content approach extends beyond any single page.