Convert WordPress to Static HTML: Every Method Compared (2026)

This is the sibling article to our pillar guide, how to migrate WordPress to a static site. That one covers the whole move end to end. This one zooms in on the part people actually search for: the conversion tooling. Which exporter should you use, what does each one produce, and what happens the morning after.

What "converting WordPress to static HTML" actually means

A normal WordPress page doesn't exist until someone asks for it. A visitor hits a URL, PHP wakes up, queries the MySQL database, runs your theme and every active plugin, and assembles an HTML page on the spot. Then it throws it away and does it again for the next visitor.

Converting to static HTML means doing that work once, up front, and saving the result as ordinary .html files with their CSS, images and JavaScript next to them. The web server then just hands those files over. No PHP, no database, no plugins at request time. That's why static pages load in milliseconds and why there's almost nothing left to hack, the two big reasons people make the move (more in the real benefits and weaknesses of static websites).

The catch is in the word "once". A static file is a photograph of your site at the moment you exported it.

The four methods, at a glance

Method 1: Simply Static or Staatic (the plugin route)

This is what most people mean by "convert WordPress to static". You install the plugin in wp-admin, point it at a destination, and it walks your site rendering every page to a file.

1. Back up first. A full backup of files and database, before you touch anything.
2. Install the plugin from Plugins → Add New and open its settings.
3. Set the destination URL to the domain the static site will live on. This is the step people skip, and it's why exports so often ship with absolute links still pointing at the old WordPress domain.
4. Add anything the crawler can't find. Pages only reachable from a form, a JavaScript menu or a PDF won't be discovered by following links. Add them to the "additional URLs" list by hand.
5. Exclude what shouldn't ship: /wp-admin, staging pages, thank-you pages you don't want indexed.
6. Run the export and download the ZIP.
7. Upload to a static host such as Cloudflare Pages or Netlify and point your domain at it.

The free tier exports the entire site every time. On a 40-page brochure site that's a couple of minutes. On a 500-page site with heavy image galleries it can take a long while and time out, which is what the paid tiers' incremental builds exist to solve.

Method 2: WP2Static (the developer pipeline)

WP2Static does the same core job but is built for people comfortable with a build process: it has add-ons for deploying straight to S3, Netlify or a git repository, and hooks for post-processing the output. If you're a developer who wants "publish in WordPress, deploy static automatically", this is the closest thing to that. If you're a site owner who just wants faster pages, it's more machinery than you need.

Method 3: Crawl it with wget or HTTrack

You don't strictly need a plugin at all. Any site that's publicly reachable can be mirrored by a crawler. The classic one-liner:

wget --mirror --convert-links --adjust-extension \
     --page-requisites --no-parent https://example.com/

--convert-links rewrites internal links to work locally, --adjust-extension adds .html where needed, and --page-requisites pulls the CSS, images and fonts each page needs. HTTrack does the same with a GUI.

This is excellent for archiving a site you're about to switch off, and it's how you keep a legal record of what a page said on a given date. It's a poor foundation for a site you still run: the output is a tangle of generated filenames, the URLs often gain .html extensions your rankings don't know about, and there's no structure to edit.

Method 4: A managed migration

The other route is not to export at all, but to rebuild the site as clean static pages, keeping the look, the content and the URLs, and then leave WordPress behind entirely. That's the difference between a snapshot and a migration, and it's the one thing the exporters can't do. We cover it in depth in the pillar migration guide, and you can see it on a real site in the CSR Tools case study, 200+ pages moved off WordPress and about 7× faster.

Export, then what? The eight things the ZIP doesn't handle

This is the section every "how to convert WordPress to static HTML" tutorial ends before reaching. You have a folder of HTML files. Here's what's now your problem.

1. Contact forms. Contact Form 7, Gravity Forms, WPForms all post to PHP. Nothing receives them any more. Replace with a form service (Formspree, Basin) or a hosted handler, and test an actual submission before you cut the domain over.
2. Site search. WordPress search is a database query. You need a static index instead (Pagefind, Lunr, Algolia) or a link to Google site search.
3. Comments. Move to Giscus, Disqus or drop them. Existing comments are baked into the exported HTML as read-only text, which is usually fine.
4. The sitemap. Yoast and Rank Math generate sitemap_index.xml in PHP. It vanishes with the export. You must ship a real static sitemap.xml and resubmit it in Search Console.
5. Absolute URLs. Hard-coded https://oldsite.com/... links inside post content, theme templates and inline CSS survive the export and will either 404 or silently keep sending traffic to the old install. Search the exported files for the old domain.
6. Login and member areas. Anything behind wp-login.php is gone. If you gate content, static HTML alone can't do it.
7. Scheduled and dynamic content. Scheduled posts never publish. "Latest posts" widgets, popular-post counters and dynamic year stamps freeze at the export date.
8. Redirects. Your redirect plugin's rules lived in the database. They need to be re-created at the host or CDN level, and so does every URL the conversion itself changed.

Does converting to static HTML change your URLs?

It can, and this is where SEO gets lost. Watch for these:

Google's own guidance on site moves with URL changes is the reference here: 301 redirects pass nearly all of a page's authority to the new address, so keep them live for at least a year. If you're also changing host at the same time, read moving WordPress to a new host first, and don't do both moves in one night.

Editing a static HTML site after the conversion

Here's the honest trade. A plugin export gives you speed and security immediately, but the editing story gets worse, not better. You now have two systems: WordPress, which you still install, update and secure because it's your editor, and the static output, which is what the world sees. Every typo fix is edit, re-export, redeploy.

There are three ways out of that:

• Edit the HTML directly. Fine if you're technical and the site rarely changes. Not fine if someone else has to update the opening hours.
• Rebuild in a static site generator such as Astro, Hugo or Eleventy, with a git-based CMS on top. Clean and fast, but it's a development project, not an afternoon.
• Use a managed platform that keeps the static site editable. This is what ShiftPress's AI editor does: your site lives as static pages, and you change it by describing what you want ("swap the hero photo", "update the prices on every service page"). You see a preview of every affected page, approve it, and it publishes, with one-click rollback. No WordPress underneath.

That last option is also why we don't recommend bolting an AI plugin onto WordPress instead, which we argue out in connecting Claude to WordPress and WordPress and AI.

Which method should you pick?

• Archiving a site you're retiring? wget. Two minutes, done.
• A small site that genuinely never changes (an event page, a one-pager)? Simply Static free tier.
• You're a developer and want a publish pipeline? WP2Static, or Simply Static Pro with incremental builds.
• A live business site that people keep editing? Don't export. Migrate. An export just moves the maintenance problem, it doesn't remove it, and you'll still be paying for PHP hosting and patching WordPress security flaws on the editor install.

Frequently asked questions

The bottom line

Converting WordPress to static HTML is genuinely easy. Simply Static will do it this afternoon and your pages will be faster tonight. What's not easy is everything after the ZIP: the forms, the sitemap, the redirects, and the fact that you're now maintaining WordPress and a static site instead of one thing.

So the real question isn't which exporter to use. It's whether you want a snapshot or a move. If the site is finished, export it and enjoy the speed. If it's a working business site, a migration that also keeps it editable is the version that actually reduces your workload, which is the whole argument of the pillar guide and of moving off WordPress without losing rankings.