Manual action vs security issue: which problem and review route do we have?

Open the property that covers the affected URLs and record both reports before deciding that every symptom has one cause. Google's report comparison distinguishes manually detected search manipulation from security problems that can harm visitors. A traffic graph does not identify which category applies.

Our initial record contains the property, report name, issue label, sample URLs, first observation, and owner responsible for investigation. Save the actual message rather than a paraphrase such as 'Google banned us.' That wording leaves a developer or security responder without the detail needed to prioritize the work.

If you need the navigation steps, use our Search Console walkthrough . If both reports are clear, broaden the traffic-loss diagnosis while investigating any independent evidence of a security problem.

Yes. A compromise can produce spam content and harmful behavior, so we investigate both when the evidence calls for it. We do not assume a clean Manual Actions report means the website is safe, or that a security warning proves a manual action exists. Google's Security Issues documentation describes hacked content and harmful behavior in its own report.

Consider an illustrative incident: an unauthorized script inserts promotional text and redirects some mobile visitors. The script has a security origin, the output may violate search policies, and the conditional behavior makes a simple homepage check inadequate. The team's record should describe the observed script and conditions, then associate those findings with any notices actually present.

Preserve that distinction in communication. 'The redirect no longer reproduces in our tests' is a technical finding. 'The security review was approved' is a review result. 'The manual action is no longer listed' is another status. None should be silently substituted for the others.

A normal visit to the homepage is weak evidence when the reported problem lives elsewhere or depends on the request. We ask the technical owner to reproduce the affected URL and context, recording the route taken, device, time, and observed response. Use appropriate incident-response tools and controlled inspection rather than asking colleagues to click through a dangerous browser warning.

Google's dangerous-site guidance explains that warnings and reports can take time to synchronize. It also notes that an algorithmically detected problem may not produce a notice in the reports. When the visible warning and report status differ, record both observations and follow the diagnostic route appropriate to the warning instead of inventing a manual action.

We separate containment, cleanup, and prevention in the incident record. The technical owner needs to determine how the unwanted behavior entered the site and whether it can return. Removing one injected paragraph is not a complete incident response if the same unauthorized publisher or vulnerable component remains active. We prioritize containing ongoing harm over polishing the search submission, while preserving the evidence the technical owner needs for investigation.

Google's hacked-site guidance organizes the work around support, investigation, cleanup, and review. For our part, we connect the technical findings to the search evidence: which URLs existed, which remain valid after cleanup, and which reported behaviors no longer occur. That gives both teams a common record without making the SEO audit stand in for security expertise.

Keep timestamps and concrete verification outcomes. Identify the source of each change and the environment where it was tested. If the technical owner cannot yet explain the entry point, record that as unresolved rather than declaring the site secure based on a clean visual check.

Use Request Review within the report that contains the unresolved notice. For a security issue, that is the Security Issues report; for a manual action, it is the Manual Actions report. Google's security review steps say to fix and test all reported issues before requesting review. Some Google help pages use 'reconsideration' broadly, so the originating report is the clearer routing rule.

We maintain a separate status entry for each submission: prepared, submitted, pending, and final decision. Supporting facts can overlap, but the explanation should address the relevant notice. A manual-action submission should not merely say that a malware scan passed; a security submission should explain the security cleanup and verification. Our reconsideration guide covers the manual-action evidence structure.

When a decision arrives, compare it with the current status of both reports and the technical incident record. Close only the work that the evidence supports. We avoid a single green incident status while one report or the technical investigation remains open; a small amount of extra status detail prevents an expensive handoff mistake. Keep the date of clearance alongside remaining indexing or visibility questions, so the team can see whether the next task is further cleanup or a different search investigation.

A site may need follow-up work after the reported issue is cleared. We use the post-revocation diagnostic guide for that handoff. If a manual-action review is unsuccessful, use the rejected-request guide to reassess the evidence. Our manual penalty support can coordinate the search side with the technical team handling the incident.