How to Migrate from WordPress to Jekyll Without Losing SEO
Migrate your WordPress site to Jekyll while preserving rankings — keep URLs intact, set up 301 redirects, transfer authority, and resubmit your sitemap correctly.
Migrating from WordPress to Jekyll can destroy your search rankings if done carelessly — or preserve them completely if done right. The difference is almost entirely about URLs and redirects. This guide focuses specifically on the SEO side of migration.
Why Migrations Hurt Rankings (And How to Avoid It)
When you migrate a site, Google typically sees:
- Broken URLs — old pages return 404, Google drops them from the index
- Changed URLs without redirects — link equity built up over years evaporates
- Missing content signals — metadata, structured data, and canonicals vanish
- Crawl errors — Google Search Console fills with errors, trust drops
All of these are avoidable with the right preparation.
Step 1: Audit Your Current Rankings Before You Touch Anything
Before migrating, document what you have to protect.
Export your current rankings:
- Open Google Search Console
- Go to Performance → Search results
- Export the full report (all queries, all pages)
- Save it — this is your baseline
Identify your top pages: Sort by impressions or clicks. The top 20 pages drive the majority of your traffic. These are the pages that absolutely must have working redirects.
Check your backlinks: Use Ahrefs, Moz, or the free Google Search Console Links report to export pages with inbound links. Any URL with external links pointing to it must either be preserved or redirected.
Step 2: Decide on a URL Strategy
This is the single most important SEO decision in your migration.
Option A: Match Your WordPress URL Structure (Safest)
WordPress defaults to /YYYY/MM/DD/post-title/. Set your Jekyll permalink to match:
# _config.yml
permalink: /:year/:month/:day/:title/
With matching URLs, you need zero redirects. Google sees no change. This is the safest option if your WordPress URLs are already clean.
Option B: Improve Your URL Structure (Riskier but Better Long-Term)
WordPress date-based URLs are not ideal for SEO — they signal post age and add unnecessary path segments. Cleaner URLs like /blog/post-title/ perform better.
# _config.yml
permalink: /blog/:title/
If you change URL structure: every old URL must have a 301 redirect to the new one. Skipping this step will cause ranking drops.
Option C: Keep WordPress Slugs, Drop the Date
permalink: /:title/
This is a good middle ground — shorter URLs than WordPress default, but slugs are unchanged so most existing links still work.
Step 3: Set Up 301 Redirects
301 redirects tell Google: “this content has permanently moved to a new URL.” They pass ~90-99% of link equity to the new destination.
Method A: jekyll-redirect-from Plugin
Add old URLs to each post’s front matter:
---
title: "My Post Title"
redirect_from:
- /2024/03/15/my-post-title/
- /2024/03/my-post-title/
- /?p=1234
---
Jekyll generates redirect pages at those URLs that immediately redirect to the current post URL.
Limitation: jekyll-redirect-from creates HTML redirect pages, not true HTTP 301 redirects. Google handles these well, but HTTP 301s via your hosting platform are more reliable.
Method B: Netlify Redirects (Recommended)
Create _redirects in your site root:
/2024/03/15/my-post-title/ /blog/my-post-title/ 301
/2024/03/20/another-post/ /blog/another-post/ 301
/?p=1234 /blog/my-post-title/ 301
/?p=5678 /blog/another-post/ 301
Netlify processes these as real HTTP 301s — the gold standard.
Method C: Cloudflare Pages Redirects
Create _redirects (same format as Netlify) or use _headers for more complex rules. Cloudflare processes these as HTTP 301s at the CDN level.
Method D: Match URLs Exactly (No Redirects Needed)
As mentioned in Step 2, the cleanest approach is matching your Jekyll permalink structure to WordPress. Then there are no redirects to manage.
Step 4: Preserve Your Metadata
WordPress stores titles, descriptions, and OG images in plugins like Yoast SEO or Rank Math. You need to transfer this to Jekyll front matter.
Export Yoast data: Many Jekyll importers pull Yoast SEO data automatically. Check your imported posts for:
---
title: "Exact title from Yoast"
description: "Exact meta description from Yoast"
image: /assets/images/og-image.jpg
---
If the importer didn’t pull this data, open your WordPress admin, go to each top post, and manually copy the Yoast title and description into the post’s front matter.
Install jekyll-seo-tag:
gem "jekyll-seo-tag"
Add `
` to your <head>. This auto-generates all SEO tags from your front matter.
Step 5: Handle WordPress-Specific URL Patterns
WordPress generates several URL types that need attention:
Category URLs: WordPress creates /category/tech/, Jekyll creates /tech/ by default. Set up redirects or configure Jekyll to match:
# jekyll-archives config
permalinks:
category: /category/:name/
Tag URLs: Same issue — match WordPress’s /tag/name/ pattern:
permalinks:
tag: /tag/:name/
Author archives: WordPress creates /author/username/. Unless you replicate this, set up redirects to the homepage or about page.
Feed URL: WordPress feeds live at /feed/ or /?feed=rss2. Jekyll’s jekyll-feed plugin creates /feed.xml. Set up a redirect:
/feed/ /feed.xml 301
/feed.xml /feed.xml 200
Page URLs: WordPress pages often have trailing slashes (/about/). Make sure your Jekyll pages have matching permalinks:
---
permalink: /about/
---
Step 6: Migrate Your Sitemap
Before going live, have your new sitemap ready to submit.
Install jekyll-sitemap:
gem "jekyll-sitemap"
Your sitemap auto-generates at /sitemap.xml.
After going live:
- Open Google Search Console
- Go to Sitemaps
- Remove your old WordPress sitemap URL
- Submit the new
/sitemap.xml - Request indexing on your most important pages via URL Inspection
Step 7: Verify Structured Data Is Intact
WordPress plugins like Yoast add structured data (JSON-LD) automatically. On Jekyll, you add it manually.
In your _layouts/post.html:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": {{ page.title | jsonify }},
"description": {{ page.description | jsonify }},
"datePublished": "{{ page.date | date_to_xmlschema }}",
"dateModified": "{{ page.last_modified_at | default: page.date | date_to_xmlschema }}",
"author": {
"@type": "Person",
"name": {{ page.author | default: site.author | jsonify }}
}
}
</script>
Test with Google’s Rich Results Test before and after migration to verify no structured data was lost.
Step 8: The Migration Go-Live Sequence
Order matters. Do this exactly:
- Build and test Jekyll site locally — verify all pages render, no broken links
- Set up redirects on your hosting platform — before pointing DNS
- Deploy to your hosting platform — but keep WordPress live
- Test the new site at its staging URL — check 5-10 key pages manually
- Point DNS to the new host — this is when migration goes live
- Verify redirects are working — check old URLs return 301, not 404
- Submit new sitemap to Google Search Console
- Monitor Search Console for the next 2 weeks — watch for crawl errors and ranking changes
Step 9: Post-Migration Monitoring
In the 4 weeks after migration, check weekly:
Google Search Console → Coverage: Should show no significant increase in 404 errors. If you see new 404s, find the URLs and add redirects immediately.
Search Console → Performance: Compare impressions and clicks week over week. A small drop is normal (Google is re-indexing). A large sustained drop means redirects are missing.
Core Web Vitals: Jekyll sites typically score significantly better than WordPress. Confirm your scores improved in PageSpeed Insights.
Expected Timeline
| Week | What to Expect |
|---|---|
| 0–1 | Google discovers changes, some ranking fluctuation |
| 1–2 | Re-indexing, potential minor dip |
| 2–4 | Stabilisation, rankings return to pre-migration levels |
| 4–8 | Rankings often improve — Jekyll’s speed benefits kick in |
A well-executed migration should recover fully within 4 weeks and often improve rankings within 2–3 months as Google rewards the faster, cleaner site.
Migrating to Jekyll? Browse themes on JekyllHub to find the right design before you start — picking your theme first makes the technical migration easier to plan.