Converting a WordPress site to static HTML sounds like a step backward, WordPress exists precisely to avoid hand-writing HTML, but for a specific category of site, it’s one of the more sensible infrastructure decisions available. A brochure site that hasn’t changed its content in six months, a documentation archive, a marketing microsite, a blog that’s been retired but needs to stay live for SEO and backlink equity: none of these need a database, a PHP runtime, or an admin login sitting on the public internet waiting to be probed. What they need is fast, cheap, nearly unhackable delivery of content that used to be dynamic and no longer needs to be.
The mechanics are straightforward in concept: render every page WordPress would generate, save the output as plain HTML/CSS/JS files, and serve those files directly instead of running PHP and MySQL on every request. What differs between the tools below is how that rendering happens, what breaks in the process, and where the resulting files end up living.
What you actually gain, and what you give up
The upside is real and measurable. Static files skip database queries entirely, so page loads are typically limited only by network latency and file size rather than PHP execution time or a slow query. There’s no wp-login.php to brute-force, no plugin vulnerability to exploit, no SQL injection surface, because there’s no database connected to the public-facing site at all. Hosting costs drop sharply too, a static site can often run on a free or near-free CDN tier that would cost real money to run as a dynamic WordPress install with equivalent traffic.
The downside is that anything genuinely dynamic stops working unless you rebuild it around a third-party service. Comments need Disqus or a similar hosted commenting system, since there’s no database to store them in locally. Contact forms need a service like Formspree or Netlify Forms that accepts a POST request and forwards it by email, because there’s no PHP mail() function running server-side anymore. Site search needs something like Algolia or a client-side JS search index (Lunr.js, Fuse.js), since there’s no live database to query against. WooCommerce, membership logins, and anything requiring a logged-in user session are effectively incompatible with a fully static approach, those sites need a hybrid architecture, not a pure static conversion, and none of the tools below will make that work cleanly on their own.
The main approaches, and which tools fall into each
WordPress plugins that generate a static export directly from your existing site
Simply Static is the most widely used option in this category, and for good reason, it runs inside your existing WordPress install, crawls every published URL, and outputs a complete static copy you can deploy to any static host: an S3 bucket behind CloudFront, Netlify, Cloudflare Pages, or a plain Apache/Nginx server with no PHP at all. It handles internal link rewriting automatically, which matters more than it sounds, since a static export with broken internal links defeats the point. The free version covers most single-site use cases; the paid tier adds scheduled automatic re-generation and deployment integrations for teams that update content regularly but still want the security and performance benefits of static delivery.
WP2Static is a strong alternative built around the same core idea, crawl the live site, output static files, with a plugin architecture that supports deploy targets including Netlify, GitHub Pages, Bunny CDN, and Amazon S3 out of the box, without needing to hand off to a separate deployment script. It’s a solid pick for teams already comfortable configuring deploy integrations directly rather than manually uploading a ZIP of generated files.
Export WP Page to Static HTML/CSS takes a narrower approach: rather than crawling and freezing the entire site at once, it lets you export individual pages or posts to static HTML on demand, including automatic re-export triggered by publishing. That’s useful for a hybrid setup, a mostly-dynamic WordPress site that wants specific high-traffic pages (a pricing page, a popular blog post) served as pre-rendered static files behind a cache layer, without converting the entire site.
Offline crawlers: freezing a live site from the outside
HTTrack is a free, open-source offline browser that works completely independently of WordPress, it crawls a live URL the way a search engine bot would, downloading every page, image, stylesheet, and script it finds, and reconstructs the site’s link structure locally. It’s cross-platform (WinHTTrack on Windows, WebHTTrack on Linux) and genuinely useful in a specific scenario: archiving a site you don’t have admin access to, or one running on a CMS other than WordPress where a plugin-based export isn’t an option. The tradeoff is that a crawler-based approach can miss content behind JavaScript-rendered interactions or AJAX-loaded elements that a plugin running inside WordPress would catch automatically.
SiteSucker serves a similar purpose on macOS and iOS specifically, a polished, native app for downloading an entire site for offline browsing. It’s more of a personal archiving tool than a production deployment pipeline; useful for backing up a site you’re about to decommission, less useful as the basis for an ongoing static-hosted replacement.
Static site generators: rebuilding rather than freezing
A different category entirely: rather than exporting an existing WordPress site as-is, these tools rebuild your content from source files (usually Markdown) into a static site using their own templating system. This is a bigger commitment, it typically means migrating content out of WordPress’s database into flat files and adopting a new authoring workflow, but it produces a cleaner, purpose-built static site rather than a frozen snapshot of a dynamic one.
Hugo, written in Go, is the fastest of the mainstream options by a wide margin and has one of the largest theme ecosystems in the space, with hundreds of community-maintained themes to start from. Jekyll, Ruby-based and the tool GitHub Pages was originally built around, has the longest track record and the most tutorials, making it a reasonable starting point for a first static site project. Eleventy (11ty), JavaScript-based, has gained ground for its near-zero-configuration setup and support for multiple templating languages in the same project. Pelican, Python-based, fits teams already working in a Python-centric stack. Gatsby is the outlier here, a React-based framework that pulls content via GraphQL from various sources including a headless WordPress install, aimed at teams that want a genuinely modern JS frontend rather than a simple content-out-flat-files site, at the cost of a meaningfully steeper learning curve than the others.
None of these five are a one-click WordPress export. Choosing this path means committing to a content migration and a new publishing workflow, which is worth it for a from-scratch rebuild or a documentation site with a technical team behind it, and usually not worth it for a small business owner who just wants their existing WordPress site to stop needing PHP hosting.
A note on Strattic
Strattic used to be commonly recommended in this space, a managed service that converted a WordPress site into a static, CDN-hosted deployment while keeping the familiar WordPress admin for editing. It’s worth flagging that Strattic was acquired by WP Engine in 2022, and the standalone product has since been wound down as an independent offering rather than continuing to onboard new customers directly. If a managed, WordPress-admin-preserving static hosting service is specifically what you’re after, it’s worth checking WP Engine’s current headless and Atlas offerings directly rather than looking for Strattic as a separate product, since the landscape here has shifted since it was last a commonly recommended standalone tool.
Choosing the right approach for your actual situation
The honest answer depends less on which tool has the longest feature list and more on what the site needs to keep doing after conversion. A small business brochure site with a contact form and no blog updates is the easiest case, Simply Static or WP2Static, paired with a hosted form service, covers it completely in an afternoon. A blog that’s being retired but needs to stay live for SEO equity is nearly as simple, minus the form consideration, since there’s nothing left to submit. A documentation site with a technical team maintaining it benefits more from committing to Hugo or Eleventy from the start, since the authoring workflow (Markdown in a git repo, reviewed via pull request) tends to fit a documentation team’s existing habits better than editing inside wp-admin.
A site with active commerce, memberships, or frequent content updates from non-technical staff is the case where full static conversion is the wrong call, not just a harder one. WooCommerce checkout, logged-in member areas, and any workflow that depends on server-side session state need a dynamic backend somewhere in the stack. The realistic options there are a hybrid setup, static delivery for marketing pages with a separate dynamic app or WordPress instance handling checkout and accounts, or simply staying on a well-optimized, well-cached dynamic WordPress install rather than forcing a static conversion where it doesn’t fit.
A walkthrough: converting a simple brochure site with Simply Static
It’s worth working through the actual steps once, since the process is less intimidating than the tool list above might suggest. After installing and activating Simply Static on the WordPress install you want to convert, the plugin’s settings screen asks for a destination URL, the domain the static site will eventually live at, which it needs up front so it can rewrite internal links correctly during the export rather than leaving them pointing back at the old dynamic URLs. From there, running the export triggers a full crawl: the plugin walks every published page and post, following internal links the way a visitor would, and saves the rendered HTML output along with every image, stylesheet, and script it encounters along the way.
Once the crawl finishes, Simply Static offers a few delivery options, a downloadable ZIP you can upload anywhere manually, direct deployment to an S3 bucket, or (on the paid tier) a direct SFTP push to your static host. For a first attempt, downloading the ZIP and manually deploying it to a free tier on Netlify or Cloudflare Pages is the lowest-friction way to see the result before committing to an automated pipeline. Both of those hosts support dragging a folder directly into their dashboard for an instant deploy, which is a reasonable way to sanity-check the export before wiring up anything more permanent.
The step people skip and then regret is checking the exported site’s internal search, if the theme had one, a static export almost never carries search functionality forward automatically, since WordPress search depends on a live database query. If site search matters for the converted site, that’s a separate integration to add afterward (Algolia’s free tier covers small sites reasonably, or a client-side index via Lunr.js for a site with a modest number of pages), not something to assume the export handled.
What happens to SEO rankings after conversion
This is the question that stops a lot of site owners from attempting a static conversion, and the honest answer is: nothing changes, as long as the migration is done carefully. Search engines rank content and technical signals, page speed, mobile-friendliness, structured data, internal linking, not the underlying server technology. A well-executed static conversion typically improves the page-speed signal, since static file delivery is faster than a PHP-rendered response by a wide margin in most real-world comparisons, which is a ranking factor Google has weighted more heavily since the Core Web Vitals rollout.
Where sites actually lose rankings during a conversion, the cause is almost always a migration mistake rather than an inherent penalty for going static: URLs changing without 301 redirects in place, XML sitemaps not being regenerated and resubmitted to Google Search Console, structured data (schema markup) not surviving the export because it was generated by a plugin that only runs in a live PHP context rather than being baked into the static HTML, or canonical tags pointing at the old dynamic domain instead of the new static one. Auditing each of those specifically, redirects, sitemap, structured data, canonicals, before and after the cutover is the actual work of protecting rankings through a static migration, and it’s a more reliable use of time than worrying about the conversion itself hurting SEO in some abstract sense.
Cost comparison: what static hosting actually saves
It’s worth being concrete rather than vague about the savings, since “static is cheaper” gets repeated often without numbers attached. A typical small WordPress site on managed hosting runs anywhere from $15 to $50 a month depending on traffic and the host’s tier structure, covering PHP execution, a managed database, and usually some level of built-in caching and security scanning. The equivalent static site, hosted on Cloudflare Pages, Netlify’s free tier, or GitHub Pages, frequently costs nothing at all for low-to-moderate traffic, since these platforms are built around serving static assets from a global CDN and price around bandwidth and build minutes rather than server compute time. Even at higher traffic volumes where a paid tier kicks in, the pricing tends to scale more gently than equivalent dynamic hosting, because there’s no database or PHP runtime consuming server resources on every request, the CDN is just handing back files it already cached.
That said, the savings aren’t purely financial once you factor in the ongoing cost of maintaining a re-export pipeline, wiring up third-party services for anything that used to be dynamic, and the discipline required to remember that content edits in the live WordPress admin won’t appear on the public site until the next export runs. For a site that updates rarely, that tradeoff is clearly worth it. For a site with a content team publishing daily, the operational overhead of the export-and-deploy cycle can eat into the savings enough that staying dynamic, with solid caching (a plugin like WP Rocket or a server-level cache such as Varnish or Nginx FastCGI cache) sitting in front of it, ends up being the more practical choice.
Practical steps before you commit
Run the conversion on a staging copy first, not the production site, a static export is only as good as the crawl that generated it, and the first attempt on any real site tends to surface a handful of pages that didn’t get picked up (orphaned pages with no internal links pointing to them, for instance, which a crawler-based tool will miss entirely since it only follows links it can find). Check that forms, if any remain, are wired to a working third-party endpoint before going live, not after, a “successfully submitted” message on a form that silently goes nowhere is a worse failure mode than no form at all. Confirm redirects from old dynamic URLs (particularly anything with query strings, like WooCommerce’s cart or checkout URLs) either 404 cleanly or redirect somewhere sensible, rather than serving a broken static page where a dynamic script used to run. And set a calendar reminder to re-export periodically if the underlying WordPress install is still being edited in the background, a static site only reflects the state of the source at the moment it was generated, and content edited afterward won’t appear until the next export runs.
Static conversion isn’t the right move for every WordPress site, but for the ones where it fits, retired blogs, documentation, brochure sites, anything that doesn’t need a database talking to the public internet, it’s a genuine security and performance upgrade, not just a cost-cutting workaround. Match the tool to what the site actually needs to keep doing, test the export thoroughly before cutting over, and the tradeoffs above are the only ones you’ll need to plan around.