What to do if Google flags your site as dangerous

Few things stop a website in its tracks like Chrome’s red screen. A visitor types your address and, instead of your home page, gets a full-screen warning: “Deceptive site ahead” or “The site ahead contains malware”. Almost nobody clicks through, so for practical purposes the site ceases to exist.

The first thing to know is that it is rarely the owner’s direct fault, and that the warning can be lifted. The second is that the fix is not arguing with Google, but finding and cleaning up whatever caused it.

What Google Safe Browsing is

Safe Browsing is a list Google maintains of web addresses considered dangerous. Its crawlers feed it as they go through the web, and Chrome, Firefox, Safari and many other programs check it before opening a page. If the address is on the list, the browser shows the warning instead of the site.

That is why the problem shows up in almost every browser at once, and why it can also affect links you send by email: some email clients and antivirus products use the same source.

The list distinguishes several types of threat:

Type	What it means	Typical warning
Malware	The page tries to install malicious software or loads code that does	“Contains malware”
Social engineering	Impersonates another organisation to steal data: phishing	“Deceptive site ahead”
Unwanted software	Offers downloads that do things they do not disclose	“Contains harmful programs”
Potentially harmful application	Distributes dangerous mobile apps	Warning on Android

Google can flag a single page, a section or the entire domain.

Why your site is flagged when you did nothing

Because, usually, someone else got in. The most common causes:

• Outdated plugins, themes or core CMS. By far the most common way in. A known flaw in a popular plugin is exploited automatically across thousands of sites at once.
• Weak or reused passwords on the admin panel, FTP or hosting. If one of them appeared in a breach, someone has tried it; we cover this in how to check if your password was leaked.
• Phishing pages hosted on your server. The attacker uploads a fake copy of a bank’s or email provider’s login page to a hidden folder and uses it in their campaigns. Your home page may look perfectly normal.
• Injected code that redirects some visitors to other sites, often only those arriving from Google or on mobile, so the owner does not notice.
• Compromised third-party resources: a script, an ad or a widget loaded from another domain that has been tampered with.

First steps

Before cleaning, contain the damage and keep evidence:

1. Take a full backup of files and database exactly as they are. It helps you work out what happened and lets you roll back if the clean-up breaks something.
2. Change every password: hosting, FTP or SFTP, database, CMS admin users, API keys. Do it from a clean machine.
3. Check Search Console. Under “Security and manual actions”, the “Security issues” report shows what Google has found and often gives sample affected URLs. It is the best clue to where to look.
4. If the site is actively distributing malware, consider putting it into maintenance mode while you work.

Cleaning up properly

Cleaning is not deleting the one file that jumps out. If the back door they came through is still there, the problem returns within days.

• Update everything: CMS core, plugins and themes. Remove the ones you do not use; a deactivated plugin is still code on the server.
• Compare files against a clean copy. In WordPress, for example, core files can be replaced with the official ones for the same version. Look for PHP files in upload folders, recently modified files and names that imitate legitimate ones.
• Review the server configuration: .htaccess, redirect rules, scheduled tasks and users you do not recognise.
• Review the database: new admin users, scripts inserted into posts, options or widgets.
• Find the entry point. Server logs and the dates of the first altered files usually point to the plugin or account they used. Until that is closed, any clean-up is temporary.

If you do not know which platform or plugins the site runs, because you inherited it or whoever built it has gone, start by finding out what it is built with. On large or badly damaged sites, the safest route is sometimes to restore a backup from before the attack and update it, rather than cleaning piece by piece.

Requesting a review

Once you are confident the site is clean, the same Security issues report in Search Console offers the option to request a review. Describe specifically what you found, what you did to remove it and how you closed the entry point. A generic “it’s fixed now” is more likely to be turned down.

Google rescans the site and, if it no longer finds the problem, lifts the warning. It usually takes days rather than weeks. If the review fails, go back and look again: something was left behind.

If the site is not yet set up in Search Console, now is the time. Without it you cannot request a review or see what Google has detected.

Keeping it from happening again

• Updates applied regularly, not once a year.
• Unique passwords and two-step verification on the admin panel and the hosting.
• Automatic backups stored off the server.
• Few plugins, all actively maintained.
• Someone checking Search Console now and then: Google sends alerts by email, but only to verified owners.

Checking yours

Our Safe Browsing checker queries the Google Safe Browsing API with the URL you give it and tells you whether it is clean or flagged, and if flagged, for which type of threat: malware, social engineering, unwanted software or harmful application. Since Google may flag only part of a site, if you suspect a particular section, check it separately as well as the home page.

It is also handy after a clean-up, to confirm the warning has gone, and as a periodic check on the domains you manage. For the full detail of what Google has found, Search Console remains the source.

---

A Safe Browsing warning is alarming, but the path out is clear: contain, clean thoroughly, close the entry point and request a review. What drags the problem out most is skipping the third step.