How to convert a WordPress site to static HTML

Converting WordPress to a static site means replacing a live PHP and MySQL application with files a static host can serve: HTML, CSS, JavaScript, images, fonts, and public downloads. That can be a good fit for a brochure site, archive, campaign page, or older site you want to preserve. It is not the same as a complete WordPress backup.

There are three honest paths. If you still control the WordPress install, a plugin static site generator such as Simply Static or WP2Static is usually the first path to evaluate. If you only have the public URL, lost hosting access, need a quick archive, or want to check the public pages as files before deciding, a public HTML copy can preserve what visitors receive in the browser. If you want a CMS dashboard or a clean framework codebase, treat the static copy as a reference and rebuild. If you want to keep the pages and change them, the files are yours and an AI assistant can help.

Only export sites you own or are authorized to copy. A public URL is not permission to republish someone else's work.

Static site versus WordPress-powered site

A WordPress-powered site is an application. A request may run PHP, query MySQL, apply themes and plugins, check user state, render comments, serve search results, process forms, and generate pages from stored content.

A static site is the rendered output. The host serves files that already exist. There is no wp-admin, no WordPress database, no PHP runtime, and no plugin system unless you rebuild those jobs elsewhere.

That difference is why "convert WordPress to static website" can describe more than one job:

• generating static files from inside WordPress while you still have admin access;
• copying the public WordPress front end that a browser can receive;
• rebuilding the design and content into a different static-site generator, CMS, or framework.

The right choice depends on what access you have and what must keep working after the move.

What transfers, and what does not

A static WordPress copy can usually preserve:

• published posts and pages as HTML;
• theme CSS and browser JavaScript used by public pages;
• public images, icons, fonts, PDFs, and other downloadable files;
• menus, internal links, and public route structure for captured pages;
• visible Elementor, block editor, or theme-rendered layouts as delivered to visitors.

It does not independently preserve:

• the MySQL database as a live content source;
• wp-admin, user roles, drafts, revisions, or editorial workflows;
• themes and plugins as maintainable source systems;
• WooCommerce inventory, carts, checkout, orders, taxes, refunds, or customer accounts;
• form submissions, email routing, spam protection, and CRM integrations;
• comments, login, memberships, gated pages, or personalized content;
• WordPress search unless you replace it with a static index or hosted search provider.

Published posts can become static HTML pages. The underlying database, editing workflow, plugin settings, and future publishing system do not come along.

Path A: use a WordPress static site generator plugin

When you have WordPress admin access, start with the tools that can run from inside the WordPress environment. Simply Static and WP2Static are common examples in this category. They can ask WordPress to render pages, collect linked assets, and produce a static output for deployment elsewhere.

This path is strongest when you control the install because the generator can work with the canonical WordPress URLs, current theme output, and known content routes. Depending on your setup, it may also integrate better with WordPress-specific URL structures than a general crawler.

Keep the expectations practical:

• confirm current plugin documentation before relying on a feature or deployment target;
• export database and media backups separately before changing hosting;
• test representative posts, archives, categories, tags, landing pages, and custom post types;
• replace forms, search, ecommerce, comments, memberships, and login flows intentionally;
• keep the WordPress site available until the static deployment has passed real checks.

Plugin output is still static output. It may be a good way to export WordPress to HTML, but it does not make WooCommerce or wp-admin portable as static files.

Path B: copy the public site as files

A public-site copy loads the published URL, saves the HTML, CSS, JavaScript, images, fonts, and public files a visitor's browser receives, then rewrites references so the result can run on another host. This is useful when you do not have WordPress admin access, inherited a site without hosting credentials, need a quick archive, or want to see whether the public front end is enough before committing to a migration plan.

Export Your Site is one way to create that copy.

A homepage screenshot cannot tell you whether mobile navigation, deep posts, Elementor sections, galleries, images, and service boundaries survived the copy. Open the copy and click through those states before you treat it as a migration artifact.

For the general mechanics of crawling, rewriting, and checking a public archive, see the guide to downloading an entire website as HTML, CSS, JavaScript, and assets. WordPress has its own boundaries, so classify the WordPress features separately instead of treating it as a generic download.

Path C: rebuild when you want a CMS or clean source

Choose a rebuild when the goal is a CMS, a clean source tree, or a new platform rather than keeping the published pages as files. A developer can recreate the site in a static-site generator, a headless CMS, a framework, or another hosted platform while using the current WordPress site as a visual and content reference.

A rebuild is usually the better destination when:

• editors need a CMS after launch;
• developers need clean source code rather than generated delivery output;
• the site depends on custom plugins, WooCommerce, memberships, or application logic;
• accessibility, performance, or design cleanup is part of the project.

A static copy can still help. It gives you a working archive, a rollback reference, and concrete evidence of what the public site looked like before the rebuild started.

Before you start: classify every feature

Create a simple inventory before running a plugin or public copier:

| Page or feature | Static or dynamic? | Replacement plan | | --- | --- | --- | | Home, about, services, landing pages | Usually static | Capture and check the copy | | Blog posts and category pages | Mixed | Capture rendered pages; decide future publishing workflow | | Elementor layouts | Usually static visually | Test scripts, responsive sections, and widgets | | Contact forms | Dynamic | Replace endpoint, spam protection, and email delivery | | WooCommerce products and checkout | Dynamic | Separate commerce migration or external store | | Search | Dynamic | Static index, hosted search, or remove | | Comments, login, memberships | Dynamic | New platform or rebuild |

Static items are things a visitor can receive without submitting data, logging in, or querying a private service. Dynamic items depend on WordPress, a plugin, a database, a third-party API, or account-specific state.

If a feature collects leads, takes payments, changes often, or gates access, assign its replacement before moving DNS.

Steps for the public-copy path

1. Inventory the live WordPress site

List the homepage, top navigation, footer links, legal pages, core landing pages, important posts, category or tag archives, downloadable files, embeds, and any unlinked campaign URLs you still need.

Also record dynamic features: forms, search, comments, WooCommerce, login, membership gates, calculators, popups, analytics, consent tools, and custom plugin behavior.

2. Create the public copy

Use an online exporter with conservative route and size limits. It should follow safe redirects, collect required assets, and avoid wandering into unrelated domains. For a WordPress static site, sample every distinct page type rather than assuming the homepage proves the rest.

Make a copy of the live published pages as files, then open that copy and click through it.

3. Check the copy

Treat the copy as an acceptance test:

1. Open the homepage, main navigation, footer links, and important posts.
2. Resize from desktop to mobile and open each menu state.
3. Check a page, a post, an archive page, and any Elementor-built layout.
4. Test galleries, accordions, sliders, popups, video embeds, and downloadable files.
5. Follow internal links and watch for jumps back to the old WordPress domain.
6. Try every form, search box, login link, cart control, and comment form.
7. Open developer tools and classify errors by user impact.

Some remote requests may be intentional, including analytics, video embeds, maps, font providers, and payment widgets. The goal is to know what remains remote, not to pretend every third-party service became static.

4. Replace services that WordPress used to provide

Point forms to a provider or server endpoint you control. Add validation, spam protection, success and error states, and email delivery tests.

Replace WordPress search with a static index or hosted search service if search matters. Remove login, comments, memberships, and cart controls unless you have a new backend for them.

For WooCommerce, migrate product, customer, and order data through supported export paths and choose a new commerce system. A copied product page is not a store migration.

5. Deploy to a temporary hostname

Upload the files to the host you intend to use: Cloudflare Pages, Netlify, Vercel, GitHub Pages, object storage with a CDN, or a conventional web server can all serve static files.

Test on the temporary deployment because production path handling, HTTPS, redirects, compression, caching, and security headers can differ from local files.

Review titles, descriptions, canonical links, social metadata, robots rules, sitemaps, 404 behavior, old URL redirects, and any absolute references to the WordPress domain.

6. Change DNS last

Save the current DNS records before the cutover. Point the domain to the static host only after the temporary deployment works and required services have been replaced.

Keep the old WordPress hosting available during validation. Watch the homepage, a deep route, lead delivery, analytics, search replacement, checkout replacement, and error responses before cancelling the old plan.

When static is the wrong choice

Do not convert WordPress to static HTML as the final system when the site needs private dashboards, user accounts, memberships, WooCommerce checkout, complex forms, personalized pages, or WordPress admin. You can still change the copied pages, including with an AI assistant.

Do not choose it when the team expects to keep using WordPress admin after the domain moves. The static files have no database connection and no WordPress editor.

Do not choose it when clean maintainable source code is the main deliverable. Public browser output and plugin-generated static output are built for delivery. They are not the same as a carefully organized source project.

In those cases, use the export as an archive or migration reference while rebuilding on a platform that matches the future workflow.

Related platform guides

The same boundary appears on other hosted builders, with different details. Compare the Wix self-hosting guide, the Squarespace self-hosting guide, the Webflow export guide, and the guide on leaving Framer if your migration spans more than WordPress.

FAQ

Is Simply Static or WP2Static better than a public export?

Use a WordPress plugin first when you have admin access and control the install. It can ask WordPress to render known routes from inside the system. Use a public export when you only have the public URL, cannot access hosting, need a quick archive, or want to check a public copy before deciding whether static files are useful.

Will WooCommerce work after I export WordPress to HTML?

No. Static files may preserve the look of product pages, but they do not preserve inventory, carts, checkout, taxes, shipping, order history, customer accounts, subscriptions, or refunds. Treat WooCommerce as a separate commerce migration.

Will WordPress forms keep working?

Do not assume so. The fields may appear, but the submission handler usually depends on WordPress, a plugin, or a third-party service. Replace each form endpoint and test validation, spam protection, redirects, failure states, and email delivery.

Is a public static copy a WordPress backup?

No. A public copy is not a WordPress backup. It does not include MySQL, wp-admin, themes and plugins as source, private uploads, settings, users, orders, or drafts. Keep database and file backups separately if you still control the WordPress install.

Can I edit the HTML after converting WordPress to static?

Yes. The files are yours. An AI assistant can help you swap text or add a page if you do not want to hire a developer. You do not get the WordPress admin or a theme editor with the static copy.

Can Elementor pages become static HTML?

Often, the public Elementor-rendered page can be captured as HTML, CSS, JavaScript, and assets. Elementor itself does not become portable as an editor. Test responsive sections, widgets, sliders, popups, and forms because those may depend on scripts or services that need replacement.

How do I export a WordPress site if I lost admin access?

If the site is still publicly reachable and you are authorized to copy it, use the public-copy path. You can preserve the visible front end and public assets, then rebuild or replace any dynamic features. If you need the database, users, orders, or source files, you need hosting or backup access.

A published-page copy can start from the WordPress export page.