A HubSpot blog migration playbook: why SaaS teams outgrow HubSpot's cost tiers, the redirect checklist that protects rankings, and what changes on git.
HubSpot is the default CMS a SaaS marketing team lands on, and for a while that's a reasonable place to be. The pull to leave doesn't show up because HubSpot is broken. It shows up because the pricing model taxes exactly the traffic growth your blog is supposed to produce, the templating language only runs inside HubSpot, and the CMS ships zero structured data for a blog post by default.
A HubSpot blog migration is the same discipline as any other platform move: map every indexed URL, redirect it with a permanent code, and don't lose what you already ranked for. It also has one twist specific to HubSpot, and it catches teams off guard because it looks like a HubSpot feature you can lean on mid-migration. It isn't.
This post covers why teams outgrow HubSpot's blog, the redirect and metadata checklist that protects your rankings, and what actually changes once your content lives in git instead of HubSpot's database. For the same playbook against two other platforms, see our WordPress to Astro migration and Notion to git-based blog migration posts; the platform changes, the discipline doesn't.
HubSpot's Content Hub tiers run from free to $1,500 a month, and the blog itself is rarely the line item that forces a move. HubSpot's own pricing page lays out four tiers:
| Tier | Price | Seats | Pages | Notable limits |
|---|---|---|---|---|
| Free | $0/month | 2 users | 30 landing pages, 30 website pages | HubSpot branding on every page |
| Starter | $7/month per seat (billed annually) | Per seat | 30 landing pages, 30 website pages | Custom templates, branding removed |
| Professional | $450/month | 3 core seats | Up to 10,000 pages | HubDB, more custom templates |
| Enterprise | $1,500/month | 5 core seats | Multi-site, up to 10 domains | Highest tier, most seats |
On paper, Content Hub Starter's blog alone allows up to 10,000 blog posts, 20 authors, and 50 tags on one blog, per an independent breakdown of Content Hub tiers, which is plenty of room for a growing content operation.
The blog rarely hits those ceilings. What forces the conversation is Marketing Hub, HubSpot's separate contact-based product that most teams end up bundling in to run email and lifecycle marketing alongside the blog.
A blog's job is to bring in new visitors who convert into contacts. Marketing Hub bills by exactly that number, in tiers, and crossing a tier by even one contact moves your whole account to the next bracket. HubSpot's own pricing breakdown shows Starter including 1,000 contacts, and Professional including 2,000 contacts at roughly $890/month plus a mandatory $3,000 onboarding fee, with additional contacts sold in 5,000-contact blocks from around $250/month. That means a Professional-tier account that grows from 2,000 to 2,001 marketing contacts, the exact outcome a working blog is supposed to produce, jumps to the next full contact tier rather than paying for one extra contact.
The compounding version of that math is documented, not theoretical. Lynton, a former 16-year HubSpot partner agency with more than 2,000 implementations, found that a company nominally paying $43,200 a year for Marketing Hub Enterprise typically faces $150,000 to $200,000 a year in real total cost of ownership once partner retainers and internal admin time are added in, with contact overages alone running $2,400 to $24,000-plus a year on top of 5 to 10% annual renewal increases. Their own scoring framework grades total HubSpot spend on a five-point scale: under $25,000 a year and stable scores as "stay," $25,000 to $60,000 a year or growing faster than revenue scores as "evaluate," and over $60,000 a year, rising 5 to 10% annually, scores at the top of the scale, their cue to leave rather than just evaluate. A growing blog's own success, more contacts, more traffic, more seats, is exactly what pushes a team up that scale faster, not slower.
Every HubSpot theme is built in HubL, HubSpot's own templating language, and it exists nowhere outside HubSpot. A breakdown of HubSpot CMS limitations is specific about the constraint: you cannot host a site built with HubSpot's CMS on an external server, and you cannot host a site built elsewhere on HubSpot's servers. HubSpot also has no native support for server-side languages like PHP; developers use HubL for server-side logic instead, because that's the only option HubSpot gives them.
Lynton's assessment of what that does to a team is blunt: "HubSpot's proprietary templating language (HubL) creates key-person risk," because HubL fluency doesn't transfer, and it means one or two specialists become a bottleneck for changes that should be self-service, like layouts, email templates, and landing pages. A developer who learns HubL has learned a skill that works in exactly one product. A developer who writes Markdown, HTML, or a mainstream templating language has learned something portable.
Structured data is the clearest gap. An analysis of HubSpot CMS output for schema markup found the platform generates standard meta tags, Open Graph tags, and canonical URLs, but nothing beyond that: "HubSpot does not generate JSON-LD structured data for your pages. There is no built-in Organization schema for your homepage, no Article schema for your blog posts, no FAQPage schema for your knowledge base articles, and no BreadcrumbList schema for navigation." The same analysis summarizes it as plainly as it can be summarized: "every HubSpot site starts at zero for schema markup. You need to add it yourself." That's a real cost for both classic rich results and AI answer engines, both of which lean on structured data to understand what a page actually is.
We checked what "add it yourself" looks like in practice by pulling the raw page source of a live post on HubSpot's own blog, which runs on HubSpot's own CMS. It does carry Article, BreadcrumbList, Organization, and WebPage JSON-LD, so the schema isn't impossible to get on HubSpot. But it's hand-built, not automatic: the markup follows HubSpot's specific template structure rather than shipping as a default block every blog gets for free, which is consistent with the "add it yourself" finding above, not a contradiction of it. A team without HubSpot's own engineering resources behind their theme is the team that ends up shipping the zero-schema default.
Page and branding limits stack on top of that. Free-tier pages are capped at 30 and carry visible HubSpot branding; branding removal and higher page ceilings require a paid tier. None of this is a dealbreaker on its own. Together, contact pricing, HubL lock-in, and a schema-free starting point are why the exit conversation keeps coming up on well-resourced SaaS teams specifically, not on hobby blogs.
The honest starting point: none of the reasons above are a reason to migrate carelessly. A HubSpot blog that has any real search traffic turns this from a platform swap into a redirect-mapping project first and a rebuild second.
HubSpot's own export documentation recommends its HTML export specifically "if you're going to import content onto another platform," and that's the export you want: HTML files of your pages, blog posts, and templates. Separately, HubSpot offers CSV, XLS, or XLSX data exports limited to fields like title, language, and URL, useful for building your redirect map but not a content backup, since HubSpot's own docs note that exports from reports carry page-level data and metrics only, not the full HTML of your pages. HubSpot's documentation doesn't describe any tool for restoring an entire site to a prior version either, so treat the HTML export as raw material for conversion, not as a database dump you could restore from if something goes wrong mid-migration.
Pull every URL Google actually has indexed from Search Console's Coverage report, not just the post list in HubSpot's blog dashboard. A post you unpublished last year can still be indexed and still sending a trickle of traffic through an old backlink; if it disappears with no redirect, that traffic and the link equity behind it disappear with it. Build a spreadsheet, old URL to new URL to redirect type, before you export a single file. This step is unglamorous and it's also where nearly all of the actual migration risk lives, not in the framework you pick for the rebuild.
The redirect type carries the ranking signal, and Google is explicit about the difference. Google's own documentation on redirect types states that for a 301 or 308, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical," while for a 302, 303, or 307, "the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical." A HubSpot migration is permanent, so anything short of a 301 or 308 sends the wrong signal at the exact moment you need the right one.
Here's the HubSpot-specific catch, and it's the one that trips teams up mid-migration: HubSpot's own knowledge base states plainly, "URL redirects only work for domains connected to and hosted in HubSpot." HubSpot's redirect tool does support three types, permanent (301, the default), temporary (302), and proxy (305), and bulk uploads work well while you're still on HubSpot's hosting. But that tool stops functioning the moment your domain points somewhere else, because it's a HubSpot hosting feature, not a portable redirect service. Bulk imports on that tool also cap out at 500 redirects per CSV upload and 140 characters per URL, a real constraint if your blog runs into the thousands of posts. The takeaway: build and test your redirect map on the new host or CDN from the start of the project. Don't plan to run redirects through HubSpot for a transition period after the domain moves, because there won't be a transition period where that works.
Keep the redirects live once they're on the new host. Google's site-move guidance is specific: "Keep the redirects for as long as possible, generally at least 1 year," because that's the window Google needs to recrawl the backlinks other sites still have pointing at your old HubSpot URLs and reassign that signal to the new ones. Expect a temporary crawl spike too. Google states directly that after a move, it "will crawl your new site more heavily than usual," since redirected requests from the old URLs stack on top of normal crawl demand.
Some of what a migration "risks" isn't actually at risk, because HubSpot never had it in the first place. Zero JSON-LD schema by default means there's no schema to preserve, only schema to add for the first time. That's worth doing at build time in the new site; see our guide to schema markup for AI Overviews for which structured data types are actually worth shipping in 2026 versus which are vendor invention. The same logic applies to per-post sitemap control and template ownership: these aren't things a HubSpot migration threatens, they're things it finally gives you.
The tradeoff is real in both directions, and it's worth stating plainly rather than pretending the move is a pure upgrade.
HubSpot's blog editor is built for a marketer who wants to write, format, and publish from a browser with no engineering involved. A git-based blog trades that for every post becoming a Markdown file on a branch, reviewed as a diff, merged through the same process as a code change. For a marketing team that has never touched git, that's a genuine cost, not a footnote, and it's the honest reason some teams stay on HubSpot even after they've outgrown its pricing.
What you get in exchange is a publishing pipeline that behaves like the rest of your product instead of a separate system nobody on the engineering side ever opens. Every post change is a diff someone can review before it ships. Nothing publishes without a merged pull request, a meaningfully different failure mode than a HubSpot post going live the moment someone clicks publish. If your marketing team is weighing that tradeoff and wants to walk through what it looks like for your specific HubSpot setup, request early access rather than guessing from a blog post.
A static build generates a unique meta title and description per post automatically, writes an XML sitemap from your content directory with no manual step, and lets you add Article and BreadcrumbList schema to every page instead of none. You can also gate every merge on the checks that actually protect rankings: broken links, valid canonicals, valid JSON-LD, and Core Web Vitals budgets. Our GitHub Actions SEO checks post walks through exactly that kind of workflow, four automated jobs that fail a build before a bad page ever reaches production, which is a stronger guarantee than a marketer remembering to fill in a meta description field.
If you're weighing a fully static rebuild against a headless CMS sitting in front of your new frontend, it's worth understanding the tradeoff there too. Our headless CMS vs git-based blog post covers the ghost-content risk a sync-based publish flow can introduce that a plain static build never has, since a git-based build has no separate sync layer to fall behind in the first place.
Work through this before you export a single post:
Article/BreadcrumbList schema in the new build, since HubSpot shipped none of it.That's a version of the same checklist any technical SEO migration needs, whether you're leaving HubSpot, WordPress, or Notion. Recovery timing after a move varies more than most teams expect, though the widest end of that variance describes a harder case than most HubSpot exits. A widely cited third-party study of 892 domain migrations, surfaced in Digital Applied's migration playbook, covers moves to an entirely new domain and 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. A HubSpot exit that keeps the same domain and just changes hosting and templates is a narrower change than swapping domains, so treat that 523-day figure as the ceiling for a hard case, not the expected outcome for a same-domain platform swap. Either way, the spread comes down to execution, not the platform you left. A clean redirect map and a same-day launch put you toward the fast end.
Once your content lives as Markdown files in a repo, the publishing question changes from "who has HubSpot editor access" to "what does our git workflow look like for content." A new post is a branch and a file. Review happens as PR comments instead of a HubSpot revision history nobody checks. A merge to main triggers the same build and deploy pipeline your product already uses, no separate HubSpot login and no separate mental model for the marketing team's tools versus engineering's.
That handoff is also where a repo-native writing tool fits, instead of a HubSpot content assistant plugged into a database you no longer have. A git-based AI blog writer reads your repo's conventions, drafts a post as a Markdown file on a branch, and opens a pull request the same way a human contributor would, so nothing auto-publishes and your existing review process still gates every post. If your migration is still ahead of you and you're building your keyword strategy from scratch rather than porting an existing HubSpot blog, our guide to SEO for SaaS covers picking winnable keywords and building topic clusters before you're locked into any platform's constraints.
Once your HubSpot 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 says ranking fluctuation during a migration is expected, and a small to medium site typically settles within a few weeks. The risk isn't leaving HubSpot, it's an unmapped URL or a redirect built after launch instead of before it.
No. HubSpot's own documentation states that URL redirects only work for domains connected to and hosted in HubSpot. The moment your domain points at a new host, HubSpot's redirect tool stops doing anything for that traffic, so the redirect layer has to live in your new host or CDN from day one, not get built as a HubSpot task partway through the move.
It depends what you're leaving. A former 16-year HubSpot partner agency puts a website-only exit from Content Hub Enterprise at roughly $85,000 saved over 5 years, and a full-platform exit (CRM, marketing, and CMS) at $300,000 to $400,000 over 5 years. Their broader point is that a $43,200/year Marketing Hub Enterprise license often runs $150,000 to $200,000/year in real total cost once partner retainers and admin time are counted.
No, not by default. An analysis of HubSpot CMS output found no built-in Organization schema for the homepage, no Article schema for blog posts, no FAQPage schema for knowledge base articles, and no BreadcrumbList schema for navigation, concluding that every HubSpot site starts at zero for schema markup and you have to add it yourself.
HTML files of your pages, blog posts, and templates, which HubSpot itself recommends specifically if you're importing content onto another platform. Separately, a CSV/XLS/XLSX data export covers fields like title, language, and URL, but HubSpot's own documentation describes no way to restore an entire site to a prior version, so the export is a starting point for conversion, not a database dump you can restore from.
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? Tell us about your blog and the founder will walk through it with you.
Keep reading
A Notion to git blog migration playbook: where Notion breaks down as a CMS for SEO, how to map redirects, and how to move without losing rankings.
How to join Google Search Console and GA4 by landing page URL, assign lead value with no revenue event yet, and stop last-click from hiding organic's real ROI.
Solo founder content marketing without a writer or agency: how much time it really costs, what only the founder can do, and a weekly schedule that holds.