A red browser warning or a “This site may harm your computer” message can stop traffic and damage trust overnight. The priority is not hiding the warning—it is removing the harmful behavior, closing the attacker’s access and giving Google a clean site to review.
Google’s Security Issues report may identify hacked content, URL injection, malicious downloads, phishing or other harmful behavior and provide sample URLs. Those examples may not represent every affected page.
Book a free, no-obligation strategy call and we'll map out your next move.
Security warning, manual action or indexing problem?
A security issue indicates behavior that may harm visitors or devices. A manual action usually concerns search-policy violations. Coverage and indexing reports describe crawling and indexing, not necessarily malware. Check each relevant report instead of assuming one review fixes everything.
Step 1: confirm the warning safely
Verify the correct Search Console property and review every issue category and sample URL. Avoid opening known malicious pages on a normal work device. Record the warning date, examples and recent changes, then export available security, server and authentication logs.
Compare the symptoms with signs of a hacked WordPress site. Search spam may also connect to the Japanese keyword hack.
Step 2: contain visitor risk
If the site redirects, serves malicious downloads or captures credentials, restrict public access or use a controlled maintenance state while investigating. Preserve a full file and database snapshot before cleanup. Coordinate with the host when server-level evidence or account isolation is required.
Step 3: clean the entire environment
Remove malicious files, scripts, database injections, unauthorized users, application passwords, scheduled tasks and hostile server rules. Replace modified core, plugin and theme code with trusted packages. Audit DNS, CDN, tag managers, deployment credentials, sibling sites and hosting users.
For rerouted visitors, use the WordPress redirect-hack guide. For an ordered response, follow Emergency Recovery Steps.
Step 4: remove persistence and close the entry point
Investigate vulnerable extensions, stolen credentials, exposed control panels, insecure permissions, compromised devices and shared hosting. Rotate WordPress, hosting, database, SFTP, SSH, CDN and deployment credentials. Update salts, invalidate sessions and enable multi-factor authentication.
A scanner reporting zero findings is not enough when the cause is unknown. Compare files with trusted copies, review scheduled tasks and monitor the clean build before requesting review.
Step 5: test the repaired site
- Confirm harmful pages and injected URLs are removed or return the correct status.