URL Redirects: How They Work, How to Check Them and How to Fix Them

How URL Redirects Work

A redirect is a two step conversation, and the whole thing runs over plain HTTP status codes. Your browser asks for the old URL, and instead of sending the page the server answers with a 3xx status code plus a Location header that holds the new address. The browser then sends a second request to that address. Every extra hop in a chain is another full round trip to the server.

Sites use redirects, also called url forwarding or domain forwarding, for ordinary reasons. A page moved, a domain changed, a migration renamed half the URLs, or someone decided to force https, pick www or drop the www, or add and remove a trailing slash.

It helps to separate three families. A server side redirect is a real HTTP redirect, answered with a 3xx code before any HTML is sent. An HTML meta refresh tag and a JavaScript window.location assignment both happen after the page has started loading, so they are client side tricks, and the JavaScript kind needs the browser to execute code before it moves on. Google describes JavaScript redirects as a last resort, and our Meta Refresh check covers the HTML kind separately. This page is about the server side family.

One more distinction catches people out. A rewrite is not a redirect, and a url rewrite never changes what the visitor sees in the address bar. With a rewrite the server quietly serves other content while the address bar keeps the original URL, so no second request ever happens. If the address in the browser never changes, you are looking at a rewrite or a proxy.

Browsers also cache permanent redirects, sometimes for a long time. That means a normal tab can keep showing the effect of a rule you removed an hour ago. Test in a private window or with curl, as described below, and never trust a single tab when you want to trace redirects. The Redirections in HTTP guide from MDN Web Docs is a solid neutral reference for the mechanics.

301 vs 302 Redirects: Which Status Code to Use

The status code tells clients whether a move is permanent and how to treat the request method. Five redirect status code values cover almost every real case, and the table below puts them side by side so you can pick without guessing.

According to Google's 3xx redirect documentation, Googlebot follows all of these, reads a 301 as a strong hint that the destination is the page to process, and a 302 as only a weak hint. The same page says a 307 is equivalent to a 302 and a 308 to a 301, and that Google's crawlers follow up to 10 hops by default.

Google's separate guidance on redirects and Search adds the client side case: a meta refresh with a zero second delay is read like a permanent redirect, and a delayed one like a temporary redirect.

Our own check treats every 3xx status code alike. The code you choose does not change the report result, it changes what search engines do with your pages afterwards.

Permanent redirects: 301 and 308

Use a 301 redirect whenever a page has moved for good. It tells crawlers to replace the old URL with the new one in the index, and over time the old address drops out of results. Link equity from backlinks pointing at the old URL is expected to follow the redirect, which is the whole reason migrations rely on them.

A 308 does the same job but promises that the request method stays the same. For ordinary page moves a 301 is fine and far more common. Reach for 308 when an API client or a form posts to the old address and must not be turned into a GET. Browsers cache both codes aggressively, so be sure of the destination before you ship, because undoing a cached 301 for returning visitors is slow.

Temporary redirects: 302, 303 and 307

Use a 302 or 307 when the original URL will come back, such as during maintenance, a test of a new landing page or a seasonal offer. Search engines keep the old URL in results because you told them the move is not permanent. A 307 is the stricter sibling that guarantees the method survives.

The 303 has a narrower job. After a visitor submits a form, the server answers with a 303 pointing at a confirmation page, and the browser fetches it with GET. That is the Post/Redirect/Get pattern, and it stops a refresh from submitting the form twice. The classic mistake is a 302 left in place for a move that is permanent, which can keep the old URL in search results long after you meant to replace it.

How SEO Site Checker Tests URL Redirects

The URL Redirects line sits in the part of the report labeled Advance. It is deliberately simple, so it helps to know exactly what it does and what it cannot see before you read the color of the icon.

Exact rule: our report sends one HTTP HEAD request to the address you entered, adding https:// if you typed no scheme and forcing one trailing slash. It follows redirects for up to 30 hops, gives each request 3 seconds to answer, the default python-requests user agent and TLS verification on. The line passes only when no redirect happened before the answer.

Only real 3xx answers that carry a Location header count, meaning 301, 302, 303, 307 and 308. The final status code does not matter for this line. An address that itself answers 404, or answers HEAD with a 405, still passes because no redirect happened. A redirect that lands on a 404 is a hop and shows a warning. Other checks in the report deal with broken pages.

• Pass: the address you entered answered directly, so there was no hop to follow. The final status is not judged here, which is why a 404 or a 405 on HEAD still passes this line.
• Warning: one or more 3xx hops happened before the answer, and the How to Fix button appears. A harmless looking non-www to www hop costs the same as a long chain.
• Fail: the request raised an error. That means a loop or more than 30 hops, no answer within 3 seconds, or a DNS, TLS or connection error. A slow server can therefore show a red line even though visitors get the page, so re-run the report before assuming a loop.
• Not tested: meta refresh and JavaScript redirects, redirects that happen only on GET, and redirects that depend on country or user agent.

Because we always add a trailing slash, a site whose pages normally have none can show a warning for a slash redirect that visitors never notice. If you typed http://, the http to https redirect also counts as a hop. Enter the exact address you want indexed, with the scheme and slash style your site really uses, and a clean site passes.

A pass means this one HEAD request saw no hop. It does not prove that browsers and crawlers see the same thing, especially behind bot protection or a CDN that treats scripts differently from real visitors.

The score counts only passed lines, so a warning is not a pass. That is stricter than Lighthouse, which starts failing its redirect audit at two redirects. We flag a single hop so you can decide whether it is intentional.

The report keeps only the addresses that redirected, not where they ended up or which status codes they returned, so use curl when you need the complete path. The steps further down show how.

Test my website now

Why Redirect Chains and Loops Hurt SEO and Speed

The first reason to care is time. Each redirect hop adds a request and a response before any content starts, and Lighthouse notes that redirects can add hundreds of milliseconds, especially on slow mobile connections. Because that delay lands before the first byte, time to first byte grows by the full length of the chain, and every Core Web Vitals metric that follows, Largest Contentful Paint included, starts late too. Our page speed guide explains how extra requests compound.

The second reason is crawling. That 10 hop ceiling is a limit, not a target, and one hop is the goal. Every hop also spends a little of your crawl budget, which matters most on large sites with thousands of old URLs. A crawler that gives up halfway never reaches your page, so the page cannot be indexed from that path.

Loops are worse, because nothing ever answers. Chrome stops after about 20 hops and shows ERR_TOO_MANY_REDIRECTS, so visitors see a redirect error page, crawlers record a failure, and our report shows a red Failed line. Loops usually appear right after a server, CDN or CMS change, so the timing is a clue. The Page indexing report in Google Search Console lists URLs that fail with a redirect error, which is a useful second place to look.

A quieter problem is the broken redirect that technically works but points nowhere useful. Rules that redirect everything to the homepage are the classic example, and the mistakes section below explains why they cause trouble and what to do instead.

How to Check URL Redirects with a Browser, curl and Our Report

There are three ways to see the hops and two habits that catch the rest. It is worth knowing all three methods, because each shows something the others hide.

1. Run our report. Enter your address in the free SEO report, then find the URL Redirects line in the section labeled Advance. Green means no hop, orange means at least one, red means the test hit an error.
2. Use the browser. Open the Chrome DevTools Network tab, tick Preserve log and reload. Read the status column, and click each 3xx row to see the Location header among the response headers. A 307 marked Internal Redirect comes from HSTS in the browser, not from your server, so it does not count as a server hop.
3. Use curl. In the flags -sIL, s silences the progress bar, I asks for headers only using a HEAD request (the same method our report sends) and L follows each Location header, so you see every hop. The first command below prints the headers of each hop. The second prints only the hop count and the final URL, which suits scripts and bulk checks.
4. Habit one: test every homepage variant. Try http and https, each with and without www. At most one hop to the final address is the target, and the canonical version should need none.
5. Habit two: spot check after a migration. Take your top landing pages from the redirect map and test those, not only the homepage. Old product and article URLs break far more often than the front page.

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

curl -sIL -o /dev/null -w "%{num_redirects} %{url_effective}\n" http://example.com/

curl -sL -D - -o /dev/null https://example.com/old-page

In the first output, look for each HTTP status line followed by its location: header. The second prints something like 2 https://example.com/, meaning two hops before the final URL. Anything above 1 deserves a fix. The third command repeats the trace with a normal GET, which helps when a site answers browsers differently from scripts.

How to Fix Redirect Chains and Redirect Loops

Fixing a chain means making sure nobody hits more than one rule on the way to a page. Work through the steps in order, because the first ones remove most of the problem.

1. Map the chain. Use the curl output to note the first URL and the last URL of every chain you found.
2. Rewrite the first rule. Change it to point straight at the final URL, so the middle hops disappear.
3. Update what you control. Internal links, canonical tags, hreflang annotations, sitemap entries and ad or social links should all use the final address. Then no visitor or crawler meets the redirect at all.
4. Pick one slash style. If /services redirects to /services/ while your menu and sitemap link to /services, every visitor pays a hop for nothing, so link to the form the server settles on.
5. Merge protocol and host rules. The http version of the www host should reach the https non-www version in one hop, not two. This removes the double redirect that most migrations leave behind.
6. Clear caches and re-test. Flush the CMS, plugin, CDN and browser caches, test in a private window and run the report again.

The Lighthouse redirect audit lists further ways to eliminate redirects, including pointing links to the current location of a resource. If choosing between www and non-www is your real question, read our URL canonicalization guide. The http to https hop is covered in the HTTPS encryption check, and your XML sitemap guide reminds you to list final URLs only.

Collapse a chain into one hop

Suppose a visitor types the old http address with www. Two stacked rules send them first to https, then to the bare domain. That is two hops. One server rule that matches every http host and answers with the final address removes the middle step.

Before: 2 hops
  http://www.example.com/page
  https://www.example.com/page
  https://example.com/page

After: 1 hop
  http://www.example.com/page
  https://example.com/page

In Nginx the merged rule lives in the port 80 server block, which lists both hosts so that one return line catches them all. The $request_uri variable keeps the path and the query string, so deep links survive.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

The https www host still needs its own server block or rule that sends visitors to the bare domain, otherwise that variant stays unredirected.

Break a redirect loop

A loop means two rules undo each other. Common pairs are a CMS that forces www while the server strips it, or a CDN on Flexible SSL that talks to the origin over http while the origin forces https. Cloudflare documents switching the encryption mode to Full or higher for that case, which requires a certificate on the origin.

Find the two competing layers, remove one of them, and clear every cache. Then run curl again and confirm that the chain ends with a 200.

How to Set Up a URL Redirect on Apache, Nginx, WordPress and More

Pick the layer closest to the request and use only that one. The snippets below are minimal, and each sends the visitor to the final address in one hop. If the target contains spaces, accents or query strings, run it through the URL Encoder Decoder first so the Location value is valid.

Apache and Nginx

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

# or with mod_rewrite
RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page [R=301,L]

# Nginx, inside the matching server block
location = /old-page {
    return 301 https://example.com/new-page;
}

On Apache the plain Redirect line matches by path prefix and carries any remaining path along, so /old-page/child also lands on /new-page/child. For an exact single URL use RedirectMatch ^/old-page$ or the rewrite rule shown, and keep mod_rewrite for real patterns. On a Windows server with IIS, the URL Rewrite module does the same job with a redirect action. On Nginx, a return 301 is simpler and faster than a rewrite for a plain redirect.

WordPress, Shopify and Wix

In WordPress, use one layer only. Choose either a WordPress redirect plugin or the server file, never both for the same URL, or you build double hops without noticing. A redirect manager plugin, an SSL or force-https plugin and an .htaccess rule on the same URL stack into chains.

Check Settings, then General, as well. The WordPress Address and Site Address must use the same scheme and host as your canonical URL, otherwise WordPress keeps redirecting to the version it believes is correct. Switch off or purge the caching plugin before testing, because it can serve an old redirect long after you changed the rule.

In Shopify, open Content, then Menus, then View URL Redirects. According to Shopify's help pages, you can redirect only from a URL that currently returns a 404, and the limits are 100,000 redirects (20,000,000 on Plus), with CSV import for bulk work.

In Wix, open the SEO tools in your dashboard and find the URL Redirect Manager (menu names change, so follow the live help page). Wix's help pages say it needs a custom domain, allows 5,000 redirects per site at the time of writing, and cannot redirect the homepage or URLs that contain a hash sign.

Cloudflare

Cloudflare offers Single Redirects and Bulk Redirects in the Rules section of the dashboard, under Redirect Rules. A redirect rule on top of an origin redirect is a common source of loops, so keep the SSL mode on Full or stricter if the origin already forces https.

Common URL Redirect Mistakes

Most 301 redirect problems come from the same handful of habits. Check your setup against this list.

Biggest one: the temporary 302 that nobody swapped for a 301 after the move became permanent. Nothing in the browser looks wrong, which is why it survives for years.

• Dead URLs sent to the homepage. Visitors expected a specific page and land on the front page instead, and search engines may read the pattern as a soft 404. If an old page has no equivalent, let it return a real 404 or 410 with a helpful page. Our custom 404 page guide shows what that page should contain.
• Links that still point at redirecting addresses. Internal links, canonical tags and sitemap entries that name the old URL make every visitor and crawler pay for the hop again, long after the redirect was set up.
• A redirect that targets another redirect. It usually hides in two separate rules, one for http to https and another for www to non-www. Each looks reasonable alone, and together they make a chain.
• Stacked rules. The CMS, a plugin, the CDN and the server file can each carry their own redirect, and when they disagree you get a loop that only shows up after a change in one layer.
• Testing only the homepage. The front page is often the one URL that works. Try the trailing slash, uppercase and www variants of deeper pages too.

URL Redirect Best Practices

Keep this list next to your deploy checklist.

• One hop at most. No public URL needs more than a single redirect to reach its final address.
• Right code for the job. Use 301 or 308 for permanent moves and 302 or 307 for temporary ones.
• Direct links. Link to final URLs wherever you control the link.
• Relevant targets. Send each old URL to its closest equivalent page.
• A redirect map. Keep one for every migration and check it with a crawl and our report after launch.
• Long memory. Leave old redirects in place for the long term, because old backlinks and bookmarks still use them. Google's site move guidance suggests keeping them at least a year, and there is little reason to remove them sooner.
• Retest after changes. Check the host and protocol variants after every server, CDN or CMS change.

Redirects are one part of a wider audit, and our technical SEO checklist shows where they fit.