Google Flagged Your Site as Dangerous

What has actually happened

A warning page appears in front of your site in most browsers, in place of the page somebody asked for.

It is generated from a shared list of sites found to be serving something harmful, which browsers and search engines consult.

Your search results may also carry a warning, and traffic falls to close to nothing within hours.

The site itself is still running and reachable by anybody who overrides the warning, which almost nobody does.

Find out why

The search console tells you, in a section for security issues, and it is the first place to look.

It names the category: harmful software, deceptive content, unwanted software, or in some cases a small number of specific example pages.

Those examples are the most useful part, since they point at where to look rather than leaving you searching a whole site.

Where the site is not connected to the search console, connect it now, since it is the only route to both the diagnosis and the review request.

Verification takes a few minutes and is worth doing before anything else, because everything that follows depends on it.

The common causes

• Injected code serving something to visitors.
• A compromised advertising or third-party script.
• Uploaded files in a public folder.
• A page imitating a bank or a login.
• A plugin shipping something unwanted.
• A neighbouring site on shared hosting.

The second catches sites that were never compromised themselves. A third-party script that was itself compromised serves something harmful through your pages, and the warning lands on you.

Fix it before requesting anything

The point that determines how long this takes.

A review is a check, and a site still serving the problem fails it, which puts you back at the start of a queue measured in days.

Businesses commonly request a review immediately, out of urgency, and lose the better part of a week that way.

Clean or restore first, close the entry point, change every password, and confirm the example pages named in the console are actually clean.

Check as a visitor would, from a search result and on a phone, rather than assuming the removal worked.

Only then request the review.

A worked example

A business found their site behind a warning on a Monday morning and requested a review within the hour.

It was declined two days later, since the site was still serving the injected content.

They then restored from a backup, updated everything, changed the passwords, and requested a second review, which was declined again because a scheduled task had reinstalled the code overnight.

The third attempt, after somebody removed the scheduled task, was approved in about two days.

Total time behind the warning was nine days, of which roughly five were spent on reviews that were always going to fail.

The site was clean by day four and the queue cost the rest.

While the warning is up

Since the business continues during it.

Tell customers plainly, on whatever channel you have: your business listing, your social accounts, and by email if you have a list.

Say that the site is temporarily unavailable, that you are dealing with it, and how to reach you meanwhile.

Make sure your phone number and email are visible somewhere that is not the site, since the site is where they normally are.

Check that your business listing is complete, because for those days it is doing the work the site normally does.

Do not pretend it is not happening, since a customer who hit the warning and receives no explanation draws their own conclusion.

After the warning is lifted

The recovery, which is slower than the removal.

Traffic returns over days rather than instantly, since caches and other systems consulting the same list update at their own pace.

Rankings may take longer, particularly if the site was serving injected pages that have now disappeared.

Watch the indexed page count, which should fall as the injected pages drop out, and expect that to look alarming before it looks better.

Take a fresh backup and store it out of reach, since the copies you held are now suspect.

And keep the search console notifications on, since the same site is a likely target for a repeat if anything was missed.

The shared hosting version

Worth separating, since the response is different and the situation is not your fault.

Where the problem originates elsewhere on a shared server, cleaning your own site achieves nothing and the warning persists.

Contact the host with the specific example pages and ask them to investigate at their level.

Ask directly whether other accounts on the same server are affected, which they may be reluctant to answer and which determines what you should do.

Where a host is slow or dismissive about this, that is information about the host, and a repeat occurrence is a reason to move.

Set up the console before you need it

The preparation that would have removed most of the delay in the example above.

Connecting the site to the search console takes a few minutes and gives you notification of a security issue directly, frequently before the warning is applied.

Without it, the first indication is a customer telling you or traffic disappearing, by which point the warning is already in place.

Add a second person to the account as well, since a business where one person holds the only access has a problem whenever that person is unavailable.

Check that the notification address is one somebody reads, which is the same failure as any other alert going to an unmonitored mailbox.

The counter-case

Warnings are occasionally wrong.

A false positive can be triggered by a legitimate script, a file download, or a page resembling something else, and the review process exists partly for that.

Where you have looked properly and found nothing, request the review and say what you checked rather than assuming you must have missed something.

There is also a risk of over-reacting by rebuilding a site that needed one file removed.

Read the console, fix what it names, verify as a visitor, and then request the review once.

The order

1. Open the search console security section.
2. Note the category and example pages.
3. Fix or restore, and close the entry point.
4. Change every password.
5. Verify as a visitor from a search result.
6. Then request the review, once.
7. Tell customers while you wait.

Step six is where the days are won or lost, since each failed review costs another turn in a queue and requesting early never speeds anything up.

What the whole incident looks like is covered in a site that got hacked and what happened next.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.