How to Check Redirects and Redirect Chains

A redirect sends a visitor or a bot from one address to another. To check redirects properly you need three things: the status code of every step, the number of steps in the chain, and the final address with its own status. Below are three ways to check redirects on a website — online, with curl and in the browser — what the difference between 301, 302, 307 and 308 is, and how to fix chains and loops in nginx, Apache and WordPress.

How to Check Redirects Online

The quickest way is the free redirect checker. It requests the URL, follows every Location header by itself (up to 15 steps) and shows the whole path.

1. Paste the full address, including the scheme: http://example.com and https://example.com often behave differently, so check both.
2. Read the summary: number of redirects, final status, total time and whether the chain ends on the same or another domain.
3. Go through the chain step by step. Each step shows its URL and code: 301 or 308 is marked as permanent, 302 or 307 as temporary.
4. Check the recommendations under the chain. The tool flags chains longer than one step, temporary redirects that may need to be 301, redirects to another domain, and confirms a correct HTTP → HTTPS redirect.

Two limitations to keep in mind: the checker follows only server-side HTTP redirects (not meta refresh or JavaScript, see below), and it requests the page with its own user agent, so redirects that depend on the visitor's country, device or cookies may look different for real users.

How to Check a 301 Redirect with curl

In a terminal, curl shows the raw response headers without browser caching:

curl -sIL http://example.com/old-page \
  | grep -iE "^HTTP|^location"

-I requests headers only, -L follows redirects, and grep keeps just the status lines and targets. A clean result looks like this:

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

Some servers answer HEAD requests differently from normal ones. If the result looks odd, repeat with a real GET request: curl -sL -o /dev/null -D - URL.

Checking Redirects in Chrome DevTools

1. Open DevTools (F12) → Network.
2. Tick Preserve log, otherwise the redirect steps disappear when the page changes, and Disable cache.
3. Load the old URL. Each step appears as a separate row with its status; the Location header is in the response headers.

Browsers cache 301 responses aggressively. If you changed a redirect and the browser still follows the old one, test in a private window or with curl before assuming the server is wrong.

301 vs 302 vs 307 vs 308

A 307 can also appear in DevTools without your server sending it: that is the browser's internal redirect to HTTPS for sites on the HSTS list. curl and the online checker will show the real server response instead.

Redirect Chains and Loops

A chain is several redirects in a row: http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. Each step adds a round trip for the user. Googlebot follows up to 10 hops, but Google recommends keeping chains short, and every extra step is another place where something can break during the next migration. Aim for a single redirect from any old address to the final one.

A loop is a chain that returns to an address it has already visited, so it never ends. Browsers show ERR_TOO_MANY_REDIRECTS, and the page cannot be indexed. In the checker a loop shows up as a chain that hits the 15-step limit with the same addresses repeating. Typical causes: an HTTPS redirect on the server plus a "Flexible SSL" setting at the CDN, or conflicting www rules in two places (server config and CMS).

How to Check Redirects Across a Whole Website

Single URLs are fine for spot checks. To find every chain on a site, you need a crawler that follows internal links and records each redirect. SEO Audit does this and reports redirect chains and loops as separate issues alongside broken links, so you can see which internal links still point to old addresses.

How to Fix Redirects

nginx

Combine scheme and host into one step instead of two:

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name example.com;
  location = /old-page/ {
    return 301 /new-page/;
  }
}

Add a separate listen 443 block for www.example.com that also returns 301 to https://example.com$request_uri. After editing, run nginx -t and reload.

Apache (.htaccess)

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

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

The .htaccess generator builds these rules without typos.

WordPress

• Make sure Settings → General has the final URL (https and the right www version) in both address fields; a mismatch with the server rule is a classic cause of loops.
• For individual pages use a redirect plugin (for example, Redirection) or your SEO plugin's redirect manager, and avoid setting the same redirect in a plugin and in the server config.
• After changing permalinks, check a few old URLs: WordPress guesses some old slugs itself, but not all.

Whatever the server, update internal links, canonical tags and the sitemap to point straight to the final URLs, so redirects are only needed for external links and old bookmarks.

Why This Matters for Link Promotion

Links point to a specific address. With a permanent redirect their value still reaches the final page, but it is better to promote the final address directly. If a promoted page has moved after launch, set up a 301 from the old address — the publications do not need to be redone, see "Can I Delete or Change a Publication".