{"id":9983,"date":"2026-06-16T10:22:04","date_gmt":"2026-06-16T10:22:04","guid":{"rendered":"https:\/\/www.neelnetworks.com\/blog\/?p=9983"},"modified":"2026-06-16T12:04:09","modified_gmt":"2026-06-16T12:04:09","slug":"how-to-recover-hacked-wordpress-website-step-by-step","status":"publish","type":"post","link":"https:\/\/www.neelnetworks.com\/blog\/how-to-recover-hacked-wordpress-website-step-by-step\/","title":{"rendered":"How to Recover a Hacked WordPress Website Step by Step"},"content":{"rendered":"
\n

If you are reading this because your WordPress site is showing pharmacy ads in the footer, redirecting visitors to a site you have never heard of, displaying a defacement page, or has been flagged by Google as dangerous \u2014 first, take a breath. Recovery is almost always possible. The site you have spent years building is not lost, even if it looks that way right now. What you do in the next few hours will determine whether the recovery is straightforward or expensive, so the most useful thing this guide can do is walk you through the steps in the right order, calmly.<\/p>\n

We have been called in to recover compromised WordPress sites often enough over the last decade to know that the panic decisions made in the first thirty minutes are usually the ones that make the cleanup harder later. This guide is written from the agency side of those incidents \u2014 what we actually do, in what order, and what we wish more site owners knew before they made the situation worse. If you want the broader context of how WordPress security fits into ongoing website care, our complete website maintenance guide<\/strong><\/a> sets the foundation. This article is the emergency manual for when something has already gone wrong.<\/p>\n

\"Hero<\/p>\n

First, do not panic \u2014 what to do in the first 30 minutes<\/h2>\n

The instinct when you discover a hack is to start clicking, deleting, reinstalling \u2014 anything to make the problem go away. Resist it. The first thirty minutes after discovery are the most important, and the actions that genuinely help are mostly passive ones. The actions that hurt are the active, panicked ones.<\/p>\n

The first thing to do is to verify, calmly, that what you are seeing is actually a hack and not something else. A site that is suddenly slow, throwing 500 errors, or showing a database connection issue is not necessarily compromised \u2014 it might just be broken. A hack typically shows specific signs: unauthorised content appearing on pages, redirects to unfamiliar sites, search results showing your domain serving spam content, a Google “this site may be hacked” warning, your hosting provider suspending the account, or admin users you do not recognise appearing in the WordPress dashboard.<\/p>\n

Once you have confirmed it is a hack, the second action is to preserve evidence. Do not start deleting files or reinstalling WordPress yet. The current state of the compromised site is the diagnostic information that tells you how the attacker got in, and destroying it makes future prevention much harder. Make a complete backup of the hacked site exactly as it is right now, label it clearly as compromised, and store it somewhere you will not accidentally restore from later.<\/p>\n

The third action is to inform your hosting provider. Many hosts have security teams who can help, can run scans from their side, and in some cases can isolate the compromised site to prevent further damage. They also need to know because the attack may have used hosting-level vulnerabilities, and they may have information about whether other accounts on the same server have been affected.<\/p>\n

How to confirm your WordPress site has actually been hacked<\/h2>\n

Before committing to a full recovery process, it is worth being sure about what you are dealing with. Hacks present in fairly recognisable patterns, and the symptoms below are the most common ways a compromise reveals itself.<\/p>\n

Visible defacement or unauthorised content<\/h3>\n

The most obvious sign \u2014 pages on your site display content you did not put there. Sometimes this is dramatic (a full page replaced with a hacker’s message), sometimes subtle (pharmacy ads appearing in the footer, hidden links inserted into existing pages, spam content added to your blog archives). If you see content on your site that you do not remember adding, you are almost certainly looking at a compromise.<\/p>\n

Unexpected redirects<\/h3>\n

Visitors who click on your site from Google get sent to a completely different website \u2014 often a spam site, an adult site, or a fake pharmacy. The redirect frequently triggers only for visitors arriving from search engines (so the site looks normal when you visit directly), which makes it harder to spot and is a strong indicator of a deliberate attack rather than a configuration error.<\/p>\n

Search results showing spam content for your domain<\/h3>\n

Google searches for your brand or your URL return results titled in foreign languages, related to drugs, casinos, or other unrelated content. This is the SEO spam injection pattern \u2014 attackers have added pages or hidden content to your site that Google is now indexing under your domain. The search results often appear before you have noticed any visible problem on the front end.<\/p>\n

Google’s “This site may be hacked” or “Deceptive site ahead” warning<\/h3>\n

Google’s Safe Browsing system has flagged your site and is warning visitors. This is one of the more urgent signs because it directly cuts your traffic \u2014 visitors who see the warning leave, and the warning persists for as long as the compromise does. The warning will not lift automatically; it requires a review request after the site is cleaned.<\/p>\n

Hosting provider has suspended your account<\/h3>\n

The host has detected malicious activity from your account \u2014 typically outbound spam, malware distribution, or attacks against other servers \u2014 and has taken the site offline to contain the damage. This is bad news in the short term but good news in one specific way: the compromise has been caught, often before it spread further.<\/p>\n

Admin users or scheduled tasks you do not recognise<\/h3>\n

Log into the WordPress dashboard. Check Users \u2192 All Users. Check Tools \u2192 Scheduled Tasks (if your security plugin shows them). Unknown admin accounts and unfamiliar scheduled tasks are clear evidence of compromise \u2014 the attacker has created persistence so they can return even if you change the obvious passwords.<\/p>\n

The eight common types of WordPress hacks<\/h2>\n

Most WordPress compromises fall into one of eight recognisable patterns. Identifying which pattern you are dealing with helps shape the recovery \u2014 different hacks hide in different places and require different cleanup approaches. The table below summarises the most common types and how to spot them.<\/p>\n

\"Visual<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Hack type<\/th>\nWhat it looks like<\/th>\nHow attackers usually got in<\/th>\n<\/tr>\n<\/thead>\n
Pharma hack<\/td>\nPharmaceutical spam content and hidden pages, often visible only in search results<\/td>\nOutdated WordPress core or vulnerable plugin<\/td>\n<\/tr>\n
Redirect hack<\/td>\nVisitors from search engines redirected to spam, adult or casino sites<\/td>\nCompromised theme or plugin files<\/td>\n<\/tr>\n
SEO spam injection<\/td>\nSpam pages or hidden links added to existing pages, often in foreign languages<\/td>\nVulnerable plugin or weak admin password<\/td>\n<\/tr>\n
Defacement<\/td>\nHomepage or pages replaced with hacker message or political content<\/td>\nWeak admin credentials or vulnerable plugin<\/td>\n<\/tr>\n
Backdoor<\/td>\nNo visible symptom \u2014 hidden script files giving the attacker ongoing access<\/td>\nOften follows an earlier compromise; designed for persistence<\/td>\n<\/tr>\n
Credit card skimmer<\/td>\nJavaScript stealing payment data on eCommerce checkout pages<\/td>\nPlugin vulnerability or compromised hosting<\/td>\n<\/tr>\n
Phishing pages<\/td>\nFake login pages for banks, email or services hosted under your domain<\/td>\nWeak credentials or file upload vulnerability<\/td>\n<\/tr>\n
Cryptocurrency miner<\/td>\nSite is slow; CPU usage spikes; visitors’ browsers run mining scripts<\/td>\nCompromised theme or plugin, especially nulled or pirated ones<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The pattern matters because some hacks are visible (defacement, redirects) and some are silent (backdoors, skimmers). The silent ones are the more dangerous because they continue compromising visitors long after the obvious damage has been done. Even if your visible problem is a redirect or pharma hack, assume backdoors are also present and clean for them too.<\/p>\n

\n The most important thing to do first:<\/strong> change every credential associated with the site. WordPress admin passwords. Hosting account password. FTP\/SFTP credentials. Database password. Any third-party services connected to the site. Do this before anything else, even before deleting anything. If the attacker has stolen credentials, your cleanup work is wasted the moment they log back in with the password they already have.<\/div>\n

The eight-step WordPress recovery process<\/h2>\n

With the immediate triage done and the type of compromise identified, the actual recovery process runs in a fairly consistent sequence. The eight steps below cover the work we run for clients, in the order it should be done. Skipping ahead \u2014 particularly skipping the credential-change step or the forensic backup \u2014 usually means redoing the work later when something resurfaces.<\/p>\n

    \n
  1. \n
    \n Take the site offline or put it in maintenance mode<\/strong>
    \nStop the bleeding first. If the site is actively serving malware, redirecting visitors, or being used for phishing, every minute it stays live causes more damage \u2014 to your visitors, to your domain reputation, and to your search rankings. Putting the site in maintenance mode (or temporarily switching to a static “we’ll be back soon” page) cuts off ongoing harm and gives you space to work. This is also the right moment to remove the site from any active advertising campaigns so you are not paying to drive traffic to a compromised page.<\/div>\n<\/li>\n
  2. \n
    \n Change every credential immediately<\/strong>
    \nWordPress admin accounts (all of them, not just yours). Hosting control panel password. FTP and SFTP credentials. Database username and password. Any third-party API keys connected to the site \u2014 payment gateways, email services, analytics, anything. If the attacker has captured any one of these, your cleanup is wasted the moment they reconnect. Change them all in one session, write them down securely, and do not reuse anything. Many compromises persist precisely because this step was skipped or done partially.<\/div>\n<\/li>\n
  3. \n
    \n Take a forensic backup of the compromised state<\/strong>
    \nBefore deleting or modifying anything, download a complete copy of the site exactly as it is now \u2014 all files, the full database, server logs if you can access them. Label the backup clearly as compromised and store it somewhere you will not accidentally restore from. This snapshot is your evidence of what happened, and it is what allows post-incident analysis to identify how the attacker got in. Without it, the same vulnerability often gets exploited again because nobody worked out what it was.<\/div>\n<\/li>\n
  4. \n
    \n Restore from the last known-clean backup if you have one<\/strong>
    \nIf you have a backup from before the compromise (and you can be reasonably sure that backup is clean), restoring it is often the fastest, most reliable path forward. This is exactly the scenario a proper backup strategy is built for, and the existence of a clean backup is what separates a one-hour incident from a one-week one. The 3-2-1 backup framework \u2014 three copies, two media, one off-site \u2014 is the standard we recommend, and our detailed website backup strategy guide<\/strong><\/a> covers it in full. After restore, immediately update everything (next steps) and change credentials again. If you do not have a clean backup, skip to step five and clean manually.<\/div>\n<\/li>\n
  5. \n
    \n Scan the site with multiple security tools<\/strong>
    \nRun at least two independent malware scanners on the site. Common choices are Wordfence (free version is competent), Sucuri SiteCheck (free remote scanner), MalCare, and Jetpack Scan. The reason for multiple scanners is that no single tool catches everything \u2014 different scanners are good at finding different types of compromise, and the overlap is what gives you confidence the site is genuinely clean. Pay particular attention to flagged files, especially in wp-content\/uploads (where files should never execute code), wp-content\/plugins, and wp-content\/themes.<\/div>\n<\/li>\n
  6. \n
    \n Manually remove malicious code and unknown files<\/strong>
    \nFor the issues your scanner identified, the cleanup is mostly file deletion and code removal. Delete any plugin or theme files that should not be there. Remove unfamiliar PHP files from upload directories (no legitimate WordPress installation has PHP files inside uploads). For modified core files, the safest approach is to download a fresh copy of WordPress from wordpress.org and overwrite the core. For modified theme and plugin files, deactivate everything, delete the compromised versions, and reinstall fresh copies from official sources. Hidden injected code in the database \u2014 particularly in wp_options or wp_posts tables \u2014 needs careful removal; this is where a security plugin or experienced help becomes valuable.<\/div>\n<\/li>\n
  7. \n
    \n Update everything to current versions<\/strong>
    \nOnce the obvious malicious content is removed, update WordPress core to the latest version. Update every plugin to its latest version. Update the theme. If any plugins or themes are no longer maintained (no updates in over a year), replace them with maintained alternatives or remove them entirely. Most successful WordPress hacks exploit known vulnerabilities in outdated software \u2014 running current versions is what closes the door against re-infection through the same path.<\/div>\n<\/li>\n
  8. \n
    \n Bring the site back online and monitor closely<\/strong>
    \nWith the site cleaned, updated and credentials changed, bring it back online. But the recovery is not finished \u2014 monitor closely for the next two weeks. Watch your server logs, your security plugin alerts, your search rankings, and your visitor reports. Some hacks persist quietly even after apparent cleanup, and the early days after a recovery are when re-infection most often becomes visible. If anything suspicious appears, return immediately to step two and re-examine. A truly clean recovery shows no anomalies for a full two-week window.<\/div>\n<\/li>\n<\/ol>\n
    \n

    Need Urgent Help Recovering a Hacked WordPress Site?<\/strong><\/p>\n

    If your site is compromised and you would rather have an experienced team handle the recovery \u2014 credential reset, malware removal, database cleaning, Google warning lift, and post-incident hardening \u2014 we are happy to help. Send us your URL and a description of what you are seeing, and we will respond within a few hours.<\/p>\n

    \n Request emergency help<\/a> Message on WhatsApp<\/a><\/div>\n<\/div>\n

    What to do if you do not have a clean backup<\/h2>\n

    The hardest recoveries are the ones where no clean backup exists \u2014 the host’s backup is too recent and already contains the compromise, no off-site backups were ever configured, or the only backups available are from years ago when the site was very different. This situation is unfortunately common, and it requires a manual cleaning approach that takes longer and is harder to fully verify.<\/p>\n

    The manual cleaning process starts with the WordPress core. Download the latest version of WordPress from the official wordpress.org site and overwrite all core files except wp-config.php and wp-content. This is straightforward and replaces every standard WordPress file with a known-clean copy, eliminating any modified core files in one step.<\/p>\n

    Next, the themes and plugins. Delete every theme except the one you actively use, and reinstall that active theme from a fresh download. Delete every plugin and reinstall each one from the WordPress plugin repository (do not restore them from your existing wp-content). This is tedious but it is the only way to be confident your themes and plugins are not the source of ongoing compromise.<\/p>\n

    The uploads directory is more difficult. Your uploads (images, PDFs, documents) are legitimate content that you want to keep, but the directory may also contain malicious files the attacker added. Use a file manager to look through wp-content\/uploads for any PHP files, JavaScript files in unusual locations, or files with suspicious names. Legitimate uploads are images, videos and documents \u2014 not executable code. Anything that looks out of place should be examined and removed.<\/p>\n

    The database is the hardest part of manual cleaning. Injected spam, hidden links and modified content live in database tables, particularly wp_options, wp_posts and wp_postmeta. Cleaning this requires either careful manual review (slow, expert work) or a security plugin’s database scanner that can identify and remove known malicious patterns. For most site owners, this is the point at which professional help is genuinely useful, because incomplete database cleaning is the most common reason a “cleaned” site quickly becomes recompromised.<\/p>\n

    How to remove Google’s “this site may be hacked” warning<\/h2>\n

    If Google has flagged your site as hacked, the warning will continue showing in search results even after you have cleaned the site. Removing it requires a specific process through Google Search Console, and the warning will not lift on its own.<\/p>\n

    \"Visualisation<\/p>\n

    First, verify your site in Google Search Console if you have not already. Then go to Security & Manual Actions \u2192 Security Issues. The report will list the specific issues Google detected \u2014 hacked content, malware, deceptive pages, or unwanted software. The issues are specific and detailed, which is useful because it tells you what Google itself sees on your site even if your scanners missed it.<\/p>\n

    Address every issue Google has flagged. This usually means going back through the cleanup process and specifically targeting whatever Google found \u2014 often hidden pages, injected scripts, or redirects that scanners overlooked. The exact pages and code Google identifies are documented in the report itself, so you have a concrete list of what to fix rather than guessing.<\/p>\n

    Once you are confident the issues are resolved, submit a review request through the same Security Issues page. Google’s review typically takes a few days to two weeks. If they confirm the site is clean, the warning is removed from search results automatically. If they find issues remain, they will explain what is still flagged and the process repeats. Be patient and thorough \u2014 submitting a review while issues still exist resets the timer and can extend the warning period significantly. The broader picture of how Google sees your site after a hack ties into the standard technical SEO foundations<\/strong><\/a> work, which is why a security incident is often a good moment to do a full technical audit at the same time.<\/p>\n

    Why your WordPress site was hacked: the five most common entry points<\/h2>\n

    Recovery without understanding how the compromise happened is a temporary fix. Whatever vulnerability the attacker used is still there, and unless it is closed, re-infection is likely. The pattern of how WordPress sites actually get hacked is consistent \u2014 five entry points account for the great majority of all compromises, and identifying which one applied to your site is essential for preventing a repeat.<\/p>\n

    Outdated WordPress core.<\/strong> Running an old version of WordPress with known security vulnerabilities is the single most common cause. Major WordPress security releases fix specific known exploits, and sites running the old version are sitting targets. The fix is simple \u2014 keep WordPress core updated, ideally on automatic minor updates with manual review of major version changes.<\/p>\n

    Outdated or vulnerable plugins.<\/strong> The biggest single attack surface on most WordPress sites is the plugin layer. A site with twenty installed plugins, one of which has a known vulnerability, can be compromised through that single plugin even if everything else is current. The discipline is to keep every plugin updated, remove any plugin not actively in use, and avoid plugins that have not received an update in over a year \u2014 abandoned plugins are essentially open vulnerabilities waiting to be exploited.<\/p>\n

    Outdated or nulled themes.<\/strong> Themes get less attention than plugins but follow the same pattern \u2014 outdated themes contain known vulnerabilities, and “nulled” (pirated) themes are notorious for shipping with intentional backdoors. The compromise is built in from the start. Pay for legitimate themes, keep them updated, and remove themes you are not actively using.<\/p>\n

    Weak admin credentials.<\/strong> Brute force attacks against the WordPress login page are constant and automated. A site with a weak admin password and an admin user named “admin” or “administrator” is being attacked thousands of times a day. Eventually one of those attempts succeeds. Strong, unique passwords, a non-obvious admin username, and two-factor authentication on every admin account close this entry point.<\/p>\n

    Vulnerable hosting environment.<\/strong> Some hacks come not through WordPress itself but through the underlying hosting \u2014 outdated PHP versions, weakly-isolated shared hosting where one compromised site infects neighbours, or hosting accounts left with default credentials. Quality hosting with current PHP, proper isolation and good security practices is part of the security strategy, not separate from it.<\/p>\n

    \n The single biggest cause of WordPress hacks:<\/strong> outdated software. Across the audits and recovery jobs we run, the most consistent finding is that the compromised site was running an outdated version of WordPress core, a plugin or a theme that had a known, publicly-documented vulnerability. The fix \u2014 keeping everything current \u2014 is one of the simplest and highest-return security disciplines available, and it is the discipline most consistently neglected. A site updated every week is a site that closes vulnerabilities as fast as they are discovered.<\/div>\n

    After recovery: the seven steps to prevent it happening again<\/h2>\n

    The recovery itself is only half the work. The other half is hardening the site so the same attacker cannot return through the same door, and so future attackers face a harder target. The steps below are what we apply to every site after a recovery, and what we recommend even for sites that have never been compromised.<\/p>\n

    Update everything and set up automatic minor updates.<\/strong> WordPress core, every plugin, every theme. Configure WordPress to apply minor updates automatically (these contain security patches and rarely break sites). Review major version updates manually but apply them promptly.<\/p>\n

    Change all passwords and enable two-factor authentication on every admin account.<\/strong> A strong unique password is essential but not sufficient. 2FA \u2014 through a TOTP app like Google Authenticator or Authy \u2014 is what prevents the entire category of credential-theft attacks from succeeding even when credentials are stolen.<\/p>\n

    Install and properly configure a security plugin.<\/strong> Wordfence, Sucuri Security, iThemes Security, or similar. Configure malware scanning, login attempt limits, file integrity monitoring, and notification settings. A security plugin watching the site is what catches the next attempted compromise before it succeeds.<\/p>\n

    Set up a proper 3-2-1 backup strategy.<\/strong> If you did not have a clean backup to restore from this time, do not let that happen again. Daily backups, off-site storage, periodic test restores. The discipline of working backups is the difference between a one-hour incident and a one-week one, and it is genuinely inexpensive for a typical business site.<\/p>\n

    Audit user accounts.<\/strong> Remove any user accounts that are not actively needed. Demote unnecessary admin accounts to lower roles. Check that no unknown accounts have been added during the compromise (sometimes attackers add accounts as persistence and they survive a partial cleanup). Run this audit quarterly going forward.<\/p>\n

    Remove unused plugins and themes entirely.<\/strong> Disabled plugins and inactive themes still represent code on your server, and that code can still be exploited. Delete anything you are not actively using, including the default themes that ship with WordPress if you have them disabled.<\/p>\n

    Use a web application firewall.<\/strong> Cloudflare’s free tier, Sucuri’s firewall, or your hosting provider’s WAF if available. A firewall filters malicious traffic before it reaches WordPress, blocking many automated attacks that would otherwise reach your login page or exploit known vulnerabilities. The setup is straightforward and the protection is substantial.<\/p>\n

    \"Visualisation<\/p>\n

    For ongoing security and the discipline of keeping all this maintained without it slipping back into neglect, structured website care is often what makes the difference. Our website maintenance services<\/strong><\/a> include the full security layer \u2014 updates, monitoring, backups, scans and incident response \u2014 as a continuous programme rather than something done once and forgotten. For sites already on solid WordPress development<\/strong><\/a> foundations, the maintenance overlay is what keeps them that way.<\/p>\n

    Common mistakes during WordPress hack recovery<\/h2>\n

    The recovery mistakes we see repeated across incidents are predictable, and most of them make the cleanup significantly harder. Avoiding them is much easier than recovering from them.<\/p>\n

    \n The mistakes that turn a recoverable hack into a disaster:<\/strong><\/p>\n