Security Issues recovery

Investigate hacked content, malware, and deceptive pages before requesting a review.

GSC UI required Advanced

A Search Console security issue means Google found evidence that the site was hacked or could harm visitors—for example through malware, harmful downloads, phishing, deceptive content, or compromised pages. Affected results can show warning labels, and browsers can display an interstitial before a visitor reaches the site.

Treat the report as both a user-safety incident and a site compromise until qualified investigation shows otherwise. Removing Google's warning is the last step, not the objective. The objective is to contain harm, find the full scope and entry point, eradicate the cause and persistence, restore trustworthy service, and prevent recurrence.

This guide reflects Google's documentation on July 18, 2026.

Security Issues and Manual Actions are different

Report	Main concern	Typical visible effect	Review path
Security Issues	Harm to users or compromise: hacked content, malware, unwanted software, social engineering	Search warning, browser interstitial, removal or reduced visibility	Request security review in Security Issues after complete remediation
Manual Actions	Human-detected violation of Google Search spam policies	Ranking demotion or omission, often without a browser warning	Request review in Manual Actions after complete remediation

A site can have both. Check the Security Issues report, Manual Actions report, Search Console messages, hosting alerts, and security monitoring rather than assuming one report explains every symptom.

What the Security Issues report contains

The report shows a count of detected issues. Expand each issue to see:

its category and description;
the date Google first detected it;
sample affected URLs when Google can provide them;
issue-specific guidance;
the review action after remediation.

A green check means the report currently lists no security issue. It is not a penetration test, vulnerability scan, or guarantee that no compromise exists.

The first-detected date is not necessarily the attack time. Determine the incident window from your own logs, file history, database audit records, deployments, account activity, CDN or WAF evidence, and provider alerts.

Sample URLs are clues, not the affected set

Google explicitly says the displayed URLs are samples and may not be complete. An issue can appear with no example URLs; that does not mean no page is affected.

Use each sample to identify a pattern:

directory, route, query parameter, host, or subdomain;
CMS template, theme, plug-in, or component;
page creation date and responsible account;
injected script, iframe, redirect, link, or payload signature;
device, user agent, referrer, country, cookie, or time-dependent behavior;
third-party ad, tag, widget, download, or embedded resource.

Then search the entire environment for the same mechanism. Fixing only the examples will not earn a partial return to Search; Google requires the issue to be fixed throughout the site.

Do not investigate unsafe pages casually

Google warns against opening suspected malware pages directly because a browser can expose the investigator's computer. Attackers can also cloak behavior so that the site owner sees a clean page while Google or visitors see the harmful version.

Use your organization's incident-response process and appropriately isolated systems. Depending on the issue and team capability, evidence can come from:

URL Inspection's indexed and rendered view;
controlled HTTP retrieval that varies user agent and referrer;
server, application, authentication, DNS, CDN, WAF, and database logs;
file integrity and malware scanners;
source-control and deployment comparisons;
browser testing in an isolated environment by security personnel;
hosting, CMS, ad-network, and dependency-provider investigations.

Do not paste malicious code, credentials, personal data, or untrusted files into general-purpose collaboration systems. Preserve chain-of-custody and regulatory requirements when they apply.

Classify the issue before cleaning

Hacked content

Hacked content is material placed without authorization after a security vulnerability or account compromise. It can include injected text or links, attacker-created URLs, malicious redirects, or code that behaves differently for Google and users.

Deleting the visible spam is insufficient if the vulnerable plug-in, stolen credential, malicious administrator, scheduled task, web shell, altered template, or database injection remains.

Malware and unwanted software

Google distinguishes web-based malware that can operate without explicit user action from harmful downloads that a user initiates. A site owner can host a flagged binary unintentionally; compromise is not the only possible cause.

Inventory downloads, scripts, service workers, iframes, injected resources, redirects, and third-party distribution paths. Validate that software has clear purpose, informed consent, accurate claims, transparent behavior, and compliance with Google's unwanted-software policies.

Social engineering tricks visitors into dangerous actions such as revealing credentials, calling fraudulent support, or installing software. A page can violate policy by impersonating a trusted entity or presenting a deceptive control or warning.

The harmful content can come from the site's own page, a compromise, or an embedded ad or third-party resource. The host page can be responsible even when the deceptive experience is loaded from elsewhere or appears only after a pop-up, redirect, device condition, or ad rotation.

Deceptive embedded resources and third-party services

Audit advertising, tag managers, images, widgets, payment flows, support tools, downloads, and other embedded content. Rotating ads can require repeated checks across mobile and desktop.

Third-party services should make their operator and relationship to the first-party site clear on every relevant page. A user viewing a page in isolation should understand which site they are using and who operates the service.

Phase 1: Mobilize and contain

Assign an incident lead and bring in the owners needed for hosting, application code, identity, network, security, legal/privacy, communications, and business operations. If the team cannot safely investigate a sophisticated compromise, engage the hosting provider or a qualified incident-response professional.

Containment depends on risk and architecture. Possible actions include:

taking the affected service offline or placing it in controlled maintenance;
disabling compromised accounts, API keys, sessions, integrations, and deployment credentials;
suspending a malicious third-party resource or ad provider;
blocking a confirmed exploit path while preserving evidence;
isolating affected systems from clean systems;
temporarily suppressing attacker-created Search URLs when urgent.

Do not destroy evidence or restore over the affected system before the response team captures what it needs. A hurried restore can erase the only record of the entry point and leave stolen credentials valid.

For sensitive exposure or user harm, follow the organization's legal, privacy, payment, insurance, and notification obligations. Search Console review does not replace them.

Phase 2: Establish scope and root cause

Build a time-bounded incident inventory:

all Security Issues categories and sample URLs;
affected hosts, applications, routes, templates, files, databases, and downloads;
unexpected Search results and attacker-created URL patterns;
new or changed users, owners, verification methods, tokens, keys, and sessions;
deployments, plug-in or package changes, and configuration edits;
file, process, scheduled-task, DNS, and redirect anomalies;
unusual requests, login events, outbound calls, or traffic spikes;
affected personal, authentication, payment, or proprietary data.

Check Search Console ownership and permission settings for unfamiliar users and verification tokens. Also audit identity-provider, hosting, registrar, CDN, CMS, source-control, CI/CD, cloud, and database access. Search Console access is only one control plane.

Determine the most defensible root cause, not merely the first altered file. Examples include an unpatched dependency, reused credential, exposed secret, insecure file permission, vulnerable upload path, compromised workstation, malicious extension, ad-network resource, or insufficiently isolated tenant.

Phase 3: Eradicate the compromise

Use a clean, known-good recovery environment. Depending on the root cause, remediation can include:

rebuilding from a verified clean image or restoring known-good files and data;
removing attacker files, URLs, database rows, redirects, accounts, scripts, and persistence;
patching the exploited platform, CMS, theme, plug-in, dependency, or server;
rotating credentials, keys, secrets, tokens, sessions, and recovery methods from a trusted device;
correcting permissions, upload handling, authentication, network rules, and execution boundaries;
removing or replacing deceptive ads, downloads, embeds, and third-party resources;
eliminating attacker-controlled verification methods and owners;
closing the original exploit path and plausible equivalent paths.

Do not blindly trust a backup because it predates discovery; the compromise may be older. Scan and compare it, and verify that restored versions are patched before exposure.

For attacker-created URLs that should never exist, remove the content and serve 404 or 410. Search Console's Removals tool can provide temporary Search-result containment, but it does not clean the server or make the removal permanent. Avoid blocking healthy pages or the whole site when only malicious paths need suppression.

Phase 4: Recover and harden

Before restoring normal traffic, validate the production-like build and its dependencies. Then deploy with increased monitoring and a rollback path.

Hardening should address the cause and reduce blast radius:

update operating systems, platforms, applications, themes, plug-ins, and dependencies;
remove unused software, accounts, endpoints, and services;
apply least privilege and stronger authentication;
protect secrets and prohibit sharing or hard-coding them;
restrict administrative access and risky file execution;
maintain offline or immutable tested backups;
centralize and protect logs from alteration;
monitor file integrity, unexpected URLs, redirects, downloads, and outbound traffic;
vet third-party content and maintain an owner for every integration;
keep administrative workstations patched and free of malware;
document an incident playbook and recovery contacts.

Google recommends monitoring Search Console messages, the Security Issues report, unexpected site: results, software versions, server configuration, logs, permissions, and common vulnerabilities. These are supporting controls, not a complete security program.

Phase 5: Prove that the site is clean

Test the mechanism, not only the sample URL. A strong validation plan covers:

every issue category shown in Search Console;
all identified URL patterns and affected templates;
clean and newly created representative pages;
mobile and desktop rendering;
anonymous, authenticated, Google-like, referral, and direct-request contexts where relevant;
ad and embed rotation across repeated loads;
redirects, service workers, downloads, scripts, and iframes;
status codes for removed attacker URLs;
account, owner, token, and verification inventories;
server and application logs after recovery;
independent scanning or review appropriate to the risk.

URL Inspection helps compare Google's indexed and live views, but a successful live test does not check security issues or guarantee that warnings will clear. The Security Issues report remains the Google-side source of truth for the reported issue.

If no sample URL is provided, test the whole suspected class and document the evidence. Lack of a reproduction does not justify a review request when unexplained indicators remain.

Submit a useful security review

Request review only after every listed security issue is fixed on every affected page and the fixes are tested. If several categories appear, remediate all of them before submitting.

Google says a good request does three things:

explains the exact issue;
describes the steps taken to fix it;
documents the outcome.

A concise review can follow this structure:

Issue and scope: what Google reported, affected patterns, and what the investigation found.
Root cause: the exploited component, compromised account, harmful resource, or policy problem.
Containment and cleanup: what was isolated, removed, rebuilt, or disabled.
Cause correction: the patch, access change, configuration fix, or provider removal that closes the path.
Validation: which patterns, contexts, scanners, logs, and independent checks are clean.
Prevention: monitoring, patching, permissions, backup, or vendor controls added.

Use concrete dates, systems, and outcomes without including secrets or exploit instructions. If the domain was recently acquired with a pre-existing issue, Google advises fixing it and explaining the acquisition and current compliance in the request.

Review timing and status

Google says most reconsideration reviews take several days or weeks. Search Console sends confirmation after submission and an email when review completes.

Do not resubmit while a review is pending. Google warns that requesting review before the issue is fixed can lengthen later turnaround and may contribute to repeat-offender treatment.

Warning removal can lag because updates must propagate among Google Safe Browsing, browsers, Search, and Search Console. Verify the final decision, Security Issues status, browser warnings, representative Search results, and external monitoring rather than relying on one surface.

If the review is rejected

Treat rejection as evidence that the mechanism or scope is incomplete. Do not simply rewrite the request.

Reopen:

unsampled URLs and neighboring hosts;
backups restored without patching;
persistence and compromised credentials;
conditional behavior and cloaking;
mobile-only or geographic behavior;
rotating ads and third-party resources;
harmful downloads and dormant files;
duplicate deployment environments;
unauthorized owners and verification tokens;
the possibility of more than one root cause.

Expand validation and submit again only after new remediation is complete.

Measure recovery without declaring victory too early

Track:

Security Issues and Safe Browsing status;
browser interstitials and Search warning labels;
unexpected indexed URLs and query themes;
attacker URL status and recrawl behavior;
authentication and administrative events;
file, dependency, configuration, DNS, and redirect changes;
malware, WAF, EDR, CDN, and hosting alerts;
Googlebot and user traffic to compromised paths;
Search clicks, impressions, and page availability after warnings clear.

Traffic can recover later than technical cleanup, and a clean Search Console report does not prove the environment is secure. Close the incident only when the security owner accepts the remediation and sustained monitoring shows no recurrence.

Automation boundary

The Security Issues report and review submission require the Search Console UI. Search Analytics and URL Inspection APIs do not expose security findings or submit reviews. SearchConsole.ai cannot retrieve the report, clear a warning, or certify a site as clean.

Automation can support authorized response work:

monitor known URLs and status codes;
compare deployments and file integrity;
analyze protected logs for suspicious patterns;
inventory dependencies and patch status;
verify expected owners and configuration;
inspect supplied URLs for crawl, robots, canonical, and index state after cleanup.

Keep security evidence in approved systems, minimize sensitive content, and require human incident ownership.

Common mistakes

Treating sample URLs as the full affected set.
Assuming no sample URL means no compromise.
Opening malware pages on a normal workstation.
Deleting injected content without closing the entry point or persistence.
Restoring a backup without proving it is clean and patched.
Forgetting compromised credentials, owners, tokens, or workstations.
Ignoring rotating ads, embeds, downloads, and mobile behavior.
Blocking attacker URLs only in robots.txt or only through temporary Removals.
Requesting review after fixing only some pages or issue categories.
Resubmitting while a review is pending.
Treating URL Inspection success as a security clearance.
Closing the incident when a warning disappears without post-incident monitoring.