Structured data manual action: does it affect rankings or only rich results?

Google's general structured data guidelines explicitly separate this action's rich-result eligibility impact from ordinary web ranking. That distinction changes the diagnosis. If a team reports lost traffic, we examine search appearance and the broader performance data rather than automatically attributing every loss to the schema notice.

Record the action's exact label, examples, and date alongside the relevant page templates. Also check whether there are other notices. A structured data issue can coexist with a separate content or technical problem, so do not let a precise explanation of one action become a universal explanation of the site's performance. Our manual-action diagnosis guide covers the broader fork.

A technical test and an editorial policy review ask different questions. Google's structured data guidelines explain that quality issues may not be detected by automated tools. Valid markup can still describe something misleading or unsupported by the visible content.

We keep two results in the audit: technical validity and content-policy review. A green technical result is useful evidence about parsing and supported properties, but it does not answer whether the review exists, whether the entity is correct, or whether the claim is current. Asking an engineer to fix syntax alone can leave the entire reason for the manual action untouched. We assign the claim review to someone who owns the underlying facts; the implementation owner should not have to invent editorial evidence to satisfy a validator.

The truth table records the page, structured data type, relevant property, visible supporting content, source system, and responsible owner. Start with the notice examples, then inspect other pages produced by the same component. The aim is to find the rule generating the mismatch, not simply edit one conspicuous JSON-LD block.

For an illustrative product page, compare the described product, price, availability, and review content to what the reader can actually inspect. For a service page, check that a plugin has not repackaged the business as an unrelated product to obtain a feature. Write down the discrepancy in plain language. This makes the work reviewable by both the editorial owner and the engineer responsible for the markup.

Google's introduction to structured data points publishers to feature-specific documentation. We read the relevant feature guide alongside the general policies. A schema.org type existing does not, by itself, establish eligibility for a Google search appearance.

Review markup deserves particular care. Google's review-snippet guidance includes rules about supported entities and self-serving reviews. We identify what entity is reviewed, who supplied the review, where readers can see it, and whether the feature is appropriate. Do not invent ratings, reassign reviews to a different entity, or imply that an embedded widget guarantees stars in search.

Many sites emit structured data from several places: the theme, an SEO plugin, a product component, and an embedded service. Our recommended investigation inventories each producer before adding another patch. Conflicting blocks can leave one correct description beside another inaccurate one. The browser's final output is the useful inspection target.

Choose whether to correct the affected markup or remove it when the page cannot support the claim. Then inspect another page using the same template and a page using a different template as a control. If source data changes over time, test that lifecycle too. An accurate value at deployment does not prove that an old offer or removed review will disappear from future structured output. We prefer deleting an unsupported assertion to leaving it live while waiting for evidence that may never exist.

Use Google's Rich Results Test for the types it supports, and save the relevant result alongside the policy review. We record the public URL, inspection date, corrected claim, and producer. This is more informative than an unlabeled screenshot showing that a tool returned a passing state.

The reconsideration request should explain what was misleading, how the template or data source changed, and how the affected inventory was checked. State clearly when markup was removed rather than repaired. If several plugins or editorial systems are involved, our manual action recovery support can help coordinate the evidence and ownership. Avoid presenting technical validation as a prediction of Google's review outcome.

Google's structured data guidelines do not guarantee a rich result even for correct markup. We track the manual-action decision, technical health, observed search appearance, and broader performance as separate fields. This prevents a revoked action from being reported internally as guaranteed restoration of stars or another feature.

Give the corrected implementation an owner after the incident. New templates, plugin updates, and content changes can introduce fresh mismatches. Our suggested ongoing check is a small set of representative pages tied to the source systems that maintain their claims. Expand that check when a system changes, rather than treating a one-time passing result as permanent evidence.