How to tell if your WordPress website has been hacked

A hacked WordPress website does not always show an obvious warning. Some compromises redirect only selected visitors, create spam pages only for search engines, add hidden administrator access, or leave a backdoor that quietly survives the first cleanup.

How can you tell if WordPress has been hacked?

There is rarely one definitive symptom. The safest approach is to combine evidence from the public website, Google Search Console, WordPress users, files, database activity, scheduled tasks, hosting alerts, and server logs. A suspicious redirect or unknown administrator is a strong warning sign; a slow page or a single PHP error on its own is not.

The goal is not only to find something malicious. It is also to avoid treating an ordinary plugin, PHP, DNS, caching, or hosting problem as a security incident when the evidence does not support that conclusion.

Common signs of a hacked WordPress website

First separate a possible hack from an ordinary WordPress failure

A critical error, white screen, HTTP 500 response, broken checkout, or failed update can be urgent without being malicious. Those failures are commonly caused by incompatible plugins, theme code, PHP changes, exhausted resources, deployment mistakes, or server configuration.

Security becomes a stronger possibility when the technical failure appears alongside unauthorized changes: unfamiliar administrator users, modified files with no legitimate explanation, malicious redirects, unexpected indexed pages, malware warnings, phishing content, new scheduled jobs, suspicious outbound email, or changes that keep returning after removal.

If the website is simply down and you do not yet know why, start with the first-30-minutes WordPress emergency checklist before assuming compromise.

1. Check the website from outside WordPress

Test the site in a private browser window while logged out. Open several pages rather than only the homepage, and test from another device or network when practical. Conditional malware may behave differently for administrators, search visitors, mobile devices, particular countries, or first-time visitors.

Look for redirects to unrelated domains, fake browser-update pages, gambling or pharmaceutical content, unexpected popups, injected links, altered titles, unfamiliar downloads, or pages that appear only after arriving from a search engine.

A redirect that only affects certain visitors is particularly easy to miss. The WordPress redirect hack guide and cleanup service covers that symptom in more detail.

2. Check Google Search Console and your indexed pages

Search Console can expose problems that are invisible in wp-admin. Review Security Issues, Manual Actions, indexing reports, and unusual growth in indexed URLs. Then search Google for site:yourdomain.com and inspect titles and paths you do not recognize.

Thousands of fake product, casino, pharmaceutical, Japanese-language, or keyword-stuffed pages can be generated dynamically without existing as normal WordPress posts. If that pattern appears, see the guide to removing Japanese SEO spam from WordPress.

3. Review administrator accounts and access

In WordPress, check Users for administrators you did not create, unexpected email-address changes, or accounts that should no longer have privileged access. Do not assume that deleting one suspicious account closes the incident: the attacker may also have file, database, hosting, SFTP, SSH, API, or control-panel access.

Also review the hosting account and any other privileged systems connected to the website. A clean WordPress user list does not rule out stolen credentials elsewhere.

4. Look for unexpected file changes

Compare WordPress Core files with a trusted copy of the same version and review plugins and themes for files that do not belong there. Pay particular attention to recently modified PHP files when there is no legitimate deployment or update that explains the timestamp.

Areas worth checking include:

• wp-admin and wp-includes for modified or extra Core files.
• Plugin and theme directories for unexpected PHP, loader, or helper files.
• wp-content/uploads for executable PHP or similarly suspicious files where only media should normally exist.
• mu-plugins and drop-ins that load automatically and may be overlooked in the normal Plugins screen.
• wp-config.php, .htaccess, server configuration, and bootstrap files for unfamiliar includes or redirects.

A changed file is not automatically malicious: legitimate updates and customizations change files too. The important question is whether the change has a known source and whether its contents match the role that file is supposed to perform.

5. Check for persistence, not just visible malware

A backdoor is useful to an attacker precisely because it can remain after the obvious spam or redirect is removed. Persistence can exist in plugin or theme files, uploads, must-use plugins, the database, scheduled tasks, server configuration, hidden administrator users, or another compromised site sharing the same hosting account.

If a suspicious file returns after deletion, a redirect comes back after being fixed, or the site is reinfected days later, investigate what is recreating the change. The article why WordPress malware keeps coming back after cleanup explains the common persistence paths in more detail.

For cases where hidden PHP access is the main concern, see WordPress backdoor removal.

6. Review scheduled tasks, database changes, and background activity

Not every malicious action needs a visible file. Review WordPress cron events and other scheduled jobs for unfamiliar tasks, especially when deleted content keeps returning. On WooCommerce sites, also distinguish legitimate Scheduled Actions from entries that have no connection to installed plugins or expected workflows.

Database compromise can appear as injected JavaScript, spam options, altered site URLs, rogue users, malicious widgets, modified plugin settings, or payloads stored in content that execute later. Large or unfamiliar encoded values deserve context and investigation rather than blind deletion.

7. Check hosting alerts, logs, email, and resource usage

Hosting providers often see activity that WordPress itself cannot. Malware alerts, outbound spam, phishing complaints, unusual CPU usage, unexpected processes, repeated requests to suspicious PHP files, or account suspension can all provide useful evidence.

Review web-server and PHP logs around the time the problem started when they are available. Logs may reveal requests to a backdoor, repeated authentication attempts, a vulnerable endpoint, or the first appearance of a suspicious file. They can also show that the failure is ordinary application trouble rather than malicious activity.

Can a security scanner tell you for certain?

Security plugins and external scanners are useful evidence sources. They can identify known malware signatures, unexpected Core changes, suspicious files, blacklisting, and other anomalies quickly.

But a clean scan is not the same as proof that the website is clean. A scanner may not see server-level configuration, stolen credentials, a compromised neighboring site, database-only payloads, conditional behavior, recently created malware without a known signature, or a backdoor deliberately written to resemble legitimate code.

Use scanning as part of the investigation, not as the only pass/fail test.

What to do immediately if you suspect a hack

1. Preserve the current state. Take a copy of files and database before destructive cleanup so you do not erase useful evidence or the only copy of recent business data.
2. Record the symptoms. Save screenshots, suspicious URLs, redirects, unknown users, hosting warnings, timestamps, and relevant log entries.
3. Limit unnecessary changes. Randomly deleting files or deactivating everything can destroy evidence and make the original entry point harder to identify.
4. Protect credentials. Do not send passwords through ordinary contact forms or chat. Plan credential rotation for WordPress, hosting, database, SFTP/SSH, APIs, and other privileged systems as part of containment.
5. Consider business impact. On WooCommerce, booking, membership, or other transactional sites, avoid restoring an old database without understanding which legitimate orders, users, or transactions would be lost.

Should you restore a backup?

A known-good backup can be an important recovery tool, but restoration is not automatically a complete cleanup. If the original vulnerability, stolen credential, hidden backdoor, or compromised hosting account remains, the restored site can be infected again.

You also need confidence that the backup predates the compromise. An attacker may have been present before the visible symptom appeared. On stores and other frequently changing sites, database rollback can additionally discard legitimate activity that happened after the backup was taken.

Restoration is therefore best treated as one possible recovery step inside a broader investigation, not as proof that the cause has been removed.

What a proper WordPress malware cleanup should include

A credible cleanup should answer two questions: what was changed? and how could it come back? Removing the visible payload without addressing the second question leaves the site vulnerable to reinfection.

A thorough investigation commonly includes:

• preserving a safe recovery point before destructive work
• checking WordPress Core integrity
• reviewing plugins, themes, uploads, must-use plugins, and configuration files
• checking administrator users and other privileged access
• investigating database injections and scheduled persistence
• reviewing hosting or server evidence where available
• removing malicious files and unauthorized access paths
• updating or replacing vulnerable and abandoned components
• rotating relevant credentials after containment
• verifying the site again after cleanup rather than stopping when the visible symptom disappears

Specific symptoms may need a more focused investigation

• Visitors are redirected: see WordPress redirect hack removal.
• Spam pages appear in Google: see Japanese SEO spam cleanup.
• Malware returns after cleanup: see why WordPress malware keeps coming back.
• Hidden PHP access or recurring backdoors: see WordPress backdoor removal.
• The site is down but compromise is not established: start with WordPress emergency support rather than assuming every outage is malware.

Frequently asked questions

The main rule: diagnose before declaring the site clean

The absence of an obvious redirect or scanner warning does not prove that every access path has been closed. At the same time, a broken WordPress site is not automatically a hacked WordPress site. Good incident handling starts by gathering evidence, narrowing the failure, and making changes that preserve the ability to understand what happened.