How should websites respond to security vulnerabilities? Verify anomalies first, then plan patches and isolation where necessary

When facing a security vulnerability, website operators should first verify the anomalies, the scope of impact, and the operating environment, then arrange appropriate patches. Temporary isolation or taking the site offline should be considered only if the affected website cannot be protected immediately. A normal-looking homepage does not rule out a compromise, nor does a suspicious file confirm where a vulnerability lies. Google’s descriptions of compromised sites and Search Engine Journal’s reporting on responses to a specific PHP vulnerability incident can help inform what to check and how to plan a response, respectively. They do not mean that the same shutdown or upgrade plan applies to every website.

Check for anomalies beyond the homepage

Google’s guidance notes that hackers may modify existing pages or create additional spam or phishing pages. The absence of obvious changes to existing pages therefore does not mean the entire website is free of problems. Anomalies to watch for include:

• Unauthorized JavaScript or iframes appearing on pages.
• Unfamiliar pages appearing on the website, or hidden text and links being added to existing content.
• Some visitors being redirected to harmful websites, while administrators encounter no redirect when entering the URL directly.

Redirects may vary depending on the referring URL, user agent, or device. For example, clicking through from Google search results may lead to a suspicious page, while opening the same URL directly appears normal. A single normal browsing session cannot rule out these differences.

A suspicious file is a clue, not a complete diagnosis

A reply on Webmasters Stack Exchange suggested that the file in question might simply be a link farm and not itself malicious. However, the fact that it could be uploaded to the server suggested that there was likely a security gap in the website or affecting another user on the shared server. This was speculation about an individual case, not a conclusion that can be applied to every unfamiliar file, and it was insufficient to pinpoint the vulnerability.

Response plans also need to account for the actual environment. For example, in its October 21, 2026 report on the PHP incident, Search Engine Journal recommended that WordPress administrators check their PHP version under “Tools → Site Health → Info → Server,” then ask their hosting provider to install a fixed version or confirm that the vendor’s update included both fixes for that incident. The key is to verify that the update addresses the issue, rather than treating an “updated” status as proof that the problem has been resolved.

Consider temporarily taking the site offline if patching is not immediately possible

The same report cited advice from CERT-EU and the UK’s National Cyber Security Centre: consider temporarily isolating or shutting down affected websites if immediate protection is not possible. Some government websites mentioned in the report were taken offline as a precaution, not as proof that they had been compromised.

For that incident, the report also cautioned that a web application firewall might block some attacks but could not replace patching. If a website was taken offline to update PHP, administrators could ask their hosting provider to serve a maintenance page returning HTTP 503. These measures depend on the incident and environment and should not be generalized into a rule that “every vulnerability requires shutting down the website.”