301 Redirects: When to Use Them, How to Set Them Up and How to Check Them

In short: A 301 redirect tells browsers and search engines that a URL has moved permanently. Google treats 301 and 308 as a strong signal that the target should be the canonical URL; 302 and 307 are temporary and leave the old URL in place. Every site should answer on one address only: http://, https://, www and non-www must all redirect to the same final URL, in one hop. Keep redirects for at least a year, update internal links to the final address, and check the whole chain, not just where it ends.

Redirects are invisible when they work. When they don't, the symptoms are vague: rankings split between www and non-www, a migration that loses traffic for months, a home page that takes an extra second to load because it bounces through three addresses. Most of these problems can be found in a minute by following each version of your address to its end.

This guide covers the redirect types and how Google treats them, the host versions every site must merge, chains and loops, setup on common servers, how our free redirect checker works and how to fix each problem it reports.

What a redirect is

A redirect is a response that says "this resource is somewhere else" and names the new address in a Location header. The browser requests the new address automatically. A server-side redirect looks like this on the wire:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

The status code tells clients how to treat the move. MDN splits them into permanent redirects, after which crawlers "will update the original URL," and temporary ones, which crawlers "don't memorize."

Google's redirects documentation also classifies an instant meta refresh (0 seconds) and a JavaScript location change as permanent, and a delayed meta refresh as temporary. It recommends server-side permanent redirects whenever possible and says to "only use JavaScript redirects if you can't do server-side or meta refresh redirects," because rendering can fail.

Why redirects matter for SEO

They consolidate duplicates. Google's canonicalization guide lists redirects as "a strong signal that the target of the redirect should become canonical." Without them, signals such as links can be split across several URLs for the same content.

They carry moved pages through a migration. When URLs change, a 301 from each old URL to its new equivalent tells Google to swap them in the index and sends visitors from old links to the right page.

They protect HTTPS. Google "prefers HTTPS pages over equivalent HTTP pages as canonical," and the same guide lists an HTTP-to-HTTPS redirect as one way to reinforce that.

They cost time. Every hop is another round trip before the page starts loading. On mobile networks, a chain of three redirects is a noticeable delay before anything appears.

One site, one address

To a crawler, these are four different sites, even if they show the same page:

http://example.com/
http://www.example.com/
https://example.com/
https://www.example.com/

Pick one, usually the HTTPS version with or without www, and make the other three answer with a single 301 straight to it. The choice between www and non-www is a matter of taste; what matters is that only one version answers with 200. Also make sure the TLS certificate covers both example.com and www.example.com, or the https://www redirect fails before it can run.

The same rule applies inside the site: if /pricing and /pricing/ both answer 200, pick one form and redirect the other.

Chains and loops

A chain is a redirect that leads to another redirect. The most common one is protocol and host handled in separate steps:

http://www.example.com/  301 →  https://www.example.com/  301 →  https://example.com/

Google's crawlers "follow up to 10 redirect hops" (HTTP status codes and Google Search), so a two-hop chain will not lose the page. But Google's site move guide says to "avoid chaining redirects" and redirect "to the final destination directly"; if that is not possible, keep chains short, "ideally no more than 3 and fewer than 5." Visitors pay for every hop either way.

A loop is a chain that never ends: A redirects to B and B back to A, often because an HTTPS rule on the server and another on the CDN disagree. MDN notes that browsers detect loops and show an error, so the page is simply unreachable.

How to set up a 301 redirect

Apache (.htaccess or virtual host), merging all versions into https://www.example.com:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

For a single page, Redirect 301 /old-page https://www.example.com/new-page is enough. Note that a bare Redirect without a code sends a 302 by default, per MDN.

Nginx, with one server block catching every other version:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate lines here for the 443 listener
    if ($host = example.com) { return 301 https://www.example.com$request_uri; }
    if ($scheme = http)      { return 301 https://www.example.com$request_uri; }
    # ... the site itself
}

Many setups use separate server blocks instead; either works as long as each version reaches the final address in one step.

Next.js, in next.config.js:

module.exports = {
  async redirects() {
    return [
      { source: '/old-blog/:slug', destination: '/blog/:slug', permanent: true },
    ]
  },
}

The Next.js docs note that permanent: true sends a 308 and permanent: false a 307, to preserve the request method. Google treats 308 as permanent, so this is fine.

CDNs and hosts. Most CDNs and hosting panels offer redirect rules and an "always use HTTPS" switch. Use one layer for each job: if the CDN upgrades HTTP to HTTPS and the origin server also redirects hosts, you get a two-hop chain, or a loop if the two disagree.

WordPress. The site address in Settings › General decides the canonical host; WordPress redirects other hosts to it. For page-level redirects use a redirect plugin or your SEO plugin's redirect manager, and prefer server rules for the host merge.

How the Searvia redirect checker works

The redirect checker uses the same engine as our website SEO checker: enter a domain and it audits your home page and the files around it with 38 checks in about 20 seconds, showing the three checks this tool is about first. Here is what they do.

Redirects and duplicate versions (medium priority). The checker takes the domain you entered, strips www., and opens four addresses: http:// and https://, each with and without www. It follows each one through up to six redirects and records where it ends and the status code of every hop. A version passes if it ends on the same scheme and host as your home page's final address using only permanent (301 or 308) redirects. The result:

• Fail if any version ends somewhere else, for example https://example.com answering with its own page while https://www.example.com is your main site, or if a version ends in a redirect loop or needs more than six redirects.
• Warning if any version uses a temporary redirect (302, 303 or 307), or if the address you entered needs more than one redirect hop, counted from https:// plus the host you entered, before it answers.
• Pass if every version lands on the same site with permanent redirects and the main address needs one hop or none.

The report lists each of the four versions with its final URL, the redirect codes along the way (for example 301 › 301) and a check or a cross. Versions that do not resolve or cannot be reached, for example a www host with no DNS record, are left out instead of failing.

HTTPS (high priority). It requests http:// plus your host without following redirects. It passes if the site works over HTTPS and the HTTP request answers with a 3xx whose Location starts with https://. It fails with "HTTP does not redirect to HTTPS" or "The site does not work over HTTPS." If plain HTTP does not answer at all, the redirect cannot be tested, and the check shows a note instead of a pass or a failure.

Page status (high priority). The final page must answer with a 2xx status. A 4xx or 5xx fails.

What it does not test

• Meta refresh and JavaScript redirects. Only HTTP redirects are followed. A version that redirects with a meta tag shows as ending on itself.
• Inner pages. Only home page addresses are tested. For page-level redirects after a migration, crawl the old URL list.
• Hop counts per version. The hop warning counts the hops of your main address only; a two-hop permanent chain on http://www shows its codes in the table (301 › 301) but does not lower the result. Use curl to see the URL of each hop.

To see every hop with its URL and code:

curl -sIL http://www.example.com/ | grep -iE '^(HTTP|location)'

Reading the result

The overall grade covers all 38 checks, weighted by priority (high 10, medium 5, low 2; a warning earns half), with a "Fix these first" list and a shareable report link.

How to fix every problem the checker reports

1. Some versions do not redirect to the main one

1. Decide on the final address: https://www.example.com or https://example.com.
2. In the report's table, note which versions end on the wrong URL.
3. Add a 301 from each of them straight to the final address, keeping the path ($request_uri in Nginx, $1 in Apache).
4. If the stray version ends on a different host entirely, check DNS: an old A record for www may point to a parking page or a previous host.
5. Make sure your canonical tags, sitemap and internal links all use the final address too; a redirect that contradicts your canonical sends mixed signals.
6. Rerun the redirect checker.

2. The address goes through several redirects

1. Run the curl -sIL command on the address you entered and read the chain.
2. Merge the steps: one rule that sends every non-final version straight to the final URL, as in the Apache and Nginx examples above.
3. If the CDN and the origin both redirect, let one of them do it. Typically the CDN handles HTTP to HTTPS and the origin does nothing, or the origin does both and the CDN passes requests through.
4. Update links you control: your logo link, navigation, email signatures, social profiles and ad destinations should point to the final address.

3. HTTP does not redirect to HTTPS

1. Confirm HTTPS works with a valid certificate covering both the bare domain and www.
2. Add a permanent redirect from every http:// URL to its https:// equivalent, keeping the path.
3. Once everything works over HTTPS, consider HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains), so browsers skip the HTTP request entirely. Google lists HSTS as another way to reinforce HTTPS as canonical. The security headers checker tests it.

4. The site does not work over HTTPS

Install a certificate (Let's Encrypt is free, and most hosts automate it), make sure it covers every host name you use, then add the HTTP-to-HTTPS redirect from step 3. Mixed content, meaning scripts or images still loaded over http://, is the next thing to clean up.

5. The home page does not answer with 200

A 5xx means a server problem; check error logs. A 403 often means a firewall or bot protection is refusing automated requests, which may be refusing search crawlers too. A 404 on the home page usually means a redirect sends visitors to a path that no longer exists. Fix the target, then recheck.

6. Temporary redirects, loops or long chains

1. Find the row with a cross and read its codes. A 302, 303 or 307 between host versions should become a 301 or 308; check the server, the CDN and any plugin, since the temporary one is often a default (a bare Apache Redirect sends a 302).
2. A loop usually means two layers disagree, such as a CDN that sends HTTPS to HTTP while the origin sends HTTP to HTTPS. Turn one of them off.
3. For a chain of more than six hops, replace it with one rule that goes straight to the final address, as in step 2.

Redirects during a migration

When URLs change, the host-level rules above are only the start. Google's site move guidance adds:

1. Map every old URL to its new equivalent, using sitemaps, server logs, analytics and your CMS. Redirecting everything to the home page is not a mapping.
2. Redirect to the final destination directly, never to a URL that redirects again.
3. Give each new URL a self-referencing canonical, update internal links and make sure every sitemap lists the new URLs.
4. Keep the redirects for as long as possible, generally at least one year.

For international sites, one more rule from Google: avoid automatically redirecting visitors between language versions based on their location or browser language, because "the Googlebot crawler usually originates from the USA" and may never see the other versions (multi-regional sites). Our hreflang guide covers the alternative.

Worked example (hypothetical)

The following is a hypothetical example, not real data. Bramble & Co, an invented furniture shop, moved to a new platform. The redirect checker reports:

The https:// bare domain answered with the full site instead of redirecting: the new platform served both hosts, and only the old server had the host rule. The codes also showed that http://bramble.example/ took two hops and that the first one was a 302. The team added a single 301 rule at the CDN for every non-final version, removed the platform's own HTTPS redirect to avoid a chain, and reran the check: all four versions now end on https://www.bramble.example/ in one hop.

A 15-minute redirect checklist

1. Run the free redirect checker on your domain.
2. Confirm all four versions end on one address.
3. Check the codes for each version in the report (or with curl -sIL): one hop, status 301 or 308.
4. Check that canonicals, the sitemap and internal links use the final address.
5. Make sure the certificate covers both the bare domain and www.
6. After a migration, test a sample of old URLs and keep the redirects for at least a year.

How Searvia helps

The free redirect checker follows every version of your address and checks HTTPS and the home page status in one shareable report. In a Searvia account, the site audit crawls the whole site every week and flags internal links that point to redirects, redirected or broken URLs in the sitemap and pages that return errors, so you can link straight to final addresses everywhere. Uptime monitoring checks your site around the clock and warns you when it goes down or its certificate is about to expire, which is when HTTPS redirects most often break. For the full order of technical checks, see our technical SEO audit guide.