Hacked Content vs Security Issues vs Google Manual Actions

Site owners often call every Google notification a “penalty”. Yet Search Console may show a security finding, a manual action, or no current report while Chrome still displays a Safe Browsing warning. The wrong response—such as submitting a manual-action reconsideration for malware, or using a Removal request as cleanup—wastes time and may leave visitors exposed.

The quick answer: open the correct Search Console property and inspect Security Issues and Manual Actions separately. Record each report’s message and sample URLs; one report does not stand in for the other. If a browser shows an interstitial, record the exact URL and warning, then compare it with Security Issues. Identify the finding first, perform the matching technical recovery, and request a review from the right report only after you have verified the fix.

Three signals that are often confused

Signal	Question it answers	Next step
Search Console Security Issues	Did Google identify malware, phishing/social engineering, or hacked content on this property?	Review the category and sample URLs; fix the technical issue and its full impact, then request a security review here if offered.
Search Console Manual Actions	Did a human reviewer determine that pages or the site violate Google’s spam policies?	Read the action type, affected pages, and remediation guidance; fix the violation and submit reconsideration from this report.
Safe Browsing / browser warning	Is a browser or safety service warning people about a particular URL?	Record the warning and URL. Check Security Issues and relevant status; do not infer the result from one browser or device.
A page disappears, drops, or remains indexed	Is there a crawl, indexing, content, or ranking issue?	Check Page indexing, canonical, server responses, and content. Those symptoms alone do not prove a manual action or a hack.

Google says the Manual Actions report covers decisions by human reviewers about spam-policy compliance and is a separate report (Manual actions report). Security Issues focuses on detected security threats. Google also explains that security labels, malware, hacked content, and phishing can appear in different contexts (why Google labels a site dangerous). Interfaces, property coverage, and detection can change, so use the current report itself—not an old article or someone else’s screenshot—as the source of truth.

Diagnose the signal without increasing exposure

1. Verify the property. Match the domain, protocol, subdomain, and URL prefix. A property for https://www.example.com/ may not cover every host if it is a URL-prefix property. For multisite or multiple domains, check each relevant scope.
2. Open both Search Console reports. Record the date, category, status, message, and example URLs in Security Issues and Manual Actions. Keep screenshots in a restricted internal ticket; redact email addresses, tokens, or customer data before sharing with a provider.
3. Read the accompanying message. Distinguish malware, hacked content, social engineering, spam, and indexing notices. Do not label a traffic decline a manual action if the report does not show one.
4. Handle sample URLs safely. If a URL contains phishing or a dangerous download, do not open it on your everyday browser. Record its path, response, logs, and time; ask the host for an isolation method. An attacker may show different content to an owner, visitor, or crawler.
5. Identify the browser warning. Record the browser, exact wording, domain, path, and time. A warning may be limited to a particular URL and may not match the report status you see. Compare more than one context only with the team’s approval, without sending a visitor to the dangerous page.
6. Use Google results carefully. A site:example.com search may reveal unfamiliar URLs, but it is not a complete inventory; no result does not prove the site is clean. Reconcile any clue with the sitemap, database, server logs, security reports, and directory structure.

Google notes that hacked content can involve injected code on existing pages, new spam pages, hidden content, or redirects that activate only for a particular referrer, user agent, or device (Spam policies). A normal homepage is therefore not enough to close an incident. For a focused technical workflow, read our guide to initial response to a hacked WordPress site and signs of malware on a WordPress site.

Choose recovery based on the report

If Security Issues lists a finding

Contain the problem first: contact the host, restrict access to harmful URLs, preserve file/database/log copies, and protect customers. Do not just delete the sample URL. Determine whether the source was an account, plugin or theme, changed file, database, cron job, server configuration, CDN, or hosting credential. Review every affected URL and trigger, including pages that appear only after a certain referrer.

Restore from a known-clean backup or remove each compromised change, close the entry point, revoke risky tokens and sessions, and update vulnerable components. Verify the result on an isolated copy and on production using a relevant URL/device matrix. Document what changed and evidence that the site no longer serves harmful content.

After all findings and causes are fixed, submit one review request through Security Issues if the option is available. Explain the finding category, root cause, work performed, scope checked, and verification result. Google may provide more sample URLs or need time to review; a request is not a promise that warnings or rankings will immediately recover. The report does not replace cleanup.

If Manual Actions lists an action

Open the action details and affected-page scope. Identify the stated issue—such as user-generated spam, misleading or thin content, structured data, links, or another policy category. The fix must address the report’s issue across its relevant scope, not just remove one example URL.

Document the affected examples, corrections, controls that prevent recurrence, and verification. Submit reconsideration from the Manual Actions report only after the violation has been fixed. A security review is not a substitute for a manual-action request, and a ranking decline is not proof of a human action. If malware is also present, run a security response in parallel; the two findings require different checks.

If only a browser warning is visible

Record the URL, warning type, time, and browser. Confirm the correct property is verified, then check Security Issues and Search Console messages. Also inspect redirects, download files, third-party scripts, and pages that vary by device or referrer. If the report has no finding, that does not prove the warning is false: preserve evidence, ask the host to review logs, and use the review/reporting route relevant to that warning category. Do not test a phishing page on a visitor’s device.

If both reports are empty

Do not submit a review request that does not correspond to a report. Investigate other possibilities: HTTP status, canonical or noindex, robots rules, sitemap, content quality, server uptime, URL changes, and provider-level security controls. A URL that remains visible after cleanup may need recrawling; Google’s Removals tool temporarily hides results, but it does not delete a server page or close an entry point. Clean the content and its source before relying on a removal request.

Evidence that helps your host and reviewer

Build one timeline recording when the warning first appeared, relevant changes, affected files or accounts, backup source, containment actions, patches, revoked access, tested URLs, and outcomes. Include file hashes or checksums where useful, but never send passwords, session cookies, a full database, or customer data through an unapproved channel.

Keep two copies: an untouched evidence copy with restricted access and a working copy for cleanup. Separate scanner output from manual verification. State what your checks actually covered—for example, core files were verified but a premium plugin had no public checksum, or the database and CDN configuration still need review. Honest scope is more useful than an unverifiable claim that a site is “100% clean”.

Common mistakes and how to avoid them

• Treating Security Issues and Manual Actions as the same thing because they appear under one Search Console menu.
• Requesting reviews repeatedly before cleaning all affected pages and fixing the vulnerability.
• Treating a normal homepage or a green scanner result as proof there is no conditional redirect, spam, or hidden file.
• Using Removals and assuming the source has disappeared from the website.
• Deleting every page that contains a medicine or pharmacy term without separating legitimate business content from an injection.
• Promising an index, warning, or ranking recovery date that you cannot control.
• Sharing raw evidence that contains private data in a public ticket or forum.

Prevention starts with scheduled updates, least-privilege accounts, MFA, tested backups, file-change monitoring, restricted uploads, separately retained logs, and a clear host escalation path. Google recommends monitoring site pages and security reports for unexpected content or URLs (malware-prevention guidance). If a WordPress site shows unfamiliar administrator accounts or hack indicators, follow our WordPress security guide for small businesses before calling the incident closed.

Does a manual action mean the site was hacked? Not necessarily. Manual Actions addresses spam-policy violations identified by a reviewer; malware or hacked content follows the security route. Check both reports if you see different symptoms.

If Security Issues is empty, is the browser wrong? Not automatically. Confirm the property and host, record the warning, check the URL safely, and ask the provider to review logs. The report is one evidence source, not the only one.

Will a Removals request fix hacked content? No. It can hide a result temporarily, but it does not repair a file, database record, redirect, or weakness that added the content.

Can I request a review as soon as a scanner finds no files? Not if the scan scope, sample URLs, configuration, or root cause remains uncertain. A review should follow cleanup that you can explain and verify.

If a security notice or manual action threatens traffic and user trust, request a WordPress security audit or emergency recovery assistance with a timeline and safely redacted evidence.