DNS Migrations for HubSpot CMS: A Field Guide

When moving a website (or part of it) onto HubSpot CMS, the DNS migration is the moment where planning meets the real world: domains flip, SSL provisions, caches warm, and search engines follow the breadcrumbs you’ve carefully laid out. This Lab is a practitioner’s guide to doing that safely—pre-work, cutover, and post-move—with concrete tasks for SEO, IT, and content teams.

This lab avoids any custom MDX components. It is plain Markdown/MDX so you can paste it directly into your repository.

What You’ll Accomplish

• Build a one‑page migration brief that aligns Marketing, SEO, and IT.
• Decide which hostnames will be Primary, Secondary, or Redirect inside HubSpot.
• Prepare DNS records for site hosting and, if you send email from HubSpot, for DKIM/SPF/DMARC.
• Stage and publish content in a controlled sequence.
• Migrate and validate redirects (one‑to‑one, section‑level, and bulk CSV).
• Validate SSL, canonicalization, and critical user flows.
• Monitor and stabilize SEO signals, with a clear rollback path.

Tip: Keep your migration window small and well-communicated. Reduce TTLs a day or two ahead of time so DNS changes propagate quickly, then raise TTLs again after stability returns.

1) Project Setup: Roles, Risks, and Runbook

Stakeholders and Responsibilities

• Project Lead (you): drives the plan, owns approvals, coordinates handoffs, and keeps the single source of truth.
• Client IT / DevOps: controls DNS provider access; executes record changes; confirms change windows and incident/rollback procedures.
• SEO Lead: owns the redirect map, canonical/robots decisions, Search Console actions, and post‑cutover monitoring.
• Content/Marketing: ensures all pages are authored, staged, and ready to publish; owns forms/CTAs.
• Legal/Compliance (if required): validates cookie banners, privacy, and policy content.

One‑Page Migration Brief (Template)

Copy this into your issue tracker or project wiki and fill it out:

• Scope: Move {www.brand.com} web property hosting to HubSpot CMS. Email remains on existing provider.
• DNS Provider: {Cloudflare / Route 53 / GoDaddy / etc.} with console access granted to IT.
• Hostnames & Roles:
  • Primary: www.brand.com (main site)
  • Redirect: brand.com (apex → https://www.brand.com/)
  • Secondary: blog.brand.com, go.brand.com (if used for blogs/LPs)
• SSL: Use HubSpot’s automatic SSL (default); consider custom certificates only if policy requires.
• Email Auth (if sending from HubSpot): DKIM/SPF/DMARC records added for the sending domain.
• Redirects: CSV bulk import for one‑to‑one maps; pattern rules for sections (e.g., /blog/* → /insights/:splat).
• Staging & Release: Content prepared in HubSpot staging; publish to live domains on cutover.
• Search Console: Properties verified for both old and new contexts; decide whether “Change of Address” applies (domain/subdomain changes, not simple HTTPS moves).
• Change Window: {Date, Time, Timezone} with a 60–120 minute observation period post‑cutover.
• Rollback: Reapply saved DNS records and disable new redirects. Keep the old record set stored securely.
• Success Metrics: 0 critical 404s; 200/301 correctness on top URLs; forms/CTAs and key journeys work; search impressions stable in the following weeks.

2) Domain Roles in HubSpot: Primary vs Secondary vs Redirect

HubSpot lets you connect domains as different roles:

• Primary Domain: The default domain for specified content types (e.g., website pages). Use this for www.brand.com in most cases.
• Secondary Domain: Additional hostnames that can host content but are not the default (e.g., blog.brand.com, go.brand.com).
• Redirect Domain: Hostnames that will not host content but will 301 redirect inbound requests to another connected domain.
• Email Sending Domain: The domain used for marketing email authentication (DKIM/SPF/DMARC) if you send email via HubSpot.

Common pattern: Keep the website on www.brand.com as Primary and 301 the apex brand.com to https://www.brand.com/ as a Redirect. This avoids apex‑A/ALIAS/flattening complexities at many DNS providers and keeps SSL straightforward.

Create an inventory table before you touch DNS:

3) Pre‑Work: Technical Readiness

3.1 Access and Checklists

• Confirm HubSpot subscription allows the number/types of domains you plan to connect.
• Ensure DNS provider access with permissions to add/modify records.
• Export the current DNS zone as a backup (record type, host, value, TTL).
• Lower TTLs (e.g., to 300 seconds) 24–48 hours ahead of cutover.

3.2 Connect the Domains in HubSpot (Preview Stage)

1. In HubSpot, go to Settings → Domains & URLs → Connect a domain.
2. Choose the role (Primary/Secondary/Redirect/Email Sending) and content type(s) as prompted.
3. HubSpot will generate DNS records (commonly CNAMEs) to add at your provider.
4. Share a DNS change sheet with IT listing each record: type, name/host, value/target, and TTL.

If you can, complete the connection and verification before the change window so SSL can provision in advance and you can validate ownership.

3.3 SSL Strategy

• HubSpot will automatically provision SSL for connected domains. Provisioning commonly completes within minutes, but allow extra time in your plan to avoid surprises.
• If your security policy mandates a custom certificate (e.g., EV/wildcard with a third‑party CA), plan for that early because it changes the flow and adds coordination steps.

3.4 Email Authentication (Optional but Recommended)

If you will send marketing email through HubSpot:

• Add DKIM CNAME records as provided by HubSpot for your sending domain.
• Ensure SPF includes HubSpot’s sending mechanism (either via include: or provider‑specific config).
• Publish DMARC at the organizational domain with an initial policy (e.g., p=none) to collect reports, then tighten over time (quarantine/reject) once alignment is clean.
• Some DNS providers (e.g., Cloudflare) require you to turn proxy off for DNS records used for validation and email auth. Be mindful of CNAME flattening and other provider behaviors that can subtly rewrite values.

3.5 Redirect Mapping (Do This Before Cutover)

Create a redirect map in a spreadsheet with at least these columns:

• Original URL (path only or full URL if legacy host will change)
• Redirect to URL (final destination)
• Redirect type (301 is normal for permanent moves)
• Notes (e.g., “merged,” “sunset,” or “nearest category”)

Group by sections to spot patterns. Use flexible pattern rules for broad moves (e.g., /blog/* → /insights/:splat), and keep one hop whenever possible (avoid chains like A → B → C).

3.6 Content Staging & Release Choreography

Use HubSpot’s content staging to prepare the release:

• Stage cloned or new pages in a sandboxed environment.
• Run QA on staged URLs: templates, navigation, forms, CTAs, gated assets, and tracking.
• Freeze edits shortly before the window so what you approve is what launches.
• Confirm the target live domain each staged page will publish to.

4) SEO Controls Before the Flip

Crawlability and Canonicals

• Ensure pages intended to launch do not ship with noindex or blocked via robots rules.
• Standardize canonical tags to your chosen host and protocol (HTTPS).

Search Console and Sitemaps

• Verify properties in Google Search Console for the relevant hostnames. If the migration involves a domain or subdomain change, plan for a Change of Address request after redirects are live and stable. This is not needed for simple HTTP→HTTPS moves.
• Prepare and validate XML sitemaps that reflect the new URL structure. Have them ready to submit immediately after launch.

Redirect QA Targets

• Export top URLs from your analytics and backlink data (e.g., top 500–2000). Ensure each has a mapped destination.
• Identify parameterized URLs and trailing‑slash differences; decide whether to match query strings and how you will treat slash/extension variants.
• If thin or deprecated pages must be removed, redirect to the most relevant higher‑level category rather than the home page to preserve intent.

5) The Cutover Plan (During)

Below is a generic timeline you can adjust to your window and team:

Example Timeline

• T‑60 minutes: Final Go/No‑Go checkpoint; freeze content edits; IT on standby; SEO ready with tests.
• T‑45 minutes: In HubSpot, confirm domain roles (Primary/Secondary/Redirect) and content type mappings are correct.
• T‑30 minutes: Publish staged pages to the live domain(s) so content exists the moment traffic flips.
• T‑15 minutes: IT executes DNS changes using the prepared sheet:
  • www CNAME → HubSpot target provided in the connect flow
  • Apex handling (prefer apex → www redirect)
  • Email sending DNS (DKIM/SPF/DMARC) if scheduled for this window
• T+0 to +30 minutes: Validate SSL is active and that key pages render on HTTPS with the correct host.
• T+30 to +60 minutes: Import redirect CSV and enable pattern redirects. Spot‑check top URLs.
• T+60 to +120 minutes: SEO run: verify 200/301 responses, canonicity, forms/CTAs, and analytics firing.

Commands & Checks (use a terminal)

# Confirm DNS resolution (CNAME/A/AAAA)
dig +short www.brand.com
dig +short CNAME www.brand.com

# Confirm HTTP → HTTPS and non-www → www behavior
curl -I http://brand.com
curl -I https://brand.com
curl -I http://www.brand.com
curl -I https://www.brand.com

# Spot-check a few mapped legacy URLs
curl -I https://www.brand.com/old-path

Expect to see 301 where you intend to redirect, 200 on final destinations, and consistent HTTPS on canonical hosts.

6) HubSpot Redirects (How to Work With Them)

• Standard redirects: One‑to‑one mappings for specific pages or files. Default to Permanent (301) for migrations.
• Flexible/pattern redirects: Ideal for whole sections or blogs. Examples:
  • /blog/* → /insights/:splat
  • /resources/* → /library/:splat
• Bulk import (CSV): Fastest path when migrating dozens or hundreds of URLs.

Sample CSV (typical columns):

Original URL,Redirect to URL,Redirect type,Ignore trailing slash,Match query string
/old-path-1,/new-path-1,301,false,false
/blog/*,/insights/:splat,301,false,false
/resources/*,/library/:splat,301,false,false

Guidelines:

• Keep one hop. If you must chain temporarily, replace it with a direct A → C as soon as possible.
• Match or normalize trailing slashes consistently across rules.
• Avoid redirecting everything to the home page—redirect to the closest relevant content.

7) Post‑Cutover: Stabilize and Signal

Search Console Actions

• If your migration qualifies, submit Change of Address and re‑submit your sitemaps. Use URL Inspection on representative pages to confirm Google can render and sees the correct canonical.
• Watch coverage reports for newly indexed URLs and for declining errors.

Watchlists (First 7–14 Days)

• Crawl errors: 404s, soft 404s, 5xx. Fix or map fast.
• Redirect chains/loops: collapse chains to a single hop; remove loops immediately.
• Canonical tags: confirm the preferred host/protocol.
• Performance: page speed and Core Web Vitals; ensure no regressions caused by asset paths.
• Analytics & Conversions: forms, CTAs, and goal tracking should match or exceed pre‑migration baselines.
• Email (if configured): monitor DMARC aggregate reports, bounces, and spam placement while DNS changes settle.

System Pages & Edge Cases

• Ensure 404/500/system pages are on‑brand and helpful (search, key links).
• Validate file hosting paths for images and downloads (legacy absolute URLs are a common source of mixed content and 404s).
• Confirm global navigation and footer consistency across domains.

8) Special Topics and Gotchas

8.1 Apex vs www

Using www as Primary and apex as a Redirect is the least surprising pattern cross‑provider. Hosting directly on the apex can require provider‑specific features (ALIAS/ANAME/flattening) and increases foot‑guns when you later need to shift targets. If brand guidelines insist on apex, plan extra time for DNS nuances and testing.

8.2 Cloudflare Nuances

When using Cloudflare:

• Turn proxy off (grey cloud) for any records that must resolve directly during validation (common for domain connection and email auth).
• Be aware of CNAME flattening at the root and ensure it won’t interfere with how your records need to resolve.
• Review Page Rules or Redirect Rules that might conflict with HubSpot’s own redirects or with your intended canonical behavior.

8.3 Custom SSL Certificates

If your organization requires a custom certificate (e.g., company‑wide wildcard or EV), involve security early and schedule additional lead time for issuance/validation. Align cert expiration and renewal processes with whoever ultimately owns the domain in HubSpot.

8.4 Redirecting Whole Subdomains

To sunset a legacy subdomain, connect it to HubSpot as a Redirect domain and apply a simple 301 to your chosen destination (e.g., https://www.brand.com/). Use URL redirects if you also need path‑level mapping.

8.5 Legacy Landing Pages and Campaigns

Old campaign pages can redirect to nearest equivalents. If they still earn visits or links, prefer specific mappings to preserve intent. For truly obsolete pages, consolidate to relevant category hubs rather than the home page.

8.6 Mixed Content and Asset Paths

If you previously referenced assets with http:// or absolute legacy hosts, expect mixed‑content warnings after the move. Fix by updating templates to protocol‑relative or HTTPS asset paths and by migrating important assets into HubSpot’s file system or your chosen CDN with HTTPS.

8.7 Internationalization (if applicable)

If you use language variations:

• Maintain consistent redirect behavior per locale.
• Keep hreflang tags accurate and canonicalized to the new host.
• Submit locale‑specific sitemaps and watch coverage by language.

9) End‑to‑End Checklists (Copy/Paste)

SEO Lead — Pre‑Cutover

• Export top URLs (analytics + backlinks) and create a redirect map that covers them.
• Validate canonical tags and robots settings for pages that will launch.
• Prepare XML sitemaps for post‑cutover submission.
• Determine whether Change of Address will apply (domain/subdomain migrations).

IT / DNS — Pre‑Cutover

• Confirm console access and backup current DNS records.
• Lower TTLs ahead of the window; plan to raise after stability.
• Prepare the DNS change sheet with records from HubSpot’s connect flow.
• If using Cloudflare, set required records to DNS‑only (proxy off) for validation and email auth.

Web / Content — Pre‑Cutover

• Stage all pages in HubSpot; run functional QA (forms, CTAs, menus, search).
• Validate system pages (404/500) and global elements (header/footer).
• Freeze content changes shortly before the window.

During Cutover

• Publish staged content to live domains.
• Apply DNS changes in the provider.
• Validate SSL, 200/301 behavior, and core user flows (navigation → forms → thank‑you).
• Import redirect CSV; enable pattern redirects.

Post‑Cutover (Day 0–7)

• Submit sitemaps; if applicable, file Change of Address.
• Watch 404s, chains/loops, and canonicity.
• Confirm conversions, analytics, and marketing integrations.
• Monitor email deliverability (if configured) and DMARC reports.

10) Example Scenario: Putting It All Together

Background: You’re moving www.brand.com to HubSpot. The blog lived at /blog/* and will become /insights/*. You also have a legacy host info.brand.com that should redirect to the main site. PDFs under /downloads/*.pdf were reorganized into /assets/:splat.

Decisions:

• www.brand.com → Primary (Website/Pages).
• brand.com (apex) → Redirect to https://www.brand.com/.
• info.brand.com → Redirect domain to https://www.brand.com/.
• Blog moves: /blog/* → /insights/:splat.
• PDFs: map critical files one‑to‑one; pattern‑redirect the rest to the new /assets structure.

Redirects:

Standard mappings for individual high‑value assets:

Original URL,Redirect to URL,Redirect type,Ignore trailing slash,Match query string
/downloads/guide-v1.pdf,/assets/guide-v2.pdf,301,false,false
/downloads/checklist.pdf,/assets/checklist.pdf,301,false,false

Pattern rules for sections:

Original URL,Redirect to URL,Redirect type,Ignore trailing slash,Match query string
/blog/*,/insights/:splat,301,false,false
/resources/*,/library/:splat,301,false,false

Validation matrix:

Post‑cutover: Submit sitemaps, start watchlists, and annotate the cutover in your analytics. Collapse any temporary chains you created during the first pass of redirect mapping.

11) Rollback Plan

• Keep a saved copy of the original DNS zone. If something critical fails and you cannot remediate quickly, reapply the old records. Because you lowered TTLs, reversion should also propagate quickly.
• Disable or remove redirects that conflict with the rollback pathway.
• Document the root cause and set a new window with fixes ready (e.g., an incorrect CNAME, a missing verification, or a staging page not published).

12) Frequently Asked Questions

Do we need Google’s “Change of Address” if we’re only replatforming (same host/path)?
Generally no. That tool applies to moves across domains or subdomains. For a simple replatform under the same host, rely on redirects, sitemaps, and crawl parity.

Can we host the website directly at the apex (brand.com) in HubSpot?
It can be done depending on the DNS provider’s features (ALIAS/ANAME/flattening), but it’s more complex. Many teams choose www as Primary and redirect the apex for simplicity and resilience.

How long does SSL take to provision?
Automatic provisioning is typically quick once the domain is verified and connected. Build cushion into your window to avoid visitor impact if it takes longer than expected.

Can we bulk import redirects?
Yes. Prepare a CSV; it’s the fastest method for large sets. Use pattern rules for entire sections and keep the final topology clean with single‑hop redirects.

What about email deliverability after setting up DKIM/SPF/DMARC?
Start with a permissive DMARC policy (p=none) to collect reports. Once alignment is clean and bounce/spam metrics are healthy, consider tightening to quarantine and then reject.

We have legacy microsites. Should we connect them as Secondary or Redirect domains?
If they will host content, use Secondary. If they’re being retired and should only redirect, connect as Redirect and apply the correct 301s.

13) Quick Reference Links (Add to Your Runbook)

• HubSpot → Domains & URLs (connect domains, roles, redirects)
• HubSpot → Content Staging (stage pages, then publish in bulk)
• HubSpot → Email Sending (DKIM/SPF/DMARC for marketing email)
• Google → Search Console (site verification, sitemaps, Change of Address)
• Your DNS provider’s docs → record management, TTLs, CNAME/A/ALIAS/flattening

These links vary by portal/account and provider; add the exact URLs relevant to your environment. Keep screenshots of the HubSpot connect flow and your DNS provider UI inside the project brief for IT clarity.

14) Final Notes for Clients & IT Teams

• No surprises: circulate the one‑page brief and confirm the exact change window.
• TTL hygiene: lower, cutover, validate, then raise.
• One hop: collapse redirect chains and fix loops fast.
• Measure: baseline key metrics, annotate the launch, watch for regressions.
• Ownership: ensure long‑term access to DNS, HubSpot, and Search Console is held by the client organization.

With deliberate pre‑work and tight coordination, HubSpot’s domain connection, automatic SSL, redirects, and staging tools make DNS migrations boring—in the best possible way. The few things that go wrong most often are missing DNS access, unclear domain roles, or forgotten redirects. Plan for those, and the rest is execution.