Search Console Security Issues: Every Warning, Explained
By Glenn Lyvers · Updated · 6 min read
The Security Issues report in Google Search Console is where Google tells you, in its own categories, why it has flagged your site: malware, deceptive pages, harmful or uncommon downloads, or one of three kinds of hacked-content injection. Each category points to a different kind of problem, and each clears the same way: fix the underlying issue, then click Request Review and describe what you did. Approved reviews remove the warnings, usually within a few days.
I look at this report on nearly every cleanup I take on, and the pattern I see is the same: owners either don’t know it exists, or they’ve requested three reviews in a row without fixing anything and are now stuck in the slow lane. This guide is the middle path. Find the report under Security & Manual Actions in the left sidebar of Search Console. If you haven’t verified your site there yet, do that first; verify the domain property so subdomains are covered too.
What the detection types actually mean
Google groups everything into two families. The wording matters, because it tells you where to hunt.
Social engineering and malware flags
“Deceptive pages” means phishing or trick content: fake logins, bogus support popups, download buttons that don’t do what they say. On WordPress this is very often a phishing kit uploaded into wp-content/uploads or a random new folder at the root. “Malware” means code on your pages tries to infect visitors, typically injected JavaScript loading a payload from a domain you’ve never heard of. “Harmful downloads” and “Uncommon downloads” both concern files you serve: the first means Google decided a download is malicious or bundles unwanted software, the second means a file is new and unrecognized, which is a softer flag that shows up even on some legitimate installers. These same detections power the red browser screens I decoded in the Deceptive site ahead guide.
Hacked content flags
“Content injection” means spam keywords or links were inserted into your existing pages, often invisibly. “Code injection” means the site’s code itself was modified, think malicious PHP in theme files or a tampered .htaccess. “URL injection” means the attacker created new pages on your site, and if you see thousands of strange URLs in a site: search, this is your category. Each listing usually includes sample URLs and a detection date. Treat the samples as your evidence bag.
How to investigate before you touch anything
Don’t clean blind. Fetch the sample URLs with the URL Inspection tool and read the rendered HTML, because injected content frequently cloaks itself and serves spam only to Googlebot. Note what you find: which files, which URLs, which patterns. Two reasons. You’ll clean better, and you’ll need the specifics when you write the review request. If the samples 404 for you but Google keeps flagging them, suspect cloaking or a conditional redirect rather than assuming Google is stale.
If the report is empty but browsers still warn about your site, the flag may be on a subdomain that isn’t verified, or it may come from a non-Google blocklist entirely. My free blacklist checker sorts that out quickly, and this free scan gives you an outside view of the site itself.
Fix the cause, not just the symptoms
Whatever the category, the flagged content got there somehow, and the review only sticks if that route is closed. On the sites I clean, the route is usually an outdated plugin, a stolen password, or a leftover backdoor from an earlier, half-finished cleanup. Remove the flagged content, then find and remove the access. The full process is in my article on removing malware from a hacked WordPress site, and my technical IOC checklist lists the places persistence likes to hide.
How to write a review request that passes
The Request Review button opens a text box, and what you type genuinely matters. A human or a well-trained system reads it, and vague promises read like an unfinished cleanup. Skip “we take security very seriously.” Write three plain sentences: what was compromised, what you removed, what you changed so it can’t recur. For example: “An outdated contact form plugin allowed a file upload. I removed the injected spam pages under /item/ and two backdoor files in wp-content/uploads, updated all plugins and themes, and rotated every admin and database password.” Specific, checkable, done.
One warning from experience: never request a review as a diagnostic step to see whether Google still objects. Failed reviews slow down the next one, and I’ve inherited sites where a string of hopeful, fix-nothing review requests had stretched the process out by a month.
How long do reviews take?
Malware reviews are usually the fastest, often under 72 hours. Deceptive pages and download flags commonly land in the two-to-several-day range. Hacked-content reviews are the slow ones; a few days is typical and two weeks isn’t rare. Nothing you click speeds up the queue. The only lever you control is submitting once, with the site actually clean.
Why reviews get rejected
Almost always because something bad is still reachable. The usual culprits: cloaked spam still serving to Googlebot, spam URLs redirected to the homepage instead of returning 404 or 410, an untouched second infection on a subdomain or in a forgotten folder, or a backdoor that reinfected the site between your cleanup and Google’s recheck. If a review comes back rejected, the report gets fresh sample URLs. Inspect them the same way and go again, properly this time.
A note on the downloads flags, because they trip up legitimate sites more than the others. “Uncommon downloads” is not an accusation; it means Google hasn’t seen that exact file enough times to trust it, which happens to every small software vendor who ships a new installer version. You can request a review, but the flag also tends to age out as the file builds reputation. “Harmful downloads,” on the other hand, means Google decided the file is actually bad. If you didn’t put the file there, an attacker did, and you’re back in cleanup territory. If you did put it there, scan it yourself before arguing, because bundled installers from ad-supported download services fail Google’s standards even when the core program is honest.
While a review is pending, resist the urge to keep editing the site heavily. Google is rechecking during that window, and a site that changes under the reviewer’s feet can produce confusing results. Finish the cleanup, submit, then leave it alone until the verdict.
And if the whole thing has already eaten your weekend, you don’t have to keep going alone. Reading this report, cleaning what it points to, and writing reviews that pass on the first try is everyday work for me. Hand it over here and get back to running your business while I argue with Google on your behalf.
Common questions
Where is the Security Issues report in Search Console?
In the left sidebar under Security and Manual Actions, at the bottom of the menu. If you have never verified your site with Search Console, you will need to do that first. Verify the domain-level property rather than a single URL prefix so detections on subdomains show up too.
What is the difference between a security issue and a manual action?
A security issue means Google detected malware, phishing, or hacked content that endangers visitors. A manual action is a ranking penalty applied by a human reviewer for guideline violations like spammy links. They live in neighboring reports and both offer reviews, but a hacked site normally shows security issues, not manual actions.
How long does a Google security issues review take?
Malware reviews often complete within 72 hours. Deceptive pages and download-related flags usually take a few days. Hacked-content reviews are the slowest and can run up to two weeks. Submitting repeated reviews without a real cleanup makes the process slower, so it pays to fix everything before the first request.
Why was my security issues review rejected?
Because Google still found flagged content when it rechecked. Common reasons are cloaked spam that only serves to Googlebot, spam URLs that redirect to the homepage instead of returning 404, an infection on an unverified subdomain, or a backdoor that reinfected the site after your cleanup. The rejection comes with fresh sample URLs, and those tell you where to look next.
Can I remove a Google security warning without Search Console?
Mostly no. For flags on your own site, Search Console is the official channel for requesting review, and there is no phone number or paid escalation path. The exception is when the warning comes from a different blocklist, such as an antivirus vendor, which has its own removal process separate from Google.
What should I write in the request review box?
Three specific sentences: how the site was compromised, exactly what you removed, and what you changed to prevent it recurring. Name the plugin, the folders, the files. Vague statements about taking security seriously do not help, and specifics make the review easy to approve.