AI Summary
Google's general structured data guidelines apply to every implementation regardless of the rich result type being targeted, and they split into technical rules about format and crawlability and quality rules about content, relevance, completeness, location, specificity and images. Almost all real world penalties come from the quality side, and the usual cause is markup describing content that never appears on the page.
- Technical: JSON-LD is recommended, Microdata and RDFa are also parsed, and the page must never be blocked by robots.txt or noindex.
- Quality: markup must describe visible content, represent the page accurately, carry all required properties, and sit on the page it describes.
- Violations produce a manual action that removes rich result eligibility for the affected pages.
- A structured data manual action does not change ordinary ranking. Standard listings are unaffected.
Most teams read the documentation for the specific rich result they want and skip the general guidelines entirely. That is backwards. The type specific pages tell you which properties to include. The general guidelines tell you what will get your rich results withdrawn, and they apply to every type simultaneously. A Product implementation that satisfies every Product requirement can still be penalised for breaking a general rule.
This page works through the guidelines as an operational checklist: what each rule means in practice, what a violation looks like on a real site, and how the enforcement mechanism actually behaves.
Schema Types and Applications
The guideline that governs type selection is specificity. Google asks you to use the most specific applicable schema.org type and property names rather than defaulting to a generic parent, because precision carries information. A page describing a restaurant is better typed as Restaurant than as LocalBusiness, and better as LocalBusiness than as Organization.
The constraint on that instruction is accuracy, and it is where the specificity guideline collides with the relevance guideline. Reaching for a more specific type that misdescribes the page is worse than using an honest generic one. Google's own example of a relevance violation is a live streaming site that labels its broadcasts as local events, which is precisely this failure: a more specific and more attractive type applied to something that is not that thing.
| Guideline | What it requires | What a violation looks like | How to check it |
|---|---|---|---|
| Content | Only mark up content visible to readers of the page | Ratings or FAQ answers present in JSON-LD but nowhere on the page | Read the rendered page and find every marked up value in it |
| Relevance | Markup must accurately represent the page content | Streamed broadcasts labelled as local events | Ask whether a user would agree with the type you assigned |
| Completeness | Include every required property for the target rich result | Product without offers, Recipe without required fields | Rich Results Test errors, plus the type documentation |
| Location | Put the markup on the page it describes | Article markup for a post emitted site wide on every URL | Spot check several templates, not just one |
| Specificity | Use the most specific accurate type and properties | Everything typed as Thing or WebPage when better types exist | Walk the schema.org hierarchy down from your current type |
| Images | Image URLs must be crawlable and indexable | Image path blocked in robots.txt or behind a login | Fetch the image URL directly and confirm it returns 200 |
Implementation Best Practices
The technical guidelines are short and mostly about access. Three formats are supported: JSON-LD, which Google recommends, plus Microdata and RDFa, which are still parsed. Choose JSON-LD unless you have a specific reason not to, because it isolates the markup into one block that can be validated and changed without touching the surrounding template.
The rule that quietly breaks the most implementations is the crawlability requirement. Google states plainly that you must not block pages carrying structured data from Googlebot using robots.txt, noindex or any other access control method. This sounds obvious until you consider the realistic ways it happens: a staging directory rule that survives into production, a parameter based disallow that catches filtered listing pages, a noindex left on a template during a migration, or an image directory blocked years ago for crawl budget reasons that now makes every marked up image ineligible. If you are auditing this, the meta robots and X-Robots-Tag reference covers how the directives interact and which ones actually suppress processing.
The location guideline is the second technical trap. Structured data belongs on the page it describes unless the documentation says otherwise. Site wide injection of a single Article block, which some themes do, means every URL on the site claims to be that article.
// A listing page, marked up correctly
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "CollectionPage", "@id": "https://example.com/guides/#webpage",
"url": "https://example.com/guides/",
"name": "Technical SEO guides" },
{ "@type": "ItemList", "itemListOrder": "https://schema.org/ItemListOrderAscending",
"numberOfItems": 2,
"itemListElement": [
{ "@type": "ListItem", "position": 1,
"url": "https://example.com/guides/canonical-tags/",
"name": "Canonical tags" },
{ "@type": "ListItem", "position": 2,
"url": "https://example.com/guides/log-file-analysis/",
"name": "Log file analysis" }
] }
]
}Rich Results Impact
Meeting the guidelines makes a page eligible for a rich result. It does not produce one. Google decides whether to render the treatment based on the query, the device, the quality of the page and its own confidence in the data, so a perfectly compliant implementation can still show a plain listing. Eligibility is permission, not delivery.
It also bears repeating that structured data is not a ranking factor. The gain from a rich result arrives through presentation: a listing that carries more information and occupies more space earns a higher click through rate at the position it already holds. Briefing the work as a ranking intervention sets it up to be judged a failure regardless of how well it is executed. When valid markup produces no visible treatment, the diagnostic sequence in the guide to validating and debugging structured data separates implementation faults from eligibility conditions that no validator can test.
Multiple Entities on the Same Page
Pages that contain several things need a decision about how those things relate. The guidance is to mark up the individual items and to connect the ones that genuinely belong together using identifiers, rather than emitting a set of unconnected blocks and hoping search engines infer the relationships.
In practice this splits into two patterns. A listing page uses ItemList with each entry pointing to its own detail URL, as in the example above, because the listing page is not itself any of those items. A detail page uses one connected graph in which the page node, the organisation node and the primary entity reference each other by identifier. The mechanics of those references are covered in the guide to JSON-LD graph nesting, and the same identifier discipline is what makes Product schema on an ecommerce template resolve cleanly against the organisation that sells it.
Manual Actions: What They Do and Do Not Do
Enforcement for structured data violations runs through manual actions, and understanding the scope of the penalty prevents a great deal of unnecessary panic. A structured data manual action makes the affected pages ineligible for rich results. It is reported in the Manual Actions section of Search Console, it names the issue, and it persists until you fix the markup and successfully request a review.
What it does not do is change your ordinary ranking. Standard listings continue to rank as they did. The loss is the enhanced presentation and the click through rate that came with it, which is a real commercial cost but a different one from a ranking penalty, and worth describing accurately when you report it upward.
The remediation sequence is unglamorous. Identify every template emitting the offending markup rather than fixing the single URL named in the report. Either make the marked up content genuinely visible on the page or remove it from the markup. Re-test the live production URLs. Then request the review, and expect the process to take time rather than resolving overnight.
Frequently Asked Questions
What are Google's general structured data guidelines?
They are the rules every structured data implementation must follow regardless of which rich result type you are targeting. Google splits them into technical guidelines, covering supported formats and crawlability, and quality guidelines, covering content, relevance, completeness, location, specificity and images. Type specific documentation sits on top of these, it does not replace them.
Can you block structured data pages with robots.txt or noindex?
No. Google is explicit that pages carrying structured data must not be blocked from Googlebot by robots.txt, by a noindex directive or by any other access control. If Google cannot fetch and render the page, it cannot process the markup, so the implementation delivers nothing no matter how correct it is.
What happens if you mark up content that is not visible on the page?
You are violating the content quality guideline, and the consequence is a manual action rather than a validator warning. Manual actions for structured data make the affected pages ineligible for rich results until the markup is fixed and a review is requested. This is the most common way sites lose rich result eligibility.
Does a structured data manual action hurt your rankings?
No, and this distinction matters when you are explaining the problem internally. A structured data manual action removes rich result eligibility for the affected pages, but ordinary ranking and standard blue link listings are not affected by it. The damage is to presentation and click through rate rather than to position.
How specific should the schema type be?
Use the most specific type that is genuinely accurate for the page. Google's specificity guideline asks for the most specific applicable schema.org type and property names, because a precise type communicates more than a generic parent. The constraint is honesty: do not reach for a more specific type that misdescribes what the page actually is.
How do you mark up a page that contains several items?
Mark up the individual items and connect the ones that belong together using identifiers, so the relationships between them are explicit rather than inferred. For listing pages, each item generally needs its own detail URL. Emitting several unconnected blocks that each describe part of the page leaves search engines to guess how they relate.
Read the general guidelines before the type specific documentation rather than after. The type pages tell you what to include, but these rules decide whether any of it counts, and nearly every rich result withdrawal traces back to one of six quality guidelines rather than to a syntax error.
Source: https://developers.google.com/search/docs/advanced/structured-data/sd-policies#individual-items
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
