Website migration without losing rankings

Migration cannot guarantee that every ranking will remain, but it can limit risk: redirect an old URL that has a genuine equivalent with one permanent redirect to that equivalent; leave a removed URL with no replacement as 404 or 410. Sending expired content wholesale to the homepage or a loosely related page may be treated as a soft 404.

Google recommends preparing an old-to-new map, redirecting directly to the destination, avoiding irrelevant redirects, and monitoring both URL sets. Permanent redirects do not cause PageRank loss, though chains add delay and complexity. Source: Google Search Central — site move with URL changes.

We used this approach on our own site: 81 old URLs, four blog prefixes to consolidate, a technology change, and a new canonical URL. This is the sequence we use.

Step 1. Inventory URLs before anything else

Combine the old sitemap, CMS export, analytics, Search Console, server logs, external-link tools, and known campaign landing pages. Record each address, its content type, traffic and link value where known, the intended destination, and a decision owner. Migration plans fail when a URL exists only in one forgotten system.

Step 2. Give every URL a verdict

For each old URL choose one clear outcome:

• A direct equivalent exists — use a permanent redirect to that exact new URL.
• A materially relevant successor exists — redirect only if it genuinely serves the same user intent.
• Content is deliberately gone and has no successor — return 404 or 410.
• The old page remains — keep it reachable and canonicalise correctly.

Do not use redirects to hide an unfinished migration. A user should land on the answer they expected, not on a generic page.

Step 3. Build a redirect map without chains

Map old URL → final URL directly. Avoid old → interim → final chains, mixed protocols, and loops. Test query parameters, trailing slashes, locale paths, archived articles, assets that have inbound links, and variants generated by prior systems. Version the map and review it as code or configuration rather than an untracked spreadsheet.

Step 4. Test before launch

Use a staging environment to crawl the old URL list and verify response codes, final destinations, canonical tags, page titles, robots rules, internal links, sitemap entries, structured data, and rendered content. Test authentication and CDN rules too: a correct redirect is useless if the destination is blocked or returns an error.

Step 5. Have these ready on migration day

• DNS and TLS settings, hosting access, backups, and a rollback plan;
• the final redirect map and a way to inspect logs;
• canonical URLs, XML sitemap, robots rules, and analytics/Search Console access;
• owners for content, infrastructure, SEO, and incident response;
• a method for monitoring important pages, forms, payments, and integrations.

Step 6. Order of work on moving day

Deploy the new site, enable redirects, verify critical journeys and a representative URL sample, submit or expose the new sitemap, then monitor response codes, indexing, traffic, conversions, and error logs. Do not change the information architecture, every URL, tracking, and content strategy blindly at the same moment if they can be phased; too many simultaneous changes make diagnosis difficult.

What to expect after migration

Search engines need time to recrawl and process URL changes. Short-term movement can occur even with a good plan. Compare like-for-like periods, watch important pages and queries, fix clear technical errors quickly, and do not respond to ordinary recrawling delay by repeatedly changing redirects or canonicals.

When not to migrate

Do not migrate during a critical seasonal sales window without a compelling reason, when the destination content or redirect map is unfinished, when the team cannot monitor and react after release, or when the real aim is only a visual refresh that could be delivered safely within the existing architecture.

Frequently asked questions

Must URLs with no traffic be redirected?

Assess them individually. Traffic is not the only value: an address may have links, serve a niche query, or be needed by users. If no genuine equivalent exists, a correct 404 or 410 is better than an irrelevant redirect.

How long should redirects remain?

Keep them as long as old URLs can realistically be requested through links, bookmarks, crawlers, or offline material. There is no short universal expiry date; removing a useful redirect merely reintroduces an avoidable broken journey.

Can migration be phased?

Yes. A phased move can reduce risk when source-of-truth, redirects, and canonical rules are clear. Each phase still needs its own inventory, tests, and monitoring.

---

We plan migrations as a technical and content change together, not a switch to throw at production. See website architecture options or contact us.