Moving a WordPress publication to a static site is not just a matter of saving the homepage. The publication includes posts, pages, categories, tags, media, dates, and established URLs. A successful migration preserves those relationships while removing dependencies that no longer belong in the deployed reading experience. The resulting site should be understandable as a collection of files, not as a broken imitation of a running WordPress application.
This guide proposes a repeatable migration workflow for an editorial site. It uses both a content export and available static files, because those sources answer different questions. The WordPress Dev API and CMS Dev API topic guides explain the input boundaries. Here the emphasis is on building a complete, testable publication without silently changing what the source material says.
Inventory the sources before rendering
Treat the WordPress content export as a description of content and its relationships. Treat the static export as evidence of the files that were actually captured. Neither should be assumed to replace the other. Build an inventory of published posts, pages, taxonomy terms, attachment records, and local media before designing templates or moving URLs.
Record source identifiers as well as readable slugs. Two similarly named categories may be separate terms with different memberships. A media attachment may refer to an original file and several resized versions. Keep those distinctions in the inventory so later cleanup can be deliberate and reviewable rather than an accidental consequence of filename matching.
Capture complete collections
An API-based import needs to process every page of a collection. Fetching the first response and assuming the site is small can silently omit older articles or taxonomy terms. The WordPress REST API pagination documentation describes collection pagination and the total-count response headers. Use the documented behavior to establish coverage rather than inferring completion from a convenient sample.
Define an extraction boundary. Content can change while a long import is running, so record when the capture occurred and which source revision or export was used. When the source cannot supply a consistent snapshot, note that limitation in the migration report. A precise record of the available material is more valuable than an unsupported claim that every changing resource was captured atomically.
Normalize content without rewriting its meaning
Create an intermediate record for each article with its source identifier, title, permalink, body, publication date, modification date, categories, tags, and media references. Decode markup entities carefully, but do not silently replace the author’s terminology or add new factual claims. Normalization should prepare data for rendering, not become an unreviewed editorial rewrite.
Separate source-derived fields from new editorial additions. For example, a newly written excerpt or a new topic tag can be useful, but it should not be mistaken for something found in the export. Keep a change log in the handoff materials. That record makes it possible to explain why the new site’s presentation differs while its original content remains traceable.
Resolve media against actual bytes
Map attachment URLs to local files and verify that those files can be opened. Metadata that names an image does not prove the image is present or intact. Check dimensions and file integrity, then build a report for missing or corrupt assets. Preserve useful originals and generate optimized derivatives for the new layout without discarding the source inventory.
Do not publish a broken image and hope the old server will remain online forever. Equally, do not substitute an unrelated stock picture without an editorial reason. New typography cards can provide a coherent category system, while original article images remain available where they support the source content. Keep descriptive alt text in HTML rather than relying on text embedded in the artwork.
Preserve taxonomy before reorganizing navigation
Categories and tags are different editorial structures. A category often describes a broad section; a tag can connect a narrower concept across sections. Preserve the exported term names, slugs, and memberships first. Then create a more usable visual grouping for navigation without pretending that the source taxonomy already had that hierarchy.
Similar names deserve review, not automatic merging. An older short category label may coexist with a newer expanded label. Both can remain available at their established archive URLs while the main navigation emphasizes the clearer one. Empty archives should be handled honestly and kept out of indexable search results when they add no useful content.
Build a URL disposition map
For every published source URL, decide whether the destination is a retained article, a new equivalent page, or a populated archive. Record that decision. Avoid sending every old path to the homepage; doing so loses context for readers and makes the migration harder to inspect. A useful destination should answer the reason someone followed the original link.
A static deployment can serve directory index files without custom routing. Generate actual directories for public paths and use clean URLs in navigation, canonical metadata, and feeds. When an old path becomes an alias, provide a meaningful destination and consistent canonical handling. Keep temporary implementation paths out of the public sitemap.
Remove runtime behavior that no longer exists
Imported WordPress markup can contain forms, plugin controls, search boxes, or buttons that depend on a server-side application. Keep only the behavior that the static site genuinely supports. A contact email link is honest; a form that cannot submit anywhere is not. Remove account and newsletter controls unless a real, explicitly chosen service is part of the deployment.
Also remove unrelated template brands, administration assets, and active scripts from imported article bodies. Sanitize the markup with an allowlist while preserving useful headings, paragraphs, lists, code, and tables. Do not copy the old plugin runtime simply because it appears in the static archive. The new public site should have a small, intentional dependency surface.
Render from one content model
Generate article pages, category archives, tag archives, navigation, and related-content links from the same normalized records. This reduces the chance that a title changes in one place but not another. It also makes it easier to check which pages are discoverable and which imported items have no meaningful route from the main site.
The same model should drive the sitemap and RSS feed. Include complete article content in feed entries when that is the publication’s intended policy. Preserve genuine publication dates and avoid claiming every old article was recently updated merely because the site was rebuilt. A new stylesheet is not automatically a substantive editorial revision to every article.
Test the output as a website
Serve the generated files over a simple local HTTP server. Follow internal links, check image requests, and confirm that every clean URL maps to the expected directory index. Validate fragments as well as page paths: a table-of-contents link can be broken even when the article itself loads correctly. Inspect the sitemap and feed as actual XML documents.
Test the reading experience at narrow and wide widths. Check that a sticky header does not cover anchored headings, code blocks do not force the entire page wider than the screen, and navigation remains usable with a keyboard. Disable JavaScript and verify that essential content and ordinary links still work. Progressive enhancement should improve the site, not hold the article text hostage.
Keep the handoff reproducible
Deliver the deployable files separately from build tools, source records, and migration reports when practical. The public package should be ready to extract into a hosting root without installing dependencies. The companion materials should explain how to rebuild it, which source records were retained, and which URLs or assets required special handling.
Maintain a known-good copy before replacing an existing deployment. Test a staging location first, including old incoming URLs that matter to the publication. The static website topic describes the runtime boundary, while the DNS automation guide covers the separate responsibility of moving a hostname to a new destination.
Conclusion: migrate the publication, not just the markup
A sound migration preserves the editorial relationships that make a site useful. Inventory the sources, verify the media, retain meaningful URLs, and render from one documented model. Then test the files as readers and crawlers will encounter them. The result is a publication that can stand on its own, with source content that remains traceable and a deployment that does not depend on invisible WordPress behavior.
