Keeping a WordPress site alive

Hacked WordPress Redirect: The First Hour

Visitors are sent to a spam site, or Google flags your pages. The first hour: contain it, back up, reset every login, scan, clean, then ask Google for a review.

By Anne CorcinoUpdated November 8, 20268 min read

Photo by Zechen Li on Pexels

In short

If your WordPress site sends some visitors to a spam or scam page, it has almost certainly been hacked, and the redirect is only the part you can see. In the first hour, contain the site, copy it as it is, reset every login that touches it, scan it, and write down what you find. Then clean it or restore a clean copy, close the way in, and only after that ask Google to review it, because a review requested too early keeps the warning on longer.

  • Google’s spam policy describes hacked redirects that send only some visitors to spam, depending on referrer, user agent or device, so the site can look normal when you open it yourself.
  • WordPress.org’s guide lists the first steps as documenting what you see, scanning the site and your own computer, checking with your host, resetting every access point and taking a backup before cleaning.
  • Sucuri’s guide says it is critical that all backdoors are closed, and warns that a stolen login session can stay valid after a password reset unless the secret keys are replaced.
  • Google’s Security Issues report is where a review is requested, once the fix is complete on all pages, and reviews can take days or weeks.
  • Patchstack found that 91% of the 11,334 WordPress vulnerabilities disclosed in 2025 were in plugins, so the way in is usually one of yours2.

Most owners find out in one of three ways: a customer says the site “went somewhere strange” on their phone, a search for the business name shows an odd result, or Google sends a message. This article is the order we would work in during the first hour, taken from the steps WordPress.org, Google and Sucuri publish, and what to leave until later. It is not a full cleanup guide; a cleanup depends on what the hack did. For the routine that makes these events rare, see what a WordPress maintenance plan should include.

How you can tell

  • Redirects that only some people see. Google’s spam policy says injected code can send some visitors to spammy pages depending on the referrer, the user agent or the device, and that there is no redirect when you open the same URL directly in a browser. If you see nothing wrong and a customer does, believe the customer.
  • Pages you did not write. The same policy says hackers add new pages, with spammy or malicious content, and that your existing pages may show no sign of hacking.
  • A flag from Google. The Security Issues report in Search Console shows hacked content, malware and social-engineering findings, including specific types such as hacked code injection, content injection and URL injection; affected pages can show a warning in search results or a browser interstitial.
  • Behavior you did not authorize. WordPress.org lists, among its clear signs, a site blacklisted by Google or Bing, a host that has disabled the site, new users appearing, and readers whose antivirus flags the site.

The first hour

Do these in order. The order is ours, assembled from the three guides below, and where they differ we say so.

  1. Write down what you see. Note the symptom, the time you noticed it, and anything changed recently, such as a new plugin or a theme edit. WordPress.org calls this the baseline of an incident report. It takes five minutes and it is useful to whoever cleans the site.
  2. Take the site out of public view. Sucuri suggests maintenance mode during a cleanup, because the site is likely to look broken anyway. If your host can suspend the site or put up a static page, that is better still.
  3. Copy the site exactly as it is. Take a full backup of the files and the database now, infected, before changing anything. Both WordPress.org and Sucuri say to do this. It is the evidence for working out how they got in, and a fallback if the cleanup goes wrong.
  4. Reset every access point. WordPress.org lists them: FTP or SFTP, the WordPress administrator login, the hosting control panel and the database, for every user with access. Then replace the secret keys in wp-config.php; WordPress.org says this logs out anyone still signed in, and Sucuri adds that a stolen session cookie keeps working after a password reset unless you do.
  5. Scan the site and your own computer. WordPress.org advises scanning the site from the outside and with a plugin, and scanning your own computer too, since infections can begin there and capture your logins. Check with the host, because on shared hosting the problem may reach other sites.
  6. Remove the hacker’s changes, or restore a clean copy. Replace WordPress core from the official download, using FTP or SFTP and not the reinstall option in the dashboard, since that only overwrites existing files and hacks often add new ones. Look at the .htaccess file and the theme files index.php, header.php, footer.php and functions.php. Do not overwrite wp-config.php or the wp-content folder blindly: replace plugins and themes from clean sources and read your own custom code. Sucuri also says to check the database for spam and malicious links, to remove users you do not recognize, and to look at other sites on the same hosting account.
  7. Close the way in. Sucuri calls it critical that all backdoors are closed to stop a hack. WordPress.org calls the question of how the attackers got in “forensics” and notes that it is hard for owners without the logs. Start with the plugins: Patchstack counted 11,334 new WordPress vulnerabilities in 2025, 91% of them in plugins, and 46% had no developer fix when they were disclosed2.
  8. Update everything, then reset the passwords again. WordPress.org says to update to the latest software once the site is clean, and to change the passwords again after that, because the first reset happened while the site was still infected.
  9. Ask Google for a review. Only now. See below.

Sources disagree Sucuri’s 2022 article puts strong passwords in the hardening stage after cleanup, while WordPress.org tells you to reset access at the start and again when clean. We do both.

Asking Google to review the site

In Search Console, open the Security Issues report, fix the issue throughout the site and not only on some pages, test it, and then select Request Review, explaining the issue and the steps you took. An older Google page on the subject says a premature request only extends the time the site stays flagged. It gives the following times: reviews for spam hacks can take up to several weeks, malware reviews a few days, and phishing about a day; it is an older page, so treat the numbers as indicative3. The Search Console help page says reviews can take days or weeks and not to resubmit while one is pending1.

What not to do

  • Do not request a review before the fix is complete.
  • Do not resubmit a pending request.
  • Do not use the dashboard’s reinstall to remove malware. It overwrites existing files and does not remove the files that were added.
  • Do not restore a backup and walk away. A clean copy with the same vulnerable plugin is a clean site that can be hacked again; Google’s prerequisites for a review include fixing the vulnerability.
  • Do not skip the copy of the infected state. It is the only record of what happened.
  • Do not delete users or files you cannot identify before copying the site. Copy first, then remove.

Preventing the next one

The stable list is short and boring. Keep WordPress, plugins and themes updated, remove what you do not use, and use long unique passwords with a second factor. Sucuri’s list also includes a website firewall and backups that are automated, off-site and tested. Patchstack’s figure of a 5-hour median time to mass exploitation for heavily targeted vulnerabilities suggests that waiting for a monthly update cycle leaves a long window for security fixes2. A site on a plan has someone looking at those disclosures; a site without one does not.

What we do about it

On the sites we manage, we manage the servers, updates are tried on a staging copy before the live site, and backups run daily and are kept off the server, so a clean copy exists before anyone needs it. That is the part of this article we can do something about in advance. When a site comes to us already hacked, the steps are the ones above, in that order, and the review request comes last. The routine is described on our website management page, and the difference between a host’s job and a plan’s job is in hosting vs a maintenance plan. If a developer vanished and left you without the logins, start with your web developer disappeared.

When to get help

Get help if the redirect returns after a restore, if you do not have a backup, if customer data or payment pages were involved, or if you cannot find the way in. WordPress.org’s own guide points to reputable cleanup services for owners who cannot do it themselves. The consultation is free.

Frequently Asked Questions

Why does my site only redirect on mobile or from Google?

Google’s spam policy says injected code can redirect visitors depending on the referrer, the user agent or the device, and that a direct visit to the same URL may show no redirect. Test from a phone, from a search result and in a private window.

Should I take the site offline?

Sucuri suggests maintenance mode during cleanup, because the site will likely look broken. Taking it out of view also stops further visitors from being sent to the spam page.

Can I just restore a backup?

Sometimes, if the backup is from before the hack and you fix the way in. WordPress.org says to replace core files by hand and check .htaccess, and Sucuri says all backdoors must be closed. Restoring alone leaves the original weakness.

How long does Google take to remove the warning?

Google’s Search Console help says reviews can take days or weeks. An older Google page gives about a day for phishing, a few days for malware and up to several weeks for spam hacks3.

How did they get in?

Most often through a plugin. Patchstack found 91% of 2025’s new WordPress vulnerabilities in plugins and 9% in themes, with 6 in core2. Your logs and a scan show which.

Sources

  1. Security Issues report — Search Console Help, Google.
  2. State of WordPress Security in 2026 — Patchstack, February 25, 2026.
  3. Request a review — Google, web.dev.

Research and drafting assisted by AI, reviewed before publication. Editorial policy.