Contents show

Introduction

Site migrations—changing domains, moving to a new CMS, restructuring URLs, or switching to HTTPS—are pivotal moments for organic visibility. Handled well, they modernize your platform, fix Technical debt, improve Core Web Vitals, and align Architecture with business goals. Handled poorly, they disrupt rankings, lose backlinks, and break discovery paths for search engines and users. The objective is simple: preserve and grow organic traffic by maintaining continuity of signals while the underlying stack changes.

Prerequisites / Before You Start

Define the scope and type of Migration

Domain change (example.com → example.co)
Protocol change (HTTP → HTTPS)
Subdomain to subfolder (blog.example.com → example.com/blog)
URL restructuring (/category/product-123 → /products/123)
CMS/platform change (WordPress → headless + Next.js)
Hosting/CDN or Infrastructure change

Clarify which apply, because each influences redirect strategy, canonicalization, and Search Console Configuration.

Backups and rollback plan

Full database backup and file system snapshot.
Export of all CMS content, media, and configurations.
Versioned repository branch to revert to pre-Migration state.
CDN and DNS rollback options with documented TTLs.
Automated recovery runbook with owners and time estimates.

Inventories and baselines

Crawl the entire site to capture:
- All indexable URLs, status codes, canonical URLs, titles, meta descriptions, directives (noindex/nofollow), structured data, pagination, hreflang.
- Orphan pages and parameterized URLs.
Export Search Console data (Coverage, Performance, Links) for 90–180 days.
Export GA4 organic landing pages, conversions, revenue.
Download backlink lists (Search Console, Ahrefs/Majestic/SEMrush).
Take baseline Core Web Vitals (LCP, CLS, INP), Lighthouse scores, and server response times.

Technical prerequisites and dependencies

Confirm platform versions and dependencies:
- CMS version, plugins/modules, theme compatibility.
- Runtime/build versions (Node.js, Python, PHP), package managers.
- Server stack (Nginx/Apache configs), HTTP/2 or HTTP/3 support.
- CDN feature parity (edge redirects, headers, caching rules).
SSL/TLS certificates ready; consider HSTS rollout plan.
Access to:
- DNS provider and TTL controls.
- Hosting/CDN consoles.
- Google Search Console and GA4 (Editor/Admin).
- Log files (origin and CDN) for crawl analysis.

Stakeholders, timeline, and freeze

Assign owners for SEO, engineering, content, analytics, QA, and Project management.
Publish a migration calendar with blackout periods and a content freeze window.
Agree on Success metrics and acceptable volatility thresholds.

Step-by-Step Migration guide

1) Crawl and classify current URLs

Use a crawler (Screaming Frog, Sitebulb) and Search Console exports to build a canonical URL inventory.
Classify by type: product, category, blog, resource, landing pages, paginated sets, faceted filters, media assets.
Identify thin, duplicate, near-duplicate content and prune or consolidate before the move.

Practical tip: include parameters that generate organic sessions (GA4) and ensure rules exist to handle them post-migration.

2) Build the redirect map (301s)

Create a one-to-one mapping from every old indexable URL to the most relevant new URL.
Use 301 (permanent) redirects for SEO continuity; avoid 302 unless truly temporary.
Eliminate chains and loops; aim for single-hop 301s.

Example redirect rules:

Apache (.htaccess):

RewriteEngine On

Force HTTPS

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Canonical hostname

RewriteCond %{HTTP_HOST} !^example.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Old category to new structure

Redirect 301 /category/product-123 https://example.com/products/123
RedirectMatch 301 ^/category/(.*)$ https://example.com/products/$1

Nginx:

server {
listen 80;
server_name www.oldsite.com oldsite.com;
return 301 https://example.com$request_uri;
}

server {
listen 443 ssl http2;
server_name www.example.com;
return 301 https://example.com$request_uri;
}

location = /category/product-123 { return 301 https://example.com/products/123; }
location ~ ^/category/(.)$ { return 301 https://example.com/products/$1; }

Quick reference table:

Type	Use Case	SEO Impact
301 Permanent Redirect	URL moves permanently	Passes most link equity; preferred for migrations
302 Temporary Redirect	Short-term tests or Maintenance	Signals temporary; may not pass full signals
Meta Refresh/JS Redirect	Avoid for SEO	Unreliable, can cause indexing issues

3) Replicate metadata and content parity

Preserve or improve:
- Title tags, meta descriptions, H1-H6 hierarchy.
- Structured data (Product, Article, FAQ).
- Open Graph/Twitter Cards.
Keep core copy intact to minimize relevance fluctuations.
For consolidations, merge content thoughtfully and retain the strongest signals.

4) Canonicalization and URL strategy

Set one canonical version of each page.
Avoid mixed trailing slashes, uppercase/lowercase variants, or duplicate querystring paths.
Add canonical tags:

Only canonicalize to indexable pages that return 200 and are in sitemaps.

5) Internationalization and hreflang (if applicable)

Maintain language/region pairs with reciprocal tags:

Validate return tags and URL status (no 3xx/4xx for hreflang targets).

6) Structured Data integrity

Re-implement schemas with updated URLs and IDs, ensuring:
- Product availability, price, review markup.
- Article, Breadcrumb, FAQ, HowTo where relevant.
Test with Google’s Rich Results Test and your staging environment.

7) Internal links and Navigation

Update all internal links, breadcrumbs, nav menus, sitemaps, and footers to the new URLs (no reliance on redirects).
Normalize:
- Absolute over relative links for clarity in rendering pipelines.
- Consistent trailing slash conventions.
Fix legacy “nofollow” on internal links if not needed.

8) Robots.txt and sitemaps

Deploy a coherent robots.txt that allows key sections to be crawled:

robots.txt:

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /search?
Allow: /wp-content/uploads/
Sitemap: https://example.com/sitemap_index.xml

Generate sitemap indexes segmented by content type and ensure every URL is 200, canonical, and indexable:

Sitemap index example:

https://example.com/sitemaps/sitemap_products.xml

https://example.com/sitemaps/sitemap_categories.xml

https://example.com/sitemaps/sitemap_blog.xml

9) Analytics, tags, and Search Console alignment

Preserve GA4 continuity:
- Keep the same GA4 property and data streams where feasible.
- Verify gtag/GTManager Deployment on all templates.
Track 404s and redirect hits (via Server logs or GTM custom events).
Search Console:
- Verify the new property (Domain property is recommended).
- For domain moves, use the “Change of address” tool.
- Submit new sitemaps and keep old sitemaps temporarily to assist discovery.
Migrate conversion tracking and ecommerce schemas unchanged.

10) Performance, rendering, and Core Web Vitals

Test server TTFB, CDN caching, compression (Gzip/Brotli), and image formats (AVIF/WebP).
Validate JavaScript rendering:
- Ensure critical content is server-rendered or hydrated quickly.
- Avoid rendering blockers and late-injected canonical tags.
Monitor CWV: target LCP < 2.5s, CLS < 0.1, INP < 200ms on key templates.

11) Backlink preservation and outreach

Identify top-linked pages and ensure precise 301s.
Contact key partners to update links to the new URLs.
Reclaim links for pages that were consolidated or removed; propose closest replacements.

12) Staging tests and soft launch

Block staging via Authentication or IP allowlists (not robots.txt only).
Run end-to-end crawls on staging and validate:
- Status codes, canonicals, hreflang, structured data, internal linking, sitemaps.
Conduct a soft launch for a small segment (e.g., 5–10% traffic) if Infrastructure supports it.

13) DNS, CDN, and go-live steps

Lower DNS TTL to 300 seconds at least 24–48 hours prior.
Pre-provision SSL and edge rules (redirects, headers) on the CDN.
Freeze non-critical deployments 48 hours before and after go-live.
Deploy redirects at edge and origin simultaneously to avoid Race conditions.

14) Monitor and iterate

From hour one, watch logs for spikes in 404/500, crawl rates, and 301 volumes.
Track ranking and traffic for high-value pages; adjust redirect mapping where mismatches occur.
Fix issues quickly and re-submit affected URLs in Search Console.

Risks, Common Issues, and How to Avoid Them

Redirect chains and loops
- Risk: Link equity dilution, slower crawling.
- Avoid: Enforce single-hop 301s; test with sitewide crawls and curl.
Wrong redirect types (302/307 instead of 301)
- Risk: Temporary signals; inconsistent indexing.
- Avoid: Audit response headers; lock configs via Code review.
Mixed content after HTTPS
- Risk: Browser warnings, indexing issues.
- Avoid: Rewrite asset URLs; use Content Security Policy reports.
Robots.txt blocking or noindex shipped live
- Risk: De-indexation.
- Avoid: Use Deployment checklists; require SEO QA sign-off.
Canonical tags pointing to non-200 or old domain
- Risk: Signal loss, de-duplication errors.
- Avoid: Automated tests for canonical status and host.
Hreflang with missing return tags or redirects
- Risk: Wrong locale ranking, duplicate content.
- Avoid: Validate reciprocity; ensure final 200 targets.
Loss of tracking/GA4 or broken events
- Risk: Blind spots in analysis.
- Avoid: Tag validation via Tag Assistant and server-side events.
Parameter handling and duplicate paths
- Risk: Wasted crawl budget.
- Avoid: Normalize parameters, set canonical rules, Search Console parameter hints (if applicable).
Pagination and faceted Navigation drift
- Risk: Duplicate or orphaned pages.
- Avoid: Robust linking rules, canonical to view-all only when performant, and noindex for thin combinations.
CDN cache and DNS TTL mismanagement
- Risk: Users/Google see inconsistent states.
- Avoid: Pre-warm caches; controlled TTL; staged cutover.
JavaScript rendering discrepancies
- Risk: Missing content for Googlebot.
- Avoid: Server-side render critical content; test with Mobile-Friendly and URL Inspection tools.
HSTS and preload timing
- Risk: Lock-in to HTTPS before redirects stable.
- Avoid: Enable HSTS after confirming redirect correctness.

Post-Migration Checklist / Validation Steps

0–24 hours

Verify:
- Home and critical templates return 200.
- 301s are functioning (no chains, correct destinations).
- Canonical tags point to new URLs.
- robots.txt and sitemaps accessible and correct.
- GA4 hits, conversions, and revenue firing.
Use curl for spot checks:

curl -I http://oldsite.com/category/product-123
curl -I https://example.com/products/123

Expect: 301 then 200 with correct canonical.

Log monitoring:
- 404 rate < 1–2% of total requests.
- No 500 spikes.

Days 2–7

Crawl the site and compare counts to Pre-migration inventory:
- Indexable URLs within ±5–10%.
- Orphans minimized; unexpected 4xx captured.
Search Console:
- Submit sitemaps; check Coverage and Page indexing.
- Fetch/Render important pages (URL Inspection) and request indexing where needed.
Rankings and traffic:
- Watch top 100 landing pages for CTR, positions, and impressions.
- Adjust redirect targets if mismatched intent is suspected.
Core Web Vitals and performance:
- Validate real-user metrics in CrUX/Field data dashboards.

Weeks 2–6

Backlink reclamation:
- Outreach for top referring domains to update links.
Content improvements:
- Opportunistic metadata tuning based on CTR drops.
Technical hardening:
- Remove temporary old sitemaps after stable indexing.
- Consider enabling HSTS if HTTPS setup is stable.
Crawl budget review:
- Analyze server and CDN logs to confirm Googlebot crawl patterns are healthy.

Sample KPI guardrails:

Metric	Target Range
Share of 200 responses	> 95%
Share of 301 responses	< 30% after week 2 (declining trend)
404 rate	< 1–2%
Average redirect hops	1.0
Core Web Vitals (good URLs)	> 75% in CrUX
Organic sessions	Within −10% to +10% at 2–4 weeks (varies by scale/type)

Useful command snippets and tools

Verify headers and redirects:

curl -I https://oldsite.com/path
curl -I -L https://oldsite.com/path

Find redirect chains from a list:

xargs -n1 curl -s -o /dev/null -w “%{url_effective} %{http_code}\n” < urls.txt

Grep Server logs for 404s:

grep ‘” 404 ‘ access.log | awk ‘{print $7}’ | sort | uniq -c | sort -nr | head -50

Lighthouse CI (basic):

lhci autorun –collect.settings.preset=desktop –upload.target=filesystem

Render testing with Googlebot UA:

curl -I -A “Mozilla/5.0 (Linux; Android 9; Pixel 3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” https://example.com/

Examples and templates

Redirect mapping CSV (columns)

old_url,new_url,status_code,priority,template_type,notes
https://oldsite.com/category/product-123,https://example.com/products/123,301,high,product,Exact match
https://oldsite.com/blog/seo-migration,https://example.com/resources/seo-migration,301,medium,article,Consolidated

Tracking matrix (what to verify on each template)

Exists and correct:
- Title/H1
- Meta description
- Canonical
- robots meta (no unintended noindex)
- Structured data type and validity
- Hreflang (if applicable)
- Internal links updated (no old URLs)
- Analytics/consent tags

Additional Best practices

Crawl-budget friendly Architecture

Limit infinite spaces: calendars, session IDs, filters creating countless thin pages.
Use robots rules and parameter handling to restrict low-value combinations.
Surface high-value hubs via internal linking.

Content and UX opportunities post-migration

Refine information architecture to support topic clusters.
Leverage breadcrumb schema and improved navigational links.
Expand FAQs and HowTo content with structured data for rich results.

Governance and documentation

Keep a change log of redirects, robots updates, canonical rules.
Tag releases with SEO notes for quick rollback correlation.
Schedule quarterly audits to remove legacy redirects and refresh sitemaps.

Frequently Asked Questions

How long does it take for SEO signals to fully transfer after a 301 redirect?

Most signals begin transferring quickly, but stabilization can take 2–6 weeks, depending on crawl frequency, site size, and the nature of the migration. Domain changes often take longer than simple HTTPS moves. Maintain sitemaps, monitor logs, and avoid making frequent structural changes during this period.

Should I keep the old domain active after a domain change?

Yes. Keep the old domain with 301s in place for at least 12–18 months. This preserves link equity from legacy backlinks, catches straggler traffic, and helps search engines consolidate signals. Maintain SSL on the old domain to ensure secure redirects.

Can I combine a redesign, CMS change, and URL restructuring at once?

You can, but risk increases. If possible, separate changes into stages (e.g., infrastructure + CMS first with URL parity, then redesign, then restructuring). If you must combine, invest more in mapping, QA, and rollout monitoring to control variable interactions.

Is it okay to use 302 redirects during a migration?

Use 301s for permanent moves to transfer ranking signals. 302s indicate temporary changes and can delay or prevent signal consolidation. Reserve 302s for short-lived tests or Maintenance windows only.

Do I need to update backlinks if I already have 301 redirects?

301s handle the signal transfer, but updating important backlinks is still beneficial. It shortens redirect chains, can improve crawl Efficiency, and sometimes boosts referral traffic and link equity by pointing directly to the canonical destination.