Google Safe Browsing: check your site and clear a flag

Google Safe Browsing is Google's list of sites that host malware, phishing or unwanted software. Chrome, Firefox and Safari check it, and a listed site gets a full-page red warning such as "Deceptive site ahead" that almost nobody clicks through. To check your site, look it up on Google's Safe Browsing site status page or in Search Console's Security issues report. To clear a flag, find and remove the cause, close the way in, then request a review; the warning comes off when Google re-checks and finds the cause gone. Most flagged small sites were hacked, so this guide is one part of how to tell if your website is hacked. Plan a day for a simple case; a hacked site takes longer.

Quick answer

• Check the status: Google's Safe Browsing site status page (Transparency Report) for anyone, and Search Console → Security & Manual Actions → Security issues for owners, with sample URLs.
• Find the cause before touching the review button: a hack injecting redirects or downloads, a phishing page uploaded to your hosting, a compromised third-party script, a flagged download or a forgotten subdomain.
• Clean everything, not only the sample URLs, and close the door the attacker used. Then check with the hacked-site checker and from a different network.
• Request a review in the Security issues report with a short, specific description of what you found and fixed.
• A rejected review means the cause is still there. Look again rather than resubmitting.

What a Safe Browsing flag means

Google Safe Browsing is a list of URLs and sites Google considers dangerous (Safe Browsing in brief). Chrome checks it, and so do Firefox and Safari, so one listing reaches most of the world's browsers at once. The warning text depends on the browser, its version and the category:

• Social engineering (phishing): pages that trick visitors into entering passwords or card details, or into installing something, often impersonating a bank or a well-known brand. Chrome has headed this warning "Deceptive site ahead".
• Malware: pages that try to install malicious software, often through an injected script or a redirect to an exploit site. Chrome's heading for it was "The site ahead contains malware".
• Unwanted software: downloads that change browser settings or bundle extras the visitor did not ask for. This is the warning that reads "The site ahead contains harmful programs", a variant of the same Safe Browsing flag with the same cleanup and review.

Current Chrome versions use one heading, "Dangerous site", for all three, and the paragraph under it names the category: phishing, malware or harmful software. Older browsers and screenshots still show the headings above.

Search shows the consequences too: the Security issues report lists the problem, results can carry "This site may be hacked" or "This site may harm your computer" under your listing, and Search Console owners get an email. This site may be hacked covers that search label, which can appear without a browser warning.

"Google blacklist" is the everyday name for this list. Other lists exist: Microsoft Defender SmartScreen protects Edge and Windows, antivirus vendors keep their own, and email blocklists such as Spamhaus track mail servers, not websites. They are separate, each with its own review process, but a cleanup that satisfies Google usually satisfies them too.

Most flagged small sites did nothing wrong on purpose. Someone else used the site: a hack, a stolen hosting password, a compromised ad or widget.

How getReport checks it

The hacked-site checker fetches the page three ways: with getReport's normal user agent, with Googlebot's user agent, and as a browser arriving from a Google search result. It compares the visible text, the outbound links and the inline scripts of the three copies. That is where injected spam and conditional redirects show up, because they are built to hide from the site owner.

The Safe Browsing lookup itself is a separate check. It would ask Google's Web Risk API, the commercial interface to the same lists, whether your URL is listed:

The checker also fetches from getReport's servers with Googlebot's user agent, not from Google's addresses. Injections that verify the visitor's IP address will show it a clean page; Search Console's URL Inspection, which fetches as the real Googlebot, sees them.

How to clear a Google Safe Browsing warning

1. Confirm the flag and read the samples

In Search Console, open Security & Manual Actions → Security issues. The report names the issue type (hacked content, malware, social engineering, unwanted software) and lists sample URLs. Use a Domain property if you can: it covers every subdomain and both protocols, and an old shop. or test. subdomain is a common source.

Then look the site up on Google's Safe Browsing site status page (search for "Google Transparency Report Safe Browsing site status"). It shows the current status to anyone, which helps before you have Search Console access.

2. Find the cause

Match the issue type to the usual causes:

• Hacked content or malware on your pages. An injected script, a redirect that fires only for visitors from Google or on phones, or files that serve downloads. The checker's fetch comparison and redirect findings show the first two; hacked website redirects covers where redirect code hides.
• A phishing page on your hosting. Attackers upload a fake login page for a bank or mail provider into a forgotten folder (/wp-content/uploads/, /.well-known/, an old test directory). Your own pages look normal; the sample URLs point at it.
• A compromised third-party script. An ad network, a chat widget or a script loaded from a domain that expired and was bought by someone else. The hack is not in your files; the browser's Network tab shows the request.
• A flagged download. A PDF, installer or ZIP on your site that Google classifies as unwanted software.
• A subdomain you forgot. An old campaign site or staging copy running outdated software.

Look at the sample URLs from a clean device on a different network (a phone on mobile data). Some injections skip visitors whose IP address has already seen them, or known admin IPs.

3. Clean in the right order

1. Copy the site as it is, files and database, for evidence. Never restore it later.
2. Remove the cause everywhere, not only on the sample URLs. For WordPress, follow how to fix a hacked WordPress site.
3. Close the door. Update the CMS, themes and plugins, delete unused ones, change every password (hosting, SFTP, database, CMS admins) and remove admin accounts you do not recognise. Without this, the site is reinfected within days.
4. Remove or replace the third party if it was the source.
5. Fix mixed content. A script loaded over plain http:// can be swapped by anyone on the network path.

To list what the page loads over http://:

# Lists every http:// src or href in the page's HTML
curl -s https://www.example.com/ | grep -oE '(src|href)="http://[^"]+"' | sort -u

4. Check before you ask

Run the hacked-site checker on the home page and on every sample URL. The three columns should agree: same links, no hidden links, no spam vocabulary, no redirect script. In Search Console, run URL Inspection → Test live URL on the same pages and read the crawled HTML. Only then request the review.

5. Request the review

In the Security issues report, tick "I have fixed these issues" and choose Request review. Describe what you found and changed in two or three plain sentences:

The site was hacked through an outdated form plugin (version 2.1). An injected
script in the theme's footer.php redirected visitors from Google to a pharmacy
site, and 214 spam pages were created under /wp-content/uploads/cache/.
We removed the script and the pages, updated WordPress, the theme and all
plugins, deleted two unknown admin accounts and changed all passwords.

Google's Security issues report help gives rough review times: about a day for phishing, a few days for malware, and up to several weeks for hacked content with spam. When the review passes, the browser warnings and the search label go away on their own.

If the review is rejected, the cause is still there, often a second backdoor or a page you did not look at. Go back to step 2. Sites cleaned and reinfected again and again can be classed as repeat offenders and must wait before requesting another review.

6. If you think it is a false positive

A legitimate download (a desktop app, a browser extension installer, a ZIP of scripts) or a page that looks like another service's login form can be flagged when nothing is wrong. Request the review anyway and explain what the file or page is, who publishes it and why it is safe. Sign installers, host them on a domain you control and remove files nobody needs.

Platform notes

WordPress. Most flags come from a hack through an outdated or vulnerable plugin, and most rejected reviews from a missed backdoor: a PHP file in wp-content/uploads/, a must-use plugin, an extra admin user or code in wp-config.php.

Shopify, Wix and other hosted platforms. The platform patches its own software, so look at what was added on top: an app or embed that loads a compromised script, or a flagged file in the platform's file storage.

Static sites. Look at what they include: third-party scripts, and a CDN or storage bucket someone else can write to. A bucket with public write access is enough to serve malware from your hostname.

Verify

• Search Console's Security issues report shows no issues, and the review reads as approved.
• The Safe Browsing site status page shows no unsafe content for your domain.
• The hacked-site checker shows the three fetches agreeing on the home page and the former sample URLs, and the mixed-content finding passes.
• Chrome on a phone on mobile data opens the site without a warning. Keep checking weekly for a month; continuous monitoring with alerts is a funded unlock on getReport's roadmap, not something the site does yet.

Common mistakes

• Requesting a review before cleaning. It fails, and repeated failures delay the next one.
• Cleaning the home page only. Google flagged specific URLs, and injections usually sit in many places.
• Ignoring subdomains and old test sites. The flag can come from old.example.com while you clean www.
• Restoring a backup that contains the infection. Restore from before the first symptom, then update everything before going live.
• Blocking Googlebot to hide the problem. A robots.txt block or firewall rule stops Google re-checking the site, so the flag cannot come off.

Questions people ask

What is Google Safe Browsing?

It is Google's service that keeps a list of unsafe websites: pages with malware, phishing or unwanted software. Chrome, Firefox and Safari check the sites people visit against it and show a full-page warning for listed ones. Site owners see the same data in Search Console's Security issues report, and developers can query it through Google's APIs.

How long does a Safe Browsing review take?

Google's help pages give rough times: about a day for phishing, a few days for malware, and up to several weeks for sites hacked with spam. The warning disappears once the review passes. A rejected review means Google still found the problem, so look for a second backdoor before asking again, because repeated failures can add a waiting period.

Do other browsers and security tools keep their own blacklists?

Yes. Microsoft Defender SmartScreen protects Edge and Windows, and antivirus vendors run their own website ratings, each with a separate dispute form. Firefox and Safari use Google's list, so one clean review covers them. After the Google review passes, check the other services that flagged you and request a re-review where they still warn.

Can a third-party script get my site flagged?

Yes. If an ad network, widget or script you load from another domain starts serving malware or redirects, Google flags your pages because that is where visitors meet it. The same happens when a script domain expires and someone else buys it. Remove or replace the script, then request a review explaining where the code came from.