Removing Chrome’s “Dangerous site” warning

The full-page red warning is the worst thing that can appear in front of a website. Traffic stops instantly, and the owner usually finds out from a customer rather than from a monitoring alert. The good news: it is almost always fixable in a day, and the process is more mechanical than it looks.

What the warning means

The interstitial comes from Google Safe Browsing, a list Chrome, Firefox and Safari all consult. A site lands on it when Google's crawlers find malware, a phishing page, or code that redirects visitors somewhere harmful. It is a symptom. Clicking "request a review" before removing the cause simply gets you flagged again, usually within hours.

Step one: read the diagnosis

Open Google Search Console for the property and go to Security & Manual Actions → Security Issues. Google names the category — malware, unwanted software, social engineering — and frequently lists sample URLs. Those samples are the fastest route to the injected code. If the site is not verified in Search Console, verify it now; without it you are debugging blind.

Step two: find what was injected

In our experience the compromise is in one of four places, in descending order of likelihood:

• Theme and plugin files. Look for recently modified files: find . -type f -mtime -14 -name "*.php". Attackers rarely bother to reset timestamps.
• The database. Injected <script> tags in post content, or in wp_options. Search the export for eval(, base64_decode( and unfamiliar domains.
• Uploads. A .php file inside wp-content/uploads is never legitimate. That directory should serve media and nothing else.
• Dropped admin users and cron jobs. Check the user list and the server crontab. Backdoors persist by re-installing themselves.

Step three: clean, then close the door

Restore from a known-good backup taken before the infection date if you have one — it is faster and more complete than manual cleaning. Then, in the same session:

1. Update WordPress core, every plugin and the theme. The entry point is usually a known vulnerability in something outdated.
2. Delete plugins and themes you are not using. Inactive code is still executable code on disk.
3. Rotate every credential: admin passwords, database password, FTP and SSH keys, hosting panel login.
4. Remove unfamiliar admin accounts and re-check the crontab.

If you restored from a backup, verify the restored copy is actually clean before you go further. A backup taken after the compromise reinstates it.

Step four: request the review

Back in Search Console, under Security Issues, choose Request Review. Describe what you found and what you changed — specifically, not generically. "Removed injected base64 payload from header.php, updated all plugins, rotated all credentials, removed two unauthorised admin users" reads as a real cleanup. "Fixed the issue" does not.

Reviews typically clear within one to three days. The listing lifts on its own once Google re-crawls; you do not need to do anything else.

Staying off the list

Automatic updates for core and plugins, a web application firewall, file-integrity monitoring, and backups you have actually tested restoring. The last one is the one people skip, and it is the one that turns a bad day into a bad hour.