How to Fix a Hacked WordPress Website

A hacked WordPress website is usually fixable. With the right approach, you can recover the site, protect your data and get things back to normal.

What matters is how quickly and how methodically you respond. This guide walks you through the process of repairing a hacked WordPress site step-by-step, from how to confirm if your site is compromised to how to recover it, remove malware and redirects, and stop it from happening again.

 

 

How to tell if your WordPress website has been hacked

Most hacked websites do not show obvious signs straight away. Some break completely, while others keep working while losing traffic, revenue or customer trust.

However, some issues are obvious. When these appear, you can safely assume your WordPress website has been hacked until proven otherwise:

These are standard symptoms we see across hacked WordPress websites. If you see two or more at the same time, treat it as a confirmed issue and investigate immediately. Delays here can cost traffic, revenue and, in some cases, customer trust that is very difficult to recover.

 

Why WordPress websites get hacked

Most WordPress websites aren’t singled out. Hackers usually scan loads of sites looking for known weak spots and hit anything that’s vulnerable. If your site has a gap, it’s only a matter of time before it gets found.

More often than not, this gap comes down to the basic website maintenance : updates not being done, poor access control or settings not being properly configured.

Outdated plugins and themes are often the biggest factor. Once a vulnerability is public, automated tools start scanning for it. Weak or reused passwords make access even easier, especially when combined with credential leaks from other platforms. On top of that, insecure hosting, poor site isolation and overly permissive file settings widen the attack surface. Add in abandoned plugins, unsafe upload forms or code injection tools, and you are effectively leaving the door wide open.

Once a weakness exists, the methods used to hack WordPress websites are predictable. For example, attackers exploit plugin vulnerabilities, run automated login attempts, reuse stolen credentials or inject code into the database and files. Techniques like SQL injection and cross-site scripting (XSS) allow them to manipulate content or take control of sessions. Others focus on persistence, adding backdoors or hiding redirect scripts that only trigger under certain conditions.

In short, WordPress websites get hacked because something was left exposed.

 

What to do immediately after a hack

If you discover your WordPress website has been hacked, your priority is to contain the issue, protect users and keep enough access to investigate properly. Do not start deleting files or reinstalling plugins yet, as that often removes evidence and leaves backdoors behind.

Start by isolating the website. If users are being redirected, served malware or seeing broken pages, take the site out of circulation. Use maintenance mode if WordPress is still accessible. If not, apply password protection at server level.

Next, work out what access you still have. Try WordPress admin, but do not rely on it. Check your hosting panel, then file access through FTP, SFTP or SSH. If admin login fails, go straight to the database and confirm whether users or settings have been changed.

It is worth asking your hosting provider for access and error logs so you can see when the issue started and what triggered it. Check if they have already flagged malware or restricted your account. On shared hosting, confirm whether this could be cross-site contamination rather than an isolated issue.

Finally, reset credentials across the board. This means changing WordPress admin logins, hosting access, file transfer credentials, database passwords and any connected email accounts.

 

Investigate how the hack happened

Cleaning the site without identifying the entry point is wasted effort. Most reinfections happen because the original weakness is still there. Due to this, a key part of responding to a hacked WordPress website is to understand how the situation arose in the first place.

Start with the data you already have. Check activity logs for changes to users, plugins or settings around the time the issue started. Review access logs for unusual requests, repeated login attempts or spikes from a single IP. Error logs can highlight files that were modified or broken during the attack.

Then focus on access. Most compromises involve someone getting in, not just code being injected. Look for admin users you do not recognise, or accounts that have been recreated after deletion. Check FTP, SFTP and SSH access for anything unfamiliar. Pay attention to logins from unexpected locations or accounts gaining higher privileges.

From there, narrow down the likely entry point. In most cases, it comes down to a small number of causes:

• A vulnerable plugin or theme, usually outdated or recently changed
• Weak or reused credentials, often exposed through brute force or credential stuffing
• Database injection, where malicious content or users are inserted directly
• A server-level issue, such as poor isolation or outdated software
• A compromised local machine, where credentials were stolen outside the site

You might not find a perfect answer. What matters is landing on a reasonable explanation you can act on; something you can fix and close off so it doesn’t happen the same way again.

 

Remove malware and repair the website

Deleting obvious malware is not enough. If you miss hidden code or leave the entry point open, the website will be reinfected.

Start with WordPress core files. These should never be edited, which makes them the easiest place to reset. Download a fresh copy from wordpress.org and overwrite everything except wp-config.php and the wp-content directory. wp-config.php holds your database credentials, and wp-content contains your themes, plugins and uploads.

Next, deal with plugins and themes. This is where most infections originate. Do not try to clean them manually. Instead, delete anything affected and reinstall from a trusted source. If a theme has been modified, assume it is compromised and replace it. Remove anything unused or unsupported. If you cannot verify where it came from, it should not stay on the site.

After that, move to manual inspection. Some areas cannot be safely replaced and need to be checked directly. Focus on common hiding places:

• wp-content/uploads
• Inactive or unused themes
• Child themes
• Plugin directories
• Key files such as functions.php, header.php, footer.php, index.php, wp-config.php, wp-load.php and .htaccess

These locations are often ignored during routine maintenance, which is why attackers use them.

When reviewing files, focus on behaviour, not just appearance. Malware is usually hidden, not labelled. Watch for obfuscated JavaScript, encoded PHP or redirect logic that only triggers under certain conditions. Functions like eval(), base64_decode(), gzinflate(), preg_replace() and str_rot13() are commonly used to execute hidden code. They are not always malicious, but in a hacked WordPress site they are a strong signal.

If you find something you cannot explain, remove or replace it with a clean version. The next step is making sure the same access point cannot be used again.

 

Remove malicious redirects

Redirects are often where the damage shows up. They send your visitors somewhere else, waste your traffic and quickly make your site look untrustworthy.

They’re not always easy to get rid of either. This isn’t because they’re especially complicated, but because they’re usually hidden well enough to be missed if you’re not looking carefully.

Where redirects hide and why they are hard to catch

Redirects can be injected almost anywhere code runs or content is rendered. Common locations include:

• Theme files and templates
• Plugin files
• JavaScript assets
• Widgets and dynamic content areas
• Posts and pages
• Code snippet or custom script plugins
• Database content, such as options and post metadata
• .htaccess server rules
• Third-party scripts, such as ad networks

They’re also easy to miss because they don’t always show up. For example, they might:

• Only trigger on mobile devices
• Only affect traffic from search engines
• Depend on referrer, browser or user agent
• Not trigger for logged-in admins

That’s why everything can look fine on your end while real users are getting redirected. If you can’t reproduce it, change how you’re testing. Log out, use incognito, try a different device and switch browsers until you see what your users are seeing.

How to remove malicious redirects

When it comes to removing malicious redirects from a hacked WordPress website, you need to be methodical. Start with what the user actually sees:

• Inspect page source. Look for injected scripts, iframes or unexpected external calls.
  Check <script> tags. Focus on obfuscated or dynamically generated code.

Then move into the code:

• Review theme and plugin files. Prioritise headers, footers and template files.
• Search files via FTP, SFTP or SSH. Look for unfamiliar domains, encoded strings or redirect logic.
• Inspect .htaccess. Server-level rules can override everything else.

After that, look at stored and external sources:

• Disable suspicious third-party or ad scripts.
• Scan and clean database content. Specifically, check posts, widgets and options for injected scripts.

If you find something you can’t clearly explain, remove it. Where possible, replace files entirely instead of trying to edit them.

Once you think it’s clean, test again in different conditions. If the redirect is still happening, you haven’t found the source yet.

 

Clean the database

File clean-up is only half the job. A lot of WordPress malware lives in the database. If you skip this step, the site can reinfect itself even after you replace the files.

What to look for

Focus on anything that should not be there or does not match how the site normally works, such as:

How to clean it

Take your time with this, as database changes are much harder to undo than file changes. The main steps you should take include:

Getting the database properly clean is often what makes the difference between fixing the issue once and having it come back again.

 

Restrict website access

Most hacks come down to access. If the wrong people can get in, cleaning the site won’t fix the problem for long, as they’ll just use the same way back in again.

Start by removing anything you do not trust. Go through WordPress users first and remove any accounts you did not create or cannot verify, especially at admin level. Then check FTP, SFTP and SSH access and delete anything unfamiliar or no longer needed. Do the same for your hosting or control panel access. The basic rule is: if an account is not required, it should not exist.

Next, assume all credentials have been exposed and reset them properly. Update passwords for all users, not just admins. If needed, replace the database password and update it in wp-config.php. Rotate the WordPress salts in wp-config.php to invalidate all active sessions. This logs out anyone who should not have access.

Once access is clean, make it harder to abuse. Enable 2FA (two-factor authentication) so passwords alone are not enough. Add CAPTCHA to login and key forms to reduce automated attacks. Limit login attempts to block brute force behaviour, and enforce strong passwords across all users. These are simple controls, but they remove the most common entry points attackers rely on.

 

Update the site and clean things up properly

Cleaning the website just gets you back to square one. What matters next is stopping the same thing happening again.

Update and remove risk first

Outdated software is the most common entry point. Update WordPress core, all active plugins and themes, and your PHP and server environment. If something cannot be updated, it becomes a risk. In most cases, it should be replaced or removed.

At the same time, reduce what is running on the site. Remove unused plugins and themes, anything unsupported, and anything you do not fully trust. This includes nulled themes, unofficial downloads and code injection tools that allow direct execution.

Add protection where it matters

Security isn’t about throwing loads of tools at the problem. Focus on things that actually reduce risk and help you spot issues:

• Web application firewall (WAF) to filter malicious traffic
• Malware scanning to detect known threats
• File integrity monitoring to catch unexpected changes
• Brute force protection to limit login attempts
• Activity logging to track user and system changes
• Downtime monitoring to alert you when the site breaks

You ay also need spam filtering or rate limiting depending on how the site is used.

Reduce how much is exposed

The fewer ways into your site, the better. Disable XML-RPC if you are not using it, restrict access to wp-admin, wp-cron.php and other sensitive endpoints where possible, and review which REST API endpoints actually need to be public.

You should also tighten file permissions so files cannot be modified unnecessarily, and apply least-privilege access across all users.

This isn’t about making the site “perfectly secure”. Instead, it’s about removing the easy opportunities and keeping control over who and what can access it.

 

Check everything before putting the site fully live

A site can look fixed and still not actually be clean. Before you put it fully back into use, you need to make sure the main parts of the site work properly and that the original issue has genuinely gone.

If anything still looks off or gets flagged, the clean-up isn’t finished.

 

Clean up search results and reputation damage

Fixing a hacked WordPress website is only part of the recovery. Search results and user trust usually take longer to recover.

Handle indexed hacked URLs

Hacked content often gets indexed quickly, especially when it targets search traffic.

Return a 410 status for spam URLs where appropriate. This tells search engines the page is intentionally gone, which is clearer than a 404 status code . You will then need to be patient, as deindexing takes time, meaning that the URLs may continue to appear for days or weeks after removal.

Also, don’t rely too heavily on the Google Search Console removal tool. It’s fine for a few URLs, but it’s not built for clearing out loads of random spam pages in bulk.

Submit clean signals to Google

Once the site is properly cleaned, you need to make that visible.

Submit an updated XML sitemap so search engines can prioritise valid pages again. If the site was flagged as hacked or unsafe, request a review through Search Console. If your domain has been blocked by browsers or security providers, you will need to go through their review process as well.

Communicate with users if necessary

Not every situation needs an announcement, but some do. If users were affected, keep it simple and clear. Say what happened, what you’ve fixed and if there’s anything they need to do (like resetting passwords or checking their account).

 

How to prevent it from happening again

Most WordPress websites don’t just get hacked once; they get hit again. This isn’t because the attacks are advanced, but because the same gaps are still there. Due to this, the final step in repairing a hacked WordPress website is to simply stay on top of things.

Ongoing website maintenance

Most problems come down to day-to-day maintenance, so this is where to focus:

• Keep everything updated to avoid known vulnerabilities in WordPress core, plugins, themes and server software. For a deeper look at this, see our guide to keeping WordPress websites secure .
• Monitor logs and run regular scans so issues are caught before they become visible problems.
• Review users regularly to remove access that is no longer needed, especially at admin level.
• Remove anything unnecessary because every plugin, theme or script increases your attack surface.
• Keep backups off-site so they remain usable if your hosting environment is compromised.

Hosting and infrastructure

Your hosting and setup set the baseline for how secure your site is:

• Use quality hosting because lower-cost providers often have weaker isolation and slower response to security issues.
• Use SSL (Secure Sockets Layer) to encrypt data in transit and protect login sessions.
• Use SFTP or SSH instead of FTP because FTP sends credentials in plain text.
• Use a CDN or WAF (Web Application Firewall) where appropriate to add a protective layer between your site and incoming traffic.
• Ensure proper site isolation so one compromised site cannot affect others on the same server.

Access and usage controls

Access is one of the most common weak spots, so it needs to be controlled properly:

• Use unique passwords
• Enable 2FA (two-factor authentication)
• Secure admin machines
• Give users only the permissions they need
• Avoid abandoned plugins or themes
• Do not use nulled or unofficial software

Security failures are usually the result of small gaps, not single major mistakes. Close the gaps, and the risk drops quickly.

A hacked WordPress website can usually be fixed. The process isn’t overly complex, but it does need to be done properly. Cleaning up what you can see is only part of it. If you don’t fix how they got in, it will happen again.

That is exactly what our professional hacked WordPress website repair service is designed to handle. It removes the infection, fixes the root cause and secures the site so it stays protected.

If your site has been compromised, acting quickly makes all the difference. The sooner it is properly cleaned and secured, the less impact on your traffic, revenue and reputation. Prevention is always easier and cheaper than dealing with it again later but, when it does happen, getting it fixed properly the first time is what matters most.