WordPress to Static Site Migration Checklist for 2026

WordPress-to-static migrations usually go wrong when teams treat them like a hosting change. They are not. You are changing how the public site is delivered, which features can stay native, how editors publish, and what has to be tested before launch.

This checklist is for teams planning a migration, whether they use Staatic, another export workflow, or a custom pipeline. The goal is simple: confirm the site is a good fit, prepare the WordPress origin properly, replace the pieces that cannot stay dynamic, and cut over without surprises.

Before you begin

Use this as a decision checklist, not a theory piece. Then use the phases below in order. Skipping ahead is where the trouble usually starts.

• Do not start with your exporter. Start with the site audit.
• Do not assume every WordPress feature can stay native on a static site.
• Do not treat the launch as complete until you have tested rebuilds, redirects, and rollback.
• Do not leave your WordPress origin exposed on the public domain after cutover unless you have a specific reason to do so.

If you are migrating a simple marketing site, documentation site, or blog, most of this will move quickly. If you are migrating a large publisher, multilingual site, or plugin-heavy build, this checklist helps you avoid the expensive mistakes.

At-a-glance migration flow

flowchart TD
    A[Phase 1: Fit check<br/>Is the public site mostly read-only?] -->|No: auth, ecommerce, per-user logic| H[Choose hybrid architecture<br/>Do not force pure static]
    A -->|Yes| B[Phase 2: Dependency inventory<br/>Forms, search, comments, previews, AJAX, cron, feeds]
    B --> C[Phase 3: Prepare WordPress origin<br/>Private origin, backups, current PHP, freeze changes]
    C --> D[Phase 4: Dynamic feature plan<br/>Replace, keep dynamic, or remove]
    D --> E[Phase 5: Publication model<br/>Manual, CI, or build-hook deploys]
    E --> F[Phase 6: URL and SEO validation<br/>Redirects, canonicals, sitemaps, archives, media]
    F --> G[Phase 7-8: Release and cutover<br/>Smoke test, launch runbook, rollback, restrict origin]

Phase 1: confirm that the site is a good fit for static delivery

The first question is not which plugin or platform to use. It is whether the public site should be static at all.

Site type	Static fit	What to watch for
Company site	Strong	Usually straightforward if forms are handled separately
Marketing site	Strong	Check forms, analytics, cookie tools, and preview workflow
Blog	Strong	Check comments, search, feeds, and archive pages
Documentation site	Strong	Check search, versioning, redirects, and navigation depth
News or editorial site	Medium to strong	Publishing frequency, preview workflow, and search matter more
Membership site	Weak for full static	Logged-in content usually pushes you toward hybrid
WooCommerce store	Weak for full static	Cart, checkout, account, and stock logic stay dynamic
Client portal or dashboard	Weak for full static	Auth and user-specific content are core runtime features
Personalized content site	Weak for full static	Per-user content is usually better handled with hybrid delivery

If most public pages are read-only and the dynamic pieces are limited to forms, search, comments, or a few embeds, static is usually a good fit. If the public experience depends on user state, server-side filtering, or live account logic, start from a hybrid assumption.

Before moving on, answer these questions clearly:

• Which parts of the site must stay dynamic?
• Which parts can be replaced with client-side or external services?
• Which parts can be removed without harming the business case?
• Does the team want WordPress to remain the authoring system but stop being the public runtime?

If you cannot answer those questions yet, do not move to implementation. You will likely solve the wrong problem first.

Phase 2: audit everything the public site currently depends on

Most migration failures come from missing a dependency that only becomes visible after launch. Audit the public site like a release inventory, because that is effectively what this is.

At minimum, review these areas:

• forms and submission handlers
• comments
• site search
• shortcode output and block/plugin-rendered content
• login links and account areas
• WooCommerce or other ecommerce flows
• membership or gated content
• previews and editorial review flows
• admin-ajax.php usage, AJAX endpoints, and live filters
• scheduled posts and anything that depends on WordPress cron
• password-protected posts or pages
• analytics, tag manager, consent, and cookie banner behavior
• redirects, canonicals, sitemaps, and robots.txt
• RSS feeds and newsletter integrations
• menus, pagination, archive pages, and taxonomy pages
• custom post types and custom rewrites
• multilingual or region-specific URL paths
• media files, uploads path assumptions, downloads, and externally hosted assets
• webhooks, scheduled tasks, and anything that assumes public WordPress traffic

For smaller sites, a spreadsheet is enough. For larger sites, create a proper inventory with at least these columns:

Feature or URL group	Current behavior	Static risk	Replacement or action	Owner
Contact form	Plugin submits to WordPress	Breaks on pure static	Move to external form endpoint	Marketing
Blog comments	Native WordPress comments	Breaks on pure static	Replace with hosted comments or remove	Editorial
Site search	Plugin-backed live search	Breaks or degrades	Client-side or hosted search	Product

This is where you find out whether the project is a clean static migration, a static-plus-helpers migration, or a hybrid build in disguise.

Some WordPress-specific examples are worth calling out because they are easy to miss:

• a form plugin that submits through admin-ajax.php
• a theme that renders important content through shortcodes or plugin callbacks
• preview links that only work against the private origin
• scheduled posts that depend on low-traffic WordPress cron behavior
• password-protected pages that no longer behave as expected once the public site is just files

Phase 3: prepare the WordPress origin before you export anything

Once the site passes the fit check, prepare WordPress as the origin system rather than the public application server.

Start with platform readiness:

• Get the site onto a current PHP version before the migration. WordPress currently recommends PHP 8.3 or newer in its requirements, and current 2026 developer guidance makes clear that older PHP lines are at the end of their safe planning life.
• Remove plugins you do not need before export work begins.
• Review theme and plugin behavior for features that assume a live public runtime.
• Freeze nonessential design and plugin changes during the migration window.

Then prepare the origin architecture:

• Move WordPress to a separate origin such as wp.example.com if it currently lives on the public domain. If you need the concrete pattern, the walkthrough on using WordPress as a static site generator and the Preparation guide are the most relevant Staatic references.
• Decide whether the origin will be public, IP-restricted, password-protected, or placed behind access control after launch.
• Take a clean backup before changing URLs, deployment settings, or routing.
• Create a staging path if the production origin is too risky to experiment on directly.

If you need to hard-code origin URLs during the move, review WordPress’s wp-config.php guidance around WP_HOME and WP_SITEURL before changing anything manually.

If you are changing origin URLs, use WordPress-safe migration methods. The official migration docs warn against careless database-wide replacements because serialized data can break, and they explicitly warn not to rewrite guid values during URL replacement.

If your team uses the Site Editor or block themes heavily, review how design changes are stored. In 2026, many visual changes still start in the database. The recent WordPress Playground and GitHub workflow is useful here because it gives teams a disposable workbench for testing editor-driven changes before they are pushed into a real deployment workflow.

If your goal is to keep WordPress editorial while making the public site static, this is where Staatic’s model is strongest: WordPress keeps doing content management, while the public request path stops depending on live PHP and database execution. That same private-origin, public-static split is also the main security advantage described in What the Essential Plugin incident means for WordPress security.

This is also the right moment to settle one process question teams often delay: after launch, who publishes the static site, and from where?

Phase 4: decide how each dynamic feature will be handled after the migration

Static migrations succeed when every runtime-dependent feature has an explicit plan. If there is a vague hand-wave in the middle of the project, it tends to turn into launch-day pain.

Cloudflare’s static WordPress guide is still one of the clearest reminders here: WordPress forms, WordPress comments, and links to /wp-admin do not survive a plain static deployment by accident. You have to redesign those pieces.

Use this table as your default decision aid:

Feature	Pure static?	Usual replacement
Contact forms	Not by itself	External form service, serverless handler, or narrow dynamic endpoint
Comments	Not natively	Hosted comments such as Disqus, or remove comments
Site search	Sometimes	Client-side search for small sites, hosted search for larger ones
Login or account area	No	Keep dynamic or split into separate app area
WooCommerce cart and checkout	No	Keep dynamic or move to hybrid architecture
Editorial previews	Not by itself	Private origin preview, preview deploys, or separate review workflow
AJAX filters	Usually no	Replace with prebuilt pages, client-side filtering, or dynamic helper
Personalization	Limited	Client-side personalization or hybrid delivery

Be honest during this phase. If the site depends on a feature that only works with a live application server, calling the project “static” does not solve anything.

Useful rules of thumb:

• If a feature collects data, it needs a submission path.
• If a feature depends on user identity, it usually stays dynamic.
• If a feature only reads a fixed dataset, it often works well client-side.
• If a feature needs low-latency server logic on every request, plan for hybrid.

Two practical examples:

• If your site search only needs to index a few hundred pages, client-side search is often enough.
• If your contact form currently posts to WordPress, assume it is broken until you have tested the replacement end to end.

If you are using Staatic specifically, this is the phase where the forms integration and search integration docs become relevant. For comments, the existing tutorial on enabling Disqus comments is the closest how-to in the current archive. If you are not using Staatic, the same architectural decision still applies: remove the runtime dependency, or replace it deliberately.

Phase 5: choose the deployment model and publication workflow

Your deployment model should match the site complexity and the editorial cadence. There is no prize for choosing the fanciest workflow if the team will not actually use it.

For very simple sites, branch-based static publishing can still be enough. GitHub Pages remains a valid low-complexity option when you do not need much control over the build process. But GitHub’s current guidance leans toward GitHub Actions and custom workflows for modern Pages deployments. If you need a custom build, artifact generation, or nontrivial deployment logic, do not stretch branch-only publishing beyond its useful limit.

For teams that publish frequently, build automation should be part of the migration, not a nice-to-have. Netlify build hooks are a good example of the pattern: a simple POST request can trigger a rebuild, optionally with a target branch, custom title, or cache clearing. Build hooks only work while builds are active, and the target branch must already exist in the deployment history. The same idea applies across platforms.

Choose one of these models deliberately:

Model	Best for	Tradeoff
Manual export and upload	Small sites that change rarely	Easy to understand, easy to forget
Branch-based static publishing	Small to medium sites with Git-based publishing	Limited control over complex build logic
CI pipeline with GitHub Actions	Teams that need validation, artifacts, and repeatability	More setup, but much safer for ongoing operations
Build-hook-triggered deploys	Editorial teams that publish from WordPress and want near-automatic deploys	Needs monitoring so failed builds do not go unnoticed

If GitHub Pages is your destination, the existing tutorial on hosting WordPress sites on GitHub Pages is the most relevant Staatic-specific implementation guide.

Before launch, document this workflow clearly:

• What exactly triggers a rebuild?
• Who can approve or promote production deploys?
• Where do preview builds live?
• How does the team know that a content change actually reached production?
• What happens when a build fails?

If you cannot answer those questions in one page, the migration is probably not operationally ready.

Phase 6: validate URLs, SEO, and content completeness before cutover

Do not launch a static site that is merely visually similar to the old one. Validate the URL model and public output directly.

Check all of these before cutover:

• permalink structure and trailing slash behavior
• canonical URLs and Open Graph URLs
• redirect map from old paths to new paths
• XML sitemap coverage
• robots.txt behavior
• menus, breadcrumbs, and internal links
• category, tag, author, and archive pages
• paginated content and next/previous links
• media paths, downloads, PDFs, and image URLs
• structured data and SEO metadata
• custom post type archives and any manually curated landing pages
• hreflang or locale-specific paths if the site is multilingual

If possible, compare the exported site against a known-good URL inventory instead of browsing randomly. This matters most on older WordPress sites where URL behavior has drifted over time.

Two failure modes deserve special attention because they show up all the time:

• links that still point to /wp-admin, preview URLs, or the private origin
• content that exists in the CMS but never made it into the export

If you changed WordPress URLs during the migration, also verify that replacement was done safely. WordPress data often contains serialized values, so a naive database find-and-replace can break widgets, settings, or builder data. WordPress migration guidance is explicit here: use serialization-aware tools and do not rewrite guid values just because the origin moved.

If you are using a crawler-based exporter, also review whether additional URLs, sitemaps, or path rules are required. That is where more advanced configuration becomes important. For Staatic users, the Build Settings docs and the guide on advanced publication process customization are the relevant deep dives.

Phase 7: test the generated static site like a production release

Treat the first full export like a release candidate, not a convenience preview.

Run a real smoke test:

• open the home page, primary landing pages, and top traffic pages
• test mobile and desktop navigation
• verify CSS, JavaScript, fonts, and images load correctly
• submit every public form that is supposed to remain available
• test search if search is part of the public experience
• test archive pages, pagination, and filtered landing pages
• test downloads, media embeds, and outbound integrations
• confirm that cookies, analytics, and tag manager behavior still match policy expectations
• verify that a new WordPress content change can move through the publication workflow and appear publicly

Also decide who signs off. A practical minimum is:

• content owner for editorial correctness
• technical owner for deployment and routing
• SEO owner for canonicals, redirects, and sitemap behavior

If no one owns the sign-off, users will do it for you.

Phase 8: plan launch, rollback, and post-launch operations

Migration day should be boring. That is the goal.

Before launch:

• reduce DNS TTL if you expect a domain or platform switch
• snapshot the current live site and keep the rollback path simple
• confirm where the old dynamic site will remain available if rollback is needed
• make sure the origin is ready to be hidden, protected, or moved off the public domain

For the actual cutover, use a fixed runbook:

1. Freeze nonessential content and plugin changes.
2. Run a final sync or export from the prepared WordPress origin.
3. Review the final static artifact, not just an earlier preview build.
4. Deploy to the production target.
5. Purge or refresh CDN caches if your platform requires it.
6. Switch DNS or production routing.
7. Run a short post-cutover smoke test on the live domain.
8. Trigger rollback immediately if core pages, redirects, or forms fail.

After launch:

• monitor 404s and missing assets
• watch for stale deploys and failed rebuilds
• confirm that editors understand the new publish path
• keep the WordPress origin maintained even if it no longer handles public traffic

One operational detail teams often miss after going static: if the WordPress origin receives little direct traffic, scheduled tasks may stop behaving the way they did before. If you still rely on WordPress cron-driven behavior on the private origin, move it to a real cron or task scheduler. Do not rely on low traffic to trigger it reliably. The existing guide on optimizing WP-Cron performance covers the fix.

The goal is not just to launch. It is to leave behind a model the next operator can actually run.

The short version: if you only check three things

If you are short on time, these three checks catch most bad migrations:

1. Confirm that the site is actually a fit for static delivery.
   If the public experience depends on logged-in state, ecommerce runtime, or per-user personalization, plan hybrid instead of forcing a pure static solution.

2. Make an explicit plan for every dynamic feature.
   Forms, comments, search, previews, and account-related behavior should never be left as “we will sort that out later.”

3. Test the ongoing publish workflow before launch.
   One successful export is not enough. You need to know that the second, third, and twentieth content change will also reach production safely.

Final migration checklist

Before you migrate

• Confirm the public site is a realistic fit for static delivery.
• List every public feature that depends on WordPress at request time.
• Classify the project as full static, static plus helpers, or hybrid.
• Inventory important URLs, archives, downloads, and media paths.
• Audit plugins, theme behavior, and custom runtime dependencies.
• Upgrade PHP and platform components to a current, supported baseline.
• Remove unused plugins and freeze nonessential changes.
• Back up the site before changing origin, routing, or deployment behavior.
• Move WordPress to a separate origin or plan how it will be isolated.

Before cutover

• Decide how forms will work after the migration.
• Decide how comments will work after the migration.
• Decide how search will work after the migration.
• Decide how previews and editorial review will work after the migration.
• Decide which areas must remain dynamic.
• Choose a deployment target and a publication model.
• Decide whether deploys are manual, CI-driven, or hook-triggered.
• Create a preview and approval workflow if multiple people publish changes.
• Validate canonical URLs, redirects, sitemaps, and robots.txt.
• Check menus, pagination, archives, internal links, and metadata.
• Confirm no public links still point at /wp-admin or the private origin.

Launch day

• Test the generated site on desktop and mobile.
• Test every kept form, search path, and integration.
• Publish a real content change through the final workflow before launch.
• Prepare rollback, DNS, and cache-clearing steps.
• Restrict or hide the WordPress origin after cutover.

After launch

• Monitor for 404s, stale deploys, and missing assets after launch.
• Keep the WordPress origin maintained even if it no longer handles public traffic.
• Write down the post-launch editorial runbook so the workflow stays usable.

Where Staatic fits

If your goal is to keep WordPress as the editorial system but stop using it as the public runtime, Staatic fits that model directly. In practice, the work usually breaks into three parts: prepare and isolate the WordPress origin, verify how publishing will work, and then configure build and deployment behavior for the destination you actually want to use.

The most useful starting point is the Preparation guide. Once the origin model is settled, the next docs that usually matter are Publishing, Build Settings, and Deployment Settings.

If you want a concrete walkthrough for moving WordPress off the public domain and serving a static site instead, start with using WordPress as a static site generator. If you need a Git-backed destination, hosting WordPress sites on GitHub Pages is the closest destination-specific guide in the current archive.

The product choice matters less than the operating model. Decide what has to stay dynamic, isolate WordPress properly, and make the publication workflow trustworthy. If you are starting from scratch, begin with the Preparation guide and use this checklist to work forward from there.