You just finished migrating 300 pages from WordPress to HubSpot. The DNS is updated. The 301 redirects are mapped. The staging site looked clean. Your project manager sent the "we are live" Slack message and everyone reacted with party emojis.
Then you open Google Search Console four days later.
Half your blog posts have duplicate meta descriptions pulled from template defaults. Ninety-something pages lost their featured image alt text entirely. The Open Graph tags on your entire /resources section are either blank or pointing to the old domain. And someone on the team quietly admits they forgot about canonical URLs on the landing pages.
Welcome to the part of CMS migration that nobody puts in the project plan.
Why the migration itself is never the problem
I have been through three HubSpot CMS migrations in the past four years. Every single time, the actual migration went fine. The data transferred. Pages loaded. Redirects fired correctly. The technical move is well-documented and, honestly, pretty straightforward if you follow the standard checklist.
The disaster is always what comes after.
Every CMS stores and renders metadata differently. WordPress might auto-generate your og:description from the first 160 characters of your post body. HubSpot expects you to set it manually in the page settings. Drupal handles canonical URLs one way. Webflow handles them another.
The result is that your content technically migrated, but the metadata layer that search engines and social platforms rely on is either missing, duplicated, or just plain wrong.
What I typically find during a post-migration audit
After every migration, there is a phase I call "the spreadsheet phase." This is where someone (usually me) exports every page and blog post into a spreadsheet and manually audits the metadata field by field, row by row.
Here is what consistently shows up:
Title tags that are blank or populated with template defaults like "New Page" or the CMS placeholder text. Meta descriptions that were pulled from the wrong field during import, so they are either truncated gibberish or identical across dozens of pages. URL slugs that gained extra characters or lost hyphens during the conversion process. Internal links still pointing to old URL structures that somehow bypassed the redirect map. Featured image alt text that vanished completely during the transfer.
For a 200-page site, the audit alone takes about three full days of focused work. For a 500-page site with an active blog, you are looking at a week or more.
And this is just the audit. Fixing everything takes even longer.
The real bottleneck is not finding the problems
Finding metadata issues is tedious but manageable. Screaming Frog, Sitebulb, or even a simple crawl export will surface most of them. The real bottleneck is fixing them inside HubSpot.
HubSpot does not offer native bulk editing for page metadata. You cannot export all your meta titles and descriptions to a CSV, fix them in a spreadsheet, and re-import. The official workflow is: open a page, click into settings, update the field, save, publish, go back to the page list, find the next page, and repeat.
For 300 pages, that is roughly 300 individual editing sessions. Each one requires multiple clicks, a page load, and a publish confirmation. The HubSpot community forums have threads going back years asking for bulk metadata editing, and the feature requests have hundreds of upvotes with no native solution in sight.
This is where the gap between "migration complete" and "migration actually done" becomes painfully obvious.
A better post-migration audit workflow
Over the past few migrations, I have built a workflow that cuts the post-migration cleanup time significantly. Here is the general approach:
First, crawl the migrated site immediately, before Google has fully re-indexed everything. Export the full crawl data including titles, meta descriptions, H1 tags, canonical URLs, alt text counts, and status codes.
Second, build your audit spreadsheet. Map every URL against the pre-migration data you should have captured during the planning phase. Flag discrepancies in a dedicated column. Prioritize by traffic. Your top 50 organic pages should be audited first because those are the ones where metadata errors will cost you the most.
Third, fix in bulk. This is the step where most teams burn out because they try to do it inside HubSpot one page at a time. Tools like Smuves exist specifically for this problem. You can pull your HubSpot CMS content into a spreadsheet-style interface, edit metadata fields across hundreds of pages at once, and push the changes back. The activity logs give you a clear audit trail of what changed, when, and by whom, which matters a lot when multiple people are touching pages during a migration cleanup.
Fourth, re-crawl and validate. After bulk fixes, run another crawl to confirm everything stuck. Compare against your pre-migration baseline. Check Google Search Console for any new crawl errors that appeared.
The alt text problem nobody talks about
One metadata field that consistently gets destroyed during migrations is featured image alt text. Most migration tools focus on transferring the image file itself but ignore the alt text attribute. The result is hundreds of pages with images that have no alt text, which hurts both accessibility and image search visibility.
This is one of those issues that is invisible until someone audits for it specifically. If you are doing a post-migration audit, add an alt text column to your spreadsheet and flag every page where the featured image alt text is empty or generic. The Smuves blog has a solid breakdown of why this specific field gets overlooked and how to approach fixing it at scale.
What should be in every migration project plan
If I could add one section to every CMS migration project plan, it would be a dedicated "Post-Launch Metadata Audit" phase with its own timeline and resource allocation. Not a bullet point under "QA." An actual phase with assigned owners and deadlines.
Here is what that section should include: a pre-migration metadata export as a baseline, a crawler setup ready to run on launch day, a prioritized audit checklist sorted by organic traffic, a bulk editing tool or workflow for fixing issues without the one-page-at-a-time grind, and a 30-day monitoring plan covering Search Console, analytics, and social sharing previews.
The migration is not done when the site goes live. It is done when the metadata is clean. Every team that learns this the hard way wishes someone had told them sooner.
Top comments (0)