My WordPress site was hacked: the first hour, then how to stop a repeat

The short answer

If your WordPress site was hacked, you can get it back today: take a copy, take the site offline, change every password and WordPress's secret keys, then look for admin accounts and plugins you did not add. After that, restore a clean backup or hand the cleanup to a professional, and if Google flagged the site, request a review in Search Console once it is clean.

WordPress's own help page on hacks starts the same way: "Stay calm." It also says, "Yes, you will recover from this" (WordPress.org). Work through these steps in order. The first four fit in about an hour; the rest take the day.

• Write down what you see and take a copy. Before anything changes, so you can tell later what the hacker did.
• Take the site offline and call your host. Stop visitors seeing it, and find out whether the host already knows.
• Change every password and the secret keys. From a computer you trust, and sign everyone out.
• Check for unknown admins, plugins and files. This is how a hacker gets back in after you clean up.
• Restore a clean backup, or get professional cleanup. A short table below helps you choose.
• Tell Google if it flagged your site. The Security Issues report in Search Console, then a review request.
• Confirm it is clean, then change the passwords again. The last step most people skip.

You need four logins before you start: your WordPress admin, your hosting account, your domain registrar, and the email address that receives WordPress's password resets. If you cannot sign in to WordPress at all, start with your host; they can reset access for you.

1. Write down what you see and take a copy

Spend five minutes noting what made you think the site was hacked, when you noticed it, and anything that changed recently, such as a new plugin or an update. Then take a full copy of the site as it is now, files and database, even though it is infected. WordPress.org recommends both: notes are "the baseline for what is recognized as an incident report", and a copy of the hacked site means you "at least have that bad copy to reference" if the cleanup goes wrong (WordPress.org).

Useful things to write down:

• What you see. Spam pages, a redirect to another site, a warning in Google or the browser, an email from your host, or an admin account you do not recognize.
• When. The date and time you noticed, with your time zone.
• What changed. Plugins or themes installed or updated in the last few weeks, and anyone new who was given a login.

Your host's control panel or a backup plugin can make the copy. Download it to your computer and label it clearly as the hacked copy, so nobody restores it by mistake.

2. Take the site offline and call your host

Put the site into maintenance mode, or ask your host to block public access, so visitors and search engines stop seeing whatever the hacker added. Then open a support ticket and tell the host the site was hacked. On shared hosting, the hack "may have affected more than just your site", and your host can confirm whether it is a hack or an outage (WordPress.org).

Ask your host three things:

If the site has been sending spam email, mention it. WordPress.org warns that email blocklists flag the server's address, and that address is often the one your own email uses (WordPress.org).

3. Change every password and the secret keys

Change the password on every account that can touch the site, from a computer you trust, and then sign everyone out by replacing WordPress's secret keys. WordPress.org lists the access points to cover: "FTP / SFTP, WP-ADMIN, CPANEL (or any other administrator panel you use with your host) and MYSQL", and says this "must include all users that have access" (WordPress.org).

Change them in this order:

1. Your hosting account. It controls everything else.
2. Your domain registrar. Whoever controls the domain controls where your site points.
3. The email account that receives WordPress password resets.
4. Every WordPress administrator, including old ones. Use a long, unique password for each, from a password manager.
5. FTP or SFTP, and the database password. Your host can change these. If the database password changes, it also has to be updated in the site's wp-config.php file, so ask the host to do both together.

Then replace the secret keys. These are random values in wp-config.php that keep people signed in. Changing them "will force anyone that might still be logged in off", including a hacker using a stolen session. WordPress gives you a fresh set at its key generator; you or your host paste them over the old ones (WordPress.org).

Why a computer you trust: WordPress.org notes that some attacks start on the owner's own machine, where malware captures logins. Run a full virus scan on the computer you use for the site before you rely on it (WordPress.org).

4. Check for unknown admins, plugins and files

Look for anything a hacker left behind to get back in: an administrator account you did not create, a plugin you did not install, or files that changed. These are called backdoors, and they are why a hacked site that looks clean gets hacked again a week later. WordPress.org lists "creation of new users" as a clear sign of a hack (WordPress.org).

Check these in your WordPress dashboard:

• Users. Open Users and filter by Administrator. Delete any account you cannot name, and give its posts to your own account when WordPress asks.
• Plugins. Open Plugins and read the whole list, including inactive ones. Remove anything you do not recognize or no longer use.
• Themes. Under Appearance, then Themes, delete every theme except the one you use and one default theme.

Then scan the site. WordPress.org names plugin scanners (Wordfence, Sucuri, Quttera and GOTMLS) and outside scanners that read your public pages (Sucuri SiteCheck and VirusTotal), and says "together you improve your odds greatly" (WordPress.org). A scan that finds changed files in WordPress's own folders, or in a file called .htaccess, is a strong sign the hack goes deeper than one plugin.

If a scan finds nothing but you can still see the problem, trust what you can see. Some hacks only show spam to search engines or to visitors arriving from Google, which is why a search for site: followed by your domain in Google is worth a look. Pages you never wrote are what the hacker added.

5. Restore a clean backup, or get professional cleanup

Restore a backup if you have one from before the hack began and you know roughly when that was; otherwise, hand the cleanup to a professional. Restoring a backup from after the hack started brings the hack back with it, and so does restoring without fixing the way in. Use this table to choose:

Whichever you choose, the update matters as much as the cleanup. If an out-of-date plugin let the hacker in, a restored site with the same plugin is open the same way. WordPress.org's advice once you are clean is to update, because "Older versions are more prone to hacks than newer versions" (WordPress.org).

When you hire help, ask for three things in writing: what they found, what they removed, and how they think the hacker got in. That note is worth keeping. It tells you what to fix so this does not happen again.

6. Tell Google if it flagged your site

If Google shows a warning on your site, open the Security Issues report in Google Search Console, fix every issue it lists across the whole site, then request a review. The report appears when "a Google evaluation determines that your site was hacked", and Google is clear that partial fixes do not count: "Fix the issue throughout your site. Fixing the issue on just some pages will not earn you a partial return to search results" (Google).

1. Sign in to Search Console. If you have never set it up, add your site and verify it; your host or domain registrar can help with the DNS step.
2. Open Security Issues in the left menu and read each issue and its example pages. The list of examples may not be complete.
3. Fix every issue, then check the example pages yourself, logged out.
4. Request a review from the same report. Say what the problem was, what you did, and what you found when you checked.

Then wait, and do not resubmit while a review is pending. Google says "A review can take from a few days to a few weeks to complete" (Google). If the hacker created spam pages, delete them so they return a "page not found" error; Google drops them as it recrawls.

7. Confirm it is clean, then change the passwords again

Run your scans again, look at your Users and Plugins lists once more, and search Google for your domain to check for pages you did not write. When all three come back clean, change every password from step 3 a second time. WordPress.org says to "change the passwords for your site after making sure your site is clean" (WordPress.org), because passwords changed while the hacker still had a way in may already be known.

Before you call it done, check the things your visitors use:

• Forms. Send a test from every contact form and confirm it arrives.
• Key pages. Open your home page and your most visited pages on your phone, logged out.
• Search Console. The Security Issues report shows no issues, or a review is pending.

How to stop a repeat

Keep everything updated, remove what you do not use, add a second sign-in step, and keep backups somewhere other than your web server. Most of this is setup you do once; the rest is a short monthly check.

• Update every week or two. WordPress, plugins and the theme. Turn on automatic updates for plugins you trust, and check the site after each round.
• Remove what you do not use. Every plugin and theme on the server is code someone has to keep patched, active or not.
• Add two-factor sign-in for every administrator, so a stolen password alone is not enough. WordPress.org recommends it (WordPress.org).
• Give out fewer admin accounts. People who only write posts need the Editor or Author role, not Administrator.
• Keep backups off the server. Daily, kept for at least 30 days, stored somewhere a hacker on your server cannot delete them, and test a restore once.
• Do a monthly check. Users list, plugins list, a site: search, and a test of every form. It takes a few minutes and finds the next problem before a customer does.

If keeping up with this is the part you cannot do, that is what WordPress care plans sell. Our guide to WordPress care plans covers what they cover and what they leave out.

Why it can happen again

A hack is rarely bad luck. A WordPress site is WordPress itself plus a set of plugins and a theme, each written by someone different, each needing updates, and each a way in when one falls behind. Patchstack counted 11,334 new WordPress vulnerabilities in 2025, 91% of them in plugins (Patchstack). The steps above lower your risk; they do not take the plugins away. Someone still has to keep patching them, every month, for as long as the site runs.

That is the real problem behind a hacked WordPress site: it is a set of plugins someone has to keep patching, and the cleanup does not change that. The process fix is the monthly check above, plus a written list of every plugin, who installed it and why, so whoever looks after the site knows what to keep updated and what to remove.

For many sites, the right answer is to clean up, follow the list above, and stay on WordPress. Stay if your site is a store, has members or courses, or is built around one plugin's feature: those sites need WordPress, and a well-kept WordPress site is a reasonable place to be. Stay too if this was a first hack, the cause is found and fixed, and someone now keeps the site updated.

When moving is the better fix

If your site is mostly pages and posts, and this is the second hack or the latest in a run of breakages, the lasting fix is a site with less to patch. EmDash, the open-source CMS from Cloudflare that its makers call "the spiritual successor to WordPress" (emdashcms.com), is built on Astro and "does not run PHP, WordPress themes, or WordPress plugins" (EmDash docs). You sign in with a passkey instead of a password; the docs say passkeys "are phishing-resistant, don't require passwords" (EmDash docs). Plugins from its registry are sandboxed and permission-gated, and an update that asks for more access needs "fresh approval before the new version takes effect" (EmDash docs).

Clean the site first, then move. Importing copies your posts and pages, so spam a hacker added to them comes along unless it is removed. Our EmDash vs WordPress comparison covers what changes for an owner, what gets harder, and who should stay on WordPress.

Bring your WordPress site into the AI era on EmDash and Astro. We check every URL, redirect, form and search detail against your live site before anything changes, and switch only after you approve the preview, with the rollback written down. Once the whole site has moved, there is no WordPress core, theme or plugin left for you to patch. We host the site and email you a monthly certificate listing the checks we ran and what changed. A free, read-only check of your public pages shows whether your site is a good fit and the exact price before you ask.

Want to know where your site stands? Check your site for free.

Frequently asked questions