WordPress to Static Site: When and How to Migrate (October 2026)

Patching WordPress stops making sense when the site can't run on a supported PHP version, nobody is responsible for updating it, and the content only changes a few times a year. If two or more of these describe your site, I'd price a move before paying for another round of fixes:

• It's stuck on PHP 7.4, 8.0 or 8.1 because a plugin, theme or page builder breaks on anything newer. PHP says "PHP 8.1 and older no longer receive updates from the PHP project", and PHP 8.2 reaches end of life on 31 December 2026. My guide to PHP end-of-life dates has every version in one table.
• Something it depends on is abandoned. A page builder or plugin with no update in a year is what breaks at the next PHP upgrade.
• Nobody owns it. The person who built it in 2019 has left and nobody is sure who has the hosting login.
• It's mostly a brochure. Services, an about page, a gallery, a contact form, and new content four or five times a year.

None of this is a knock on WordPress. Its core is well maintained. The risk lives in the PHP version underneath and the plugins on top, and each needs a person keeping it current. When there isn't one, the site gets older every month whether anyone looks at it or not.

You should stay on WordPress and keep it patched if several people edit the site every day, it runs memberships or customer logins, or it's a large WooCommerce store, because those jobs need code running on the server for every visitor. This is what WordPress is good at, and rebuilding it elsewhere costs more than looking after it properly.

• Heavy daily editing: a school posting notices, a team publishing several articles a week with drafts and approvals.
• Members-only areas: online courses, directories, client portals.
• A big WooCommerce store. If you want out of WooCommerce, the usual next step is a hosted platform such as Shopify, not a static site; my list of WordPress alternatives says who patches what on each.
• A recent, looked-after site already on PHP 8.3 or 8.4 with current plugins. Patch it and get on with your week.

For these sites the fix is a patched PHP version and a routine. On shared hosting your host updates PHP, and some, SiteGround among them, already have at no charge; if yours has, you don't need me. On a VPS somebody has to do it, and a security plugin can't do it for you. Not sure if patching is still viable? Send me your web address for a free PHP check and I'll tell you which PHP version it runs, what it's built on and how old its theme and plugins are. If it needs the update, you get a fixed price in writing before I start, from SGD 850, covering the PHP update and anything it breaks, with a rebuild quoted next to it so you can compare: Starter from SGD 2,535, One Week Website SGD 3,545, Growth from SGD 7,585. Upkeep after that is SGD 550 a month on my website maintenance retainer, covering core, plugin, backup and security work plus five hours of changes.

There are two ways to convert WordPress to a static site: export WordPress to static HTML with a plugin and keep WordPress hidden, or rebuild the site on a static site generator such as Astro and retire WordPress. Both put plain HTML, CSS and images on a CDN, with no PHP and no database running when someone visits. That's why a PHP bug can't reach the public site. I cover the mechanics in static vs dynamic websites.

A static site still has things to protect: your registrar and DNS logins, the hosting or GitHub account it deploys from, whatever receives your forms, third-party scripts, and the npm packages it's built with. It just has no PHP runtime, database or public WordPress login.

Simply Static is the most used plugin for exporting WordPress to static HTML: the free version generates the whole site in one click as a ZIP file or folder you upload to any static host. Its WordPress.org listing shows 30,000+ active installs and an October 2026 update. The paid tiers on Simply Static's pricing page add what a business site needs:

• Pro, US$99 a year per site: deploys to GitHub, Netlify, Cloudflare Pages, AWS S3 or BunnyCDN, re-exports only changed pages, and adds working forms, search and comments.
• Studio, US$12 a month per site: hosts both WordPress and the static site, and Simply Static says the WordPress side "remains offline until needed".

WP2Static, which older guides recommend, had its WordPress.org listing closed permanently in August 2020 at the author's request, and its GitHub repository last bumped its version in January 2023. I wouldn't start a project on it.

Simply Static's own FAQ is clear about the limits: "With the free version, these features won't work on your static site (they require server-side processing)", meaning forms, search and comments. Three more catch people out:

• Every edit means a fresh export. Change your phone number in WordPress and the live site stays the same until you export again.
• The page builder's weight comes along. The export is a snapshot of what WordPress outputs, heavy scripts included.
• WordPress still exists. The copy runs no PHP, but the install that made it does. On a public server PHP2Shell can still reach it, and a strong WordPress password won't help: PHP says its demonstrated mod_php exploit triggers "before any application code runs".

So get WordPress off the public internet. Run it on your own computer with the free Local by WP Engine app, or put it behind a gate that works before PHP does, like an IP allowlist or Cloudflare Access, and keep it patched anyway. Done that way, this route suits a small site you want off a risky server this week while you decide what to do properly.

Rebuilding on Astro means moving your WordPress content into a new site that Astro turns into static HTML at build time, so WordPress can be switched off for good. Astro is an open-source framework for content sites. It ships no JavaScript by default and adds it only where a page needs it, such as a calculator or a filter.

Astro's WordPress migration guide gives two content options: keep WordPress as a headless CMS behind the new site, or move the posts into Markdown files with a community export tool. Which fits depends on who edits after launch (step 7 below).

The trade is simple. A rebuild gets you a design without page-builder weight and no plugins to update. It costs more upfront, and structural changes go through a developer. If you were going to rebuild your website anyway because it looks dated or brings in nothing, this is the route where the security fix comes free with the work.

A WordPress migration that keeps your Google rankings runs in ten steps, from crawling the old site and mapping every URL, through rebuilding forms and tracking, to watching Search Console and retiring the old install. Most of it follows Google's site-move documentation.

1. Inventory the old site. Combine the XML sitemap, a Screaming Frog crawl (free up to 500 URLs), the Search Console Pages report and 12 months of top landing pages from Analytics. Flag every page with traffic or backlinks.
2. Export the content. Tools > Export in WordPress downloads a WXR file with your posts, pages, custom post types, comments, custom fields, categories and tags. Copy the wp-content/uploads folder for the images. Page-builder pages often export as shortcodes, so I take that text from the live page.
3. Map every URL and set up 301 redirects. Keep URLs the same wherever you can. Anything that moves gets a permanent server-side redirect to its closest match, in one hop, never a pile of them dumped on the homepage. Google says to keep redirects "for as long as possible, generally at least 1 year". Redirects in Vercel's vercel.json are 308s by default, which Google treats as permanent like a 301. One catch: with no host adapter, Astro's redirects come out as meta refresh pages, so put them in the host's config.
4. Carry over titles, meta descriptions and schema from Yoast or Rank Math word for word, with canonicals and Open Graph images. Improve them once the move has settled, so you can tell which change did what.
5. Rebuild the forms and decide where submissions go. A static page posts to a small serverless function or form service that emails you; mine runs on Vercel and checks reCAPTCHA first. Then check the old database: plugins like Gravity Forms keep every entry, and years of enquiries are personal data. My note on PDPA breach duties after a website hack explains why a forgotten database matters.
6. Re-install analytics and conversion tags. Whatever the old site fired (GA4, Google Ads conversions, Meta Pixel, Clarity) must fire on the new one, tested before launch.
7. Choose how you'll edit: no CMS (your developer edits files), a headless CMS such as Sanity, Storyblok or Decap, or headless WordPress kept away from the public site. My headless CMS guide covers which suits whom.
8. Run a launch checklist. Lower your DNS TTL to a few hours at least a week ahead, as Google suggests. On the day, remove any staging noindex or robots.txt block, test every redirect, send a test enquiry through every form, and check HTTPS on www and the bare domain.
9. Watch Search Console. Submit the new sitemap, inspect your ten most important URLs, and check the Page indexing report weekly for a month. Use the Change of Address tool only if the domain changed; Google says you need it only "when moving from one domain or subdomain to another".
10. Retire the old WordPress. Back up the files and database offline, then delete the install. A forgotten copy at old.yourdomain.com is exactly what a PHP bug finds.

Google is upfront that visibility "may fluctuate temporarily during the move". A planned move wobbles for a few weeks and settles. One with no redirects quietly loses every page other sites linked to.

MET Interior's website moved from WordPress with a page builder to Astro, statically rendered and deployed to Vercel, as a 176-page site in six weeks. It's my clearest example of when leaving makes sense, partly because the WordPress site it replaced was mine.

I rebuilt MET's site in 2024 on WordPress with a page builder, and it did its job for two years. Then the business outgrew it. MET has designed over 500 Singapore homes since 2011, and every page-builder section carried more script than the content inside it, so each plugin the marketing asked for made the site heavier. They wanted a filterable portfolio, a guide library, a cost calculator and pages for upcoming BTOs. On that stack, the site would have got slower the more useful it became.

The new site has 75 project pages filterable by property type and by 21 design styles, 12 landing pages for upcoming BTOs, a renovation cost calculator, 30+ cost and renovation guides, and site-wide search. Here's how the six weeks went:

In a neutral ranking check on 19 October 2026, the site was #4 on phones in Google Singapore for "landed property interior design singapore". The full story is in the MET Interior case study.

Moving WordPress to a static site with me starts at SGD 2,535 for a rebuild of up to 10 pages, and moving your content and planning the redirects are included. The package depends on page count and whether you need to edit the site yourself:

A blog worth keeping puts you in Growth, the tier with the blog and the CMS. A site MET's size is quoted on its own scope. My website design packages page lists what each tier includes, and my guide to website costs in Singapore shows how they compare with the market.

Not included: hosting, which stays on your own account, and your domain, which stays in your name. Static hosting is cheap. Cloudflare Pages' free plan allows 500 builds a month, and Vercel Pro is US$20 a month, since Vercel's free Hobby plan is for personal, non-commercial use. Some costs stop, too: premium plugin and page-builder licences, and the old PHP hosting plan.

If you're weighing a redesign against a full rebuild, my website redesign vs rebuild guide walks through that decision.

You shouldn't lose Google rankings when you move off WordPress, as long as every page that ranks keeps its URL or 301-redirects to its closest match, and its title, description and content come across intact. Expect a few weeks of movement: Google says that with URL changes, "it can take a few weeks or more" for a medium-sized site's new URLs to replace the old ones.

What loses rankings is avoidable: deleting pages that had backlinks, redirecting everything to the homepage, rewriting every title on launch day, and a noindex tag left over from staging.

You can edit a static site yourself if it's built with a CMS: a headless CMS such as Sanity or Decap, or headless WordPress, gives you an editing screen, and publishing triggers a fresh build, usually within minutes. In my packages, a CMS you edit yourself comes with Growth. Starter and the One Week Website don't have one, so changes go through me. On the plugin route, you edit in WordPress and export again.

Your WordPress blog posts move to the new site at the same URLs: they're exported from WordPress as an XML file, converted to Markdown or loaded into a headless CMS, and published at the addresses they already rank on. Images come across from the uploads folder, and each post keeps its title, meta description and date.

Comments are the one decision. A static site can't take new ones without a third-party service, so the usual choice is to keep the old comments and close new ones, or drop them if they were mostly spam.

A WordPress to Astro migration takes 2 to 3 weeks for a site of up to 10 pages, 7 days on the One Week Website, and 3 to 5 weeks for a Growth site with a CMS and a blog. Bigger sites take longer: MET Interior's 176 pages took six weeks from audit to launch.

Speed matters most when the old site has already failed. J Tech Eng Services' previous site had completely broken down, bad news for a contractor whose clients vet suppliers online, and their new Astro site went live in 4 weeks. A plugin export of a small brochure site takes an afternoon, but the WordPress behind it still needs dealing with.

A static HTML export of WordPress is safe from PHP2Shell on its own, because the exported files run no PHP, but the WordPress install that made the export is not. If that install stays on a public server, it's exposed like any other WordPress site, and a security plugin can't be relied on to stop a flaw that triggers before WordPress's code runs. Keep it offline, or gated and patched.