Google recovery
How to request a Google Safe Browsing review after WordPress cleanup
How to request a Google Safe Browsing review after WordPress cleanup
A Google Safe Browsing review request is the final step in incident response, not the first. Submit it after the WordPress site has been fully cleaned, the entry point has been closed, and post-cleanup checks show no backdoor, phishing page or malicious redirect.
If the investigation is incomplete, start with fixing the Google Safe Browsing red warning. An early request cannot force Google to clear an unsafe site.
Pre-review checklist
The homepage loading is insufficient. Confirm that:
- every sample URL and related directory was investigated;
- injected files and database records were removed;
- there are no unknown administrators, plugins, themes or cron events;
- core and available components match trusted sources;
- the vulnerability or stolen access path was addressed;
- credentials and WordPress salts were rotated;
- mobile, search-referral and logged-out visits show no conditional payload;
- a fresh scan and file-change review remain clean.
If a deleted file returns or .htaccess is rewritten, cleanup is not complete.
Where to request the review
As a verified Search Console owner, open Security Issues, expand the active category, and request a review after fixing it. Google's official dangerous-site guidance asks owners to explain, for each category, how the damage and underlying vulnerability were addressed.
If Safe Browsing flags the domain but Search Console has no reviewable item, algorithmic recrawling may clear it after cleanup. Verify that you are checking the correct property, including www, non-www, HTTP and HTTPS variants.
What should the request say?
Provide a short, verifiable incident record:
We found a PHP backdoor and conditional redirect created through a vulnerable
outdated plugin. We removed the malicious files and database injection, patched
the plugin, reviewed all administrators and cron events, and rotated credentials
and WordPress salts. Core and repository plugin files were checked against
official checksums. We retested mobile and search-referral requests and observed
no further malicious changes.
Do not claim work that was not performed. “We ran an antivirus” does not establish that persistence and the entry point are gone.
How long does it take?
Google does not promise one deadline for every category. Malware reviews often take days; reprocessing hacked spam can take longer, potentially weeks. The official Security Issues documentation describes category-dependent review times.
Do not submit the same vague request daily. Monitor Search Console messages and keep the cleaned site accessible so Google can verify it.
Why can the red warning remain after approval?
Search Console, the Safe Browsing database and browsers may update at different times. Check the Transparency Report and test from a fresh browser profile, but do not restart cleanup solely because of a short delay.
If the warning remains for several days, verify:
- every host and protocol variant is clean;
- external scripts or advertising resources are not compromised;
- cache or CDN is not serving an old payload;
- no conditional response targets a specific device, referrer or country;
- no new spam URLs or files have appeared;
- the request was sent under the correct issue category.
Continue monitoring after the warning disappears
Monitor file changes, administrators, plugins and scheduled events. Preserve logs, manage updates, and keep frequent usable backups. WebShield uses two-hour incremental backups and continuous state monitoring, and can correlate a new file with the HTTP request that created it.
If the warning returns after professional WordPress cleanup, treat it as a new incident or missed persistence. Repeating the review request is not a substitute for proving the reinfection path.