HubSpot CMS migration SEO comes down to one rule: every URL that earned traffic or links on the old site must resolve, with a single 301, to the page on the new site that carries the same content and intent. When organic traffic drops after a move onto HubSpot, the cause is almost never HubSpot itself; it is URL paths that changed without redirects, a blog that moved folders, links and images still pointing at old paths, and service pages that came back as thin templates. This guide walks through the repair sequence we run, the HubSpot settings that usually cause the loss, and the one report to watch until recovery is confirmed.
Definition first. A website migration, for search purposes, is any change that alters the URLs, templates, content or hosting Google has already crawled and ranked; a CMS move onto HubSpot usually changes all four at once.
Why traffic drops after a HubSpot migration.
Google ranks URLs, not businesses. When a URL that held a position for years starts returning 404, Google keeps it in the index for a while, watches it fail, and drops it. The new URL starts from zero unless a 301 tells Google the two are the same page. Everything that goes wrong in a migration is a variation of that mechanism.
On the migration we most recently repaired, four things had happened at once. Service pages moved to new paths with no redirects. The blog moved from one folder to another, so every post URL changed. Image paths and internal links still pointed at the old structure. And the service pages had been rebuilt on a template with a hero, three icons and two sentences, while a city page came over intact with its full content. Google did what the content told it to: the city page began ranking for every head term the service pages used to own, at a worse position than any of them had held.
The data signature is specific: organic sessions fall, impressions hold because Google still sees the site, and clicks go nowhere because the page being shown is the wrong one and sits too low to be clicked. If that pattern appears within weeks of a launch, you are looking at a migration, not an algorithm update.
Build the URL inventory before touching anything.
The new site cannot tell you what it lost. The inventory has to come from sources that remember the old site.
- Search Console Performance report, Pages tab, set to the 16 months before launch and exported in full. Every URL with impressions is a URL that needs a destination.
- Wayback Machine captures of the old sitemap and the old blog index, which recover URLs that had no search traffic but did have backlinks.
- The old analytics landing page report, which catches URLs that earned direct and referral visits.
- Search Console Links report, External links, Top linked pages, because a URL with backlinks needs a redirect even if it never ranked.
- A crawl of the old site if it is still reachable on a staging host, which is the only complete list you will get.
Merge those into one sheet: old URL, status code today, new URL, match type (exact, closest equivalent, or no equivalent), and a done flag. On a site with a few hundred URLs this takes an afternoon, and it is the highest-value afternoon of the whole project.
Build and load the redirect map in HubSpot.
HubSpot settings that change URLs without warning.
Four HubSpot specifics caused most of the damage we have repaired, and none are bugs. They are settings a builder can change without realizing they change public URLs or what Google reads.
Blog root URL. Each HubSpot blog has a root URL set under Settings, then Content, then Blog, on that blog's General tab. Every post URL is that root plus the post slug. Change the root from one folder to another and every post URL changes at once, with no redirect created automatically.
Pages versus Blog. HubSpot keeps website pages, landing pages and blog posts as separate content types with separate URL rules. Content that lived as posts on the old CMS often gets rebuilt as website pages on HubSpot, which puts it outside the blog root, outside the blog listing and outside the RSS feed. Decide the content type for each old URL before the build, and keep the slug identical wherever possible.
Domain and language settings. A primary domain change, or a language slug enabled under Domains and URLs, prefixes or alters paths sitewide.
Template CSS that hides h1s. Several themes render the page title in a hero module and hide it with a display: none rule for one visual variant, or render the visible headline as a div while the h1 sits empty in the DOM. Google reads the rendered HTML, so a page can look correct in the editor and have no usable h1, or two. Inspect the rendered source of every template.
Restore content depth and fix canonicals and titles.
Redirects stop the bleeding; they do not win back the positions the content lost. On the migration we repaired, the service pages had gone from full pages to templated stubs, so we rebuilt each one with the questions a buyer asks before calling, the process, the factors that move price, and a set of FAQs marked up with FAQPage schema. The city page kept its content but gained clear links pointing to each service page with the service name as the anchor, so Google had a reason to hand the head terms back.
At the same time, check three things on every key page in the HubSpot editor's Settings tab: the page title is written for that page and not inherited from a template pattern, the meta description is present, and the canonical URL under Advanced options points to the page itself. Duplicate canonicals across templated pages are common after a migration, and they tell Google to consolidate pages you wanted ranked separately. Our migration checklist has the full pre-launch list; these three fields are where a HubSpot build most often drifts.
If the template cannot hold the depth a service page needs, that is a design problem, which is why we treat template structure as part of web design rather than something to patch after launch.
The internal linking pass.
Every post that came over carried links and image paths from the old structure. A find and replace across the blog is the first pass. The second pass is editorial: read each post, add a link to the relevant service page with a descriptive anchor, and remove links to pages that no longer exist. On a blog of seventy-odd posts this is a day of work.
It is also the step that most often moves the ranking page from the city page back to the service page, because internal anchors are the clearest signal Google has about which page a site thinks is the answer. If every post links the city page for roof repair, Google keeps serving the city page. If every post links the roof repair page with that anchor, the vote changes.
“Redirects stop the bleeding. Content depth and internal links are what get the rankings back.”
Monitor for at least eight weeks.
Recovery is not a traffic number; it is the right page owning the right query again. The report that shows this is Search Console Performance, filtered to one query, with the Pages tab open: for each head term, it tells you which URL Google is serving. Check it weekly for at least eight weeks after the fixes ship, and expect the wrong page to hold for a few weeks before it flips. Also watch the Pages report under Indexing for a falling count of Not found (404) entries, and the Sitemaps report for a discovered count that matches what you submitted.
| Symptom | Likely cause | What to do |
|---|---|---|
| Organic sessions fall across most pages within two weeks of launch | Old URLs returning 404 or a soft 404 | Build the one-to-one 301 map from the URL inventory and load it in HubSpot URL Redirects |
| Blog posts vanish from search while site pages hold | Blog root URL changed and posts moved folders without redirects | Add a flexible pattern redirect for the old folder and keep slugs identical where possible |
| Broken images and internal 404s on the new site | Content copied with links hard-coded to old paths | Find and replace across posts, then crawl to confirm zero internal 404s |
| A service query ranks the city page or the homepage instead of the service page | Service pages became thin templates with less content than the city page | Restore depth on the service page, add FAQ schema, link to it from the city page with the service anchor |
| Titles show as generic or duplicated in results | Template title pattern overwrote hand-written titles | Set the title per page in the editor Settings tab and confirm the canonical points to itself |
| Rankings partly recover but the wrong page still owns head terms | Internal links still favor the old winner | Run the internal linking pass so every post points to the intended page with a descriptive anchor |
Mistakes that keep traffic down after a migration.
- Redirecting every old URL to the homepage, which Google treats as a soft 404 and which passes nothing to the pages that should rank.
- Building the inventory from the new site's sitemap, which by definition contains only the URLs that survived.
- Changing the blog root URL after launch to tidy things up, which creates a second migration on top of the first.
- Leaving the old host or a staging domain live without redirects, so two copies of every page compete.
- Trusting the visual editor for the h1 and title when the rendered HTML has a hidden or duplicated heading.
- Declaring victory when sessions tick up, before the query-to-page report shows the intended pages winning.
Why did my organic traffic drop after migrating to HubSpot?
Almost always because URLs changed without one-to-one 301 redirects, so Google saw the old pages fail and the new pages start from zero. Common HubSpot causes are a changed blog root URL, posts rebuilt as website pages, and service pages rebuilt as thin templates. Inventory the old URLs, redirect each one, then restore content depth on the pages you need to rank.
How do I set up redirects in HubSpot after a migration?
Go to Settings, then Content, then Domains and URLs, then URL Redirects. Add standard redirects for one-to-one paths, use flexible pattern redirects to move whole folders such as an old blog root, and import a CSV for bulk work. Set every redirect to permanent (301), then recrawl the full list of old URLs to confirm each returns a single 301 to a live page.
How long does it take to recover rankings after a website migration?
Plan for at least eight weeks of weekly monitoring after the fixes ship, and longer for large sites. Google has to recrawl the old URLs, follow the redirects, and re-evaluate which page should own each query. Watch the Search Console query-to-page view for your head terms; recovery is confirmed when the intended page is served, not when sessions tick up.
Why is a city page ranking instead of my service pages after the migration?
Because the city page kept its content and the service pages lost theirs. When a service page becomes a hero, three icons and two sentences, Google picks the deepest page on the topic, which is now the city page, and serves it at a lower position. Rebuild the service pages with real depth and FAQ schema, then link to them from the city page and every relevant post.