What to Do When Google Flags Your WordPress Site as Hacked

You search your own domain on Google. There it is: a "This site may be hacked" warning.

Or something weirder. A friend tells you your meta description is showing Japanese text in search results. You open the site yourself and it looks completely normal.

If this is you right now: it is fixable. You are not the only site owner who has been here.

I have walked clients through this exact situation more than once. One was bad enough that we had to rebuild the entire WordPress installation from a clean copy.

No fun. Necessary, though.

Here is what actually happens during a WordPress hack recovery. What catching one early looks like versus catching one late. And the security layers that stop round two.

Why Can a Hack Show Up in Google Before You See Anything Wrong?

One client found out because a friend searched their business on Google and saw Japanese text sitting in the meta description.

The client opened the site themselves. Same homepage. Same content. Nothing obviously wrong.

That gap, what the owner sees versus what Google sees, is the whole point of this kind of attack.

It is documented as the Japanese keyword hack. Google's own web.dev guide describes the exact pattern: autogenerated spam pages planted in randomly named directories, cloaked so they only show to search crawlers or to visitors arriving from search results. A direct visit to the homepage looks untouched.

This one had been sitting undetected for a few months. So I could not treat it as a simple file cleanup.

No half-measures on something like this.

When an infection reaches that deep, you cannot be fully sure which core files, plugins or database entries got touched. Miss even one backdoor and the hack comes right back. So here is what the fix actually looked like:

1. Pull the site onto a staging copy first, so nothing we tried could take down the live site or let the infection spread further while we worked.
2. Replace the entire WordPress installation, including core files, with clean copies rather than trying to selectively delete suspicious files.
3. Audit the database, plugins and user accounts separately, since a reinstalled WordPress core does not fix a backdoor sitting in a plugin file or a database table.
4. Test thoroughly on staging, confirm the warning conditions were gone, then push the clean version live and request a review in Search Console.

Turns out this is also Google's own recommended approach. web.dev's guide to the Japanese keyword hack calls for removing unrecognized Search Console owners, replacing .htaccess files with clean copies, and reinstalling core files rather than patching around the infection.

What Does It Look Like When You Catch a Hack Early?

The second case was a completely different experience. Night and day.

We caught it early. This was a new maintenance client, one we had just taken on and were watching closely, so it took less than a week to catch.

Someone had broken in, created a new admin user, and started publishing pages that had no business being on the site. Nothing cloaked. Nothing hidden. Just obviously wrong content sitting in the dashboard.

Finding it early meant the cleanup stayed contained. Remove the rogue user and its pages. Check for other unexpected admin or editor accounts. Scan theme and plugin files for injected code. Reset every password and API key tied to the site: hosting, WordPress, FTP, the database, all of it.

No reinstall needed.

The difference between these two cases comes down to one thing: how early you catch it. Which really just means whether you are watching for the signs at all. Unexpected users. Unexpected pages. Outbound links you did not add. A traffic spike to pages you do not recognize.

The earlier you catch it, the more of your site you get to keep.

What Does a WordPress Hack Recovery Actually Involve?

No matter how bad the infection is, the process is always the same three stages. Diagnose. Clean up. Test. In that order, every time.

• Diagnose: find every compromised file, user, plugin and database entry, not just the one symptom you noticed. A spam meta description or a strange page is usually just the part that happened to surface.
• Clean up: remove what does not belong, and when the infection is bad enough that you cannot be confident you have found everything, replace the WordPress installation folders with clean copies rather than hoping a targeted delete caught it all.
• Test: confirm the site is clean and behaves correctly before it goes back in front of visitors and Google.

For anything beyond a minor, clearly contained issue, do all three steps on staging first. Not on production.

Why? Because a mistake during cleanup, or an infection that turns out worse than it looked, cannot take the live site down if it never touches the live site.

Once staging checks out clean, push it live. If Google had already flagged the site, request a review through the Security Issues report in Search Console.

What Stops This From Happening Again?

Cleaning up a hacked site fixes the symptom. Not the cause.

Most cleanup stops right there. The infection gets removed and nothing else changes: no new security, nothing done to stop it happening again.

Here is what I put in place afterward so it does not happen twice:

• A security plugin like Wordfence or Sucuri, for malware scanning, firewall rules and file change monitoring.
• Hiding or renaming the default login URL, since wp-login.php and wp-admin are the first thing automated attacks try.
• Blocking user enumeration through the REST API, which otherwise lets anyone pull a list of your usernames and go straight to brute-forcing passwords.
• Hiding the PHP and WordPress version numbers from the page source, so attackers cannot immediately tell which known vulnerabilities to try.
• Configuring HTTP security headers properly (HSTS, Content-Security-Policy, X-Frame-Options and similar), which close off several common attack paths at the browser level, not just inside WordPress.
• Turning off comments when you are not actually using them, since script injection can happen through the comment system too, especially on a site that has fallen behind on updates.

That last one is where most sites fall short. Mostly because it is invisible. There is no obvious symptom when your headers are misconfigured, not until something exploits the gap.

Our audit tool checks for exactly this. It is new, but we are already seeing 10 to 25 sites run through it every day, and missing or misconfigured headers show up constantly. It is usually the fastest way to find out if this particular door is still open on your own site.

FAQ

My site looks fine to me, so why does Google say it's hacked?

Because a lot of WordPress hacks are built to hide from you specifically. Cloaked spam pages. Injected redirects. Content served only to crawlers. It can sit there for weeks and you would never spot it just by browsing your own site.

How do I know if my WordPress site has actually been hacked?

Start with Google Search Console's Security Issues report. It flags hacked content, malware and social engineering issues directly.

Beyond that, watch for unfamiliar admin users, pages you did not create, a changed meta description in search results, outbound links you did not add, or your host suspending your account for malicious activity.

Can I just delete the infected files myself and move on?

Sometimes.

If you caught it early and know exactly what was touched, a targeted cleanup works fine. That is what happened in the second case above.

If it has been sitting there a while, or you are not sure how deep it goes, skip the shortcut. A partial cleanup often leaves a backdoor behind, and the hack just comes back.

Why fix this on a staging site instead of the live site?

Because cleanup itself carries risk. Plain and simple.

You might delete something the site needs. The infection might turn out worse than it looked. Staging means your visitors and your rankings are not exposed while you sort that out, and you only push live once it is actually confirmed clean.

Will my Google rankings recover after a hack?

Usually, yes. Once the site is clean and you have requested a review through Search Console.

Google is not trying to punish you. It is trying to protect its users, so the warning lifts once the risk is gone.

The bigger risk is usually how long the warning stays up, not the hack itself. Traffic and trust take a hit the longer visitors see it.

Do I need a security plugin if my hosting already has protection?

Hosting protection and a WordPress security plugin cover different things.

Your host protects the server. A plugin like Wordfence or Sucuri watches what happens inside WordPress itself: file changes, login attempts, plugin vulnerabilities.

I recommend both. Not one instead of the other.

What is this REST API user enumeration issue, in plain terms?

By default, WordPress's REST API can hand anyone a list of your usernames just for asking.

That is exactly what an attacker needs to start guessing passwords. Block that endpoint, or restrict what it returns, and you close off one of the easiest ways in. A normal visitor will never notice the difference.

How do I know if my site has a gap like this right now?

That is exactly what our audit tool is for. It scans for missing HTTP security headers and a lot more, so you are not guessing about what is already in place.

Next Steps

Dealing with an active warning right now? Start with diagnose, clean up, test. On staging, if the site is at all business-critical. Request a review in Search Console once it is confirmed clean.

Site looks fine today? Run it through our free Website Audit tool anyway. It flags missing security headers and a handful of other issues in a few minutes.

Not sure where to start, or want a second set of eyes on an active hack? Book a consultation and let us walk through it together.