PHP and Node.js Security, Part 3: What Unpatched Servers Do to SEO

Parts 1 and 2 covered the CVEs. Part 3 is for whoever owns the traffic: what an unpatched PHP or Node.js server can do to your search presence, as of 26 Oct 2026. Google's wording below is quoted from its own help and Search Central pages. We don't invent traffic-loss numbers, and nobody honest can.

TL;DR

• Code execution bugs (Parts 1 and 2) are the road to hacked pages.
• Google may label you "This site may be hacked" until you fix it.
• The Security Issues report can come with "an interstitial warning page in the browser".
• Crashes count too: 5xx errors slow Google's crawling, and URLs that keep failing are eventually dropped from the index.
• Patch order, a checklist and a printable PDF are below.

From an unpatched server to a search warning

The "This site may be hacked" label

Google shows it "when we believe a hacker might have changed some of the existing pages on the site". It "won't be removed until the website owner of the site takes action", and it comes off "after we check that your site is fixed", via a review requested in Search Console's Security Issues report.

Google's spam policies say why it's strict: "Hacked content gives poor search results to our users and can potentially install malicious content on their machines." And the ranking consequence, in their words: "Sites that violate our policies may rank lower in results or not appear in results at all."

Security Issues: interstitials and repeat offenders

The Security Issues report lists what Google found. Its help page says affected sites can get "a warning label in search results" and "an interstitial warning page in the browser": visitors meet a warning before they meet you.

No hack needed: crashes, 5xx and crawling

Several of these bugs crash rather than take over: July's HTTP/2 memory exhaustion (CVE-2026-56846, v22/v24), dns.resolveAny() aborting the process (CVE-2026-58042) and June's WebCrypto remote process abort (CVE-2026-48933). A dead process serves 5xx errors.

Google's crawling docs: "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling." URLs that persistently return server errors are eventually dropped from the index. A blip slows crawling; a pattern costs indexed pages.

Patch priority: what to do first

PHP goes first because both CVEs are critical, need no login and have a public proof of concept. End-of-life lines come right after because there's no patch to apply, only an upgrade. Can't patch PHP within hours? Use the stopgaps in Part 1 meanwhile.

The patch-day checklist

# One pass per server, container or CI image
php -v 2>/dev/null | head -n 1
php -i 2>/dev/null | grep -i "Server API"
node -v 2>/dev/null

1. Inventory every runtime: servers, containers, CI images.
2. Compare each version against the fixed versions in Parts 1 and 2.
3. Back up, patch on staging, run your tests, then patch production.
4. Restart PHP-FPM, Apache or your Node processes so the new binary actually runs.
5. Re-run the version check after the restart.
6. Check Search Console's Security Issues report and watch for server errors.
7. If anything was flagged: clean every page, then request review once.

Take it with you: PHP + Node.js security patch checklist (PDF, Oct 2026). If you'd rather have it done for you, our website maintenance and security monitoring covers patching and Search Console checks.

The whole series

1. Part 1: The October 2026 PHP RCE fixes
2. Part 2: The Node.js October 2026 security release
3. Part 3: What unpatched servers do to SEO (this post)

That's the series. Skipped straight here? Start with Part 1 on PHP.