WordPress Website Hacked? What UK Businesses Should Do Next

WordPress website hacked? Act quickly, but do not start deleting files or restoring random backups. A compromise can expose customer information, redirect potential buyers to scam sites, send spam from your domain, disrupt online payments or cause Google and browsers to warn people away.

The first priority is not to make the site look normal again. It is to stop further damage, preserve enough evidence to understand what happened, remove every route the attacker can still use and only then return the website to normal service.

This guide explains that sequence in plain English for UK small-business owners. It covers the warning signs, the immediate decisions, the clean-up process, the possible data-protection implications and the work needed to restore trust and search visibility.

WordPress website hacked? Follow these 7 urgent steps

If you need the immediate answer, use this order:

1. Contain the incident. Restrict access or disable affected functions so visitors and customer data are not exposed.
2. Preserve evidence. Record symptoms, save relevant logs and take a labelled snapshot of the files and database before cleaning.
3. Contact your host and connected providers. Ask about suspicious activity, server logs, quarantine options and clean backups.
4. Secure every access route. Rotate WordPress, hosting, SFTP, email, domain and integration credentials, then invalidate active sessions.
5. Find and remove the compromise. Check core files, plugins, themes, uploads, database records, users, cron jobs and server rules against trusted sources.
6. Patch, test and assess data risk. Close the entry point, test key customer journeys and decide whether the incident may be a reportable personal data breach.
7. Restore search trust and monitor. Review Search Console security warnings and hacked URLs, request a review where available and watch closely for reinfection.

Do not treat one clean scanner result as proof that recovery is complete. The root cause, hidden persistence and connected accounts also need to be checked.

How can you tell whether a WordPress website has been hacked?

One strange page or failed login does not prove a website has been compromised. A plugin conflict, expired SSL certificate, broken DNS record or hosting outage can produce alarming symptoms too. However, several signs should be investigated immediately.

• Your website redirects visitors to gambling, adult, pharmacy, investment or imitation login pages.
• Google results show unfamiliar Japanese characters, pharmaceutical pages or spam titles under your domain.
• A browser or security product displays a malware, phishing or deceptive-site warning.
• Your hosting company suspends the account or reports malicious files.
• Unknown administrator accounts appear in WordPress.
• Pages, links, pop-ups or adverts appear that nobody on your team added.
• You cannot sign in even after using the normal password-reset process.
• Search Console reports hacked content, harmful downloads or a security issue.
• Customers report unexpected emails, payment problems or unusual redirects.
• Server use, outgoing email or traffic rises sharply without a business reason.

The official WordPress hacked-site guidance describes these as indicators of compromise. Record each symptom, when it was first noticed and who observed it. That timeline will help your developer, host or security specialist distinguish the visible effect from the original point of entry.

What should you do first if your WordPress site is hacked?

Begin with four immediate actions: stop uncontrolled changes, contain the risk, preserve a snapshot and contact the organisations that control the surrounding systems. The order matters. Simply deleting the most obvious spam file may remove a symptom while leaving an administrator account, scheduled task or hidden backdoor in place.

1. Stop making unplanned changes

Do not start deleting plugins, restoring random backups or installing several security tools at once. Every change makes the original incident harder to reconstruct and can destroy useful evidence.

Write down what you can see. Take screenshots of warnings and redirects. Note the time and timezone. Record recent plugin installations, updates, new users, hosting changes and emails from your host or Google. Save relevant server, firewall and activity logs before their retention period expires.

2. Contain the risk without destroying the evidence

If the site is actively harming visitors, it may need to be placed behind a temporary maintenance page, restricted at server level or taken offline. Ask the host to help if you do not know how to do this safely. An ecommerce website accepting payments needs particularly careful handling: disabling checkout may be more urgent than keeping every product page available.

A maintenance-mode plugin inside the already compromised WordPress installation is not always enough. An attacker may have bypassed WordPress or altered server rules. Containment at hosting, firewall or proxy level can be more reliable.

Do not leave a hacked site publicly accessible merely to avoid downtime. A short controlled interruption is normally less damaging than sending customers to malicious content or collecting information through an untrusted form.

3. Make a complete snapshot of the compromised site

Back up both the files and database before cleaning, even though the copy is infected. Label it clearly and store it away from live hosting. This snapshot can preserve logs, timestamps, unfamiliar accounts and malicious files that help identify how the breach happened.

Do not later use that snapshot as a clean restore point. Its purpose is evidence and recovery reference. A separate backup from before the compromise may become the basis of a rebuild, but only after its date and integrity have been checked.

4. Contact the organisations that control the surrounding systems

Tell your hosting provider what you have found. Ask whether they detected suspicious activity, suspended any services, retain access logs or can provide a clean server snapshot. If the website uses a separate payment processor, email provider, domain registrar, CDN or firewall, check those accounts too.

A WordPress incident is not always confined to WordPress. A stolen hosting password, compromised email inbox or exposed API key can allow an attacker back in after the visible malware is removed.

Which passwords and access details need changing?

Changing only the main WordPress password is rarely sufficient. An attacker may still have an active session or access through another account.

Review and rotate credentials for:

• every WordPress administrator and editor;
• hosting and server control panels;
• SFTP or SSH accounts;
• the database user, where appropriate;
• domain registrar and DNS accounts;
• business email accounts used for password resets;
• CDN, firewall and backup services;
• payment, form, CRM and email-marketing integrations;
• WordPress application passwords and API keys.

Use new, unique passwords created by a password manager. Enable multi-factor authentication wherever it is available. WordPress security keys and salts should also be rotated so that existing logged-in sessions are invalidated.

Scan the computers used to administer the website. If a laptop contains credential-stealing malware, changing passwords from that device can hand the new details straight back to the attacker.

How a hacked WordPress website should be investigated

A thorough investigation looks at the whole installation, not just the file named in the first scanner alert.

Check users and privileges

Review all WordPress accounts, especially administrators. Look for unfamiliar names, recently changed email addresses and legitimate accounts with more access than they need. Also check hosting, SFTP and database users. Remove unknown access only after it has been documented.

Compare files with trusted originals

WordPress core files can be compared with the official release. Plugin and theme files should be checked against fresh copies from their legitimate publishers. Modified core files, executable files in upload folders, unfamiliar PHP files and recently changed server configuration deserve attention.

Do not assume that reinstalling WordPress core removes the infection. Malware may sit in wp-content, the database, a must-use plugin, a server-level configuration file or another website sharing the same hosting account.

Inspect the database

Attackers may inject spam links, scripts, rogue administrator accounts, altered site URLs or scheduled actions into the database. Search content and options for suspicious scripts, encoded payloads and unfamiliar domains. Ecommerce sites also need their orders, customer records and payment-related settings checked carefully.

Review plugins, themes and the original entry point

List every active and inactive extension, its version and its source. Remove abandoned or unnecessary software. Update supported components after compatibility checks. Pirated or “nulled” themes and plugins should never be trusted.

Recent vulnerabilities matter. For example, Core Web UK has separately reported on an Elementor Pro vulnerability being actively exploited. Updating a vulnerable component closes that specific weakness, but it does not prove that a site already exposed to attack is clean.

Check logs, cron jobs and persistence

Attackers often create more than one way back in. Review server access logs, WordPress activity, scheduled tasks, must-use plugins, configuration files and unexpected changes to .htaccess or equivalent server rules. A backdoor can recreate deleted malware hours or days later.

This is why a “scanner says clean” result is useful evidence, not a complete guarantee. Different scanners see different layers, and some malicious code activates only for particular visitors, referrers or search-engine crawlers.

Should you restore a backup or clean the live website?

A clean backup can be the fastest route back, but only when you know it predates the compromise. The date when symptoms first appeared may be later than the date of entry. Restoring yesterday’s backup can therefore restore yesterday’s hidden backdoor.

Before relying on a backup, ask:

• When was it created?
• Was it stored separately from the compromised hosting account?
• Does it include both files and the database?
• Has it ever been test-restored?
• What legitimate orders, enquiries or content would be lost?
• Was the vulnerable plugin, stolen credential or other entry route already present?

For a simple brochure site, rebuilding from trusted WordPress, theme and plugin packages and carefully transferring verified content may be safer than cleaning an uncertain installation. For a busy WooCommerce store, a blunt restore may erase recent orders, stock changes and customer records. The recovery plan must protect both security and business data.

What about customer data and UK breach reporting?

A website hack and a personal data breach are related but not identical. You need to establish whether personal data was accessed, altered, lost or disclosed. Relevant information might include contact-form submissions, customer accounts, order details, IP addresses, staff data or credentials.

Keep a decision record even if you conclude that notification is not required. The Information Commissioner’s Office guidance explains when an organisation must report a personal data breach and when affected people may also need to be informed. If a risk to people’s rights and freedoms is likely, the ICO says it must be notified as soon as possible and, where feasible, within 72 hours of awareness. If the risk is high, affected people must also be told without undue delay. Take qualified data-protection or legal advice where the facts are uncertain, and do not wait for the technical clean-up to finish before starting the assessment.

If payment card information might be involved, contact the payment provider or acquiring bank promptly and follow its incident process. Avoid telling customers that “no data was affected” until the investigation supports that statement.

How to remove malware without breaking the website

The exact clean-up depends on the compromise, but a controlled process generally includes the following work:

1. Work on a protected copy or staging environment where possible.
2. Replace WordPress core files with verified official copies.
3. Replace affected plugins and themes with clean packages from trusted sources.
4. Remove malicious files, database injections, rogue users and persistence mechanisms.
5. Patch or remove the vulnerable component that allowed entry.
6. Rotate passwords, sessions, salts, keys and integration secrets.
7. Check neighbouring sites and accounts on the same hosting package.
8. Run more than one appropriate scan and manually review high-risk areas.
9. Test forms, logins, checkout, emails, redirects and scheduled tasks.
10. Monitor the cleaned site for unexpected file, user and traffic changes.

Avoid bulk-deleting unfamiliar files from the live server. Legitimate plugins often contain minified or encoded code, while sophisticated malware can use ordinary-looking filenames. A false positive can take the website down; a missed backdoor can cause reinfection.

If the problem turns out to be a technical failure rather than a compromise, the diagnostic steps in our guide to a website that is not working can help distinguish hosting, DNS, plugin, caching and application faults.

How do you remove Google security warnings and spam results?

Cleaning the website is the first step. Google and browser warnings do not always disappear immediately afterwards.

Open Google Search Console and check the Security Issues report, Manual Actions report and URL inspection data. Confirm that hacked pages, injected sitemaps and spam URLs are no longer being generated. Remove malicious internal links and redirects. Make sure legitimate pages return the correct status codes and that no emergency blocking rule is still preventing Google from crawling the clean site.

If Search Console offers a security review request, submit it only after the whole site has been cleaned and the vulnerability has been addressed. Explain what was found, what was removed and what was changed to prevent recurrence. Repeatedly requesting a review before the problem is fixed can slow the process.

Spam URLs may remain visible for a while as Google recrawls them. They should normally return an appropriate 404 or 410 response unless there is a genuine equivalent page to redirect to. Do not redirect thousands of hacked URLs to the homepage; that hides neither the incident nor the poor user experience.

After recovery, review impressions, indexed pages, crawl behaviour and queries. A focused technical SEO audit can uncover hacked URLs, broken canonicals, injected structured data and indexation problems that are easy to miss during an emergency clean-up.

When is a hacked site genuinely safe to reopen?

There is no single green light, but the evidence should support all of these points:

• The malicious behaviour has stopped across different devices and networks.
• Files and database content have been checked against trusted sources.
• Unknown accounts, sessions, keys and scheduled tasks have been removed.
• The original entry point has been patched, removed or otherwise controlled.
• Administrator devices and connected accounts have been checked.
• Forms, emails, checkout and customer journeys work correctly.
• Fresh scans and manual checks find no remaining indicators.
• Logging and monitoring are active for the period after recovery.
• Any data-protection, payment-provider or customer communications have been addressed.

Continue monitoring after the site returns. Watch file changes, new users, outgoing email, server resources, redirects and Search Console. Reinfection shortly after a clean-up usually means the original access route or a persistence mechanism was missed.

How to reduce the risk of another WordPress hack

No website can be promised perfect security. The practical goal is to reduce the likelihood of compromise, limit the damage if one occurs and make recovery faster.

The official WordPress hardening guidance recommends layered controls rather than one magic plugin. For a small-business site, the most valuable routine measures include:

• keeping WordPress, plugins, themes and supported PHP versions current;
• removing unused themes, plugins and accounts;
• using unique passwords and multi-factor authentication;
• giving each user only the access they need;
• taking automatic off-site backups and testing restores;
• monitoring uptime, files, security alerts and server logs;
• using secure hosting, HTTPS and SFTP;
• protecting administrator email and domain accounts;
• testing updates on staging when the website is business-critical;
• maintaining a written incident and recovery plan.

Security updates should be prompt, but blind updates on a live WooCommerce or booking website can create another kind of outage. Good maintenance combines backups, compatibility checks, controlled deployment and post-update testing. Our website maintenance and support service is designed around that ongoing work.

When should you call a WordPress security specialist?

Get experienced help promptly if the site redirects visitors, distributes malware, affects checkout, exposes personal data, has been suspended by the host or keeps becoming infected after a clean-up. Professional investigation is also sensible when you cannot access the server, do not have a verified backup or cannot confidently identify the original entry point.

Before granting access, ask who will carry out the work, what will be backed up, how the infection and root cause will be checked, whether the database and connected accounts are included, how testing will be documented and what monitoring follows the repair. Be cautious of anyone who promises that installing one plugin or deleting one flagged file guarantees a clean website.

For an urgent business site, the useful first outcome is a clear diagnosis: what is happening, what must be contained now, what evidence should be preserved and whether the website can remain partly available while recovery proceeds.

Frequently asked questions

Can a hacked WordPress website be fully recovered?

Often, yes. Recovery depends on the severity of the compromise, the quality of available backups and whether the original access route can be identified and closed. A clean appearance alone does not prove recovery; files, database, accounts, integrations and connected systems all need checking.

Will changing my WordPress password remove the hacker?

No. It may stop one login route, but it does not remove malware, unknown users, active sessions, stolen hosting credentials or server-level backdoors. All relevant credentials and sessions need reviewing as part of a wider clean-up.

Can I just restore yesterday’s backup?

Only if there is good reason to believe the backup is clean and you understand what newer data will be lost. Attackers can remain hidden before symptoms appear, so the newest backup is not automatically the safest.

Why does my site keep getting hacked again?

Common causes include a vulnerable plugin that remains installed, a missed backdoor, stolen credentials, another infected site on the same hosting account or an insecure administrator device. Repeated infection means the root cause or a persistence route has probably not been removed.

How long does WordPress malware removal take?

It depends on the size of the site, the type of infection, server access, backup quality and whether ecommerce or customer data is involved. A visible redirect may be quick to suppress, while full investigation, clean-up, testing and search-warning review can take considerably longer.

Does a security plugin guarantee that my site is clean?

No. Security plugins are useful for scanning, logging, firewall protection and alerts, but no single tool sees every layer. A proper recovery combines automated scans with manual checks, trusted file comparisons, access review and monitoring.

Should I tell my customers?

That depends on what happened and the risk to individuals. If personal data may have been compromised, assess the incident promptly against ICO guidance and obtain professional advice when needed. Customer communications should be accurate, timely and based on evidence.

Get the site stable, then fix the cause

A hacked WordPress website is an operational problem, a trust problem and sometimes a data-protection problem. The strongest response is calm and methodical: contain it, preserve evidence, secure every access route, clean from trusted sources, test properly and monitor what happens next.

If your website is redirecting, blacklisted, suspended by the host or showing unfamiliar content, Core Web UK can investigate the fault and explain the safest next step. The priority is to restore a dependable website without overlooking the route that caused the incident.