How to Migrate from WordPress to a Static Site Generator

In this article, you’ll learn how to turn your WordPress-driven site into a static site with just a handful of powerful tools. We’ll focus on migrating from WordPress to a static site generator, and cover some of the alternatives including using a headless CMS. Why would you do this? Because you can get massive speed gains and therefore boost your site’s performance in search engines, and also reduce (or eliminate) your hosting bill and dramatically improve your security.

The Benefits of Going Static

Fantastic speedups are certainly no small feat, but that isn’t all you can get from turning your dynamic WordPress (WP) site install into a static one. Let’s summarize:

• Reduced page load speed. Pages aren’t preprocessed at runtime (user’s request), and content isn’t pulled from the database. As a result, the web server will respond a lot faster (10x and even more).
• Reduced latency through CDN’s. You can just drop these now-static pages on a distributed content delivery network (CDN), hugely improving response times all around the world.
• Easier management. Once you’ve set your workflow — which is what we’ll do here — you’ll see that you actually won’t need to spend any additional effort in maintenance, WP upgrades or server updates.
• Dramatically enhanced security. HTTPS out of the box with only static pages that aren’t being run by some bogus PHP version or an outdated WordPress, and most probably not even by Apache.
• Improved SEO. Google values not only your content but how easy and secure the access to it is. This is, in fact, one of the few search engine optimizations still valid these days: a faster, more secure site will perform better on the search engine results page.
• Peace of mind. No need to upgrade PHP, no unpatched WP concerns, even no Linux servers being managed. Just relax and have your coffee/beer/tea/ginseng after your deployment.

“Is WordPress Secure?” Well, It’s Complicated …

WordPress developers follow good standards and security practices, although a long-term support (LTS) is still very much missing. However, because of its very architecture, there are things that are out of the WP Security Team’s hands and transferred directly into yours:

• updating your server
• installing WP updates
• installing PHP updates
• installing updates for plugins and themes (if available, at all)
• managing WP and PHP (neither of which has LTS) mayor upgrades every once in a while

All of this is a constant process, and plugins are not a minor threat, especially unmaintained ones. These often have security holes by which attackers take control of WordPress installations. That is precisely why it took Automattic years to support some plugins on WordPress.com, the commercial, managed version of WordPress. WordPress could be secure with a fair amount of conscious effort. And while you could argue that these are efforts any decent developer should put in, it’s also true that you can potentially lift this weight off your shoulders by turning your WP site into a static one, and while doing so redefining its architecture and removing for good nearly all of the available spots that could turn into a security threat. After all, there isn’t much an attacker can do with plain HTML, CSS files and flat images. However, you’ll still need to take care of cross-site scripting and cross-site request forgery. 🤷‍♂️

Preliminaries: Enter Static Site Generators

Provided: Netlify We briefly reviewed static site generators (SSGs) on our list of 100 Jamstack tools, APIs and services to power your sites article, and there are tons more than we’ll cover here, so make sure to check StaticGen to learn more. Some SSGs are specifically targeted at WordPress, such as WP2Static, but we’ll focus on a more general-purpose one, Gatsby.js — the “free and open source framework based on React that helps developers build blazing fast websites and apps”.

Migrating WordPress

I’ll have to admit that, as much as I wanted this process to be dead simple, there are a number of things that could make it a little more cumbersome and time consuming, such as the existing plugins you may have installed (the fewer the easier) and the way in which you’ve formatted your posts (the simpler the better). Think of this as a guideline that you might need to adjust to your specific case. Essentially, this is what we’ll do:

1. set up Gatsby.js
2. export WP posts/pages to Markdown
3. generate the static assets

Step 1: Fork the Gatsby Starters

We’ll start by forking either the Gatsby Advanced Starter or the Gatsby Material Starter, both of which are tweaked general purpose primers for a Gatsby.js project, the second one with an “opinionated” Material Design template (demo). Right off the bat these starters will get you a fully featured React-powered progressive web application (PWA) with all batteries included:

• blazing fast loading times (pre-rendered HTML, JS auto-chunk loading)
• Markdown posts (code syntax highlight, embed YouTube videos, embed Tweets)
• pagination, tags, categories
• Disqus support
• NetlifyCMS support
• SEO goodies (Google Analytics support, Sitemaps and robots.txt generation, meta tags, Schema.org JSON-LD for Google Rich Snippets, OpenGraph Tags for Facebook/Google+/Pinterest, Twitter Tags for Twitter Cards)
• syndication feeds (RSS)
• social features (Twitter, LinkedIn and Telegram share button; Facebook and Reddit share/share count)
• development tools (ESLint, Prettier, Remark-Lint, deploying support for GitHub pages and Netlify, CodeClimate config file and badge)
• and more!

The claim is that after a successful migration and deployment to a CDN, your site should be so performant that an audit with Google Lighthouse should report the best results possible:  

Installation and Configuration

You’ll first need to install Gatsby.js and Node.js so that you can use the gatsby CLI and the Node.js packet manager npm. For Node.js just download and install, for Gatsby.js see the Quick Start or Set Up Your Development Environment. Once you sort that out, this is how you start a project (remember you can also clone gatsby-material-starter):

gatsby new YourProjectName https://github.com/Vagr9K/gatsby-advanced-starter
npm run develop # or gatsby develop

The configuration for the Advanced (example) and Material (example) starters are pretty much the same. As mentioned, there is Netlify CMS support right out-of-the-box which you can sync with your Git repository enable by editing static/admin/config.yml as follows:

backend:
  name: github
  branch: master
  repo: your-user/your-repo

You can also integrate Netlify CMS with GitLab or Bitbucket (see Backend Configuration).

Step 2: Export WordPress Posts

In some cases you might be able to convert an XML exported file with all of the posts and pages into Markdown files by simply using ExitWP. However, depending on your WP setup and tweaks, this process can demand a bit of craft; but still manageable and worth doing. Tania Rascia wrote a good overview about how she dealt with this part of the process on her article The End of an Era: Migrating from WordPress to Gatsby.

Step 3: Build the Pages

Given that Gatsby.js is a React app, being a React developer or at the very least a seasoned JavaScript programmer will help you a great deal in order to customize Gatsby tightly. Knowing some GraphQL will also become very handy in making queries and digging through your data, especially now that those pages aren’t served by a MySQL database. Fortunately, Gatsby.js is very well documented. Here are some useful resources:

• Programmatically create pages from data
• Creating and Modifying Pages
• Creating Pages from Data Programmatically

Now that you’re done with pages generation, you can securely drop the assets (static pages and images) pretty much anywhere! Check the Hosting section of our list of 100 Jamstack tools, APIs and services to power your sites for some ideas, and take a look at our article on hosting static sites for free with an automated pipeline.

Security, for Once!

Even if your WordPress admin is on the Internet (and there’s a lot an .htpasswd file could do for you), and even if it’s unpatched, and even if your WP backed gets defaced, none of this will affect your already deployed static pages, as the front end is “detached” from it. Don’t get me wrong, even if you run WordPress on a local area network (LAN) behind a firewall, you should still update it regularly.

Losing My Head: Headless CMS

If you’ve got up until this point, you may not need to use WordPress anymore. While you can keep the admin to generate new posts and pages, another workflow would be using another headless CMS to generate the static files for you and sync them to your repository, all automated and in a single step. Enter the “headless CMS” — a content management system that still runs as a back-end instance somewhere, but that is completely detached from the actual live website. WordPress is a common choice of headless CMS for static sites, and may in fact be the most common for large-scale SSG deployments. While a migration approach can cover many situations, you may have too much legacy content or too much of your content process built into WordPress for a wholesale migration to be immediately feasible. This is particularly true for large content operations and digital media businesses. If you have less history to manage, though, it’ll serve you well to look at more modern approaches to content management — the migration away from a dynamically served site is as good a time as any to make this kind of change. The migration we implemented already supports Netlify CMS, although we won’t cover how to use a headless CMS here. This is a topic we’ll return to with its own article in the near future.

Digging Further

There’s only so much that we can cover in an article like this, so here are some additional resources on the topic of migrating WP with an SSG.

Gatsby.js

The official documentation hub and blog are very comprehensive and very well written. Here are some WP-related articles:

• Getting Started with Gatsby and WordPress
• Migration to Gatsby.js and Jamstack from WordPress
• How to Build a Blog with WordPress and Gatsby.js: Part 1, Part 2 and Part 3

Hugo

Based on the Go programming language, Hugo is another big name for SSGs with plenty of templates available, and a solid option you might consider to Gatsby.js. There are tools to migrate WordPress to Hugo. If you check out these guides, you’ll see that while you’ll have less flexibility, the process should be quite a bit simpler that with Gatsby.js:

• Migrating From WordPress to Hugo by Chris Ferdinandi
• A step-by-step guide on migrating from WordPress to Hugo by Mattias Geniar
• Switching From WordPress To Hugo by Christopher Kirk-Nielsen

Jekyll

If you manage to set up the Ruby environment, Jekyll, the SSG that can transform your plain text into static websites and blogs, is even more straightforward to use, although it will only generate static pages, not web applications like Gatsby.js. Just as with Gatsby, you can use the Python-based ExitWP to generate Markdown out of WP. And you also have the Windows executable wpXml2Jekyll to general Jekyll-ready Markdown files from a WP XML export. Some useful articles:

• Migrating a blog from WordPress to Jekyll by Sam Atkinson
• Migrate from WordPress to Jekyll: Part 1 and Part 2 by Florian Courgey
• Jekyll For WordPress Developers by Mike Neumegen

Software-as-a-Service (SaaS) Solutions

Gatsby Cloud offers support to build and maintain Gatsby.js sites for free or for a fee, where you could automate your fast builds, access to previews, generate daily edits, and fire deployments with ease to Netlify, Cloudflare, AWS CloudFront or Akamai. HardyPress also generates static WordPress sites, and for a fee you’ll have an admin panel from where you can enter the credentials to access your online WP installations to manage everything on the spot: shut down live WP installs that were already imported, transparently deploy to a global CDN, HTTPS, forms, and search. Other WP-related SSGs with commercial support are Shifter, Strattic, and Sitesauce.

Conclusions and a Thought: Is the King Dead?

Peace of mind is huge for me, and it’s one of the main reasons why I stopped developing WordPress sites years ago. I hated that a bug might come up (zero day or otherwise) at any given time and that, if not patched in time, it would jeopardize my work. And believe me, the amount of times I’ve seen my websites defaced or simply stop working because of a major — and sudden — PHP or WP upgrade, are more than I care to admit. But these security concerns are gone if your site is static! In my opinion, WordPress already reached its “peak oil” situation in 2012 (see Google Trends: WordPress 2004-present). And if it doesn’t adapt very quickly, it will only keep losing market share in favor of technologies that can do a faster and more secure job with better integrated workflows. Matt Mullenweg, creator of WP and CEO of Automattic, also acknowledged this when he started encouraging developers to “learn JavaScript deeply“, and in a bold move got rid of WP’s PHP back-end in favor of JavaScript with the introduction of Calypso (read his own reflection on the process). This sent shockwaves (and even panic) through the community, with rumors of WordPress ditching PHP altogether. And Gutenberg was nothing but another step in that direction. The king might keep its crown after all if it manages to reinvent itself. And if not, hey, having powered nearly a third of the Internet was no small feat — so long live the king! 👑 Read about how SitePoint moved its front end to Gatsby powered by a WordPress headless CMS in 2020.

Jamstack Foundations

Get up to speed with the Jamstack. Our Jamstack Foundations collection helps you take your first steps into the Jamstack and beyond, and we’re adding to it constantly. We’ll bring you the tutorials you need to become a pro. You can always refer to our index as it’s updated at the end of our Introduction to the Jamstack: ➤ Jamstack Foundations

Frequently Asked Questions (FAQs) on Migrating WordPress to a Static Site Generator