A manual action is not an algorithm. Somebody at Google looked at your site, compared it with the spam policies and decided it crossed a line. That one fact changes how recovery works: you are not tuning signals, you are answering a human being who will look again.
The reviewer only sees what is live
Everything you intend to change is irrelevant at the point of review. The reviewer opens the URLs, loads the templates and reads what is published at that moment. A reconsideration request submitted before the fixes are deployed and verified is the most common reason a first attempt fails.
Submit when the site is already clean, not when the plan to clean it is agreed.
Google's examples are a sample, not the scope
When a notice lists three URLs, those three are illustrations. If they share a template, the fault almost certainly repeats across every page that template generates. Fixing the three and submitting tells the reviewer you did not understand the problem.
| What the notice shows | What it usually means | What to check |
|---|---|---|
| Three product URLs | A product template fault | Every URL that template renders |
| One directory | A publishing rule or import | The source feeding that directory |
| “Site-wide matches” | A sitewide pattern or link profile | The whole property, template by template |
Write the cause in terms someone can verify
Compare these two explanations of the same structured data issue:
- Vague: “We have corrected our schema markup and it now complies with Google's guidelines.”
- Verifiable: “Our product template inserted a five-star aggregate rating even when a product had no reviews. We removed the fallback rating and now read verified review records only. Example A has no rating markup; example B shows a rating matching its visible reviews.”
The second gives the reviewer two URLs to open and a claim to test. That is the whole job.
Keep an evidence log as you work
Record the affected URL or template, the old behaviour, the change made, the date it went live and the result of a fresh check. The log is what turns a defensive request into a documented one, and it is the difference between one submission and three.
Before you submit
- Re-read every action listed in the Manual actions report.
- Confirm the fixes are live on the affected property, not staging.
- Check any URL you reference loads for a logged-out visitor.
- Make sure shared documents open without an access request.
Google still controls the decision and the timing. What you control is whether the request is complete, honest and testable the first time it is read.