Fix a Hacked WordPress Site Fast.

If your WordPress site is suddenly redirecting to spam, showing strange pop-ups, or your hosting has flagged malware, treat it like a break-in. Your priority is not cosmetics. Your priority is stopping further damage, keeping access, and getting back to a known-good state without leaving the door open.

This is a practical runbook to fix hacked wordpress site incidents for small to mid-sized NZ businesses. It is written for speed, not theory.

First 30 minutes: contain the damage

Start by assuming the attacker still has a way back in. If you begin “cleaning” before containment, you can waste hours and get reinfected.

Put the site into a maintenance mode page if you can do it safely. If the hack is actively serving malicious content, it is often better to block public access temporarily than keep leaking visitors to spam or getting your domain blacklisted.

If you are using Cloudflare, enable “Under Attack” mode and add a WAF rule to challenge or block suspicious paths (common ones are wp-login.php, xmlrpc.php, and random-looking PHP file names in wp-content). If you are not sure what is safe to block, start with rate limiting the login page rather than hard-blocking it.

Take a full snapshot now: site files and database. Do not skip this. You need a point-in-time copy for forensics and for the “we cleaned it and it broke something” moment later. If your host offers snapshots, take one. If you have SSH access, archive the web root and export the database.

Then change credentials immediately, starting with hosting control panel, SSH/SFTP, database user, and WordPress admin accounts. Use a password manager and unique passwords. If you share logins between staff, stop doing that today.

Confirm what kind of hack you are dealing with

“Hacked” can mean a few different things, and the fix depends on which one you have.

If you see redirects only on mobile, or only from Google results, that points to conditional malware, often injected into theme files, mu-plugins, or the database. If the site has new admin users you did not create, your WordPress credentials or a vulnerable plugin is likely involved. If only a single page is defaced, you may be dealing with a compromised file rather than full access.

Check these quickly:

• WordPress Users: look for new administrators and strange email addresses.
• Plugins: anything you do not recognise, anything recently added, or anything that looks like a “security” plugin you did not install.
• File Manager/FTP: recently modified PHP files, especially under wp-content/uploads (uploads should not normally contain PHP).
• Search Console warnings and hosting malware notices if you have them.

Do not spend an hour diagnosing. The point is to decide whether you can clean in place or you should rebuild from a clean backup.

Decide: clean in place or restore and rebuild

Cleaning in place is tempting. It is also where businesses burn time and end up with a site that keeps getting reinfected.

If you have a known-good backup from before the incident and your site is not heavily transactional (for example, no constant order flow or bookings stored only in the database), restoring is usually faster and more reliable. The trade-off is data loss between the backup time and now.

If you do not have a trustworthy backup, or you cannot lose recent transactions, you may need to clean in place and then rotate every credential.

A third option is often the best: restore files from a clean backup, then selectively merge database content you must keep (recent orders, form submissions) after you have validated the database is not carrying the infection. This takes more care, but it reduces the chance you reintroduce the malware.

Fix a hacked WordPress site: the clean rebuild method

This method assumes you can restore to a pre-hack backup or rebuild from clean sources.

Start with a fresh WordPress core. Do not trust existing core files. Delete wp-admin and wp-includes and replace them with a clean copy of the same WordPress version (or the latest, if you are confident your theme and plugins are compatible). Core files should match official checksums.

Next, reinstall your theme and plugins from clean sources. Do not copy old plugin folders across “because it is faster”. If a plugin is abandoned, replace it. Abandoned plugins are one of the most common re-entry points.

Then restore wp-content selectively:

• Keep uploads (images, PDFs) but scan for PHP files and unexpected executables.
• Treat mu-plugins and custom plugins as code you must review.
• Treat any custom theme code as potentially compromised until checked.

Finally, restore the database, but do not assume it is clean. Scan wp_options, wp_posts, and any plugin tables for injected scripts. Common patterns include base64_decode, eval, gzinflate, and long obfuscated strings inside option values.

If you find injected content in the database and you are not confident cleaning it without breaking the site, restore an older database and manually re-enter only the critical recent content.

Fix a hacked WordPress site: the clean-in-place method

If you cannot restore cleanly, you are going to remove access, remove persistence, and then clean.

First, remove any unknown admin users and reset passwords for all real users. If you can, enforce 2FA for admins. Then disable file editing in wp-config.php (set DISALLOW_FILE_EDIT to true) to prevent quick edits via the dashboard.

Second, remove persistence. Look for these common footholds:

• wp-content/mu-plugins: attackers love it because it loads on every request.
• wp-cron abuse: malicious tasks scheduled to reinfect files.
• rogue PHP in uploads: a classic webshell location.
• .htaccess rules injecting redirects or allowing execution where it should not.

Third, clean the code. Replace WordPress core as described above. Then remove and reinstall every plugin and theme. If you have custom code, diff it against version control if you have it. If you do not, review changes by modified date and look for obfuscated snippets.

Fourth, clean the database. Search and remove injected JavaScript, iframe tags, and suspicious option values. Be careful: automated “search and replace” can break serialised data. If you are not familiar with serialised values in WordPress, use a tool that understands them or get help.

After cleaning, clear all caches: WordPress cache plugins, Cloudflare cache, server cache. Otherwise you will think the site is still infected when you are just seeing cached junk.

Close the hole so it does not happen again

Once the site looks clean, assume you are still vulnerable until you fix the entry point.

Update everything: WordPress core, plugins, themes. Remove anything unused. If you are running old PHP, plan an upgrade. Old PHP versions are not just slower - they reduce your ability to run supported, patched software.

Lock down login and admin access. If you can restrict wp-admin by IP for staff locations, do it. If you cannot, at least add strong rate limiting and 2FA. Disable XML-RPC if you do not need it, or restrict it to known services.

Review file permissions. WordPress should not need to write to most PHP files. If your setup requires FTP-based updates, consider moving to a model where updates are managed via proper server permissions and controlled deployment, not ad-hoc edits.

Check your hosting posture. If you are on cheap shared hosting with no isolation, you can get compromised by a noisy neighbour. If you are running a VPS, ensure it is patched, has a firewall, and has malware scanning and monitoring in place. If you a stack like Digital Ocean with RunCloud, make sure your server security settings and SSH access are controlled and logged.

Prove you are clean

Do not stop at “the homepage loads”. You need confidence before you put real traffic back through the site.

Manually test key pages on mobile and desktop, in private browsing, and from a different network. Hackers often use conditional redirects that only trigger under certain conditions.

Check server logs for repeated POST requests to wp-login.php, attempts to access wp-config.php, and hits to strange PHP files in wp-content. If you are using Cloudflare, review the Security events and WAF hits for patterns.

If Google has flagged the site, address it properly. Clean up, then request a review in Search Console. If you run paid ads, expect disapprovals until the site reputation recovers.

When to stop DIY and hand it off

If any of these are true, it is usually faster and cheaper to get a specialist involved:

• You cannot identify the entry point and reinfection keeps happening.
• The database contains widespread injected content and you are unsure how to clean serialised values.
• The site handles payments, medical information, or sensitive client data.
• You have no clean backups and the site is business-critical.

A proper fix is not just deleting a few files. It is containment, clean restoration, credential rotation, and hardening, plus monitoring so you find out quickly if something changes.

If you want this handled end-to-end in the Bay of Plenty, Responsive can take over cleanup, hardening, and ongoing maintenance so the site stays fast and stable across mobile, tablet, and desktop.

What to set up after the incident

If this incident surprised you, your process needs tightening, not just your passwords.

You want automatic updates where safe, scheduled maintenance where it is not, uptime monitoring, and alerting that reaches a real person. You also want backups that are tested, not just “enabled”. A backup you cannot restore is not a backup.

Finally, keep a simple change log. When something breaks or gets compromised, the fastest path back is knowing what changed, when, and by whom.

The goal is not to build an unhackable site. The goal is to make a compromise unlikely, quickly detected, and boring to recover from.