Google Flags Your Website as Unsafe: What to Do

A warning about an unsafe website can stop traffic and orders within minutes. The red interstitial in Chrome turns away practically every visitor, and a notice in the search results cuts clicks even on positions that otherwise perform. The good news is that it can be removed. The bad news is that it comes back if you only fix what is visible.

This article explains what each warning actually means, how to establish the real scope of the problem, and how to request a review so it passes the first time.

Which warning are you actually seeing

Google uses several different messages and each points to a different kind of problem. Before you fix anything, establish which one you have:

• “Deceptive site ahead” — Google classified the content as phishing or social engineering. Typically a fake login form or a page injected by an attacker.
• “The site ahead contains malware” — malicious code was found that tries to install something on the visitor’s machine.
• “The site ahead contains harmful programs” — usually unwanted software or deceptive downloads, often through an injected advertising script.
• “Dangerous site” — the red marker in the address bar, which also appears on domains already flagged.
• “This site may be hacked” — a note directly in the search results. The site still loads, but Google has already recorded the problem.

One common mix-up: “Your connection is not private” and NET::ERR_CERT_* are not security incidents but HTTPS certificate problems. They have nothing to do with malware.

How to find out what Google actually found

The authoritative source is Google Search Console, under Security & Manual Actions → Security Issues. It shows the type of finding and — most valuably — example URLs. Google distinguishes these categories in particular:

• malware and unwanted software,
• social engineering, meaning phishing and deceptive content,
• harmful or uncommon downloads,
• a hacked site with injected code, content or URLs.

Save those example URLs together with the detection time. It is the first timestamp of the incident and it will save you hours when tracing the entry vector. It is also worth comparing what Google sees with what you see — some attacks only render for visitors arriving from search or only on mobile, so an ordinary visit to the site looks perfectly fine.

If you have no Search Console property for the domain, that is step one — without it you will never learn the outcome of the review and have nowhere to submit the request.

The first hour: what to do and what to avoid

1. Save the evidence. Export the report from Search Console, take screenshots, and note the time, the URLs and the exact wording of the warning.
2. Preserve a copy of the site. Download the webroot, the database and any logs before you delete anything. An infected copy is often the only thing that explains how the attacker got in.
3. Restrict access. Disable unknown administrators and change passwords for the CMS, hosting, FTP/SFTP, database and email — from a clean device.
4. Do not submit the review request yet. A rejected request only lengthens the process. It is submitted after recovery and hardening are complete.
5. Do not delete blindly. Attackers use multiple entry points and legitimate-looking files; fast deletion destroys evidence without closing the hole.

Where the problem usually sits

With a Google warning the source is in one of four layers, and it pays to check all of them rather than only the first:

• Site files — injected JavaScript in the template, obfuscated PHP, a web shell in a directory that should only hold images.
• The database — scripts and iframes injected into post content, spoofed URLs, altered settings.
• External scripts — a compromised ad network, widget or library loaded from someone else’s domain. Your site is “clean” and flagged anyway.
• Redirects — rules in .htaccess or in code that send only a subset of visitors elsewhere.

A clean recovery, not cosmetics

Once the approach is approved we create a working copy, remove the malicious changes and restore damaged components from verified sources. Then come CMS and extension updates, credential rotation, permission checks and regression tests — forms, logins, orders, redirects. The goal is not to delete the file that was found but to get the site to a state where the entire webroot is trustworthy again and the entry point is closed.

The deliverable is a classification of findings by severity and confidence, a description of the probable entry vector, and recommendations for ongoing operation. Where the scope cannot be determined reliably, we say so.

Requesting a review in Search Console

Only after recovery is complete, go to Security & Manual Actions → Security Issues in Search Console and use Request review. The description should contain specifics, not general reassurance:

• what was found and how it was removed,
• what the entry vector was and how it is now closed,
• that all credentials were rotated,
• which measures prevent a recurrence.

Google processes the request in a matter of days and returns the outcome in Search Console. Phishing reviews tend to be faster than malware ones. Also verify that the fixed URLs are crawlable again — if you blocked them in robots.txt in the meantime, the review cannot happen because Google cannot reach them.

A rejected request means Google still found something during the review. Resubmitting it unchanged is pointless — go back to the scope and look for what remained.

How long until the warning disappears

The work on the site can be finished well before the warning clears in the browser. Google has to recrawl and reassess, so some time usually passes between approval and the red page going away, and the browser holds the state in a local cache as well. If your host also blocked the site, or it is listed on other blacklists, each of those is handled separately — Google does not notify them. We cover hosting blocks in Hosting blocked your website because of malware.

Joomla, WordPress and WooCommerce

On older Joomla sites the decisive combination is usually outdated extensions plus compromised administrators; findings often hide in template and media directories. WordPress calls for checking plugins, the theme, the uploads directory and also mu-plugins and wp-cron, which are routinely overlooked. On WooCommerce we additionally verify payment and email flows — tampering with orders or checkout can cause commercial damage even after the malware is gone.

Frequently asked questions

Why does Chrome warn when I can see nothing wrong?

Many attacks are targeted — they render only for visitors arriving from search, only on mobile, or only outside your own IP address. That is why the example URLs from Search Console are more reliable than your own inspection of the site.

Is restoring the latest backup enough?

Not always. A backup taken after the compromise restores the infection; one taken long before it costs you data. The backup has to be reviewed first.

Can I request a review more than once?

Yes, but resubmitting without a real change only drags the process out. After a rejection the right move is to revisit the scope, not to send the same thing again.

Will this affect my search rankings?

A flagged site loses clicks immediately and, if the state persists, positions as well. Traffic usually returns once the warning is removed, though how fast depends on how long it lasted.

What if the warning came from an advertising script?

The site is responsible for whatever loads on it. The fix is to disable or replace the offending script and only then request a review.

What if my host blocked the site too?

Those are two independent layers and each has to be resolved separately. First ask the host for the reason and the list of findings — then run diagnostics with a forensic copy rather than deleting at random.

Order a security diagnosis · More about website malware removal · Ongoing website management