Google reconsideration requests
Submit a reconsideration request only for a confirmed manual action, after the underlying problem has been fully repaired and documented. Security issues use their separate review path.
Know when the form exists
A reconsideration request asks Google to review a site after a manual action has been fixed. Security issues have a separate review action inside the Security Issues report. There is no equivalent form for an ordinary core-update loss, a clean Manual Actions report, or an SEO tool's “toxic link” warning.
If you do not have a notice, a better-written request cannot create a review channel. Investigate the loss instead, starting with the first-party penalty checks. A confirmed notice sends the work through the Google manual-action removal process, with the named issue defining its scope.
Build the request from the work log
Google says a good request explains the exact quality issue, describes the steps taken to fix it, and documents the outcome. Those are evidence categories, not headings that magically make a request complete.
| Statement | Evidence behind it | What Google can verify |
|---|---|---|
| Exact notice and scope | Preserved wording, date, property, and whether the action is partial or sitewide | The correct issue and affected pattern. |
| Root production cause | Template, vendor, serving rule, account, or workflow | The repair reaches the source rather than a few examples. |
| Complete work | Counts, dates, representative URLs, removal records, and prior attempts | Every affected pattern was handled. |
| Recurrence control | Generator disabled, access closed, policy changed, or approval removed | The violation is not still being produced. |
| Public verification | Live URLs, final 404/410 states, rendering comparisons, and URL Inspection | Google can reach the repaired result. |
Use dates and concrete examples. “We improved quality across the site” asks the reviewer to believe an adjective. The work log should make the affected system, completed repair, and final live state inspectable.
Make the repaired result crawlable
Affected pages must be reachable by Google during review. Do not use robots.txt, authentication, a paywall, or noindex as a cosmetic way to make a violation invisible and then claim it was repaired. If content was intentionally removed, make the removal technically final; if it was repaired, let Google crawl the repaired version.
For unnatural inbound links, document good-faith removal work and use disavowal only for the qualifying remainder in that confirmed link cleanup.
Write from facts the reviewer can inspect
We improved the quality of the affected pages and put safeguards in place.
The notice covered generated city pages. We removed 412 URLs, retired the generator on 6 August, returned 404 for deleted routes, rewrote 18 pages with independent service information, and checked the final states in URL Inspection.
The second version works because it names the affected system, completed actions, counts, dates, and live outcomes. Use only facts supported by the work log. Do not add a confession the evidence does not support, blame a former supplier instead of explaining the repair, or promise that the violation can never recur.
A concise request can follow four paragraphs: the exact notice and scope; the production cause; the completed repair with representative evidence; and the control that now prevents the same output. Attach or link supporting records where the interface allows, but do not make the reviewer reconstruct the story from a folder of unlabeled exports. An SEO penalty removal company that made the repair can write those four paragraphs from its own log.
Set the right expectation after submission
Search Console confirms receipt and later reports the decision. Google says most reviews take several days or weeks and that link-related reviews may take longer; there is no fixed service level to promise. Do not resubmit while a request is pending.
A successful review revokes the manual action. It does not restore a historical result set. After revocation, technical accessibility, relevance, links, competition, and the quality of the current site still determine what happens next.
The request should be shorter than the work log because the work has already made the case. If the notice is confirmed but the repair is not, send the notice before drafting the request.