Site migration: protect the pages that earn traffic

A site migration may change a domain, URL paths, a CMS, or page structure. The launch itself is rarely the whole problem. The risk is breaking the route from a search result or external link to a useful page. This guide gives you a testable process for protecting the pages that already bring visitors or enquiries.

Identify pages with measured value

Before changing URLs, export landing pages from analytics, pages and queries from Google Search Console, the current sitemap, and pages with known external links. Add leads or sales where you can. A low-traffic service page that produces qualified enquiries may matter more than a high-traffic post with no business outcome.

Build one inventory with the complete URL, page type, baseline sessions for a comparable period, organic clicks, known backlinks, conversions, and editorial owner. Mark missing data as unknown. Treating missing data as zero can hide an important page.

Sort URLs into three groups: those that retain the same address, those that move to a clear equivalent, and those whose content is genuinely retired. Make that decision before writing redirect rules.

Map each old URL to a relevant destination

The destination should satisfy the same visitor need. An old product page may map to the current version of that product. A discontinued product does not automatically map to the home page. When there is no close replacement, a real 404 or 410 response can be the appropriate outcome.

Your mapping sheet should include the old URL, proposed new URL, original intent, reason for the mapping, expected HTTP status, test status, owner, and date. Add a column for valuable external links so those journeys are checked first.

Fictional example: a firm moves /services/seo-audit/ to /seo-audit/. The service and its essential information remain, so a permanent redirect makes sense. If it drops /services/local-seo/ and offers nothing similar, redirecting that URL to the audit service would mislead a visitor.

Google recommends creating an old-to-new URL map and redirecting moved pages to their corresponding destinations in its site migration documentation. A redirect alone cannot replace a useful page; the new page must still answer the original need.

Test the new site before launch

On staging, sample every important template: home, service, category, article, product, pagination, and removed pages. Check that indexable pages return 200, canonicals point at the final URLs, and navigation links lead directly there. Test forms, checkout, images, and downloadable files that matter to users.

Test the mapping with real HTTP requests. For each priority old URL, follow the redirect and confirm the final page is a relevant 200. A direct old-to-new redirect is easier to audit than a chain through several intermediate URLs. Check the http, https, www, and non-www variants actually used by the site.

Prepare a sitemap containing the new canonical, indexable URLs. A sitemap helps search engines discover pages, but it does not guarantee indexing. Remove redirected, retired, and noindex URLs from it. Google's sitemap guidance explains its discovery role.

Launch and verify real user journeys

Keep a copy of old redirect rules, the sitemap, and baseline measurements. Publish the final pages, enable redirects, and immediately test the URLs that produced leads or attracted links. Opening the new home page does not test the migration. Request an actual old URL, inspect its HTTP response, and open its destination.

Update internal links to the final addresses so navigation does not rely on redirects. Recheck canonicals, forms, analytics events, and any accidental sitewide robots.txt or noindex block.

Submit the new sitemap in Search Console. Monitor coverage issues, landing pages, and queries. If the domain changed, verify and monitor both old and new properties. Google recommends tracking traffic on both sides of a move. Search visibility may fluctuate while pages are recrawled; a short-term drop alone does not diagnose the cause.

Investigate a traffic drop by URL

Compare equivalent periods and account for seasonality. Group affected pages by failure: HTTP error, irrelevant destination, wrong canonical, thinner content, lost internal link, tracking failure, or changed search demand. Read page and query data together instead of relying on one sitewide traffic figure.

When an external link points to a 404, identify the historical subject first. Find or create a genuinely equivalent page before redirecting. A link to an old discussion forum does not become relevant merely because it lands on the front page of a magazine. That matters especially for acquired domains with a different past use.

Change one cause at a time and record the result. If many pages share one broken template, fix the template and retest a representative sample. A specific fix followed by a repeatable check teaches you more than another broad redesign.

Migration worksheet

Start with pages that already have measured value. A successful move is verified one URL at a time, then checked against search data and actual enquiries.

What to hand over after the move

Give the site owner the final mapping sheet, the date of each rule change, a list of unresolved URLs, and the contacts responsible for content, engineering, and analytics. Keep a small monitoring list for the first weeks: old URLs with backlinks, highest-value landing pages, forms, checkout, and pages that were excluded from the sitemap. That list is much easier to act on than a generic “traffic is down” message.

When a partner links to an old URL that now redirects correctly, you can ask them to update the link to the final address, but the redirect should still remain in place for visitors who use older bookmarks or copies. If the link points to a subject the new site no longer covers, do not invent an unrelated landing page just to capture it. Record the missed opportunity and decide whether a genuinely useful replacement article belongs in the editorial plan.