Patch, Harden or Rebuild? Planning a Secure Website Rebuild

Patch when the site is current and the problem is one known flaw. Harden when the software is supported but the setup around it is weak. Rebuild when the foundation itself can no longer be kept safe: the server runs a PHP version that no longer gets security fixes, key plugins or themes are abandoned, or the site needs so much other work (accessibility, a new CMS, a new host) that fixing it in place costs more than starting clean.

Most sites need the first two long before they need the third. A rebuild is slow, and it carries its own risks, from lost search rankings to a new set of vendors you now depend on. It is the right call when every patch buys only a few months, and when the people who maintain the site can no longer tell you what is installed or who can log in.

The PHP2Shell flaws fixed on 21 October 2026 are a useful test. A supported site needed a PHP update and a restart. A site on PHP 8.1 or older had no official release to install, and CISA told organizations in that position to take PHP-based systems offline until they could be patched or updated. If your site was in the second group, this guide is for you.

Patch, Harden or Rebuild: The Three Options

These words get used loosely, so here is how this guide uses them.

• Patch: apply a vendor fix to software you already run. Updating PHP, the CMS core or a plugin to a fixed release is a patch.
• Harden: change the configuration around supported software so it is harder to attack. Examples are removing unused plugins and accounts, turning on two-factor sign-in, restricting the admin area, tightening file permissions and adding monitoring.
• Rebuild: move the site to a new, supported foundation. That can mean the same CMS on a new server and current versions, a different CMS, or a static or headless architecture.

The three are not exclusive. A rebuild project almost always starts with patching and hardening the old site, because the old site stays live while the new one is built.

Decision Criteria: When Patching Stops Being Enough

Use the table to score your site. One "rebuild" signal is a reason to investigate. Several usually settle it.

The PHP dates come from the PHP supported versions page, checked in October 2026. Some Linux distributions and control panels ship their own patched builds of older PHP branches, so "end of life upstream" does not always mean "unpatched on your server." Ask your host which build you run and who patches it. Our guide to upgrading old PHP safely covers the in-place route.

Abandoned extensions are the most common trigger

For most small and mid-size sites, the CMS core is not the problem. Patchstack's report on 2025 data found that "91% of new vulnerabilities were found in plugins, and 9% were found in themes," with only six low-priority issues in WordPress core. It also found that "46% of vulnerabilities did not receive a fix from the developer in time for public disclosure" (Patchstack, State of WordPress Security in 2026). If your booking form, member area or store depends on a plugin no one maintains, you can't patch your way out. See why you inherit the security of everything you install.

Accessibility debt changes the math

If templates, navigation and forms fail accessibility checks, you will pay to rebuild them anyway. Doing that work once, as part of a secure rebuild, is usually cheaper than fixing an old theme and then replacing it. State and local governments have fixed deadlines under the ADA Title II web rule (see our local government security guide). An accessibility audit before you scope the rebuild tells you how much of the front end has to change.

What PHP2Shell Showed About Old Foundations

PHP2Shell is a flaw in PHP itself, not in WordPress, Drupal or Joomla. Updating the CMS or a plugin does not fix it. The fix is a patched PHP build and a restart of the PHP processes.

For sites on supported PHP, that was a short job. For sites on PHP 8.1 or older there was no official release. CISA's 21 October alert said organizations "that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." The PHP project did publish source-only backports for 7.4, 8.0 and 8.1, but there are no official binaries, and applying them is a job for whoever builds your server's PHP.

That is the real cost of an old foundation. It is not that you get hacked every week. It is that when a serious flaw lands, your options shrink to "go offline" or "take a risk." If you need help now, see emergency PHP patching. The rest of this guide is about making sure the next one is a routine update.

Secure by Design and Memory Safety, Without the Hype

CISA's Secure by Design guidance asks software makers to "Take Ownership of Customer Security Outcomes, Embrace Radical Transparency and Accountability, and Lead From the Top" (CISA, Secure by Design, revised 25 October 2023). For a website owner, the useful translation is: choose platforms and vendors that publish security fixes on a schedule, document their support periods and make updates easy to apply.

Memory safety comes up in rebuild conversations because the PHP2Shell flaws are use-after-free bugs (CWE-416), a memory-safety class. CISA and its partners' Case for Memory Safe Roadmaps (December 2023) lists C#, Go, Java, Python, Rust and Swift as memory safe languages. PHP is not on that list. The same paper also says memory safe languages "will almost certainly need to rely on libraries written in languages such as C and C++."

So don't rebuild just to change languages. Every mainstream web stack sits on lower-level code somewhere. What matters more for a small site is that the stack you choose is supported, widely used, patched quickly and maintained by people you can reach. CISA's memory-safety roadmap deadline is aimed at software manufacturers, not at businesses that run websites.

Static and Headless Builds: What Actually Shrinks

A static or headless site moves most pages out of a live CMS and serves them as prebuilt files. That removes a lot of server-side code from public view. OWASP's advice on attack surface is to reduce it "by simplifying the model," by not storing data you don't need and "turning off features and interfaces that aren't being used" (OWASP Attack Surface Analysis Cheat Sheet).

Hosting vendors make strong claims here, so read them for what they cover. Jamstack.org, which Netlify runs, promises "fewer servers and systems to harden against attack." Netlify says content on its edge nodes is "fully prerendered and static, offering no active processes or surface area for attack." That statement is about static files on the edge. It does not cover the rest of the site.

What stays your job on a static or headless build:

• Forms and serverless functions. Contact forms, quote requests and search still run code.
• The headless CMS and its accounts. Editors still sign in somewhere, and that login needs two-factor authentication.
• The build pipeline. Packages pulled in at build time are part of your supply chain.
• Third-party scripts. Analytics, chat and payment scripts run in your visitors' browsers. For card payments, PCI DSS 6.4.3 and 11.6.1 still apply.
• Costs from attacks. Vercel's shared responsibility page says "Customers are responsible for addressing any costs and resource consumption related to malicious traffic."

Our headless and custom website security guide covers these in detail. A static build is a good choice for many brochure sites. It is not a security guarantee.

Migration Risks: Rankings, Redirects and Data

A rebuild that loses half your search traffic is not a success, even if it is secure. Google's site move guidance (last updated August 2026) recommends server-side permanent redirects "such as 301 and 308," says to avoid chaining redirects, and calls Search Console "your friend, especially during a site move."

1. Export every live URL from the old site, your sitemap and your analytics before anything changes.
2. Map each old URL to its new home, one to one where you can. Don't send everything to the home page.
3. Carry over titles, meta descriptions, headings and structured data for pages that rank.
4. Test the redirect map on staging, then again on launch day.
5. Keep the old site's database and files in a secured backup, offline from the web, until the new site has been stable for a few months.
6. Decide what data you no longer need to keep. Old form submissions and user accounts you don't need are risk without benefit.
7. Watch crawl errors and rankings weekly for the first two months.

If the old site was ever compromised, don't copy its files or database wholesale. Move content, not code, and review anything that came from the old database.

Phasing a Rebuild So It Can Be Approved and Funded

Large one-shot rebuilds stall in budget meetings. Phases with a clear deliverable each are easier to approve, easier to procure and easier to stop if priorities change.

Phase 1 is a website security assessment. Phase 3 is where a vendor and platform review belongs. OWASP's Application Security Verification Standard (ASVS) says it can be used "during procurement" to specify security requirements in contracts.

Requirements to Write Into the Rebuild Scope

Whatever platform you choose, put these in writing before the build starts:

• A named runtime and CMS version with its published end-of-support date, and an upgrade plan before that date.
• Who applies security updates to the runtime, CMS and extensions, how fast for critical fixes, and who restarts services afterward.
• A short, approved list of plugins, modules or packages, each with an active maintainer.
• Two-factor sign-in for every admin and editor account, and named accounts instead of shared logins.
• Backups stored separately from the site, with a tested restore.
• An inventory of third-party scripts and who approves new ones.
• The accessibility standard the site must meet and how it will be tested.
• Handover: you own the domain, hosting account, code repository and admin credentials.

Conclusion

A rebuild is the right answer when the foundation can't be kept in support: an end-of-life runtime that won't upgrade, core features tied to abandoned extensions, or accessibility and hosting changes that make the old site expensive to keep. Otherwise, patch and harden first, and rebuild on your schedule rather than during the next emergency. Whichever path you take, plan the migration as carefully as the build. If you want an independent view before you commit budget, our website security consulting team can assess the site and give you a written recommendation.

Frequently Asked Questions