How to Recover a Hacked WordPress Site in Nigeria
A hacked WordPress site can be recovered. Most of the damage happens in the hours after discovery rather than during the hack itself. Panicked restores, half-finished cleanups and guesswork in phpMyAdmin often cause more permanent harm than the original breach.
This guide walks through how recovery actually works: what to check first, how serious the compromise is, and where the line sits between something you can reasonably handle and something that needs a professional.
If your site is clean, our WordPress security guide for Nigerian businesses covers how to keep it that way.
If customer payment data may be involved, treat this as urgent and get specialist help immediately rather than working through the steps below alone.
Recognising the Signs of a Compromise
Common Warning Signs
A compromised WordPress site tends to show a recognisable pattern:
- Visitors get redirected to spam or adult sites without warning
- Google Search Console or a search result displays a security warning
- Admin accounts appear that nobody on the team created
- Plugins or themes show up that nobody installed
- The site slows to a crawl or crashes without explanation
- The hosting provider sends a suspension notice out of nowhere
- Login attempts fail despite the correct password
- Strange code or links surface inside posts and pages
- Customers report spam emails coming from the site’s domain
Any one of these on its own is worth investigating. Several together is close to confirmation.
Not every compromise is this visible, though. Some hacks leave a site looking completely normal on the surface while it quietly sends spam email, hosts a phishing page, or mines cryptocurrency in the background. Those are often caught by the host or by a customer complaint before the business itself notices anything wrong.
False Alarms vs Real Compromise
Not every broken site has been hacked. A plugin conflict can take a site down completely, and a hosting outage can look identical to a hack from the outside. The difference is evidence: a genuine hack leaves traces such as unfamiliar files, unauthorised users, malicious code sitting in the database, or the site actively spreading spam of its own accord.
A technical fault breaks things without leaving anything behind. Working out which one applies is the first real diagnostic step, and it shapes everything that follows.
Often, the hosting provider is the first to notice, not the business itself. They flag the malicious activity and suspend the account to protect their own infrastructure, and the business owner finds out through a terse email rather than their own monitoring.
The First Few Hours Matter Most
Every hour a compromised site stays live in its current state adds to the exposure. Search engines index the spam, malware keeps spreading, and the blacklisting gets harder to reverse. A few decisions early on matter more than speed for its own sake.
Containing the Damage
The instinct to fix things immediately is understandable, but two moves at this stage tend to cause more harm than good: installing an untested “quick fix” security plugin mid-incident, and updating plugins or themes before anyone has looked at what happened.
Both can destroy the evidence needed to identify how the attacker got in, which makes the same hack more likely to happen again.
Passwords are a different matter and should change immediately, ideally from a separate device: the WordPress admin login, the hosting account, FTP or SFTP credentials, and the database password.
If the compromise is actively spreading spam or serving malicious downloads, taking the site offline behind a simple maintenance page limits the damage while the rest of the assessment happens.
Working With Your Hosting Provider
Response quality varies a lot depending on who’s hosting the site. Local Nigerian hosts and international ones like Bluehost, SiteGround, or Cloudways are both common, and neither guarantees a fast response.
Whatever the response time, it’s worth asking specifically for server access logs, confirmation of whether clean backups exist, and any automated malware scan results the host may already have.
Document the interaction regardless of how helpful it is. If the provider is consistently unresponsive, that’s useful information for deciding whether to choose a different host once the site is stable again.
Communicating With Customers and Staff
The technical response tends to absorb all the attention, but the business still has to keep operating. Staff who use the site day to day need to know it’s compromised, so they don’t log in through it or share files while the investigation is underway.
If customer-facing services are affected, saying so directly holds up far better than customers noticing on their own. Pausing paid advertising until the site is confirmed clean matters too, since sending paid traffic to a compromised site adds risk for no return.
Assessing the Scope of the Breach
Recovery decisions depend on how deep the compromise goes, rather than on whether the site looks visibly broken.
Finding the Entry Point
Recently modified files, unfamiliar folders inside wp-content, and admin accounts nobody recognises all point toward how the attacker got in.
Outdated plugins remain the most common entry point, followed by weak passwords and nulled themes downloaded from unofficial sources that come pre-loaded with a backdoor.
External scanners like Sucuri SiteCheck and the security warnings inside Google Search Console are useful first checks. Neither touches anything on the live site, which makes them a safe starting point before deciding on a recovery path.
A clean-looking homepage does not mean a clean website. Many attacks leave a hidden backdoor behind, and that backdoor quietly reinstalls the malware days or weeks after the visible symptoms are gone.
That’s why recovery isn’t really about removing suspicious files. It’s about closing whatever let the attacker in, whether that’s stolen admin credentials, a scheduled task nobody set up, or a vulnerable plugin still sitting on the site.
When the Hosting Server Itself Is Compromised
Sometimes the fault sits below WordPress entirely. Budget shared hosting, whether from a local Nigerian provider or a cheaper international plan, is common among small businesses, and some of those packages run outdated server software or offer weak isolation between accounts on the same server.
If several unrelated sites on the same server get hacked around the same time, the server is the actual problem, and cleaning the WordPress installation in that situation buys nothing. The site gets reinfected because the environment underneath it is still compromised. The only durable fix is a clean rebuild on a different, properly maintained host.
WordPress itself is not always the problem. Incorrect file permissions, an upload folder that allows scripts to execute, or malware sitting at the server level rather than inside the WordPress files can all cause a “clean” WordPress installation to stay compromised. This is a server-level diagnosis, not something a WordPress security plugin can fix on its own.
Determining Your Data Protection Exposure
If the site stores customer names, emails, order history or any other personal data, a hack that reached the database is a potential NDPA matter as much as a technical one.
Whether notification is required, and how the 72-hour window works in practice, is covered in detail in our guide to responding to data breaches in Nigeria. It’s worth reading that alongside this one if there’s any chance customer data was touched.
Choosing a Recovery Path
Which path makes sense depends largely on whether a clean backup exists and how comfortable anyone on the team is working directly in FTP and a database.
| Recovery Path | Best When | Main Risk |
|---|---|---|
| Restore from clean backup | A verified, pre-hack backup exists | Restoring an already-infected backup by mistake |
| Manual file and database cleanup | No clean backup, and someone has genuine technical skill | A wrong database change can take the site down permanently |
| Professional recovery | Reinfection has already happened, payment data is involved, or nobody is confident with the above | Cost, weighed against downtime and data risk |
Restoring From a Clean Backup
If a confirmed clean backup exists from before the compromise, it’s the fastest and most reliable path back to a working site.
The backup date has to predate the hack, and both the files and the database need restoring together. Restoring one without the other tends to leave part of the infection in place.
Once the site is back, every password changes again, WordPress core and all plugins get updated, and the restored site gets rescanned before anyone calls it done.
Before relying on a backup at all, confirm that it actually restores successfully. Businesses often discover a backup was incomplete or corrupted only during the emergency it was meant to solve.
Why Manual Cleanup Is Riskier Than It Looks
Without a clean backup, the alternative is manual cleanup: removing infected files, replacing WordPress core, cleaning malicious entries out of the database, and regenerating security keys to lock out anyone still holding stolen credentials.
Each of those steps is a real technical task with a real chance of making things worse if done incorrectly, particularly the database work. A wrong query in phpMyAdmin does not politely fail; it can take the site down permanently.
Replacing WordPress core with a fresh copy from wordpress.org is usually faster and safer than inspecting every core file individually. Custom code and configuration live in wp-content and wp-config.php, so those are the areas that need closer examination.
At this point in recovery, the cost of getting it wrong starts to exceed the cost of getting help. A specialist doing this daily can usually complete in an hour or two what would otherwise be a full day of trial and error.
When Professional Recovery Makes Sense
Certain signals point clearly toward bringing in help rather than continuing alone: the site keeps getting reinfected after cleanup attempts, or the hosting server itself turns out to be compromised.
The same applies when nobody on the team is comfortable in FTP or a database, customer payment data was involved, or the business is losing meaningful daily revenue while the site is down.
NDPA notification is another trigger worth taking seriously on its own. When it’s required, the compliance guidance needs to be right the first time.
Professional recovery typically covers full malware scanning, database-level cleaning, entry-point identification, and security hardening. Where a server migration is needed, it also covers moving the cleaned site to a properly maintained host without carrying any infection across with it.
Recovery cost depends heavily on how much has to be cleaned up or rebuilt, and is usually clearer after an initial assessment than it is upfront.
Verify the Site Is Genuinely Clean
Whichever path got the site back online, the next step is the same: confirming it’s actually clean rather than just quiet. A malware scan finding nothing is encouraging, but it isn’t proof the site is clean. Automated scanners look for known patterns, and a skilled attacker can leave custom code that only a manual check catches.
Before moving on to hardening, confirm a few things directly: the admin login and key forms work as expected, and server and access logs don’t show anything unusual.
A fresh crawl of the site shouldn’t turn up unfamiliar pages, and Search Console should show no lingering security warnings. It’s also worth checking the uploads folder specifically, since that’s a common place for renamed malicious files to hide.
Getting Off Google’s Blacklist
Google blacklists sites it catches distributing malware, running phishing pages, or injecting heavy spam into search results.
Once the site is genuinely clean rather than superficially tidied up, Google Search Console allows a security review request under Security Issues. Reviews are typically resolved within a few days.
If the warning persists after that, it usually means something was missed rather than that the review is slow: hidden backdoors, leftover .bak or .suspected files from a previous cleanup attempt, or a piece of malware the first pass didn’t catch.
The blacklist warning is only part of the search visibility damage, though. Attacks that inject spam often get hundreds of junk pages indexed under the site’s domain, pushing casino, pharmaceutical, or counterfeit product content into Google’s results. Clearing the blacklist doesn’t remove those pages on its own.
Getting them out requires returning a proper 404 or 410 status for each spam URL and regenerating the sitemap so it reflects only real content.
The cleaned sitemap then needs to be submitted through Search Console so Google recrawls it. Skipping this step means the malware warning clears while the spam pages quietly stay indexed.
Hardening the Site After Recovery
A recovered site is clean. That is not the same as secure, and the gap between the two is where reinfection usually happens.
Meaningful hardening covers a proper WordPress security plugin with firewall and login protection, two-factor authentication on every admin account, and disabling in-dashboard file editing so a future compromised login can’t be used to inject code directly.
Automated off-site backups that are actually tested matter just as much as any of the above. A network-level layer like Cloudflare adds another barrier in front of the site itself.
Recovery is also the point to rotate every credential connected to the site, beyond the WordPress admin password alone. Hosting, SSH, SFTP, the database, Cloudflare, SMTP, and any API keys the site uses should all change, since a determined attacker often collects more than a single login on the way in.
Connected third-party services are worth reviewing too: Cloudflare, email providers like Zoho Mail or Mailgun, payment gateways, and analytics tools. Unfamiliar API keys, DNS changes, or forwarding rules that appeared during the compromise are easy to miss and easy for an attacker to reuse later.
Our WordPress security guide covers each of these in more depth, and our website maintenance overview covers what ongoing monitoring should look like once the immediate crisis has passed.
Documenting What Happened
Once the site is stable, write down what happened while it’s still fresh: how the attacker likely got in, which component was vulnerable, roughly when the compromise started, and what was done to fix it.
This isn’t paperwork for its own sake. It’s the difference between a business that can explain to a customer, an insurer, or the NDPC exactly what happened, and one that’s guessing after the fact. It also means the next incident, if there is one, starts from a known cause instead of a blank page.
Preventing the Next Hack
A hack is a warning about what was missing beforehand, rather than a one-off event to clean up and move past.
The most common gaps are weak or reused passwords, no proper security plugin, backups nobody ever tested, no monitoring for suspicious activity, and continued use of nulled plugins or themes after everyone knows better.
Repeat hacks compound the damage. Customers forgive one incident and rarely forgive a second; Google is less patient with repeat offenders, and NDPA penalties escalate for organisations with a pattern of breaches rather than a single event.
Facing a Hacked WordPress Site Right Now?
A hacked site is stressful, but it’s rarely as unrecoverable as it feels in the first hour. What matters most is getting the sequence right: contain it, work out what actually happened, recover it properly, and confirm it’s clean before calling it done.
If you’re dealing with an active compromise or you’re not confident handling the cleanup yourself, PlanetWeb provides emergency WordPress recovery for Nigerian businesses. Visit our Managed Support Services page to see how ongoing protection works, or contact us directly for urgent recovery help.
