Website Redirect Audit

Server assisted New Website & HTTP Diagnostics

Requests the URL and every redirect it points to one at a time through the Mutqan server, so each hop's own status, Location header, timing, server and Cache-Control are visible. The audit grades the chain the way crawlers and browsers experience it: temporary redirects where a permanent one is meant, HTTPS downgrades, extra hops, cross-host jumps, old pages sent to the home page and client-side meta refresh on the final page.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

What makes a good redirect chain?

A redirect chain is the sequence of 3xx responses a client follows, each Location header pointing to the next URL, until a page answers. A good chain is short — ideally one hop — uses a permanent code (301 or 308) when the move is permanent, keeps the path and query of the old URL, never drops from HTTPS to HTTP and never loops. Every extra hop costs a round trip, and Google's crawlers stop after 10.

How to use Website Redirect Audit

  1. Enter the URL whose redirects you want to audit — an old address after a migration, a campaign link, or the http:// form of your domain.
  2. Choose who the requests claim to be: the default checker, a mobile browser or Googlebot.
  3. Press Audit redirects. The Findings table lists problems first, then warnings, notes and what is already right.
  4. Use Every response to see each hop's status, Location header and timing, fix the redirect rules on the server, and run the audit again.

Website Redirect Audit features

  • Requests the start URL and each redirect target separately through the Mutqan server — up to six responses — so every hop shows its own status, Location header, time, Server and Cache-Control
  • Classifies each hop as a permanent (301, 308) or temporary (302, 303, 307) redirect, an unusual 3xx, the final page or an error
  • Flags the problems that cost rankings and speed: redirect loops, chains still redirecting after five hops, HTTPS-to-HTTP downgrades, temporary redirects, chains that end on an error, slow hops and redirects without a Location header
  • Checks the move itself: whether the path and query string survive, whether an old page is sent to the home page (a soft 404), and whether a hop only adds a trailing slash or changes letter case
  • Audits the HTTPS upgrade from an http:// start: where it happens, whether the first redirect stays on the same host as HSTS preloading requires, and whether the final page sends Strict-Transport-Security
  • Reads the final HTML page for a meta refresh — a client-side redirect — and reports its delay and target without following it
  • Fetches as the Mutqan checker, a mobile browser or the Googlebot User-Agent, to catch redirects that depend on the client

Inputs and outputs

Inputs

  • Start URL — any public http:// or https:// address; a bare host name gets http:// added, so the HTTPS upgrade is part of the audit.
  • Fetch as — the request profile used for every hop: the Mutqan checker, a mobile browser User-Agent or Googlebot's User-Agent (self-declared).

Outputs

  • Summary — the number of redirects, the last status, the total time, the hosts crossed, whether the chain ends on HTTPS, and the count of problems.
  • Findings — every problem, warning, note and good practice found, worst first; downloadable as CSV.
  • Every response — each hop's URL, status, type, Location header as sent, time, Server and Cache-Control; downloadable as CSV.
  • Last response — the URL the chain ends on, its status and Content-Type, its Strict-Transport-Security header and any meta refresh.

Website Redirect Audit example

A sale page sent to the home page through a temporary redirect

Input:

Start URL: http://shop.example.com/sale?ref=mail · Fetch as: Mutqan checker (default)

Output:

Redirects 2 · Last status 200 (Final page) · Total time 640 ms · Hosts 1 · Ends on HTTPS Yes · Problems 0
1 http://shop.example.com/sale?ref=mail → 301 Permanent redirect → https://shop.example.com/sale?ref=mail (140 ms)
2 https://shop.example.com/sale?ref=mail → 302 Temporary redirect → / (180 ms)
3 https://shop.example.com/ → 200 Final page (320 ms)
Warning: Hop 2 is a temporary redirect (302); if the move is permanent, use 301 or 308.
Warning: The path /sale is not kept: the chain ends on the home page https://shop.example.com/.
Note: The query string of the start URL is dropped along the way.
Good: The plain-HTTP address is upgraded to HTTPS at hop 1.

How to read the Website Redirect Audit results

Problem rows break the chain for visitors or crawlers: a loop, an endless chain, an HTTPS downgrade, a redirect without a Location header or a chain that ends with 4xx or 5xx. Fix these first.

Warning rows work but cost something: a temporary redirect where the move is permanent, three or more redirects, a slow hop, an old page sent to the home page, a chain ending on plain HTTP, or a meta refresh doing a server's job.

Notes describe choices that may be intended — two redirects, a relative Location, a host change, a trailing-slash hop, a missing Strict-Transport-Security header. Good rows confirm what is already right.

Times are measured from the Mutqan server and include resolving the host; a hop over one second is reported. A visitor far from the site sees different times, but the number of hops costs every visitor a round trip each.

An "Audit incomplete" note means the checker could not make the next request: the request limit, a refused address, a timeout or a network error. It is not counted among the problems, the chain after that hop is unknown, and the summary shows "—" for the last status and for "Ends on HTTPS".

When to use Website Redirect Audit

  • After a site migration, run the old URLs from your redirect map and confirm each one reaches its replacement in one permanent redirect, keeping the path.
  • Check the http:// form of a domain before submitting it to the HSTS preload list: the first redirect must stay on the same host and switch to HTTPS.
  • Find out why Search Console keeps an old URL or reports a redirect error: look for temporary codes, loops, long chains and meta refresh.
  • Audit marketing and QR-code links: make sure the campaign parameters survive the redirects and the chain does not stop at an error page.

Troubleshooting

  • The audit ends with an "Audit incomplete" note carrying the request-limit message: every hop is one page fetch on the Mutqan server, and page fetches are limited to 10 a minute without signing in (30 when signed in), shared with every tool that fetches a page; all Internet tools together also allow 120 requests a minute from one address. A six-hop audit uses six of the ten, so wait a minute and run it again.
  • A loop between the www and non-www host, or between http and https: two rules (often one in the application and one at the CDN) disagree about the canonical address. Make both point to the same final form.
  • The chain ends with 403 or a challenge page: a firewall or bot protection may answer automated clients differently. Try the mobile profile; if visitors see a page, the protection is the cause, not the redirect.
  • A hop ends in an "Audit incomplete" note because its target was refused: the Mutqan server does not connect to private or reserved addresses, internal names (single-label hosts, .local, .internal, .corp and the like), this site's own address, workers.dev hosts, or ports outside 80, 443, 8080, 8443 and most of the 3000–3999, 5000–5999 and 8000–8999 ranges. Some of these targets are reachable for ordinary visitors, so the refusal is a limit of the checker, not proof that the redirect is broken; the note gives the specific reason.

Frequently asked questions about Website Redirect Audit

How is this different from the Redirect Checker and the Domain Redirect Checker?

The Redirect Checker traces one chain quickly. The Domain Redirect Checker compares the four entry points of a domain (http and https, with and without www). This audit requests each hop of one URL separately, so it can show every hop's own headers and timing, check whether the path survives the move, and read the final page for a meta refresh.

Should I use 301 or 302?

Use 301 or 308 when the old URL is gone for good: browsers remember the move and search engines treat the target as the page to index. Use 302, 303 or 307 only when the old URL will come back. 308 and 307 also keep the request method and body, which matters for forms and APIs; 301 and 302 allow a client to switch POST to GET.

How many redirects are too many?

One is ideal and two is common (http to https, then to www). Each hop costs a round trip before the page can start loading, and Google's crawlers follow at most 10 hops. The audit requests at most six responses and reports a chain that is still redirecting after five redirects.

Why is redirecting old pages to the home page reported?

When a removed page redirects to the home page instead of to its closest replacement, search engines usually treat it as a soft 404 and drop it, and visitors lose the content they were looking for. The audit flags a chain that starts on a deeper path and ends on the root of a site.

Does the audit follow JavaScript redirects?

No. It reads HTTP redirects and, on the final page, a meta refresh tag, which it reports without following. A redirect done by JavaScript only happens in a browser that runs the page's scripts, so it cannot be seen here.

How many audits can I run in a minute?

Every hop is one page fetch on the Mutqan server. Without signing in you can make 10 page fetches a minute (30 when signed in), and that allowance is shared with every tool that fetches a page; all Internet tools together also allow 120 requests a minute from one address. A chain with two redirects costs three fetches and the longest audit six. When the allowance runs out mid-chain, the audit ends with an "Audit incomplete" note for the hop it could not request instead of reporting a problem with the site.

Technical notes

Each hop is one POST /api/v1/internet/http/fetch call with followRedirects set to false: the Mutqan server resolves the host through DNS over HTTPS, refuses private and reserved addresses, sends the chosen fixed header set and returns that single response, including its raw Location header. The browser resolves the Location against the hop's URL (as RFC 9110 §10.2.2 specifies), drops any fragment, and requests the next hop, up to six responses in all.

RFC 9110 §15.4 defines the redirect codes: 301 and 308 are permanent, 302, 303 and 307 temporary, and 307 and 308 forbid changing the request method. Google treats 301, 308 and an instant meta refresh as permanent signals for its canonical choice and 302, 303, 307 and a delayed meta refresh as temporary, and its crawlers follow at most 10 hops.

A loop is reported as soon as a Location points to a URL already requested in the chain; a Location that is not a valid URL, or that points to a scheme other than http or https, ends the audit with a finding instead of a request.

Limitations and methodology

Requests come from the Mutqan server on Cloudflare's network. Sites that redirect by country, language, device or cookie may send real visitors somewhere else.

JavaScript redirects are not seen: only HTTP redirects and a meta refresh in the final HTML page are reported, and the meta refresh is not followed.

At most six responses are requested per audit, and only the first 64 KiB of the last page is read when looking for a meta refresh.

Security and privacy

The Mutqan server receives the start URL and each redirect target, requests each one once with a fixed set of headers and none of your cookies, and keeps nothing. The page bodies are read as text in your browser and never rendered.

References

  • RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
  • Redirections in HTTP — MDNMDN Web Docs (Mozilla)HTTP redirects: 3xx status codes with a Location header, permanent (301, 308) versus temporary (302, 303, 307), and how redirect loops arise.
  • Redirects and Google SearchGoogle Search CentralHow Google treats permanent (301, 308) and temporary (302, 303, 307) server-side redirects when it picks the canonical URL of a moved page or site.