Google Manual Actions: Diagnose, Fix, Request Review

Direct answer: a Google manual action is confirmed only when it appears in the Manual Actions report in Search Console. Read the action type and affected scope, preserve the notice, find every page or pattern involved, correct the underlying policy violation, verify that Google can access the repaired pages, and document what changed. Submit one reconsideration request that explains the issue, the work, and the outcome. If the report shows no action, do not send a reconsideration request for an ordinary algorithmic, technical, seasonal, or reporting-related traffic drop.

This guide owns recovery from a confirmed manual action. It does not diagnose core updates or promise that revoked action will restore an old ranking. For a wider drop with no notice, begin with the Search Console evidence check and the sitewide technical audit workflow.

Confirm that it is a manual action

Google says manual actions can lower rankings or omit some or all affected pages without a visible warning to searchers. Search Console is the source of truth for the action, its description, scope examples, and request-review control. An email can alert you, but the report is what you should preserve and work from.

1. Preserve the notice and control the incident

Before changing the site, save the action type, issue description, first-detected or notification date when shown, affected patterns, sample URLs, property name, and a screenshot or PDF of the report. Record who owns the website, Search Console, CMS, hosting, link outreach, structured data, user-generated content, and any agency access.

Pause the behavior connected to the notice. That may mean stopping a publishing feed, disabling a vulnerable user-submission route, suspending paid link placement, removing an outbound-link template, or freezing a structured-data deployment. Do not delete evidence or make unrelated sitewide changes in panic. You need a stable incident record and a reviewable set of corrections.

2. Read the action type and affected scope

Expand every active action in the report. Note whether it affects all pages or a narrower pattern such as a directory. Google warns that listed URLs can be examples rather than a complete inventory, so treat them as clues to the underlying generator, template, link source, account, or editorial process.

1. Copy the exact action label and follow its Learn more route.
2. Read the current spam policy or guideline connected to that action.
3. Map each sample URL to the system or process that created the problem.
4. Search for sibling pages, alternate hosts, parameters, feeds, and templates with the same behavior.
5. If more than one manual action is active, keep separate finding and validation rows for each one.

Scope controls the work. Fixing three examples is insufficient when the same template created hundreds of affected pages. Conversely, a section-level action does not justify deleting unrelated legitimate pages from the rest of the property.

3. Find the complete pattern, not only the samples

Build an inventory from the action evidence and the system that produced it. Use a crawl, CMS export, database query performed by an authorized owner, link exports, source-code search, or account audit as appropriate. The objective is to answer four questions:

• Which live and historical URLs share the behavior?
• Which template, workflow, vendor, account, or editorial rule created it?
• Can the same behavior reappear after a deploy, import, user submission, or scheduled job?
• What evidence will prove both removal and prevention?

A reproducible crawl joined with Search Console evidence is useful for URL patterns, directives, responses, canonicals, and rendered output. It cannot decide policy intent by itself. Link-related cases need link-source review, while user-generated or hacked-spam cases need account, moderation, and vulnerability evidence too.

4. Fix the cause and the affected output

This is a triage map, not a substitute for the instructions attached to the actual notice. Google's manual-action documentation lists action-specific remediation, and that current guidance outranks a generic checklist.

Correct both the public result and its source. If a plugin can recreate a redirect, a feed can republish removed pages, or an unmoderated account can restore spam, the incident is not actually contained.

5. Keep the repaired pages reviewable

Google generally instructs site owners to keep affected pages reachable for review. Follow the action-specific guidance: for the site reputation policy, noindex is an allowed remediation for inconsistent content, but the page must not also be blocked by robots.txt or Google cannot see the rule. Do not use login, a paywall, robots.txt, or noindex merely to conceal an unresolved violation. Use URL Inspection and a normal browser session to verify representative repaired URLs.

• Confirm the expected status and final URL without an unintended redirect chain.
• Compare raw and rendered output when scripts, redirects, or structured data caused the issue.
• Test representative pages from every affected pattern, device state, and template.
• Confirm that removed content is actually absent and that replacement content is visible to users.
• Re-run the inventory that found the pattern and record remaining exceptions.

Do not request ordinary URL indexing as a substitute for reconsideration. The action belongs to the Manual Actions workflow, and individual recrawl requests do not prove that the full violation was corrected.

6. Build a reviewable recovery log

Keep one row per issue pattern or material exception. The log should connect the notice to the affected scope, root cause, change, prevention control, evidence, and verification result. It gives the reviewer a concise trail and gives the owner a record if the request is rejected.

Property:
Manual action label:
Notice date:
Reported scope:
Incident owner:
Policy source:

Affected pattern or system:
Representative URLs:
Root cause:
Correction completed:
Prevention control added:
Evidence location:
Validation method:
Validation date:
Result: FIXED / EXCEPTION / RECHECK

Reconsideration request
1. Exact issue acknowledged:
2. Complete scope reviewed:
3. Corrections made:
4. Prevention controls added:
5. Evidence and representative examples:
6. Remaining exceptions, if any:

7. Write the reconsideration request

Google says a good request explains the exact quality issue, describes the steps taken to fix it, and documents the outcome. Write for a reviewer who needs to understand the incident quickly. Be direct about ownership, including inherited or vendor-created problems, without shifting responsibility.

If the site was recently acquired, say so and explain what was inherited, what ownership changed, and why the violating behavior can no longer recur. The owner still needs to fix the site before asking for review.

8. Submit once and wait for the decision

Use Request Review inside the active Manual Actions report only after all listed actions and affected patterns are fixed. Save the submitted text and confirmation. Google says most reviews take several days or weeks, and link-related requests can take longer. Do not resubmit while the first request is outstanding.

During the wait, keep the corrections live, preserve access, monitor the affected systems, and stop any workflow that could recreate the problem. A successful review revokes the manual action. It does not guarantee the previous ranking or traffic because relevance, competition, site quality, recrawling, reprocessing, and other systems still apply.

If the request is rejected

1. Preserve the decision message and compare it with the original notice.
2. Re-run the full pattern inventory, not only the URLs named earlier.
3. Look for alternate hosts, old templates, parameters, feeds, user accounts, injected code, redirects, and vendor-controlled assets.
4. Audit whether the root process can still recreate the violation.
5. Improve the evidence log and submit again only after additional remediation is complete.

A rejection is not a signal to rewrite the same request with more emotional language. It is evidence that the violation, scope, prevention, accessibility, or documentation remains insufficient.

What not to do

• Do not call every traffic drop a penalty. Confirm the report before choosing the recovery workflow.
• Do not fix only the example URLs. They may represent a much larger affected pattern.
• Do not hide affected pages from the reviewer. Blocking access does not demonstrate compliance.
• Do not move the same behavior to a new domain, subdomain, or directory. Policy circumvention can lead to broader action.
• Do not use the disavow tool as a generic backlink-cleaning ritual. Follow the action-specific guidance and preserve good-faith removal evidence.
• Do not submit repeated requests before a decision. Keep the first case stable and wait for the result.
• Do not promise a complete ranking recovery. Revocation removes the manual action, not every other ranking factor.

Manual action recovery checklist

• The Manual Actions report confirms an active action.
• The original label, notice, scope, examples, property, and dates are preserved.
• Every active action has its own root-cause and validation record.
• The team found the complete pattern beyond Google's sample URLs.
• The public output and the system that created it are corrected.
• Prevention controls have an owner and can be tested.
• Representative repaired pages are accessible to Google and users.
• The recovery log records corrections, evidence, exceptions, and validation.
• The request acknowledges the issue, explains the complete work, and documents the outcome.
• One request is submitted and preserved while the team waits for a decision.

Evidence basis

Manual-action definitions, scope behavior, accessibility requirements, the EEA site-reputation exception, reconsideration content, review timing, security separation, traffic-drop diagnosis, and spam-policy boundaries were checked against official Google documentation on August 31, 2026. The incident-control sequence, recovery log, prevention matrix, and rejection review are FloxoLab operational frameworks.

• Google Search Console Help: Manual Actions report, remediation, review requests, and timing
• Google Search Central: August 28, 2026 update to site reputation policy enforcement in the EEA
• Google Search Central: spam policies and policy circumvention
• Google Search Console Help: Security Issues report and its difference from manual actions
• Google Search Console Help: diagnosing traffic and ranking drops
• Google Search Console Help: URL Inspection and live testing