Hacked WordPress Site? What to Do First and 5 Steps to Recover

If you have a hacked WordPress site, work in this order: block public access, take a copy of the site as it is now, change your hosting passwords and sign everyone out, then contact your host.

What should I do first when my WordPress site is hacked?

Do these things before you start any cleanup. They stop the damage spreading and keep a record you will need later.

1. Block public access to the site. Download a copy of your site’s .htaccess file, then add Require all denied as its first line. This blocks every visitor, including you, but you keep working through SFTP (a secure way to reach your site’s files) and your hosting control panel’s File Manager. Step 1 explains how.
2. Take a copy of the site as it is now, and keep it off the server. With the dashboard blocked, use your hosting control panel’s backup tool. If it has none, compress the site folder in the File Manager and export the database from phpMyAdmin, the database tool in your control panel. Download both to your computer or to storage outside your hosting account, then delete any archive left inside the site folder, because the cleanup deletes files there. The copy contains wp-config.php, which holds your database password, so keep it private. Label it with the date, for example infected-2026-10-26. WordPress.org’s guide to hacked sites recommends taking one more snapshot before you clean, even if it is infected, so you have that copy to refer to if something fails badly. Our guide on how to back up and restore a WordPress site covers the backup tools in cPanel and DirectAdmin.
3. Change your hosting passwords and sign everyone out. Change the passwords for your hosting control panel, SFTP or FTP, and the database. Then download a copy of wp-config.php. In the file on the server, put the new database password on the DB_PASSWORD line, so the site can still reach its database, and replace the secret keys with a new set from the WordPress key generator. Secret keys are the long random values WordPress uses to recognise a logged-in visitor, so new keys sign out every session, including any the attacker holds.
4. Contact your host. WordPress.org notes that a hack may affect more than your site, especially on shared hosting, and that your host may already be taking steps or can confirm whether you are dealing with a real hack or a loss of service.
5. Tell your payment provider, if you take payments on the site. Report the incident and follow its guidance.
6. Write down what you saw. Note where any redirect sent you, which spam pages appeared, or what the suspension email said, with dates. You will use these notes to match the hack to one of the three patterns below.
7. Check whether customers’ personal data was reached. If the site held customers’ personal data and you think the attacker reached it, you may have a legal duty to notify the Data Protection Commission and those customers as soon as reasonably practicable. The section on reporting a hacked website in Ghana, further down, explains what to do.

How do I know if my WordPress site has been hacked?

Not every outage is a hack. A failed plugin update or a server fault can also take a site down, and your host can tell you which one you are facing.

WordPress.org lists these clear indicators of a hack:

• Google, Bing or another search engine has blacklisted the site
• Your host has disabled the site
• The site has been flagged for distributing malware
• Visitors say their antivirus software flags your site
• You are told your site is being used to attack other sites
• You notice activity you did not authorise, such as new users you did not create
• You can see the hack when you open the site in a browser

If you see any one of these, treat the site as compromised.

Then check what Google sees. If your site is verified in Google Search Console, open the Security Issues report. Google’s Search Console Help says its browser warnings depend on the browsing context, so you may not be able to reproduce them yourself, and you can rely on the Security Issues report as the source of truth for whether security issues exist on your site or have been fixed.

Three hack patterns to match your symptoms against

Match your symptoms to the closest pattern below and use its removal steps alongside the five recovery steps. One hack can combine more than one pattern.

Several removal steps change or delete files and database records. Do them only after you have the copy from your first moves, so you can go back if a change breaks something.

The database steps use table names that start with wp_. Before you run them, open wp-config.php and read the $table_prefix line. If it shows a different prefix, use that prefix in place of wp_.

Pharma SEO hack: drug spam in your search results

Symptoms. Your site starts appearing in Google for pharmaceutical terms you have never used, and a site:yourdomain.com search shows pages you did not create. Those pages may look normal or not exist when you open them yourself, because the spam can be shown only to search engines, a trick called cloaking.

Removal steps

1. Confirm the infection. Note the spam pages from your site: search, then check the Security Issues report, which shows what Google has found even when you cannot see the spam yourself.
2. Search your files for encoded code. Use the File Manager’s search or, if you have SSH (command-line access to the server), run grep -r "base64_decode" wp-content/. Look closely at your theme’s functions.php, your plugin folders and any PHP files inside wp-content/uploads/, the folder that holds your images and documents. Some genuine plugins use base64_decode too, so compare anything you find with a fresh copy of that plugin or theme before you remove it.
3. Inspect the database. In phpMyAdmin, look through the wp_options table for entries you do not recognise, and check wp_posts for published pages you did not create. Note each one. Plugins and themes store their settings in wp_options, so compare an unfamiliar entry’s name with the plugins and themes you have installed. If it matches none of them and contains spam links or encoded code, delete it. Once you have confirmed nobody on your team created the spam pages, delete them.
4. Replace WordPress core and your active theme. Replace the core files the way Step 3 describes. If you edited your theme’s files yourself, copy those edits out first so you can check them line by line and re-apply them. Then delete the theme’s folder in wp-content/themes and upload a fresh, current copy from its official source.

JavaScript redirect malware: visitors sent to other sites

Symptoms. Visitors say your site sent them to a scam, adult or fake-prize page. The redirect may happen only on phones, only on someone’s first visit, or only when they arrive from Google, so the site can look normal when you check it from your desk. Customers who tap your link on WhatsApp or social media can land somewhere else entirely.

Removal steps

1. Check siteurl and home first. In phpMyAdmin, run SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');. If either value points anywhere other than your own domain, the attacker changed it. Edit it back to your real address.
2. Check your theme files for injected scripts. Open functions.php, header.php and the other PHP files in your active theme. Look for script tags or code that decodes hidden text, such as atob() in JavaScript or base64_decode in PHP, especially near checks for mobile, userAgent or Googlebot.
3. Ask your host what its scanner flagged. Its server-level scan can name files you would not think to open.
4. Clear every cache. A redirect can survive in cached pages after you fix the source. Purge your caching plugin, your host’s cache and any content delivery network (CDN) before you test again.

Admin user injection: accounts you did not create

Symptoms. An administrator account you did not create appears in the user list. The username may be generic, such as admin1 or a random string, and its user_registered date is recent. If you clean the site but leave the account in place, the attacker keeps a way back in.

Removal steps

1. Inspect wp_users directly. In phpMyAdmin, open wp_users and sort by user_registered, newest first. Treat any account you do not recognise as suspect, especially one with a generic name or an unfamiliar email domain.
2. Delete accounts you do not recognise. Once you have the copy from your first moves, and everyone who manages the site has confirmed that nobody created the account, delete it in phpMyAdmin, because the dashboard is blocked. Note the account’s ID in wp_users, delete that row, then delete the rows in wp_usermeta whose user_id matches that ID. When you can reach the dashboard again in Step 4, check Posts and Pages for anything the account published and remove what your team did not write.
3. Protect the login. Add brute-force protection and turn on two-factor authentication, a second check such as a code from your phone, for every remaining administrator. Our guide to securing your WordPress login against brute-force attacks covers the setup.

Step 1: Take the site offline without losing your own access

Blocking the site stops visitors receiving malware, spam or redirects while you work. The Apache HTTP Server 2.4 documentation gives this rule for denying all requests:

Require all denied

1. Connect over SFTP, or open the File Manager, and find .htaccess in your site’s main folder. Files whose names start with a dot can be hidden, so turn on the option to show hidden files if you cannot see it.
2. Download a copy of .htaccess to your computer before you change it.
3. Add Require all denied as the first line of the file on the server, and save it.
4. Open the site in a private browser window. If your pages still load, the rule has not taken effect on your server, so ask your host’s support how to block public access instead.

This rule blocks everyone, including you. While it is in place you cannot load the site or reach the WordPress dashboard in your browser. Steps 2 and 3 happen through SFTP, the File Manager and phpMyAdmin, which the rule does not block. Step 4 shows how to let only your own connection back in before the site reopens.

Older guides give Order deny,allow and Deny from all instead. That is the Apache 2.2 form, which Apache 2.4 supports only through a compatibility module, so use Require all denied.

If your host has already suspended the account, the site is offline already. Contact the host to find out what it found and how you can reach your files.

Step 2: Scan the site and find what changed

Your aim is to find every file and database record the attacker changed, and to match them to one of the three patterns above.

• Your host’s server-level scanner. Your host may scan your account for malware at the server level. On LuminWeb WordPress Hosting that scanner is Imunify360, which covers firewall protection and malware scanning. Ask support what it has flagged on your account and which files it named.
• Recently changed files. In the File Manager or your SFTP program, look for files changed around the date your symptoms started, especially PHP files in wp-content/uploads/ and theme files you did not edit.
• The database. Use the pattern checks above on wp_options, wp_posts and wp_users.

Plugin and remote scanners need the site to be reachable, so they come later, in Steps 4 and 5. Keep a list of every flagged file and suspect record. It becomes your checklist for Step 3.

Step 3: Should I restore a backup or clean the site manually?

Restore a backup if you have one from before the infection. Clean the site manually if you do not, or if you cannot tell when the infection began.

	Restore a clean backup	Clean the site manually
When it fits	You have a restore point from before the infection	You have no clean restore point, or cannot tell when the infection began
What changes	Files and database return to the backup’s state, and anything added since is lost	Only the infected files and records you find are replaced or removed
Time	Much faster	Slower, and grows with the number of changed files
Main risk	The backup is already infected, or the original weakness is still there	Missing a hidden file or account

Restore a hacked WordPress site from a clean backup

A restore replaces the files and database on the server with the backup’s versions. Before you restore, confirm that you have the infected copy from your first moves, and export anything added since the backup date that you want to keep, such as orders, form entries or new posts.

1. Find out which restore points exist. LuminWeb WordPress Hosting includes automatic backups. Ask support which restore points exist for your site and how far back they go.
2. Choose a point from before the infection. Start from the date of your first symptom. An infection can begin before anyone notices it, so if you are unsure, pick an earlier point.
3. Restore the files and the database from the same point, so the two match. If your host’s restore tool lets you leave files out, leave .htaccess out of the file restore so your block stays in place.
4. Make sure the site is still blocked. If the restore brought back an .htaccess without the Require all denied line, because the backup is older than your block, add the line back as the first line of the file. Then open the site in a private browser window and confirm it is blocked before you go further. If you left .htaccess out of the restore, clean it now as step 7 of the manual path below describes: compare it with a standard WordPress .htaccess, remove unfamiliar redirect rules, and keep the Require all denied line.
5. Update the restored wp-config.php. The restored file holds the database password and secret keys from before the hack. Put the database password you set in your first moves on the DB_PASSWORD line, and replace the secret keys with a fresh set. If you skip this, the site cannot connect to its database and shows a database connection error instead of your pages.
6. Replace WordPress core, plugins and themes with current versions. The restore brings back the versions the attacker got in through. Replace core the way the manual path below describes. If you edited your theme’s files yourself, copy those edits out first. Then, for each plugin and theme, delete its folder in wp-content/plugins or wp-content/themes and upload a fresh, current copy from its official source.
7. Check the restored site. Repeat the checks from Step 2. If the same signs appear, the cause may be files added after the restore point, because some restore tools put back the backup’s files without removing newer ones. Ask your host whether its restore removes them, and look for files dated after your restore point, especially PHP files in wp-content/uploads/. Remove any you find. If the signs remain after that, the backup was already infected, so pick an earlier point.

For the restore mechanics in cPanel, DirectAdmin and plugins, see our step-by-step WordPress backup and restore guide.

Recover a hacked WordPress site by cleaning it manually

Deleting files cannot be undone, so before you delete anything, confirm that your copy is downloaded off the server and includes all your files and the database.

1. Download a fresh copy of WordPress from WordPress.org and unzip it on your computer.
2. Delete the old WordPress files, keeping the ones you need. Keep wp-config.php, the wp-content folder, .htaccess (it holds your block) and robots.txt if you have one, along with any files or folders you added yourself, such as another site’s folder. Then delete the wp-admin and wp-includes folders and the WordPress files in the main folder: index.php, xmlrpc.php, license.txt, readme.html, and the files whose names start with wp- other than wp-config.php. Then look at what is left in the main folder. If you find a PHP file there that you did not add and do not recognise, ask your host whether it is theirs, and delete it only if it is not. This follows the order in WordPress’s manual upgrade guide, which deletes the old files before uploading new ones and lists a customised .htaccess and robots.txt among the files not to delete.
3. Upload the fresh files in their place. Do not upload the new package’s wp-content folder over yours.
4. Inspect what you kept. Open wp-config.php and look for code you do not recognise, particularly at the top and bottom of the file. Check wp-content/uploads/ for PHP files.
5. Replace your plugins and themes. If you edited your theme’s files yourself, copy those edits out first. Then, for each plugin and theme you use, delete its folder in wp-content/plugins or wp-content/themes and upload a fresh, current copy from its official source.
6. Remove plugins and themes you do not use. Delete them entirely rather than leaving them deactivated, because deactivated code is still on the server.
7. Run the removal steps for your pattern, and clean the live .htaccess. Compare it with the copy you downloaded and with a standard WordPress .htaccess, remove unfamiliar redirect rules, and keep the Require all denied line until Step 4.

Delete before you upload, for core, plugins and themes alike. Copying new files over the old ones replaces the files that ship with the package but leaves in place any extra files the attacker added to those folders.

Not sure which restore point is clean? If your site is hosted with LuminWeb, contact our WordPress support team with your notes and your list of flagged files. The team specialises in WordPress and can answer your questions about restore points, themes and plugins.

Step 4: Close every access point

Do the tasks that need the dashboard while the public is still blocked, and reopen the site last.

1. Change the hosting passwords again. WordPress.org says to change your passwords again after making sure the site is clean, even if you changed them when you discovered the hack, and to cover every access point: FTP or SFTP, the WordPress dashboard, your hosting control panel and MySQL, the database. If you change the database password, update it in wp-config.php too, or the site cannot connect to its database.
2. Replace the secret keys once more. An attacker who could read your files may have seen the set you created earlier.
3. Let only your own connection in. Find your current public IP address by searching “what is my IP” in your browser. In .htaccess, replace the Require all denied line with Require ip followed by that address, for example Require ip 203.0.113.10. The Apache documentation for mod_authz_host says that when Require ip is specified, the request is allowed access if the IP address matches, so other visitors stay blocked. Check on your phone using mobile data that the site is still blocked there. If the dashboard does not load for you, your address may have changed, or a CDN in front of your site may be hiding it, so check the address or ask your host’s support for another way in.
4. Reset every WordPress password. WordPress.org advises forcing a password reset for all users, especially administrators. Change the password of the email account linked to your administrator login as well.
5. Confirm everything is current. In the dashboard, check that WordPress core, every plugin and every theme is on its latest version. Replace any plugin whose developer has stopped releasing updates.
6. Run a plugin scan. Wordfence Security, which the WordPress.org plugin directory lists with 5+ million active installations, can scan your site’s files once installed. Run a full scan and review everything it flags. If your host already scans your account for malware, you can remove the plugin once the scan comes back clean.
7. Turn on two-factor authentication for every administrator.
8. Reopen the site. Once the scan is clean, remove the Require ip line from .htaccess. If the scan flags something, keep the site blocked and go back to Step 3.

To keep weak plugins out from now on, audit your plugins on a regular schedule, and check our list of essential WordPress plugins for a business website before you add new ones.

Step 5: Get Google’s warning removed

First, check the site the way a visitor would. Open it in a private browser window on a phone using mobile data, and confirm the redirects or spam pages are gone. For an outside view, Sucuri SiteCheck is a free remote scanner that checks a URL for known malware, blacklisting status, website errors and out-of-date software. Sucuri says remote scanners have limited access and results are not guaranteed, so a clean result does not prove the site is clean.

Then ask Google to review the site. In Search Console, open the Security Issues report, select Request Review once every listed issue is fixed, and describe what you fixed.

How long does a Google security review take?

Google’s help page says a review can take from a few days to a few weeks. The wait starts only once you have finished the cleanup and requested the review.

The cleanup itself varies. Restoring a clean backup is much faster than cleaning by hand, and a manual cleanup takes longer the more files and database records the attacker changed.

What does it cost to fix a hacked WordPress site?

Restoring a backup you already have costs mostly your time. A manual cleanup costs more of your time or, if you hire a specialist, their fee, so compare more than one specialist’s prices before you hire. If you might hire a specialist based outside Ghana, check which payment methods they accept before you ever need them, rather than in the middle of an incident.

The least costly recovery is one you prepared for, with a backup from before the attack and a host that scans for malware.

Where do I report a hacked website in Ghana?

You can report the incident to Ghana’s Cyber Security Authority (CSA). Its incident reporting form sends what you submit to CERT-GH for triage and further investigation. The CSA also takes reports by email at report@csa.gov.gh and by call or SMS on 292. Reporting is an option open to you. Include your notes on what you saw and when.

If customers’ personal data was reached, you must notify the Data Protection Commission

A separate rule applies when the hack reached personal data. If your site held customers’ personal data, such as names, phone numbers, emails or order details, and you have reason to believe the attacker accessed or took it, Ghana’s Data Protection Act, 2012 requires your business, as the data controller, to notify the Data Protection Commission and the affected customers as soon as reasonably practicable after you discover it. The duty sits with your business as the data controller. Do not assume your host will notify anyone for you.

• The Commission. It publishes an incident and data breach report form and asks for the completed form to be sent to incidents@dataprotection.org.gh.
• Your customers. The Act lets you notify them by email, by registered mail, by a prominent notice on your website, or through the media. Give them enough detail to protect themselves, such as which data was involved and what they can do about it.

This is not legal advice. If you are unsure whether personal data was reached, speak to the Commission or a lawyer.

Why WordPress sites get hacked

Most of the risk sits in plugins and themes rather than WordPress itself. Patchstack’s State of WordPress Security in 2026 reports that 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, a 42% increase compared to 2024. Of those, 91% were in plugins and 9% in themes. Only 6 were reported in WordPress core, and those were low priority.

Attackers also move fast. Patchstack found that for heavily exploited vulnerabilities, the median time to mass exploitation was 5 hours, and approximately half of high impact vulnerabilities were exploited within 24 hours. A site that waits days to apply an update can be attacked in that gap.

No single defence stops everything. In Patchstack’s 2025 pentests (simulated attacks) of common hosting security solutions such as internal web application firewalls (filters that block suspicious requests) and Cloudflare, traditional defences blocked only 12% of WordPress-specific attacks on known exploited vulnerabilities, and only 26% of total attacks in a broader second test.

How do I stop my WordPress site being hacked again?

Layer your defences, because each one covers gaps in the others:

• Keep WordPress, plugins and themes updated, and delete anything you no longer use.
• Use strong, unique passwords and two-factor authentication for every administrator.
• Choose one security plugin for the recovered site. Our comparison of WordPress security plugins covers how the main options differ.
• Keep backups you can restore from, including a copy stored outside your hosting account. Our WordPress backup strategy guide covers how often to back up, where to store copies and how to test them.
• Host with server-level malware scanning, so a problem can be caught on the server, not only by a plugin inside WordPress.

For the full list of protections, work through our WordPress security checklist.

When to call a professional

Bring in a specialist, your host or a lawyer if any of these apply:

• Customers’ personal data may have been accessed or taken. You have a duty to notify the Data Protection Commission and those customers, as set out above.
• The hack came back after a careful cleanup. Something is still hidden, such as an account, a planted file or a vulnerable plugin.
• You cannot reach your control panel, SFTP or the database. Your host has to restore access before any recovery can start.
• You cannot tell which files the attacker changed. A specialist can work from your host’s scan results and your notes.

If your site is hosted with LuminWeb, get in touch with our WordPress support team and tell them what you found.

Make the next incident easier to recover from

Prevention starts with your hosting. LuminWeb WordPress Hosting for businesses in Ghana includes Imunify360 firewall protection and malware scanning, automatic backups, and a support team that specialises in WordPress. You can compare plans and current prices on our Ghana hosting page.