Website Migration Redirects: Keep Your Search Traffic

Moving to a new domain, platform or URL structure asks search engines to work out that your new pages are the same as the old ones. Redirects are how you tell them. This guide covers which redirect to use, how to map your old URLs, and how to test the move.

In short: Make a complete list of every old URL and decide where each one goes. Use permanent redirects (301 or 308) for pages that have moved for good, and send each old address to its new address in a single hop. Test key URLs by hand, crawl the rest, and watch Search Console after launch. Most migration damage comes from planning gaps, not from the redirects themselves.

What a redirect actually is

When a browser or search engine asks for a URL, your server replies with a status code. 200 means "here is the page". A redirect reply says "this page lives at another address", and the browser follows it automatically.

Four codes come up in migrations:

• 301 Moved Permanently: the old address is replaced for good.
• 308 Permanent Redirect: like 301, but keeps the request method (useful for forms and APIs).
• 302 Found: the move is temporary.
• 307 Temporary Redirect: like 302, but keeps the request method.

301 or 302: which to use

Google treats permanent redirects as a strong signal that the new URL should replace the old one in search results. Temporary redirects are not a canonical signal, so Google may keep showing the old URL. For a permanent move, use a permanent redirect. Google's documentation on redirects and Google Search explains the details.

For short planned downtime, the affected URLs should return 503 Service Unavailable. A 302 sends visitors elsewhere; it does not say "come back later". If you are unsure during a migration, the answer is almost always 301.

Before you move anything: build a URL map

The most useful preparation is a spreadsheet of every current URL and its new address. That means every URL that exists, not just the twenty pages you remember.

Sources to pull from:

1. Your sitemap, often at /sitemap.xml, or the Sitemap: line in robots.txt.
2. Google Search Console: exports from the Pages and Performance reports are useful, but not a complete inventory.
3. A crawl of your current site with any crawler that reports status codes.
4. Your analytics: any URL that received visits in the last year.
5. Backlink data: any page that other sites link to.

Give the sheet these columns: old URL, action (redirect, keep or remove), new URL, expected status code, priority and test result.

Redirect only when the new page genuinely serves the same purpose. If there is no real equivalent, return 404 or 410 Gone. Sending every retired product to the homepage is a classic mistake: it is unhelpful for visitors, who land somewhere unrelated to what they wanted, and a 404 or 410 is the more honest answer.

Before building anything, check the map:

• Every old URL points to exactly one destination, or is marked for removal.
• No redirect points to another redirect (a chain), and none points to itself (a loop).
• Every destination exists and returns 200.

Tip: Ask whether you need new URLs at all. A redesign does not require new addresses, and keeping the same structure removes most of the risk.

If sorting out which pages matter feels overwhelming, how to read an SEO audit helps you prioritise.

How to add redirects

Apache (.htaccess):

Redirect 301 /old-page/ https://example.com/new-page/

Apache's Redirect directive matches by prefix, so test trailing-slash and sub-path variants.

Nginx:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

The = makes this an exact match.

WordPress: redirect plugins let you add rules from the dashboard. Very large rule sets are usually easier to maintain at server or CDN level.

CDNs, Shopify, Wix, Squarespace: most offer a redirects feature. Limits and wildcard support differ, so check current documentation before relying on it for hundreds of URLs.

Watch out: A typo in .htaccess or an Nginx file can take the whole site offline. Back up the configuration, validate the syntax and know how you will roll back before you save changes.

The migration, step by step

1. Back up everything. Site files, database, server configuration, DNS records, your URL map and a baseline of analytics and Search Console data. Decide in advance what would trigger a rollback.
2. Build the new site on a staging address and password-protect it. If you rely on noindex instead, do not also block staging in robots.txt, because crawlers must fetch a page to see the instruction. See robots.txt mistakes.
3. Update internal references so menus, links, canonical tags, sitemap entries, structured data and hreflang (if used) point at the new URLs rather than relying on redirects.
4. Load every redirect rule from your map. For a domain change, the rules must answer requests to the old domain.
5. Launch. Point DNS at the new site and remove the staging password and any noindex. If you change DNS provider, copy your mail records (MX, SPF, DKIM, DMARC) across too. See SPF, DKIM and DMARC explained.
6. Check indexability at once. Important pages should return 200, carry no accidental noindex, and have canonicals pointing at themselves.
7. Test by hand, then crawl. Check revenue pages, high-traffic pages, pages with many backlinks and one example of each URL pattern. Then crawl the full old URL list and look for anything that is not a single clean redirect to a 200 page.
8. Submit the new sitemap in Google Search Console and Bing Webmaster Tools. For a domain move, consider Search Console's Change of Address tool, after checking Google's site move guidance for current requirements.
9. Keep the redirects running. Google's site move guidance says to keep them as long as possible, generally at least a year. The old hosting server can go, but the old domain, its HTTPS certificate and the redirect service must stay.

Test the non-SEO parts too: checkout, contact forms, analytics tags, consent banners and downloads. Perfect redirects do not help if a broken form quietly loses enquiries.

What to watch after launch

Check often in the first week, then regularly.

Google may crawl more than usual while it processes the new URLs, so a change in the Crawl stats report is not automatically a problem.

If your new site is a single-page JavaScript application, redirects are not enough because Google must also see the content. Why your React site might be invisible to Google covers that.

Once things settle, run a fresh crawl to find leftover chains (A → B → C) and flatten them. A free single-page SEO scan on key pages of the new site can also surface common on-page issues after a redesign.

Common mistakes

• Chains and loops. Each hop adds delay, and broken chains can stop crawlers and visitors reaching the page.
• Forgetting the four variants. http://example.com, http://www.example.com, https://example.com and https://www.example.com are four different URLs. Pick one and 301 the other three to it.
• Letting the old domain lapse. Links on other sites take a long time to update, and a lapsed domain sends them nowhere.
• Losing the URL map. Months later, you will want to know where each old URL was meant to go.
• Changing everything at once. Domain, platform, design and URL structure in one launch make it hard to tell what caused a drop.

Key takeaways

• Build a complete old-to-new URL map before you touch anything, and keep it afterwards.
• Use 301 or 308 for permanent moves, 302 or 307 only for temporary ones, and 503 for downtime.
• Redirect to an equivalent page; otherwise let the old URL return 404 or 410.
• Test key URLs by hand, crawl the rest, and make sure every old URL reaches its destination in one hop.
• Keep redirects and the old domain active for at least a year, and watch Search Console after launch.

FAQ

Will I lose rankings when I migrate?

Nobody can promise an outcome. Some fluctuation is normal while search engines process the change. A complete URL map, correct permanent redirects and sound testing reduce the risk of avoidable losses.

Do I need a 301 for every single page?

Every old URL with a real equivalent should redirect to it. Pages with no equivalent can return 404 or 410. URLs that do not change need no redirect.

How long should I keep redirects?

For as long as you can. Google's site move guidance says generally at least a year, and longer if old URLs still get visits or backlinks.