The quickest ways to tell if your website is hacked are to check Google Search Console's Security Issues report, search Google for site:yourdomain and look for pages you never wrote, open your site from a Google result on a phone, and look in your admin panel for users and plugins you did not add. Each of those catches a different kind of hack, and most hacks are designed so the site looks normal when its owner visits it directly. Below are the twelve checks I would run, in order, and what I learnt from cleaning my own hosting account this year.
That last part is why I am writing this. At the end of August 2026 I cleaned a compromised WordPress installation on this domain. On 3 November I found it compromised again, through mechanisms the first cleanup had missed. Nothing below names the attacker's tools or the other sites on that account. It describes what the attack looked like from the owner's side, because that is the view most guides skip.
Why a hacked site looks normal
Modern website malware is built to make money quietly: spam pages for search engines, redirects for visitors arriving from Google, or a foothold to sell or reuse later. All of that works better if the owner never notices. Google's own documentation on hacked sites describes redirects that fire depending on the referrer, user agent or device, so a visitor from a search result is redirected while you, typing your address directly, are not. Security firm Sucuri documented in January 2026 an attack that injected spam only when the visitor was Googlebot or another crawler.
In my case the public pages were clean. Those pages are static HTML that WordPress does not touch, so nothing reached visitors. Behind them, in the WordPress installation, there were five separate ways back in.
What I actually found
These are the persistence mechanisms, meaning the parts that let an attacker return after a cleanup, that I removed on 3 November 2026. They are worth knowing because each one survives a different kind of cleanup.
| What | Where it hid | Why a normal cleanup misses it |
|---|---|---|
| A file that logs any visitor in as administrator when given a secret parameter | Three identical copies: the uploads folder, the languages folder, and inside a fake plugin | Removing one copy leaves two |
| Hidden administrator accounts | The user table, plus settings that marked them hidden | Deleting them without removing the files that recreate them only buys time |
| Malware stored in the database | Settings entries disguised as cache data: one held a complete malicious plugin encoded as hex, ready to be written back to disk; another held encrypted JavaScript that fetched its instructions from a public blockchain | File scanners do not read the database |
| Plugins named to look legitimate | Names like a hosting "patch", a "security" or "seo" plugin with a number on the end, and a well-known hosting brand's name | They look like something the host or an SEO tool installed |
| Empty "dropper" files and a check-in beacon | Zero-byte PHP files kept ready for new code, and one line added to a theme file so the attacker could test whether access still worked | Empty files do not trigger malware scanners |
Three lessons came out of it.
Clean the files before the database. In the first incident, an administrator account kept reappearing after deletion because a file recreated it. Delete the code that does the recreating first, then the accounts and database entries.
The database is part of the site. Two of the five mechanisms would have survived reinstalling WordPress, every plugin and the theme from clean copies, because it lived in the settings table.
Your site is only as safe as its neighbours. On my hosting account, every domain ran as the same system user. A backdoor in any other site on the account could rewrite this one's files and read its database password. That is the most likely reason the first cleanup did not hold. If you host several sites, especially old or abandoned ones, on one shared account, they share one security boundary.
Twelve checks, in the order I would run them
From the outside (no technical access needed)
- Search Console, Security Issues report. Google lists hacked content, malware and social-engineering problems here, with example URLs and the date it first saw them (Google's help page). If nothing is listed, that is good but not conclusive.
- Search
site:yourdomain.comon Google and page through several screens of results. Look for pages you never created, Japanese or other foreign-language titles, or pharmacy, casino and loan keywords. Google's guides on the Japanese keyword hack and the cloaked keywords hack show what these look like. - Open your site from a Google result on a phone, using mobile data. Do not type the address. Google's sneaky mobile redirects page names hacker-added scripts as one cause of redirects that only mobile visitors from search see.
- Use URL Inspection in Search Console on your homepage and a few key pages, and look at the rendered HTML Google received. Content shown only to Googlebot appears here, not in your browser.
- Check Google Safe Browsing's site status for your domain.
From the admin panel
- List every administrator. Any account you cannot name a person for is suspect, as is any whose email you do not recognise.
- List every plugin, including inactive ones, and the "must-use" plugins in
wp-content/mu-plugins, which do not appear in the normal list and cannot be disabled from the dashboard. Sucuri documented a backdoor that hid there in 2025. Any plugin you do not remember installing, especially one with a vague or generic name, needs explaining. - Check Search Console's users and owners. Attackers add themselves as owners to control what Google sees. Google's guide says to revoke unknown owners.
From the files and database (needs hosting access)
- Look for PHP files where none should be, above all in the uploads folder, which should contain images and documents only.
- Compare core files against official checksums. WordPress publishes them, and WP-CLI's
wp core verify-checksumsandwp plugin verify-checksums --alldo the comparison. - Read
.htaccessand any.user.iniorphp.iniin full. Rewrite rules pointing to strange PHP files, orauto_prepend_filesettings, are classic hiding places. Google's guide mentions rewrite rules that fake Search Console verification files. - Search the database settings table for long entries containing
base64,eval,<scriptor very long hex strings, and check your posts for script tags you did not add.
If you are not comfortable with the last four, that is normal. They are the checks to ask your developer or host to run and report back on in writing.
PHP2Shell: why every PHP site in Nepal should check its version now
In October 2026 two critical vulnerabilities in PHP itself, nicknamed PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619, were disclosed. According to PHP's own security advisory they allow remote code execution and affect PHP versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Qualys reported that any PHP setup serving web requests was exposed, and that the temporary mitigations PHP suggested do not make an unpatched installation safe. Help Net Security reported an exploitation attempt seen four days before public disclosure.
In Nepal, the Kathmandu Post reported that thousands of government websites were taken offline as a precaution, that banks suspended some web services, and that the National Cyber Security Center had issued an advisory. By 26 October most government sites on the shared GIWMS platform had been patched and restored. When I counted 1,128 government websites a week later, 704 still did not answer from outside Nepal.
For a private website, the check is simple: ask your host which PHP version your site runs, and whether it is at or above the patched release for its branch. Older branches such as 7.4, 8.0 and 8.1 are end of life and get only limited fixes, so "we are on PHP 7.4" is itself the answer. Some Linux distributions patch without changing the version number, so if your host says so, ask for the advisory that confirms it. A site that ran an unpatched version in late October should be checked with the list above, not merely updated.
If you find something
- Do not start deleting at random. Take a full backup of files and database first. It is evidence, and your fallback if a cleanup breaks the site.
- Change every password: hosting panel, FTP and SFTP, database, every admin account, and Search Console. Do it from a device you trust.
- Remove the code that recreates things before the things themselves: files, then accounts, then database entries.
- Reinstall WordPress core, plugins and themes from official sources rather than editing infected copies, and delete anything you do not use.
- Check every other site on the same hosting account. If they share a system user, cleaning one alone will not hold.
- Update PHP to a supported, patched version.
- Request a review in Search Console's Security Issues report once everything is fixed. Google says reviews take from a few days to a few weeks.
- Check again in two weeks. My first cleanup looked complete. It was not.
How common is this?
Very common, and getting stealthier. SiteLock's 2025 website security report, which is vendor research, found a backdoor on 70.3% of the infected sites it cleaned in 2025, up from 48.9% in 2024. In other words, most infections now include a way back in.
A clean set of security headers does not mean a clean site. When I checked the headers on 30 Nepali government websites in September, I noted that I had found two live backdoors on my own hosting account, on a site with clean headers. Headers describe the front door. This article is about everything behind it.
Questions people ask
How do I know if my website is hacked if it looks normal?
Check from the outside the way Google and search visitors see it: the Security Issues report, a site: search, URL Inspection, and a visit from a Google result on a phone. Then check admin users and plugins.
Can a website be hacked without the owner noticing?
Yes. That is the normal case. Attacks are designed to show spam or redirects only to search engines or to visitors arriving from search.
Will reinstalling WordPress remove the hack?
Not always. Malware can live in the database, in uploads, in must-use plugins, or in other sites on the same account, and none of those are touched by reinstalling core.
How do I check my PHP version?
Your hosting panel usually shows it. In WordPress, Tools, then Site Health, then Info, then Server lists it. Compare it with the patched releases for PHP2Shell: 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
Does a hacked site lose its Google rankings?
It can. Google may show a warning in results or remove hacked pages, and spam pages dilute the site. After cleaning, request a review in Search Console.
Sources
- Google Search Central, What is a hacked site?; Google, Security Issues report; Sneaky mobile redirects. Accessed 5 November 2026.
- web.dev (Google), Fix the Japanese keyword hack; Fix the cloaked keywords and links hack.
- PHP, Security advisory GHSA-6wmf-4rv5-p3rp, 21 October 2026.
- Qualys, PHP announces critical security release for two vulnerabilities, 20 October 2026, updated 29 October 2026.
- Help Net Security, PHP2Shell vulnerabilities patched, 21 October 2026.
- The Kathmandu Post, PHP2Shell security flaw forces thousands of Nepali websites offline, 25 October 2026; Most Nepal government websites back online, 26 October 2026.
- Sucuri, Google sees spam, you see your site, 8 January 2026; Stealthy WordPress backdoor in mu-plugins, 22 July 2025 (vendor research).
- SiteLock, 2025 Website Security Report (vendor research).
Featured photo: Estormiz, Wikimedia Commons, CC0. Cropped to 16:9.
