PHP2Shell: A Hacked Site Is an SEO Problem Before It Is a Security Problem

Most website owners will treat PHP2Shell as a job exclusively for their developer or hosting provider. That is a costly mistake, and it can take months to undo. When a domain gets compromised, organic search rankings almost always fall long before any security tool spots the breach, and the way teams react in the first 48 hours often causes more permanent damage than the hack itself.

On October 21, 2026, PHP shipped emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which allow attackers to execute arbitrary code on a web server without authentication. Every PHP version from 5.4 through 8.5.11 is vulnerable. 

Because PHP runs most websites with a known server-side language (roughly 71%, according to W3Techs), including every WordPress installation, security researcher Kevin Beaumont has warned the flaw will trigger a massive wave of compromises.

Patching the server is the immediate priority. However, from an operational standpoint, the far bigger business risk is what an attacker does after gaining access. That is where it becomes a search problem.

“Every hack we have cleaned up in the last few years had one thing in common. The owner found out from their traffic drop, not from a security tool. By the time someone noticed, Google had already indexed thousands of pages the owner never wrote.” Varun, Head of SEO Vertical, Stan Ventures

How a Server Compromise Shows Up in Search First

Attackers rarely want to break a website or take it offline. They want to monetize its authority. A domain with years of trust in Google is a ready-made vehicle for ranking spam, which is why the most common payload we encounter is not ransomware or defacement, but SEO spam.

Website security firm Sucuri consistently ranks SEO spam among the most frequent infections it handles. Across the compromised domains our team has audited at Stan Ventures, the execution follows a predictable pattern:

• Thousands of injected doorway pages: Attackers auto-generate thousands of URLs targeting high-margin casino, pharmaceutical, replica luxury goods, or adult keywords, burying them in subdirectories the site owner never visits.
• User-agent cloaking: The malicious script detects the visitor and serves spam exclusively to Googlebot or users clicking through from search results. When the site owner types the URL directly into a browser, the website renders normally.
• Conditional redirects: Visitors arriving from Google search results are bounced to external scam storefronts, while direct visitors and logged-in administrators see no anomalies.
• Cross-domain link networks: The injected pages on your server link out to spam pages on other compromised domains, and those infected sites link back to yours.

The most common variant is the Japanese keyword hack, which floods a clean domain with auto-generated Japanese pages selling counterfeit merchandise. Korean and Chinese variants operate on the exact same mechanics.

To Googlebot, it appears as though your business has suddenly decided to publish thousands of low-quality spam pages at scale. Site-wide quality signals degrade, crawl budget gets consumed by junk URLs, and legitimate revenue-driving pages begin sliding down the SERPs.

“The pattern is always the same. Rankings drop over two or three weeks, the owner blames a core update, and they spend a month rewriting content that was never the problem. Meanwhile, the injected pages keep multiplying.” Varun, Head of SEO Vertical, Stan Ventures. 

Why Site Owners Are Always the Last to Know

For years, webmasters relied on Google Search Console (GSC) as an automatic early warning system. The standard assumption was that if Googlebot detected hacked content, an alert would land in your inbox and flag the Security Issues report.

In the recovery projects our team has handled over the past two years, that warning frequently never arrives. We regularly audit Search Console properties for domains carrying over 10,000 indexed pharmaceutical pages that still display a completely clean Security Issues tab and zero notification emails.

Whether Google’s automated classifiers failed to flag the injection as a security breach or failed to dispatch the alert is irrelevant. For the business owner, the operational reality is identical: zero warning while organic traffic bleeds out.

Consequently, discovery almost always happens by accident. A marketing manager searches the brand name and spots Japanese characters in the search results, or a customer emails support to ask why a product page redirected them to a Korean gambling portal.

“The scariest call is the one from a customer. It means real people have been landing on spam under your brand, possibly for weeks, and you have no idea how many.” Varun, Head of SEO Vertical, Stan Ventures

Monitoring cannot rest on Search Console alerts alone. Running a weekly site:yourdomain.com audit, tracking the Pages (Indexing) report for sudden spikes in indexed URLs, and monitoring server logs for unexpected crawl activity will catch an injection weeks before a customer complains.

The Panic Mistakes That Cause a Second Wave of Damage

Once a compromise is discovered, site owners typically pull in whoever is immediately available, whether that is an in-house developer, the hosting support team, or a freelance sysadmin. The security hole gets patched, but the search footprint often gets wrecked in the process. Two specific mistakes come up repeatedly during recovery audits.

Mistake 1: 301 Redirecting Every Spam URL to the Homepage

In one case we reviewed, the developer deleted thousands of injected pages and configured a blanket 301 redirect pointing all of those missing URLs straight to the homepage. To a developer, that feels clean because it eliminates broken links.

From an SEO perspective, it is self-sabotage. Those injected spam pages are wired into toxic link networks across hundreds of other compromised domains, carrying casino and pharmaceutical anchor text. A blanket 301 redirect instructs Google to consolidate all of those toxic equity signals directly into the most important page on your domain.

“A redirect says ‘this content moved here.’ You do not want Google thinking your homepage is the new home of ten thousand casino pages. Spam URLs should tell Google they are 410 Gone, nothing more.” Varun, Head of SEO Vertical, Stan Ventures

Mistake 2: Leaving the Site in Maintenance Mode for Weeks

When technical teams cannot immediately locate the backdoor, the standard impulse is to take the entire website offline while they investigate. Google’s documentation on this is explicit: disabling a whole site should last a few days at most, and leaving a domain offline for weeks will severely damage how the site is indexed. Once your core URLs drop out of the index completely, recovery has no fixed timeline and no manual override to speed it up.

WordPress maintenance plugins frequently compound this error by serving a temporary holding page with a standard HTTP 200 OK status code across every URL. To Googlebot, you have just replaced every unique product and article page on your domain with thin, duplicate content.

Taking a Site Down for Patching the Right Way

Many administrators will take PHP environments offline this week to apply the PHP2Shell updates. Google has already issued specific guidance for handling this exact rollout without triggering de-indexing.

On October 21, Google’s John Mueller noted on Bluesky that sites going offline for unplanned security updates must return an HTTP 503 (Service Unavailable) status code, rather than letting requests time out or returning 404 or 500 errors. Crucially, he pointed out that the 503 response should be served outside of PHP, either by routing DNS elsewhere temporarily or firing the rule directly through a CDN or edge firewall like Cloudflare. A 503 generated by a PHP script will fail the moment PHP itself goes down for patching.

Google Search Central confirmed that an HTTP 503 preserves your existing indexed URLs while maintenance happens. Follow these exact parameters from Google’s documentation during your maintenance window:

• Limit 503 responses to 48 hours maximum: URLs that return a 503 for several consecutive days will eventually be treated as permanently offline and dropped from the index.
• Include a Retry-After HTTP header: Provide Googlebot with an explicit timestamp or duration indicating when the server will return online.
• Never serve a 503 on robots.txt: Returning a 503 on your robots.txt file blocks all crawling across the domain immediately.
• For outages exceeding 48 hours: Serve an indexable holding page on the homepage only with a standard 200 status code, rather than leaving the entire domain on a 503 for a week.
• Never use 403, 404, or 410 for temporary downtime: Those status codes instruct Googlebot that your legitimate pages have been permanently removed or restricted.

“A 503 is you telling Google ‘come back later.’ A 404 is you telling Google ‘forget this page.’ Under pressure, people pick whichever one the server spits out. Pick deliberately.” Varun, Head of SEO Vertical, Stan Ventures

Cleaning Up Injected Pages Without Losing Rankings

Deleting malware files from your server does not remove the spam URLs from Google’s index. Those injected pages will remain live under your brand name in search results until Googlebot recrawls each URL and confirms it is gone. The HTTP status code your server returns dictates how fast that cleanup happens.

Our operational standard is to return an HTTP 410 (Gone) status code for every injected spam URL, rather than a standard 404. While Google treats 404 and 410 similarly over the long term, the short-term processing speed matters during a hack cleanup.

John Mueller has explained that Googlebot often recrawls a 404 multiple times over a grace period to confirm the deletion was intentional before dropping the URL. A 410 status code removes ambiguity and accelerates removal by several days per batch. Across ten thousand injected URLs, those saved days compound quickly.

“For injected spam pages, we return a 410, not a 404. It tells Google the page was removed on purpose, so it skips the confirmation step and clears faster. When you are dealing with thousands of Japanese or casino pages, a few days saved per URL adds up.” Varun, Head of SEO Vertical, Stan Ventures

Once the server is patched, execute the search cleanup in this exact order:

1. Eliminate the backdoor, not just the visible spam: Attackers usually leave a persistent uploader script or rogue cron job behind. If your developer only deletes the spam directories, the script will regenerate the pages within days.
2. Audit Google Search Console users: Attackers sometimes upload verification tokens to register themselves as property owners in GSC. Navigate to Settings > Users and permissions, revoke any unrecognized accounts, and purge their verification files from your root directory.
3. Serve a 410 header on all injected URLs: Configure server-level rewrite rules via .htaccess, Nginx, or Cloudflare to return an immediate 410 status across the subdirectories or URL regex patterns used by the attacker.
4. Deploy the GSC Removals Tool for immediate triage: Use the URL Prefix removal tool in Search Console to hide the highest-visibility spam folders from live search results within 24 hours while Googlebot processes your 410 headers.
5. Submit a clean XML sitemap: Verify that your sitemap generator was not compromised, confirm it lists only canonical legitimate pages, and resubmit it in GSC to prioritize fresh crawling on your core URLs.
6. File a review request if flagged: If Search Console did register a Manual Action or Security Issues flag, submit a formal review detailing the PHP patch, backdoor removal, and 410 implementation.
7. Monitor index bloat weekly: Track your indexed page count in Search Console over the next 30 days to verify that the total volume steadily returns to your pre-breach baseline.

Dileep Thekkethil

Author

Dileep Thekkethil is the Director of Marketing at Stan Ventures, where he applies over 15 years of SEO and digital marketing expertise to drive growth and authority. A former journalist with six years of experience, he combines strategic storytelling with technical know-how to help brands navigate the shift toward AI-driven search and generative engines. Dileep is a strong advocate for Google’s EEAT standards, regularly sharing real-world use cases and scenarios to demystify complex marketing trends. He is an avid gardener of tropical fruits, a motor enthusiast, and a dedicated caretaker of his pair of cockatiels.