Your WordPress site is hacked. Here is what to do, in order.

First, confirm you are actually hacked

A surprising number of panics are something else. A plugin conflict, an expired certificate, a caching layer serving a stale page, or a host moving you to a new server. It is worth spending ten minutes proving the problem before you start pulling things apart, because half the damage on a bad cleanup is self-inflicted.

Signs that usually do mean an infection:

• A red interstitial in Chrome or Safari saying the site is deceptive or contains malware. That is a blocklist entry, and it is serious.
• Pages that look normal to you and wrong to everyone else. Injected content often hides from logged-in administrators and from visitors on your own network. Check in a private window on mobile data.
• Search results showing pages you never wrote. Search your domain in Google with the site prefix. Pages about pharmaceuticals, streaming, or gambling in a language you do not publish in are the classic spam injection.
• Redirects that only fire from search. Type the address directly and it is fine. Click it from a Google result on a phone and you land somewhere else. That conditional behaviour is deliberate and is very common.
• Administrator accounts you did not create, or a scheduled task running at an odd hour.
• Your host suspending the account for outbound spam or CPU abuse. Hosts see the traffic before you see the symptom.

Signs that usually do not: a single plugin throwing an error, a blank white page after an update, a certificate warning about an expired certificate, or slow loading on its own. Those have ordinary causes and ordinary fixes.

The first hour

Do these in order and resist the urge to skip ahead to deleting files. The goal in the first hour is to stop the bleeding and preserve evidence, not to clean.

• Take a full backup, infected as it is. Files and database both. This feels wrong and it is the most important step. You will need it to work out how they got in, and you will need it when a cleanup goes too far and takes real content with it.
• Tell your host. They can see server logs you cannot, they often know if it is spreading across accounts, and they can put a temporary hold on outbound mail so your domain stops being reported.
• Change every password. WordPress administrators, the hosting control panel, the database user, and any file transfer accounts. Change the ones on your own computer too if you have ever saved them into a client.
• Force everyone to sign out. Rotating the authentication keys in the site configuration invalidates every existing session, which matters because a stolen session cookie survives a password change.
• Do not delete anything yet. The urge is enormous. Deleting the visible symptom before you understand the mechanism just teaches you nothing and leaves the entry point open.

Where the infection actually lives

People assume malware is a file sitting in a folder with an obvious name. Sometimes it is. More often it is spread across four or five places so that removing any one of them does nothing, and the site reinfects itself within hours. That reinfection loop is why so many do-it-yourself cleanups fail on the second day.

The usual hiding places, roughly in order of how often we find them:

• Core files that should never change. WordPress ships a known set of files. Any difference between yours and the official release for your version is a red flag, and comparing them is the fastest honest test available.
• The uploads folder. It is meant to hold images. Anything executable in there is either a mistake or a backdoor, and it is a favourite because uploads are usually writable and rarely inspected.
• Theme files, especially an inactive theme. Nobody looks at the theme they stopped using two years ago, and it still sits on the server where it can be reached directly.
• The database. Injected scripts in post content, in site options, and in widget settings. A file-only cleanup misses all of it and the pages stay poisoned.
• Scheduled tasks. A task that runs every few hours and rewrites the files you just cleaned. This is the single most common reason a site comes back infected.
• Server configuration files. Rules that redirect visitors arriving from search while leaving direct visits alone. This is how a site looks fine to the owner for weeks.
• Extra administrator accounts, sometimes with names designed to look like a plugin or a service account.

Cleaning it properly

A real cleanup has a shape. Deviating from it is what produces the sites we get called about on the third attempt.

• Replace rather than repair. Core files, themes and plugins all get replaced with clean copies from source at the matching version. Do not try to edit malicious code out of a file. You will miss something and you will never be sure.
• Rebuild anything customised, deliberately. If somebody edited a theme file directly, that customisation has to be identified and rewritten in a place that survives updates, which is usually a child theme.
• Clean the database by hand. Search for injected script tags and encoded blocks across post content, options and metadata. Automated find and replace on a live database without a verified backup is how people lose a shop's product catalogue.
• Remove the persistence. Scheduled tasks, unknown administrator accounts, unexpected configuration rules. If this step is skipped, everything before it is temporary.
• Find the entry point. An outdated plugin with a known vulnerability, a weak administrator password, a reused hosting password, or a neighbouring site on the same shared account. If you never establish which, you are guessing about whether it is fixed.
• Watch it for a week. Reinfection almost always shows up within days. A cleanup that has not been rechecked is a cleanup that has not finished.

Getting off the Google blocklist

If browsers are showing a red warning, cleaning the site is only half the work. The warning is served from a list, and the list has to be told you are clean. Until that happens your traffic stays near zero no matter how spotless the server is.

The sequence:

• Verify ownership in Google Search Console if you have not already. Nothing else can happen until you can prove the domain is yours.
• Read the security issues report. It names the category, sometimes lists sample affected addresses, and those samples are the fastest route to anything the cleanup missed.
• Finish the cleanup properly first. A failed review is worse than no review, because repeat failures lengthen the wait on later attempts.
• Request a review and describe what you did. Plain sentences: what was found, what was removed, how the entry point was closed. A serious description gets treated seriously.
• Wait. Usually a few days. Do not submit again while one is pending.

Expect a recovery period after the warning lifts. Rankings usually come back over a few weeks rather than immediately, and there is nothing to do in that window except keep the site clean and fast.

Hardening so it does not happen again

The vast majority of WordPress infections are opportunistic. Automated software crawls the web looking for known vulnerabilities in out of date plugins, then exploits whatever it finds. Almost nobody is targeted personally. That is good news, because it means ordinary maintenance defeats most of it.

• Update on a schedule you actually keep. Once a month, in a calendar entry, with a backup taken first. Most compromised sites we see were running a plugin with a public vulnerability that had been patched months earlier.
• Delete what you are not using. Every deactivated plugin and unused theme is still code sitting on the server. Deactivated is not the same as absent.
• Fewer administrators. Most people who need access need an editor account. Administrator is for the person who maintains the site, and that is usually one person.
• Two-factor on every administrator, plus unique passwords out of a password manager. Password reuse across the site, the host and email is how a single unrelated breach becomes your problem.
• Automatic offsite backups. Files and database, stored somewhere other than the server they came from, and restored once as a test. An untested backup is a hope.
• Do not stack four security plugins. They fight, they slow the site down, and the aggregate protection is worse than one configured properly.

When it is worth paying somebody

Plenty of owners can do this themselves. The steps are not secret, and a small site with a recent clean backup and a single injected file is a reasonable evening's work.

It is worth handing over when any of these are true: the site is on a blocklist and your traffic is gone today, it has been cleaned once already and come back, you take payments or hold customer records, you cannot find a backup from before the infection, or the site is how the business actually gets paid and every day offline has a number attached.

What we charge depends on how far it spread. A standard cleanup with a single entry point is $800. A site that also needs blocklist recovery and reputation work is $1,750. A full recovery, where multiple sites on the account are affected or the infection has been in place long enough to be tangled into the content, is $3,500. The look that tells us which of the three it is costs nothing, and if the site turns out to be clean we say so and charge nothing.