Requesting a review before the site is clean can waste the review and leave visitors exposed. Removing only the warning banner or redirect is not enough; the malicious content, persistence and entry route must be addressed.
Prepare evidence, verify public behaviour and submit through the authorised Search Console/Safe Browsing workflow.
Confirm the warning scope
Record affected domain/property, example URLs, warning type, first observation and source. Distinguish malware, phishing/social engineering, unwanted software and hacked-content search issues.
Do not repeatedly visit flagged pages while logged into owner accounts. Preserve screenshots/URLs safely without sharing malicious destinations publicly.
Check www/non-www, HTTP/HTTPS and subdomains.
Contain public harm
Serve static maintenance outside WordPress or remove public routing to compromised content. Disable checkout/login/downloads if credentials or payment data may be at risk.
Do not use robots.txt or a visual overlay as containment; users and scanners can still fetch malicious responses.
Record containment time and affected paths.
Rebuild trusted code and data
Replace WordPress core/plugins/themes from verified sources, validate custom code, inspect database/users/cron/uploads and isolate infected roots.
Remove phishing pages, redirects, injected scripts and executable uploads. Close the vulnerable component/stolen account and rotate relevant credentials.
Check staging, sibling sites, CDN/tag manager and DNS.
Review third-party resources and downloads
Inspect external scripts, iframes, ads, tag-manager/CDN workers and downloadable files. A clean WordPress HTML page can still load a flagged domain or serve unwanted software.
Confirm owner and purpose for every sensitive-page resource, remove unapproved suppliers and scan/rebuild downloads from trusted sources. Do not host suspicious samples on the recovery domain.
Use CSP/reporting and network inventory as supporting controls.
Verify every reported URL
Fetch representative URLs from clean public sessions and relevant referrer/mobile/first-visit conditions. Confirm correct 200 clean content, legitimate redirect or true 404/410.
Purge cache only after fixing the source. Check that malicious external domains/scripts no longer load.
Do not redirect every hacked URL to homepage.
Secure Search Console ownership
Review property owners/users and verification methods. Preserve unknown identifiers, then revoke unapproved access and remove malicious HTML/DNS verification tokens after control is secured.
Protect the Google owner account with MFA and session/app review. Use a durable organisational owner rather than one employee.
Verify the correct domain property.
Check Security Issues details
Use Search Console’s Security Issues report to review example URLs/categories. Inspect additional paths using logs/sitemaps/database, because examples may not list every compromised URL.
Do not declare cleanup complete because one example disappeared. Re-run the full recovery matrix.
Record the date and scope of checks.
Submit an evidence-based review
Explain the issue found, cleanup, entry-vector fix, credential rotations and prevention/monitoring added. Be concise and factual.
Do not include passwords, customer data or malware payloads. Submit only after public DNS points to the clean site and maintenance does not hide the actual result unnecessarily.
Keep submission and response records.
Handle an unsuccessful review
If the warning remains or review fails, re-check all examples plus conditional/mobile/referrer paths, subdomains, caches and external resources. Compare provider/search details with the submitted scope.
Do not resubmit the same generic statement repeatedly. Correct remaining evidence, update the remediation explanation and keep public containment if customers are at risk.
Record each request/result and dates.
Monitor after submission
Watch Search Console, Safe Browsing status, logs, original indicators, new hacked URLs and privileged/file changes. Review search snippets separately; indexing updates can lag behind security-warning removal.
Do not make repeated identical review requests while one is processing. Fix any remaining examples before resubmission.
Keep a rapid containment path.
Verify business recovery
After warnings clear, test forms, checkout, login, mail and analytics without disabling security controls. Confirm browsers and public networks reach the correct clean origin.
Request urgent security-review help when warnings span subdomains or reappear. Share property/example URLs and redacted remediation evidence—never Search Console credentials, customer data or malware publicly.