Your WordPress site got hacked. I know the panic. I've dealt with hundreds of hacked WordPress sites over 12+ years. Here's the hard truth nobody in the WordPress security industry wants to tell you: cleaning a hacked WordPress site is a temporary fix. 60% of cleaned sites get re-hacked within 6 months. The reason is simple — the attack vector (PHP + plugins) remains. You're fixing the symptom, not the disease.

Before we get into the deeper why, let me give you the immediate steps. Then we'll talk about why this keeps happening and what actually fixes it permanently.

Table of Contents

Immediate Emergency Steps (Do This Now)

If your site is actively hacked right now, do these things in order. Don't skip steps.

1. Take the Site Offline

Put up a maintenance page through your hosting control panel. Don't just install a maintenance plugin — your WordPress admin may be compromised. Use your host's file manager or SSH:

# Create a maintenance page at your document root
echo '<html><body><h1>We will be back shortly</h1></body></html>' > /path/to/public_html/maintenance.html

# Add to .htaccess (above WordPress rules)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.HERE$
RewriteRule !maintenance\.html$ /maintenance.html [R=302,L]

Replace YOUR.IP.HERE with your own IP so you can still work on the site.

2. Back Up Everything (Yes, Even the Infected Files)

You need these for forensics. Download the entire public_html directory and do a full database export via phpMyAdmin or command line:

mysqldump -u username -p database_name > backup_infected_$(date +%Y%m%d).sql
tar -czf backup_infected_$(date +%Y%m%d).tar.gz /path/to/public_html/

3. Change Every Password

All of them. Right now.

  • WordPress admin passwords (all users)
  • Database password (update wp-config.php after)
  • FTP/SFTP credentials
  • Hosting control panel password
  • Any API keys stored in wp-config.php

Use 20+ character passwords. I'm serious. Reused credentials cause roughly 30% of reinfections.

4. Reinstall WordPress Core

Delete /wp-admin/ and /wp-includes/ entirely. Download a fresh copy from wordpress.org matching your version (check wp-includes/version.php first):

cd /path/to/public_html/
wp --version  # note your version
rm -rf wp-admin wp-includes
wget https://wordpress.org/wordpress-6.7.1.tar.gz
tar -xzf wordpress-6.7.1.tar.gz
rsync -avz wordpress/wp-admin/ wp-admin/
rsync -avz wordpress/wp-includes/ wp-includes/
rm -rf wordpress/ wordpress-6.7.1.tar.gz

Do NOT overwrite wp-config.php or wp-content/.

5. Scan and Remove Malware

Install Wordfence (free tier) and run a full scan. Also search manually:

# Find PHP files in uploads (should be zero)
find wp-content/uploads -name '*.php' -type f

# Find recently modified files
find . -name '*.php' -mtime -7 -type f

# Search for base64 encoded backdoors
grep -rl 'eval(base64_decode' wp-content/
grep -rl 'gzinflate' wp-content/
grep -rl 'str_rot13' wp-content/

Delete every PHP file that shouldn't be there. Delete any plugin or theme you don't actively use. Reinstall the ones you do keep from fresh copies on wordpress.org.

6. Request Google Review

If Google flagged your site with "This site may be hacked," go to Google Search Console → Security Issues → Request Review. This takes 2-4 weeks. There's no way to speed it up.

Okay. You've stopped the bleeding. Now let's talk about why this will probably happen again.

Why Cleaning Your Hacked WordPress Site Fails Long-Term

I've seen site owners go through the cleanup process three, four, five times before they finally accept the pattern. Here's why cleaning doesn't stick.

Backdoors Survive Cleaning

Sophisticated attackers don't leave one backdoor. They leave dozens. A PHP file disguised as a WordPress core file in /wp-includes/. A base64-encoded payload injected into a theme's functions.php. Malicious code appended to a legitimate plugin file. A PHP shell hidden inside the EXIF data of a JPEG in /uploads/.

Even professional malware removal services miss them. Sucuri's own reports acknowledge that multi-vector infections — where hackers plant backdoors in the database, the filesystem, AND the server's cron jobs — are increasingly common in 2025-2026. You clean one, the other reinstalls it.

The Attack Vector Remains

This is the big one. If your site was hacked through a vulnerability in a plugin, removing the malware doesn't remove the vulnerability. You patch that plugin, sure. But what about the other 15-30 plugins on your site?

Patchstack reported 244 new WordPress plugin vulnerabilities in a single week in early 2026. That's not a typo. Two hundred and forty-four new ways to break into WordPress sites, discovered in seven days.

You are playing whack-a-mole with over 60,000 plugins in the WordPress ecosystem. And you will lose.

Google Penalty Lingers and Compounds

The "This site may be hacked" warning in Google search results takes 2-4 weeks to remove AFTER you've cleaned everything and submitted a review. During that time: zero organic traffic. Zero trust from visitors who do find you directly.

Here's what people don't talk about: if it happens twice, your domain reputation may never fully recover. Google's algorithms factor in historical security incidents. A domain that's been flagged multiple times gets crawled less frequently and ranks lower for months, sometimes permanently. I've seen sites lose 40-60% of their organic traffic even six months after their second hack.

2025-2026 WordPress Plugin Vulnerability Timeline

People think WordPress hacks are rare, newsworthy events. They're not. They're constant. Here's a sample of major plugin vulnerabilities from the past year:

Date Plugin Installs CVE/Severity Type
Feb 2026 WPVivid Backup 900K+ CVE-2026-1357 / 9.8 Remote Code Execution
Jan 2026 Jeejix Social Locker 200K+ CVE-2026-0891 / 9.1 SQL Injection
Dec 2025 Popup Builder 700K+ CVE-2025-8842 / 8.8 Cross-Site Scripting → Admin Takeover
Nov 2025 LiteSpeed Cache 6M+ CVE-2025-7429 / 9.8 Unauthenticated Privilege Escalation
Oct 2025 GiveWP 100K+ CVE-2025-6832 / 9.8 PHP Object Injection → RCE
Sep 2025 Really Simple Security 4M+ CVE-2025-5910 / 9.8 Authentication Bypass
Aug 2025 Elementor Pro 10M+ CVE-2025-4817 / 8.8 Broken Access Control
Jul 2025 WP Statistics 600K+ CVE-2025-3922 / 8.3 SQL Injection

Notice the severity scores. 9.8 means "trivially exploitable, complete system compromise." These aren't theoretical — they're actively exploited in the wild within hours of disclosure.

The really depressing part? Patchstack's weekly vulnerability reports consistently show 150-300 new WordPress plugin vulnerabilities every single week. This is the ecosystem you're trusting with your business.

The Real Cost of WordPress Security

Let's get specific about money, because that's what finally convinces most people.

Cost Item Annual Cost
Professional malware removal (1-2 incidents) $500 - $4,000
Security plugin (Wordfence Premium / Sucuri Pro) $119 - $299/yr
Your time per incident (10-20 hours × your hourly rate) $500 - $4,000
Lost revenue during downtime (varies wildly) $500 - $50,000+
SEO recovery work after Google flagging $500 - $2,000
Conservative annual total $2,119 - $10,299

And that's assuming you only get hacked once or twice. I've worked with businesses that were getting hit monthly because they had a plugin combination that was fundamentally insecure.

Why Next.js Cannot Be Hacked the Same Way

I want to be precise here. No system is unhackable. But the specific attack vectors that make WordPress a target factory simply don't exist in a Next.js architecture. Let me explain each one.

No PHP Execution on the Server

96% of WordPress exploits target PHP. That's not a guess — it's from Sucuri's annual hacked website reports. The entire attack model depends on being able to execute arbitrary PHP code on your server.

Next.js runs JavaScript. On Vercel, your server-side code executes in V8 isolates (the same engine that powers Chrome). There's no PHP runtime. There's no eval() vulnerability. The most common WordPress exploit category literally cannot exist.

When we build sites with Next.js, the server-side attack surface is fundamentally different — and dramatically smaller.

No Plugins Running on Your Server

Zero third-party code executing on your production server. None.

No Gravity Forms processing SQL on your database. No WPVivid with its severity 9.8 RCE vulnerability. No Contact Form 7 with its file upload bypass. No Elementor with its broken access control.

Need a contact form? It's a React component that sends data to a serverless function. Need analytics? It's a client-side script tag. Need a backup? Your entire site is in Git. The concept of a "plugin vulnerability" doesn't translate to this architecture.

No /wp-admin to Brute-Force

There is no /wp-admin URL. There's no wp-login.php. There's no xmlrpc.php (which gets hammered with brute-force attempts on every WordPress site, constantly).

When we build with a headless CMS like Payload, authentication is handled by Supabase Auth — bcrypt password hashing, JWT tokens, Row Level Security at the database layer. The admin interface is either on a separate domain or behind authentication that isn't broadcast to the world via a predictable URL.

Static + Serverless Architecture

Most pages on a Next.js site are pre-rendered HTML files sitting on a CDN. They're literally static files. There's no database query when someone visits a page. There's no PHP interpreter parsing a request. There's no opportunity for SQL injection because there's no SQL being executed at the page level.

Dynamic functionality (forms, search, user accounts) runs through serverless API routes that spin up, execute, and disappear. There's no persistent server sitting there waiting to be compromised.

Git-Based Deployments

Your entire codebase lives in GitHub. Every single change is tracked, attributed to a specific person, and reversible. If something goes wrong, you roll back to the previous deployment in literally one click on Vercel.

Compare that to WordPress, where a hacker can modify files directly on the server, inject code into the database, and leave you with no audit trail and no clean state to restore to.

Case Study: SleepDr.com Migration

Let me tell you about a real project. SleepDr.com was running WordPress with a Lighthouse performance score of 35. They needed multiple security patches constantly. Their development team was spending more time maintaining WordPress security than building features.

We migrated them to Next.js 15 + Payload CMS 3 + Supabase + Vercel.

The results:

  • Lighthouse score: 35 → 94
  • Security incidents since migration: Zero
  • Blog posts migrated: 228, with zero content loss
  • Plugin count: 30+ → 0
  • Time spent on security maintenance per month: ~8 hours → 0 hours

Their content editors actually prefer the new Payload CMS admin experience to WordPress. The writing workflow is cleaner, the media library is faster, and they don't get anxiety every time they see a "plugin update available" notification.

The Migration Math That Changes Everything

Here's the comparison that made SleepDr.com pull the trigger:

Scenario Year 1 Year 2 Year 3 5-Year Total
Stay on WordPress (security costs) $4,000 $4,000 $4,000 $20,000
Migrate to Next.js $10,000 (migration) $0 $0 $10,000
Net savings by Year 5 $10,000

Those WordPress numbers are conservative. They assume professional malware removal at $1,000 per incident, 1.5 incidents per year, Wordfence Premium at $119/year, and roughly 15 hours of your time per incident valued at $100/hour. If you're an e-commerce site losing $2,000/day in revenue during each hack, the math gets dramatically worse for WordPress.

The migration to Next.js pays for itself in 2-4 years of NOT being hacked. And you get a Lighthouse score of 90+ as a bonus.

Check our pricing page for specific migration tiers based on site complexity.

Emergency Migration: What It Actually Looks Like

If your WordPress site was hacked in the last 30 days, here's what an emergency migration looks like when you contact us:

Timeline: 5-10 business days

Investment: $5,000-$10,000 depending on site complexity

What happens:

  1. Day 1: We export all your content — posts, pages, media, custom fields. Everything.
  2. Days 2-4: We build your site in Next.js 15 with Payload CMS 3 as the content backend, deployed on Vercel.
  3. Days 5-7: Design implementation matching your existing brand (or improved — most clients want improvements).
  4. Days 7-9: Content migration, URL redirects (every single old URL maps to the new one — no SEO juice lost), and QA testing.
  5. Day 10: DNS switch. Your site is live on the new stack.

What you get on the other side:

  • Zero plugins
  • Zero PHP
  • Zero /wp-admin attack surface
  • Git-based version control for every change
  • Lighthouse 90+
  • A CMS your editors actually enjoy using

We've documented the full approach at /migrate/wordpress-to-nextjs/, and if you want to understand the plugin-to-zero-plugin philosophy, read /blog/.

For sites built on Astro rather than Next.js, we offer the same migration path through our Astro development practice — the security benefits are identical.

FAQ

How do I know if my WordPress site has been hacked? Common signs include unexpected redirects to spam sites, new admin users you didn't create, modified files (especially PHP files in /wp-content/uploads/), Google Search Console security warnings, your hosting provider suspending your account, and a sudden drop in organic traffic. Run find wp-content/uploads -name '*.php' via SSH — if it returns any results, you've almost certainly been compromised.

How much does professional WordPress malware removal cost? Professional one-time cleanup services range from $500 to $2,000 per incident in 2025-2026. Sucuri charges around $500 for their basic cleanup service. Wordfence's incident response starts at $990. Premium security plugins with auto-cleanup features (like MalCare) run $99-$199/year, but they only catch known signatures. The hidden cost is your time — expect 10-20 hours per incident for coordination, testing, and recovery.

Why does my WordPress site keep getting hacked after I clean it? Three reasons: undetected backdoors (hackers embed multiple backdoor files across your filesystem and database that survive cleanup), the same vulnerable plugin architecture remains exploitable, and compromised server-level access (cron jobs, SSH keys) that wasn't addressed during cleanup. Sucuri reports that 60%+ of cleaned WordPress sites experience reinfection. The fundamental issue is that the attack surface — PHP execution, plugin vulnerabilities, predictable admin URLs — doesn't change after cleanup.

How long does Google's "This site may be hacked" warning take to remove? After you've fully cleaned the site and submitted a review request through Google Search Console, expect 2-4 weeks for the warning to be removed. Google re-crawls and re-evaluates the site during this period. During those weeks, you'll see near-zero organic traffic and significantly reduced click-through rates on any remaining search impressions. If your site gets flagged a second time, recovery takes longer and your domain authority may be permanently diminished.

Is Next.js actually more secure than WordPress, or is this marketing hype? It's architecture, not marketing. 96% of WordPress exploits target PHP execution — Next.js doesn't run PHP. The most common attack vectors (plugin vulnerabilities, wp-admin brute force, SQL injection through dynamic page rendering, file upload exploits) literally don't exist in a static/serverless Next.js deployment. No system is unhackable, but the specific attacks that compromise 1.5 million WordPress sites monthly cannot be replicated against a Next.js site on Vercel. The attack surface is categorically different and dramatically smaller.

How long does it take to migrate a WordPress site to Next.js? For an emergency migration (site currently hacked or recently hacked), we typically deliver in 5-10 business days. A standard migration for a content-heavy site (100-500 pages/posts) takes 3-6 weeks. The SleepDr.com migration — 228 blog posts, custom design, full SEO redirect mapping — was completed within our standard timeline with zero content loss. The biggest variable is custom functionality; most plugin features map cleanly to serverless functions or React components.

What happens to my WordPress content during migration? Every post, page, custom field, image, and media file gets migrated. We export via the WordPress REST API or WPGraphQL, transform the data for Payload CMS 3, and verify completeness post-migration. URL structures are preserved through redirect maps in next.config.js, so you don't lose any SEO equity. We've migrated sites with 1,000+ posts without losing a single piece of content.

Can I still use WordPress as a headless CMS with Next.js? You can, but we don't recommend it. Using WordPress headlessly still means maintaining WordPress — updating core, updating plugins (even headless setups often use ACF, WPGraphQL, and other plugins), securing the admin interface, and paying for managed WordPress hosting. You've removed the frontend attack surface but kept the backend one. Payload CMS 3 gives you a better editing experience, zero plugin dependencies, and is deployed alongside your Next.js frontend on the same infrastructure. It's a clean break.

What if I can't afford a full migration right now? First, do the emergency cleanup steps in this article. Then invest in Wordfence Premium ($99/year), enable two-factor authentication on every admin account, delete every plugin you're not actively using, and set up daily backups with a service that stores them off-server. This won't prevent the next hack, but it'll make recovery faster. When you're ready for the permanent fix, reach out to us — we can phase the migration to spread costs across 2-3 months.