Since the PHP2Shell news broke, I have been getting the same question from business owners again and again: “My website looks fine. Does that mean it wasn’t hacked?” Many people believe a hacked site is easy to spot, with a defaced home page or a scary message from the hacker. That is rarely how it works today.
Most hacks that hurt SEO are built to stay hidden. The spam is shown to Google, not to you. The redirects fire for visitors who come from search, not for the owner who types the address directly. So your site can look normal on your laptop while Google is indexing hundreds of pages you never wrote.
As of October 23, 2026, this matters more than usual. On October 21, PHP released security updates for two critical flaws that Wiz Research named PHP2Shell, and attacks reportedly started within minutes. I explain the news and its SEO cost in my post on how PHP2Shell can hurt your rankings. Here, I give you 12 warning signs you can check yourself, today, and what to do if one turns up.
Why a hacked site can look perfectly normal to you
The main reason owners miss a hack is a trick called cloaking. In simple words, cloaking means the site shows one thing to Google and something else to people. Google’s spam policies define it as “presenting different content to users and search engines” to manipulate rankings and mislead users.
Cloaking buys hackers time. If you never see the spam, you never clean it up. Google’s guide says it plainly:
“Hackers try to trick you into thinking the page is gone or fixed when it’s still hacked.”
— web.dev, Fix the cloaked keywords and links hack
Hackers usually hide their work in one of these ways:
- By visitor type: Googlebot sees spam, while humans see your normal page or a 404 page.
- By referrer: visitors clicking your Google result are redirected to a scam site, but typing your address works fine.
- By device: desktop visitors see the real site, while mobile visitors are sent elsewhere.
- By location: your pages stay untouched, but new spam pages appear in odd folders, like the Japanese keyword hack’s
/ltjmnjp/341.html.
So the checks below don’t ask “does my home page look okay?” They look at Google’s data, Google’s results, your files and your logs.
The 12 warning signs at a glance
Here is the full checklist, grouped by where you look. Treat any “strong” sign as a likely hack until you prove otherwise.
| # | Warning sign | Where to check | How strong a signal |
|---|---|---|---|
| 1 | An issue in the Security issues report, or an email about it | Search Console | Strong (Google has confirmed something) |
| 2 | A manual action for cloaking, sneaky redirects or third-party spam | Search Console | Strong |
| 3 | Owners, users or sitemaps you don’t recognize | Search Console settings and Sitemaps report | Strong |
| 4 | Strange queries: foreign scripts, pharma, casino, replicas, loans | Performance report | Strong if the pages are not yours |
| 5 | A sudden jump in indexed pages | Page indexing report, Crawl stats | Medium to strong |
| 6 | Google sees different content than you do | URL Inspection tool | Strong |
| 7 | Spam pages or odd titles in a site: search | Google search | Strong |
| 8 | “This site may be hacked” or a red browser warning | Google search, Chrome, Safe Browsing site status | Strong (confirmed by Google) |
| 9 | Redirects only from Google or only on mobile | Phone test, analytics, a simple header check | Strong |
| 10 | New admin users, plugins or themes | Your CMS dashboard | Strong |
| 11 | Changed files, new PHP files, odd .htaccess rules | Hosting file manager or your developer | Strong |
| 12 | PHP2Shell-style traces in server logs | Server and PHP error logs | Medium (needs a technical eye) |
One sign alone is enough to start investigating. Two or more together, and I would stop guessing and move straight to the recovery steps.
Signs 1 to 6: what Google Search Console is telling you
Search Console is your direct line from Google. If it isn’t set up yet, our complete guide to Google Search Console walks you through it.
Sign 1: an entry in the Security issues report
Open Security & Manual Actions → Security issues. If Google has detected a problem, it will be listed here with a type and some example URLs. According to Google’s Security issues report help page, the hacked categories include malware, code injection, content injection and URL injection. Other types cover social engineering (for example, fake login pages) and harmful downloads.
The example URLs are a sample, not a full list. And Google says affected pages may get a warning label in search or a browser warning screen, so an entry here usually means you are already losing clicks. Make sure Search Console alerts go to an inbox you actually read.
Sign 2: a manual action linked to spam or redirects
Next, open Manual actions. There is no manual action named “hacked,” because hacks go to the Security issues report. But several manual action types often appear on hacked sites. The Manual actions report help page lists:
- Cloaking and/or sneaky redirects
- Sneaky mobile redirects (Google’s own advice here is to check the Security issues report for signs of a hack)
- Site abused with third-party spam
- Major spam problems
If you never used cloaking or redirects and one appears, assume someone else did.
Sign 3: owners, users or sitemaps you didn’t add
Go to Settings → Users and permissions. Look for any owner or user you can’t name. Google’s guide on the Japanese keyword hack warns that hackers often verify themselves as site owners so they can change settings such as sitemaps or geotargeting. If you find a stranger, the guide says there is “a strong possibility that your site has been hacked.”
Then open Sitemaps. Attackers add or change sitemaps so their spam gets crawled faster. Question any sitemap you don’t remember submitting.
Sign 4: queries that have nothing to do with your business
This check often catches a hack before Google flags it. Open Performance → Search results, choose the last 28 days, and scan the Queries and Pages tabs for scripts your business doesn’t use, words like pills, casino or replica watches, and URLs in folders you never created.
A regex filter (a search pattern) speeds this up. Click + Add filter → Query → Custom (regex) and try these:
| What you are looking for | Regex to paste in the query filter | Notes |
|---|---|---|
| Common pharma and gambling spam | viagra|cialis|pharmacy|casino|slot|betting|replica|payday | Add words in your own market’s language |
| Japanese or Chinese characters | [\p{Han}\p{Hiragana}\p{Katakana}] | Uses Unicode script classes; skip if you really target these markets |
| Random-looking page paths (Pages tab) | /[a-z]{6,}/[0-9]+\.html | Matches paths like the Japanese keyword hack example |
If regex is new to you, our guide to regex filters in Search Console explains the syntax in plain words.
Sign 5: a sudden jump in indexed pages
Open Indexing → Pages. If indexed pages jump by hundreds or thousands in a few days and you published nothing, something is creating pages. A spike in Settings → Crawl stats, or a pile of unfamiliar 404 URLs, points the same way.
Sign 6: Google sees something different from what you see
This is the direct test for cloaking. Take a suspicious URL from signs 4 or 5, or simply your home page, and paste it into the URL Inspection tool. Click Test live URL and then View tested page to see the HTML and screenshot that Google received.
Compare it with your browser view. Look for extra links, hidden text, foreign words or a redirect you don’t see. Google’s hack guides recommend this step because a page can show you a 404 while serving spam to Google. Our URL Inspection tool guide shows where each button is.
Signs 7 to 9: what Google search and a phone test reveal
You don’t need to log in for these. Anyone can run them, which means your customers can see the results too.
Sign 7: spam in a site: search
Type site:yourdomain.com into Google. This shows pages Google has indexed from your domain. Google’s web.dev guide explains that this “shows you all the pages on your site, including pages a hacker might have added.”
Click through several pages of results and look for:
- Titles in a language you don’t use, or titles about products you don’t sell
- URLs in folders you never created
- Snippets full of nonsense text or keyword lists (the “gibberish hack”)
- Your brand name sitting next to pharma, gambling or adult terms
Narrow it with site:yourdomain.com casino and similar words. Our Google search operators cheat sheet lists more combinations, and Google suggests trying another search engine too.
Sign 8: a warning label next to your site
Your customers may see these before you do:
- “This site may be hacked” under your result in Google Search. This usually points to spam hacks.
- “This site may harm your computer” in search, or a full red warning screen in Chrome and other browsers that use Google Safe Browsing. This usually points to malware or phishing.
Check your domain in Google’s Safe Browsing site status tool, which Google’s malware guide recommends.
Sign 9: redirects that only fire for some visitors
Conditional redirects steal the exact visitors you worked hardest for. Google’s malware guide says hackers often set redirects “based on the user-agent, time of day, or referrer.” Here is how to test without technical tools:
- On your phone, using mobile data, search Google for your brand name.
- Tap your own result (not an ad) and note where you land.
- Repeat for two or three top pages, and once in a private desktop window.
- Ask your developer to request a few URLs with a mobile user agent and a Google referrer and look for redirects to another domain.
Analytics can back this up. If GA4 organic sessions fall while Search Console clicks stay flat, visitors may be redirected before your tag loads. And if a customer says “your site sent me to a weird page,” believe them, even if you can’t reproduce it.
Signs 10 and 11: what has changed inside your website
These two look for the break-in itself. WordPress, Drupal and Joomla all run on PHP, so they matter for PHP2Shell.
Sign 10: admin users, plugins or themes you didn’t add
Check every administrator in your CMS. Hackers like to add an admin with a harmless name such as “wpsupport,” so they can get back in after you patch. Then look for plugins or themes you didn’t install. Google’s guide on the top ways sites get hacked also warns against free copies of paid plugins, because they often carry hidden code.
Sign 11: files that changed when nobody touched them
Ask your developer or host to list files modified in the last 30 days, and compare that list with what you know was changed. Google’s cleanup guides point to a few classic signs in PHP files: recent changes, unusual file sizes and blocks of encoded code that a normal theme wouldn’t need.
Two places deserve special attention:
- The
.htaccessfile (on Apache servers). Hackers add rewrite rules that send visitors or bots to their own PHP files. Any rule you don’t recognize is suspicious. - Upload folders, such as WordPress’s
/wp-content/uploads/. These should mostly hold images and documents. A PHP file sitting there is a strong warning sign.
Don’t delete anything yet. The wrong deletion can break the site and destroy evidence.
Sign 12: the PHP2Shell traces Wiz says to look for
This last sign is specific to the new vulnerability. Wiz Research published its findings on October 21, 2026. It gave no file names or IP addresses to block. Instead, it listed behavior patterns that may show up in server logs:
- Unusual multipart requests (the kind of request used for file uploads) followed by memory-limit errors or repeated HTTP 500 errors
- Unexpectedly large or malformed PHPSESSID cookies in responses (PHPSESSID is the standard PHP session cookie)
- Unexplained PHP worker churn, meaning PHP processes crashing and restarting more often than normal
Wiz also warned that your normal application logs may not help much:
“These issues execute below the application layer, so application logs may contain little context.”
— Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities
So a security plugin’s log may look clean even if the server was hit. Check the web server access log, the PHP error log and your host’s resource graphs instead. Our guide to log file analysis explains what each line means.
Keep it in proportion. A few 500 errors are normal; a pattern since October 21, 2026 is not. These traces suggest someone tried, not that they succeeded, and a clean log doesn’t prove you are safe.
What is confirmed and what is reported so far
This is fast-moving news, so here is how I separate the facts as of October 23, 2026.
| Claim | Status | Source |
|---|---|---|
| Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | Confirmed by the PHP project | php.net security advisory, Oct 21, 2026 |
| PHP 8.1 and older get no fix from the PHP project | Confirmed by the PHP project | php.net security advisory |
| Two CVEs, severity up to CVSS 9.2, pre-auth code execution shown on WordPress, Drupal and Joomla | Confirmed by the researchers | Wiz Research |
| 22.6 million potentially vulnerable instances | Reported (Palo Alto Networks’ initial analysis) | Fortune, Oct 21, 2026 |
| Millions of exploit attempts seen by Cloudflare on the evening of Oct 21 | Reported (Cloudflare CEO) | Fortune, Oct 21, 2026 |
| The flaw is “now being broadly exploited in the wild” | Reported (AWS statement) | Fortune, Oct 21, 2026 |
The PHP project is clear about the fix:
“There are no complete mitigations, updating is the only safe choice.”
— The PHP Group, php.net news archive 2026
A 30-minute hack check you can run this afternoon
Here is how I would do it, from the quickest, strongest signals to the slower ones.
- Ask your host which PHP version you run and whether it has been updated since October 21, 2026. Write the answer down. (2 minutes)
- Search Console → Security issues and Manual actions. Screenshot whatever you see, even “No issues detected.” (3 minutes)
- Search Console → Users and permissions, then Sitemaps. Note any owner or sitemap you can’t explain. (3 minutes)
- Performance report with the regex filters above, last 28 days, Queries and Pages tabs. (5 minutes)
- Page indexing report: has the indexed count jumped? (2 minutes)
- Run
site:yourdomain.comand scroll through five pages of results. (5 minutes) - Phone test: search your brand and two key services on mobile data and tap your results. (4 minutes)
- URL Inspection live test on your home page and one suspect URL. (4 minutes)
- CMS users and plugins: any admin or plugin you don’t recognize? (2 minutes)
Hand signs 11 and 12 to your developer or host: “Any PHP files changed in the last 30 days that we didn’t change? Any memory-limit errors or repeated 500s since October 21?”
A worked example: the dental clinic that “looked fine”
This is a hypothetical example to show how the signs fit together.
Imagine a dental clinic with a 55-page WordPress site. The owner opens the home page and everything looks normal. But during the 30-minute check, they find this:
- Performance report: normally around 600 impressions a day. Over the last five days, impressions have jumped to about 9,000 a day. The regex filter for Japanese characters matches about 8,200 of them.
- Pages tab: the extra impressions go to URLs like
/qzvbnr/1187.html, a folder the clinic never created. - Page indexing: indexed pages went from 55 to around 1,400 in a week.
- URL Inspection: one of those URLs shows a 404 in the owner’s browser, but Google’s tested page shows Japanese text and dozens of links to an online shop.
- Security issues: still says “No issues detected.”
That last point is the lesson. Google hadn’t flagged the site yet, but four signs agreed. Waiting for the official warning only loses days. Compare a false alarm: 30 extra impressions for one Spanish query on the real “Dental implants” page is just noise. The difference is scale, pages you didn’t create and content you didn’t write.
Questions owners ask about spotting a hacked site
If Search Console shows no security issues, am I safe?
Not necessarily. The report only shows what Google has detected so far, and its URL list is a sample. Use it together with the Performance report, a site: search and the URL Inspection test.
Can I see Google’s “This site may be hacked” label for my own site?
Yes. It appears under your result in normal Google Search, so a quick brand search or site: search will show it. It is usually tied to an entry in the Security issues report.
My site isn’t on WordPress. Should I still check?
If your site runs on PHP in any form, yes. Wiz showed attacks on WordPress, Drupal and Joomla, and said nearly every PHP version back to 5.4 is affected by at least one of the two flaws. If your site is on a hosted builder, ask the provider whether it uses PHP and whether it has been patched.
My host says PHP is updated. Do I still need to look for signs?
Yes. Patching closes the door, but it doesn’t remove anyone who got in before the update. AWS reportedly saw exploit attempts in the days before disclosure, so a site patched on October 22 could still have been touched earlier.
How fast does a hack show up in Google?
It varies. Spam pages can appear in the Performance report within days if Google crawls them quickly, which is why hackers like to add sitemaps. A malware warning can appear soon after Google detects it. That is why I suggest checking weekly for the next few weeks.
What to do in the first hour if you find something
Stay calm. A hack is fixable, and Google lifts warnings once a site is clean. First:
- Don’t delete in a panic. Screenshot what you found and back up the current state, hacked files included.
- Patch PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or move off PHP 8.1 or older. If you can’t do it today, the PHP Foundation’s advice, as reported by Fortune, is to take the site offline until you can.
- Change passwords and rotate API keys. Wiz says the memory leak can expose passwords, tokens and API keys. Turn on two-factor login.
- Remove unknown Search Console owners and sitemaps.
- Turn on a web application firewall (WAF) from your host or CDN. Wiz lists protections from Cloudflare, Fastly, Google, Vercel and others, but only the PHP update is a complete fix.
Then follow the full cleanup plan in how to recover rankings after a website hack. If traffic also dropped during a Google spam update, read recovering when a hacked site gets caught in a spam update.
Make these hack checks a weekly habit, not a one-off
In brief: a hacked site rarely announces itself. The early signs are in Search Console, a site: search and URL Inspection. Repeat those checks weekly for the next month. For the basics, see our free lesson on HTTPS and website security for SEO and our post on why HTTPS matters for SEO.
If you found something, or don’t have time to check, we can help. Our SEO team handles hacked-site audits and cleanups, including the Search Console side. Get in touch for a quote and tell us what you found.
Further reading on hacked site warning signs
- Recovering Rankings After a Website Hack: A Step-by-Step SEO Cleanup Plan
- PHP2Shell and Your Rankings: What a Hacked PHP Site Can Cost You in Google
Sources for this hacked-site warning signs checklist
- Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Oct 21, 2026)
- php.net: News archive 2026 (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 and security advisory)
- Fortune: AI tools discovered the PHP vulnerability that could take down 70% of the internet (Oct 21, 2026)
- Google Search Console Help: Security issues report
- Google Search Console Help: Manual actions report
- Google Search Central: Spam policies for Google web search
- web.dev: How do I know if my site was hacked?
- web.dev: Fix the Japanese keyword hack
- web.dev: Fix the cloaked keywords and links hack
- web.dev: Hacked with malware
- web.dev: Top ways websites get hacked by spammers
