10 Steps to Recover from a Hacked Website

1. Contain first, investigate second

The instinct is to open the site in a new tab and poke around. Don’t. Every additional request to a compromised site gives the attacker more opportunities to exfiltrate data, inject additional payloads, or log your session. The first action is containment.

If your host offers one-click site disable (Cloudflare “Under Attack” mode, managed WordPress maintenance mode, cPanel “Disable Site”), enable it immediately. Otherwise, contact your host — most providers can take a site offline within minutes of a support request. Point DNS at a 503 Service Unavailable placeholder page hosted somewhere other than the compromised server (a static file on Cloudflare Pages, Netlify, or Vercel works fine). The 503 response tells Google to pause indexing temporarily without assuming the site is gone permanently — which is what 404 or 410 responses would signal.

While you’re containing, rotate credentials from a clean machine:

• CMS admin passwords
• FTP / SFTP / SSH credentials
• Database root and application user passwords
• Hosting control panel (cPanel, Plesk, managed host dashboard)
• Domain registrar (critical — a compromised registrar allows DNS hijacking)
• Any third-party integrations with API keys (Stripe, Mailchimp, cloud storage, Search Console service accounts)

Enable multi-factor authentication everywhere it isn’t already on. If the attack involved a stolen admin credential, the new password alone isn’t enough.

2. Tell your host and engage expert help

Notify your hosting provider immediately. Shared hosts in particular will want to check neighboring accounts on the same server, and many hosts have incident-response teams that handle cleanup as part of your plan. Managed WordPress hosts (Kinsta, WP Engine, Cloudways, Pantheon) typically offer free incident-response and malware cleanup for severe compromises.

For sites where cleanup is beyond in-house capability, engage a specialist:

• Sucuri — the best-known site-cleaning firm; offers flat-fee emergency cleanup and ongoing WAF protection.
• Wordfence Care / Wordfence Response — WordPress-focused cleanup and incident response from the Wordfence team.
• Patchstack — WordPress vulnerability detection and virtual patching.
• MalCare — automated WordPress malware detection and one-click removal.

Pick one — don’t stack multiple security vendors doing the same job. The wrong time to compare prices is mid-incident; have a relationship established before you need it.

3. Verify (or re-verify) ownership in Search Console

Open Google Search Console — renamed from Google Webmaster Tools back in May 2015 — and confirm you are still listed as a verified owner of the property. A sophisticated attacker will add themselves as an owner to receive Search Console notifications (including any manual actions against the site) and to modify settings like preferred canonical, international targeting, or disavow files.

1. Go to Settings → Users and permissions.
2. Review every user and every verified owner. Any unfamiliar Google account or service account is suspicious — note the email address for the incident log, then remove access.
3. Check Settings → Ownership verification for any verification method you didn’t add (an unexpected HTML file, DNS TXT record, Google Tag Manager integration, or Google Analytics association).
4. Remove any HTML verification files that belong to accounts you don’t control.

If the attacker has already removed you as a verified owner, re-verify via DNS TXT record (the most tamper-resistant method) to regain access before moving on.

4. Assess the scope of the attack

Search Console’s Security issues report is the single most useful diagnostic. It tells you exactly what Google detected — malware, social engineering, harmful downloads, unwanted software, hacked spam — and shows representative example URLs. The categories Google reports align with the attack types you’re likely to face:

• SEO spam / hacked content — injected pages or redirects designed to rank for pharmaceutical, gambling, or counterfeit keywords. Visible to Googlebot but often cloaked from normal visitors.
• Malware — downloadable payloads served from your domain.
• Phishing / social engineering — pages impersonating trusted brands to harvest credentials.
• Magecart / e-skimmer — JavaScript injected into checkout forms on e-commerce sites to exfiltrate payment details.
• Cryptomining — hidden browser-based cryptocurrency miners running on your visitors’ CPUs.
• Unwanted software — browser-extension drops, fake update prompts.

Cross-reference with:

• Google Safe Browsing Site Status — shows whether your domain is currently flagged in Chrome, Safari, and Firefox warnings.
• VirusTotal URL scanner — scans your URL against dozens of antivirus engines simultaneously.
• Sucuri SiteCheck — free remote malware scanner that mimics search-bot and browser perspectives.

Document what you find. A running incident log (when you noticed, what each scan showed, credentials rotated, files modified) is invaluable both for recovery and for any legal or compliance disclosure requirements.

5. File-system forensics

With the site offline, dig into the server. The hacker’s goal is usually persistence — they want a way back in even after you patch the original entry point. Look for:

• Files created or modified since the last known-good backup. Use find . -type f -newer /path/to/reference-file on Linux, or compare against a known-clean backup with rsync or git.
• PHP files outside expected locations — backdoor shells (c99, r57, WSO, weevely) frequently land in /wp-content/uploads/, theme folders, or buried under plausible-looking names (wp-includes/js/jquery/jquery.min.php).
• Obfuscated code — base64-encoded strings, eval() calls, gzinflate() + str_rot13(), hex-encoded PHP. These are rarely legitimate in application code.
• Modified core files — WordPress, Joomla, Drupal core files should match the distributed checksums. Wordfence and Sucuri’s scanners automate this check; manual comparison against a clean download also works.
• Injected JavaScript — especially on checkout, login, and form pages. Magecart skimmers attach to form submit events and POST the data to attacker-controlled domains.
• Rogue .htaccess redirects — conditional redirects that trigger only for specific user agents (mobile, Googlebot, referrers from search engines).
• Unexpected cron jobs and scheduled tasks — persistence mechanisms that re-inject payloads even after cleaning.
• Database injections — malicious admin users, SEO-spam entries in wp_options, injected script tags in post content.

Check access logs and error logs for the initial compromise timestamp — failed logins, suspicious POST requests to wp-login.php or xmlrpc.php, unusual file uploads. Assume the attacker may have tampered with logs; cross-reference with hosting-level logs if available.

6. Identify every vulnerability

Finding one entry point doesn’t mean you’ve found them all. Common vulnerabilities in 2026:

• Outdated CMS, theme, or plugin — by far the most common cause of compromise. Patchstack tracks WordPress-specific vulnerabilities; the WPScan database is another reliable source.
• Weak or reused passwords — especially for admin, FTP, and database accounts.
• Exposed wp-config.php, .env, or .git directories — usually through misconfigured web server rules.
• Supply-chain compromises — a legitimate plugin updated with malicious code. The 2022 AccessPress theme incident and various 2023–2025 plugin compromises are reminders that “all updated” is no longer a guarantee. Pin critical plugin versions, read release notes, and monitor Patchstack or Wordfence threat feeds.
• Compromised developer workstations — stolen cookies, leaked SSH keys. A breach here skips every hardening measure on the server.
• Unsecured admin endpoints — wp-admin or /administrator exposed to the open internet with weak rate-limiting.
• Overly permissive file and directory permissions — writable PHP files, 777 directories.
• Exposed XML-RPC — xmlrpc.php is a common brute-force and amplification target; disable if you don’t use it.

Run a proper vulnerability scan — Wordfence, Sucuri, or Patchstack for WordPress; Nessus, OpenVAS, or OWASP ZAP for generic web apps.

7. Clean the site

With the vulnerabilities mapped, start cleanup. Several guiding principles:

1. Work in a clean environment. Copy the infected site to a local machine or isolated staging server. Do your surgery there, not on the live host.
2. Remove, don’t modify, where possible. Delete attacker-created files outright. Restore legitimate core files from original distribution downloads, not from the infected copy.
3. Review before deletion. Hackers sometimes inject into legitimate pages — a full recursive delete of “anything that looks wrong” can delete real content. Diff against backup first.
4. Nuke uploads carefully. Attacker payloads often hide in /wp-content/uploads/ among legitimate user uploads. Scan file-by-file rather than wholesale-deleting the directory.
5. Check database integrity. Injected content in wp_posts, rogue users in wp_users, modified wp_options (siteurl, home, active_plugins), injected rows in plugin tables.
6. Handle legal obligations. If personal data was exposed — especially under GDPR, CCPA, PIPEDA, or industry regulations like HIPAA or PCI-DSS — notification deadlines and required disclosures start running from the point of discovery. Consult counsel before going public.
7. Submit cleaned URLs for re-crawl via URL Inspection. The old “Fetch as Google” tool was replaced by URL Inspection in Search Console back in 2018 — paste any URL, click “Request Indexing” to accelerate re-crawl.

8. Rebuild from a clean base

For severe compromises, full reconstruction is faster and safer than in-place cleanup:

1. Provision a new server — a fresh VM, new container, or new managed hosting account. Assume the old environment may have persistence you haven’t found.
2. Install latest CMS and dependencies — fresh downloads from official sources, verified checksums.
3. Restore content from a known-good backup — typically a backup from before the earliest signs of compromise. Verify the backup itself is clean (scan it with Sucuri SiteCheck or similar before restoring).
4. Re-enable only plugins and themes you actually use. Each unused plugin is an attack surface; incident recovery is a good time to prune.
5. Apply all security updates to OS, web server, PHP, MySQL, CMS, plugins, themes.
6. Reset every credential again on the new environment. Don’t reuse even the post-incident passwords.
7. Enable MFA on every account that supports it — especially admin, hosting, registrar.
8. Deploy a WAF — Cloudflare (free tier is adequate for most small sites), Sucuri Firewall, or Wordfence’s Real-Time Firewall. A WAF catches known attack patterns before they hit your application.
9. Repoint DNS to the new server and monitor closely for the first 72 hours.

No good backup exists? Make two backups of the compromised site before touching anything else — one as a forensic snapshot (disk image), one for content recovery. Clean content offline from the content copy and restore to the fresh server.

9. Pre-relaunch checklist

Before bringing the site back online, confirm the following — every “no” is a reason to wait:

1. Have I notified affected users if personal data was exposed?
2. Is the CMS, every plugin, and every theme on the latest version with no known CVEs?
3. Have I removed every plugin and theme I’m not actively using?
4. Did I remove every attacker-created file, URL, and database row?
5. Is content restored from a verified-clean backup?
6. Is the root-cause vulnerability patched?
7. Is MFA enabled on every administrative account?
8. Is a WAF active and tuned?
9. Is automated malware scanning running (Wordfence, Sucuri Pro, hosting-bundled scanner)?
10. Are nightly off-site backups configured and tested?
11. Is a long-term security plan in place — patching schedule, monitoring, incident-response runbook?

10. Request a Google review

Cleaning the site doesn’t automatically remove Safe Browsing warnings or restore rankings. You need to request a review:

1. Search Console → Security issues: if Google flagged your site, this report includes a Request a review button. You must describe what was compromised and how you fixed it; vague responses extend review time. Include specific remediation details — files removed, credentials rotated, vulnerability patched.
2. Phishing / malware removal: if Chrome or Safari is showing the red interstitial, the Security issues report review handles both. The old standalone google.com/safebrowsing/report_error path is still reachable, but Search Console is now the primary channel.
3. Manual action recovery (if Google issued a manual action against the site for spam): submit a Reconsideration request under Security & Manual Actions → Manual Actions. Be concrete about what caused the violation and what you changed.

Review timelines have tightened since the mid-2010s. Typical processing in 2026:

• Malware reviews: 24–72 hours.
• Phishing reviews: 24–48 hours.
• Hacked spam reviews: several days to ~2 weeks, depending on severity and repeat-offender status.
• Manual action reconsideration: 1–4 weeks.

While you wait, monitor Search Console’s Coverage and Security reports daily, watch for any regression, and keep your incident log updated. When the review passes, the Safe Browsing interstitial disappears from browser warnings, and rankings typically recover over the following weeks as Google re-crawls the clean content.

Frequently asked questions

How do I know if my site was hacked?

Common signals: Google Search Console sends a Security issues notification; Chrome or Safari shows a red interstitial when visitors reach the site; organic traffic drops sharply; Google search results for your brand show unrelated pharmaceutical, gambling, or counterfeit content; users report pop-ups, unexpected redirects, or antivirus warnings. Run Sucuri SiteCheck if you suspect something but aren’t sure.

Will the site’s rankings recover after cleanup?

Usually yes, over a few weeks. Google’s systems de-rank hacked content while the warning is active, then re-crawl and re-rank once the review passes. Sites with sustained authority and a clean history typically see most rankings return within 30–60 days. Sites that were marginal before the compromise may struggle more — the recovery is an opportunity to rebuild quality, not just restore.

Should I pay a ransom if the attacker demands one?

For website compromises specifically, almost never. Website attackers rarely hold your data hostage in a way that payment reliably unlocks; most hacks are opportunistic SEO spam or payload injection, not targeted extortion. If ransomware has encrypted server files (rare for shared hosting, more common for self-managed VMs), consult your incident-response vendor, your insurer, and potentially law enforcement before paying.

Is a managed WordPress host safer?

Generally yes, with caveats. Managed hosts (Kinsta, WP Engine, Cloudways, Pantheon, Pressable) bundle malware scanning, automatic core updates, a WAF, and free cleanup for compromises. They don’t eliminate your responsibility for plugin hygiene and credential security, but they handle a large class of server-level attacks that self-managed hosts leave to the site owner.

What should be in a long-term security plan?

Weekly: review Search Console security issues, Wordfence/Sucuri scan results, and hosting-level alerts. Monthly: apply CMS, plugin, and theme updates; review user accounts; test backup restore. Quarterly: rotate service-account credentials; review WAF rules; audit plugins against Patchstack vulnerabilities. Ongoing: MFA on every admin, off-site backups, activity logging, and a written incident-response runbook so you’re not improvising at 2 AM when the next one hits.

Bottom line

Website compromises are recoverable, and the 2026 toolkit (Search Console Security issues report, URL Inspection, managed-host cleanup services, free WAFs, mature scanner ecosystems) is the best it’s ever been. Contain first, investigate with discipline, clean from a known-good base, and harden against the specific vulnerability that got you. Request Google’s review promptly but only after you’re genuinely clean — a premature review that fails resets the clock. The sites that recover fastest are the ones that treat the incident as both a cleanup and a forcing function to fix the security debt that invited the compromise in the first place.