Most schema work fails on eligibility rather than syntax. Google supports roughly twenty-five structured data features, each with its own required properties, and valid markup earns candidacy rather than a guaranteed result. Three published policies disqualify more implementations than bad code ever does: do not mark up content that is not visible on the page, mark up all the items a user can see rather than a favorable subset, and never let a business publish star ratings about itself, since reviews controlled by the entity being reviewed are ineligible for the star feature. A structured data manual action removes rich result eligibility without touching web rankings, which is why the damage often goes unnoticed. The strategy that holds up is a connected entity graph, kept honest against visible content, validated at release and monitored afterward.
Most schema markup strategy advice stops at the point where the validator turns green, which is roughly the least interesting moment in the whole process. Valid markup is table stakes. The interesting questions are which features you are actually eligible for, which published rules quietly disqualify you, and how you find out when a deploy silently breaks something invisible.
This is a working schema markup strategy built around those questions rather than around a list of types to install. It covers what Google currently supports, the eligibility policies that void otherwise perfect implementations, how to structure markup as a connected graph rather than a pile of isolated blocks, and what to monitor once it ships.
Eligibility, not entitlement
Every schema markup strategy should start from one distinction: what markup actually buys. Adding structured data makes a page a candidate for a feature. It does not commission the feature, and Google decides what to show based on its own assessment of whether the result would help the user.
Completeness affects that assessment. Every feature has required properties without which the page is simply not a candidate, and Google’s guidelines add that the more recommended properties you supply, the higher the quality of the result to users. That is the closest thing to a scoring statement in the documentation, and it argues for filling in optional fields rather than stopping at the minimum viable block.
Framing it this way changes how the work gets prioritized. A half-populated block on every page across a site is usually worth less than complete markup on the templates that actually matter, and the decision about which templates matter is a business question rather than a technical one. That is where we start when scoping this kind of implementation, using the same reasoning that shapes how we structure our own published content, where the markup follows the content model rather than being sprinkled on afterward.
What is actually on the table right now
Anyone asking how to get rich results should start here rather than with a plugin. The supported feature list is public, finite, and shorter than most teams assume, which makes it a better planning document than any third-party checklist.
The approximate number of structured data features Google Search currently documents as supported, ranging from Article, Breadcrumb, Organization and Product through to narrower types such as Vacation rental, Math solver, Education Q&A and Speakable. Structured data carousels sit in beta through an early adopters program. Anything outside that list may still describe your content accurately, but it will not produce a search feature.
Grouping them by who they apply to makes the planning conversation much shorter than working through the list alphabetically.
| Applies to | Features worth planning for | Usual blocker |
|---|---|---|
| Almost every site | Organization, Breadcrumb, Article, Image metadata, Video | Incomplete properties and inconsistent identifiers across pages |
| Retailers | Product, Review snippet, Carousel in beta | Variant handling and prices that disagree with the visible page |
| Service businesses with premises | Local business, Event, Q&A | Self-published star ratings, which are disallowed |
| Publishers and communities | Discussion forum, Profile page, Subscription and paywalled content | Newer types nobody has implemented yet, which is the opportunity |
| Specialist cases | Job posting, Course list, Dataset, Recipe, Vacation rental, Software app | Implemented by sites they do not apply to, which achieves nothing |
The last row is the one worth reading twice in the other direction. A plugin that offers every available type makes it trivially easy to publish markup describing something the business does not do, which produces no feature and adds an inaccuracy to the page. Availability is not a reason to implement.
The fourth row is where the unclaimed ground sits. Discussion forum and Profile page markup arrived recently enough that most sites with genuine community content have not touched them, and a feature nobody has implemented is easier to win than one every competitor shipped years ago. Spotting those gaps before the field fills in is ordinary competitive work, and it is a recurring exercise in the national campaigns we run where the same twenty competitors have all done the obvious things.
The visibility rule that voids most implementations
If one policy sinks more schema markup strategy work than any other, it is this one, and it is stated plainly in Google’s guidelines.
“Don’t mark up content that is not visible to readers of the page.”
The temptation this forbids is obvious and common. A team adds a rich block of properties describing details the page does not display, because the markup is invisible anyway and more data feels like more signal. The guidelines treat that as a mismatch rather than a bonus, and the requirement is that what the markup claims corresponds to what a person actually sees.
There is a second half to the same rule that catches better-intentioned teams. When a page contains multiple items of a type, the guidelines call it misleading to mark up only some of them, using the example of omitting reviews that are visible to users. Selecting the flattering subset is treated as deception, not curation. That distinction matters most on catalog and directory templates, where the logic deciding what to include is code rather than an editorial choice, which is exactly the sort of thing we look at first for the smaller businesses we work with, where a single template governs the whole site.
Why your star ratings never showed up
This is the rich results eligibility rule that generates more confused support tickets than any other, because the markup validates perfectly and the stars never appear.
For Local business and Organization types, if the entity being reviewed controls the reviews about itself, those pages are ineligible for the star review feature. A testimonials page on your own website is the entity reviewing itself. So is a page that embeds a third-party reviews widget, since the placement is still controlled by the business. Neither is a bug, and no amount of correcting the JSON will change the outcome.
Review snippets remain available for other types, including Book, Course, Event, Movie, Product, Recipe and Software app, and reviews must be readily available on the marked-up page rather than tucked behind an interaction. The practical consequence for a service business is that reputation belongs on platforms you do not own, and multi-location operators feel this most, since the star ratings that matter attach to each location’s own profile rather than to a page on the corporate site. That is part of why we keep a separate section for each market we serve rather than consolidating everything into one testimonials page that can never earn a star.
What a structured data manual action actually costs
A schema markup strategy has to account for enforcement, and the mechanism is unusually specific about its own scope.
A structured data manual action means a page loses eligibility to appear as a rich result. Google’s documentation states directly that it does not affect how the page ranks in web search. That is a narrower penalty than most people fear, and it is also the reason the damage frequently goes unnoticed for months: traffic does not collapse, positions do not move, a visual enhancement simply stops appearing and nobody reads the Manual Actions report.
The named violations are the ones you would expect. Fake reviews or ratings, impersonating a person or organization, misrepresenting ownership or purpose, and using markup to deceive or mislead. What deserves attention is that none of these need to be deliberate at scale. A ratings aggregate that defaults to five stars when no reviews exist is fabricated data, whatever the intent behind the code that produced it. Catching that class of defect before it becomes a pattern is a governance problem more than a markup problem, and it belongs in the review process for the enterprise programs we manage, where one template defect replicates across thousands of URLs before anyone notices.
Structure the graph, not the page
In a schema markup strategy, the difference between a mature structured data implementation and an average one is not which types are present. It is whether the blocks are connected to each other.
The average implementation produces an isolated island of markup per template: an Article block here, an Organization block there, each declaring its own version of the publisher with no relationship between them. A connected implementation defines each entity once, gives it a stable identifier, and has every other block reference that identifier rather than repeating a description of it. The publisher of the article is the same organization that appears in the site-wide markup, stated as a reference instead of a duplicate.
The benefit is consistency that survives contact with a real content operation. When the company description lives in one place and everything else points at it, a rebrand is one change rather than four hundred, and no page can drift into describing the business differently from its neighbors. That principle is the whole reason we keep one canonical description of who we are rather than letting each section invent its own.
Two site diagrams side by side. On the left, five page templates each containing its own self-contained markup block, with the organization described separately inside every one of them and four of the five descriptions subtly different after two years of edits. On the right, the same five templates, but the organization is defined once in a single shared node and each template holds a lightweight reference pointing back to it, with author and location nodes handled the same way. The left diagram has fifteen assertions and four contradictions. The right has five assertions and none.
Where this work carries over to AI visibility
It is worth being precise here rather than promising more than the evidence supports. Structured data is not a documented input to most answer engines, and a schema markup strategy sold primarily as an AI visibility fix is overselling.
What does carry over is the discipline underneath it. Defining your entities once, describing them identically everywhere, and keeping every published claim consistent with what the page actually says is the same work that makes a brand legible to any machine reading the web, whether it is building a search index or absorbing text. The markup is one expression of that consistency rather than the source of it.
The honest sequencing for a schema markup strategy follows from that. Fix the content and the entity consistency first, express it in markup second, and treat any AI benefit as a reasonable expectation rather than a guarantee. We take the same position across the Generative Engine Optimization work we deliver, because a client who was promised citations from a JSON block is a client who will be disappointed on a predictable schedule.
Validation is a moment; monitoring is the job
The last piece of any schema markup strategy is the one teams skip. Structured data has an unusual failure profile: it is invisible to every human who visits the site, so when it breaks, nothing looks wrong. A migration drops a field, a plugin update changes an output format, a template refactor removes a block, and the site carries broken markup for a year while everyone assumes it is fine.
Three checks at three different moments cover it. Before release, validate the rendered output of each affected template rather than the source, since markup injected or modified by script is what actually reaches the crawler. After release, read Search Console’s rich result reports, which tell you what Google detected and considered valid across the whole site rather than on the one page you tested. Continuously, watch the Manual Actions report, since that is the only place a structured data penalty is ever announced.
There is a sequencing point buried in that list worth stating outright. Validation answers whether the markup is well formed, the rich result reports answer whether Google accepted it, and only the second question tells you anything about eligibility. Teams routinely stop after the first, report the work as complete, and never learn that Google discarded most of it.
Those three habits cost very little once they are written into a schema markup strategy, and they are almost never written in. Building them into the release cycle rather than into an annual audit is the difference between structured data that stays correct and structured data that was correct once, and it is the sort of ongoing discipline reflected in how we scope and price ongoing engagements rather than one-off implementations.
Frequently Asked Questions
Does valid schema markup guarantee a rich result?
No. Valid markup makes a page eligible to be considered, and Google decides whether showing the feature helps users. Required properties are the floor, and Google’s guidelines add that supplying more recommended properties produces a higher quality result, so completeness improves the odds without ever guaranteeing the outcome.
Why are my review stars not showing in search?
Most likely because the reviews are self-serving. For Local business and Organization types, if the entity being reviewed controls the reviews about itself, those pages are ineligible for the star review feature. That covers testimonials on your own site and embedded third-party review widgets alike, and no correction to the markup changes it.
Can I mark up content that is not visible on the page?
No. Google’s guidelines say not to mark up content that is not visible to readers of the page, and the markup has to correspond to what a person actually sees. Adding hidden properties because the block is invisible anyway is treated as a mismatch rather than extra signal.
Is it acceptable to mark up only my best reviews or products?
No, and the guidelines name this specifically. When a page contains multiple items, marking up only some of them is considered misleading, with omitting visible reviews given as the example. On catalog and listing templates this is usually a code decision rather than an editorial one, which makes it easy to ship without anyone intending it.
What happens if I get a structured data manual action?
The page loses eligibility to appear as a rich result. Google states that it does not affect how the page ranks in web search, which makes the penalty narrower than most teams fear and much easier to miss, since rankings and traffic stay roughly where they were. The Manual Actions report in Search Console is where it is announced.
How many structured data features does Google actually support?
Around twenty-five are documented, spanning common types like Article, Breadcrumb, Organization and Product through to narrow ones such as Math solver, Vacation rental and Speakable, with structured data carousels currently in beta. Types outside that list can still describe your content accurately but will not produce a search feature.
Should schema blocks reference each other?
Yes, and it is the main thing separating a mature structured data implementation from an average one. Define each entity once with a stable identifier and have other blocks reference it rather than repeating a description. Consistency then survives edits, and a rebrand becomes one change instead of hundreds of slightly divergent copies.
Does schema markup improve AI visibility?
Indirectly at best, and it should not be sold as the mechanism. What transfers is the discipline behind it: defining entities once, describing them identically everywhere, and keeping claims consistent with the visible page. That consistency is what makes a brand legible to any system reading the web. The markup expresses it rather than creating it.
How do I keep structured data from breaking silently?
Validate the rendered output of each affected template before release rather than the page source, read Search Console’s rich result reports after release to see what Google detected across the whole site, and keep an eye on the Manual Actions report. Because markup is invisible to visitors, nothing else will tell you it broke.
Skyfield Digital will audit what your templates actually output, check it against the eligibility rules that disqualify most implementations, and tell you which features you can realistically win.
Sources
| Google Search Central | Structured Data Markup That Google Search Supports |
| Google Search Central | General Structured Data Guidelines |
| Google Search Central | Review Snippet Structured Data |
| Google Search Central | Introduction to How Structured Data Works |
| Google Search Console Help | Rich Result Status Reports |
| Google Search Console Help | Manual Actions Report |
