How to check if your website is hacked
Updated 2026-10-16 · 9 min read · by the IsHacked team
Most hacked sites look perfectly normal to their owners. Attackers make money only while the infection stays unnoticed, so modern malware hides from logged-in admins, shows spam only to search engines and redirects only some visitors. These twelve tests check the site the way attackers don't expect you to.
Check your site in one click The free check runs most of the tests below automatically.
1. Compare what Googlebot sees with what you see
SEO spam hacks cloak: they serve casino, pharma or Japanese spam only when the visitor claims to be Googlebot. Request the homepage twice and compare the titles and outbound links.
curl -s https://example.com/ | grep -i '<title'
curl -s -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://example.com/ | grep -i '<title'Different titles, extra links or foreign-language text in the second response mean the site is cloaking. Read more in SEO spam and cloaking.
2. Visit as a phone arriving from Google
Redirect malware usually fires only for mobile visitors who come from a search engine, often once per visitor. You will never see it by typing the address into your desktop browser.
curl -sI -A 'Mozilla/5.0 (Linux; Android 14) Mobile' -e 'https://www.google.com/' https://example.com/A 301 or 302 to an unrelated domain is a hack. See the WordPress redirect hack.
3. Search Google for your own site
Search site:example.com and scan the titles. Pages you never wrote, Japanese titles, or words like casino, slot and viagra are spam pages that Google has already indexed. Add a keyword to narrow it down: site:example.com casino.
4. Open the sitemap and robots.txt
Hacks add their spam URLs to the sitemap so Google finds them faster, or add a Sitemap: line pointing to the attacker's own domain. Check /robots.txt, /sitemap.xml and, on WordPress, /wp-sitemap.xml. A sitemap that suddenly lists thousands of URLs, or URLs on other domains, is a red flag.
5. Check Google Search Console
Look at Security & Manual actions and at Settings → Users and permissions. The Japanese keyword hack often verifies the attacker as an owner of your Search Console property so they can submit their own sitemaps. Remove any owner you don't recognise.
6. Read the page source for injected scripts
View the source and search for <script. Be suspicious of scripts from domains you don't use, and of obfuscation patterns such as eval(atob(, long String.fromCharCode(…) lists, document.write(unescape( or long strings of \x escapes. A script loaded from a .php file inside wp-content/plugins or wp-content/themes is a classic loader: we found exactly that in a recent cleanup, where a fake plugin served a pop-under ad script.
7. List the WordPress users
Attackers create administrator accounts to get back in. Check Users in wp-admin, and from outside, /wp-json/wp/v2/users (if your site exposes it). Names like adminbackup, wp-admin2 or random strings deserve a closer look.
8. Look for files that should never be public
Database dumps and config backups left in the web root are both a sign of past compromise and an open door. Try /wp-config.php.bak, /wp-config.php.save, /wp-content/mysql.sql, /.env, /.git/HEAD and /wp-content/debug.log. Each should return 403 or 404.
9. Watch for a blank or replaced homepage
In one recent cleanup, malware dropped a 115-byte index.html into the web root. The server preferred it over WordPress's index.php, so the homepage went blank while every inner page still worked. If /index.html answers on a WordPress site, find out why.
10. Check browser and blocklist warnings
Look the site up in Google's Safe Browsing status, and the domain in Spamhaus's blocklists. A hacked site that sends spam gets its domain or server IP listed, and its legitimate email starts bouncing.
11. Read the error log and hosting alerts
Bursts of requests to xmlrpc.php, uploads of .php files through a form plugin, or PHP errors from files you don't recognise all appear in the server logs before the damage is visible.
12. Compare core files with the official checksums
On the server, wp core verify-checksums and wp plugin verify-checksums --all list every modified or extra file in WordPress core and in plugins from wordpress.org. This is the strongest single test, but it needs server access.
What an outside check can't see
A backdoor that waits silently for its owner's password shows nothing to the public. In one recent cleanup, a well-known external scanner reported a site clean while it carried 46 web shells. External monitoring catches what visitors and Google see, quickly; server-side scanning confirms a site is clean. Use both.
If the site is hacked
Don't just delete the visible spam: the attacker will be back within hours through the backdoor. Work through the hacked WordPress cleanup checklist, then keep a daily watch on the site so a reinfection is caught the same day.
FAQ
Can a website be hacked without me noticing?
Yes, and that is the norm. Most infections hide from logged-in administrators and from the site owner: spam is shown only to Googlebot, redirects fire only for phone visitors arriving from Google, and backdoors print nothing at all.
Is an online scanner enough to know my site is clean?
No. External scanners see what the public sees. A backdoor that does nothing visible stays invisible from outside. Use an external check to catch symptoms early, and a server-side scan of files and the database to confirm the site is clean.
How often should I check?
At least daily for sites that matter. Spam campaigns can index thousands of pages in a few days, and the longer an infection runs, the longer the search ranking takes to recover.