Redirect Checker

What Are URL Redirects?

A URL redirect is pretty simple. Someone visits one web address, and the server sends them somewhere else instead. It's like mail forwarding. You move houses, tell the post office your new address, and your mail shows up there. Same idea with web pages. Our redirect checker lets you trace every hop and make sure your redirects actually go where they should.

Here's what happens under the hood: your browser asks for a page, and the server responds with a special HTTP status code, basically a three-digit number that tells the browser the page moved and to go to the new location instead. The browser follows that instruction and loads the new URL. It happens so fast most people don't even realize it. You can look up any HTTP status code to see what it means.

The thing is, not all redirects work the same way. That status code tells browsers and search engines how the page moved. Was it temporary? Permanent? Something else? If you pick the wrong one, it can mess up your SEO, confuse visitors, or throw off your analytics. Whether you just need a quick redirect test or a full-on audit, knowing the difference between each type is where you start.

301 Permanent Redirect

A 301 redirect tells browsers and search engines that the page has permanently moved to a new URL and they should update their records. It's the most common redirect you'll use, and it's the one that passes the most SEO value (often called link equityor link juice) from the old URL to the new one.

Use a 301 when you've changed a URL slug, moved to a new domain, consolidated duplicate pages, or switched from HTTP to HTTPS. Basically, any time the old URL should never come back, use a 301. Want to check 301 redirect behavior on your own URLs? Paste them into the tool above and see the full redirect path instantly.

302 Temporary Redirect

A 302 redirect tells search engines that the page has moved, but only for now, so they should keep the old URL in their index. The key difference from a 301 is that search engines won't transfer ranking signals to the new URL. They'll keep the original indexed.

Use a 302 when you're running an A/B test, showing a temporary maintenance page, or redirecting users based on their location or language for a limited time. If the move is permanent, don't use a 302. You'll lose SEO value.

303, 307, and 308 The Other Redirect Types

These three are less common but still important to understand:

• 303 (See Other) tells the browser to fetch the new URL with a GET request, regardless of the original method. You'll see this after form submissions when the server wants to redirect you to a confirmation page.
• 307 (Temporary Redirect) is like a 302, but stricter. The browser must use the same HTTP method (POST stays POST, GET stays GET). This matters for API endpoints and form submissions where changing the method would break things.
• 308 (Permanent Redirect) is like a 301, but with the same strict method preservation as 307. The page has permanently moved, and the browser must keep using the same HTTP method. It's the modern, spec-compliant version of 301.

Why URL Redirects Matter for SEO

Look, redirects aren't just some nerdy server thing. They have a real impact on whether people find your site on Google. A well-set-up SEO redirect keeps your rankings intact. Screw it up and you might wake up to a traffic drop you can't explain.

PageRank and Link Equity

When another site links to your page, that link carries equity, a signal that tells Google your page is valuable. When you redirect that page, the equity needs to flow to the new URL. A 301 redirect passes most of that equity along. Google has confirmed that 301 redirects pass full PageRank, so there's no penalty for using them correctly.

Here's the deal: redirect chains (A → B → C → D) leak a little bit of equity at each hop. One redirect? No problem. Two? Still fine. But five in a row? Now you're losing ranking power at every step. That's why you should check your redirect chains regularly and shorten them to a single hop when you can.

Core Web Vitals Impact

Every redirect adds a bit of delay. Each hop means your browser has to do another DNS lookup, open another connection, and wait for another response. On a decent server that's maybe 50–100ms. On a slow one? Could be 300ms or more. Chain three or four of those together and you've just added a full second before your page even starts loading.

That matters because Google's Core Web Vitals, especially LCP (Largest Contentful Paint), take a hit from redirect latency. If your LCP is already borderline, a messy redirect chain might be the thing that pushes it over. Our health score accounts for total redirect latency, so you can catch these problems right away.

Common Redirect Problems: How to Check and Fix Them

Most redirect problems are pretty predictable. Here are the ones we see all the time, and what to do about them.

Redirect chains (too many hops). This happens when URL A redirects to B, which redirects to C, which redirects to D. Each hop adds latency and dilutes link equity. The fix is simple: update the redirect so A goes directly to D. Use our tool to trace the full chain and identify where to cut.

Redirect loops. A redirect loop happens when URL A redirects to B, and B redirects back to A. The browser goes back and forth until it gives up and shows an error. This usually happens after a misconfigured server rule or a plugin conflict. Check your .htaccess or NGINX config for conflicting rules.

Mixed HTTP/HTTPS chains. You've set up HTTPS, but some redirects still go through HTTP first. For example: http://example.com → http://www.example.com → https://www.example.com. That first hop is insecure and adds unnecessary latency. Proper security headers like HSTS can help prevent this by telling browsers to always use HTTPS. Fix it by redirecting straight from HTTP to the final HTTPS URL in one step.

302 used instead of 301. This is one of the most common mistakes. A developer sets up a temporary redirect and forgets to change it to permanent. Months later, search engines are still indexing the old URL because the 302 told them to. Audit your redirects and switch any permanent moves to 301. If old URLs are returning 404 errors, use our broken link checker to find them.

When Do You Need URL Redirects?

Site Migrations

Moving to a new CMS, restructuring your URL paths, or switching from a subdomain to a subfolder? You need redirects. During a site migration, every old URL that had traffic, backlinks, or search rankings should 301 redirect to its equivalent on the new structure. Miss even a handful and you'll see 404 errors in Search Console and lost rankings.

Pro tip: before migrating, use our URL extractor to crawl your entire site and export a list of all URLs. After migration, use our bulk redirect checker to verify every redirect is working. It handles up to 15,000 URLs at once.

Rebrands and Domain Consolidation

Changing your company name or merging multiple domains into one? Every page on the old domain needs a 301 redirect to the corresponding page on the new domain. Don't just redirect everything to the homepage. That's a "soft 404" in Google's eyes and you'll lose the ranking power of those individual pages.

Affiliate Link Tracking

Affiliate marketers use redirects to track clicks and route users through partner networks. The problem? Some affiliate chains have 4–5 hops before reaching the final destination. Each hop adds latency and gives the user another chance to bounce. Use our tool to trace the full chain and see exactly where your traffic is going. You can also use our link preview tool to check how your final destination looks in social shares.

301 Redirect vs 302 vs Canonical Tag

This one trips people up all the time, so let's sort it out.

A 301 redirect physically sends the user to a new URL. The old URL is gone, and visitors and search engines both end up at the new address. Use this when the old page no longer exists or has permanently moved.

A 302 redirect also sends the user to a new URL, but tells search engines the move is temporary. The old URL stays in the index. Use this when running A/B tests, geo-based routing, or maintenance pages.

A canonical tag doesn't redirect anyone. Both URLs stay accessible. The tag just tells search engines that the two pages have similar content and to please treat one as the main version. Use canonicals when you have duplicate content across multiple URLs that you want to keep live (like print-friendly versions, tracking parameter variations, or product pages accessible from multiple categories).

Simple rule: if visitors should only ever see one URL, use a redirect. If you need both URLs to stay live but want Google to pick a favorite, go with a canonical tag.

How to Set Up URL Redirects (Apache, NGINX, PHP)

Here's how to actually set up redirects on the most common server platforms. Grab the snippet that matches your setup and swap in your own URLs.

Apache (.htaccess)

If you're on shared hosting or running Apache, the .htaccess file is your go-to. Drop this in your site's root directory:

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

# 301 Redirect using mod_rewrite (more flexible)
RewriteEngine On
RewriteRule ^old-page/?$ /new-page [R=301,L]

# Redirect entire domain from HTTP to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

The first method is the simplest, one line per redirect. The RewriteRule approach gives you regex support for pattern matching. The third example is the classic HTTP-to-HTTPS redirect that every site should have.

NGINX

NGINX handles redirects in the server block configuration. Here's how:

server {
    listen 80;
    server_name example.com www.example.com;

    # Redirect all HTTP to HTTPS
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    # Redirect a single page
    location = /old-page {
        return 301 /new-page;
    }

    # Redirect with regex pattern
    location ~* ^/blog/old-(.*)$ {
        return 301 /articles/$1;
    }
}

NGINX is generally faster than .htaccess because it reads the config once at startup instead of checking a file on every request. If you have access to your NGINX config, always prefer it over .htaccess.

PHP

If you need to redirect from within your application code, PHP makes it straightforward:

<?php
// 301 Permanent Redirect
header("HTTP/1.1 301 Moved Permanently");
header("Location: https://example.com/new-page");
exit();

// 302 Temporary Redirect
header("HTTP/1.1 302 Found");
header("Location: https://example.com/temporary-page");
exit();

// Conditional redirect based on a query parameter
if (isset($_GET['ref']) && $_GET['ref'] === 'old-campaign') {
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: https://example.com/new-campaign");
    exit();
}
?>

Important: always call exit() after a header("Location: ...") call. Without it, PHP continues executing the rest of the script, which wastes resources and can cause unexpected behavior.

Server-Level vs Plugin-Based Redirects

If you're using WordPress, Shopify, or another CMS, you might be tempted to use a plugin for redirects. Plugins like Yoast, Redirection, or Rank Math make it easy. Just fill in the old URL and the new URL and you're done.

Here's the thing about plugins: they work, but they're slow. When a request comes in, a plugin redirect has to spin up the whole CMS first. WordPress loads PHP, connects to the database, fires up all your plugins... and only then checks if there's a redirect. That overhead can easily add 200–500ms.

A server-level redirect (in .htaccess or NGINX config) happens before the CMS even loads. The web server sees the request, checks its rules, and sends the redirect response immediately. It's faster by an order of magnitude. Also make sure your robots.txt isn't blocking crawlers from following your redirects.

For a handful of redirects, the difference is negligible. But if you're managing hundreds or thousands of redirects (common after a site migration), server-level rules are significantly faster and put less load on your server.

Our recommendation: use server-level redirects whenever possible. Use plugins only when you don't have access to server configuration (like on some managed hosting platforms) or when you need a non-technical team member to manage redirects through a UI.

Bottom line: redirects are just part of running a website. Whether you're moving to a new domain, cleaning up old links, or merging duplicate pages, getting your redirects right keeps your SEO healthy and your visitors happy. Use our free link redirect checker above to run a redirect test on your URLs right now. Paste in a single URL or use our bulk redirect checker and either way, you'll get a clear picture of every hop, status code, and potential issue in seconds. Check your redirects today and keep your site running the way it should.