Redirect Checker

Use the Redirect Checker to trace one public URL through its HTTP redirects and inspect the response reached at the end. The report shows the observed addresses, status codes and redirect destinations. Compare that evidence with where the link should lead: a completed chain can still reach the wrong page, while an unfinished check cannot confirm a final destination.

Enter the URL that needs checking

Start with the address people actually use, including its path and any relevant query parameters. Checking only the homepage will not tell you what happens to an old product link. For example, http://example.com/products/old-mug/ illustrates a source address; replace it with the public URL you want to investigate.

Before submitting, identify the expected destination and whether the move should be permanent or temporary. After a product URL change, that might be the same product at its new address. For a temporary service interruption, the original address may need to remain the long-term entry point.

Enter one complete HTTP or HTTPS URL and run the check. Screpy makes a GET request and follows supported HTTP redirects. It does not discover every variant of your domain, use your logged-in browser session or run scripts. To compare different paths, schemes or hostnames, submit those source URLs separately.

Read the redirect chain and final response

Read the response rows in order. Each row gives the requested URL, its HTTP status and a Location destination when a supported redirect supplies one. Location values are shown as resolved addresses. If a response points to /products/new-mug/, the report resolves that path against the URL that sent it; the displayed address need not be the header's original literal text.

This illustrative chain has three responses and two redirects. It is an example, not a scan of a real website:

http://example.com/products/old-mug/       301 → https://example.com/products/old-mug/
https://example.com/products/old-mug/      301 → https://example.com/products/new-mug/
https://example.com/products/new-mug/      200

Here the first status is 301, the final status is 200, and the final URL is the new product address. The final 200 row is a response, not an additional redirect. On a completed check, the redirect count describes the transitions between observed responses. If the check stops early, read that count alongside the retained rows rather than as the chain's full length.

Use the result color with those details:

• Green: a direct successful response with no followed redirects. This is useful when a URL should already be the destination.
• Yellow: a redirect, even when it ends in a successful response, or another response needing review. A yellow redirect is not automatically a broken link.
• Red: a final HTTP error, such as 404 or 500. Read the destination and code before deciding what to fix.
• Gray: the check could not establish a final response. Any retained rows are partial evidence.

These colors describe response categories. They do not score the page's content, prove indexing or determine whether a redirect fits your intention.

Understand 301, 302, 303, 307 and 308

Choose the intended behavior before choosing a status. These are the five redirect codes this checker follows:

The distinctions follow HTTP redirect semantics in RFC 9110. A GET-only check cannot verify what happens to a submitted POST or its body. Seeing 307 or 308 here does not test a form-submission workflow.

Google's redirect guidance recommends permanent server-side redirects for permanent URL changes. Google uses them as a signal favoring the destination as canonical; temporary redirects have a different purpose. That does not make every 302 an SEO error or promise that a 301 will immediately change search results.

For a permanent move that unexpectedly returns a temporary code, inspect the rule that produced it. For an intentional temporary detour, do not change the status merely to obtain a preferred-looking result.

Check that the destination is the right page

A completed chain answers where this request ended. It does not establish that the page is a good replacement. The checker reads response statuses and redirect destinations, without inspecting the final page's content.

Compare the final URL with the destination you identified before running the check. Review the hostname, path and relevant query parameters. An old product link that ends at the homepage with 200 may still fail the visitor's task. Open the destination and decide whether it contains the intended product, article or other relevant replacement. If no suitable replacement exists, do not invent one just to remove an error from the report.

Also review an HTTPS-to-HTTP warning. Decide whether the redirect rule points to the intended secure address and correct an unintended downgrade. The tool's warning describes that transition; it is not a security audit of the destination.

For a page intended to appear in search, use the Canonical Tag Checker to inspect its declared preferred URL separately. Redirect success does not confirm its canonical declaration, the absence of noindex or Google's indexing decision. A correct HTTP chain and a correct page-level declaration are different observations.

Diagnose an incomplete chain

When the final URL or final status is unavailable, start with the last response actually recorded. A Location value tells you where that response wanted the request to go. It does not prove that the next address was reached or that it returned a successful response. An unavailable result is also different from an observed HTTP error: a timeout has no confirmed final code, while a completed response can explicitly return 404 or 403.

Use the retained rows to narrow the investigation:

• Repeated addresses: an illustrative A → B → A sequence is a loop. Review rules that send the request back to an already visited URL, such as conflicting hostname or path rules.
• A long sequence without repetition: the checker follows at most five redirects. Reaching that ceiling does not establish a loop or reveal the rest of the chain. Inspect the last recorded destination separately.
• Redirect status without a usable destination: check whether the relevant response supplies a valid Location. A missing or invalid target cannot be treated as a completed move.
• No next response: public access, name resolution, connection or secure-connection problems can prevent the check. The entire URL chain has eight seconds; it does not receive eight seconds for every hop. Response-header limits and private or unsupported targets can also stop it.

If the destination returns an access restriction or rate-limit response, investigate that condition before assuming the content has been deleted. This request can receive a different response from your logged-in browser. JavaScript redirects, meta refresh and browser behavior are outside the check, so an HTTP result cannot explain every navigation you see on screen.

Fix the cause and recheck the same URL

Download the JSON report before changing a rule. Keep the submitted URL and intended destination with it so the person making the correction can distinguish what happened from what should happen. This tool exports the report as JSON; it does not provide a filtered CSV or edit redirects for you.

1. Find the response where the address or status first differs from your intention. Locate the setting that produces that response, rather than changing unrelated page metadata.
2. Correct an unintended destination, status, loop or downgrade. Remove unnecessary intermediate moves where you control the rules, while preserving routing or tracking that has a deliberate purpose. Point internal links directly to the intended destination when that suits the visitor's task.
3. Run the exact same source URL after the corrected public response is available. Compare the sequence, first and final codes, final address and any remaining unavailable evidence with the saved report.
4. Check relevant source variants separately, such as an old path or a different hostname. One repaired address does not establish that every migration mapping is correct.

Use the Bulk HTTP Status Checker when you have a list to review. It accepts up to 50 URLs and supports filtered CSV export. Keep this single-URL checker for reading one chain closely. A successful recheck verifies the response observed now; it does not prove a future visitor, browser or search crawler will receive identical behavior.