Security Guides
How to check if your website or server was hacked: step-by-step checks for shared hosting, WordPress and a VPS, and what to do first if you find something
How to check your own website or server for intrusion, by environment: shared hosting, WordPress, a Linux VPS and Google Search Console. Admin users, wp core verify-checksums, login history, authorized_keys, cron and listening ports, plus the order to respond in if you find something.
For: individuals and small businesses running a site on shared hosting, WordPress or a VPS who are now wondering "have I been hacked?". This guide walks through checking your own site and server yourself. It draws on official documentation from WordPress.org, WP-CLI, Google Search Central, the manual pages of each command, Japan's IPA and JPCERT/CC, and the GDPR. Attack techniques are not covered.
If something looks wrong right now, do just this
Before you delete or overwrite any site files, make a copy of the logs and the whole site (files and database). Once they're gone, you can no longer work out how the attacker got in. Change passwords from a different, clean device that you have scanned with antivirus software.
Signs that should make you suspect an intrusion
If any of these apply, go on to the checks by environment below. WordPress.org's "FAQ My site was hacked" also lists clear signs of a hack, including being blocklisted by search engines, your host disabling the site, and unauthorized behavior such as new users being created.
| Sign | Where you notice it |
|---|---|
| Search Console shows a security issue, or Google emails you | Google Search Console |
| Search results show "This site may be hacked" | Google Search |
| Browsers warn that the site is dangerous, or visitors' antivirus flags it | Messages from visitors |
| Your host warns about defacement, spam or excess load, or suspends the site | Email from your host |
| Admin users you never created | WordPress dashboard |
| Pages you never created (pharma, brand goods, mass Japanese-language pages) appear in search | A site: search |
| Redirects to another site only on a phone, or only when arriving from search | Checking on a phone |
| Your server is sending spam, or hits the sending limit | Host notices, bounced mail |
| CPU or traffic jumps for no reason | Your server's monitoring |
"It looks fine on my computer" proves nothing
Google (web.dev) explains that some hacked sites show different content to different types of users (cloaking): a page can look empty when you open it, while Google sees spammy words and links on it. A Google Search Central blog post also notes that a hacked site may redirect only mobile users to spammy domains, and recommends opening your site from Google search results on a smartphone to check.
Checks by environment
Check the rows that match your setup. If you run WordPress on shared hosting, both of the first two rows apply.
| Environment | Where to look | What to look for |
|---|---|---|
| Shared hosting | Access and error logs in the control panel, the file manager, mail sending history | Requests to unfamiliar URLs or floods of POSTs, recently modified files, unfamiliar .htaccess or PHP files, a jump in outgoing mail |
| WordPress | All Users and Installed Plugins in the dashboard, WP-CLI | Unknown administrators, plugins or themes you didn't install, modified core files |
| VPS (Linux) | SSH logs, authorized_keys, cron, the user list, listening ports, package verification | Logins from unknown sources, unknown public keys, unknown scheduled jobs, new users, unknown programs listening |
| Google Search Console | Security issues, the URL Inspection tool, a site: search | Problems and sample URLs Google found, and what Google sees on a page |
Shared hosting
Even without SSH, the control panel usually lets you check these three things (the names differ by host).
- Open the public folder in the file manager and sort by modification date. Watch for files changed on days you didn't touch them, PHP files with meaningless names, and PHP files inside image folders such as
uploads - Download the access and error logs and check where admin-area requests came from and when (on WordPress,
/wp-login.phpand/wp-admin/), and any requests to URLs you don't recognise - If you can see mail sending counts or history, look for large volumes you didn't send
Check .htaccess too. WordPress.org names .htaccess as one of the files most often modified and abused regardless of the type of infection, and notes that index.php, header.php and footer.php are high-value targets because they affect every page request.
WordPress
In the dashboard, check two places.
- Users > All Users: is there anyone with the Administrator role you didn't create?
- Plugins > Installed Plugins: is there any plugin you didn't install? Check Appearance > Themes the same way
If WP-CLI (the official command-line tool for WordPress) is available on the server, you can check files against the official release automatically.
# Check WordPress core files against WordPress.org checksums
wp core verify-checksums
# Also warn about non-WordPress files in the WordPress root directory
wp core verify-checksums --include-root
# Verify plugins distributed on WordPress.org
wp plugin verify-checksums --all
# List administrator accounts with their registration dates
wp user list --role=administratorA clean result prints Success: WordPress installation verifies against checksums. A mismatched file prints Warning: File doesn't verify against checksum: followed by its name. Plugin verification compares against WordPress.org checksums, so premium plugins and custom themes can't be checked this way. For those, download the same version from the vendor again and compare.
VPS (Linux)
On a VPS, look for things an intruder leaves behind to get back in: public keys, scheduled jobs, new users and programs listening for connections. Run all of these on your own server, as an administrator.
# SSH login records (the unit is ssh on Debian/Ubuntu, sshd on RHEL-family)
sudo journalctl -u ssh --since "2026-10-01"
# Recent logins (on Debian 13, use wtmpdb last instead; install the wtmpdb and libpam-wtmpdb packages)
last -a
# Each user's last login (on Debian 13, use lastlog2 instead; install the lastlog2 and libpam-lastlog2 packages)
lastlog
# SSH public keys: the current user's (other users: /home/*/.ssh/authorized_keys) and root's
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# Scheduled jobs (per user and system-wide)
crontab -l
sudo crontab -l -u root
sudo cat /etc/crontab
sudo ls -la /etc/cron.d
# Users, and the group with admin rights (wheel on RHEL-family)
getent passwd
getent group sudo
# Listening TCP ports and the programs behind them
sudo ss -tlnp
# Files in the web root whose contents changed in the last 7 days
sudo find /var/www -type f -mtime -7
# Have package files changed since they were installed?
sudo debsums -s # Debian/Ubuntu (needs the debsums package)
sudo rpm -Va # RHEL-familyHow to read the results:
- In the
journalctloutput, check the source IP of successful logins (Accepted) for addresses that aren't yours. If nothing shows up, the unit name may differ; check the SSH service name withsystemctl list-units --type=service - In
authorized_keys, look for public keys you never added. Managing the keys that can reach a server is covered in SSH key least privilege - In cron, look for lines that download and run something from an unknown URL
- In the
sslist, look for programs listening that you didn't start debsums -sreports only problem files;rpm -Vamarks changed files with codes such as size (S), digest (5) and modification time (T)
Don't lean too hard on logs and command output
find -mtime looks at a file's modification time, which can be changed. The debsums manual itself says the tool is of limited use as a security tool. Logs disappear when their retention period ends. And on Debian 13, last, lastb and lastlog are no longer provided because of the year-2038 problem. Every check can give you evidence of an intrusion, but finding nothing does not prove you are clean.
Google Search Console
If your site isn't registered in Search Console yet, add it and verify ownership first.
- In the Security issues report, see whether any problem is listed. Issues fall into three broad categories: Hacked content, Malware and unwanted software, and Social engineering, usually with sample URLs. Some issues come with no sample URLs; Google says this does not mean no pages are affected
- Search Google for
site:yourdomainand look for pages you never made. Google says this lists the pages of your site, including any a hacker may have added - Put suspicious pages into the URL Inspection tool to see how Google sees them
For terminology: traces of a compromise that has already happened, like the ones above, are called IOCs (indicators of compromise). See what is an IOC, and for spotting an attack by its behavior while it is still under way, what is an IOA.
What to do first if you find something
Get the order wrong and you either destroy the evidence or restore the site with the attacker's entry point still open. Work from the top.
1 — Contain
Take the site offline or put up a maintenance page
2 — Preserve evidence
Copy logs, files and the database off the server
3 — Rotate every credential
Dashboard, FTP, SSH keys, database, API keys (from a clean device)
4 — Get back to a clean state
Restore a pre-intrusion backup, or rebuild
5 — Close the entry point
Update, remove unused plugins, find the cause
6 — Review and report
Request a Search Console review; report a data leak if required
Contain: take the site offline for now
So visitors aren't served malware or scam pages, take the site offline or show a maintenance page. On a VPS, restrict outside traffic while keeping the access you need to investigate. On shared hosting, contact your host's support to agree how to take it down and what they will do on their side. WordPress.org also advises checking with your host, because on shared hosting the hack may affect more than just your site.
Preserve evidence: copy before you clean
WordPress.org recommends taking one more snapshot of the environment before you start cleaning, even if it's infected. Google likewise advises backing up the whole site and database to a location off the server before cleaning. Access, error and SSH logs disappear on a schedule, so save them first. The approach in backup essentials applies directly.
Rotate every credential, from a clean device
WordPress.org asks you to change the passwords for every access point — FTP/SFTP, the WordPress dashboard, your hosting control panel and MySQL — and to include every user with access to the environment, not just yourself. Regenerating the secret keys (salts) in wp-config.php also logs out anyone still signed in. On a VPS, generate new SSH keys and leave only yours in authorized_keys. Reissue any third-party API keys stored in files such as .env.
WordPress.org notes that attacks often start on the owner's own computer, and recommends scanning it too. Make the changes from a clean device that you have scanned, and turn on multi-factor authentication.
Get back to a clean state: a pre-intrusion backup, or a rebuild
If you have a backup you know predates the intrusion, restore from it. If you don't know when the attacker got in, the newer the backup, the more likely it is dirty. On WordPress, replace wp-admin and wp-includes with the same version from the official download, and fetch themes and plugins in wp-content from their sources again. On a VPS where root may have been compromised, building a fresh server and moving only checked data across is more reliable than cleaning.
Close the entry point so they can't come back the same way
Update WordPress core, plugins and themes, and delete anything you don't use. Common causes are vulnerabilities in outdated plugins, reused passwords and configuration files leaked from public folders. Google warns that if you don't fix the vulnerability that let the infection in, the site may be reinfected. Hardening WordPress is covered in WordPress security, and where to keep configuration files in did you leave a secret file in a public directory? WordPress.org also recommends changing your passwords again once the site is clean.
Review and report: Search Console, and leaked personal data
If Search Console listed problems, fix every issue across the whole site, then select Request Review in the Security issues report. In the request, describe the problem, the fixes you made and the outcome. Google says a review takes from a few days to a few weeks and that you'll get emails when it's received and when it's complete. Resubmitting before a decision can lengthen the review.
If personal data such as contact-form submissions or member records may have leaked, see "If personal data may have leaked" below.
This site's view: the point of checking isn't to declare yourself clean — it's to decide how much you can trust
A common mistake on small sites is to find one suspicious file, delete it and call it done. But the file you found is the result of the intrusion, not the entry point. Unless you close the entry point and the ways back in the attacker left behind (public keys, admin users, scheduled jobs), it will happen again.
So we suggest judging your findings by how much you can still trust. If only WordPress core files were modified, replacing core and rotating credentials will likely get you back. If root on the server may have been taken, neither its logs nor its command output can be trusted, so rebuild. Drawing that line early saves you from spending days cleaning only to rebuild in the end.
If personal data may have leaked
If you handle personal data as a business and contact-form submissions or member records may have leaked, check the rules where you operate.
- EU and UK (GDPR, Article 33): notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to people's rights and freedoms. Article 34 covers when you must also tell the people affected
- Japan: the Personal Information Protection Commission (PPC) lists four reportable categories — sensitive data, risk of financial harm, a suspected improper purpose, and more than 1,000 people. A leak caused by unauthorized access is given as an example of the improper-purpose category. The preliminary report is due within 3 to 5 days of discovery and the final report within 30 days (60 days for the improper-purpose category), and people affected must also be notified
- Elsewhere: check your national data protection authority
Where to get help
| Who | What they can do |
|---|---|
| Your hosting or VPS provider | Suspend the site, check provider-side logs, investigate impact on the same server |
| JPCERT/CC incident response request (Japan) | Accepts incident reports from the general public; for defaced websites, contacts the site administrator to request a fix. Report via web form or email |
| IPA report on computer viruses and unauthorized access (Japan) | Accepts reports of unauthorized-access damage, including attempts with no actual harm |
| Your national CERT or data protection authority | Incident reports and data-breach notifications outside Japan |
| WordPress.org support forums | Describe your symptoms in detail and get help from the community |
Sources (official)
- WordPress.org: FAQ My site was hacked — wordpress.org
- WordPress.org: Administration Screens — wordpress.org
- WP-CLI: wp core verify-checksums — developer.wordpress.org
- WP-CLI: wp plugin verify-checksums — developer.wordpress.org
- WP-CLI: wp user list — developer.wordpress.org
- Google: Security issues report (Search Console Help) — support.google.com
- Google: How do I know if my site was hacked? (web.dev) — web.dev
- Google: Fix the cloaked keywords and links hack (web.dev) — web.dev
- Google Search Central Blog: Detect and get rid of unwanted sneaky mobile redirects (October 2015) — developers.google.com
- Google Search Help: Report a problem with Google Search (on the "This site may be hacked" label) — support.google.com
- Debian manual pages: journalctl(1), last(1), lastlog(8), sshd(8), crontab(1), cron(8), ss(8), find(1), debsums(1) — manpages.debian.org
- RPM: rpm(8) (reading --verify output) — rpm.org
- Debian 13 (trixie) release notes: the last, lastb and lastlog commands have been replaced — debian.org
- GDPR (Regulation (EU) 2016/679), Articles 33 and 34 — eur-lex.europa.eu
- Personal Information Protection Commission, Japan: mandatory leak reporting and notification of individuals (Japanese) — ppc.go.jp
- Personal Information Protection Commission, Japan: responding to data leaks (Japanese) — ppc.go.jp
- JPCERT/CC: incident response request (Japanese) — jpcert.or.jp
- IPA: reporting computer viruses and unauthorized access (Japanese) — ipa.go.jp
Read next
- For your personal accounts: How to check if someone accessed your account
- When your host itself is breached: When your web hosting provider is breached: what customers should do (preparing for what your own settings can't stop)
- Checking where files live: Did you leave a secret file in a public directory? / Keeping .env off the public web on shared hosting
- WordPress: WordPress security — a production hardening reference / a common entry point: file upload vulnerabilities
- Terms: What is an IOC? / What is an IOA? / What is a backdoor? / What is malware?
- Recovery: Backup essentials
FAQ
QHow do I check whether my website has been hacked?
Start with the Security issues report in Google Search Console and see whether any problem is listed. Then search Google for site:yourdomain and look for pages you never created. Finally, open your site on a smartphone from Google's search results and see whether you get redirected elsewhere. Hacked content is sometimes built to stay invisible when the owner visits the site directly.
QHow do I check whether my WordPress site has been taken over?
In the dashboard, open Users > All Users and look for administrators you did not create, then Plugins > Installed Plugins for plugins you did not install. If you have WP-CLI, wp core verify-checksums checks WordPress core files against the official release. Plugins distributed on WordPress.org can be checked with wp plugin verify-checksums --all.
QMy site looks normal when I open it, but search results say it may be hacked.
Cloaking (showing different content to different visitors) may be in use. Hacked pages sometimes show spam or redirects only to search engines, or only to people arriving on a phone from search results. Google says the label stays until the owner fixes the security issues in Search Console and requests a review. Check the sample URLs in the Security issues report and use the URL Inspection tool to see what Google sees.
QI'm on shared hosting without SSH. How can I check?
Use the control panel's file manager to sort files by modification date, and download the access and error logs to look for requests to unfamiliar URLs or logins to the admin area. On WordPress, check users and plugins in the dashboard. If you're unsure, contact your host's support. On shared hosting, the provider can sometimes check the impact on the whole server, including other customers.
QIf I don't find anything, am I safe?
No. File timestamps can be changed, logs disappear once their retention period ends, and on a server where an attacker gained root, the output of the server's own commands can no longer be trusted. If you have outside evidence, such as a Search Console warning or a notice from your host, treat the site as compromised even if you find nothing, and plan to rotate credentials and rebuild.
QPersonal data may have leaked from my site. Who do I report it to?
It depends on where you operate. In Japan, the Personal Information Protection Commission lists data leaks caused by unauthorized access as an example of a reportable case, with a preliminary report due within 3 to 5 days of discovery and a final report within 30 days (60 days where an improper purpose is suspected). In the EU and UK, the GDPR requires notifying the supervisory authority within 72 hours where feasible, unless the breach is unlikely to result in a risk to people. Check your own country's data protection authority.