Static vs Dynamic Website: Which Is Safer? (October 2026)

A static website sends every visitor a page that was built in advance, while a dynamic website runs code and queries a database on the server to build the page at the moment it's requested. The clearest way to see it is to follow one visit.

Say it's 9pm and a customer in Tampines opens the cake menu of a small bakery in Joo Chiat.

If the bakery's site is WordPress on shared hosting (dynamic):

1. The request reaches the host's server, where the web server software hands it to PHP.
2. PHP reads and unpacks the request: the address, the cookies, any form data. PHP2Shell lives in this step.
3. PHP loads WordPress, the theme and every active plugin, often 20 or 30 of them.
4. WordPress asks the MySQL database for the menu page, the cake photos, the header and footer settings.
5. PHP stitches the HTML together and sends it back. Then it does it all again for the next visitor.

If the site is static (say, Astro on a CDN):

1. Last Tuesday, when the owner changed the price of the pandan chiffon, a build turned the whole site into finished HTML files. It took about a minute.
2. Those files were copied out to the host's content delivery network, which has servers in Singapore.
3. At 9pm the customer's phone asks for the page and the nearest server sends the file. PHP and the database never come into it.

A cache plugin blurs this a little. It saves finished copies of WordPress pages so most visitors skip PHP. But PHP is still sitting there for everything the cache passes through: logins, form posts, searches and any request an attacker shapes on purpose.

The tools that build static sites are called static site generators: Astro, Hugo, Eleventy and Jekyll are the common ones, and the approach is sometimes called Jamstack. Astro's documentation says its pages are pre-rendered at build time by default. If you want the framework comparison, I've written up Astro vs Next.js vs WordPress separately. This post is about security.

PHP2Shell can't reach a static website because the flaw is in the PHP engine's handling of incoming requests, and on a static site no PHP process ever receives a visitor's request. There's nothing to send the malicious request to.

The PHP Foundation credits Calif, OpenAI and Wiz with finding the flaws. Wiz showed the attack working against the then-latest WordPress, Drupal and Joomla container images, and said every PHP version released in the last decade is affected by at least one of the two flaws. The site's own code being secure didn't help. That's the uncomfortable part for a WordPress owner who did everything right: updates, a security plugin, strong passwords. The hole was underneath all of it.

Three cases where "static" isn't quite static, so check yours:

• A WordPress site exported to static files, with WordPress still online. Plugins like Simply Static can publish a static copy, but if the original WordPress stays reachable on a subdomain or the same server, PHP is still answering requests there.
• A static front end with headless WordPress behind it. Visitors never touch WordPress, but PHP still runs wherever the CMS lives. It needs patching too, and it should sit behind a login or off the public internet.
• Server functions. Forms and APIs on a static site usually run as small serverless functions, in Node.js rather than PHP. That's a different runtime with its own updates, which the next section covers.

A static website is more secure than a dynamic one against the attacks that break into most small business sites, because those attacks target code that runs on the server, and a static site runs almost none. There's no PHP to exploit, no database to inject into, no plugin with a known hole and no public login page to guess passwords on.

The numbers explain why that matters. W3Techs counted PHP on 69.3% of websites whose server-side language it could identify, on 22 October 2026. Of the PHP sites showing a version, 26.9% reported PHP 7 and 7.7% PHP 5. Every one of those versions is past end of life, and PHP 8.1 and older got no PHP2Shell fix from the PHP project. WordPress.org's own statistics on 23 October showed about 36% of WordPress sites still on PHP 8.1 or older.

The bottom half of that table is the honest part. More secure doesn't mean nothing to secure.

A static website still has to protect its domain registrar and DNS, its hosting and code accounts, its form endpoints and serverless functions, the third-party scripts it loads and the npm packages it's built from. Attackers who can't exploit the server go after whoever controls it.

• Domain registrar and DNS. Whoever controls your DNS decides where your domain points, including your email. Turn on two-factor at the registrar, switch on the registrar lock if it offers one, put renewals on a card that won't expire, and make sure the account is in the company's name. A .com.sg still registered to the freelancer who built the site in 2019, long since moved on, is a common way for a business to lose its own domain.
• Hosting and code accounts. On a static site, anyone who can push to the code repository or log in to Vercel, Netlify or Cloudflare can publish anything. Two-factor on GitHub and the host, remove ex-staff the day they leave, and protect the main branch so changes need approval.
• Form endpoints and serverless functions. These are the one place your own code runs per request. Check every input, add spam protection, rate-limit them, and keep API keys in the host's environment settings, never in the page. The host patches the runtime, but you choose the Node.js version and must move off old ones.
• Third-party scripts. Every chat widget, tracker and font loader runs with full access to your page. In June 2024, Sansec reported that the polyfill.io script, embedded on more than 100,000 sites, started sending some mobile visitors to scam sites after the domain changed hands. Keep the list short and review it once a year.
• The npm supply chain. A static site is built from open-source packages. In September 2025, CISA warned that a self-replicating worm called Shai-Hulud had compromised over 500 npm packages and was stealing developer credentials. Commit a lockfile, update packages on purpose rather than automatically, and use phishing-resistant two-factor on npm and GitHub.

Here's how that looks on my own site. terris.sg is about 1,900 pages built with Astro and served from Vercel. The only code of mine that runs per request is a handful of small serverless functions, mostly behind the forms, and the form ones check reCAPTCHA on the server before anything is sent. Most of my security work is the boring list above: logins, keys, packages. A static site rarely needs a paid firewall either, which I explain in does a small business need a web application firewall.

With a static website you give up instant edits, built-in logins and anything that has to be worked out on the server for each visitor, and you need a developer or a separate CMS to change content. Some of that is easy to replace. Some of it isn't.

• Edits need a rebuild. Change a price and the site rebuilds, usually in a minute or two. Fine for most businesses. Annoying if you change things twenty times a day.
• No admin panel by default. Out of the box, a static site is edited in code. Self-editing needs a CMS connected to it, which is extra setup and sometimes an extra subscription.
• No customer accounts on their own. Member areas, course libraries and customer portals need a separate service, and at that point you're running a dynamic system again.
• No real shop on its own. A few products with a hosted checkout works well. A WooCommerce-style store with stock levels, coupons and order management doesn't belong on a static site.
• Fewer people know it. Almost any freelancer in Singapore can edit WordPress. Fewer can work on Astro. If I build it, you'll want someone who can keep it going.

On a static site, forms post to a small serverless function or a hosted form service, search runs in the visitor's browser from an index built at deploy time, bookings and payments go through embedded or hosted tools, and editing happens in a CMS that triggers a rebuild. None of it needs PHP on your server.

• Forms: terris.sg sends enquiries to its own serverless functions. MET Interior's site uses a hosted form service. Either way, the form works like any other and lands in your inbox.
• Search: the build writes a search index file, and the visitor's browser searches it. Pagefind, a free static search library, says a 10,000-page site can be searched with under 300kB downloaded in total. My site and MET's both search this way.
• Bookings and payments: embed a booking tool, or link to a hosted payment page from your payment provider, so card details never touch your site. For many Singapore service businesses, a WhatsApp button does the booking anyway.
• Calculators and filters: these run in the browser. MET Interior's renovation cost calculator and its 75 project pages, filterable by property type and 21 design styles, are all part of a static build.
• Editing: a CMS stores the content and tells the host to rebuild when you hit publish. It can be a git-based editor, a hosted headless CMS or headless WordPress kept away from the public site. My guide to what a headless CMS is and when you need one compares the options.

MET Interior is the clearest example I have. I moved their 176-page site off WordPress and a page builder onto Astro, statically rendered and deployed to Vercel, in six weeks. The content was exported out of WordPress into files in the project, old URLs were mapped to the new ones, and WordPress was retired. Security wasn't on their list of reasons. WordPress was costing them page weight for every plugin the marketing asked for. Security came along with the move.

Rebuilding a small business website as a static site with me costs from SGD 2,535 for up to 10 pages, SGD 3,545 for up to 20 pages live in seven days, or from SGD 7,585 if you need a CMS you can edit yourself. Hosting stays on your own account.

The full breakdown is on my website design packages page, and the step-by-step move, including keeping your Google rankings through the URL change, is in my guide to migrating from WordPress to a static site.

Static hosting is cheap but read the terms. Vercel's free Hobby plan is for personal, non-commercial use only, so a business site belongs on Pro, which Vercel prices at US$20 a month per developer seat. Cloudflare Pages has a free plan with 500 builds a month. Either way, the account is yours, and so is the code.

Staying on a dynamic website is the right call when the site's job needs live server logic: an online shop with stock and orders, member logins, course libraries, bookings with real rules, or a team publishing several times a day. It's also right when your WordPress is current, on a patched PHP 8.3, 8.4 or 8.5, and looked after.

A rebuild costs money and time. If your site is on a supported PHP, updated monthly, with a short plugin list and a host that patched PHP2Shell on day one, it's in decent shape. Patch it, keep it patched, and work through my WordPress security checklist. A static rebuild makes sense when patching has stopped working: stuck on PHP 7.4 or 8.1, a page builder nobody can update, abandoned plugins, and nobody who remembers the admin password.

If you want to stay on WordPress and would rather not do the work yourself, start with my free PHP check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, then tell you what I find. If your host has already patched it, I'll say so and you won't need me. If it needs the update, you get a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850. If a rebuild would serve you better over the next few years, I'll quote it next to the fix so you can compare. To keep it patched afterwards, my content retainer is SGD 550 a month, month to month, covering updates, backups and security plus five hours of changes. The details are on my website maintenance page.

Yes, a static website can be hacked, but not the way most WordPress sites are: with no server code, database or login page to exploit, attackers go after the domain registrar, the hosting or GitHub account, the form functions, third-party scripts or npm packages instead. Two-factor everywhere closes most of those doors.

If it does happen, recovery is usually quick: roll back to the last good build, which hosts like Vercel and Netlify keep, then find out which account was used and lock it down.

WordPress is a dynamic website platform: PHP and a MySQL database build each page when it's requested, though cache plugins serve saved copies to most visitors. You can export a WordPress site to static files with a plugin like Simply Static, but then WordPress itself should be taken offline, or PHP is still reachable.

Headless WordPress is the in-between. The public site is static and WordPress only stores the content, ideally behind a login where visitors and bots can't reach it.

A static website doesn't need a database on its server, because every page is already a finished file before anyone visits it; the content sits in files in the project or in a headless CMS that's read when the site builds. Anything that collects data, such as enquiry forms or orders, sends it to a separate service.

That's a security win in its own right. With no database online, there's nothing for SQL injection to reach, and no database password on a server to steal.

A static website isn't ranked higher by Google for being static, because Google reads the finished HTML either way; it helps indirectly, since pages arrive complete and quickly without waiting on PHP or a database. The content and the links still decide where you rank.

The real SEO risk is the move itself. Change URLs without redirects and you lose rankings you've spent years earning. That's why every old URL gets mapped to its new address before launch, as MET Interior's did.