logo
A safe SEO migration starts with a complete URL map, not with launch day fixes. Before a new site goes live, every valuable old URL needs a planned destination, every canonical needs a clear target, every sitemap needs clean indexable URLs, and every indexing rule needs to be checked in staging and again after release.
TLDR: Treat migration as a controlled SEO audit with a launch deadline, not as a design or CMS task. For example, a retailer moving 12,400 URLs should map the top 95% of organic traffic pages first, then test redirects, canonicals, sitemaps, and robots rules before DNS changes. In one common case, fixing 312 redirect errors before launch can protect thousands of monthly visits that would otherwise hit 404 pages. The goal is simple: keep search engines confident that the same content still exists, just at a new address.
Start With a Migration Risk Inventory
Do not begin with redirects. Begin with risk. Export every URL that currently matters from analytics, Google Search Console, crawling tools, backlink data, paid landing pages, XML sitemaps, and server logs. Each source catches something different, which is annoying but necessary.
Your inventory should include:
- Current URL
- New URL
- HTTP status code
- Organic sessions from the last 12 months
- Conversions or revenue
- Backlinks
- Indexing status
- Canonical target
- Content type, such as product, article, category, or PDF
Prioritize URLs by business value. A page with 18,000 organic visits and 240 conversions deserves more review than an archived tag page with no traffic. This sounds obvious. It still gets skipped far too often.
Build Redirects Around Intent, Not Convenience
Use 301 redirects for permanent moves. Map each old URL to the closest matching new URL. A category page should not redirect to the home page unless there is no better option. Search engines treat poor matches as soft errors, and users do too.
A good redirect plan should follow these rules:
- One hop only: Old URL to final URL. Avoid chains such as A to B to C.
- No loops: Test rules so URLs do not redirect back to themselves.
- No bulk home page redirects: These waste relevance and frustrate users.
- Preserve parameters only when useful: Tracking parameters can often be dropped. Functional filters may need rules.
- Keep case and trailing slash logic consistent: Mixed rules create avoidable crawl waste.
Honestly, it feels like most migration trouble comes from “temporary” redirect logic that nobody owns. Assign one person to approve the redirect file. Then freeze it before launch, except for documented fixes.
Check Canonicals Before They Break Indexing
Canonical tags tell search engines which URL should be treated as the preferred version. During a migration, bad canonicals can undo good redirects. A new page that canonicals to an old URL sends a messy signal. A paginated page that canonicals to page one may hide useful content. A staging canonical that slips into production can be painful.
Review these canonical rules before launch:
- Every indexable page should point to its final production URL.
- Canonical URLs should return 200 OK, not 3xx, 4xx, or 5xx.
- Canonicals should use the correct protocol, host, and path.
- Duplicate pages should point to the preferred version, not to a random similar URL.
- Pages blocked by robots.txt should not be relied on as canonical targets.
It drives me crazy that some CMS previews add temporary canonical tags and leave them there. That small mistake can cost days of cleanup after launch. Crawl staging with authentication access if needed. Then inspect the rendered HTML, not just the raw source, because JavaScript can change signals after load.
Create Clean XML Sitemaps
XML sitemaps are not a fix for weak site architecture, but they are very useful during migration. They help search engines find the new URL set quickly. They also give your team a clean list to validate.
Your launch sitemap should include only canonical, indexable, production URLs that return 200 OK. Do not include redirected URLs. Do not include blocked URLs. Do not include thin internal search pages unless they are meant to rank.
For larger sites, split sitemaps by type. Use separate files for products, categories, articles, locations, videos, or images. This makes post launch debugging faster. If the product sitemap has a 31% indexing gap while articles are fine, you know where to look first.
Audit Robots, Noindex, and Access Rules
Indexing checks should happen before launch, not after traffic drops. Review robots.txt, meta robots tags, HTTP headers, password rules, CDN settings, and firewall behavior. Staging sites often block crawlers, which is correct. The problem starts when those blocks move to production.
Check for these issues:
Disallow: /pushed live by mistakenoindextags on templates that should rank- Canonical pages blocked in robots.txt
- Important resources blocked, such as CSS, JavaScript, or images
- Geo or bot protection blocking search engine crawlers
- Incorrect hreflang targets on international sites
Use a crawl tool that can compare staging and production. Expect to waste time on login walls, IP allowlists, and CDN caching. Still, that wasted hour is better than finding out a week later that Google could not reach your main category pages.
Run a Pre Launch Crawl and Compare Signals
Before launch, crawl the new site as if you were a search engine. Then compare it with the old site inventory. The comparison should answer four questions.
- Did every important old URL get a valid destination?
- Do the new URLs return 200 status codes?
- Do canonicals point to the correct final URLs?
- Are indexable pages present in the XML sitemap?
Make a short launch blocker list. Not every issue should stop release. A missing redirect for an old press release may be acceptable. A noindex tag on all product templates is not. Classify issues as blocker, high, medium, or low.
Prepare the Launch Day Checklist
On launch day, keep checks simple and fast. Long review documents are useless when the site is live and people are waiting. Use a checklist that covers the first two hours.
- Confirm DNS and SSL are working.
- Test key redirects manually and with a crawler.
- Crawl a sample of high value old URLs.
- Check robots.txt on production.
- Confirm meta robots tags on main templates.
- Validate XML sitemap URLs.
- Submit sitemaps in Google Search Console and Bing Webmaster Tools.
- Inspect several pages with URL inspection tools.
- Check analytics tracking and conversion events.
- Monitor server errors and crawl spikes.
Monitor Indexing After Launch
The first days after launch matter most. Track traffic, rankings, crawl errors, indexing, and server logs daily for at least two weeks. Large sites may need four to six weeks of close monitoring.
Watch these metrics:
- Organic sessions by page type
- 404 and 5xx errors
- Redirect hits by old URL
- Indexed page count
- Submitted versus indexed sitemap URLs
- Top query and top page changes
- Crawl frequency in server logs
Some volatility is normal. A short ranking dip does not always mean failure. But sharp patterns need quick action. If organic traffic drops 35% only on category pages, inspect category templates first. If indexed URLs fall while crawled URLs rise, check canonicals, noindex tags, and duplicate paths.
Assign Ownership and Keep Records
A migration is not finished at launch. Keep the redirect map, crawl exports, sitemap versions, indexing notes, and approval history. This record helps when someone asks why an old URL points to a specific page three months later.
Assign clear owners for redirects, template SEO, sitemap generation, analytics, and post launch reporting. Serious migrations fail less often when accountability is boring and explicit. The process is not glamorous. It protects revenue, rankings, and trust.
The best SEO migration strategy is simple: map everything valuable, test every signal, launch with a short checklist, and monitor until search engines settle on the new URLs. If that sounds repetitive, good. Repetition is what keeps organic traffic from becoming collateral damage.
