If you think your WordPress website has been hacked, someone may have gained access to part of it without your permission and changed something: files, content, users or settings.
A hack can affect:
- what visitors see on the website
- where visitors are sent when they click a link or a search result
- who can log in to the WordPress dashboard
- the emails the website sends
- customer data, orders or form submissions
- how Google and browsers treat the website
- other websites hosted on the same account
Discovering a hack is stressful, especially when the website supports your business. However, it does not necessarily mean that your content or data has been lost or stolen. In many cases, the website can be cleaned, secured and brought back to normal.
The most important thing in the first hour is not to delete everything and start again. Hasty changes can destroy the evidence needed to understand how the attacker got in, and leave the real problem in place.
This guide explains the common signs of a hack, the first safe steps to contain it, what to avoid and when it is better to ask for specialist support.
What are the signs that a WordPress website has been hacked?
Some hacks are obvious. Others are designed to stay hidden for as long as possible.
Common signs include:
- visitors are redirected to unrelated or spam websites
- Google or the browser shows a warning that the site is dangerous or may be hacked
- pages you did not create appear in Google, often in another language
- the homepage has been replaced with a message or image
- you can no longer log in with your usual password
- new administrator accounts appear in the user list
- the website sends spam emails or your hosting provider reports outgoing spam
- the hosting provider has suspended the account or quarantined files
- the website has become much slower without an obvious reason
- a security plugin or hosting scanner reports modified or suspicious files
- customers report strange pop-ups, downloads or payment pages
One of these signs alone does not prove a hack. A redirect may come from a misconfigured plugin, and a slow website may simply need optimization.
But if you see several of them, or something you cannot explain, treat the situation as a possible security incident until you know more.
Why do WordPress websites get hacked?
WordPress itself is actively maintained and security updates are released regularly. Most compromises happen through the parts around it.
Outdated plugins or themes
A plugin or theme with a known vulnerability is one of the most common entry points. Once a vulnerability is public, automated tools can scan large numbers of websites looking for installations that have not been updated.
This applies also to plugins that are installed but deactivated, and to themes that are not in use. Their files are still on the server.
Weak or reused passwords
An administrator, hosting or SFTP password that is short, common or reused on other services can be guessed or obtained from a data breach elsewhere.
Nulled or pirated themes and plugins
Premium themes and plugins downloaded for free from unofficial sources sometimes contain hidden code that gives someone else access to the website. They also stop receiving security updates.
Shared or forgotten access
Old accounts belonging to former suppliers, colleagues or agencies, shared logins and credentials sent by email can all become a route in.
Other websites on the same hosting account
If several websites share one hosting account, a compromise in one of them can sometimes spread to the others.
A compromised device
Malware on a computer used to manage the website can capture passwords as they are typed. This is one reason why passwords should be changed from a device you trust.
First: do not panic and do not delete everything
When you discover a hack, it is natural to want to remove all traces as quickly as possible.
Deleting the website, reinstalling WordPress or restoring the oldest backup you can find may feel decisive. In practice, it can:
- destroy the evidence that shows how the attacker got in
- delete recent orders, messages or registrations
- leave the original vulnerability in place
- leave hidden backdoors in files you did not replace
- leave other websites on the same account infected
A calmer approach is more effective. The first goal is to contain the incident, then to understand it, and only then to clean and secure the website.
What should you do immediately?
These first steps are mostly organisational. You do not need technical skills to do them.
1. Record what you are seeing
Collect:
- screenshots of anything unusual
- the affected URLs
- the date and approximate time you noticed the problem
- emails from your hosting provider, Google or WordPress
- reports received from customers
- any recent changes to the website you are aware of
Write down what you do from this point onwards, with the time. This record will be useful to anyone who investigates the incident.
2. Change passwords from a clean device
If you suspect that your own computer may be infected, use a different device you trust.
Change, in this order of priority:
- the hosting control panel password
- SFTP or FTP passwords
- the passwords of WordPress administrator accounts
- the email account linked to the WordPress administrator, if it may be affected
- the database password, if you or your developer can update it safely
Use long, unique passwords and enable two-factor authentication wherever it is available, especially for the hosting account.
Changing the database password also requires updating wp-config.php with the new value, otherwise the website will stop working. If you are not sure how to do this, ask your hosting provider or developer to do it.
3. Review administrator accounts carefully
In WordPress, open:
Users → All Users
Then filter by the Administrator role.
Look for accounts you do not recognize, unexpected email addresses or users created recently.
Before removing an unknown administrator:
- take a screenshot or note the username, email address and any other visible details
- consider changing its password or role first, rather than deleting it immediately
When you delete a WordPress user, WordPress asks what to do with the content that user created. Choosing the wrong option can delete pages or posts. Recording the details first also preserves useful evidence.
4. Preserve a copy of the current state
Before anything is cleaned or replaced, ask your hosting provider or developer to make a full copy of:
- the website files
- the database
- the available server and access logs
This copy may be infected, so it must not be restored over the live website. Its purpose is to support the investigation.
5. Inform your hosting provider
Your hosting provider may be able to:
- confirm whether malware was detected
- tell you which files were quarantined
- share access logs
- check whether other websites in the account were affected
- help you restrict access temporarily
- provide information about available backups
Some providers may suspend the account to protect their infrastructure. If that happens, ask what they need from you to restore access.
6. Check the other websites on the same account
If the hosting account contains other websites, test databases or old copies of the site, they should be checked too. An old forgotten installation is a common hiding place for malicious files.
Why is restoring a backup not enough?
A backup can be very useful during recovery, but restoring one is rarely a complete solution on its own.
There are three main reasons:
- The vulnerability remains. If the attacker came in through an outdated plugin or a weak password, the restored website has the same weakness and can be compromised again.
- The backup may already be infected. Some hacks stay hidden for weeks or months before they become visible. A backup made during that time may contain the malicious code.
- Recent data can be lost. Orders, form submissions, user registrations and content created after the backup will be overwritten.
A restore can still be part of the solution. It should be used together with an investigation of the entry point, a check of the restored files and a plan to recover any recent data.
D4Hub can help you evaluate which backup is suitable and how to combine it with a proper cleanup.
How do you find and fix the entry point?
Cleaning the visible symptoms without closing the entry point is one of the most common reasons why a website is hacked again shortly after cleanup.
A proper investigation normally looks at:
- which plugins and themes are installed, including inactive ones, and whether they are up to date
- whether any of them have known vulnerabilities
- whether any theme or plugin came from an unofficial source
- which user accounts exist and which of them were used recently
- whether files in the WordPress core, plugins or themes have been modified
- whether PHP files are present where they should not be, such as the uploads folder
- whether the database contains injected scripts, links or unexpected options
- whether scheduled tasks have been added
- what the server access logs show around the time of the compromise
Once the cause is identified, the fix may involve updating or replacing components, removing abandoned software, resetting credentials, reviewing file permissions and improving the hosting configuration.
Check Google Search Console
If your website is connected to Google Search Console, open the property and go to:
Security & Manual Actions → Security Issues
The report may show whether Google has detected hacked content, malware or other security problems, with example URLs.
These URLs are samples, not a complete list. Once the whole website has been cleaned and secured, you can request a review from the same report.
If you are not sure who manages Search Console for your website, check with your agency, developer or marketing team. Our guide on what to do when Google has marked your website as dangerous explains this process in more detail.
What if personal data may have been exposed?
If the website stores personal data, such as customer accounts, orders, form submissions or newsletter subscribers, a hack may also be a personal data breach.
Under the GDPR, controllers generally have to notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people. In some cases, the people affected must also be informed. Rules may differ in other countries.
Whether this applies to your incident depends on what data was involved and what the attacker could access. Speak to your Data Protection Officer or legal advisor as early as possible, and share with them the information you are collecting about the incident.
Technical support can help establish what was accessible, but the legal assessment should be made by the people responsible for data protection in your organization.
What should you avoid doing?
Avoid:
- deleting the website or reinstalling everything before preserving a copy
- restoring an old backup without checking its date and contents
- changing passwords from a device that may be compromised
- deleting unknown users without recording their details
- installing several security plugins at once
- copying cleanup code found in forums without understanding it
- assuming the problem is solved because the homepage looks normal
- sharing passwords, logs or backups through ordinary email or public forums
- ignoring other websites on the same hosting account
- making several changes at once without noting what you did
Change one thing at a time and keep a record. If you are unsure about a step, stopping is often safer than continuing.
When should you ask for specialist support?
Ask for technical support when:
- the website redirects visitors to unrelated pages
- Google or browsers show a security warning
- unknown administrators have appeared
- you can no longer log in
- the hosting provider has suspended the account
- the website handles payments, subscriptions or personal data
- you do not know when the compromise started
- you do not have a backup you are confident is clean
- several websites share the same hosting account
- the problem returns after a cleanup
- you are not comfortable working with files, databases or logs
You do not need to identify the malware or the entry point yourself before asking for help.
What information should you collect?
Before opening a support request, collect whatever is easily available:
- the website URL
- screenshots of the symptoms
- when you first noticed the problem
- any messages from your hosting provider, Google or customers
- what you have already changed or tried, with approximate times
- whether you can access WordPress and the hosting panel
- the name of the hosting provider
- whether backups are available and from which dates
- whether the website handles orders, subscriptions or personal data
- whether other websites share the same hosting account
Do not worry if you cannot provide everything. Do not send passwords, private keys or complete logs in an unsecured message: D4Hub can tell you how to share access safely.
How D4Hub can help
The objective is not only to remove the visible signs of the hack. A complete response should contain the incident, remove the malicious content, close the entry point and reduce the risk of it happening again.
Depending on the situation, D4Hub can help with:
- assessing the symptoms and confirming whether the website is compromised
- preserving a copy of files, database and logs before cleanup
- reviewing users, files, database content and scheduled tasks
- coordinating with your hosting provider
- removing malicious code, spam pages, redirects and backdoors
- identifying the entry point, such as a vulnerable plugin or exposed credentials
- updating or replacing vulnerable components
- evaluating backups and planning a restore without losing recent data
- checking other websites on the same hosting account
- testing forms, login, checkout and other important functions
- supporting the Google Search Console review when needed
- recommending measures such as updates, backups and access controls to reduce future risk
You can ask for support at any stage: right after you notice something strange, after your hosting provider has run a scan, or after an initial cleanup attempt that did not fully work.
If any step in this guide feels unclear or risky, you do not need to perform it alone.
Open a support ticketFor hands-on users: a first technical review
The following checks are intended for people who are comfortable with SSH, SFTP, WP-CLI and hosting panels. They help collect evidence and identify suspicious areas, but they do not replace a complete security cleanup.
Before you start, make a full copy of the files and database and store it outside the website. Run read-only checks first and do not modify or delete anything until you have recorded what you found.
On a compromised website, plugins and themes may contain malicious code that runs whenever WordPress loads. When running WP-CLI commands, you can add --skip-plugins --skip-themes to avoid loading them.
List administrator accounts
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themesCompare the results with the people who should have administrator access. Note any unknown account and its registration date before taking action.
Verify the WordPress core files
wp core verify-checksums --skip-plugins --skip-themesThis compares the core files with the official checksums for your WordPress version. It reports modified files and files that should not be present in the core folders.
It does not check the wp-content folder, where plugins, themes and uploads are stored.
Verify plugin files
wp plugin verify-checksums --all --skip-plugins --skip-themesThis works for plugins published in the official WordPress.org directory. Premium and custom plugins cannot be verified this way and will be reported as such: this is not, by itself, a sign of infection.
Find recently modified files
From the root folder of the WordPress installation, list PHP files modified in the last 7 days:
find . -type f -name "*.php" -mtime -7Change the number to cover the period you suspect. Legitimate updates also modify files, so compare the results with known update dates. Attackers can also alter modification dates, so an old date does not prove a file is safe.
Look for PHP files in the uploads folder
The uploads folder normally contains images and documents, not PHP code:
find wp-content/uploads -type f -name "*.php"Any result deserves a closer look. A few plugins legitimately create PHP files there, often small protection files, so check the content and location before drawing conclusions.
Review scheduled tasks
wp cron event list --skip-plugins --skip-themesLook for events with unfamiliar names that do not match WordPress or the plugins you use.
Invalidate existing login sessions
After changing passwords, you can replace the security keys and salts in wp-config.php:
wp config shuffle-saltsThis logs out every user, including any attacker with an active session. Make sure you have a working administrator password before running it.
Store any logs or results you collect privately. They may contain IP addresses, usernames and other sensitive information, so do not publish them in forums or support threads.
D4Hub can perform or review these checks, interpret the results and decide on the next safe step with you.
FAQFrequently asked questions
It depends on what the hack is doing. If visitors are being redirected, shown malicious content or asked for payment details, restricting access temporarily may protect them.
Your hosting provider or a specialist can help you choose a method that limits harm without destroying evidence, for example a maintenance page or access restrictions rather than deleting the website.
A security plugin can help detect known malicious patterns and modified files. It may not find every backdoor, recognize custom code correctly or identify how the attacker got in.
It can be a useful tool during the investigation, but it should not be considered the entire response.
Changing passwords is an essential step, but it does not remove malicious files, injected database content or vulnerable plugins. An attacker who left a backdoor may still be able to get back in.
Passwords should be changed as part of a wider cleanup.
The most common entry points are outdated plugins or themes, weak or reused passwords, nulled software and old accounts that were never removed. Sometimes the cause is another website on the same hosting account.
Identifying the exact cause usually requires reviewing files, users and server logs, which is why preserving them before cleanup matters.
Yes, if the entry point is not closed. This is why a complete response includes updating or replacing vulnerable components, removing unused software, securing access and keeping regular, tested backups.
If personal data may have been exposed, you may have legal obligations to notify the supervisory authority and, in some cases, the people affected. Speak to your Data Protection Officer or legal advisor, who can assess the situation with the technical information collected.
Yes. Explain what you changed, restored or deleted and when. This information helps reconstruct the incident and decide on the next safe step.