How to Recover from a Google Manual Action

A manual action is a human Google reviewer deciding your site violates a spam guideline, and the single fact that defines your entire recovery path is that it appears in Search Console under Security and Manual Actions. Algorithmic demotions never notify you; a manual action does. So before you change anything, confirm one is actually listed, because the recovery process here is specific and sequential: read the action in the report, fix the root cause completely across every affected page, file a reconsideration request that evidences the fix, and wait. Partial fixes get rejected, and there is no phone line, escalation, or negotiation beyond the reconsideration loop.

This post owns the end-to-end recovery process. The taxonomy of penalty types and the deeper craft of writing the reconsideration text are a separate concern; here the spine is the workflow that takes you from “there is an action in my report” to “it has been revoked.”

First, confirm it is a manual action and not an algorithmic drop

This is the distinction people skip, and skipping it wastes the most time. Open Security and Manual Actions in Search Console. If the report says “No issues detected,” you do not have a manual action, full stop, and a reconsideration request cannot help you because there is nothing for a reviewer to revoke. A drop with a clean Manual Actions report is algorithmic: a core update reassessment, a quality-system effect, or a technical or competitive cause. Those are fixed by improving the site and waiting for re-evaluation, not by submitting a request.

A manual action means a person at Google looked at your site, judged it in violation, and applied a suppression that stays in place until you clear it. An algorithmic change is a system reweighting signals, with no human in the loop and no notification. The recovery mechanisms do not overlap. People burn months “improving content” when they needed a reconsideration request, and they burn reconsideration requests on drops where no action exists. Read the report first so you know which problem you actually have.

Read the action: scope and the named violation

The report names the specific violation and its scope. Scope is either site-wide (the whole domain is affected) or partial (specific URLs or sections). The violation is named in Google’s own terms, for example a thin-content action that reads “Thin content with little or no added value,” an unnatural-links action, user-generated spam, or a hacked-site action. Both pieces matter. The violation tells you what to fix; the scope tells you how much of the site the reviewer was looking at and therefore how much you must clean before the request can pass.

Expand the action to see the affected URLs or the sample Google provides. For a partial action, that sample is your starting map, but treat it as a sample, not an exhaustive list. Reviewers cleared the request against the pattern, not just the listed URLs, so fixing only the named examples and leaving the same pattern elsewhere is the most common reason a “fixed” site gets rejected again.

Fix the root cause completely, not the symptom

Recovery is binary. The reviewer is checking whether the violation still exists, so “mostly fixed” reads as “still in violation.” You have to remove or genuinely fix every page that exhibits the problem, not most of them.

What “fix the root cause” means depends on the violation, but the trap is always the same: treating a quality problem as a formatting problem. For a thin-content action on affiliate or aggregated pages, length, headings, and a rewrite do not fix thinness; what fixes it is genuine firsthand value the page did not have before, or removing the pages that cannot be made first-hand. Adding three paragraphs of padding to a page that exists only to funnel an affiliate link does not change what the reviewer saw. For an unnatural-links action, that means identifying the manipulative links and disavowing or removing them at the pattern level, which is why link cases take longer to review. For user-generated spam, it means cleaning the spam and closing the hole that let it in, not just deleting the visible examples.

Decide page by page: can this page carry real, unique value, or does it only exist to game the guideline? If the latter, removing it is a legitimate and often faster fix than trying to rehabilitate it.

File the reconsideration request

Once the fix is live and crawlable, use Request Review inside the Manual Actions report. Verify the fixes are actually deployed first; inspect a sample of corrected URLs so you are not describing changes Google cannot yet see. A request that references fixes the reviewer cannot verify on a live crawl is a wasted cycle.

The request itself has to evidence three things: what the problem was, what you specifically changed, and proof. State the violation plainly, describe the concrete remediation (pages removed, content rewritten with firsthand detail, links disavowed), and point to where the reviewer can confirm it. Be specific rather than apologetic; a reviewer is checking facts, not sincerity. The deep mechanics of writing persuasive request copy and the full menu of violation types are out of scope here; the process point is that the request must map cleanly to the fix you actually shipped.

Timeline, rejection cycles, and what recovery actually returns

Expect a review to take from a few days to a few weeks, and longer for link-related actions because reviewers have to assess link work that itself takes time to be recrawled. You may go through more than one cycle. If the request is rejected, Google generally indicates the action is still in place; the honest read is that the fix was incomplete, so widen the cleanup beyond the originally listed URLs to the rest of the pattern and resubmit. Do not resubmit identical work hoping for a different reviewer.

Set expectations about the ceiling, too. Clearing the action removes the suppression, but it does not restore rankings by fiat. Once the action is gone, your pages compete normally, and if recovery required deleting a large share of thin pages, the cleaned site is smaller and may have a lower traffic ceiling than before. That is the correct outcome, not a failure of the process. There is no appeal beyond reconsideration and no way to accelerate the review; the only levers you control are the completeness of the fix and the specificity of the request.

Frequently Asked Questions

How do I know if I have a manual action or an algorithmic demotion?

Open Security and Manual Actions in Search Console. If an action is listed, it is manual and clears via a reconsideration request. If the report says no issues, the drop is algorithmic and there is nothing to request; you improve the site and wait for re-evaluation. This single check determines your entire recovery path.

Can a reconsideration request fix a drop from a core update?

No. Core-update and other algorithmic drops do not produce a manual action, so there is nothing for a reviewer to revoke. Submitting a reconsideration request in that situation does nothing. Those drops recover only through genuine quality improvement and subsequent re-evaluation.

Why was my reconsideration request rejected after I fixed the pages?

Almost always because the fix was partial. Reviewers assess the pattern, not only the sample URLs in the report, so fixing the named pages while the same violation persists elsewhere reads as still in violation. Widen the cleanup to every page exhibiting the problem and resubmit.

Sources

Manual actions report – Search Console Help: https://support.google.com/webmasters/answer/9044175
Reconsideration requests – Search Console Help: https://support.google.com/webmasters/answer/35843
Debug Google Search traffic drops – Google Search Central: https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops