Migrating a static HTML site to WordPress

A static HTML site is made of files: one page, one file, often written by hand or with an editor that no longer exists. Moving it to WordPress lets you edit content without touching code, and add a blog, forms and plugins. But there is no database to export and no migration tool that does it all: the difficulty comes from the starting point.

This article covers what is specific to leaving an HTML site. If your site is already on WordPress and only changes server, see moving a WordPress site to a new host; if it is on Wix, migrating from Wix to WordPress.

On a static site, what exists is what is on the server. Get a full copy of the files over FTP or SFTP, and crawl the site to compare: the crawl finds the pages linked to each other, the server reveals the orphan pages (old offers, thank-you pages, campaign pages) that sometimes still receive links or traffic. Search Console completes the list with the pages Google knows.

Also note the files that are not pages: images, documents, style sheets and scripts called by other sites, server-side includes (SSI, PHP) that assemble the header and footer.

The URLs of a static site often end in .html, those of WordPress with a slash. Two options:

• keep the same addresses: a /%postname%.html permalink structure allows it for posts; for pages, you need a plugin or a dedicated rule. Nothing to redirect, but a lasting constraint;
• adopt WordPress addresses and redirect each old address with a 301 to its new page, one by one. A generic rule that removes .html only works if page names stay the same, which is rare when the site is reorganised.

Either way, think of index.html: the folder address and the file address must lead to the same page.

HTML page import plugins read the files and create the matching pages in WordPress, but the result almost always needs rework: a static site mixes content and layout (layout tables, inline styles, font tags, menus copied into every file). For a site of a few dozen pages, pasting the text into the block editor often gives a cleaner result in no more time.

Take the opportunity to restore a clear heading hierarchy, complete the title and meta description tags (often identical on every page of a static site) and the image alt texts. Our article on migrating editorial content covers these points.

Images and documents can keep their original paths, placed as they are on the new server: it is the safest choice for those that are indexed or linked from other sites. If they move into the WordPress media library, their addresses change and are redirected like pages (see redirecting images).

The forms of a static site often send their data to a custom script or an external service: rebuild them with a form plugin and test each submission.

For the rest, the migration follows the steps of any CMS change: build the site on a staging server, prepare the redirect plan, switch, check. They are described in the CMS change procedure.

If you valued the benefits of static (speed, smaller attack surface), plugins such as Simply Static or WP2Static publish a static version of a site managed in WordPress. Dynamic features (comments, search, forms, shop) then do not work as they are.