What Is a 301 Redirect and How Do You Verify One?

A 301 redirect is a permanent HTTP redirect: the server tells the browser (and search engines) that the requested URL has moved for good and that the new URL is the canonical destination. You verify one by requesting the old URL and reading the status code and Location header at each hop until you reach the final page. Use a 301 when a URL change is permanent, such as an HTTP-to-HTTPS migration, a domain move, or a renamed page; use a 302 when the change is temporary.

301 vs. 302 and Other Redirect Codes

The status code is the server's statement about permanence, and that statement is what search engines act on.

For SEO, TrueURL's FAQ notes that a 301 tells search engines to transfer ranking power to the new URL, while a 302 signals the move isn't permanent. That is why 301 is usually preferred for permanent changes. The distinction matters most when the old URL has accumulated links or rankings you want carried over.

How to Verify a 301 Redirect

You can check a single URL with command-line tools or trace the full chain with a redirect checker.

Check the status code directly

Send a request without following redirects and read the response headers:

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

Expected result: a line like HTTP/1.1 301 Moved Permanently followed by a Location: header pointing to the new URL. If you see 200 OK instead, the old URL is serving content directly and no redirect exists. If you see 302, the move is marked temporary.

Trace the full chain

A single request only shows the first hop. To see every step, follow redirects and print each response:

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

Each block of headers represents one hop. Read them in order: the first status code and Location, then the next, until a 200 appears. That final 200 URL is where the link really goes.

Use a redirect checker

TrueURL follows and analyzes every redirect in the chain, including status codes, and shows the complete path with timing data. The workflow is: paste the URL into the search box, let the tool follow each redirect, then review the results for the status code at each step and the final destination. This is useful for shortened links, where the visible URL hides the true target. TrueURL's FAQ states it doesn't store or save checked URLs and analyzes one URL at a time, so bulk checks require running each URL individually.

What to Look For in the Results

• First-hop code: Confirm the old URL returns 301, not 302 or 200.
• Final destination: The last 200 URL should be the page you intend, on the domain you intend.
• Chain length: Each extra hop adds latency. A long chain of redirects is a sign of accumulated, unmanaged rules.
• Response time per hop: TrueURL reports timing for each step; multiple slow redirects can hurt user experience.
• Protocol: For HTTP→HTTPS migrations, the chain should end on an https:// URL.

Common Causes of Redirect Problems

Redirect loops. Two rules point at each other (A→B and B→A), so the browser gives up with an error. Spot it when the chain never reaches a 200 and repeats the same URLs.

Long chains. Old redirects were never updated after later changes, so A→B→C→D. Collapse them by pointing the original URL directly at the final destination.

Unexpected 301s. A page you thought was live returns 301 because a CMS or server rule still maps the old path. Checking the status code directly confirms whether the redirect is intentional.

Temporary moves marked permanent. A 302 used for a permanent change, or a 301 used for a temporary one, sends the wrong signal. Match the code to the intent.

Practical Checks for Common Migrations

• HTTP to HTTPS: Request the http:// version and confirm a 301 to the https:// equivalent, not a 302 and not a direct 200 on both.
• Domain migration: Confirm the old domain's key URLs return 301 to the corresponding new URLs, and that the chain ends on the new domain.
• Renamed pages: Verify the old path 301s to the new path, and that the new path itself returns 200.

If a check shows the wrong code or an unexpected destination, the fix belongs in the server or CMS redirect rules, not in the link itself. Re-run the same check after the change to confirm the chain now ends where intended.