When rankings slide after a HubSpot migration, the platform almost never deserves the blame. HubSpot CMS serves clean, fast, crawlable pages. What actually costs traffic is the cutover itself — and in practice it comes down to five specific, avoidable technical failures that happen in the days around launch.
We see the same five every time we get called in to repair a migration someone else ran: redirects that were never mapped, metadata wiped during import, canonical tags fighting each other on dynamic pages, schema left behind on the old CMS, and an indexing toggle pointed the wrong way.
That's why every migration Hubstack runs starts with an audit, not a copy-paste. Before a single template is built we inventory every live URL, its metadata, its schema and its traffic — so the new portal has to match a documented baseline instead of somebody's memory of the old site.
1. Broken or missing 301 redirects
Old URL structures and HubSpot URL structures are almost never 1:1, and blog and landing page slugs are where it breaks hardest. HubSpot's default blog pattern is /blog/post-name, while a WordPress site typically publishes /category/post-name — or /2019/04/post-name with dates in the path — so every legacy blog URL needs an explicit destination.
HubSpot's auto-mapping tool matches what it recognises during import and quietly ignores the rest: category archives, tag pages, paginated URLs, attachment pages, old campaign landing pages and anything that changed slug along the way. A manual redirect map, built from a full crawl plus your Search Console and analytics URL exports, is the only way to know the tail is covered.
We build that map before launch, load it into HubSpot's URL redirects, then re-crawl the old URL list post-cutover to confirm each one returns a single 301 to a live 200 — no chains, no loops, no soft 404s dumped on the homepage.
2. Lost or duplicated metadata
Bulk imports are the fastest way to lose years of title tag work. Page titles and meta descriptions often come across empty, truncated, or worse — templated identically across dozens of pages because the import used a single default pattern for a whole content type.
The damage doesn't always show up as a ranking drop. Rankings can hold while click-through rate collapses, because every result in the SERP now carries the same generic description instead of the specific promise that earned the click.
Our baseline export includes the title and description of every indexed URL, so post-launch QA is a diff, not a guess. Anything that doesn't match the old value — or a deliberately improved one — gets fixed before we hand over.
3. Canonical tag conflicts
HubSpot generates a lot of pages you didn't explicitly create: blog listing pages, pagination, tag and author archives, and language variants. Configured carelessly, those pages self-canonicalise, or point at the wrong parent, and Google gets contradictory signals about which URL is the real one.
The most common outcome is that paginated listing pages and tag archives compete with the posts themselves for the same terms, diluting internal signals across near-identical content.
We set canonical behaviour explicitly for listing, pagination and tag templates, keep archive pages out of the index where they add nothing, and verify the rendered canonical on each template type rather than trusting the setting.
4. Schema markup left behind
Structured data lives in the old theme's templates, so it does not travel with your content. Organization, BlogPosting and ProductGroup markup that took months to earn rich results simply isn't there on day one of the new portal.
The loss is immediate and visible: review stars, breadcrumbs, FAQ expansions and product detail disappear from your results, and with them a chunk of SERP real estate that competitors keep.
We port the existing schema into HubSpot modules and templates during the build, tighten it where the old markup was invalid, and validate every template type before launch — so structured data ships with the site instead of being retrofitted a quarter later.
5. Indexing left open on staging or closed on the live domain
HubSpot has a portal-level toggle that controls whether search engines may index your content, plus per-domain and per-page controls. Missing it cuts both ways: Google indexes a staging subdomain and starts competing with your own site, or the live domain launches with indexing blocked and quietly disappears.
The closed-on-live version is the expensive one, because nothing looks broken. The site loads perfectly for humans while robots.txt and the noindex settings keep crawlers out for weeks.
Our launch checklist verifies the live domain's robots.txt and page-level directives, confirms staging stays excluded, then submits the new sitemap and watches coverage reports for the first fortnight.