Google Search Console security issues warning

The Security Issues report in Search Console (Security & Manual Actions > Security Issues) isn’t a generic “something might be wrong” alert. It names a specific category, and each one means something different about what an attacker did to your site.

Hacked content

The most common flag, covering several distinct sub-patterns: URL injection (new spam pages you never wrote), code injection (malicious JavaScript or PHP added into your existing files), content injection (spam text or links inserted into your existing pages, often invisible via CSS), and the gibberish or cloaked-keyword hack, where attackers generate thousands of auto-translated spam pages targeting unrelated keywords — the Japanese keyword hack that hits WordPress sites is a well-documented example.

Malware and unwanted software

Google’s crawlers or Safe Browsing scanners found code that tries to do something to a visitor’s device or browser — a drive-by download, a malicious redirect chain, or a bundled unwanted-software installer. This is the category most likely to trigger the red “Dangerous site” interstitial in Chrome.

Deceptive pages (social engineering)

Phishing pages, fake login forms, fake tech-support-scam overlays, and fake download buttons. These are frequently injected on otherwise-legitimate sites as a single hidden page rather than a site-wide compromise, which is exactly why a sample-based check can miss them.

Two different reports, easy to confuse

Security Issues is generated automatically by Google’s crawling and Safe Browsing systems — no person reviewed your site. Manual Actions is the result of an actual human reviewer flagging a webspam violation. A site can have either, both, or neither, and clearing one has no effect on the other.

Google pulls back from what it can’t vouch for

When Google’s systems find evidence a site is compromised, the response is often a reduction in crawling and a removal of the affected URLs from the index, because continuing to rank a page that might serve malware or a phishing form works against Google’s core job of sending searchers somewhere safe. This is a protective, automated response — but the effect on your traffic is identical to a penalty either way.

Safe Browsing warnings choke off traffic even on indexed pages

Google Safe Browsing (the same system behind Chrome’s red “Dangerous site” interstitial, also used by Firefox and Safari) can flag your domain independently. A visitor who finds your URL in search or types it directly can still hit a full-page browser warning, which is why total visits can crater faster than the indexing numbers alone suggest.

This is usually filtering, not a formal manual penalty

Most security-related deindexing happens without any manual action logged against your site at all. This matters practically: fixing the underlying compromise is necessary but, on its own, does not automatically flip pages back into the index. You still have to close the loop with a review request.

Site owners in this exact spot usually try to fix things in a rush and out of order — patch one plugin, delete one spam page, then immediately request a review. That sequence fails often enough that it’s worth doing deliberately instead.

• Step 1 — Read the actual report before touching anything. Note the exact issue type, sample URLs, and detection date.
• Step 2 — Find every compromise point, not just the samples. Google shows examples, not an exhaustive list. Check file-modification timestamps, database entries, cron jobs, and admin user lists by hand.
• Step 3 — Close the entry vector. Patch the vulnerable software, rotate every admin/API/database credential, remove any backdoor or unauthorized admin user.
• Step 4 — Request a review in Search Console. Describe specifically what was found and fixed — vague descriptions slow the process down.
• Step 5 — Expect gradual recovery. Once cleared, Google has to re-crawl affected pages before indexing and ranking fully return — not instantly.

Automated tools check signatures, not behavior

Most security scanners and plugin-based malware checkers compare files against known malicious signatures. That catches a lot of off-the-shelf infections, but structurally misses custom code written specifically for your site, content injected into the database rather than a file, and anything designed to behave differently depending on who’s requesting it.

Cloaked injections are built to fool exactly this kind of check

A redirect or spam page that only triggers for Googlebot’s user-agent string, or only for mobile visitors, will pass a normal browser check and a normal scanner pass — while still being exactly what got the site flagged. Finding these requires deliberately testing the site the way an attacker or Googlebot would encounter it.

Not every indexing problem traces back to Security Issues — if your report is clean but pages still aren’t indexed, the cause is almost always one of these instead.

A noindex tag or robots.txt block, often left over from staging

The single most common cause of unexpected non-indexing. Check the Page Indexing report and the URL Inspection tool — both will state this directly if it’s the cause.

Canonical tags pointing away from the page

If a page’s canonical tag points elsewhere, Google will generally index the canonical target instead, which shows up as “Alternate page with proper canonical tag” rather than anything alarming.

New sites and normal discovery delay

A newly launched site can simply be waiting on initial crawl and discovery — a timing issue, not a fault.

Server errors or slow response during crawl attempts

If Googlebot’s crawl attempts time out or hit 5xx errors, pages can silently fail to get crawled, which looks identical to “not indexed” from the outside but has a completely different fix.