Flagged by Google Safe Browsing? What to do step by step

The first sign is usually a customer's screenshot: a full-screen red page saying the site ahead contains malware or is deceptive, with your domain underneath it. A Google Safe Browsing warning stops nearly all of your traffic instantly, because the warning appears in Chrome, and other browsers use the same data. It is alarming, and it is recoverable, but only if you work in the right order.

That order is: confirm what you have been flagged for, contain the damage, find the actual infection, clean it including the way in, and only then ask for a review. Requesting a review on a site that is still compromised wastes days.

What the warning means and where it appears

Safe Browsing is Google's list of pages known to host malicious or deceptive content. Being on it affects far more than Chrome users:

• Browsers show an interstitial warning before the page loads, which most visitors will not click past.
• Search results may carry a note that the site may be hacked or may harm your computer.
• Google Ads campaigns pointing at the domain are typically disapproved.
• Links shared in some messaging and social platforms may be blocked or carry a warning.

The warnings come in a few flavours, and the wording tells you the category: malicious software, deceptive or phishing content, unwanted software, or uncommon downloads. The category narrows where to look. A deceptive-content flag often means injected phishing pages in a subdirectory; a malware flag often means injected scripts serving something nasty to visitors.

Confirm it in Search Console, not by guessing

Log in to Google Search Console for the property and open the Security Issues report. It tells you the category, and usually lists sample URLs where the problem was detected. Those samples are the fastest route to the infection.

If the site is not yet verified in Search Console, verify it now. You will need it to request the review later, and verification through DNS or a file upload takes a few minutes.

Check the Google Transparency Report's Safe Browsing site status page as well for an outside view of your domain. Also check your Google Ads account, since a separate policy notice there needs its own resolution.

One caution: do not browse your own infected site casually, especially not while logged in as an administrator. Many infections serve different content to administrators, to search engine crawlers and to first-time visitors from search.

Contain the damage before you start digging

Take a snapshot of the current state first, including files and database, and store it separately. You may need it to understand what happened, and restoring over it would destroy the evidence.

Then reduce exposure: put the site into maintenance mode if you can, pause paid campaigns, and tell your host that you suspect a compromise, because they may already have scan results or server logs that shorten the search.

Change the passwords that matter, and do it from a clean machine: hosting panel, administrator accounts, database user, FTP and SSH, and any API keys stored in the site's configuration. If credentials were stolen, cleaning files without rotating them just invites the attacker straight back.

Finding the infection

Start with recently modified files

List files by modification time across the web root. An injection almost always leaves a cluster of files changed on a date nobody deployed anything. Pay attention to unexpected files in upload directories, which should contain media rather than scripts.

Look where injections hide

Common places are theme header and footer templates, the main index file, configuration files, and database records holding site-wide options or widget content. Redirect rules inserted into the server configuration file are another favourite, often written to trigger only for visitors arriving from search results.

Check for persistence

Look for administrator accounts you do not recognise, scheduled jobs that were not created by you, and additional files that re-create the infection after you delete it. A cleanup that misses a backdoor gets undone within hours.

Compare against something known good

For platform files, reinstalling core files from an official source replaces anything altered. Comparing your files with a clean copy of the same version highlights what does not belong far faster than reading code.

Identify the way in

Usually it is an outdated plugin, theme or core version with a known vulnerability, a weak or reused administrator password, or stolen hosting credentials. Server access logs around the first modified file will often show the request that started it.

Cleaning properly rather than deleting symptoms

If you have a backup from before the infection, restoring it is usually faster and safer than hand-cleaning. Restore it to a staging environment, apply every pending update, change all credentials, then bring it live. Remember that a restore also rolls back legitimate recent data, so plan how to re-enter orders or content from the gap.

Where hand-cleaning is the only option, work methodically: remove the injected code, delete unrecognised files, remove unknown accounts and scheduled jobs, update the platform and every extension, and delete plugins and themes you do not use at all rather than leaving them deactivated.

Finally, view the site as a first-time visitor would, from a different network and browser, and from a search result rather than by typing the address. Then recheck twenty-four hours later, because reinfection shows up quickly if a backdoor survived.

Requesting the review and what happens next

Only when you are confident the site is clean, return to the Security Issues report in Search Console and request a review. You will be asked to describe what you did, so write a few specific lines: what was found, what was removed, what was updated, and which credentials were rotated. A vague description is more likely to be rejected.

Review times vary. It is often a matter of days, and sometimes faster for straightforward malware cases than for deceptive-content flags. Do not submit repeatedly; multiple requests do not speed it up.

If the review fails, the report will usually indicate that problems remain. That nearly always means a backdoor or an injected record you missed rather than a mistake on Google's side, so go back to the search rather than resubmitting.

Handle related systems separately. An Ads policy issue, a hosting suspension and any email delivery problems each need their own resolution even after the browser warning clears.

Harden the site so it does not happen again

Once the warning is gone, spend an afternoon on prevention. Keep the platform, plugins and themes updated on a schedule rather than when you remember. Remove anything unused. Enable two-factor authentication on administrator accounts, and give staff the lowest role that lets them do their job. Disable in-browser file editing if your platform offers it, restrict what can execute inside upload directories, and take backups to a location the web server cannot write to.

If your site was compromised through an old platform version that cannot easily be updated, the honest answer may be a rebuild on something maintainable. Our team handles cleanup and hardening through the support desk, and can advise whether a rebuild under website development is more sensible than repeatedly patching an outdated install.

Frequently asked questions

How long does it take for the warning to disappear after a review?

Once the review passes, the warning is generally removed within a short time, often hours. Visitors who saw the warning earlier may need to reload, and cached copies in some places take a little longer to catch up.

Will my search rankings recover?

Usually yes, though not always instantly. Traffic typically returns as pages are recrawled. Longer infections cause more disruption, which is a practical reason to detect and fix quickly rather than waiting to see whether it matters.

My host suspended my account. Do I fix that first?

You will generally need to work with your host to get access for the cleanup, and they often require a clean scan before restoring service. Treat the host's process and the Google review as two separate tasks running in parallel.

Can I just delete the flagged pages and request a review?

Deleting the visible pages without finding the entry point almost always leads to a failed review or a fresh infection. The flagged URLs are the symptom; the vulnerability and any backdoor are the problem.