301 Redirects: How They Work and How to Set Them Up

A 301 redirect is a server response that tells browsers and search engines a page has moved permanently to a new URL. Visitors who follow an old link land on the new page, and Google treats the new URL as the one to show in search results. Use a 301 when a page moves for good, keep it simple and point it straight at the final address. This guide is part of our website design best practices guide.

You'll need access to wherever your site handles redirects: the server configuration, your hosting platform's settings or your CMS. A terminal with curl makes testing quicker. If you're moving a whole site, start with how to migrate a website without losing SEO, then come back here for the setup.

What a 301 redirect does

When a browser requests a URL that has a 301, the server doesn't send the page. It sends a short response with the status code 301 and a Location header holding the new address. The browser then requests that address, and the visitor sees the new page, usually without noticing.

Search engines follow the same response. Google's documentation says it uses a permanent redirect as a signal that the target should be the canonical URL, so the new address replaces the old one in results over time. Links that pointed to the old URL count towards the new one, and Google says permanent redirects don't cause a loss in PageRank.

Redirects are useful when you change a page's URL, merge two pages, move to a new domain, or choose one preferred version of your home page and send the others to it.

301 vs 302, 307 and 308

Several status codes redirect. For search, the main split is permanent versus temporary. Google shows the target of a permanent redirect in results, and the source of a temporary one:

The difference between 301 and 308, and between 302 and 307, is technical. Codes 307 and 308 tell the client to repeat the request with the same method, so a submitted form stays a form submission. Some older clients turn a 301 into a plain page request.

Some frameworks choose the code for you. In Next.js, redirects live in the config file, and setting permanent to true sends a 308, which the Next.js docs say clients and search engines cache:

module.exports = {
  async redirects() {
    return [
      { source: "/old-page", destination: "/new-page", permanent: true },
    ];
  },
};

Steps

1. 01
   Decide whether a redirect is the right answer.

   Redirect only when the content has a real new home. If a page is gone and nothing replaces it, return a 404 or 410 instead. If the move is temporary, such as a service paused for a month, use a 302 or 307 so the original URL stays in search results.

2. 02
   Pick the closest relevant target.

   Send each old URL to the page that best replaces it: the same content at a new address, or the page it was merged into. Don't send many old URLs to the home page. Google says that can confuse users and may be treated as a soft 404, which means the redirect counts for little.

3. 03
   Use a server-side permanent redirect.

   Google recommends a server-side 301 or 308 whenever possible, because it has the best chance of being read correctly. An instant meta refresh is the fallback if you can't change server settings. Use a JavaScript redirect only as a last resort, since Google sees it only if the page renders.

4. 04
   Set it up where your site is served.

   On Apache, a single line in the configuration or .htaccess file does it. On NGINX, a return rule inside a location block. Hosted platforms and most CMSs have a redirects screen in their settings instead. Here are the server versions, with placeholder paths:

   text

   # Apache (mod_alias)
   Redirect permanent "/old-page" "https://example.com/new-page"
   
   # NGINX
   location = /old-page {
     return 301 https://example.com/new-page;
   }

5. 05
   Redirect straight to the final URL.

   If a page has moved twice, point the oldest URL directly at the newest one, not through the middle step. Google's crawler follows up to 10 hops, but its guide recommends going directly to the final destination and keeping any chain short. Every hop adds a delay for visitors, which shows up in Time to First Byte.

6. 06
   Update links, canonicals and sitemaps.

   A redirect is a safety net, not a substitute for correct links. Change internal links, navigation and buttons to point at the new URL. Make sure the new page's canonical tag points to itself, and list the new URL in your sitemap, not the old one.

7. 07
   Test the response, not the browser.

   Browsers can cache permanent redirects, so a browser test may show an old result. Use curl to see the raw response. You should see one 301 or 308, a Location header with the new URL, and then a 200 when you request that address:

   bash

   curl -sI https://example.com/old-page
   curl -sIL https://example.com/old-page

8. 08
   Keep the redirect in place.

   Google's site move guide suggests keeping redirects for at least a year, so it can transfer signals and recrawl links from other sites. Old links in emails, bookmarks and other websites keep arriving for longer than that, so leaving redirects in place indefinitely is kinder to visitors.

If you'd rather have redirects mapped and set up for you, our in-house web team builds sites with SEO foundations such as metadata, structured data and sitemaps built in.

Redirects and accessibility

A well-made redirect is invisible, which is exactly what you want for every visitor. Problems start when a redirect is slow, surprising or sends people somewhere unexpected.

Avoid timed redirects. A page that says "this page has moved" and forwards visitors after a few seconds can interrupt a screen reader user partway through reading it. W3C lists a meta refresh redirect with a time limit as a failure technique, F40, tied to WCAG's Timing Adjustable criterion. An instant server-side redirect avoids the problem.

Send people to a matching page. A redirect to an unrelated page, such as the home page, is disorienting for anyone, and more so for someone navigating by headings or links. They arrive expecting one thing and must work out that the page they wanted is gone.

Keep chains short. Each hop adds waiting time before anything appears. On a slow connection, a long chain can look like a broken link.

Make the 404 page clear. When you choose not to redirect, the 404 page should say plainly that the page wasn't found, in both its heading and its page title, and offer a search box and links to the main sections.

For more on what the guidelines cover, see website accessibility and WCAG.

Troubleshooting

The browser says the page has a redirect loop

Cause: a redirect points back to itself, directly or through other redirects, so the browser never reaches a page. Common causes are two rules that undo each other, such as one adding a trailing slash and another removing it, an http to https rule fighting a setting in a CDN or proxy, or a pattern rule that also matches its own target.

Fix: run curl with the -L flag on the URL and read each hop to see where the cycle starts. Check for overlapping rules in the server, the CMS and the CDN, since any of them can add redirects. Decide on one place to manage each kind of redirect. If a server returns a 500 error straight after a configuration change, MDN notes that a redirect loop is a likely cause. Clear the browser cache before testing again.

Google still shows the old URL in results

Cause: Google hasn't recrawled the old URL yet, the redirect isn't permanent, or other signals still favour the old address. Internal links, canonical tags or sitemap entries pointing at the old URL all tell Google the old address is still the one you prefer. After a domain move, Google may also show old URLs for a while as alternate names, which it says is normal.

Fix: check with curl that the old URL returns a 301 or 308, not a 302. Update internal links, the canonical tag and the sitemap so they all use the new URL. Inspect the new URL in Search Console and request indexing. Then give it time: Google needs to recrawl the old URL to see the redirect, and pages that are rarely crawled take longer.

A redirect works in one browser but not another

Cause: the browser cached an earlier response. Permanent redirects can be cached, so a browser that once saw a different redirect, or none, may keep using that result. A CDN or caching layer between the server and the visitor can do the same, which makes changes appear on some devices and not others.

Fix: test with curl, which doesn't use the browser's cache, or in a private window. Purge the CDN or hosting cache after changing redirect rules. If you set a permanent redirect by mistake and need to change it, update the rule and purge caches, but expect some browsers to keep the old redirect for a while. While testing a new rule, a temporary redirect avoids the problem, then switch to permanent once it's right.