Your WordPress site runs PHP and queries a database every single time someone loads a page. It does not have to.
When you convert WordPress to a static site, that whole stack disappears from the public path. Pre-rendered HTML files sit on a CDN edge, and nothing executes on request.
Patchstack logged 11,334 new WordPress vulnerabilities in 2025. Static files run none of that code.
This guide covers what you gain, what breaks, and how to do it properly:
- Export tools that still work in 2026
- Plugin and command-line methods, step by step
- Replacing forms, search, and comments
- Hosting, real costs, and keeping your rankings
Plus the sites where static conversion is the wrong call.
What Is a Static WordPress Site
A static WordPress site is a set of pre-rendered HTML files, plus CSS, JavaScript, and media, served without PHP or MySQL at request time. WordPress moves behind the scenes and becomes the editing layer only.
Nothing is computed when a visitor arrives. The file already exists on disk, and the server hands it over.
That single change removes the entire backend from the public path. No wp-login.php, no plugin execution, no database lookup, no theme rendering.
WordPress itself keeps running somewhere private: a local install, a staging box, a Docker container, or a VPS behind HTTP auth. You still write posts in the block editor. The public just never touches it.
Worth knowing before you start: WordPress stores every page and post inside MySQL, not as files. The export step is what turns database rows into flat files on disk.
| Architecture | PHP Executed on Each Request? | Public Database Exposed? |
|---|---|---|
| Standard WordPress | Yes – PHP runs on every page request | Yes |
| WordPress with Page Caching | Sometimes – PHP runs only on cache misses or dynamic requests | Yes |
| Static WordPress Export | No – Only pre-generated HTML, CSS, and JavaScript are served | No |
| Headless WordPress | Yes – PHP processes API requests through the WordPress backend | Yes |
Static Export vs Page Caching
The confusion is understandable. WP Rocket, LiteSpeed Cache, and W3 Total Cache all write HTML files too.
Difference: cached HTML expires. When the cache misses, PHP fires, the database gets queried, and the whole stack wakes up.
Static export deletes the stack. There is no cache miss because there is no application server behind the file.
Static Export vs Headless WordPress
Headless WordPress keeps PHP alive. A separate frontend pulls content over REST or GraphQL, either at build time or on every request.
Build time means the output ends up static anyway. Request time means you still run a server, and WordPress is still a dependency in production.
Static export is the simpler cousin. Crawl the rendered site, save what comes back, ship the folder.
Why Site Owners Convert WordPress to Static
Security and speed drive most conversions. Patchstack recorded 11,334 new WordPress vulnerabilities in 2025, a 42% year-on-year jump, and 91% of them lived in plugins. A static site executes none of that code.
Attack surface: Patchstack found 57% of first-half 2025 vulnerabilities needed no authentication at all. No login, no stolen password, just an active plugin.
Speed of exploitation: the weighted median from public disclosure to mass exploitation sat at roughly five hours in Patchstack’s 2026 data. Patching on a weekly schedule is not a defense against that.
Volume: Wordfence blocks around 55 million exploit attempts and 6.4 billion brute force attacks monthly across its network (TDW Digital, 2025). Most of it is bots fingerprinting /wp-login.php.
Then there is the performance argument, which is less dramatic but easier to measure.
Only 32% of WordPress origins record good TTFB according to CrUX data. Flat files on a CDN edge routinely respond in under 50 milliseconds because there is nothing to compute.
Hostingstep’s November 2025 analysis of 3,087,534 mobile origins put WordPress at 46% good Core Web Vitals on mobile and 50% on desktop. Half the platform fails.
One documented case: an agency site profiled by Tapflare moved from 5.2s desktop load and a 12% Core Web Vitals pass rate to 0.8s and 94%, after rebuilding on Hugo with WordPress kept as the editor. Hosting dropped from roughly $189/month to around $25.
Cost collapse is real but oversold, honestly. The bigger operational win is that nothing on the public site ever needs an update again. If you have ever wondered why a WordPress site keeps getting flagged as not secure, removing the executable layer settles most of it permanently.
What Stops Working After a Static Conversion
Every feature that depends on PHP at request time breaks. That means comments, forms, native search, carts, logins, and anything that writes to the database from the frontend. Read this list before you commit, not after.
| WordPress Feature | What Happens on a Static Site | Can It Be Replaced? |
|---|---|---|
| Native Comments | The built-in WordPress comment form no longer works because there is no server-side processing. | Yes – Use a third-party service such as Giscus, utterances, or Commento. |
| Contact Form 7 / WPForms | Form submissions cannot be processed because the PHP handler is unavailable. | Yes – Connect the form to an external service such as Formspree, Netlify Forms, or Basin. |
WordPress Search (?s=) | The default WordPress search functionality is unavailable and may return a 404 or no results. | Yes – Implement client-side search with Pagefind, Fuse.js, or Lunr.js. |
| WooCommerce Checkout | Shopping cart, checkout, customer accounts, and dynamic inventory features stop working. | Partially – A static product catalog can use services such as Snipcart or a Shopify Buy Button for checkout. |
| Memberships / Paywalls | User authentication, protected content, and logged-in experiences are unavailable. | No – These features require a server-side application or authentication service. |
Scheduled posts deserve their own warning. WP-Cron still fires inside your private install, but the public files do not change until a new export runs.
Anything driven by Ajax calls back to admin-ajax.php also stops: live filters, infinite scroll, vote counters, real-time inventory.
Native site search is the loss people underestimate. If you previously spent time adding a search bar to WordPress, that query string approach needs a completely different mechanism once PHP is gone.
Which Tools Convert WordPress to a Static Site
Simply Static is the default choice in 2026, with 30,000+ active installs and continuous development. WP2Static is effectively abandoned. Strattic shut down on January 1, 2025 after Elementor discontinued static hosting. Shifter and wget cover the remaining cases.
| Tool | Export Method | Development Status | Starting Price |
|---|---|---|---|
| Simply Static | WordPress plugin that crawls and exports your site as static files | Active | Free |
| Simply Static Pro | WordPress plugin with deployment integrations (e.g., S3, GitHub, ZIP, and more) | Active | From $99/year |
| WP2Static | WordPress plugin that generates a static copy of your website | Limited maintenance / Community-supported | Free |
| Shifter | Managed static WordPress hosting and deployment platform | Active | Free trial or paid plans available |
wget / HTTrack | External website mirroring tools | Active | Free |
Simply Static
Free version, the sensible starting point.
- Crawls the rendered site and writes a folder or a .zip
- Rewrites URLs to absolute, relative, or offline mode
- Include and exclude rules per path
Export destinations in the free tier are limited to local directory or ZIP download. Good enough to test whether your theme survives.
Simply Static Pro
Pro adds the deployment layer, which is where most of the work actually lives.
Deploy targets: GitHub (and by extension Cloudflare Pages, Netlify, GitHub Pages), Amazon S3, BunnyCDN, SFTP.
Dynamic replacements: built-in form handling and a search index with autocomplete, which removes two of the three biggest post-conversion gaps.
Pricing starts around $99/year for a single site. The managed Static Studio tier sits above it for agencies running many client sites.
WP2Static
Elementor acquired WP2Static through the Strattic deal, and development stalled shortly after.
It still works on older setups. I would not start a new project on it in 2026, and neither would most people who have watched the repo go quiet.
Verdict: historically important, currently a maintenance risk.
Strattic by Elementor
Dead. Strattic pioneered managed static WordPress at scale from 2018, Elementor acquired it in 2022, and the platform closed on January 1, 2025.
Former customers were pushed toward standard Elementor hosting, which is not a static product. If a 2023 tutorial recommends Strattic, that tutorial is stale.
Shifter
Hosted, not self-hosted. Shifter spins up WordPress in a container, generates the static output, and serves it from its own CDN.
Scheduled deployments are built in, which solves the scheduled-post problem cleanly.
Free tier exists for testing. Paid plans start near $16/month.
HTTrack and wget
No plugin, no license, no WordPress access required beyond a public URL.
wget runs from any terminal. HTTrack gives you a GUI if command line arguments make you nervous.
Trade-off: external crawlers see only what the server sends. JavaScript-rendered content and gated URLs are invisible to them.
How to Convert WordPress to a Static Site with a Plugin
Install Simply Static, clean the site first, configure URL handling, set include and exclude rules, run the export, verify locally, then deploy. Budget an afternoon for a 200-page site and considerably more for anything with custom post types.
Step one, clean before you crawl.
Deactivate plugins that will not survive the trip. Every membership plugin, cache plugin, and admin-only tool is dead weight in a static export.
Flush all caches. A stale cache means you export yesterday’s HTML and wonder why the fix you just made is missing.
Fix your links now, not later. Broken internal links get baked into the output, so repairing broken links in WordPress before the crawl saves a second full export cycle.
Resolve mixed content too. If assets are still loading from unauthenticated http sources, those hardcoded references follow you into the static build.
Step two, URL handling.
- Absolute URLs: use when you know the final domain. Cleanest option for production.
- Relative URLs: portable across domains, fragile with deep folder structures.
- Offline mode: writes index.html into every folder. For local archives and client handoffs.
Step three, include and exclude rules.
Exclude /wp-admin/, /wp-json/, feed URLs, and any staging paths you do not want mirrored.
Add unlinked files manually. The crawler follows links, so a PDF referenced only from a form confirmation email never gets discovered.
Step four, run and read the log.
Simply Static logs every URL it fetches with a status code. A run that finishes in four seconds on a 500-page site did not do what you think it did.
Common misses: lazy-loaded images with data-src attributes, dynamically injected assets, custom REST endpoints your theme depends on.
Step five, verify locally before deploying.
Serve the folder with python3 -m http.server 8000 and click through it. Check pagination, category archives, and any page your theme builds with a custom template.
Once it works, lock down the source. Keeping the editing install private, whether by making WordPress private, moving it behind a VPN, or dropping it to localhost, is the step that actually delivers the security benefit.
How to Convert WordPress to a Static Site Without a Plugin
wget mirrors the entire public site from the command line in one pass. HTTrack does the same with a graphical interface. Neither touches your WordPress install, which makes both useful when you have a URL but no admin access.
The command that matters:
“ wget --mirror --convert-links --adjust-extension --page-requisites --no-parent https://example.com `
What each flag does:
- –mirror
: recursive, infinite depth, timestamping on
- –convert-links
: rewrites internal references to point at local files
- –adjust-extension
: appends .html so files render without a server rewrite
- –page-requisites
: pulls CSS, images, and fonts, not just documents
- –no-parent
: keeps the crawl inside the target directory
Post-crawl cleanup is where the time goes.
Query strings become filenames like style.css?ver=6.9, which some hosts refuse to serve. Hardcoded absolute URLs survive in inline scripts and JSON-LD blocks that –convert-links never inspects.
Pagination often breaks. WordPress /page/2/ paths crawl fine but land in nested folders that need a rewrite rule on the destination host.
Where the crawler approach fails outright: JavaScript-injected content, lazy-loaded galleries, and anything behind a login. wget sees raw server output, nothing more.
For a small brochure site this method takes ten minutes. For a 5,000-post blog with a custom theme, a plugin gives you far better control.
How to Rebuild WordPress Content in a Static Site Generator
Export content through the WordPress REST API, WPGraphQL, or a WXR file, convert post HTML to Markdown, map frontmatter fields, then rebuild templates in Hugo, Astro, Eleventy, or Next.js. Your theme does not come with you.
That last sentence is the whole cost of this path. Crawling preserves your design automatically. Rebuilding means recreating every template by hand.
Getting the content out:
- The WordPress REST API at /wp-json/wp/v2/posts returns paginated JSON with no plugin required
- WPGraphQL lets you request exactly the fields you need in one query
- The built-in exporter produces a WXR file, which is just XML with WordPress-specific tags
Then convert. Tools like wordpress-export-to-markdown and Turndown handle the HTML-to-Markdown step, and the generator runs a Markdown to HTML conversion in reverse at build time.
Frontmatter mapping is the tedious part. Categories, tags, custom fields, featured images, author names, and publish dates all need to land in the right YAML keys or your templates render blanks.
| Static Site Generator | Primary Language | Best Use Case |
|---|---|---|
| Hugo | Go | Large content archives and documentation sites where fast build times are a priority |
| Astro | JavaScript / TypeScript | Content-focused websites that ship minimal JavaScript by default |
| Eleventy (11ty) | JavaScript | Developers who want maximum control over the generated HTML and templating |
| Next.js | React (JavaScript / TypeScript) | Static websites that also need dynamic application features, hybrid rendering, or server-side capabilities |
Hugo
Speed king. A single Go binary, no nodemodules, thousands of pages built in seconds.
Hugo has demonstrated streaming builds at the million-page scale, which no JavaScript generator matches.
Templating uses Go templates. They are not fun to learn.
Astro
Astro ships zero JavaScript by default and has become the common recommendation for content-heavy migrations.
It overtook Eleventy, Jekyll, and Hugo in Netlify’s State of Web Development survey, and Astro 5 added Server Islands and a Content Layer for pulling from external sources.
Practical benefit: the Content Layer reads a WordPress API directly, so you can skip the Markdown conversion entirely.
Eleventy
Deliberately un-opinionated. Eleventy supports 10+ template languages and imposes almost no structure on your project.
The trade: more freedom, more decisions, longer setup than Astro.
Version 3.0 brought full ESM support. Popular with government and accessibility-focused teams for a reason: the output HTML is exactly what you wrote.
Next.js and Gatsby
Next.js handles static export through its App Router and makes sense when the site also needs application features.
Gatsby was the dominant WordPress-to-static choice around 2019 through 2021. It has faded, and starting a new migration on it in 2026 is hard to justify.
Rule of thumb: pick Next.js if you already write React daily. Otherwise Astro or Hugo will get you there faster.
Where to Host a Static WordPress Site
Cloudflare Pages, Netlify, Vercel, GitHub Pages, and Amazon S3 with CloudFront all serve static files from an edge network. Cloudflare Pages is the strongest free tier because static asset bandwidth is unmetered. Netlify caps free bandwidth at 100 GB.
| Hosting Platform | Free Tier | Considerations |
|---|---|---|
| Cloudflare Pages | Free tier with generous bandwidth and monthly build limits | Limits apply to project resources (such as concurrent builds and file counts); check the latest platform limits. |
| Netlify | Free tier with bandwidth and build-minute allowances | Additional bandwidth and build usage may incur charges on paid plans. |
| GitHub Pages | Free hosting for static websites | Best suited for personal, open-source, and project sites. Repository, bandwidth, and feature limitations apply. |
| Amazon S3 + CloudFront | No permanent free tier (AWS Free Tier may apply for eligible accounts) | Requires manual setup and deployment unless paired with a CI/CD pipeline or deployment tool. |
The Netlify billing change matters. Netlify moved to credit-based billing in September 2025, and exceeding limits on the free plan pauses your sites until the next cycle. Cloudflare keeps serving.
Cloudflare Pages Pro runs about $20/month for 5,000 builds and 5 concurrent builds. For an agency with 20 client sites, that single account covers everything.
Redirects and headers are configured per host, not per site.
- Netlify: a redirects
file ornetlify.toml
- Cloudflare Pages: redirects
andheaders
- Vercel: vercel.json
- S3: CloudFront functions or bucket routing rules
SSL is automatic everywhere now. Point the domain, wait for the certificate, done.
Now the part people forget: the WordPress install still needs a home.
Options in rough order of popularity: LocalWP on your laptop, a Docker container, or a cheap VPS behind HTTP auth. Agencies running multiple WordPress installs usually keep them on one private box and deploy outward to separate static hosts.
How to Replace Forms, Search, and Comments on a Static Site
Forms move to an external endpoint like Formspree or Netlify Forms. Search moves to a build-time index like Pagefind. Comments move to Giscus, Disqus, or Commento. Each replacement is a script tag and a config file, not a rebuild.
| Dynamic Feature | Static-Site Replacement | Free Option |
|---|---|---|
| Contact Forms | Formspree, Netlify Forms, Basin | Free tiers available (submission limits vary by provider) |
| Site Search | Pagefind, Fuse.js, Lunr.js | Yes – Free and open source (MIT License) |
| Comments | Giscus, Commento, utterances | Giscus and utterances are free with a GitHub account; availability varies by provider |
| Checkout / E-commerce | Snipcart, Shopify Buy Button | No permanent free tier; pricing varies by provider (for example, transaction-based or monthly plans) |
Forms. Formspree’s free plan allows 50 submissions per month, Personal runs $15/month for 200, and Professional $30/month for 2,000.
Netlify Forms gives 100 free submissions monthly but only works on Netlify deployments. Platform lock-in, though for a brochure site nobody cares.
You keep full control of the markup either way, so styling the form with CSS is entirely yours and none of the accessibility work that makes forms usable is lost in the switch. Contact Form 7 markup, honestly, was never great on that front.
Search. Pagefind is the one I would pick without much deliberation.
It runs after the build, indexes the rendered HTML, and shards the index so the browser fetches only what it needs. A 10,000-page site produces a total network payload under 300KB including the library. Most sites land nearer 100KB.
Algolia’s free tier covers 10,000 records and 10,000 operations per month, and DocSearch runs $49/month for commercial sites. A 500-post blog with real traffic burns through the free allowance quickly.
Trade-off worth knowing: Pagefind runs entirely in the browser, so you get no query logging and weak typo tolerance. Algolia handles both.
Comments. Disqus charges $10/month per site to remove its ads, and the script is heavy enough to dent your Core Web Vitals.
Giscus stores threads in GitHub Discussions. No ads, no tracking, no cost. The friction is that commenters need a GitHub account, which is fine for a dev blog and useless for a bakery.
Commento and Comentario are the self-hosted route, starting around $10/month hosted. If you are migrating threads out, clearing the old WordPress comments afterward keeps the editing install tidy.
Ecommerce. Snipcart charges roughly 2% per transaction with a $10 to $20 monthly minimum. Shopify’s Buy Button sits at $9/month plus payment processing.
Analytics. Server logs are gone, so tracking moves fully client side. Plausible starts at $9/month for 10,000 pageviews with a script under 1KB, against GA4’s 45KB+. Fathom starts near $14/month.
How to Keep Rankings Intact During the Conversion
Match URLs exactly, map every path that changes to a 301, generate the sitemap at build time, carry canonical tags and structured data into the exported HTML, and crawl the result before launch. Roughly 60% of site migrations lose organic traffic (Ahrefs, 2025).
That number is the whole reason this section exists.
An analysis of 892 migrations cited by Search Engine Journal put the average time to regain pre-migration traffic at 523 days. A separate 2025 study found 17% of migrations had still not recovered after 1,000 days.
The failure mode is almost always the same: incomplete or chained redirects.
One documented May 2025 replatform saw daily organic clicks fall from around 1,200 to 500 because top URLs were mapped to chains instead of direct 301s.
Trailing slashes will bite you. WordPress serves /about/ by default. Some static hosts serve /about. Pick one, enforce it in the host config, and 301 the other.
Do not change URL structure during the same launch. If you have wanted to remove /category/ from your URLs, do it as a separate release with its own redirect map and its own recovery window.
Sitemaps need a new source. Yoast and Rank Math generate sitemap.xml through PHP, which no longer runs. Most export plugins produce a static sitemap, and every major generator has a sitemap integration.
Check your metadata before the crawl, not after. Any duplicate title tags sitting in WordPress get baked permanently into the exported files.
404 handling works differently. There is no PHP fallback, so the host serves whatever you tell it to serve. Build a 404.html and register it in your host config. The custom 404 page you designed in WordPress can be exported and reused directly.
Permalink quirks travel too. If permalinks were already misbehaving before the export, the crawler faithfully copies the broken structure.
Post-launch verification, in order:
- Full Screaming Frog crawl of the static build on staging
- Compare the URL list against your pre-migration export
- Check for redirect chains, not just redirect presence
- Validate JSON-LD survived the export
- Submit the new sitemap and watch Search Console index coverage for 14 days
How to Publish New Content After the Site Is Static
Write in WordPress, trigger an export, deploy the output. A webhook can automate the last two steps so publishing feels close to normal. The gap between hitting publish and the page going live equals your build time.
That delay is the single biggest workflow change, and it is what most editors complain about first.
Build times by generator and page count:
| Number of Pages | Hugo (Typical Build Time) | Astro (Typical Build Time) |
|---|---|---|
| 1,000 | Under 1 second | 20–60 seconds |
| 10,000 | 2–5 seconds | Several minutes |
| 50,000 | 3–5 minutes | 25–40 minutes |
Plugin-based crawl exports behave differently. Simply Static fetches each URL over HTTP, so a 2,000-page site takes minutes, not seconds, and the bottleneck is your own server.
Scheduled posts need a scheduled build. WP-Cron fires inside the private install, the post goes live there, and the public site stays unchanged until something triggers an export.
Fix it with a cron job that calls your host’s build hook, or use Shifter, which schedules deployments natively.
Incremental export vs full rebuild:
- Incremental: only changed URLs are re-crawled and pushed. Fast, and occasionally misses a template change that affected every page.
- Full rebuild: slow, boring, always correct. Run one weekly.
Preview still works normally, which surprises people. Draft previews render from the live WordPress install, so sharing a draft page for review behaves exactly as it did before, as long as reviewers can reach the private editing environment.
Watch your build allowance. Cloudflare Pages gives 500 builds per month on the free plan with a 20-minute timeout per build. Publish 15 times a day and you are fine. Automate a rebuild on every plugin save and you are not.
What a Static WordPress Site Costs to Run
A small static WordPress site runs $0 to $150 per year against $300 to $600 for managed WordPress hosting. Savings come from hosting, not tooling. The export plugin, form service, and search index are usually the only line items that appear.
| Feature | Free Option | Paid Option |
|---|---|---|
| Static Hosting | Cloudflare Pages | Cloudflare Pages Pro (paid plans available) |
| Static Export Tool | Simply Static (Free) | Simply Static Pro |
| Forms | Formspree (free tier) | Formspree (paid plans for higher submission limits) |
| Site Search | Pagefind | Algolia (paid plans available) |
| Analytics | Google Analytics 4 (GA4) | Plausible Analytics (paid plans) |
The realistic small-site total is $0. Cloudflare Pages, free Simply Static, Pagefind, Giscus, and GA4 add up to nothing beyond your domain registration.
A more typical business setup lands near $250 to $400 per year: Simply Static Pro at $99, Formspree Personal at $180, Plausible at $108.
Managed tiers exist if you would rather not run infrastructure. Simply Static’s Static Studio runs $49/month, Simply Static Pro is $129/year, and Shifter’s paid plans start around $16/month.
The Tapflare case study I mentioned earlier put the before and after at roughly $189/month versus $25/month after moving to Hugo with WordPress kept as the editor.
The hidden cost is labor. A crawl-based export is a few hours. A generator rebuild is a template project, and WordPress developer rates apply exactly the same way they would to any redesign.
Your private WordPress environment is usually free (LocalWP, Docker) or about $5 to $12/month on a small VPS.
When a Static Conversion Is the Wrong Move
Skip the conversion if your site has user accounts, live inventory, faceted filtering, daily publishing by non-technical editors, or more than 50,000 URLs. Static export removes the features those sites are built on, and no third-party service fully replaces them.
Membership and logged-in states. There is no session on a static site. MemberPress, Restrict Content Pro, and paywalls have nothing to hook into. This one is not negotiable.
Active WooCommerce stores. WooCommerce holds roughly 31% of the ecommerce platform market, and about one in three online shops runs on it. Cart, checkout, account pages, and live stock levels all require a server.
You can bolt Snipcart onto a static catalogue. You cannot statically export a working WooCommerce store and expect orders to arrive.
Multi-author teams publishing daily. Every publish becomes a build. Editors who are used to seeing a typo fix go live in three seconds will not enjoy waiting for a deploy queue.
Sites over 50,000 URLs. Build times stop being a footnote. Astro takes 25 to 40 minutes at that scale, which exceeds Cloudflare Pages’ 20-minute build timeout, and the free plan caps out at 20,000 files per site.
Directory and listing sites. Faceted filtering multiplies into thousands of parameter combinations. Anything driven by a dynamic query loop has to be rebuilt as client-side filtering or pre-rendered as separate pages, and neither is cheap.
Here is the middle ground almost nobody mentions in these articles.
Full page caching plus a CDN gets you most of the speed with none of the workflow change. Aggressive caching with Cloudflare in front of a decent host closes a large part of the TTFB gap, and everything on the site keeps working.
Static conversion is the right call when your site is genuinely a publication: content in, HTML out, no user state. It is a poor call when the site is an application wearing a CMS. There are reasons WordPress dominates as a CMS at 43% of the web, and most of those reasons involve the exact features a static export deletes.
FAQ on Convert WordPress To Static Site
Can I still use WordPress after the conversion?
Yes. WordPress becomes your editing layer, running locally, in Docker, or on a private VPS. You write posts in the block editor exactly as before, then export and deploy the static files.
Will my rankings drop after a static conversion?
Only if URLs change. Keep paths identical, carry over canonical tags and structured data, and generate a sitemap at build time. Ahrefs found 60% of migrations lose traffic, almost always from broken redirect mapping.
How long does a static export take?
Plugin exports crawl each URL over HTTP, so a 500-page site takes a few minutes. Hugo builds 10,000 pages in under 5 seconds. Astro needs several minutes at that scale.
Do contact forms still work?
Not natively. The PHP handler behind Contact Form 7 or WPForms is gone. Point the form at Formspree, Netlify Forms, or Basin instead. Free tiers cover 50 to 100 submissions monthly.
Can WooCommerce run as a static site?
No. Cart, checkout, accounts, and live inventory all need a server. Snipcart or a Shopify Buy Button adds checkout to a static catalogue, but a full store belongs on standard WordPress hosting.
What is the best free tool for this?
Simply Static, with 30,000+ active installs and ongoing development. WP2Static stalled after Elementor acquired it. For a no-plugin approach, wget mirrors any public site from the command line.
Is static export just aggressive caching?
No. WP Rocket and LiteSpeed Cache write HTML that expires, and PHP fires again on every cache miss. Static export removes PHP and MySQL from the public path permanently.
Where should I host the static files?
Cloudflare Pages offers unlimited static bandwidth free, with 500 builds monthly. Netlify caps free bandwidth at 100 GB with expensive overages. GitHub Pages works for public repositories and non-commercial projects.
How do I add site search back?
Pagefind indexes your rendered HTML after each build and runs entirely in the browser. A 10,000-page site ships under 300KB total. Algolia costs $49 monthly for commercial sites.
Do I still need to update plugins?
Update the private install for your own safety, but nothing on the public site executes plugin code. That removes the five-hour window between vulnerability disclosure and mass exploitation Patchstack recorded in 2025.
Conclusion
The decision to convert WordPress to a static site comes down to one question: does anything on your public pages need a session? If not, flat file delivery from the edge wins on every measurable axis.
Start small. Export a staging copy with Simply Static, serve it locally, and click through the pages your theme builds with custom templates.
That single test tells you more than any comparison table. Broken lazy-loaded images and missing custom post types surface within ten minutes.
Then wire up the deployment pipeline: a build hook, a redirect file, a 404.html.
Keep the editing install private, and treat your first full rebuild as the baseline.
The maintenance you stop doing is the real return.


