Static vs Dynamic Website: Which Is Safer?

A static vs dynamic website comparison comes down to where code runs: a static site serves pre-built files, while a dynamic site runs code and a database each time a page is requested. After the 2026 PHP vulnerabilities, that difference stopped being theoretical. A visitor request to a static page never reaches a PHP engine, so those flaws could not touch it. A request to a typical dynamic site always does.

This is part 4 of The Web After PHP2Shell. Parts 1 to 3 covered the PHP vulnerability, the AI angle and whether PHP is dead. This part tests the popular claim that static sites are “more secure”, says where it holds, and shows where the risk moves instead of disappearing.

On this page

• What is the difference between a static and a dynamic website?
• Did the PHP flaws spare static sites?
• Where does the risk move in a static stack?
• Can a static site still have forms, search and logins?
• Static, dynamic and hybrid compared
• Is WordPress static or dynamic?
• What about SEO and AI crawlers?
• Choosing between a static and dynamic website

What is the difference between a static and a dynamic website?

A static website is a set of ready-made files. A dynamic website is a program that makes pages on demand. The practical difference is what has to run, and be kept patched, every time someone visits.

On a static site, a build step turns your content into HTML, CSS and JavaScript files ahead of time. A web server or CDN then hands those files to visitors. On a dynamic site, a server-side language such as PHP receives each request, queries a database and assembles the page before sending it. WordPress, Drupal, Magento and most custom web apps work that way.

Did the PHP flaws spare static sites?

For pages served as plain files, yes, by construction. The php.net advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Wiz notes that the flaws sit in PHP itself, so even a minimal “Hello World” script on an affected version could be vulnerable. A request for a static HTML file does not invoke PHP, so there is nothing for these two CVEs to attack in that request.

Three caveats keep that from becoming a blanket promise:

• Shared servers. If the same machine also runs a PHP application, such as a WordPress blog under /blog/ or a phpMyAdmin panel, that software is exposed even though your home page is not.
• Reverse proxies and plugins. A “static” site that is really a static front for a PHP back end is dynamic where it counts.
• Assumed safety. The static claim covers these CVEs. It says nothing about the next flaw in a different layer.

Ambeltek’s own marketing site is a static Astro build with no PHP anywhere in the project. It is not purely static: the contact form uses hosted Netlify Forms and a few small serverless functions power the audit tool. That is a typical modern pattern, and the honest way to describe it is “mostly static, with a few small dynamic pieces we keep deliberately small.”

Where does the risk move in a static stack?

It moves from the live server to everything that produces and surrounds the site. This is the part most “static is secure” articles skip, and it is where small teams get caught.

The clearest documented example is on the supply chain side. In September 2025, CISA reported a self-replicating worm in the npm ecosystem that compromised over 500 packages. It scanned developer environments for GitHub tokens and cloud API keys, sent them to the attacker and used stolen credentials to infect more packages. Static site generators are built from npm packages, so a project that runs npm install on a developer laptop or build server is in the blast radius. CISA’s advice is practical and applies to any team: review and pin dependencies, rotate credentials, require phishing-resistant multi-factor authentication on GitHub and npm accounts, and turn on branch protection and secret scanning.

The other risks are older and quieter. A hosted form handler or edge function is server code you do not see. A third-party chat or analytics script runs in every visitor’s browser with your page’s trust. The accounts that can publish the site, at the registrar, DNS provider, host and Git platform, are worth more to an attacker than the files they publish.

Can a static site still have forms, search and logins?

Yes, with small pieces of dynamic code added deliberately. This is what “hybrid” means in practice, and it is how most modern static sites work.

• Forms. A form can post to a hosted handler run by your host or a form service, or to a small serverless function. Either way, that handler is the part of your site that can be attacked, so it should do one job, validate its input and hold no more access than it needs. A honeypot field and rate limiting are common first defences against spam.
• Search. Site search can run entirely in the browser against an index built at deploy time. No server code runs when someone searches, which keeps the site static.
• Logins and personal data. This is where static stops. Anything that remembers who a visitor is needs a server component. Use a mature identity provider or a managed back end instead of writing your own, and keep that part separate from the public pages.
• Content updates. Editors do not need to touch code. A headless CMS or a Git-based editor can trigger a rebuild when content changes, so the public site stays static while editing stays friendly.

The test for each piece is the same: does it run code when a stranger visits? If yes, treat it as part of your attack surface, give it an owner and put it on the patch list. Our own audit tool is a good example of the trade-off. It needs a few serverless functions, so those functions are kept small and separate from the pages that carry the articles.

Static, dynamic and hybrid compared

Most real sites are mixes. The question is how much code runs per request and who patches it.

Is WordPress static or dynamic?

Dynamic by default. WordPress runs PHP and a database to build pages when they are requested, which is why it sat squarely inside the October 2026 exposure. WordPress is used by 39.6% of all websites, per W3Techs on 23 October 2026, so this is the most common version of the problem.

There are two ways to reduce the exposure without leaving WordPress. A caching layer can serve saved copies of pages, which lowers load but still leaves PHP reachable on cache misses and in the admin area. A stronger approach is to keep WordPress private, behind a login or network restriction, and publish its public pages as static files. That keeps the editing experience and removes PHP from the public path. It does not remove the need to patch the WordPress server, since it still holds your content and accounts. For the SEO side of WordPress sites, see WordPress SEO.

What about SEO and AI crawlers?

Static pages are a good fit for crawlers because the full content is in the first HTML response. Googlebot can render JavaScript, but most AI crawlers do not, as covered in JavaScript rendering and AI crawlers and server side rendering SEO. A static build also tends to be fast, which helps site speed optimization and the Core Web Vitals metrics. If you use Astro, the Astro SEO guide covers the specifics.

Static is not an SEO guarantee. Thin content, bad internal links and slow third-party scripts hurt static sites like any other. The security and SEO benefits are separate wins that happen to arrive together.

Choosing between a static and dynamic website

Choose by what visitors need to do, not by fashion. The path below keeps the public site as static as it can be and puts dynamic code only where it earns its place.

A short rule of thumb: the fewer things that run when someone visits, the fewer things can be attacked while you sleep. Static is the right default for any page that looks the same to every visitor. Dynamic code should be the exception you justify.

Ambeltek builds sites this way on Astro, using static pages by default and adding server functions only where a project needs them. If you are weighing a rebuild, our web development service page explains the approach, and web design vs web development clarifies who does what. Next in the series, website maintenance mode covers what to do when a site must go offline to patch, and the final part looks at the future of web development.