"Export WordPress to static HTML" is the easy part — several plugins do it. The part that actually determines whether the migration works is what happens to everything that isn't a plain content page: comments, site search, contact forms, and (if you're running a store) WooCommerce prices and cart. A static export with no plan for those simply breaks them.

What breaks in a naive static export

  • Comments — there's no PHP running to accept a comment submission on a static file.
  • Search — WordPress search is a database query; a static site has no database to query.
  • Contact forms — form plugins post to a PHP handler that no longer exists on the static output.
  • WooCommerce prices, stock, and cart — anything that needs to be current at request time can't be baked into a static file generated hours or days ago.

The fix: proxy, don't abandon

The working pattern is to keep your WordPress installation running exactly as it does today — same host, same database, same plugins — and serve everything static from the edge except the small number of requests that genuinely need to hit WordPress live. A router in front of the static site (Pinery Static uses a Cloudflare Worker for this) inspects incoming requests and quietly forwards comment submissions, search queries, form posts, and WooCommerce price/cart requests back to your real WordPress backend, while every normal page load is served instantly from the static export.

Migration steps, roughly in order

  1. Keep your WordPress backend where it is. Don't migrate hosting as part of this — the backend stays live and becomes the thing the proxy talks to.
  2. Run a full static export and review the output for anything that looks broken before going live — this is where you catch missing pages or malformed URLs early.
  3. Deploy the static output to Cloudflare Pages under a project you control.
  4. Put the proxy router in front of it so dynamic requests route back to WordPress instead of hitting a static 404.
  5. Point your domain at the new deployment — ideally via a same-domain migration path that doesn't require a DNS cutover with downtime.
  6. Re-export incrementally going forward — every time you publish or update content, only the changed pages need to re-export, not the whole site.

What you get on the other side

Static pages served from a CDN edge are faster than anything WordPress can serve directly — no PHP execution, no database query, no plugin overhead for the request — while comments, search, forms, and store functionality keep working exactly as before, just proxied instead of native. See our performance guide for why this matters specifically for affiliate conversion rates, or compare static-export tools generally in our Simply Static and WP2Static comparisons.