Security Issues Report

TL;DR — The Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review. in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. tells you when Google thinks your site has been hacked or is doing something that could hurt visitors — like phishing or spreading malware. It’s a safety warning, not a ranking penalty. You fix the problem, then ask Google to review the site and clear the warning.

What this report is

Open Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. and you’ll find a Security Issues report. Most of the time it says “No issues detected” — which is exactly what you want. When it does show something, Google is telling you one of two things: your site has been hacked, or your site is behaving in a way that could harm the people who visit it.

That second part is the key idea. This report is about user safety, not about whether Google likes your SEO. It’s a completely different thing from a penalty.

What it flags

Google groups problems into three broad buckets, though the actual list of issue types inside them is longer than most people expect:

1. Hacked content — someone broke into your site and added spam, links, or malicious code without your permission.
2. Malware and unwanted software — your site is serving software that could harm a visitor’s device. This isn’t always someone else’s doing — it can happen because of a compromised plugin you installed yourself, not just a hacker.
3. Social engineering — your pages trick people into doing something dangerous, like handing over a password or downloading something they shouldn’t (this is what “phishing” means).

Google’s actual report can show more specific labels within those buckets — things like deceptive pages, harmful or “uncommon” downloads, and unclear mobile billing prompts. The Advanced tab breaks the full current list down.

Where you’ll first notice it

You might see it before you even open Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.:

• A “This site may be hacked” label under your listing in Google’s search results.
• A full red warning page in Chrome — “Deceptive site ahead” — when someone tries to visit. This same warning can show up in other browsers too, because it’s powered by a Google system called Safe Browsing.
• An email from Search Console (if you’ve verified your site there).

What to do

1. Don’t panic, but move fast. The warning is scaring away visitors.
2. Find and remove the bad stuff — the injected spam, the malicious code, the deceptive page. Remember the URLs listed in the report are just examples, not a full list — some issues can show no sample URLs at all, which doesn’t mean nothing is affected.
3. Close the hole it came in through. This is the part people skip. If you just delete the spam but leave the out-of-date plugin or weak password that let it happen, it’ll come right back — and your review will fail.
4. Request a review inside the report once everything is fixed. Google currently says a review can take anywhere from a few days to a few weeks — there’s no fixed one-day or 72-hour guarantee, and a passed review doesn’t mean every browser and search result clears at the exact same moment.

The thing most people get wrong

A security issue is not the same as a manual action. A manual action is when Google’s team decides your site attempted to manipulate its search indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — usually with no visible warning to visitors. A security issue means your site is hacked, hosts deceptive content, or serves malware/unwanted software that could harm a visitor — and it’s the one that can show a warning label or a red browser interstitial. Different report, different review queue, and it’s possible to have one, both, or neither. Want the full current issue list and what “request a review” actually guarantees? Switch to the Advanced tab.

TL;DR — The Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review. flags user-safety problems, not ranking penalties. Google groups them under hacked content (malware, code, content, or URL injection — SQL injection is a common method), malware and unwanted software (which can be installed by a hacker or the site owner), and social engineering (phishing and deceptive content) — but the current report also lists more specific issues like deceptive pages, harmful and “uncommon” downloads, and unclear mobile billing prompts. Sample URLs are examples, not a complete list — some issues show none at all. Warning surfaces are separate signals (a Search label, a Chrome interstitial, a download warning) and don’t always move together — an uncommon-download warning, for instance, can appear in Chrome without removing the page from Search. Fix the vulnerability, not just the symptom, across every affected page, then Request Review once; Google’s current guidance is a few days to a few weeks to process, with no guarantee every browser or search surface clears simultaneously. This is not a manual action: Manual Actions mostly concern search-indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. manipulation (usually no visible warning), while Security Issues concern hacking or user harm (can show labels or interstitialsIn SEO, interstitials are full-page popups or overlays that block the main content of a page. Google demotes pages with intrusive interstitials shown on the transition from a search click — a page-level signal, with legal gates, login walls, and small dismissible banners exempted.) — separate reports, separate review queues, and they can overlap.

What the report actually is

The Security Issues report sits in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. alongside the performance, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and enhancement reports. Google’s framing is about user safety, and that single fact is the most useful mental model on this page. As Google puts it in its description of the difference from manual actions, the report “lists indications that your site was hacked, or behavior on your site that could potentially harm a visitor or their computer.” It is not a verdict on your SEO.

The issue categories Google flags

Google groups everything under three top-level headings in its own documentation, but that’s an organizing frame, not the full list of issue types the report can actually show you. Treat the three headings below as buckets, and the current issue list beneath them as what to expect in practice.

1. Hacked content. Google’s own definition: “This is any content placed on your site without your permission because of security vulnerabilities in your site.” The current report can flag several specific issues under this heading, including:

• Code injection — “A hacker has compromised your site and is injecting malicious code in your pages.”
• Content injection — “A hacker has added spammy links or text to your site’s pages.”
• URL injection — “A hacker has created new pages on your site, often containing spammy words or links.”
• Hacked malware — malicious code or files placed on the site through the same kind of unauthorized access as the injection types above.

SQL injection is the common method behind these — a hacker exploits a database query vulnerability to insert content or code. The labels above are what the report shows you; SQL injection is one of the ways the attacker got in.

2. Malware and unwanted software. Google distinguishes the two. Malware is “any software or mobile application specifically designed to harm a computer, a mobile device, the software it’s running, or its users.” Unwanted software is “an executable file or mobile application that engages in behavior that is deceptive, unexpected, or that negatively affects the user’s browsing or computing experience.” Importantly, this category isn’t only a third-party hack: malware or unwanted software on a site can be installed by a hacker or by the site owner (most often unknowingly, via a compromised plugin, theme, or ad script). The report also separates:

• Harmful downloads — files Google Safe Browsing believes are malware or unwanted software that a visitor is prompted to download.
• Uncommon downloads — a download Safe Browsing simply hasn’t seen enough of to vouch for yet; this can trigger a Chrome download warning even though the page itself isn’t necessarily malicious (more on the warning-surface distinction below).

Confirm the exact current label wording against your own report — Google has adjusted these labels over time.

3. Social engineering. Google: “A social engineering attack is when a web user is tricked into doing something dangerous online.” Sub-types include:

• Phishing — “The site tricks users into revealing their personal information (for example, passwords, phone numbers, or social security numbers).” Google’s current report can also flag suspected phishing pages detected specifically around login flows.
• Deceptive content / deceptive pages — content that tries to trick you into doing something you’d only do for a trusted entity, such as sharing a password, calling tech support, or downloading software — including deceptive embedded resources (ads or widgets) on an otherwise legitimate page.
• Unclear mobile billing — a subscription or billing flow, usually on mobile, that doesn’t clearly disclose price or terms before charging the user.

Operating a site on behalf of another party without making that relationship clear can also be flagged as social engineering — worth knowing if you run white-label or affiliate pages.

Where the warning shows up — and why Safe Browsing matters

Affected pages don’t just sink in rankings. Google: “Pages or sites affected by a security issue can appear with a warning label in search results or an interstitial warning page in the browser when a user tries to visit them.”

Two surfaces, then:

• In Search, hacked sites can show a “This site may be hacked” label under the result.
• In the browser, Chrome may show a full-page interstitial. Google: “If Google detects that your website contains social engineering content, the Chrome browser may display a ‘Deceptive site ahead’ warning when visitors view your site.” Malware triggers a similar “the site ahead contains malware” interstitial.

The browser warnings are powered by Google Safe Browsing, and that’s the part people miss. Firefox, Safari, and other browsers consume the Safe Browsing API, so the red warning can appear across browsers — not just in Chrome, and not only via Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance..

Don’t assume every issue type produces every warning, or that surfaces move in lockstep. Search warning labels, browser interstitialsIn SEO, interstitials are full-page popups or overlays that block the main content of a page. Google demotes pages with intrusive interstitials shown on the transition from a search click — a page-level signal, with legal gates, login walls, and small dismissible banners exempted., Chrome’s download warnings, and whether a page can appear in Search at all are separate, independently-updated signals. A good example: an uncommon-download warning can show up as a Chrome download prompt without necessarily preventing the page itself from appearing in Google Search — it’s not the same as a full interstitial or a de-indexing. Because these surfaces update independently, and Safe Browsing behavior can also depend on browsing context, treat the Security Issues report itself as the authoritative record of what Google has recorded and fixed for your site — don’t assume a warning you personally can’t reproduce in one browser means nothing is wrong, and don’t assume clearing the report means every consuming browser or product has caught up yet.

Security Issues vs. Manual Actions

This is the distinction that trips up the most people, so let’s use Google’s own boundary rather than a simplified cause split.

They are separate reports with separate review queues — a site can have one, both, or neither, and it’s possible for the two to overlap (a hacked page that gets stuffed with spammy links, for example, could eventually surface in both reports). Don’t reduce this to “someone else hacked me” versus “I did my own spam” — the real dividing line Google draws is what the report is protecting against (users, versus the integrity of the search index), not who caused it.

Triage and remediation

Front-load the triage; understand the categories second.

1. Confirm it in the report. Read exactly which category and which sample URLs Google lists — but treat those URLs as examples, not a full inventory. Google is explicit that the list isn’t necessarily complete, and some issues can show no sample URLs at all, which doesn’t mean nothing is affected. Use URL Inspection on the samples to see what Google actually fetched, then look for the same vulnerability or injected pattern elsewhere on the site.
2. Limit the damage. Depending on severity, take the site (or the affected section) offline or behind maintenance mode503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. so you stop serving malware or phishing to real users while you work. Avoid directly opening a suspected infected page in a normal browser — some attacks cloak content based on browsing context, so what you see may not match what Google recorded; use isolated tooling (a scanner, a sandboxed environment, or URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.) instead.
3. Find and remove the injected content. Spam pages, injected scripts, rogue admin accounts, modified core files.
4. Close the vulnerability. This is the step that decides whether your review passes. Patch the out-of-date plugin/CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms., rotate credentials, fix the insecure directory or the input that allowed the injection. Remove the symptom and the entry point, or you get reinfected and the review fails.
5. Handle the leftover indexed URLs. Injected spam pages that got indexed should return 404 or 410 so Google drops them over time (410 is a touch faster as a signal). Don’t leave them resolving with a 200.
6. CMS notes. On WordPress, the usual suspects are outdated plugins/themes and weak admin credentials — update everything, audit users, and consider a security plugin scan. On other stacks, the principle is identical even if the tooling isn’t: patch, rotate, and close the input that was exploited.

Requesting a security review

Once every flagged issue is fixed across all pages, use Request Review in the report. Google: “When all issues listed in the report are fixed in all pages, select Request Review in the Security Issues report.”

Document what you did. Google asks you to “provide more information on what you did to clean your site. For each category of hacked spam, include a brief explanation of how the site was cleaned.” Google’s own example of good wording: “For Content injection hacked URLs, I removed the spam content and corrected the vulnerability by updating an out-of-date plugin.” Note how it names both the cleanup and the closed hole.

On timing: Google’s current guidance is that a security review can take anywhere from a few days to a few weeks to process. Earlier guidance (published separately from the report’s own documentation) broke this down by issue type — phishing faster, hacked-spam cases slower — and promised warnings clear within 72 hours of approval. That per-type breakdown and the fixed 72-hour figure are not what the report’s current documentation states, so treat them as outdated rather than a schedule you can rely on. What’s consistent: the warning does not disappear the instant you fix things — it clears only after the review passes, and even then propagation across every browser, search result, and Google product isn’t instant or guaranteed to happen at the same moment everywhere. A passed review also isn’t a promise of restored rankings, traffic, or AI-search visibility — those are separate outcomes the review process doesn’t cover.

A few rules of the road: submit once, fully fixed and documented — re-submitting before you’ve actually closed everything just wastes a review cycle. Don’t set a hard internal deadline around a specific number of hours or days; monitor the report and your site’s status instead of repeatedly resubmitting.

Preventing reinfection

The cleanup is only half the job. Keep CMS core, plugins, and themes patched; enforce least-privilege on accounts and rotate any credentials that may have leaked; turn on 2FA for admin logins; monitor for unexpected new files or users; and periodically check your site’s status in Google’s Safe Browsing site-status tool. The vulnerability that let them in the first time is the one they’ll try again.

AI summary

A condensed take on the Advanced version:

• The report is about user safety, not rankings. It flags that your site was hacked or hosts content/behavior that could harm visitors — a different animal from a ranking penalty.
• More than three simple buckets. Google groups issues under hacked content, malware & unwanted software, and social engineering, but the current report can show more specific labels — code/content/URL injection, deceptive pages, harmful and uncommon downloads, unclear mobile billing, and suspected phishing around login flows. Malware or unwanted software can be installed by a hacker or the site owner (often unknowingly).
• Sample URLs are examples, not a full list. Some issues can show none at all — that doesn’t mean nothing’s affected. Investigate the shared vulnerability, not just the listed samples.
• Warning surfaces are separate, independently-updated signals. A Search label, a Chrome interstitial, and a download warning don’t always move together — an uncommon-download warning, for example, can appear without removing the page from Search. Treat the report itself as the source of truth for what Google has recorded.
• Not a manual action. Manual Actions mostly concern search-indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. manipulation, usually with no visible warning; Security Issues concern hacking or user harm and can show labels or interstitialsIn SEO, interstitials are full-page popups or overlays that block the main content of a page. Google demotes pages with intrusive interstitials shown on the transition from a search click — a page-level signal, with legal gates, login walls, and small dismissible banners exempted.. Separate reports, separate review queues — and they can overlap.
• Fix the vulnerability, not just the symptom. Remove injected content and close the entry point across every page, or you get reinfected and the review fails. Return 404/410 on leftover indexed spam URLs.
• Request Review once, fully fixed, with per-category notes on what you cleaned and how you closed the hole.
• Timing: current guidance is a few days to a few weeks to process — not the older per-type or 72-hour promises. A passed review doesn’t guarantee every browser/product clears simultaneously or that rankings, traffic, or AI-search visibility recover.

Official documentation

Primary-source documentation from Google.

Google

• Security Issues report — the report itself: categories, hacked-content subtypes, and the Request Review flow.
• Manual Actions report — the separate report, with the section explaining how it differs from security issues.
• Social Engineering (Phishing and Deceptive Sites) — phishing, deceptive content, and the “Deceptive site ahead” warning.
• Malware and unwanted software — the definitions Google uses to separate the two.
• Why is my site labeled as dangerous in Google Search? — the user-facing explanation of the warnings.
• Request a review (web.dev / Search Central) — what to document per category, example wording, and the per-type review timelines.

Quotes from the source

On-the-record statements from Google’s documentation. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what the report covers

• “This is any content placed on your site without your permission because of security vulnerabilities in your site.” (Hacked content) Jump to quote
• “This is software that is designed to harm a device or its users, that engages in deceptive or unexpected practices, or that negatively affects the user.” (Malware and unwanted software) Jump to quote
• “This is content that tricks visitors into doing something dangerous, such as revealing confidential information or downloading software.” (Social engineering) Jump to quote

Google — hacked-content subtypes

• “A hacker has compromised your site and is injecting malicious code in your pages.” (Code injection) Jump to quote
• “A hacker has added spammy links or text to your site’s pages.” (Content injection) Jump to quote
• “A hacker has created new pages on your site, often containing spammy words or links.” (URL injection) Jump to quote

Google — how users see the warning

• “Pages or sites affected by a security issue can appear with a warning label in search results or an interstitial warning page in the browser when a user tries to visit them.” Jump to quote
• “If Google detects that your website contains social engineering content, the Chrome browser may display a ‘Deceptive site ahead’ warning when visitors view your site.” Jump to quote

Google — malware vs. unwanted software

• “Malware is any software or mobile application specifically designed to harm a computer, a mobile device, the software it’s running, or its users.” Jump to quote
• “Unwanted software is an executable file or mobile application that engages in behavior that is deceptive, unexpected, or that negatively affects the user’s browsing or computing experience.” Jump to quote

Google — social engineering / phishing

• “A social engineering attack is when a web user is tricked into doing something dangerous online.” Jump to quote
• “The site tricks users into revealing their personal information (for example, passwords, phone numbers, or social security numbers).” (Phishing) Jump to quote

Google — requesting a review

• “When all issues listed in the report are fixed in all pages, select Request Review in the Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review..” Jump to quote
• “For each category of hacked spam, include a brief explanation of how the site was cleaned.” Jump to quote
• “For Content injection hacked URLs, I removed the spam content and corrected the vulnerability by updating an out-of-date plugin.” (Google’s example wording) Jump to quote
• “A review can take several days to complete.” (Google, Search Central, Social Engineering (Phishing and Deceptive Sites)) — source

Google — Security Issues vs. Manual Actions

• “The Security Issues report lists indications that your site was hacked, or behavior on your site that could potentially harm a visitor or their computer: for example, phishing attacks or installing malware or unwanted software on the user’s computer.” Jump to quote

Clean-up and request-review checklist

A pass to take you from “flagged” to “cleared.”

Clean up

• Read the report and note the exact category and the sample URLs Google lists — treat them as examples, not a complete inventory (some issues list none).
• Inspect the sample URLs (URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.) to see what Google actually fetched, then search for the same pattern elsewhere on the site.
• Take the affected site/section offline or into maintenance mode503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. if it’s actively serving malware or phishing.
• Remove injected content: spam pages, scripts, rogue files, unknown admin users.
• Close the vulnerability — patch the CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./plugin/theme, rotate credentials, fix the exploited input or insecure directory. (Symptom and entry point.)
• Return 404 or 410 on injected URLs that got indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. so Google drops them.
• Re-scan to confirm nothing is left, then verify your status in Google’s Safe Browsing site-status tool.

Request review

• Confirm every listed issue is fixed across all affected pages first.
• Click Request Review in the Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review..
• For each category, write a brief explanation of what you removed and how you closed the hole (mirror Google’s example wording).
• Submit once — don’t re-submit before you’ve actually fixed everything.
• Set expectations on timing: Google’s current guidance is a few days to a few weeks to process — not a fixed one-day or 72-hour promise — and clearing doesn’t guarantee every browser/product updates at the same moment or that rankings/traffic recover.

Security Issues — cheat sheet

The report’s groupings (not an exhaustive list)

Sample URLs listed under any category are examples, not a full inventory — some issues can list none at all.

Where the warning appears

Surfaces update independently — clearing one does not guarantee the others have caught up yet.

Review timelines

(Older per-type figures — phishing ~1 day, malware ~days, spam hacks up to weeks — and a universal “72 hours after approval” clearance line are outdated; don’t quote them as current.)

Status codes for leftover spam URLs

• 404 / 410 — gone; drops from index over time (410 a touch faster).
• 200 on injected spam — bad; leave it and the URL stays indexed.

The mental models

1. Safety, not ranking. A security issue answers “is this site dangerous to visit?” — not “is this site’s SEO acceptable?” Reach for the user-safety frame first; it tells you who’s affected (your visitors) and what clears it (a fix + a review, not a ranking appeal).

2. Symptom vs. entry point. Every cleanup has two halves: the symptom (the injected spam, the malicious script, the phishing page) and the entry point (the unpatched plugin, the weak credential, the unsanitized input). Fix only the symptom and you get reinfected and fail the review. Always close both.

3. Separate surfaces, not one dial. A Search label, a browser interstitial, and a Chrome download warning are independently-updated signals — an uncommon-download warning can appear without blocking Search. Don’t assume “I don’t use Chrome” or “the report looks clean” means every surface has cleared; treat the Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review. as the source of truth for what Google has recorded and fixed.

4. Which report am I in? Before you plan a fix, name the report. Security Issues → hacking or user harm, fixed by cleanup + security review, can show a warning. A manual action → an attempt to manipulate the search indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., fixed by changing the offending SEO + reconsideration, usually shows no warning at all. They can overlap, so check both reports rather than assuming it’s one or the other.

5. Submit once, and don’t expect a guarantee. Treat the review as a single shot per fix: fully clean, fully documented, per category. Re-submitting before you’ve actually closed everything wastes the cycle — and a passed review clears the report’s finding, not necessarily your rankings, traffic, or every browser’s warning at the same instant.

Tools for diagnosing and clearing a security issue

• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review. — the source of truth: the category, the sample URLs, and the Request Review button.
• URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (GSC) — check what Google actually fetched and rendered for a flagged sample URL.
• Google Safe Browsing site-status check — see whether Safe Browsing still flags your domain, independent of Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance..
• A malware/site scanner — Sucuri SiteCheck and similar remote scanners help locate injected content; on WordPress, security plugins (e.g. Wordfence) scan core, plugins, and themes for modifications.
• Server access and logs — file diffs, recent-modified-file lists, and access logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened. help you find what was changed and how the attacker got in.
• Your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms.’s update and user-management screens — patch everything and audit accounts; closing the entry point is the part that makes the review pass.

Prove a security cleanup is ready for review

Test every flagged category and sample

• Test to run: Open each category in the Security Issues reportA Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review., inventory its sample URLs, and inspect the live and rendered response for every sample after remediation.
• Expected result: Injected content, deceptive elements, malicious downloads, and unauthorized redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. are absent from every sampled URL and the surrounding template.
• Failure interpretation: The cleanup missed a file, database entry, template, user-generated payload, or conditional delivery path.
• Monitoring window: Immediate after caches are cleared and the cleaned version is deployed.
• Rollback trigger: Do not restore the compromised release; roll back only a cleanup change that breaks legitimate site behavior, then replace it with a safe fix before requesting review.

Test the entry point is closed

• Test to run: Patch the vulnerable component, rotate compromised credentials, audit privileged users, and review server or application logs for renewed access.
• Expected result: The vulnerable version is gone, unauthorized accounts and keys are disabled, and no matching compromise activity appears after the fix.
• Failure interpretation: The attacker still has a viable path or persistence mechanism, so cleaning visible payloads alone will not hold.
• Monitoring window: Check immediately, then watch logs continuously through the review period.
• Rollback trigger: Halt the review request and isolate the affected system if the same exploit, account, or payload reappears.

Test external warning state before and after review

• Test to run: Check the domain in Google Safe Browsing’s site-status tool and compare it with the Security Issues report after submitting one complete review.
• Expected result: The Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. review passes and external browser or Search warnings clear after Google reprocesses the site.
• Failure interpretation: Google still detects unsafe behavior, another category remains unresolved, or warning systems have not refreshed yet.
• Monitoring window: Google’s current guidance is a few days to a few weeks; keep the cleaned site stable and monitor rather than repeatedly resubmitting.
• Rollback trigger: If warnings return after clearing, treat it as reinfection, isolate the site, and reopen incident response instead of filing another unchanged review.

Resources worth your time

From Google

• Security Issues report — the canonical reference for categories and the review flow.
• Request a review — the per-category documentation guidance and review timelines.
• Social Engineering (Phishing and Deceptive Sites) and Malware and unwanted software — the deep definitions.

From others

• MalCare — Google Search Console Security Issues: 10 ways to fix them — WordPress/plugin-leaning remediation walkthrough.
• SEOZoom — Guide to the GSC Security Issue report — a second perspective on triage.
• Google Safe Browsing site status — check whether Safe Browsing still flags your domain independently of what Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. shows.
• Search Engine Land — Google’s Mueller on hacked content and site recovery — context on how Google handles hacked pages returning 404 and dropping from the indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..
• Search Engine Roundtable — GSC manual-action review details (Mueller) — background on how review submissions are processed; useful for understanding the review-queue distinction between security issues and manual actions.
• r/TechSEO — the community for working through hacked-site recovery in real time.

Test yourself: Search Console security issues

Five quick questions on diagnosis, cleanup, and review. Pick an answer for each, then check your result.

Security Issues report

A Google Search Console report that flags signs your site was hacked or hosts content that could harm visitors — phishing, malware, or unwanted software. It's a user-safety flag, not a spam-policy penalty, and you clear it by fixing the problem and requesting a security review.

Related: Google Search Console

Security Issues report

The Security Issues report in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. surfaces signals that a site has been hacked, or that it behaves in ways that could harm visitors or their devices. Google groups what it finds into three buckets: hacked content (malicious code or spam injected because of a vulnerability), malware and unwanted software, and social engineering (phishing and other deceptive content).

The most important thing to understand is what kind of problem this is. A security issue is usually the result of a third-party compromise or deceptive content — not a ranking penalty applied by Google’s webspam team. That makes it a different animal from a manual action: separate report, separate cause, separate review queue.

Affected pages can show a warning label in search results (“This site may be hacked”) or trigger a full-page interstitial in Chrome and other browsers that consume Google’s Safe Browsing API (“Deceptive site ahead”). You clear the issue by fixing the underlying problem across every affected page, then submitting a security review from inside the report — at which point Google reviews your site and, on approval, removes the warnings.

Related: Google Search Console

Changelog