Redirect Checker

301 vs 302 vs 307 vs 308: what each redirect means for SEO

Every redirect is an HTTP status code in the 3xx range, and the code you pick tells search engines how to treat the move. A 301 is a permanent redirect. It says the old URL is gone for good, so Google should transfer ranking signals (links, relevance, history) to the new URL and eventually replace the old one in the index. This is the workhorse of SEO. URL migrations, domain changes, consolidating duplicate pages, and fixing trailing slash or www inconsistencies should all use 301s.

A 302 is a temporary redirect. It tells crawlers the move is short-lived and the original URL will come back, so they should keep the old URL indexed and keep checking it. Google has said it eventually treats long-lived 302s as permanent, but "eventually" is doing a lot of work in that sentence. During the interim period you can see split signals, the wrong URL ranking, and slower consolidation. If a move is permanent, say so with a 301.

307 and 308 are the stricter modern siblings. A 307 is a temporary redirect that forbids the browser from changing the request method (a POST stays a POST), and a 308 is the permanent version of the same guarantee. For SEO purposes, treat 308 like a 301 and 307 like a 302. One quirk worth knowing: Chrome shows an internal "307 Internal Redirect" when a site is on the HSTS preload list and the browser upgrades HTTP to HTTPS before any request leaves the machine. That is a browser behaviour, not a response from your server, and a server-side checker like this one will not show it.

The practical rule: permanent moves get 301 (or 308), genuinely temporary situations like A/B tests, geo redirects, or maintenance pages get 302 (or 307). The most common mistake we find in audits is a CMS or load balancer issuing 302s by default for moves that are clearly permanent.

Why redirect chains waste crawl budget and dilute signals

A redirect chain is a sequence of hops: URL A redirects to B, B redirects to C, and so on. Chains build up quietly. A site moves from HTTP to HTTPS, then drops www, then restructures a category, and suddenly an old backlink passes through three or four redirects before reaching a page. Each hop costs a full HTTP round trip, which slows down users and crawlers alike.

For search engines the cost is twofold. First, crawl budget. Googlebot will follow a limited number of hops (Google documents up to 10 before flagging a redirect error, but it may defer the rest of a long chain to a later crawl), and every hop is a fetch that could have been spent crawling a real page. On large sites, thousands of chained redirects add up to a meaningful share of crawl activity producing nothing indexable. Second, signal dilution. While 301s are designed to pass authority, every extra hop adds latency, risk, and another point of failure. If any link in the chain breaks, returns a 302, or starts looping, the consolidation you were counting on stops working.

The fix is simple in principle: every redirect should go directly from the old URL to the final destination in one hop. When you add a new redirect, check whether anything already redirects to the URL you are now moving, and update those rules to point at the new final target. Our checker flags any chain longer than 2 hops so you know exactly which rules to collapse.

How to audit redirects after a migration

Site migrations are where redirects make or break organic traffic. Before you launch, build a complete URL mapping: every old URL paired with its new equivalent. Include not just pages but images, PDFs, parameter variants, and anything with backlinks or impressions in Search Console. After launch, the audit has three layers.

First, spot-check your highest-value URLs with a url redirect tracker like this one. Paste the old URLs and confirm each returns a single 301 directly to the right new page, not a chain, not a 302, and definitely not a redirect to the homepage (Google treats mass redirects to the homepage as soft 404s, and you lose the signal transfer entirely).

Second, crawl the old URL list at scale. Export every URL from your pre-migration sitemap, Search Console, and analytics, then run them through a crawler in list mode and check the status code report. You are hunting for 404s (missing redirect rules), 302s (wrong type), chains (rules layered on old rules), and loops.

Third, watch the live signals for several weeks. Search Console's Crawl Stats and Page Indexing reports will show redirect errors and "Page with redirect" counts, and your server logs will show whether Googlebot is still hammering old URLs. Keep the redirects in place for at least a year. Google recommends a minimum of one year for 301s to fully consolidate, and the old backlinks pointing at those URLs never stop needing them.

Meta refresh and JavaScript redirects

Not every redirect is an HTTP status code. A meta refresh is an HTML tag in the page head (meta http-equiv="refresh") that tells the browser to load another URL after a delay. A JavaScript redirect does the same thing with window.location. Both return a 200 status code to a standard HTTP check, which is exactly why they are easy to miss and why this tool scans the final page's HTML for meta refresh tags.

Google can process both. An instant meta refresh (0 seconds) is treated as a permanent redirect, and JavaScript redirects are picked up during rendering. But "can process" is not "should rely on". They are slower for users, they require Google to fetch and render the page before discovering the redirect, they pass signals less reliably, and other search engines and AI crawlers handle them inconsistently. Delayed meta refreshes (5 or 10 seconds) are worse still and can be flagged as a poor user experience.

Treat meta refresh and JavaScript redirects as a last resort for environments where you cannot touch server configuration, like some hosted page builders. Everywhere else, replace them with proper server-side 301s. If our checker flags "Meta refresh found" on a page you thought was a final destination, that page is quietly redirecting users somewhere your status codes do not show.

Frequently asked questions