An SEO-Safe Website Migration Checklist
A practical checklist for preserving organic traffic during a website migration, from URL mapping and redirects to launch-day checks and monitoring.
A redesign launches on Friday. The new site looks right, forms work, and the team has tested the main user journeys. By Monday, organic traffic is dropping. Product pages return 404s, old URLs redirect to the homepage, and search engines are still showing pages that no longer exist. The problem is rarely that a migration changed the design. It is that the team treated URLs, metadata, and crawlability as launch details instead of parts of the migration.
An SEO-safe migration is not a promise that rankings will never fluctuate. It is a controlled transfer of the signals search engines use to understand and find your pages. That requires knowing what exists today, deciding what should exist after launch, and checking that each important old page has a useful destination.
Start with an inventory, not a redirect spreadsheet
Before changing the site, build a baseline from several sources: a crawl of the current site, the XML sitemap, analytics landing-page data, and Google Search Console. No single source is complete. A sitemap may omit valuable pages; analytics may miss pages with low traffic but strong links; and a crawl can only find URLs it can reach.
Record the pages that matter and the signals they carry: status code, indexability, canonical URL, title, organic entrances, conversions, and known backlinks where available. This gives the team a reference for decisions and makes it possible to distinguish an intentional removal from an accidental omission.
- Include product, category, editorial, and support pages—not only the top-level navigation.
- Check URL variants such as trailing slashes, uppercase paths, parameters, and old campaign URLs.
- Flag pages with traffic, conversions, external links, or a role in a critical user journey.
- Keep the source data and date of the baseline so post-launch comparisons are meaningful.
Map pages by intent, not by convenience
For every important old URL, choose one of three outcomes: retain it, redirect it to a genuinely equivalent page, or return a deliberate 404 or 410 if the content is permanently gone and has no suitable replacement. A redirect should preserve user intent. Sending many unrelated URLs to the homepage may appear to avoid errors, but it gives visitors a poor destination and does not transfer the meaning of the original pages.
| Old page | Preferred outcome | Avoid |
|---|---|---|
| Product page with the same offer | One-to-one 301 redirect or unchanged URL | Redirecting to the homepage |
| Renamed category with equivalent content | 301 redirect to the new category | Redirecting to a broad, unrelated category |
| Retired article with no replacement | Return 404 or 410 and remove from sitemap | Redirecting to the nearest popular article |
| Tracking-parameter URL | Keep parameters out of canonical URLs where appropriate | Creating a separate redirect for every parameter combination |
Treat the redirect map as a reviewed artifact, not a pile of ad hoc rules. Check for chains, loops, conflicting rules, and destinations that themselves redirect. Each important source should resolve in one hop to a final page returning 200. If the URL structure changes substantially, this map can become a significant migration workstream. The cost factors in a legacy migration estimate are useful context when scoping that work.
Keep canonical, internal, and sitemap signals aligned
A redirect is only one signal. On the new site, canonical tags should point to the preferred, indexable version of each page. Internal links should use the destination URLs directly rather than relying on redirects. The XML sitemap should contain only canonical URLs that return 200 and are intended to be indexed. These signals should agree: a page should not redirect while also appearing in the sitemap, or point its canonical tag at an unrelated URL.
Preserve page-level elements that describe content and intent: titles, headings, structured data, and useful body copy. A redesign may change the wording or layout, but removing a page's subject, its links to related content, or its structured data can change how search engines interpret it. This is especially important for product and category templates, where a single implementation change may affect many URLs.
Test the release candidate before launch
A staging site should be protected from indexing, but that protection must be removed at launch. Conversely, production must not inherit a staging noindex directive or robots.txt block. Test the actual release candidate—not a separate approximation—because rendering, routing, and metadata can differ between environments.
- Crawl the staging site and check status codes, canonicals, titles, internal links, and indexability.
- Test every high-value URL in the redirect map, plus a sample from each template and URL pattern.
- Check robots.txt, meta robots directives, and HTTP headers for accidental indexing blocks.
- Verify the rendered page, not just the initial HTML response, for important content and metadata.
- Confirm that the production sitemap contains the new canonical URLs and is accessible after launch.
For larger sites, make the redirect map testable in automation. A small script can request each source URL, follow redirects, and flag unexpected status codes, chains, or destinations. It does not replace a crawl or a review of page relevance, but it catches mechanical mistakes before release.
Monitor the migration as a release
Keep the old URL inventory and redirect map available after launch. In the first days, check server logs and crawls for spikes in 404s, unexpected redirect chains, and blocked resources. In Search Console, monitor indexing, crawl errors, and the performance of important page groups. Compare trends with the pre-launch baseline, accounting for normal seasonality and changes in demand.
Do not react to a single day's ranking movement by changing redirects at random. First identify whether the issue is technical or content-related: are important pages crawlable, do they return the expected status, do canonical signals agree, and do redirects reach relevant destinations? Then investigate page groups and templates. A problem affecting every page on one template is more likely to have a shared cause than dozens of unrelated page-level causes.
A reliable migration plan treats SEO as part of release engineering: baseline, mapping, implementation, automated checks, and post-launch monitoring. For wider SEO context, see what SEO involves and the AEO/GEO playbook. Site Analyzer can also help check your own site’s technical and search readiness.
When a migration touches an aging frontend, routing layer, or multiple complex templates, the work may need to be coordinated with broader modernization rather than bolted on at launch. WebMriya supports that work through legacy modernization, with the goal of making the new platform easier to maintain without losing sight of the pages and signals that already matter.
Frequently asked questions
Will a website migration always cause a temporary ranking drop?
Not necessarily, though search engines may need time to recrawl changed URLs. A careful migration reduces avoidable problems, but cannot guarantee unchanged rankings because content, competition, and other signals can also change.
Should every removed URL redirect to the homepage?
No. Redirect to a relevant replacement when one exists. If there is no suitable destination, return a deliberate 404 or 410 rather than sending visitors to an unrelated page.
How long should we keep redirects after a migration?
Keep important redirects in place for the long term, especially where old URLs have links or may still be bookmarked. Removing them can break visitor journeys and discard useful signals.