Moving from WordPress to Jekyll (and static site generators in general)

As I mentioned in my post earlier this week, we just completed a migration from WordPress to Jekyll. I outlined a couple of reasons for it but basically came down to preference, speed, and ability to make changes easily.

Frameworks like Jekyll (or Astro) aren’t for everybody, although they make a lot more sense in the general environment of AI proliferation, markdown becoming the lingua franca of LLMs, and a general trend toward headless sites. Everybody knows how insecure WordPress can be, although this is largely mitigated by working with a reputable host.

The biggest issue was speed. As a platform company, we move very fast and we always felt limited by what we could do with WordPress and we were constantly bottlenecked by whether or not we had WP developers available. But it’s hard to find good developers for any framework and especially for WordPress. When you find someone who is good at WordPress development, it means they are good at pretty much everything else they try and so it feels like a waste of talent to have them work on WordPress. It’s like a built-in brain drain.

Since the advent of coding agents like Claude Code, it has now become easier to completely route around this problem by simply migrating to another platform. We chose Jekyll for the reasons I’ll discuss in the next section.

Architecture decisions that led to Jekyll

Just last week, Cloudflare announced a new CMS framework that they have dubbed the “spiritual successor” to WordPress. It’s based on Astro, which is one of the most popular static site generators (SSG) right now. It looks great, but we wanted something that we had experience with and was a mature framework. As I mentioned in my previous post, our site ran on Jekyll long ago so we knew it well.

For those who are not familiar: the biggest difference between a CMS like WordPress and an SSG is that there is no database (typically), nor even an application server in the latter. You’re working entirely in HTML templates, includes, layout files, config files, and then markdown for everything else.

Metadata on the page is defined as frontmatter, which is the YAML data between the --- delimiters at the top of the markdown file.

So, for example, the frontmatter for this post looks like this:

layout: post
title: "Moving from WordPress to Jekyll (and static site generators in general)"
description: "Some technical notes on how and why we moved from WordPress to Jekyll, a well-known static site generator (SSG)."
date: 2026-04-09
author: Ray Grieselhuber
permalink: /blog/rebuilding-demandsphere-with-jekyll-and-claude-code/
tags:
- Engineering
- AI Search

Other than that, these posts are just straight markdown. We start them in the _drafts folder and move them to the _posts folder when we’re ready to publish.

Migrating 288 WordPress blog posts and other pages

The area that took the most time, aside from the design, was properly migrating the existing content. The site itself has over 15 years of blog posts but, frankly, we didn’t need all of them.

So, we used our GSC tools in DemandSphere to identify the pages that actually had valuable equity and used indexing data to make the call on which pages could be left unindexed - and simply deleted - as part of the migration.

WordPress has an XML export that you can use to export everything, so we started with that. Fortunately, I was able to leverage Claude Code quite a bit to analyze each page in terms of the equity it had and very quickly filter out what we didn’t need.

It took a little more fiddling to get featured images (and images in general) migrated over properly but this was also basically an export and an import.

AI-assisted development with Claude Code

Claude Code was basically what enabled us to do what we had wanted to do for years. Everyone on our team is so busy that we never would have had time to do a proper job of this migration. It didn’t make sense to hire out the work either.

We heavily leveraged multiple sessions, CLAUDE.md, and a bunch of other .md files to keep the project on track.

The dev tools we built

The part where Claude Code really helped the most was in building nine separate dev tools that live right in the repository. We were able to leverage custom build scripts that keep these dev tools outside of the production build as well.

Most of these tools are managed by individual audit scripts dedicated to producing the output needed. So, for example, we have a lighthouse.js script, a site structure script, and so on.

We built the following:

Site Structure

This was initially one of the most helpful tools, because it served as a tiny, onboard Screaming Frog type tool. We could easily spot URLs that weren’t on the sitemap, missing / duplicate metadata, etc.

Lighthouse Auditor

As any SEO worth their salt will tell you, Lighthouse is about a lot more than just page speed and website performance. The fact that the site, in production, is all static obviously helps.

Schema Auditor

This was a great tool to help us make sure we had a baseline of schema data in place.

AEO Auditor

The AEO auditor tool helped us cover a lot of the basics for Answer Engine Optimization.

Open Graph Preview

The Open Graph preview tool lets us preview how a page will look when shared on socials like Facebook, LinkedIn, X, and Slack.

Content Similarity - Topic Clusters

We vectorized the entire site using the all-MiniLM-L6-v2 model to understand the semantic clustering of the site.

Internal Linking

Internal link auditing, when you have the embeddings of a site, is one of the best processes you can run in order to help the engines understand which topics and pages are most related.

Redirects

The Redirects tool was invaluable in making sure that we didn’t miss anything important during the migration.

Client-side search with no external dependencies

Jekyll generates a /search.json file at build time. It’s a JSON array of every page and post with title, URL, content, tags, and date. This allows for fast, client-side searching without needing a database.