A blog migration playbook for 12 platforms. The export is never the hard part. Your redirect tool dies with the platform, and that is what costs you rankings.
Twelve platforms, one method. Whether you are leaving WordPress, Ghost, Webflow, HubSpot, Contentful, Notion, Framer, Medium, Substack, beehiiv, Squarespace or Wix, the sequence that protects your rankings is identical and the platform-specific parts are smaller than they look.
What surprises most teams is which part is hard. It is never the export. Even Wix, which has no export at all, is a solvable content problem: someone spends a week copying posts. The part that actually costs rankings is the redirect layer, because on almost every hosted platform the redirect tool stops working the moment your domain points somewhere else. You lose the tool and the URLs at the same instant.
The scale of the risk is worth stating plainly. Digital Applied's analysis of 892 domain migrations found the average site took roughly 523 days, about 17 months, to fully recover its prior organic traffic. The fastest recoveries landed in 19 to 23 days. Seventeen percent of sites were still below baseline after 1,000 days. A 27-fold gap between the fastest and the average is not noise, it is the difference between a mapped migration and an improvised one.
This guide covers the four things that decide which side of that gap you land on, then the specific trap each of the twelve platforms sets.
Pricing note. Every third-party price on this page was checked against the vendor's own published pricing on 20 August 2026. Vendors change prices, rename or retire tiers, and move to quote-only without notice, and published rates routinely differ by billing period, region, seat count, model and usage tier. Treat these figures as a point-in-time snapshot for comparison, not as a quote, and confirm on the vendor's own pricing page before you buy. Where a vendor has stopped publishing a price, this page says so rather than repeating an old one.
Four failure modes account for nearly all of it.
Missing redirects. A URL that returns 404 after the move loses everything pointing at it. This is the single largest cause and it is entirely preventable.
Many-to-one redirects. Pointing a batch of orphaned old URLs at the homepage because you could not find a good match. Google reads that as a soft 404 and treats the redirect as unreliable, so you get neither the old page's equity nor a clean signal.
Redirect chains. Old URL to interim URL to final URL. Googlebot follows up to ten hops, but Google's own advice is to keep chains to no more than three and fewer than five. Every hop leaks a little and slows recrawl.
Metadata that silently did not come across. Canonical tags pointing at the old domain, noindex copied from staging into production, structured data that existed on the old template and does not exist on the new one.
Digital Applied's 2025 replatform case study shows what the first three look like together: organic clicks fell from roughly 1,200 to about 500 a day after long redirect chains were created and critical 301 mappings from top old-site URLs were missed entirely.
This is the rule almost every team learns too late, and it is nearly universal across hosted platforms.
HubSpot states it without hedging: "URL redirects only work for domains connected to and hosted in HubSpot." Squarespace's URL Mappings "only works from built-in and custom domains connected to your Squarespace site." Wix's URL Redirect Manager requires a custom domain connected to Wix and stops the moment it disconnects. Ghost's redirects.yaml is tied to Ghost's hosting. Framer's rules only cover sub-paths inside the domain currently connected to Framer, and Framer's own docs tell you that to redirect an entire domain "use your hosting provider for the old domain."
There is no overlap window. The tool does not keep running for a grace period while DNS propagates. It works, and then your domain moves and it does not.
The practical consequence: the complete redirect map has to be live on the new host before you switch DNS. Not planned, not drafted, live and tested against a staging domain. Everything else in a migration can be fixed afterwards. This one cannot.
Contentful is the single exception in this set, and for a structural reason. It is a true headless CMS with no hosting and no URL pattern of its own, so your redirect layer already lives wherever your frontend is deployed and simply stays there. There is no Contentful redirect tool to lose.
Every platform will happily give you a list of your posts. That list is not your redirect map, because it does not include tag archives, category pages, author pages, paginated archive URLs, old slugs that were changed years ago and still have inbound links, or attachment and image pages.
The gap is large. On one 180-page project, Webnomads found that a full crawl surfaced 340 URLs needing redirects against only 94 in the client's sitemap and URL export. That is 246 URLs carrying backlink equity that would have gone dark on launch day.
Use two sources together and reconcile them:
The second source is the one teams skip, and it is where the old high-value URLs hide.
On most of these platforms images do not live in your export. They live on the platform's CDN, and the URLs in your exported HTML point straight back at it.
Two platforms are explicit that this is unfixable. Wix: "Currently, it is not possible to replace the static.wixstatic.com/media part of an image URL with your own domain name." Squarespace: "You can't redirect image or file URLs, because static assets are stored by our content delivery network service providers (CDNs)." No setting changes this, no paid tier changes this.
Squarespace adds a clock. It purges deleted or unused images automatically within 8 to 38 days of removal unless you request an expedited Static URL Removal. An XML export generated a few weeks ago can already reference dead image URLs.
The rule is the same everywhere: download every image at full resolution while the old plan is still active and the domain is still connected. You need the live site to reach its own CDN. Once you cancel, the URLs stop resolving, and any reference to them elsewhere on the web becomes an unfixable dead link.
The method above is the same for all twelve. These are the specific traps.
Astro's own migration guide frames the real decision: keep WordPress as a headless CMS behind an Astro frontend, or move every post to Markdown and drop the database. For a large or complicated site, Astro warns that a full Markdown migration "usually needs manual adjustment". An automated export is a starting point, not a finish line.
Lucky Media, an agency specialising in this move, quotes 6 to 12 weeks for a standard marketing site and 16 weeks or more with custom post types, WooCommerce or multi-language. If you are weighing the destination rather than the source, our Astro vs Next.js SEO comparison covers the Core Web Vitals trade-off between the two.
The cleanest export in this set: a single JSON file from Settings, Advanced, Import/Export, mirroring Ghost's database structure rather than its public API. What it does not include is the catch. Comments are excluded as of Ghost v5 and need a full mysqldump. Images are not in the JSON at all, they sit in the server's content directory. Members and Stripe data export as a separate CSV.
The post body is also not Markdown. A post written in Ghost's current Lexical editor exports with lexical, html and plaintext populated and mobiledoc null; older posts carry mobiledoc instead. Both are proprietary, so conversion runs from the html field through an HTML-to-Markdown pass plus review.
One field matters more than the rest: the members CSV carries stripe_customer_id, which is what preserves an active paid subscriber's billing relationship across the move.
Collection exports come out as CSV, and CSV is the wrong shape for the data. Per MigrateLab, rich text arrives as "plain text or raw HTML blobs in a single CSV column", multi-reference fields export as "comma-separated IDs that mean nothing outside Webflow", and Collection page templates "don't export at all. You're rebuilding those from scratch."
The redirect gotcha is nastier than most: uploading a CSV through Webflow's bulk-import tool replaces every existing redirect on the site rather than adding to them. Import a fresh migration map and you silently delete the redirects you already had. Webflow recommends a maximum of 1,000 redirects, and they run oldest-first in the order added.
Also note every image URL in that CSV is a Webflow CDN link that dies with the plan.
Use the HTML export of pages, posts and templates, which HubSpot's own docs recommend specifically if you are moving content to another platform. The CSV data export only carries fields like title, language and URL, not page HTML.
HubSpot's redirect tool supports 301, 302 and 305, with bulk imports capped at 500 redirects per CSV upload and 140 characters per URL. And it is the platform that states the disappearing-tool problem most clearly, quoted above.
On schema, SchemaPilot notes that HubSpot generates meta tags, Open Graph tags and canonicals but "does not generate JSON-LD structured data for your pages", so "every HubSpot site starts at zero for schema markup".
Export via contentful-export, which dumps a space to one JSON file covering content types, entries, assets, locales, tags, webhooks and roles, and works on a Free-tier space. Space memberships are not exported, webhooks come out with credentials stripped, and custom UI extensions need manual reinstallation.
The real work is Rich Text, which is a JSON abstract syntax tree, not HTML or Markdown. Every node carries a nodeType, a data object and optional content, value and marks, under a single root of nodeType: 'document'. Converting means a recursive tree walk, and a node type your walker does not handle silently drops from the output.
Embedded content is worse: embedded-entry-block, embedded-asset-block, entry-hyperlink and friends carry no content of their own, only a sys object with an id. The real data sits at the top level under includes.Entry and includes.Asset. Contentful's SDKs resolve this at runtime, so developers who only ever queried through the SDK often do not know includes exists.
For the broader trade-off, our headless CMS vs git-based blog comparison covers the ghost-content risk in more depth.
Export as Markdown & CSV from workspace settings or a page's three-dot menu. Notion appends a 32-character hex ID to every exported filename and rewrites internal links to match, so renaming files after export breaks the link rewriting. Images embedded from external URLs are not downloaded during export at all, leaving dead links in the output, and Notion-hosted images may resolve to time-limited signed URLs.
There is no frontmatter concept, so title, date and description are added by hand or by script. And meta titles and descriptions exist only in a single Site customization panel on a paid plan, with no per-post version. We checked three unrelated public notion.site blogs: every one served <title>Notion</title> and the same generic workspace meta description.
No first-party export. The closest option is the free CMS Export marketplace plugin, which exports a collection to CSV with a preview step, or the static HTML, CSS, JS and asset bundle Framer lets you download at any time.
Framer's redirect tool is genuinely good, with wildcards (/blog/*) and capture groups (/blog/*/post/* to /article/:1/entry/:2), but it starts on the Pro plan at $30 a month and only covers sub-paths inside the connected domain. A platform exit is a domain-level redirect, which Framer explicitly sends you to your hosting provider for.
Canonical URL control sits behind Enterprise or a paid reverse-proxy add-on, and no Article, BreadcrumbList or Organization JSON-LD ships with the blog template.
Export from Settings, Security and apps, Download your information. You get a .zip of HTML files, one per story, with Medium's presentation CSS inline. Images are not included, only links to Medium's CDN.
The redirect problem is structural: you do not own medium.com. With a custom domain you control DNS and can write real 301s. Without one, the workaround is to set each post's canonical field (More settings, Advanced Settings, "This story was originally published elsewhere") and trim each post to roughly the first 25% of its content with a link to the full version on your domain. Only the author can set that field, there is no bulk tool, and a re-save can silently drop it.
Three tools do the conversion: mediumexporter, medium-2-md which adds YAML frontmatter, and medium-export-image-fill which downloads every referenced image locally and rewrites the HTML to point at the copies.
Worth knowing before you agonise over the loss: Medium sets rel=nofollow on every outbound link by default, so the domain's DR 94 was never passing you equity.
Export from Settings, Import/Export. You get a zip of posts as CSV and HTML, your subscriber list and your stats. It drops images (every reference points back at Substack's servers), Notes, comment threads, and the bodies of unpublished drafts, which export as titles only.
Every post lives at a flat /p/post-title, and that /p/ prefix is fixed. Every redirect rule has to strip it and remap the remaining slug. If you connected a custom domain, your yourname.substack.com URLs currently 301 to it, but that redirect is a Substack feature running on Substack's infrastructure and it disappears when you leave.
One billing detail that catches people: paid subscriptions run through Stripe with a 10% platform fee, and that Stripe application fee keeps applying to existing subscriptions after you migrate until Substack support disconnects Stripe and removes it. This is documented by third-party migration guides rather than by Substack itself, so confirm it with support before you plan around it.
The export is a single CSV containing published, archived and draft posts in one file, and the download link is valid for 24 hours only. There is no beehiiv-to-git conversion tool, and beehiiv's own import tool only supports Substack, WordPress, Ghost and Mailchimp, with manual copy-paste as the documented fallback for anything else.
Posts publish at yourdomain.com/p/your-post-slug with /p/ inserted automatically and no setting to remove it. Ghost's beehiiv migration docs go as far as publishing a redirect regular expression for the pattern, because one-to-one slug mapping does not cover it.
Two harder edges. Stripe lock-in is tighter than Ghost's: per Ghost's migration docs the Stripe account connected to a beehiiv site cannot be reused elsewhere, so paid subscribers cannot move without custom billing work. And beehiiv's Terms of Use state that after cancellation beehiiv "is not required to receive, compile, maintain, or make available communications or data of any nature", with no contractual window guaranteeing your indexed archive stays live during the move.
The export is real on both 7.0 and 7.1, despite a widely-repeated claim that 7.1 cannot produce one. What matters is how much it leaves behind.
It covers layout pages, one blog page with its posts and up to 1,000 comments each, text blocks and image blocks. It drops album, cover, index, info, calendar, portfolio and store pages, additional blog pages beyond the first, product, video and audio blocks, drafts, style settings, custom CSS, and per-post SEO titles and descriptions.
URL Mappings caps at 400 KB, roughly 2,500 lines, only takes effect once the old page is deleted or disabled, cannot redirect away from the homepage, and breaks entirely on query strings or hash symbols. That last limit matters because Squarespace's own category and tag archives use query-string URLs (/pageslug?category=name), so the archive URLs are exactly the shape its redirect tool cannot handle.
There is no export. Wix's Help Center: "Currently, it is not possible to export blog posts to other platforms." No Markdown, no XML, no CSV. You copy each post out by hand or use a third-party scraper, and a manual copy loses anything rendered dynamically, including embedded apps and interactive blocks.
Posts sit at the fixed pattern mysite.com/post/post-title, where only the final slug is editable and the post segment cannot be renamed. Tag pages have their own fixed, uneditable structure.
The redirect trap is specific and severe. Wix auto-creates a 301 when you change a URL slug on Editor pages, Stores, Bookings and Events, but blog pages are the named exception: "For Wix Blog pages, 301 redirects will not automatically be created." The content type most likely to carry your search traffic is the one with no safety net. The manual URL Redirect Manager needs a connected custom domain and caps at 5,000 redirects.
Order matters more than speed.
noindex, structured data present on every page type it was present on before, meta titles and descriptions carried across.Google recommends permanent server-side redirects, "such as 301 and 308", and to keep them "for as long as possible, generally at least 1 year". If the redirect layer lives in your repo as config, there is no reason to ever delete it.
Set expectations before launch, because the first two weeks always look worse than the outcome.
Google's own framing is that "the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time." It also notes it will crawl the new site more heavily than usual immediately after a move, which is a good sign rather than a problem.
For concrete numbers, the honest answer is that the published figures vary and most come with caveats. Webnomads reports a 10 to 15% dip in the first four weeks and most sites back to baseline within 60 to 90 days, though that case describes teams moving onto Webflow rather than off it, so treat the direction as a caveat. Mevo puts a well-executed migration at 10 to 15% fluctuation for about three weeks, with drops as steep as 40% when redirects are missed or metadata is lost. Search Engine Journal's analysis lands on four to twelve weeks as typical.
The wide spread across those sources is the real finding. Recovery time is not a property of the platform you left, it is a property of how complete your redirect map was on launch day.
One case worth internalising if you are also changing URL structure rather than just platforms. G2 moved its blog to a learn.g2.com subdomain from a DR 88 domain already doing over 750,000 monthly visits. Jakub Rudnik, now managing director of SEO at GrowthX AI, on the move he ran at G2: "it took months for Google to build trust in that subdomain despite it being on a DR 88 website that was already generating 750k+ traffic each month. After the first 3 to 4 months, fresh backlinks, and a ton of new content sending Google signals, we picked up traction quickly." If you can avoid changing the URL shape in the same move as the platform, do. Our subdomain vs subdirectory post covers that decision separately.
Once posts are Markdown files in a repo, the publishing question stops being "who has admin access" and becomes "what does our git workflow look like for content". A new post is a branch and a file. Review happens in PR comments. A merge to main triggers the same build and deploy pipeline the rest of the product already uses.
The part that matters for everything above: your redirect map becomes config in version control. It is reviewable, diffable, and it cannot be deleted by a bulk CSV import or evaporate when a subscription lapses. The single largest cause of migration traffic loss stops being a live risk and becomes a file.
You also get to gate merges on checks no CMS admin panel has an equivalent for. Our GitHub Actions SEO checks post walks through four automated jobs, broken links, canonical and meta validation, JSON-LD linting and Lighthouse budgets, that fail the build before a bad page reaches production.
If you are rebuilding keyword strategy alongside the move rather than porting an existing archive, SEO for SaaS covers choosing winnable keywords and building topic clusters before you are locked into a platform's constraints. And once the content lives in the repo, a git-based AI blog writer can read your conventions and open a pull request for each new post the same way a human contributor would. You can see the plans if you want to know what that costs once you are there.
A migration is the right moment to fix the workflow, not just the hosting. Once your posts are Markdown in a repo, Lyra drafts the next one on a branch and opens a pull request you review, so nothing publishes without a human merge.
Step by step
Crawl the old site before you touch anything
Run a full crawl and cross-reference it against Search Console's Coverage report. Do not trust the platform's post list or sitemap, both undercount.
Download every image at full resolution
Do this while the old plan is still active. On Wix, Squarespace, Webflow, Substack and Medium the images live on the platform CDN and die with the account.
Export the content and convert it
Every platform export loses something. Identify what yours drops before you rely on it as a source of truth.
Build the complete 301 map on the new host
One old URL to one new URL. No many-to-one redirects to the homepage, and no chains longer than three hops.
Verify on staging, then cut over DNS
Check canonicals, structured data, and meta on the new pages before switching, not after.
Submit both sitemaps and monitor for 90 days
Keep the old and new sitemaps submitted side by side until indexed counts trade places. Check Coverage and Performance daily for two weeks, then weekly.
FAQ
Temporarily, yes, and Google's own site-move guidance treats that fluctuation as expected. What separates a two-month dip from a permanent loss is whether every indexed URL has a working 301 on launch day. In a study of 892 domain migrations, Digital Applied found the average site took around 523 days to fully recover prior organic traffic, while the fastest recoveries landed in 19 to 23 days. That spread is almost entirely a function of redirect completeness, not platform choice.
Because on almost every hosted platform the redirect tool only runs while your domain is connected to that platform. HubSpot states it plainly: URL redirects only work for domains connected to and hosted in HubSpot. Squarespace's URL Mappings, Wix's URL Redirect Manager, Ghost's redirects.yaml and Framer's redirect rules all work the same way. There is no transition period. The redirect layer has to exist on the new host before you switch DNS.
A full crawl plus Search Console's Coverage report, never the platform's own post list or sitemap. Those undercount badly. On one 180-page project, Webnomads found a crawl surfaced 340 URLs needing redirects against only 94 in the client's sitemap and URL export, meaning 246 URLs carrying link equity would have gone dark.
On most platforms they stay on the old CDN and break when you leave. Wix says outright that it is not possible to replace the static.wixstatic.com/media portion of an image URL with your own domain. Squarespace says image and file URLs cannot be redirected because static assets sit with its CDN providers, and it purges deleted images within 8 to 38 days. Download every image at full resolution while the old plan is still active, not after you cancel.
Google's guidance is to keep redirects for as long as possible, generally at least a year. In practice, if the redirect layer lives in your own repo as config rather than in a platform's admin panel, there is no reason to ever remove it. Keeping the rules costs nothing and deleting them re-breaks every old inbound link.
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
Chrome extension SEO for dev tools: how the Web Store ranking algorithm weighs installs and ratings, and how to optimize your listing to get found.
MCP server content access lets agents read and write your blog. See what Contentful, Sanity, and Storyblok ship, and the 2026 security record before you connect one.
Static site generator SEO comparison: Astro vs Hugo vs Next.js vs Eleventy on build speed, Core Web Vitals, and content APIs, so you pick the right one.