The Website With Nothing to Hack: How Modern Site Architecture Actually Works

The companion to this piece covered what an aging website costs: the visitors lost to slow pages, the maintenance hours that produce nothing, and a plugin vulnerability count that rose 42% in a single year.

This one covers the replacement. Not as a product pitch — as an explanation of the mechanism, so you can evaluate it yourself.

The short version: modern site architecture does not defend the database and the server-side code better. It removes them.

What a Legacy Page Load Actually Does

When someone visits a traditional CMS page, a sequence runs on every single request:

1. The web server receives the request and starts a PHP process
2. PHP loads the CMS core, the active theme, and every active plugin
3. The site queries a database — often a dozen or more times — for content, settings, and menu structure
4. The theme assembles HTML from those results
5. The finished page is sent to the visitor
6. The visitor’s browser then downloads and executes scripts from every plugin that added one

Steps one through five happen while the visitor waits. And each one is a place where something can go wrong or be exploited: the PHP process, the plugin code, the database query, the theme layer.

What a Modern Page Load Does

1. A server near the visitor sends a file that already exists

That is the whole sequence.

The page was assembled once, at build time, on a machine that is not connected to the public internet. What sits on the live server is finished HTML. There is no PHP process to start, no database to query, no plugin code executing in response to a stranger’s request.

Why this changes the security picture

Recall the Patchstack finding from the companion piece: 91% of 2025’s WordPress vulnerabilities were in plugins, 9% in themes, and 6 total in core. Nearly the entire disclosed attack surface lives in code that executes on the server when a visitor arrives.

Remove server-side execution and you remove the category. Not mitigate it — remove it.

This is not a claim that a static site is invulnerable. It is a narrower and more defensible claim: the specific classes of attack that account for the overwhelming majority of CMS compromises have nothing to act on.

Honest caveats, because they matter:

• Your DNS registrar and hosting accounts remain a target. Protect them with strong credentials and multi-factor authentication.
• Third-party embeds you add — chat widgets, booking tools, analytics — run in the visitor’s browser and carry their own risk.
• Forms still need somewhere to go. That endpoint is a service you are trusting.
• Denial of service is a hosting concern, not an application one, though edge networks handle it far better than a single origin server.

Anyone telling you a website is unhackable is overselling. The accurate statement is that the attack surface shrinks to a small, well-understood set of external dependencies rather than a sprawling and continuously changing codebase.

Why It Is Also Faster

The speed gain is not the result of optimisation work. It is what remains when you stop doing unnecessary things.

There is no server-side assembly time because the page is already assembled. There is no database round-trip because there is no database. And because the output is a plain file, it can be copied to servers around the world in advance — so the visitor is served from a machine physically near them rather than from one origin server in one city.

The Core Web Vitals thresholds Google measures are LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1, assessed at the 75th percentile of real visitors. Static, edge-delivered pages tend to clear LCP comfortably, because the largest cost in that metric for most sites is waiting on the server to respond at all.

INP is a different matter and worth being straight about: it measures responsiveness to interaction, and it is driven by JavaScript. A modern site that ships an enormous JavaScript bundle can fail INP just as thoroughly as a legacy one. The architecture makes good performance achievable; it does not make it automatic. Restraint in what you load still matters.

The Question Everyone Asks: “How Do I Edit It?”

This is the fair objection, and the reason many businesses stay put.

The concern is reasonable — it sounds like trading a system you can update yourself for one that requires a developer for every comma. That is not how it works in practice, but the answer depends on the business:

• Content management systems that separate editing from delivery. You log into a familiar editing interface. When you save, the site rebuilds itself automatically and publishes within a minute or two. Same experience as before; different mechanics underneath.
• Direct file editing for businesses that rarely change content and prefer not to maintain another login.
• Managed updates, where changes are requested and handled for you — often the right fit for sites that update a few times a year.

The tradeoff is real and should be stated: publishing is not instantaneous. A change takes a minute or two to appear rather than being live the moment you hit save. For most businesses this is unnoticeable. For a newsroom publishing breaking updates, it would be a genuine problem — and a legacy CMS may well be the correct tool for that job.

What Migration Actually Involves

The part that generates the most anxiety is search rankings, and it deserves a direct answer.

Rankings are attached to URLs. Preserve the URLs and you preserve the equity. That means every existing page address either continues to work or issues a permanent redirect to its new location. Done properly, search engines see continuity rather than a new site.

The work, in order:

1. Full inventory — every existing URL, catalogued before anything moves. This is the step that gets skipped and the step that causes the failures.
2. Content and design migration — rebuilt on the new architecture.
3. Redirect mapping — every old URL mapped to its destination and verified individually, not sampled.
4. Parallel staging — the new site fully assembled and tested while the old one continues serving customers.
5. DNS cutover — the switch itself, typically a few minutes, with the old site retained as a rollback path.
6. Post-launch verification — search console, redirect confirmation, and monitoring for anything the inventory missed.

Email deserves specific mention because it is the most common way a cutover goes badly. Your email is almost certainly routed through DNS records on the same domain. Those records must be transcribed and reproduced before any change, or mail stops flowing at the moment of switchover. It is a solved problem, but only if someone treats it as a step rather than an assumption.

When This Is Not the Right Answer

Static architecture is not universally correct, and pretending otherwise would be selling rather than advising.

It is a poor fit for sites built around per-user dynamic state — membership portals with personalised dashboards, complex multi-vendor marketplaces, applications where nearly every page differs per visitor. Those are applications wearing a website’s clothing, and they need application architecture.

It is also unnecessary for a five-page brochure site that loads quickly, has few plugins, and is not causing anyone trouble. Working software deserves to be left alone. Migration has a cost, and if the current site is not imposing one, the arithmetic does not favour changing it.

The clear cases for replacement are sites that are slow in a way that resists fixing, carry a large plugin surface, absorb ongoing maintenance attention, or have already been compromised once.

The Underlying Logic

Most security advice adds layers: a firewall, a scanner, a monitoring service, a backup system. Each is a reasonable response to a real risk, and each adds cost and complexity.

The architectural approach asks a different question — not how do we defend this component, but does this component need to exist at all? For a website that publishes information about a business, the answer for the database and the server-side runtime is usually no. Removing them eliminates the risk permanently and makes the site faster as a side effect.

That is the entire idea. It is less exciting than it sounds, which is generally a good sign.

If you want to know whether your site is a sensible candidate — or whether it is fine as it stands — we will look at it and tell you plainly.