How to Create a WordPress Static Site: Tested Step by Step

A WordPress static site is a copy of your WordPress pages saved as plain HTML files. WordPress stays where it is for editing, and visitors get the fast HTML copy instead of pages built by PHP on every request.

I built one in October 2026 on a WordPress 7.1.3 test site with WooCommerce 11.2, 12 products and a few posts. I exported it with Simply Static 3.8.17, served the files and measured the speed. Then I checked which features broke.

This guide shows the whole process with real numbers and screenshots. It also covers when a static site is the wrong choice, because a store or a site with logins needs WordPress running all the time.

Is WordPress a Static Website?

No, WordPress is not a static website by default. It is a dynamic system that runs PHP and queries a MySQL database to build each page when someone asks for it. A plugin can save those pages as static HTML files, and that copy is what people call a static WordPress site.

The difference matters for speed and security. A dynamic page needs PHP, the database and every active plugin to run before the first byte leaves the server. A static file only needs the web server to read it from disk.

The name confuses people for another reason. Settings > Reading has an option called “A static page”, but it only picks which page shows on the home page.

PHP still runs on every visit with that setting. The speed and security stay exactly the same. I checked this on the test site. The home page took 59 ms with latest posts and 71 ms with a static page because PHP still built it.

That setting does not turn your site static at all. The Reading Settings documentation describes it as a choice between your latest posts and a fixed page.

What Is a Static WordPress Website?

A static WordPress website has two parts that live in two different places. One is a private WordPress install where you write and edit. The other is a folder of HTML, CSS, JavaScript and image files that the public sees.

After each change, you export again and replace the old files.

Most setups follow the same pattern:

• Origin site: WordPress on a staging URL, a local machine or a locked down subdomain.
• Export tool: A plugin that crawls every page and saves the result as files.
• Static host: Any web server, a CDN or a service like Netlify or Cloudflare Pages.
• Public domain: Points at the static host and never at WordPress.

The static files are not a different website. They are the same pages, with the same theme, menus and images, saved at one moment in time.

That moment matters. Anything you change in WordPress afterwards stays invisible to visitors until the next export, including price changes, new posts and fixed typos.

Because the public never touches WordPress, there is no login page, no XML-RPC endpoint and no plugin code for attackers to reach. That is the biggest security gain of a static site.

WordPress Static vs Dynamic: What Changes

A static copy changes three things: how fast the first byte arrives, what an attacker can reach and which features still work. Speed and security get better. Anything that needs PHP at the moment of the visit, such as search, comments, forms and checkout, stops working unless you replace it.

Here is how the two compare:

Area	Dynamic WordPress	Static WordPress
Page build	PHP and MySQL on every request	Built once at export
Time to first byte (my test)	60 to 82 ms	0.7 ms
Attack surface	Login, plugins and XML-RPC	Plain files only
Hosting	PHP and MySQL hosting	Any file host or CDN
Search, forms and comments	Built in	Need outside services
WooCommerce	Works	Not supported
Updating content	Instant	Export and upload again

The speed figures come from my own test, explained in the next sections. A good page cache on a normal WordPress host closes much of that gap. So static is not the only way to get a fast site.

If speed is your main goal, compare it with a caching plugin first. Our list of the best WordPress caching plugins covers the options that keep WordPress dynamic.

How to Create a WordPress Static Site With Simply Static

To create a WordPress static site, install Simply Static, choose where it should save the files and click Push. The plugin crawls every page, copies the assets it finds and writes a complete static version of the site. My 27 page test site took 42 seconds.

Simply Static is the most used option on WordPress.org, with over 30,000 active installs. Version 3.8.17 was updated on 8 October 2026 and is tested up to WordPress 7.1.3, as of October 2026. Its plugin page lists the free and Pro features.

Follow these steps:

1. Go to Plugins > Add Plugin, search for Simply Static and click Install Now. Click Activate when it finishes.
2. Open Simply Static > Settings > Deploy.
3. Pick a Deployment Method. ZIP Archive gives you a download, and Local Directory writes the files to a folder on the server.
   
4. Under Settings > General, set your real domain as the URL the static site will use.
5. Go to Simply Static > Generate, keep Full Site selected and click Push.
   
6. Wait for “Done!” in the Activity Log. Then download the ZIP or open the folder.

The Export Log below the Activity Log lists every URL and its status. Mine showed a few 404 errors for images that WooCommerce’s CSS mentions but never ships, which did no harm.

Simply Static Settings Worth Checking

Three settings decide whether the export works on the first try. Most failed exports I have seen trace back to one of them.

• Replacing URLs: Absolute URLs point every link at your real domain, while relative URLs let the files work from any address.
• Extra URLs: Add any page or file that no menu or post links to, or the crawler will skip it.
• Excluded URLs: Leave out the cart, checkout, account and any admin pages, because their static copies are useless.

Pick the destination URL with care. Simply Static rewrites every link in the files to that address. A wrong value sends visitors back to the origin site.

What My Static Export Contained

My test export held 3,124 files and 99 MB for a site with 27 pages. Most of the size was WordPress core files that the crawler copied because pages linked to them. The HTML pages themselves were small, and the uploads folder was only 1.2 MB.

Here is the breakdown from my test folder:

• HTML pages: 27 with one folder per URL and an index.html inside.
• wp-includes: 68 MB, mostly scripts and styles from WordPress core.
• wp-content/plugins: 19 MB and mostly WooCommerce assets.
• wp-content/themes: 7.4 MB.
• wp-content/uploads: 1.2 MB of images.

Each page sits in its own folder. That is why /how-we-pack-ceramic-mugs/ became how-we-pack-ceramic-mugs/index.html. That keeps your existing URLs working on any host that serves index.html by default. Almost all hosts do.

The Export Log also listed 404 errors for a few images named in WooCommerce’s CSS files. Those files never existed in the plugin. The errors were harmless. Check the log for 404s on your own pages though. Those are real broken links.

A static host serves this easily, but uploads take longer than they need to. Simply Static Pro and some hosts can skip unused files. Removing unused plugins before the export also trims the size.

How Fast Is a Static WordPress Site?

In my test, static pages answered in 0.7 ms against 60 to 82 ms for the same pages from WordPress. I took the median of 10 requests per page on the same machine. The static files skipped PHP and the database completely. Every page took the same time.

These numbers come from a local server. A real visitor also has network time on top. The gap is still real. On a busy shared host the dynamic number grows, while a static file from a CDN stays fast.

The heavier the page, the bigger the gain. My Shop page was the slowest dynamic page at 82 ms, because WooCommerce does more work to build it.

If your pages are already fast, the gain may not justify the trade offs below. Measure your own time to first byte before you decide.

What Breaks on a Static WordPress Site

Anything that needs WordPress to answer a visitor in real time breaks on a static copy. In my export, search returned the home page and the comment form still pointed at the WordPress origin. Simply Static also warned that WooCommerce is not compatible with a static site.

Here is what I found, feature by feature:

• Search: The static server ignored ?s=mug and returned the home page.
• Comments: The form still posted to wp-comments-post.php on the origin, which fails once the origin is private.
• Contact forms: There is no PHP to receive the form. It needs a form service.
• WooCommerce: Cart, checkout and accounts need sessions and cannot work from files.
• New content: A new post does not appear until you push the export again.

Simply Static’s own Diagnostics screen flagged the store before I even exported:

So never make a WooCommerce store fully static. Keep it dynamic, and use a page cache and a CDN for the speed instead.

How to Keep Forms, Search and Comments Working

Replace each dynamic feature with a service that works from plain HTML. Forms send to a form endpoint, search runs in the browser from an index file, and comments move to a hosted service or get closed. Set these up before the switch, because the static copy cannot fall back on WordPress.

Use these swaps:

• Forms: Point the form at a hosted form service, or use Simply Static Pro’s form handling.
• Search: Use a client side search that loads a small index, which Simply Static Pro also offers.
• Comments: Close them, or embed a hosted comment service that stores comments elsewhere.
• Newsletter signups: Use the email provider’s own embed code that posts to their servers.

Plan the replacements in a list before you export. Open each page type, such as a post, a contact page and the home page, and note every box a visitor can type into. Each one needs a new home.

Most small static sites close comments. A static site that only shows information rarely needs them.

Test every form on the static copy before you point your domain at it. In my export, the comment form still showed and looked normal, even though it would fail for a real visitor.

How to Host and Update a Static WordPress Site

Upload the exported files to any static host and point your domain at it. Cloudflare Pages, Netlify, an S3 bucket or a plain web server all work. To update the site, edit in WordPress, push the export again and upload the new files over the old ones.

Here is a simple setup that works for most sites:

1. Move WordPress to a private address such as a subdomain protected by a password.
2. Export with Simply Static as a ZIP file.
3. Upload the ZIP’s contents to the static host.
4. Point the public domain at the static host.

Both Cloudflare Pages and Netlify accept a folder upload and serve it from a global CDN. Simply Static’s Deploy settings also list GitHub, AWS S3, Bunny CDN, FTP and SFTP. Some of these need the Pro version.

Updating takes discipline. Every typo fix needs a new push. Batch your edits and push once a day or once a week.

Protect the origin too. It still runs WordPress. Keep it updated and private or attackers will simply go around the static copy.

Other Ways to Make WordPress Static

Simply Static is not the only route to a static copy of WordPress. Staatic is a smaller free plugin that works in the same way. A headless setup uses WordPress only as a content source for a separate site generator.

Hosted platforms can also run the export and hosting for you.

The main options as of October 2026:

• Staatic: A free plugin, version 1.13.2 with over 2,000 active installs. See its WordPress.org page.
• WP2Static: No longer listed on WordPress.org. Guides that tell you to install it from the plugin directory are out of date.
• Headless WordPress: A framework such as Next.js or Astro pulls content through the WordPress REST API and builds the static pages.
• Hosted static platforms: Services that host the private WordPress and publish the static copy, usually on a monthly plan.

Staatic follows the same idea as Simply Static: crawl the site, save the files and deploy them. It is worth a test if Simply Static misses pages on your site, because the two crawlers find URLs in slightly different ways.

Whichever plugin you use, add pages that nothing links to by hand. Both tools crawl from the home page. An orphan landing page is left out unless you list it as an extra URL.

Headless gives you the most control and the best speed, but you rebuild the theme in another framework. It suits developers more than site owners who want to keep their current design.

When a Static WordPress Site Is the Wrong Choice

A static site is the wrong choice when visitors need to log in, buy, search heavily or see content that changes every few minutes. Stores, membership sites, forums and booking sites all need WordPress running. For them, page caching gives most of the speed without breaking anything.

Choose static when the site is mostly read only:

• Good fit: Brochure sites, portfolios, documentation, landing pages and small blogs.
• Poor fit: WooCommerce stores, LMS and membership sites, and anything with user accounts.
• Poor fit: Sites that publish many times a day, because every change needs a new export.

Ask one question before you start. Does any visitor ever see something that only exists for them, such as a cart, an account or a saved form? If the answer is yes, that page has to stay dynamic.

A hybrid also works. Keep the shop dynamic and export only the marketing pages, or serve a static copy through a CDN cache in front of WordPress. Another route is a headless build, where WordPress keeps the editor and a separate app renders the pages.

If you want the speed without the trade offs, a WordPress speed optimization service can tune caching, images and server settings on the dynamic site. Compression helps too, and our Brotli vs GZIP test shows what each one saves.

Conclusion

A WordPress static site keeps WordPress for editing and serves a folder of HTML files to the public. In my test, Simply Static exported 27 pages in 42 seconds, and those pages answered in 0.7 ms instead of 60 to 82 ms.

The price is everything dynamic. Search, comments and forms need outside services, and WooCommerce does not work at all.

Use a static site for read only content, keep the origin private and push after every change. For stores and member sites, stay dynamic and use caching instead.

Frequently Asked Questions (FAQs)