Google Safe Browsing Check: Is Your Website Flagged?

What does a Google Safe Browsing check look for?

Safe Browsing is a set of lists that Google maintains for unsafe web resources. Chrome, Safari, Firefox, Vivaldi and Brave use them to warn people before a page loads, and Google's own products, including Search, Gmail, Android and Ads, rely on the same data. A Google Safe Browsing check is simply a question put to those lists: is this address on them right now? You'll see the same lookup sold as a Safe Browsing checker or a website safety checker, whether it takes a URL, a domain or a whole site.

The lists cover three broad threat classes. Malware is software built to damage a device or steal from it. Unwanted software is a download that behaves deceptively or changes the browser without clear consent. Social engineering covers phishing and other deceptive pages that imitate a login or trick someone into handing over data. Search Console adds a fourth label for site owners, hacked content.

One detail trips people up. A flag attaches to a URL or a whole site, not to the visitor's machine. Chrome Safe Browsing offers Standard protection, which warns about known dangers, and Enhanced protection, which also tries to catch new ones. Either setting changes what protection the visitor gets in their own browser. Neither one changes what your site is listed for.

How the Safe Browsing Test in our report works

The name of our check promises more than the test delivers. The report lists it as the Safe Browsing Test, but it never contacts Google Safe Browsing, the Transparency Report or Search Console. It checks only whether your page answers a plain request.

The exact rule: the report sends one HTTP HEAD request with a 3 second timeout and reads the status code. Below 400 is a pass, 400 or higher is a warning, and any request error is a fail.

What the test does

Our engine normalizes the address you submit, which usually means https with a trailing slash, and sends a single HTTP HEAD request using the Python requests library. A HEAD request asks for the response headers without the page body, as defined in RFC 9110 HTTP Semantics. Redirects are not followed, so a 301 or 302 counts as the answer rather than the page behind it. The code is a placeholder that could later call a Google API, and today it only reads the status code.

To approximate the request from your own machine, run the command below, which prints the status line a HEAD request gets back. It won't match our report exactly: curl sends a different user agent from a different network address, and the report's 3 seconds applies to each connect or read wait rather than to the whole transfer, so a slow server can behave differently in the two tests.

curl -I --max-time 3 https://example.com/

For plain reachability without HTTP detail, the ping tool shows whether the host answers at all.

Pass, warning and failed in the report

The table shows what each outcome means and what usually causes it.

Warning and failed share the same red message and How to Fix button. That wording is stronger than the evidence, since both states mean only that the page misbehaved on a plain request. A 405 reply to HEAD is a server preference, not a malware verdict.

What the test cannot tell you

The test never asks Google about your URL. A site that Google has flagged for hacked content but that answers with a normal 200 still passes, which is the most common real-world case. So treat a pass as "reachable", then run the Google lookups in the next section.

Check my website

How to run a Google Safe Browsing check yourself

There are three genuine ways to get Google's own verdict, ordered from easiest to most technical. Pick the one that fits whether you own the site and how many URLs you need.

1. Transparency Report. Any URL, including a site you do not own, with no account or sign-in.
2. Search Console. Your own verified property only, with a free Google account, and it shows the evidence behind a flag.
3. Lookup API. Scripts and bulk checks, which need an API key from a Google Cloud project and come with usage limits.

Google Transparency Report, any URL

Open the Safe Browsing site status page in the Google Transparency Report, which works as a Google Safe Browsing site status checker for any address. Paste the full address, with https, and submit it. The page returns Google's current verdict, and a clean result reads something like "No unsafe content found". It is also the quickest way to vet a link someone sent you. It reports what Google knows today, so a very new compromise may not appear yet, and it is a verdict on the URL, not a scan of your files.

Search Console Security Issues, your site

If you own the site, verify the property in Google Search Console and open the Security and Manual Actions section, then Security Issues. The report names the category, lists sample affected URLs and, when something is flagged, offers a way to request a review. Google says to trust this report over what you see in a browser, because warnings depend on browsing context and the page may look fine to you. For your own domain, this is the source of truth.

Lookup API, for developers

The Safe Browsing Lookup API takes an HTTP POST to threatMatches:find with a Safe Browsing API key. A single request can carry up to 500 URLs, and when nothing matches the response is an empty object, so an empty reply is the good news. Send the body as JSON with a Content-Type: application/json header. A trimmed body that covers all three threat classes looks like this.

POST https://safebrowsing.googleapis.com/v4/threatMatches:find?key=YOUR_API_KEY

{
  "client": { "clientId": "my-checker", "clientVersion": "1.0" },
  "threatInfo": {
    "threatTypes": ["MALWARE", "SOCIAL_ENGINEERING", "UNWANTED_SOFTWARE"],
    "platformTypes": ["ANY_PLATFORM"],
    "threatEntryTypes": ["URL"],
    "threatEntries": [ { "url": "https://example.com/" } ]
  }
}

Read the Lookup API documentation before building on it. The Safe Browsing APIs are for non-commercial use only, and Google points commercial services to the Web Risk API. The Update API is the other v4 option, built for local hashed checks, and Google also publishes a newer v5 API, whose urls.search method is a GET request that takes up to 50 URLs per call, while the v4 Lookup API remains documented.

A quick side note: a DNS blacklist check of the Spamhaus kind queries a different set of lists, so it cannot answer the Safe Browsing question. If you suspect mail or DNS listings as well, read our domain and IP blacklist check guide.

Why a Safe Browsing flag costs you visitors

When a page is on the list, browsers show a full page interstitial warning before it loads, with wording such as "Dangerous site ahead" or "Deceptive site ahead". According to the Search Console help page, Google Search can also put a warning label beside the result. Many visitors turn back at a red screen.

Traffic and sales can fall sharply once the flag goes live, even though your rankings have not moved, because the people who would have clicked now meet the warning first. Search Console surfaces the cause in the Security Issues report, so make that report part of every routine audit rather than something you open only after a complaint.

Common reasons a site gets flagged

Most flags trace back to one of five causes, and the first clue is usually the category named in the Security Issues report.

• Hacked content. Attackers inject spam pages, hidden links or redirects, and sometimes plant a web shell, through outdated plugins, old themes or stolen logins.
• Malware and harmful downloads. Injected JavaScript can run in the visitor's browser, sometimes sending people through a malicious redirect to another site, and files on the server may be classed as malicious or unwanted.
• Social engineering. A page, or content embedded in it, imitates a login form or tricks people into revealing data or installing software.
• Third parties. A compromised ad network, widget or analytics tag can trigger the flag even when every file you host is clean.
• Hidden behavior. Some malware uses cloaking, showing itself only to certain visitors or browsers, which is why the owner sees nothing wrong.

How to fix a Google Safe Browsing warning

Work through this order and resist the urge to ask for a review early. Reviews take days at the quick end and weeks at the slow end, so a request filed before the cleanup is finished means waiting twice.

1. Confirm the problem. Open the Security Issues report and read the issue category and the sample URLs. They tell you what to look for.
2. Contain the damage. Take a full backup first, even of the infected site, so you can compare later. If visitors are being harmed, put the site into maintenance mode. Find out who hosts you with the Hosting Checker so you know whom to ask for help.
3. Clean the site. Run a malware scan with your host or a security plugin, then do a file integrity check by comparing your files with a known clean copy. Look for unknown admin users, unfamiliar scheduled jobs, edited .htaccess rules, backdoors and injected scripts. Malware removal means deleting them or restoring a clean backup taken before the infection.
4. Close the hole. Update the CMS, plugins and themes, delete anything you do not use, reset file permissions, and rotate every password and key, including hosting, FTP or SFTP, the database and the CMS admin.
5. Request a review. In the Security Issues report, explain what you fixed. Google says reviews run from days to weeks.
6. Monitor afterwards. Watch the report and your logs for a few weeks, because reinfection through the same entry point is common.

On WordPress, malware cleanup can start from the command line. Running wp core verify-checksums and wp plugin verify-checksums --all compares core and wordpress.org plugin files with the published originals and names the ones that changed. Then look for PHP files inside wp-content/uploads, which should only hold media, and for obfuscated code such as base64_decode or eval in themes and the mu-plugins folder. Check the wp-cron schedule for jobs you did not create, rotate the salts in wp-config.php, and consider a web application firewall once the site is clean. On managed builders such as Shopify or Wix you cannot edit server files, so contact platform support and let them investigate. If the problem reaches beyond Google, our domain blacklist removal guide covers delisting more broadly.

How to stay off the Safe Browsing list

• Patch constantly. Keep the CMS, plugins and server software current, and delete the ones you no longer use.
• Lock down access. Use unique passwords, two factor login and least privilege accounts, and turn off directory listing. Our directory browsing check shows how.
• Serve everything over HTTPS and fix mixed content. That stops insecure scripts being swapped in on the way to the visitor. The SSL checker and HTTPS test guide covers the certificate side.
• Review third party code. Check script and ad tags on a schedule, because a compromised widget can get you flagged.
• Keep offsite backups. A clean copy away from the server turns a hack into a restore.
• Watch the alerts. Search Console emails you about security issues, so you hear first.