Website Redirects: How to Move Pages Without Losing Visitors

A page has moved, but its old links are still out there in search results, emails, and bookmarks. Set up website redirects so visitors reach the right new page automatically, and use a permanent redirect for a move you intend to keep.

That sounds simple until a site has hundreds of URLs, several possible destinations, and a checkout flow that cannot afford surprises. A plan for website redirects gives each old address a deliberate outcome instead of sending everyone to the homepage and hoping for the best.

Choose the Right Redirect for the Move

A redirect is a server response that tells a browser or search engine to request a different URL. The original address returns a redirect status and a destination, usually in a Location header. The browser then makes another request to that destination.

For a permanent move, a 301 is the familiar default. It tells clients that the old URL has moved for good. A 308 also indicates a permanent move, but explicitly preserves the request method and body. That distinction matters for forms and application endpoints, not just ordinary page visits.

For a temporary change, use a 302 or 307. A 307 explicitly preserves the method and body; a 302 may lead clients to turn a POST request into a GET. For an ordinary page temporarily moved during maintenance, a 302 is often suitable. For an endpoint receiving submitted data, consult your application documentation and test the exact behavior before choosing.

Permanent redirects can be cached by browsers and other systems, which makes mistakes harder to undo immediately. Start with a temporary redirect while testing if you need flexibility, then switch to the permanent status once the destination and rules are confirmed. Temporary redirects are not a substitute for a long-term migration plan.

Map Old Pages to Useful Destinations

Before changing the site, make a list of the URLs you control and decide where each one should go. Include pages found in your sitemap, internal links, analytics reports, and any export your site platform provides. None of these lists is guaranteed to be complete, so combine them.

A simple spreadsheet is enough. Give each row an old URL, a proposed destination, a reason for the change, an intended status, and a test result. Add an owner for decisions that need business input. The person configuring the server should not have to guess which replacement product page the sales team wants.

Match intent, not just words. If an old page describes a particular service and the new site has an updated version of that service, redirect there. If the service has been discontinued with no meaningful replacement, a relevant category page may work, but only if it helps the visitor continue their task.

Do not automatically redirect every missing page to the homepage. Someone following a link to a discontinued product may conclude that the site is broken when they land on an unrelated front page. Search engines may also treat irrelevant redirects as errors rather than useful moves.

Some pages should stay gone. Return a 404 when a page is unavailable and there is no suitable replacement. A 410 communicates that removal is intentional and permanent. Both are preferable to a misleading destination. Use a helpful error page with navigation and search, while making sure the server still returns the correct error status.

Work Through a Small Migration Example

Consider a local bakery rebuilding its website. The example below uses illustrative addresses and counts, not measured traffic or real business data.

Assumptions: The old site has 40 indexed or linked URLs to review. The bakery is keeping its domain, moving its cake-ordering page, combining two location pages, and removing an old promotion. Its developer can configure redirects on the hosting platform.

Suppose the review finds 12 URLs that need permanent website redirects, one that needs a 410, and 27 that remain unchanged. The developer can test those 13 changed responses individually, then sample the unchanged pages to make sure no broad rule caught them by accident.

Next, the bakery updates its navigation and order buttons to point directly to the new URLs. The old links still work through redirects, but visitors using the new site avoid an unnecessary extra request. Any printed flyers with the old ordering address can continue to reach the new page as long as the redirect remains active.

Set Rules Where You Can Maintain Them

Where you create website redirects depends on how the site is hosted. Common choices include a hosting control panel, a content management system plugin, web server configuration, or an edge service such as a content delivery network. Pick the layer your team can inspect and maintain. A rule nobody knows exists is a future debugging problem.

A control panel or plugin is convenient for a small list and may give nondevelopers access. The trade-off is that plugins can conflict, disappear during a platform change, or add processing before a visitor reaches the destination. Server or edge rules can handle larger sets efficiently, but usually require more technical review and a safe deployment process.

Keep one authoritative record even if rules live in different places. For example, a hosting-level rule may force HTTPS while a content management plugin handles individual article moves. Document both, along with who can change them. Otherwise, two individually sensible rules can produce a loop.

Specific rules generally need to take precedence over broad patterns. A rule moving an entire folder might send an exceptional page to the wrong destination if it runs first. Test the actual matching order on your platform rather than assuming every server handles rules the same way.

Redirect behavior also intersects with other configuration. If a browser reports a cross-origin error after an application endpoint moves, the redirect may expose a separate configuration issue; the CORS troubleshooting guide explains the distinction. That does not mean a redirect alone fixes access permissions.

Test Website Redirects Before and After Launch

Test from the old URL, not just the new page. Check the status code, the Location header, and the final response. Browser developer tools can show the request sequence in the Network panel. Command-line tools such as curl can inspect headers too, but make sure your test follows redirects when you want to see the complete path.

A good result is usually one hop: old URL, then the correct destination with a successful response. A chain such as old page to intermediate page to current page adds requests and creates more places for failure. Update older rules to point directly to the final destination where practical.

Watch for loops. A rule that sends HTTP traffic to HTTPS can conflict with another rule that sends requests back to HTTP, especially when a proxy sits between the browser and the server. The exact fix depends on how the host passes connection information, so inspect the full path through your infrastructure.

Run a small acceptance checklist before launch:

Query strings deserve special care. Some platforms preserve them automatically, some require explicit configuration, and some rules discard them. Campaign parameters may be useful for reporting, but not every parameter should be carried to every destination. Test a representative link rather than assuming the behavior. For a closer look at campaign parameters, see the guide to UTM tracking.

After release, check server logs or your platform’s reports for unexpected errors and redirect chains. Review important pages in a fresh browser session as well. A browser may remember a previously cached permanent redirect, so a normal reload does not always prove your latest rule is being used.

Protect Links and Search Visibility Over Time

Website redirects help people and search engines find moved content, but they do not guarantee that rankings or traffic will stay unchanged. A redesign can alter page content, internal links, loading behavior, and many other signals at the same time. Keep a record of what changed so you can investigate losses without blaming the redirect list by default.

Update internal links, canonical references, and your XML sitemap to use final URLs. Redirects are a safety net for old links, not a reason to keep publishing outdated addresses. When changing domains, retain control of the old domain and its hosting or redirect service for as long as practical. If that domain expires or the rules disappear, old links stop reaching you.

External links take longer to fix. Ask key partners to update important links where feasible, especially ones that drive customers to booking, ordering, or contact pages. You cannot control every bookmark or old email, so preserve useful redirects rather than removing them simply because the launch is over.

Finally, compare outcomes that matter to visitors. A successful redirect can still land someone on a page that makes an order harder to complete. Review the destination’s content and calls to action alongside the technical response. The landing page conversion guide offers a useful framework for investigating that next problem.

Final Verdict

Use a 301 for a page move you intend to keep, map each old URL to the closest useful destination, and leave genuinely obsolete pages as clear errors. Test the full request path and maintain the rules after launch; a redirect is only useful while it sends people somewhere relevant. Today, export your current URLs and mark the first page that needs a new destination.

Frequently Asked Questions