Is My WordPress Site Hacked? Diagnostic Checklist

If your site is throwing sudden errors, redirecting visitors, flagged by Google, or has a login you don't recognize, treat it as hacked until you rule each sign out below — this checklist tells you exactly where to look and which symptoms are near-certain versus just a false alarm.

This is for WordPress owners — store owners, bloggers, agencies managing client sites — who noticed something off and want a fast, concrete way to check for compromise, not a 40-page guide. You'll get a scannable checklist, the exact place to check each symptom, and what to do the moment you confirm one. If you'd rather have a person look instead of second-guessing your own site, the free website security check gives you a straight yes/no on critical bugs with no card and no login.

The 60-second checklist

Run down this table first. "Critical" means stop and act now; "worth checking" means it's a common false-alarm trigger too, so verify before you panic.

Sudden 500/502/503 errors — don't assume the worst yet

A wave of server errors is the symptom most likely to have an innocent cause: an auto-update conflict, a PHP memory limit, or an expired SSL cert can all produce a 500. Before treating it as a hack, check wp-content/debug.log or your host's error log (cPanel → Metrics → Errors, or your hosting dashboard's log viewer).

What separates a bug from a break-in:

• Plugin/config error — the log names a real file inside a known plugin folder, e.g. "Allowed memory size exhausted in .../woocommerce/includes/...". Ordinary bug.
• Compromise — the log references a file you don't recognize, especially inside wp-content/uploads/ (which should never contain executable PHP) or a random string like wp-content/plugins/wp-tmp-cache/x942.php.

If you have WP-CLI access, compare your files against official checksums:

wp core verify-checksums
wp plugin verify-checksums --all

Any "file doesn't match" result on a file you didn't edit is a strong signal — that's exactly the check a manual audit runs by hand, cross-referenced against what the plugin should contain rather than just a checksum mismatch.

Google Safe Browsing and search warnings

Google, Chrome, Firefox, and Safari all share data from Google Safe Browsing, which scans public sites for malware and phishing code and warns visitors before they land on a flagged page. If your own browser (in incognito, with no cached override) shows a red warning screen, or a customer reports seeing one, your site is very likely serving malicious code right now — not just a possibility.

To check without waiting for a customer complaint:

1. Go to the Safe Browsing site status page and enter your domain.
2. Check Google Search Console → Security Issues — Google lists exactly which pages it flagged and why (e.g. "hacked with spam content" vs "malware").
3. Search site:yourdomain.com in Google and look for page titles you never wrote (Japanese/Russian spam-keyword titles are a classic signature of a hacked WordPress site).

Unauthorized admin accounts and logins

This is the single clearest sign on this list — WordPress doesn't create Administrator accounts on its own, ever.

• In Users → All Users, sort by role and check every Administrator by name, email, and registration date.
• Via WP-CLI: wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
• If you're locked out or don't trust the dashboard, check the wp_users table directly in phpMyAdmin — look for accounts with a user_registered date you don't recognize.

A single account you didn't create is enough to confirm compromise on its own, since it means someone already has standing access to your site.

Unfamiliar or duplicated cron jobs

WordPress runs its own pseudo-cron (wp-cron.php) separately from any real server crontab, and attackers use both to keep a backdoor alive after you think you've cleaned up.

• List WordPress's own scheduled events: wp cron event list --fields=hook,next_run,schedule. A hook name that isn't tied to any plugin you installed (random class-style names, not woocommerce_cleanup_sessions-style ones) is worth investigating.
• Check the real server crontab via SSH (crontab -l) or your host's Cron Jobs panel. Anything that pipes to curl, wget, or php -r with a base64-looking string as the argument is a red flag, not a maintenance task.

Unexpected outbound traffic

A hacked site often "phones home" — sending spam email, connecting to a command-and-control server, or joining a botnet — which shows up as outbound traffic you didn't generate.

• Compare your hosting bandwidth graph against your actual visitor count in analytics; a spike in outbound data with flat visitor traffic is the tell, not a spike in both.
• On a VPS with shell access, ss -tnp or netstat -tnp lists active outbound connections; match the process ID back to a PHP worker connecting to an IP address that has nothing to do with your site's normal services (payment gateway, CDN, email provider).
• If your host's abuse team emails you about outbound spam volume or a blocked IP, that's third-party confirmation, not a guess.

What to do the moment you confirm a sign

1. Change every password — WordPress admin, hosting account, FTP/SFTP, and the database user — from a device you trust, before doing anything else.
2. Put the site in maintenance mode or take it offline temporarily if it's actively redirecting visitors or serving malware.
3. Don't just delete the suspicious file and call it fixed. A single backdoor is rarely the only one; CISA's guidance on web shell malware notes that attackers commonly leave multiple redundant footholds once they've gained access.
4. Restore from a backup that predates the first symptom, if you have one, then patch whatever let the attacker in before putting it back online.
5. Get a second set of eyes. Automated scanners are good at catching known signatures but miss custom-coded backdoors and logic-based abuse; that gap is exactly why manual review finds things automated scans don't.

If you're still not sure after running through this list, our guide to telling whether a website is hackable in the first place covers the underlying weaknesses (outdated plugins, weak passwords, missing headers) worth checking regardless of whether you've been breached yet.

Key takeaways

• A Google Safe Browsing warning or an admin account you didn't create is confirmation on its own — act immediately, don't wait for a second sign.
• Sudden 500/502/503 errors are the most commonly misread symptom; check the error log for unfamiliar filenames before assuming a hack.
• Check both WordPress's own cron (wp cron event list) and the real server crontab (crontab -l) — attackers use both to persist.
• Outbound traffic spikes without matching visitor spikes are a stronger signal than raw bandwidth numbers alone.
• Deleting one suspicious file isn't a fix — confirm the full extent before declaring the site clean.

If you've ticked even one "Critical" box above, the honest next step is a human looking at the actual code, not another automated scan. Circuit is a $49 one-time manual audit — a real person reviews your site and hands you a written report of every issue found, with severity and the exact fix, so you know precisely what an attacker did and what to close. There's no pressure to buy anything if the free check comes back clean.