From WordPress to static in a morning: a high-level runbook

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were patched on 21 October. Both let an attacker run code on the server without logging in, and both are rated 9.2 out of 10 for severity. The security firm watchTowr has seen them exploited since the day the patches came out, although CISA had not yet listed them as known-exploited when this was written. Every WordPress site runs on PHP, so every WordPress site needs patching this week.

Patching closes this hole. The next one will need patching too, along with the plugins, themes and WordPress itself. We moved smartible.com.au off WordPress well before this, because it has too many moving parts to keep supported. For most corporate websites the better answer is to take PHP out of the picture, and this is the high-level runbook for doing that with Azure Static Web Apps.

Why a static site has nothing to patch

Most corporate sites are information pages that change a few times a month. They do not need a database, plugins or PHP running every time someone visits.

A static site is built once into plain HTML and served from a content delivery network, which keeps copies close to visitors. Nothing runs on a server when a page is requested, so there is no application for an attacker to break into and no PHP or plugin updates to chase. Forms are the one moving part, and they are handled separately (step 3).

1. Capture the live site

Before changing anything, record what search engines and visitors rely on today.

• Crawl the public sitemaps and save each page's HTML, images and documents.
• Record every address, page title, meta description and canonical tag.
• List every form and where its submissions go.

This list becomes the test the new site must pass.

2. Convert to Next.js

• Convert the captured pages into Next.js pages, with the content in Markdown files and one component for each page-builder block. An AI coding assistant does most of this well when it has the captured pages and clear rules to follow.
• Keep every address identical, including trailing slashes. Recreate WordPress's redirects too, including the quiet ones, such as short addresses that forward to the full page.
• Set Next.js to export plain HTML with output: 'export'.

3. Replace the forms

• Contact forms send to a small serverless function, managed by Static Web Apps, which emails the submission through a mail provider's service.
• Add basic bot protection: a hidden field that only bots fill in, a check that the request came from your own site, a minimum time to fill in the form, and a limit on submissions.

4. Build the pipeline

On every change to the main branch, the pipeline:

1. Builds the static site.
2. Serves it locally and compares every page with the live site: status, title, canonical and robots tags, and the sitemap.
3. Publishes to a staging environment and checks it again.
4. Only then publishes to production.

Rolling back is redeploying an earlier version, which takes minutes.

5. Create the Azure side

The Azure set-up is a handful of commands:

az group create -n rg-web -l australiaeast
az staticwebapp create -n my-site -g rg-web --sku Standard
az staticwebapp secrets list -n my-site --query properties.apiKey -o tsv
az staticwebapp appsettings set -n my-site --setting-names KEY=value

The third command prints the deployment key: store it as a secret in your pipeline, never in the code. The fourth holds settings such as the mail provider's key. The Standard plan includes custom domains, free certificates and 100 GB of bandwidth, and costs a fixed amount per site each month. Check Microsoft's pricing page for the current figure in your region.

6. Go live

• Add your domain to the Static Web App and prove you own it with the code Azure gives you.
• Point your DNS records at the Static Web App, following Microsoft's guide for the main domain and the www address.
• Choose one address as the main one, so the other redirects to it.
• Resubmit the sitemap in Google Search Console.

Before you switch over

• Crawl the new site first. A faithful copy brings the old site's broken links with it. Find and fix them before go-live.
• Test the forms end to end. Send a real enquiry from the staging site and confirm it arrives.
• Keep the old site. Take it offline but keep it intact for a few weeks, so you can switch back if something was missed.

Keeping your search rankings

Search engines rank a page on its address and its content. They cannot see whether WordPress or a static build produced it. Keep both the same and the rankings carry over. That is why step 1 records every address, title, description and canonical tag, and why the pipeline in step 4 compares each one with the live site before anything is published. Two things lose rankings: an address that changes without a redirect, and a page that goes missing. The comparison catches both. A static site also loads faster, and page speed counts in your favour.

What you end up with

The same site at the same addresses, with almost no downtime during the switch. There is no PHP, database or plugin left to patch. Every change is tested before it goes live, and any change can be undone in minutes.

If your site is still on WordPress, patch PHP to the fixed version today, then plan the move. If your business needs more than a website, a Specification Sprint is where we would start.