Redirect Checker guide

What redirects do

A redirect is a response with a 3xx status code and a Location header telling the client where to go instead. Browsers follow it automatically, as do search engine crawlers and most HTTP libraries. Sites use redirects to move visitors from HTTP to HTTPS, to pick one host name (with or without www), and to keep old URLs working after a redesign.

Every hop costs a round trip, and each extra hop is another place where something can go wrong. A clean setup reaches the final page in one or two redirects. The Redirect Checker shows the whole chain so you can see exactly what visitors and crawlers go through.

How to use the Redirect Checker

1. Open the Redirect Checker and enter a domain, for example example.com.
2. XGM requests http://example.com, https://example.com, http://www.example.com and https://www.example.com from its server and follows each chain for up to ten hops, including meta refresh tags.
3. The table shows where each of the four ends; the raw chains list every hop with its status code, Location and response time.
4. Read the findings: variants that end at different URLs, hops that could be skipped, meta refresh, temporary redirects, loops, downgrades and errors.
5. Fix the configuration and run the check again from the permalink. The Full report tab also compares the http:// and https:// final URLs and reads the canonical tag.

Every redirect target is checked against the same rules as the starting URL, so a chain that points into a private network is stopped. That protects XGM, and it also means a redirect to an internal host shows up as refused rather than followed.

Redirect status codes

Search engines treat permanent redirects as a signal to index the target URL instead of the old one. A temporary redirect keeps the old URL as the canonical one, which is rarely what you want for HTTP-to-HTTPS or domain changes. The checker notes temporary redirects so you can decide whether they are intentional.

What the findings mean

Fixing common problems

Collapsing a long chain

Chains grow when rules are added independently: the CDN forces HTTPS, the web server adds www, the application adds a trailing slash and a language prefix. Each rule redirects once, and together they create four hops. Point each old variant straight at the final URL.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

Breaking a loop

Loops usually come from two layers disagreeing. A typical case is a CDN connecting to the origin over HTTP while the origin redirects HTTP to HTTPS, and the CDN forwards that redirect back to the visitor. Configure the CDN to use HTTPS to the origin, or make the origin trust the forwarded protocol header from the CDN.

Keeping paths and query strings

Redirects that send every old URL to the home page lose the visitor's context and search rankings. Preserve the path with $request_uri in nginx or %{REQUEST_URI} in Apache, and map changed paths individually.

Test all four variants

Visitors can arrive at four versions of the same site: http://example.com, http://www.example.com, https://example.com and https://www.example.com. All four should end at the same final URL in as few hops as possible. Checking only the one you type yourself misses the others, which are exactly the ones old links use.

Run the checker with example.com and with www.example.com to cover the two HTTP starting points, and use the HTTP Headers Checker for the HTTPS variants. A mismatch, such as www redirecting to the bare domain while the bare domain redirects to www, is the classic loop.

Redirects and search engines

Crawlers follow redirects but, like browsers, prefer short chains. Each extra hop delays discovery and can cause crawlers to give up on very long chains. After a site move, keep permanent redirects in place for a long time, because links from other sites and bookmarks keep pointing at old URLs for years.

• Link internally to the final URLs, not to URLs that redirect.
• Make the canonical link element on each page match the final URL.
• Update sitemaps to list only final URLs.
• Use the domain migration checklist when moving a whole domain.

FAQ

Sources

• RFC 9110: HTTP Semantics, §15.4 Redirection 3xx
• MDN: Redirections in HTTP
• Google Search Central: Redirects and Google Search
• nginx documentation: return directive