HubSpot CMS to Webflow: redirects across subdomains, blog tags and /hubfs files

Open settings, website, domains and urls, and write down what is connected. A typical portal has www.example.com for website pages and the blog, info.example.com or offers.example.com for landing pages, sometimes blog.example.com for the blog on its own, and an email subdomain that does not matter here.

website and blog move, landing pages stay — the usual case. The map covers www only. Landing pages keep working on their subdomain, and links to them from the new site keep pointing there.

the blog was on its own subdomain — blog.example.com/slug to www.example.com/blog/slug is a cross-domain move. Webflow can only redirect paths on domains connected to the Webflow site, so either connect the blog subdomain to Webflow too and add rules there, or keep it on HubSpot with a redirect rule per post pointing at the new domain.

everything moves — each subdomain gets its own run and its own map, because each has its own sitemap and its own paths.

/about-us · /pricing · /solutions/enterprise — site pages, with the slug the editor chose. No trailing slash.

/blog/slug — posts, under the blog’s root url, which is /blog by default and can be anything. Portals with several blogs have several roots.

/blog/tag/name · /blog/topic/name · /blog/author/name — tag archives, the older topic archives, and author archives. Generated, indexed, and occasionally ranking.

/blog/page/2 · /blog/all — listing pagination and the all-posts listing.

/hubfs/file.pdf · /hs-fs/hubfs/… — files from the file manager, served under the site’s own domain. Gated downloads, one-pagers and images are linked from everywhere.

/hs/… · /_hcms/… · /cs/c/… — HubSpot’s own machinery: tracking, preview, email click tracking. Nothing to redirect.

?hsLang=de · /de/… — multi-language pages by query string or by folder, depending on how the portal was set up. Only the folder form needs rows.

• The sitemap, per domain. HubSpot writes /sitemap.xml on every connected domain, listing that domain’s pages and posts. Run each domain that moves as its own crawl; Silentfrog reads the sitemap at the start.
• Search Console, per property. The pages export for the domain that moves. It brings back the archived posts and retired pages that left the sitemap and kept their rankings (traffic data).
• Url redirects. Settings, website, domains and urls, url redirects. Standard rules are one line each; flexible pattern rules match many urls with one line, and those need expanding before they can be carried over.
• The file manager. Not a url list, but the place to check which pdfs are still linked from campaigns before deciding which /hubfs/ paths get a row.

site pages — exact matches if the slugs were kept, and on a HubSpot to Webflow rebuild they usually are. Renamed pages come out as fuzzy matches on the title (how matching works).

the blog — exact matches if the root stays /blog. If the Webflow collection is /insights, a directory rule with keep sub-paths, /blog/(.*) to /insights/%1, exported as one wildcard row (directory rules). Two blogs, two rules.

tag, topic and author archives — no Webflow successor. If tags became a categories collection, one manual row per tag that had traffic. Everything else under /blog/tag, /blog/topic and /blog/author to the blog index with all to one page. Important: a plain /blog/(.*) wildcard would send /blog/tag/name to /insights/tag/name, a 404. The archive rules must sit above the blog wildcard in the file. Silentfrog writes wildcard rows in the order the rules were added, so add the archive rules before the blog rule, and check the preview for exactly this.

pagination — /blog/page/(.*) to /blog. One row.

/hubfs/ files — per file, for the ones with clicks or backlinks. Upload them to Webflow, then a manual row pointing at the new asset url; Webflow accepts an absolute url as a target. The rest can 404, but they should not be the pdf that sales sent to a prospect last week.

Standard redirects are one source, one target, and they are handled like anywhere else: paste the sources into the url list when starting the run, and each resolves against the new site directly instead of chaining through the old target.

Flexible pattern redirects are the part that catches people. A rule like /resources/:slug to /blog/:slug stands for every url it ever matched, and none of them appear in the export as urls. The list of what it actually served is in Search Console and in the server-side traffic report, and those urls go into the url list too. If the pattern maps cleanly onto a folder, it becomes a directory rule on Webflow; if not, the urls get matched per row.

• List the connected domains and decide which ones move. One run per domain.
• Export the url redirects and the Search Console pages report for each domain that moves, while it is still on HubSpot.
• Start a run with the HubSpot domain and the Webflow staging domain; paste the redirect sources, the pattern rule’s served urls and the Search Console urls into the url list (starting a run).
• Add the archive rules first, then the blog rule, each with export as wildcard rule ticked, and check the preview for the tag and author paths.
• Sort by clicks, pick the /hubfs/ files worth a row, review needs review from the top and verify what you accept.
• Download the Webflow csv and import it (importing into Webflow), then switch the dns, publish, and crawl the old url list against the live site.

• Start with the domain list: landing pages on their own subdomain usually stay on HubSpot and need no redirect.
• One sitemap per connected domain, one run per domain that moves.
• Site pages are mostly exact matches; the blog is one wildcard if its folder changes.
• Tag, topic and author archives go to the blog index; add those rules before the blog rule so their rows sit above the blog wildcard.
• Expand flexible pattern redirects into the urls they served, then resolve every source against the new site directly.