Website Migration Without Losing Organic Traffic: A 2026 Checklist for Redirects, Canonicals, Sitemaps and Log Analysis

Site migrations are one of the fastest ways to lose years of organic growth if the technical details are handled casually. In 2026, Google’s crawling and indexing systems are faster than they used to be, but they are also less forgiving when signals conflict. This guide is written as a practical checklist you can apply during a domain move, URL restructure, CMS change, HTTPS switch, or a major redesign.

Pre-migration planning: build a clean URL map and protect indexing signals

Before touching the live site, create a full inventory of your current URLs. Use a crawler (for example Screaming Frog, Sitebulb, or your own scripts) and export every indexable page, then enrich it with data from Google Search Console: impressions, clicks, top queries, and which pages drive revenue or leads. This step lets you prioritise what cannot break and prevents “invisible” pages from being forgotten during the move.

Next, build a URL mapping document that includes every old URL and the exact destination on the new site. In 2026, “we’ll redirect the rest to the homepage” is still one of the most damaging shortcuts you can take. Each redirect should point to the closest equivalent page by intent and topic, not simply a category page. If content is being removed, decide whether a 410 (gone) is appropriate, or whether you should replace it with a stronger evergreen page and redirect there.

Finally, define your technical rules in advance: preferred trailing slash (or not), lowercase enforcement, parameter handling, pagination strategy, and canonical patterns. Agree these rules with developers and stakeholders before launch. Many traffic drops come from inconsistent decisions made under deadline pressure, such as changing URL structure and internal linking logic at the same time.

Redirect rules: what to implement, what to avoid, and how to test at scale

For most migrations, use server-side 301 redirects for permanent changes. In 2026, Google still treats 301 as the standard for consolidating signals from an old URL to a new one. Avoid redirect chains (A → B → C) because they waste crawl budget and increase the chance that signals won’t consolidate cleanly. Your ideal setup is one hop: old URL → final new URL.

Do not rely on JavaScript redirects, meta refresh, or “soft” routing tricks unless there is a strong technical reason. They can work, but they introduce risk and reduce transparency when you’re debugging issues. Also be strict about redirect loops. One loop can block crawling entirely for parts of the site and may cause indexing to stall for weeks.

Testing should be automatic and exhaustive. Before launch, run a bulk redirect test against your full URL list and verify three things: the status code is correct (301), the final URL is exactly what you mapped, and the destination returns 200 and is indexable. After launch, recrawl the old site URL list to confirm the redirects are live and consistent. This is the fastest way to detect missing rules and accidental 302s.

Canonicals and internal linking: ensure one clear version of every page

Canonical tags matter most when you have multiple accessible versions of the same content. During migration, duplicates often appear unintentionally: old URLs might still be accessible, parameters may create near-copies, and staging environments sometimes leak into the index. In 2026, Google is better at choosing canonicals, but it still relies on your signals. If you send mixed messages, you create volatility.

Each indexable page should self-canonical to its own final URL. Avoid canonicalising all pages to a category or homepage unless the page truly shouldn’t exist as its own entity. A canonical tag is a hint, not a directive, so it should be aligned with internal links, sitemaps, hreflang (if applicable), and redirects. When these signals disagree, Google may pick an unexpected canonical and rankings can move unpredictably.

Internal linking is the “silent” part of migration that many teams underestimate. Update internal links so they point directly to the new URLs and do not rely on redirects. Redirects are for users and bots arriving from the outside world; internal linking is your opportunity to show Google the site’s new structure cleanly. After migration, run a crawl to identify internal 3xx links, fix them, and then re-crawl until the internal network is direct.

Canonical checklist for migrations: the exact items that prevent duplicate indexing

Start by verifying that the canonical tag is present on every indexable page and uses the correct absolute URL (including the right protocol and preferred hostname). If you moved from http to https, confirm that canonicals are https and that mixed versions are not being produced by templates or legacy components.

Then check that parameter URLs and sorting URLs are handled consistently. If parameters create duplicates, choose whether to canonicalise them to the clean version or block them using robots rules where appropriate. Be careful: blocking a URL in robots.txt does not remove it from the index if it is still linked externally, and you also prevent Google from seeing the canonical tag. This is why canonicalisation plus correct internal linking is often safer than blanket blocking.

Finally, confirm that canonical signals match sitemap URLs. If your sitemap contains URLs that canonicalise elsewhere, you are effectively asking Google to crawl one thing while hinting that something else is preferred. This can slow down consolidation and keep the wrong pages in the index longer than expected.

XML sitemap, robots rules and log files: control crawling and verify what Google actually does

Once the new site is live, the XML sitemap becomes your most direct way to show Google what should be crawled and indexed. In 2026, sitemaps still matter, especially after large-scale changes, because they help Google discover new URLs faster and re-evaluate old ones. Your sitemap should contain only canonical, indexable URLs returning 200, and it should reflect the new structure immediately after launch.

Robots rules should be used with precision, not fear. During migration, it’s common to block staging environments or certain URL patterns. That’s correct, but the live site should not accidentally inherit “Disallow: /” rules or over-aggressive blocks. Also confirm that your new site does not block CSS, JS, and critical assets that Google needs for rendering. Rendering matters because it affects how Google understands page content and layout.

Log analysis is what separates a confident migration from guesswork. Crawls show what your tools can see; logs show what bots actually request. After launch, analyse server logs to confirm Googlebot is spending time on your most important URLs, that old URLs are being crawled and redirected correctly, and that crawl budget isn’t being wasted on infinite parameter spaces or internal 404s. In practice, logs often reveal problems that don’t appear in audits until the ranking impact has already happened.

Post-launch monitoring: the metrics and log patterns that catch problems early

In Google Search Console, monitor indexing reports and the Pages section for spikes in “Not indexed” statuses that weren’t expected. A sudden rise in “Duplicate, Google chose different canonical” often means your canonical signals conflict. A rise in “Soft 404” can indicate thin replacements, wrong redirects, or blocked resources that prevent proper rendering.

From logs, watch for repeated crawling of redirected URLs. Some re-crawling is normal after a migration, but if Googlebot keeps hammering the same old URLs weeks later, it can mean that internal links, sitemaps, or external references still point heavily to old structures. You want to see crawl focus gradually move to the new URLs, with old URLs declining over time.

Finally, validate outcomes with ranking and traffic segment checks. Compare organic traffic on top landing pages before and after launch, not only at site level. A site can look “stable” overall while high-value sections collapse. Pair analytics data with Search Console query trends so you can tell whether changes are caused by indexation, relevance, or a technical block. When a migration is done cleanly, recovery and consolidation usually happen faster, and you’ll spend far less time firefighting.