Ghost to Next.js Migration Guide

Ghost is a clean, opinionated publishing platform, and for a pure editorial blog it does its job well. But the moment your site needs to be more than a blog — a marketing engine, a product surface, a member portal, or anything that mixes content with custom application logic — Ghost’s handlebars themes and closed data model start to feel like a ceiling. Teams outgrow it, and the natural landing spot is Next.js, where content becomes just one data source among many and the front end is yours to shape.

This guide walks through why teams migrate off Ghost, what genuinely changes (and breaks) in the move, a step-by-step process that keeps your content and rankings intact, and an honest read on what it costs. It is written for founders and marketing leads who want the upgrade without gambling the organic traffic they spent years earning.

Done carefully, a Ghost-to-Next.js migration is one of the lower-risk platform moves in web development — the content is portable, the URL structure is predictable, and the SEO fundamentals transfer cleanly. Done carelessly, you can drop 40% of your traffic in a week. The difference is entirely in the planning.

Why Teams Move Off Ghost

Ghost is deliberately narrow. That focus is a strength for writers and a constraint for everyone else. The most common reasons we see teams leave:

• Design and layout limits. Ghost themes use Handlebars templates and a fixed content structure. Anything genuinely custom — interactive components, unusual page layouts, conditional content — fights the system rather than flowing from it.
• Application logic. The moment you need gated tools, calculators, a directory, dashboards, or deep CRM and product integrations, Ghost has no real answer. Next.js treats those as first-class features.
• Performance headroom. Ghost is fast out of the box, but you can’t hand-tune bundle splitting, image pipelines, or edge rendering the way you can in Next.js with the App Router and React Server Components.
• Composability. Marketing teams increasingly want content, forms, analytics, and personalization living in one codebase. Next.js becomes the hub; Ghost, if kept at all, gets demoted to a headless content API.
• Cost and lock-in. Ghost(Pro) pricing scales with members and traffic. A static or serverless Next.js site on modern hosting is often cheaper at scale and never locks your presentation layer to a vendor’s theme engine.

The pattern is consistent: Ghost is right until the blog needs to become a platform. When that tips over, moving to a custom website and CRM development stack built on Next.js gives you room to grow for years instead of quarters.

What Changes and What Breaks

The good news is that Ghost’s data is portable and its URLs are sane. The friction lives in the pieces of Ghost you were relying on without noticing.

• Themes are gone entirely. Handlebars templates do not carry over. Your front end is rebuilt in React/Next.js. This is the largest single line item and the reason the move is an upgrade rather than a copy.
• Content ports cleanly. Ghost’s admin export gives you JSON, and its Content API serves posts, pages, tags, and authors as structured data. Mobiledoc/Lexical content converts to HTML or Markdown reliably with a conversion pass.
• Members and subscriptions break. Ghost’s native membership, Stripe integration, and email newsletters (via Mailgun) are platform features, not portable data. If you use them, you must rebuild on Stripe directly plus an ESP, or keep Ghost headless just for that function.
• Built-in features become your responsibility. Search, RSS, sitemaps, comments, and the members portal are all “free” in Ghost. In Next.js you implement each — usually a net positive since you get exactly what you want, but it’s real scope.
• URLs may shift. Ghost defaults to flat slugs (/post-slug/) and dated or tag-prefixed structures depending on config. Any change to your permalink pattern requires a redirect map, which we’ll cover below.

The Step-by-Step Migration Process

A dependable migration follows the same sequence every time. Skipping steps is where traffic gets lost.

• 1. Audit and inventory. Export a full list of live URLs from your sitemap and analytics. Capture every post, page, tag archive, author page, and RSS feed. Note which pages drive organic traffic — these get white-glove treatment.
• 2. Export the content. Pull the Ghost admin JSON export and, in parallel, plan to read from the Ghost Content API at build time. The API is cleaner for structured fields; the JSON export is your backup and captures relationships.
• 3. Choose your content strategy. Decide between fully decoupling (migrate content into Markdown/MDX or a new CMS and retire Ghost) or keeping Ghost headless as the content source behind a Next.js front end. Headless is faster to ship; full decoupling removes the last vendor dependency. Our note on choosing a JavaScript framework covers the tradeoffs if you’re still confirming Next.js is the right target.
• 4. Build the Next.js front end. Use the App Router with static generation (generateStaticParams) for posts so the blog stays fully cacheable and fast. Rebuild templates for the post, page, tag, and author routes. Wire next/image to your image source and migrate assets to a CDN or the /public tree.
• 5. Rebuild the invisibles. Regenerate the sitemap (sitemap.ts), RSS feed, robots.txt, structured data (Article/BlogPosting JSON-LD), and canonical tags. These are easy to forget and heavily weighted by search engines.
• 6. Map and implement redirects. If any URL changes, build a 1:1 redirect map with 301s. This is non-negotiable for SEO and gets its own section below.
• 7. Stage, QA, and cut over. Deploy to a staging domain, crawl it, diff it against the old site, and only then flip DNS. Keep the old Ghost instance readable for a rollback window.

Because so much can go quietly wrong between steps four and seven, many teams bring in professional website migration services to own the redirect map, parity QA, and cutover — the phases where a single missed 301 costs real revenue.

How to Preserve SEO and Rankings

The whole game is telling Google that nothing important changed except the technology underneath. Concretely:

• Preserve URLs where you can. The cheapest SEO strategy is to keep your existing Ghost slugs identical in Next.js. If the URL doesn’t change, there’s no ranking risk to that page at all.
• 301, never 302. For any URL that must change, use permanent 301 redirects so link equity passes. Build the full mapping before launch — our 301 redirect map guide walks through generating and testing one at scale.
• Match on-page signals exactly. Title tags, meta descriptions, H1s, canonical URLs, and heading hierarchy should carry over verbatim unless you’re deliberately improving them. Regenerate Open Graph and Twitter card tags too.
• Reproduce structured data. Ghost injects BlogPosting/Article and Organization JSON-LD automatically. Recreate it in Next.js so rich results and entity signals survive.
• Keep the sitemap and internal links intact. Submit the fresh sitemap in Search Console at cutover and confirm your internal link graph still points at the right slugs.
• Monitor after launch. Watch Search Console coverage, crawl stats, and Core Web Vitals for the first 4–8 weeks. A short, expected dip that recovers is normal; a sustained drop means a redirect or indexing problem to fix fast.

Running the whole process against a formal checklist prevents the “we forgot the RSS feed” class of mistake — our website migration SEO checklist is the one we use on live client cutovers.

Realistic Cost and Timeline

A Ghost-to-Next.js migration is scoped mostly by two things: how custom the new front end is, and whether you’re rebuilding membership/commerce features. Rough brackets at our $80/hr rate:

• Small content blog (no membership), design ported faithfully: typically 40–80 hours — content pipeline, templates, redirects, SEO parity, and QA. A 2–4 week calendar window.
• Mid-size site with custom design and light integrations: 80–160 hours, spread over 4–8 weeks, including a proper staging-and-crawl QA phase.
• Membership, paid subscriptions, or app features to rebuild: add 60–150+ hours for Stripe, an ESP, gated content, and account flows — this is effectively a product build layered on the migration.

The variable that inflates timelines most is content volume with inconsistent formatting — hundreds of posts with mixed embeds, cards, and legacy Mobiledoc take longer to normalize than the templates themselves. Budget QA time generously; the crawl-and-diff phase is what protects the traffic you’re paying to keep.

The Confident Close

Migrating from Ghost to Next.js is not a leap of faith — it’s a well-worn path with a predictable set of steps and a small number of places to be careful. Your content is portable, your URLs can be preserved, and your rankings survive intact when redirects and on-page signals are handled with discipline. What you gain is a front end with no ceiling: custom design, real application logic, best-in-class performance, and a codebase your team fully owns.

The teams that regret the move are the ones who treated SEO as an afterthought and discovered a missing redirect map three weeks and a traffic cliff later. The teams that are glad they did it planned the parity, tested the crawl, and shipped on a staging domain first. If you want that second outcome without absorbing the risk yourself, we run Ghost migrations end to end — content pipeline, redirect map, SEO parity, and cutover — so the only thing your audience notices is that the site got faster and better.