Marking Up Content That Isn’t Visible: Why It Backfires

Marking up content that isn’t visible on the page is one of Google’s most clearly stated structured data policies, and one of the most quietly broken ones. Add FAQ schema for questions that aren’t written out on the page, or review markup with no reviews a visitor can actually see, and you’re not adding extra SEO value, you’re violating a documented spam policy that can get the rich result suppressed entirely.

This mistake happens constantly, and rarely on purpose. A plugin auto-generates schema from data that lives in a spreadsheet, not the page. A developer copies a JSON-LD template from another site and forgets to check whether every field maps to something a visitor can actually read. Here’s what the guidance says, what “backfires” actually looks like, and how to audit for it.

What does Google’s guideline actually say?

Google’s structured data general guidelines are direct on this point: mark up content that is visible to readers of the page, not information that isn’t present. The documentation gives a specific example: if your JSON-LD markup describes a performer, the HTML body needs to describe that same performer. The same logic extends to every schema type. FAQPage schema needs the actual questions and answers rendered as visible text. Review schema needs reviews a visitor can read. Recipe schema needs the ingredients and steps present on the page, not just packed into structured data.

This isn’t a minor style preference buried in a technical appendix. Google classifies violations of this policy as a spam issue, in the same category as keyword stuffing or cloaking, not as a soft ranking signal you can ignore at low cost.

Myth vs reality: four common hidden-schema mistakes

Schema Markup: Myth vs Reality

What actually happens when this gets flagged?

The most common consequence isn’t dramatic, it’s quiet. The rich result for that schema type simply stops appearing in search results for that page. No warning email, no obvious signal beyond a rich result that used to show up and now doesn’t. Check Search Console’s structured data reports periodically; a sudden drop in valid items for a schema type, with no code change on your end, is often exactly this.

A full manual action for structured data spam is less common but does happen, particularly at scale, sites that programmatically generate hidden schema across hundreds of pages rather than one page with a one-off mistake. That shows up in Search Console’s Manual Actions report and requires a reconsideration request after the fix, which costs real time, sometimes weeks, before the rich results come back.

How do you actually audit for this on an existing site?

• Pull the JSON-LD for a sample of pages using the Rich Results Test or view-source, and list every property with a value.
• Check each value against the rendered page. Can a logged-out visitor, reading the actual HTML output, find this exact text somewhere on the page?
• Pay special attention to plugin-generated schema. SEO and review plugins often pull from a database field that was never meant to be displayed, price history, internal ratings, admin-only notes.
• Test with JavaScript disabled if your site is JS-heavy. Content that only renders client-side but isn’t present in what Googlebot’s renderer sees can create the same mismatch even when a human visitor would see it fine.

Is there ever a legitimate reason for markup that seems to go beyond the page?

Sometimes what looks like a violation isn’t one. Organization schema describing your company’s founding date, phone number, or social profiles doesn’t need to repeat every field as visible body text, this is entity-level metadata about the business, not claims about page content, and Google treats it differently from FAQPage or Review schema. The rule specifically targets schema types tied to on-page content claims: questions and answers, reviews, recipes, events, products. It isn’t a blanket demand that literally every JSON-LD field have a visible twin somewhere on the page.

The practical test we use: if the schema type exists specifically to describe something the page contains (a review, a question, a recipe step), it needs a visible match. If the schema describes the entity itself (who the organization is, what its logo looks like), the bar is different and closer to “accurate,” not “visibly repeated.”

Why does this keep happening even to careful teams?

Because the failure mode is invisible until you specifically go looking for it. A page renders correctly. The rich result test passes with no syntax errors, because syntax validity and content-matching are two entirely different checks, and most tools only catch the first one. Nothing looks broken until months later when someone notices FAQ rich results quietly stopped appearing, and by then nobody remembers which content update caused the mismatch.

The fix isn’t complicated, it’s just a step most schema workflows skip: after generating or updating JSON-LD, read it next to the rendered page and confirm every claim has a visible match. That single check, done consistently, prevents the whole category of problem.

Does this matter beyond Google’s rich results now that AI engines cite pages too?

It matters more, not less. AI systems that summarise or cite a page, ChatGPT, Perplexity, Gemini, tend to lean on structured data as a shortcut for what a page is actually about, alongside the visible text. Schema that overstates or invents content a page doesn’t contain doesn’t just risk a suppressed rich result anymore, it risks the AI engine citing a claim your page never actually makes, which is a worse outcome than a missing star rating in a search snippet. If a customer asks an AI assistant about your product and it repeats a review or a spec that only ever existed in JSON-LD, that’s a credibility problem that traces straight back to markup nobody double-checked against the page.

This is one more reason the “just add more schema types, more coverage can only help” instinct is wrong. Coverage that doesn’t match content isn’t neutral. It’s a liability with two separate enforcement paths now instead of one.

How do you fix it once you’ve found a mismatch?

1. Add the missing visible content first, if it’s reasonable to. If review schema exists but the reviews themselves aren’t rendered, the cleaner fix is usually to display the actual reviews, not to delete the schema.
2. Remove schema fields you can’t back up with visible content. If there’s no realistic way to surface a field as visible text, take it out of the JSON-LD rather than leaving the mismatch in place.
3. Re-test with the Rich Results Test after the fix. Confirm the schema still validates syntactically once fields are removed or content is added.
4. Watch Search Console for the rich result to return. This isn’t instant, expect anywhere from a few days to a few weeks depending on how often Google recrawls the page.

Frequently asked questions

Will Google penalise my whole site for hidden schema on one page?

Usually not the whole site. The most common outcome is that page’s rich results stop showing, sometimes just for that schema type. A manual action for structured data spam is possible but less common than the rich result simply getting suppressed, which is quieter and easier to miss.

Does the content have to be visible without scrolling?

No. It needs to be present and accessible on the page, not necessarily above the fold. Content inside an accordion, a tab, or something revealed by clicking is fine, Google’s guidance is about content existing on the page for users to find, not about initial viewport visibility.

Can I mark up content that’s only visible to logged-in users?

No, this specifically violates the guideline. If a logged-out visitor, and Googlebot, can’t see the content, the markup describes something that doesn’t exist for the audience the rich result is served to. This applies even if the information is completely accurate for logged-in users.

What about schema for information that’s true but just not written out as text?

Still against the guidance. A price that only appears in a product image, a rating implied by star icons with no numeric text nearby, an author name that only exists in an image credit, all technically true, none of it readable text on the page, which is what the policy requires.

Sources

• General Structured Data Guidelines, Google Search Central
• Google: Your Structured Data Should Match Visible Content, Search Engine Roundtable
• Schema Markup: A Practical Guide With Copy-Paste JSON-LD
• Does Schema Improve Rankings Directly?
• FAQPage Schema After Google Reduced Its Display
• Common Schema Errors in Search Console and Their Fixes