My website has been hacked. What do I do?

September 3, 2026
16 minutes read
211 Views

Few things get a website owner’s attention faster than opening their site and seeing something that clearly should not be there. Perhaps the homepage has been replaced. Maybe visitors are being redirected somewhere else. Strange pages have appeared in Google. The browser is showing a security warning. Or perhaps everything looks normal, but you suddenly receive a message saying that malicious code has been detected. Whatever the symptom, the first reaction is usually the same:

What do I do now?

The most important thing is not to start randomly deleting files, reinstalling plugins or changing settings without first understanding what has happened. A compromised website can often be recovered. The bigger challenge is understanding how the compromise happened and making sure the same problem does not return.

First: assume the website is compromised

If you have a reasonable reason to believe the website has been hacked, treat it as compromised until you know otherwise. A website does not necessarily have to look visibly hacked. In fact, many compromises are designed specifically to remain unnoticed.

Common signs include:

• visitors being redirected to another website

• unfamiliar pages appearing in Google search results

• new administrator accounts

• unknown files appearing on the server

• security warnings in the browser or Google Search Console

• unexpected changes to content

• emails being sent from the website without your knowledge

• a sudden increase in server load or bandwidth usage

• plugins or themes behaving strangely

• files being modified without anyone on the team making changes

Sometimes the website itself appears completely normal while malicious code runs quietly in the background. In practice, the obvious visual damage is often the easiest part of the problem. A replaced homepage is noticeable. A hidden script sitting inside a plugin directory may not be. The absence of an obvious visual change does not mean everything is fine.

Do not immediately delete everything

When something looks wrong, the temptation is often to remove suspicious files immediately. That can be a mistake. Before making major changes, create a copy of the website and, where possible, preserve relevant logs. Even an infected backup can be useful because it provides a snapshot of what happened. Server access logs, file modification dates and security logs can help establish when the compromise happened and potentially how the attacker gained access. This matters because once files are replaced or deleted, some of that evidence may disappear. One of the more common mistakes is treating the situation as a cleanup exercise before understanding the incident itself. The goal is not simply to remove the strange file.

The goal is to understand why that file was there.

Restrict access if necessary

If the website is actively redirecting visitors, distributing malware, exposing private information or otherwise presenting an immediate risk, temporarily restricting public access may be the sensible option. For an ecommerce website, membership site or platform containing customer information, the situation can be more serious than a compromised brochure website.

The purpose is not simply to make an embarrassing page disappear. It is to prevent the compromised system from continuing to cause harm while the problem is investigated.

A maintenance page can sometimes be preferable to leaving a compromised website online. This is particularly true if visitors are being redirected somewhere malicious or if there is any possibility that customer data is involved.

Check your hosting account and provider notifications. Your hosting provider may have detected suspicious activity before you did. Security alerts, malware scans, access logs and backup information can all provide useful clues when establishing what happened. It is worth checking your hosting dashboard, recent notifications and any security reports before making major changes. Depending on the provider and the severity of the incident, a compromised website may also be temporarily restricted or quarantined if it poses a risk to visitors, other websites or the provider’s infrastructure. That does not necessarily mean the hosting provider caused the problem. It may simply mean their systems detected activity that should not be allowed to continue.

If you contact your provider, useful questions include:

• When did suspicious activity first appear?

• Are other websites or services in the same account affected?

• Are older backups available?

• Can relevant access and security logs be preserved?

• Has the hosting account itself been accessed unexpectedly?

• Did the provider detect malware or quarantine any files?

Hosting is only one part of the picture.

Depending on the incident, the relevant service provider could also be your domain registrar, DNS provider, CDN provider, email provider, ecommerce platform, payment provider or another service connected to the website. Change your passwords, not just your WordPress password. Changing the website administrator password is sensible, but website access rarely exists in isolation.

Depending on the setup, credentials may exist for:

• the CMS

• hosting

• FTP or SFTP

• SSH

• the database

• domain registrar

• DNS provider

• CDN

• email accounts

• deployment services

• third-party integrations

If an attacker gained access through one of these systems, changing only the WordPress password does very little. Passwords should be unique, and multi-factor authentication should be enabled wherever it is available. It is also worth checking whether unfamiliar users, API keys or access tokens have been created. A website is rarely just a website anymore. It is usually connected to hosting, DNS, email, analytics, payment systems, external services and several user accounts. That entire chain matters during an incident.

Find out how the attacker got in

Cleaning a website without identifying the entry point is one of the most common reasons compromised websites become compromised again. Imagine repairing a broken window while leaving the front door open.

Typical causes include outdated plugins, vulnerable themes, stolen credentials, insecure hosting accounts, compromised administrator computers, abandoned software and poor access controls. Sometimes the vulnerable component is obvious. Sometimes it is not. This is where logs, file comparisons and security scans become useful. Simply finding one malicious file does not necessarily mean you have found the original vulnerability. In practice, a website can appear completely clean after the visible malware has been removed and still remain vulnerable for exactly the same reason it was compromised in the first place. That is why recovery and prevention cannot really be separated.

Check the website files

A compromised website may contain modified legitimate files, completely new files or both. Attackers often place malicious code where it is unlikely to attract attention. They may also use filenames that resemble normal system files. With WordPress, the core files can be compared against clean versions of WordPress. Plugins and themes can similarly be compared with trusted originals where those originals are available. However, custom themes and heavily modified websites require more care. Replacing everything indiscriminately could also remove legitimate development work. The database should be checked as well. Malicious code, spam links, administrator accounts and injected scripts can all exist in the database rather than the filesystem. A clean-looking file system therefore does not automatically mean the entire website is clean.

Look for persistence

One of the more frustrating aspects of website compromises is persistence. An attacker may leave several different ways of regaining access. Removing the most obvious malicious file may therefore appear to fix the problem, only for the website to become infected again a few hours or days later.

A proper review should look for unusual administrator accounts, scheduled tasks, modified server configuration, hidden scripts, unfamiliar database entries and other mechanisms that could restore the malicious code. This is also why simply installing a security plugin after an incident is not necessarily enough.

Security software can be useful, but it cannot automatically prove that every part of an already compromised environment is trustworthy again. The first malicious file you find is not necessarily the only malicious file. Quite often, it is not the most important one either.

Check the server, not only the website.

If several websites exist inside the same hosting account, the problem may not be limited to the website where the symptoms first appeared. A compromised account can sometimes allow malicious code to spread between websites. That means neighbouring installations, staging environments and forgotten old websites deserve attention too. An old WordPress installation sitting in a folder nobody remembers can still become the entry point into an otherwise well-maintained hosting account. This is something website owners often overlook because they naturally focus on the site visitors can see. From the server’s perspective, an old staging site or forgotten subdomain can be just as relevant as the main website. Removing unused websites and software is therefore part of security maintenance, not simply housekeeping.

Check Google Search Console

Search engines may discover a compromised website before its owner does. Google Search Console can show security issues, suspicious pages and other problems associated with the website. It is also worth manually checking what Google has indexed.

Try searching:

site:yourdomain.com

Look for unfamiliar titles, languages, products, casino pages, pharmaceutical pages or anything else that clearly does not belong there. Search spam is a common form of website compromise. Attackers insert large numbers of pages into a legitimate website in an attempt to benefit from the domain’s existing reputation. Sometimes these pages are difficult to spot because normal visitors never see them while browsing the website. They may exist primarily for search engines. Even after the website has been cleaned, those pages may remain visible in search results for some time.

Do not restore a backup blindly

Restoring yesterday’s backup sounds like an obvious solution. Sometimes it is.

But there is an important question:

When was the website actually compromised?

If the attacker gained access three weeks ago, yesterday’s backup may already contain the same malicious code. This is one of the easiest mistakes to make because restoring a backup can make the problem appear solved immediately. The website loads again. The strange redirect disappears. Everything looks normal. But if the vulnerability remains, or if the backup already contains the compromise, the website can simply be infected again. A backup is only useful as a clean recovery point if you have reasonable confidence that it predates the compromise. This is why keeping several generations of backups is considerably more useful than keeping only the most recent copy.

Update everything after the website is clean

Once the compromise has been removed and the entry point understood, outdated software should be updated.

This includes the CMS, plugins, themes and, where relevant, server-side software. Anything that is no longer maintained should be reconsidered entirely. A plugin that has not received an update in years may continue functioning perfectly while simultaneously becoming a security liability.

The same applies to old themes, forgotten integrations and abandoned administrator accounts.

There is often a tendency to leave old components alone because they still work.

From a security perspective, “it still works” is not the same thing as “it is still safe to run.”

Check the computers used to manage the website

Not every website compromise begins on the server. If credentials were stolen from a computer through malware, a malicious browser extension or another compromise, changing the server password from the same infected machine may simply give the attacker the new password. The computers used to administer important websites should therefore be treated as part of the security environment. Website security does not end at WordPress. It also includes the device used to log into WordPress, the browser storing passwords, the email account used for password resets and every other service capable of changing the website.

Think about customer data

If the website processes personal information, payments, customer accounts or other sensitive data, the incident may have implications beyond restoring the website. You may need to establish what information was accessible, whether it was actually accessed, how long the compromise existed and what legal or contractual obligations apply. For organisations operating in the EU, a personal-data breach can also create obligations under the GDPR. Not every compromised website automatically becomes a reportable personal-data breach, but the possibility should not be ignored. The technical investigation should therefore answer more than simply: Does the homepage work again?

A functioning homepage tells you very little about whether data was accessed or what happened before the website was restored.

After recovery, reduce the attack surface

The best time to reconsider website security is immediately after seeing how many different systems are involved. A sensible setup usually means fewer unnecessary components, fewer privileged users, current software, strong authentication, reliable backups and proper monitoring. Unused plugins should be removed rather than merely deactivated. Old accounts should disappear. Administrator access should be limited to people who actually need it. Backups should exist outside the production server. Updates should be part of normal maintenance rather than something that happens after a problem appears. Security is often less about adding another plugin and more about removing things that should no longer be there.

A compromised website is not necessarily a lost website

Seeing an unfamiliar page where your business website used to be can make the situation look worse than it is. In many cases, the website itself can be recovered. The more difficult question is establishing exactly what happened and making sure it cannot immediately happen again. That means recovery is not simply about removing whatever looks suspicious. It is about preserving what matters, identifying the entry point, removing the compromise, checking for persistence, securing every relevant account and understanding whether anything beyond the website itself has been affected.

In practice, the visible malware is often the easiest thing to remove. The real job is finding the reason it was possible in the first place.

Tags:

Cyber security

Development