A website migration needs an account of what happens to every important URL. A new design can look complete while old service links lead nowhere, staging directives remain in place or the canonical points at the wrong destination. Build the migration checklist around the old-to-new relationship and verify the public result after cutover.

TLDR: Inventory the current URLs, approve a destination for each, test redirects and canonical signals, and check indexability after launch. Preserve the before-state and assign an owner for exceptions. No checklist can guarantee that rankings or traffic remain unchanged during a move.

Sources checked September 7, 2026. The redirect map below is fictional. No live routing, DNS or Search Console changes were made for this article.

Separate platform selection from migration acceptance

If you are still choosing a platform, our WordPress and HubSpot CMS comparison addresses that decision. This checklist starts after the destination is agreed and focuses on search-related cutover evidence.

We recommend retaining working URLs when there is no approved reason to change them. When a URL must change, document the intended replacement and the person who approved the mapping. Keep content consolidation separate from a routine move so deleted or merged pages do not disappear without a decision.

Inventory the current website before CMS migration

Combine a crawl of the current site with the URLs your team knows matter: service pages, blog posts, campaign destinations, linked downloads and pages receiving search or referral visits. Record the source of each entry and preserve the baseline before changing the site.

We recommend fields for the original URL, current status, canonical, page purpose, proposed destination and decision. Add a reason for any intentional removal. Do not rely exclusively on the navigation menu; it may omit older pages that still receive visits or links.

Treat forms, tracking and consent continuity as a parallel workstream with its own acceptance. A correct redirect does not prove a lead form or analytics event works.

Approve the redirect map

Google recommends permanent server-side redirects for moved URLs and warns against sending unrelated old pages to a single irrelevant destination. It also recommends linking directly to the final destination rather than creating unnecessary redirect chains. Google: site moves.

The following is a fictional mapping review, not a configuration to deploy.

Original path Proposed destination Review result
/old-service /services/current-service Test the approved equivalent destination
/old-guide /resources/current-guide Confirm the guide exists and serves the same need
/previous-offer / Hold: the homepage may not answer the old offer's purpose
/loop-a /loop-b, which returns to /loop-a Reject: redirect loop
/missing-guide /resources/not-built Hold: destination is unavailable

Have the content owner approve relevance as well as technical behavior. A redirect can return the intended status and still take a visitor to the wrong subject.

Confirm where each redirect will run

HubSpot's redirect tool applies to domains connected to and hosted in HubSpot. The documentation also states that file URLs cannot be redirected through this tool. Verify the host and URL type before assuming a CMS redirect can handle every entry in your map. HubSpot: URL redirects.

For a source that remains on another host, identify the system responsible for the response and the authorized owner of that configuration. Keep files, subdomains and external campaign links in the inventory instead of excluding them because they need a different method.

Do not turn a broad pattern rule on before reviewing its matches. Test representative edge cases and preserve a rollback copy of the current rules.

Check canonical URLs and SEO signals in Content Hub

Google's migration guidance calls for updated canonical references, internal links and sitemaps. It also directs site owners to review any staging noindex rules when the new site becomes public. Confirm those signals on the final URL rather than only in the page editor. Google: migration annotations and launch checks.

We recommend a page-level acceptance record covering:

  • Delivery: The intended public destination loads without an unexpected login or error.
  • Content: The page retains the approved purpose, useful text and important links.
  • Canonical: The final rendered and source signals identify the approved URL.
  • Indexability: The intended public page is not accidentally blocked or marked noindex.
  • Internal links: Navigation and in-body links use the final approved destinations.
  • Metadata: The title and description match the new page and approved content.

For campaign pages, our landing-page overview provides related context. Keep the campaign's destination in the same URL map as the main site.

Run prelaunch and postlaunch checks separately

Before launch, verify the proposed map and staged content in the available test environment. Record limitations where the final domain or routing cannot yet be tested. Do not mark those checks passed from a preview alone.

After the authorized cutover, test the actual old URLs through to their final destinations. Check the response chain, final content and search signals. Capture exceptions with an owner and a decision to repair, accept or restore the prior behavior.

Keep a defined review window for the relevant crawl and Search Console evidence. A submitted sitemap or indexing request is not confirmation that every page has been indexed. Separate observed delivery from search-engine processing and performance.

Plan migration quality assurance by page type

A HubSpot CMS migration can involve service pages, campaign landing pages, blog posts, resource explanations and downloadable files. Each surface needs a destination and an acceptance check appropriate to its purpose.

Group the inventory by template and content type so repeated patterns are visible. Then identify the exceptions that need individual review. A shared page template can pass while an unusually long article or embedded table still fails.

Preserve content that has a defined job

Before moving website content, record what the existing page helps the reader do. Retain important explanations, headings, useful links and qualified claims unless an approved content decision changes them.

Do not turn a migration project into an unrecorded content rewrite. If a page is being consolidated, identify the material moving to the destination and the material intentionally being retired.

The marketing team and technical team should agree on that decision. A developer can verify the response code but may need the content owner to confirm the destination serves the original intent.

Check blog migration separately

Review post URLs, authors, tags, images, publication history and body structure. Confirm which metadata the migration method preserves and which fields need deliberate mapping.

Inspect representative long posts, tables, image captions and older embedded content. Keep the original source files and export so a missing section can be recovered.

The new blog page should expose the approved content and links on the actual HubSpot template. A successful import count does not prove every article migrated correctly.

Check the title and meta description in the final page

Compare the approved metadata with the rendered destination. Look for accidental template defaults, duplicate titles or descriptions that no longer match the page.

Keep title changes intentional. A platform move alone does not justify replacing a useful page title with a generic service label. If the content purpose changed, document the new title alongside that decision.

Make the cutover plan operational

Name the person responsible for routing, the person checking content and the person authorized to decide whether to proceed or restore the prior behavior. Keep contact and escalation details available to the launch team.

Define which checks must pass before cutover and which require the final public domain. A staged preview can demonstrate the content layout, but it cannot establish the public DNS and response chain.

Separate domain changes from CMS changes

A move to a new content management system does not necessarily require a new domain or new paths. Record the specific changes in scope.

Where the old site remains responsible for an old domain, its hosting arrangement may still be needed to serve redirects. Identify that dependency before cancelling or removing infrastructure.

Do not promise a complete migration based solely on the new site loading. Verify that the old entry points continue to behave according to the approved map.

Include XML sitemap review

After the authorized launch, inspect the actual XML sitemap and confirm it lists the intended canonical URLs. Check that obsolete or unavailable destinations are not being presented as current pages.

A sitemap is a discovery signal. Keep its submission separate from search-engine processing and indexing evidence. Do not label a page indexed merely because its URL appears in the file.

Keep measurement continuity visible

Preserve the baseline dates and collection definitions used for Google Analytics, HubSpot analytics or other approved measurement tools. A tracking configuration change can make a before-and-after traffic comparison misleading.

Forms, consent, events and lead routing require their own tests. Record those results alongside the migration acceptance without treating search-related QA as proof that the entire CRM process works.

Review exceptions after launch

Inspect observed broken links, redirect chains, unexpected canonicals and crawl issues against the original map. Prioritize the affected reader path and business purpose.

Assign each issue an owner and a verification condition. Keep a repair, an accepted limitation and a search engine's pending processing state distinct.

A clear exception log gives the team something concrete to work through. It also prevents ordinary processing delays from becoming a reason to make repeated, unplanned URL changes.

Treat the HubSpot migration process as a release

A CMS migration moves an existing website into a different publishing environment. Your release plan should cover both the web pages and the operational dependencies around them: forms, analytics, redirects, access and ongoing maintenance.

We recommend defining the migration boundary before selecting tools or a service provider. State which URLs and content types will move, which will remain where they are and who verifies the result. HubSpot Content Hub can be part of the proposed architecture, but the product name alone does not establish that every requirement is supported.

For a website-to-HubSpot project, keep the original inventory beside the destination inventory. Use that comparison to identify missing pages and unexpected destinations. A complete file transfer is not the same as a complete migration.

Frequently asked questions

Should every old URL redirect to the homepage?

No. Review the purpose of each old page and choose a relevant replacement when one exists. Document intentional removals rather than hiding them in a blanket rule.

Can the editor preview prove the migration is complete?

No. It can support staged-content review, but final routing, canonical signals and public delivery need checks on the actual URLs after cutover.

Does a CMS move require changing every URL?

We recommend keeping suitable existing URLs unless the approved design or content plan requires a change. Document the reason and destination for each changed URL.

Can this checklist guarantee ranking preservation?

No. It provides an acceptance process for migration work. Search visibility still needs observation after the move, and technical completion does not guarantee a ranking outcome.

Make the URL map a launch requirement

Our website design services can help you define the migration scope and acceptance evidence alongside the new site.

If the routing or indexability decisions are unclear, talk with Selworthy before approving cutover.