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.
- 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.
Preliminaries: Enter Static Site Generators
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”.
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:
- set up Gatsby.js
- export WP posts/pages to Markdown
- 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 new YourProjectName https://github.com/Vagr9K/gatsby-advanced-starter npm run develop
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
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
Fortunately, Gatsby.js is very well documented. Here are some useful resources:
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.
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.
Here are some WP-related articles:
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:
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:
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.
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.
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.
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: