A Substack to git-based blog migration playbook: keep your subscriber list, redirect the /p/ URLs, and protect the rankings you already earned.
Substack is a newsletter platform that happens to render as a website, not a blog CMS that happens to send email. That distinction is the whole story behind a Substack to git-based blog migration: every post you publish builds trust for a domain you don't control, and even the fix for that, a custom domain, starts your new domain at zero. Compared to the Ghost and Notion migrations in this series, Substack's redirect story has a specific quirk: a connected custom domain auto-redirects your old subdomain for as long as you stay on the platform, but leaving Substack entirely hands you no redirect tool at all.
The platform's growth is exactly why this matters to more teams every year. Substack reported roughly 35 million active subscriptions as of September 2025, more than 5 million of them paid, and unique website visitors grew from 22.1 million in August 2023 to 47.6 million in September 2025, a 65.85% year-over-year jump (Backlinko). More than 17,000 writers now earn revenue on the platform. None of that traffic or trust transfers to you when you leave, even the part your own writing generated.
This post covers why a newsletter platform caps how much SEO authority you can build, exactly where Substack breaks down as a CMS, how to keep your subscriber list and archive intact, the redirect mechanics specific to Substack's custom-domain setup, and the honest recovery timeline once you're live on your own domain.
Substack was built to grow a writer's reach inside its own network first and a search-engine-visible archive second. That ordering is fine for a solo newsletter. It's a ceiling for a business blog that needs to compound its own domain authority over years, not borrow Substack's for as long as it stays a tenant.
Publish without a custom domain and every post lives at yourname.substack.com, a subdomain of substack.com. Backlinks other sites point at your posts, and the trust Google assigns as a result, accrue to the substack.com root domain, the same domain hosting every other publication on the platform. Your own writing is doing work for a domain you'll never own a fraction of.
Connecting a custom domain costs a one-time $50 fee (IONOS), unlocked in Substack's settings, and the DNS side of it is a CNAME record that Substack generates and hands you once you enter the domain. IONOS's own walkthrough of the setup notes "after linking your Substack to your custom domain, it can take up to 36 hours to complete configuration" before it's fully live.
The registrar matters here too. Some registrars only allow a CNAME record on a subdomain, not the bare root domain. One writer documenting their own Substack custom-domain setup ran into exactly this with Hover.com: "Hover.com rejects '@' as a HOST. Substack's config doesn't work," so the fix was entering the CNAME on www instead and setting up a root-domain redirect from the apex to www (magyar.blog). If your registrar behaves the same way, you may end up serving from www.example.com rather than the bare example.com, which is a small decision worth making deliberately rather than discovering by accident.
Even once the domain is yours, it's a brand-new root domain as far as Google is concerned. Every bit of authority your writing built up now sits on a domain with zero history, which is a different problem than the one a custom domain actually solves. A custom domain fixes ownership. It does not fix the authority gap, and it's worth treating those as two separate projects rather than assuming the domain switch alone protects your rankings.
Connecting a custom domain has a narrower cost than most writers expect, but it's real: your publication drops out of Substack's in-app Discover tab, even though your content keeps getting promoted everywhere else inside Substack's network, in recommendations, home feeds, and the rest, and Google still indexes your posts fine under the new domain (Saulenas). That's the trade you're making the moment you connect a domain, well before you've decided to leave the platform entirely: one discovery surface in exchange for owning the URL your rankings live on. It's the right trade for a business blog, but it's worth knowing you're already making it once you flip on a custom domain, not just when you finally migrate off Substack for good.
Substack was built to publish a newsletter, not to run a blog that competes for rankings across dozens of posts. It gives writers no schema markup, no control over robots.txt, and a flat URL structure with no site architecture underneath it, gaps that stay invisible until a Substack blog has real search traffic worth protecting.
Substack writers get no access to structured data, meaning no Article, Author, or FAQ schema that helps both classic rich results and AI answer engines understand a page. There's no breadcrumb navigation, no access to robots.txt or advanced crawl settings, and no support for pillar pages or content hubs (Dellos).
Substack does auto-generate a basic sitemap. One writer documenting Substack SEO practices confirms it lives at "yourname.substack.com/sitemap.xml or yourcustomdomain.com/sitemap.xml," submittable to Search Console as-is (Letters by Burk). But that same lack of writer control extends to it: you can't customize what's in it or how it's structured, the same gap that hits robots.txt and schema.
Every Substack post publishes at a flat /p/post-title path, an editable slug behind a fixed /p/ prefix, with no category, folder, or topic-silo segment in the URL at all (Dellos). All posts exist at the same structural level, which makes it harder for Google to read topical clusters and harder for you to signal which posts matter most. There's no way to nest a guide under a pillar page or group related posts under a shared path, the kind of internal architecture that a blog built to rank depends on. That fixed /p/ prefix also becomes the specific thing your redirect map has to account for later, since almost nothing else uses it.
The fair counterpoint: Substack's post settings do include an SEO panel with real per-post control. Substack's own SEO guide confirms writers can edit "the SEO title (title tag), SEO description (meta description), post URL, and social preview image" for every post, and that "the default is strong, and many writers never need to touch it" (Substack). That's real, usable control at the page level. It just doesn't extend to the structural layer, schema, sitemap, robots.txt, site architecture, that a growing blog needs on top of it.
A Substack migration is really three parallel problems, not one: rebuilding the SEO layer Substack never gave you, getting your archive and subscriber list out intact, and mapping every old URL to a redirect before you launch. Skip the second one and the first is moot, since a blog with no subscribers and a broken image on every post isn't worth ranking.
Substack's export lives under Settings, then Import/Export, then "Export your data," and produces a zip containing your posts as CSV and HTML files, your subscriber list, and your stats. What it leaves out is the longer list: it doesn't include your images at all, since every image reference in the exported HTML still points back to Substack's own servers, and it drops Notes, comment threads, and the bodies of unpublished drafts, which export as titles only, no content (Letters by Burk).
As Burk, the writer behind Letters by Burk, put it after migrating off the platform: "The archive comes with you, the traffic doesn't. All links break once you're moved." That's the honest framing for this whole section: the export gets you your words, not your addresses, and not everything that made the addresses work.
A git-based static blog has no built-in way to send email, so your subscriber list needs a real destination before you decommission Substack. The main data export's subscriber CSV is a starting point, but Burk's own account recommends the fuller export instead: "The three dots above the list, then Export. You can take all columns or only the visible ones, and all columns goes down to when someone last opened an email" (Letters by Burk). Run that export regularly if you're serious about owning your list, not just once at the end.
Wherever that CSV lands, beehiiv's own migration guide is a useful preview of what every ESP import flow looks like: after uploading the file, "a confirmation will appear asking you to verify that all contacts in the import have knowingly opted in to receive emails from you" before the import completes (beehiiv). Budget time for that consent check, since it's a manual gate, not a formality you can click through.
If your Substack has paid subscriptions, there's a second thing worth checking before you leave: every paid subscription Substack sets up runs through Stripe with a 10% platform fee baked into the subscription itself, and that fee doesn't disappear automatically when you go, it has to be requested by name (Letters by Burk). Email Substack and ask them to disconnect Stripe from your publication and remove the fee, rather than assuming it lapses on its own.
Because the export's HTML still points at Substack-hosted image URLs, every image in your archive keeps working right up until the account closes, and then quietly breaks across your entire back catalog. Audit every post for image references, download and re-host each one on your own infrastructure, and only then close the Substack account. Treat this as a checklist item with its own line, not a side effect of exporting the text.
Here's the quirk that makes Substack different from the other platforms in this series: a custom domain gives you an automatic redirect while you're still on Substack, and no redirect mechanism at all once you leave. The migration has to build the redirect layer Substack never hands off.
If you haven't connected a custom domain yet, do it before you migrate, not as part of the migration itself. It's the one-time $50 fee plus a CNAME record Substack generates and hands you once you enter the domain, and IONOS's setup guide puts the propagation window at up to 36 hours before the domain is fully configured. Getting your indexed URLs onto your own domain first, ahead of the platform switch, is what makes the eventual redirect map a same-domain problem instead of a domain-change problem, a distinction that matters a lot for your recovery timeline below.
While you're on Substack with a custom domain connected, your original yourname.substack.com URL keeps working: it auto-redirects with a 301 to your custom domain, which is exactly what Burk experienced moving to letters.byburk.net, where "burk.substack.com still 301s to it, so nothing I'd shared before the switch broke." That redirect is a Substack feature running on Substack's own infrastructure, not something you can take with you.
The moment you actually leave the platform, that redirect goes away, and Substack gives you nothing to replace it with. If you never connected a custom domain and you're migrating straight from a substack.com subdomain, you're starting the redirect map from scratch with no interim safety net at all. Either way, the working redirect map has to live entirely on your new host or CDN before launch, since Google treats a 301 or 308 as a signal the target URL should be canonical, a signal a 302, 303, or 307 does not carry.
The /p/ prefix is the specific thing to plan around. As Burk frames it: "Substack puts posts under /p/slug and most other platforms don't, so you need a redirect rule on the new side to catch the old shape." That means your redirect map isn't a simple slug-to-slug swap the way a Ghost or Notion migration often is; every rule needs to strip the /p/ segment and map the remaining slug onto whatever path structure your new blog uses, /blog/slug/ or otherwise. Pull every indexed URL from Search Console's Coverage report first, not just your own list of published posts, and write the mapping as a spreadsheet before you touch a redirect config.
Google's own site-move documentation treats ranking fluctuation during any migration as expected, states that "a medium-sized website can take a few weeks for most pages to move" in the index, and recommends keeping redirects live "for as long as possible, generally at least 1 year," since that's the window Google needs to transfer signals from old backlinks to the new URLs.
Which honest timeline applies to you depends on the domain decision you made above. A clean, single-event migration that keeps the same domain, meaning you already connected a Substack custom domain and you're carrying that exact domain to your new git-based host, sees a 10 to 15% organic dip in the first four weeks as normal, with most sites returning to their pre-migration baseline within 60 to 90 days (Webnomads). If you're migrating straight off a substack.com subdomain onto a brand-new domain at the same time, you're closer to a full domain change, and the wider benchmark applies: a study of 892 domain migrations found an average of roughly 523 days, about 17 months, to fully recover prior organic traffic, with the fastest recoveries at 19 to 23 days (Digital Applied). Connecting a custom domain before you migrate, and keeping that same domain on the new host, is what buys you the faster timeline instead of the slower one.
Submit your new sitemap the day you launch, then check Coverage daily for the first two weeks and weekly through the 90-day mark. Google states it will crawl a moved site more heavily than usual right after the move, so expect a temporary spike as redirected requests from your old /p/ URLs stack on top of normal crawl demand, not a sign anything's broken.
Work through this before you export a single post:
Once your posts are Markdown files in a repo, publishing stops depending on Substack's editor and starts depending on your own review process. A new post is a branch and a file, not a click in an admin panel with no diff for anyone to review. You also pick up checks Substack had no equivalent for: broken links, valid canonicals, valid JSON-LD, all gate-able before a page reaches production. Our GitHub Actions SEO checks post walks through four automated jobs that do exactly that.
It's also worth comparing a git-based rebuild against a headless CMS, not assuming git is the only alternative to Substack; our headless CMS vs git-based blog breakdown covers the sync-step risk a CMS-plus-frontend setup can introduce that a static build never has. And if you're building your keyword strategy fresh rather than just porting an existing Substack archive, our guide to SEO for SaaS covers picking winnable keywords and building topic clusters from scratch.
That handoff is also where a repo-native writing tool fits, instead of a Substack export you convert once and never touch again. A git-based AI blog writer reads your repo's conventions and opens a pull request for each new post the same way a human contributor would, so nothing publishes without someone approving the merge, a different failure mode than a newsletter going out the moment you hit send. Lyra's plans start at $39 a month if you want to see what running that workflow costs once your migration is done.
Once your Substack migration lands on git, Lyra can take over the writing from there, reading your repo's conventions and opening a pull request for every new post, the same review gate you already use for code.
FAQ
Not if you map every indexed URL and redirect it with a permanent 301 before you launch. Google's own site-move guidance treats ranking fluctuation during a migration as expected, and a medium-sized site typically takes a few weeks for most pages to move in the index. The specific risk in a Substack migration is the /p/ URL prefix: Substack gives you no redirect tool once you leave the platform, so every old /p/slug link has to be mapped by hand on your new host.
Substack gives writers no schema markup, no control over robots.txt, and no way to customize the XML sitemap it auto-generates. Posts publish at a flat /p/post-title path with no category, folder, or topic-silo structure, so there's no way to build the kind of site architecture that signals topical authority. What you do get is per-post control over the SEO title, description, URL slug, and social preview image, which covers the basics but not the structural gaps.
Only while you're still on Substack. If you connected a custom domain, your old yourname.substack.com URL auto-redirects with a 301 to that custom domain, so shared links keep working. That redirect is a Substack feature, not something you own, and it stops working entirely the moment you leave the platform. There is no equivalent tool for redirecting your Substack URLs to a new host once you're gone, which is why the redirect map has to be built on the new side before you migrate.
Substack's export (Settings, then Import/Export) generates a zip with your posts as CSV and HTML files, plus your subscriber list and stats. It does not include images, which stay hosted on Substack's own servers, or your Notes, comment threads, and draft post bodies. For a fuller subscriber file, export separately from the Subscribers page using the three-dot menu, which lets you include every column down to a subscriber's last email open.
It's worth doing early if you haven't already, since it costs a one-time $50 fee and starts moving your indexed URLs to a domain you'll actually keep. But it doesn't solve the underlying problem: your new domain still starts at zero authority, and connecting a custom domain removes your publication from Substack's Discover tab, though your content keeps getting promoted in its recommendations and home feeds, and Google keeps indexing your posts under the new domain.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
A Contentful to git-based blog migration playbook: convert Rich Text JSON and entry references to Markdown, protect your rankings, and cut the metered API bill.
A Medium to git-based blog migration playbook: export your posts, handle redirects since medium.com isn't your domain, and protect your rankings.
Content pruning for AI-era SEO means deleting or merging thin posts, not refreshing them. A decision framework, an audit, and what Google's 2026 update changed.