WordPress incident response
Google Safe Browsing red warning on WordPress – how do you remove it?
Google Safe Browsing red warning on WordPress – how do you remove it?
A Google Safe Browsing warning is not a browser error that can be switched off. The red interstitial means Google detected malware, phishing, unwanted software or hacked content on the site. Visitors turn back, advertising may stop, and search results can display a warning beside the domain.
Do not begin by requesting a review. First find and remove the compromise, close the entry point, and gather evidence that the site is clean. If the warning has just appeared, follow the first 30 minutes after a website hack without destroying useful logs.
Why does Google show the red warning?
Several different security findings can produce a similar user experience:
- malicious JavaScript or PHP executes on a page;
- visitors are redirected to a harmful domain;
- a phishing form asks for passwords or payment details;
- an attacker created spam pages;
- the site distributes malware or unwanted software;
- a compromised third-party script or advertisement loads harmful content.
Google's Security Issues report normally shows sample URLs, not a complete inventory. One example does not mean one infected page. The same incident may include generated URLs, several backdoors, a scheduled task and an unauthorized administrator.
“It loads normally for me” proves very little
Modern website malware often hides from the owner. It may redirect only mobile users, visitors arriving from Google, a particular country, or one request in several hundred. It may stay inactive while an administrator is logged in or set a cookie after its first execution.
One test in a private browser window is therefore not an investigation. Inspect source files, network requests, database content, file changes and server logs. Our guide to WordPress redirect malware explains how conditional redirects evade ordinary checks.
Start with evidence
Open the Security Issues report and record the finding type, detection date and example URLs. Preserve a copy of the compromised state before editing it. That snapshot is not your recovery source; it is evidence for comparing files and understanding what happened.
Inspect at least:
wp-config.php
.htaccess
index.php
wp-content/plugins/
wp-content/themes/
wp-content/uploads/
wp-content/mu-plugins/
wp-admin/ and wp-includes/
A PHP file under uploads is usually suspicious. So are unknown plugins, recently created administrators, unexpected cron events and long encoded values in wp_options.
For core files, WP-CLI provides a useful baseline:
wp core verify-checksums --include-root --version=$(wp core version)
wp plugin verify-checksums --all --strict
A successful core checksum does not certify the entire site. It does not validate custom or premium components, database records, user accounts or every uploaded file. The official WP-CLI checksum command has a deliberately narrower purpose: compare known WordPress core files with the official baseline.
How the compromise commonly works
The initial access often comes through a vulnerable plugin, stolen administrator credentials or a leaked hosting account. Attackers rarely make only one visible change. They add persistence so they can return after the obvious payload is removed.
A typical chain looks like this:
- A vulnerable endpoint allows file upload or remote code execution.
- A small PHP loader appears.
- The loader downloads another payload, adds an administrator or creates a cron event.
- Some visitors receive a redirect or phishing page.
- Google's crawler observes the behaviour and flags the domain.
Deleting the JavaScript used in step four does not remove the loader. That is why apparently fixed sites often trigger the warning again days later.
The correct cleanup order
Contain active harm first. If the site is serving phishing content or malware, restrict public access while preserving logs. Then:
- capture the current state and collect logs;
- identify modified and unknown files;
- compare core, plugin and theme files with clean sources;
- inspect database content, scheduled jobs and administrators;
- remove every persistence mechanism;
- patch or remove the component that allowed access;
- rotate WordPress, hosting, database and SFTP credentials;
- replace WordPress security salts;
- test from multiple devices and referral contexts;
- request a Google review only after those checks pass.
The professional WordPress malware cleanup process goes deeper into file comparison, request correlation and post-cleanup monitoring.
What counts as a clean site?
The homepage loading is not enough. You need stronger evidence:
- file comparison shows no unexplained changes;
- there are no unknown administrators, plugins, themes or scheduled jobs;
- the database contains no injected scripts or spam records;
- logs no longer show the same successful attack pattern;
- mobile, search-referral and logged-out visits behave consistently;
- the vulnerable entry point has been patched or removed;
- a second scan after cleanup still returns clean results.
WebShield correlates file changes with incoming HTTP requests, monitors administrators and newly installed components, and creates incremental backups every two hours. The objective is not merely to remove Google's warning. It is to stop the same compromise from being recreated.
A review request does not clean the website
Failed fixes we see repeatedly
The first is restoring an old backup immediately. That can work only when you know when intrusion occurred, can establish that the backup is clean, and close the entry point before restoration. Restoring the same vulnerable plugin and credentials gives the attacker the same route back. On a store, rolling back orders and stock changes also creates a separate business incident.
The second is accepting one security plugin's clean result. A scanner may run inside the already manipulated WordPress environment, lack access to some files, skip premium software, and miss persistence stored in the database or cron. The article on restoring a backup versus cleaning the site explains when each approach makes sense.
The third is deleting every recently modified file. An update can legitimately change hundreds of files, while malware can copy an old timestamp onto a backdoor. Content, origin, hash and related requests are more useful together than a date alone.
Database and browser indicators
Inspect the database as well as files. Long encoded-looking values in wp_options, unknown JavaScript in widgets, a changed siteurl, an unexpected administrator email or bulk-created posts deserve attention. On multisite, inspect each site's tables.
In browser developer tools, look for requests to unknown domains, document.location changes, dynamically created scripts and service-worker registrations. A service worker may affect a previously infected browser profile after the server is cleaned, so test with a fresh profile too.
curl -sS -D headers.txt -o page.html https://example.com/
curl -sS -A 'Googlebot' -e 'https://www.google.com/' https://example.com/ -o googlebot.html
curl -sS -A 'Mozilla/5.0 (Linux; Android 13)' https://example.com/ -o mobile.html
diff -u page.html googlebot.html
Different HTML is not automatically malicious; responsive and personalised sites vary legitimately. Unknown scripts, iframes and redirects require explanation.
Customer and data-impact questions
For sites handling accounts, payments or personal data, assess whether the attacker could access data or alter checkout. Do not claim that no information was exposed without logs and evidence. Legal notification obligations depend on the facts and jurisdiction, not on whether the homepage is working again.
Never instruct visitors to bypass the red warning. If a temporary status page is needed, host it on separate, verified-clean infrastructure.
Prevention after delisting
Use managed updates, unique accounts with multi-factor authentication, removal of unused software, restrictions on PHP execution in upload directories, frequent backups, central logging and file-change monitoring. A daily scanner may report the compromise long after the first successful request.
Alert on new administrators, plugins, themes and critical file changes. For a new component, verify that it contains real functionality, identify its source, and correlate its creation with incoming requests. The objective is for your own monitoring to detect the next incident before Google does.
In the review form, state exactly what was found, what was removed, which vulnerability was closed, and how the result was verified. “We fixed everything” is not useful evidence. Google explicitly advises owners to request a review only after the problem is genuinely fixed; a premature request can extend the period during which the site remains flagged.
The review submission itself deserves a separate guide. For now, remember the distinction: do not hide the red warning. Remove the reason it exists. On a business-critical site, especially one running ads or handling customer data, professional incident response is usually cheaper than several failed cleanup attempts that destroy evidence along the way.