WordPress site hacked? What to do in the first 24 hours

That order is the whole method. If you would rather not do it yourself, you can get the site cleaned and the entry point closed by a team that starts with a forensic copy and ends with a blocklist review. The rest of this page is the runbook, hour by hour, with the official documentation behind each step. All platform rules below are as of September 30, 2026.

Short answer: the 24-hour runbook

Print this table or paste it into a shared doc. Assign a name to every row before you start. Two people working the same row at once tend to overwrite each other's evidence.

A reasonable goal for day one is a clean, locked site and a pending review. The warning label itself may stay up longer. Google's own help page says a review "can take from a few days to a few weeks" (Search Console Help, Security issues report, as of September 30, 2026).

Signs your site is hacked

Most owners find out from someone else. A customer emails a screenshot. The host suspends the account. A search result carries a gray line under the title.

The common signals:

• "This site may be hacked" in Google results. Google shows it when it believes someone changed existing pages or added spam pages (Google Search Help, as of September 30, 2026).
• A red interstitial in Chrome. That points to malware, phishing or unwanted software flagged by Safe Browsing.
• Redirects to spam. Often only for mobile visitors or only for traffic from search. You open the site directly and see nothing wrong.
• Admin accounts you did not create. Or an existing account with a changed email.
• Japanese or pharma pages in search. The Japanese keyword hack creates pages of autogenerated text in random directories, and the attacker often adds themselves as a property owner in Search Console (web.dev, Fix the Japanese keyword hack, as of September 30, 2026).
• Mail from your host. Suspended account, outbound spam, abuse report.

The WordPress documentation lists similar "indicators of compromise": blacklisting, a disabled host account, readers whose antivirus flags the site, and new users nobody authorized (WordPress.org, FAQ My site was hacked, as of September 30, 2026). One of these is enough to start the clock.

A note on reproducing warnings. Safe Browsing decides what to show based on browsing context. You may not see the warning your customer saw. Google says to treat the Security Issues report as the source of truth (Search Console Help).

Hour 0–1: contain and preserve evidence

The instinct is to start deleting. Resist it for sixty minutes.

First, stop the damage. Switch on a maintenance page at the server level, or ask the host to restrict access to your IP. A plugin-based maintenance mode is weaker, because the attacker may control PHP. If the site skims payment data or serves malware downloads, take it fully offline.

Second, copy everything as it is. Files, database dump, server access logs, PHP error logs, and the host's own logs if they keep separate ones. Store the copy off the server and write the time on it. This copy holds the malicious files, and that is the point. It is the only record of where the attack came from. Clean first and you lose the log trail with it.

The FTC gives the same advice to any business facing a breach: "Do not destroy evidence" (FTC, Data Breach Response: A Guide for Business, as of September 30, 2026). The WordPress FAQ adds a step owners skip: write down what you saw, when, and what changed recently. That note becomes your incident report.

Third, call the host. On shared hosting the infection may sit in a neighboring account. The host can also tell you whether it is an actual hack or an outage that looks like one. Ask how many days of logs they retain. Some keep only a few.

Do not log in to wp-admin from a laptop you have not scanned. The WordPress FAQ warns that trojans on the owner's own machine can steal FTP and admin logins.

Hours 1–4: find what changed

Now you look for the delta between "known good" and "now." Work from the outside in.

Search Console. Open the Security Issues report. Expand each issue to see sample URLs and the date Google first detected the problem. That date is your starting point in the logs. Then open Settings → Users and permissions. Remove any owner you do not recognize, and write it down first.

Safe Browsing. Check the domain on Google's Safe Browsing site status page. It shows whether Google currently flags the site as dangerous.

Users. List every administrator. With WP-CLI that is wp user list --role=administrator (WP-CLI docs). Compare registration dates with the detection date. Look at the wp_users table directly too; a plugin can hide an account from the dashboard.

Files. Run wp core verify-checksums, which compares core files with WordPress.org checksums without loading WordPress (WP-CLI docs). Run wp plugin verify-checksums --all for plugins from the official directory (WP-CLI docs). Then sort all files by modification time and read anything that changed near the first-detected date. Attackers fake timestamps. Treat the sort as a lead, not proof.

Places code hides:

• wp-content/uploads/ — any .php file here is suspect.
• wp-config.php — extra include lines, base64 blobs, new constants.
• .htaccess — conditional redirects for search engine referrers or mobile user agents.
• wp-content/mu-plugins/ — must-use plugins load silently and do not appear in the normal list.
• wp_options — injected scripts in widget text, siteurl or home pointing elsewhere.
• wp_posts — hidden links or <script> tags inside post content.
• Scheduled tasks — wp cron event list for WordPress events (WP-CLI docs), plus the server crontab.

Logs. Search the access log around the first-detected date. Look for POST requests to odd files, logins from unfamiliar IPs, and requests to a plugin's upload endpoint. Usually one request stands out. That request is your entry point.

Hours 4–12: clean

The cleanup sequence matters: contain, find the route in, clean, rotate every credential, close the hole. Deleting the files is the quick part. If the entry point stays open, the same code tends to come back, often under a new file name.

If you have a backup from before the first-detected date, restoring it is usually faster than cleaning. Check that it really predates the infection. Then patch the entry point before the site goes live, or you restore the same hole.

Without a clean backup, rebuild from trusted sources:

1. Core. Replace wp-admin/ and wp-includes/ with a fresh download of your exact version from wordpress.org. Do not copy over them; delete and replace.
2. Plugins and themes. Delete each folder and reinstall from the official directory or the vendor's site. Premium plugins from "nulled" download sites go in the trash. Remove anything you do not use.
3. Unknown files. Anything that is not core, a known plugin, a known theme or your media gets deleted. PHP inside uploads goes first.
4. wp-config.php. Compare it line by line with wp-config-sample.php. Keep only your database settings and constants you recognize.
5. .htaccess. Regenerate it. For a standard install, saving Settings → Permalinks writes the default rules back.
6. Database. Search posts, options and widgets for <script, eval(, base64_decode and iframe tags. Remove injected content and unknown admins.
7. Permissions. The WordPress hardening guide suggests 644 for files and 755 for directories, and 400 or 440 for wp-config.php where the server allows it (WordPress Hardening, as of September 30, 2026).

While you are in wp-config.php, add define( 'DISALLOW_FILE_EDIT', true );. The hardening guide notes the dashboard file editor is often the first tool an attacker uses after logging in. The constant turns it off.

Then scan again. Run the checksum commands a second time. Use an application-level scanner plugin and a remote scanner. The WordPress FAQ recommends using both types because each sees different things. Clean means both come back empty and the file list matches what you expect.

Hours 12–24: rotate credentials and request a review

Rotation comes after cleaning, not before. If the backdoor still runs, it can read the new passwords.

Credential rotation checklist

The key-and-salt step comes straight from the WordPress FAQ: replacing the values forces anyone still logged in out of the session. Any password reused elsewhere changes too. Add two-factor login for every administrator (WordPress, Two Step Authentication).

Next, update core, every plugin and every theme. Then close the specific route you found in hour 1–4. An outdated plugin gets updated or removed. A stolen password gets rotated and protected with 2FA. A vulnerable form gets fixed or disabled. Write one sentence on how they got in. If you cannot write it, you are not done.

Staying clean after today is a routine job. Here is a maintenance checklist that prevents repeat infections, with the weekly and monthly checks that catch the next problem early.

Request the review

Only now, go back to Search Console → Security Issues → Request Review. Google asks for three things in the request: the exact issue, the steps you took, and the outcome (Search Console Help). Fix every listed issue on every page first. Google says partial fixes do not earn a partial return to search results.

Do not resubmit while a request is pending. And do not rush it. Sites that flip between clean and dirty in a short window get marked as Repeat Offenders by Safe Browsing. Repeat Offender status lasts 30 days, and during that time you cannot request another review (Google Safe Browsing Repeat Offenders Policy, as of September 30, 2026). One solid request beats three hopeful ones.

If your host or an email blocklist flagged the domain, contact them separately. Google's review does not clear those.

If customer data was exposed

If the attacker could read customer records — orders, accounts, form submissions — the question changes from cleanup to notification. According to the FTC, all states, the District of Columbia, Puerto Rico and the Virgin Islands have laws requiring notice of breaches that involve personal information (FTC, Data Breach Response, as of September 30, 2026).

Decision line: if personal information may have left the site, stop and call a lawyer before you tell customers anything, then follow the FTC guide and your state's law. This article is not legal advice.