WordPress Site Hacked? 8 Things to Do Right Now to Fix It

You typed your own domain and got a pharmacy ad. Or Google is showing a red warning page. Or a customer emailed to say your contact form is sending them something strange. Whatever the symptom, the situation is the same: someone else has code running on your website.

The instinct is to start deleting things. Resist it. A hacked WordPress site is a forensics problem before it is a cleanup problem, and the order you do things in decides whether you fix it once or fix it four times. Here are the eight steps, in the order they actually need to happen.

The first hour: contain the damage

1. Put the site into maintenance mode

Do not leave a compromised site serving the public. Every hour it stays up is more visitors exposed to whatever is being injected, more spam pages indexed by Google, and more chance your domain lands on a blocklist that takes weeks to clear. Most hosts have a one-click maintenance or "suspend" toggle. If yours does not, an .htaccess rule that allows only your IP address will do the job in thirty seconds.

This is also the moment to tell anyone who needs to know — if the site takes payments or holds customer accounts, that is not an optional courtesy, and depending on where your customers live it may be a legal obligation with a clock attached.

2. Take a full backup before you change anything

This feels wrong. You are about to back up an infected site. Do it anyway.

That backup is your only evidence. It contains the attacker's files, their timestamps, and the modified versions of your own files — the entire record of how they got in. If you clean first and discover next week that the site is reinfected, without that snapshot you are guessing. Copy the full file tree and export the database, then store both somewhere off the server and clearly labelled as infected so nobody restores it by accident.

3. Change every credential, in the right order

Hosting control panel first, then SFTP and SSH keys, then the database user, then WordPress admin accounts, then anything the site connects to — payment gateways, mail services, APIs. Doing WordPress passwords first is the common mistake: if the attacker still holds your SFTP credentials, they simply put the back door back.

While you are in the users list, look for accounts you do not recognise. Attackers routinely create a second administrator with a plausible name so that losing one foothold does not cost them access. Delete them — but note the details first, because the registration date narrows down when the breach happened.

The cleanup: remove the infection, not just the symptom

4. Replace core, themes and plugins wholesale

Do not hunt line by line through WordPress core for injected code. Download a fresh copy of the same version and replace wp-admin and wp-includes outright. Do the same for every theme and plugin, taking clean copies from the official source rather than trusting what is on the server.

Two folders survive this: wp-content/uploads, which holds your media, and your wp-config.php, which holds your settings. Both need to be inspected by hand. The uploads folder is where PHP files love to hide, and there is never a legitimate reason for a .php file to live in uploads. Search for them and delete every one you find.

5. Clean the database

File cleanup alone misses a common class of infection. Check wp_options for unfamiliar entries, especially anything auto-loading, and scan wp_posts for injected scripts and hidden link blocks in old published content. Spam pages are frequently written straight into the posts table where they will not appear in your admin menus but will happily rank in Google.

6. Scan again with something you did not use the first time

Run a reputable scanner, then run a second one from a different vendor. Every scanner has blind spots and they are not the same blind spots. When both come back clean and you have manually confirmed no stray PHP in uploads, you are ready to bring the site back.

Why it happened — and how to make it not happen again

7. Find the entry point

Skip this step and you will do the whole thing again in a fortnight. In practice there are four usual doors.

• An outdated plugin or theme. By far the most common. A vulnerability is disclosed publicly, a patch ships, and sites that have not updated within a few days get scanned and hit automatically. Nobody chose you.
• Nulled or pirated premium plugins. The back door is the business model.
• Weak or reused admin passwords. Brute force still works because people still use passwords they have used elsewhere.
• Shared hosting cross-contamination. A neighbouring site on the same server gets compromised and the infection walks across.

Your server access logs will usually tell you which. Look for the first appearance of any file you deleted during cleanup, then look at what requests preceded it.

8. Harden the site properly

Once you are clean, close the doors: enforce two-factor authentication on every administrator account, disable the file editor in the WordPress dashboard, put a web application firewall in front of the site, restrict access to wp-login.php, and set core, plugin and theme updates to apply automatically for security releases.

None of this is exotic. All of it is boring, which is precisely why it stops getting done. That is the honest argument for treating security as a standing monthly routine rather than an emergency response — updates applied within days rather than months, backups verified by actually restoring one occasionally, and someone looking at the logs. Our website maintenance service exists because the cost of that routine is a rounding error next to the cost of a week of downtime and a Google blocklisting.

Frequently asked questions

How long does it take to clean a hacked WordPress site?

A straightforward infection caught early is usually a few hours of focused work. One that has been sitting for months, has spread across several sites on the same server, or has triggered a Google Safe Browsing flag can take several days — most of that spent on reinfection checks and getting the warning lifted.

Should I just restore from a backup?

Only if you are confident the backup predates the breach, and most people are not. Infections often sit dormant for weeks before they do anything visible, which means your recent backups are infected too. Restoring an old clean backup also throws away every order, comment and content change since then. Clean forward when you can; restore only when the backup date is genuinely known to be safe.

Will being hacked hurt my SEO?

It can, and how much depends almost entirely on speed. Spam pages that get indexed, or a Safe Browsing warning that sits for days, do real damage to rankings and to click-through even after removal. Caught and cleaned within a day, most sites recover without lasting harm.

Is WordPress inherently insecure?

No. WordPress powers a large share of the web, which makes it a large target, but the core software is actively maintained and patched. The overwhelming majority of compromises come from unmaintained plugins, pirated themes and weak credentials — none of which are WordPress's doing. A well-maintained WordPress site is not the weak link people assume it is.

The short version

Contain, back up, rotate every credential, replace core and extensions wholesale, clean the database, scan twice, find the entry point, then harden. The step people skip is the seventh, and it is the only one that determines whether you ever have to read this article again.

Book a free consultation — let's talk about your project. trodad.com/appointment