How to keep your URLs working after a move

A plain host migration, done properly, should not change a single URL. Same domain, same page paths, just a different server behind them — which is exactly why it does not itself affect search rankings or break bookmarks and inbound links. Problems only appear when something changes alongside the hosting: a URL structure that gets "cleaned up" during the move, a folder that lands in a slightly different place, or a platform change that generates addresses differently than the old one did.

Why a changed URL matters more than it seems

Every URL that has ever been shared, bookmarked, linked to from another website, or indexed by a search engine is a promise that something exists at that address. Break the promise without a redirect and you get, in order: a visitor hitting a 404, a search engine eventually noticing and dropping that page from its results, and any ranking history built up at that address effectively starting from zero somewhere else.

Checking what actually changed

Before assuming URLs are unchanged, verify it. Compare a sample of pages on the old site against their equivalent on the new one:

• Does the page path match exactly — same folders, same trailing slash behaviour, same file extension if any?
• Are dynamic pages, such as blog posts or product pages, generating addresses the same way on both platforms?
• Has www versus non-www stayed consistent? Search engines treat these as different addresses unless one properly redirects to the other.
• Has the site moved from http to https, or vice versa? This is technically a different URL for every single page, even though the path looks the same.

Setting up redirects for anything that did change

For every URL that is genuinely different on the new site, add a 301 (permanent) redirect from the old address to the new one. A 301 tells both browsers and search engines the move is permanent, which is what allows ranking signal to transfer to the new address rather than being lost.

Redirect 301 /old-page-path /new-page-path

A rule like this in .htaccess handles one page. Where old and new addresses follow a consistent pattern — a category prefix that changed, for instance — a single pattern-based rule can cover many pages at once. See setting up 301 redirects for the detail on writing these correctly.

Testing redirects before and after the switch

Test redirects on the new server before DNS changes, using the same hosts file technique used for the rest of the migration — see previewing a site with your hosts file. After DNS has switched, spot-check a sample of old URLs again from a real browser to confirm the redirects are live for everyone, not just working in your private preview.

What if the whole site's structure is being rebuilt?

This is common when moving off a website builder or changing CMS platform entirely, and it deserves its own redirect mapping exercise rather than an afterthought — see moving off a hosted website builder for handling that case, and moving to a new domain if the domain is changing as well as the structure.

Checking search engines have kept up

A short dip in crawl activity right after a migration is normal, as search engines re-verify a few technical details. If, weeks later, old URLs are still showing in search results instead of new ones, or pages are returning errors when a search engine tries to recrawl them, that points to a missing or incorrectly configured redirect rather than something to wait out.