Redirect Audit

A 301 (or 308) tells browsers and search engines that the move is permanent: the new address should replace the old one. A 302 (or 307) means the move is temporary, so search engines may keep the old address. For http → https or www → non-www, a permanent redirect is the right choice.

Both work. What matters is choosing one, sending the three other variants to it in a single redirect, and using it consistently in your links, sitemap and canonical tags.

The HTML <link rel="canonical" href="https://example.com/page"> tag, placed in a page’s <head>, tells search engines which URL the site owner prefers when several addresses show identical or very similar content (for example, with or without www, or with tracking parameters).

It is not a redirect: visitors stay on the URL they requested. It is a search-engine signal, not a guarantee. A permanent 301 or 308 redirect is still preferable when an old address should actually send visitors to a new one.

In RedirectAudit, “Matches final URL” means the declared canonical matches the address reached after redirects. “Not declared” is not necessarily an error. A different, invalid or conflicting canonical should be reviewed; it may be intentional, but could send mixed indexing signals.

It happens when a variant goes through an intermediate address before reaching the final one, for example http://www → https://www → https://. It often comes from two separate rules (force HTTPS, then remove www). A single rule that sends every variant straight to the final address fixes it.

Not necessarily. A slow Time to First Byte (TTFB) delays the start of a page load, but a fast TTFB does not guarantee that the page appears quickly. Large images, CSS and JavaScript can still slow down rendering.

RedirectAudit measures the time from sending each HTTP request to receiving its response headers from Cloudflare’s network. This is a server-side approximation of TTFB, not a browser measurement. The final page’s response time contributes up to 20 points out of 100 to the redirect score; the time of individual redirect steps is reported separately. RedirectAudit does not measure the complete page load or visual rendering. For those, use Google PageSpeed Insights.

A site does not always answer every visitor the same way. Depending on the identity sent (the User-Agent), it may redirect phones to a mobile version, send visitors to a page in their language, or treat bots differently from people. Comparing identities shows these differences:

• Desktop and mobile browsers: check that phone visitors land on the same address, without an extra redirect.
• Googlebot and Bingbot: make sure search engines get the same redirects as visitors. Serving them something different can hurt indexing.
• Facebook, X and LinkedIn: these bots read the page to build the link preview. A redirect to a login page or a block gives a broken preview.
• GPTBot and ClaudeBot: see whether AI crawlers can reach the site, or whether a firewall rule blocks them.

The tool only changes the User-Agent header. Requests still come from Cloudflare’s servers, not from Google. A site that serves crawlers differently, or that verifies the real identity of bots, may respond differently. To see exactly what Google sees, use the URL Inspection tool in Google Search Console.

It depends on where your site is hosted. On Cloudflare, a single Redirect Rule can handle all variants. On Apache, use rules in the .htaccess file; on Nginx, a server block with return 301. Also check options that add their own redirect, such as Cloudflare’s “Always Use HTTPS”, which can create an extra hop.

Step-by-step examples are in the fix guides.

To keep the tool fast and spare the sites being checked, raw results are reused for two minutes (twenty seconds after a network error) for the same address and identity. The page shows how long ago the check ran. After fixing your redirects, click Re-check now to run a fresh test. The cache is per Cloudflare data center: a link opened elsewhere in the world may run a new test.

Security headers are HTTP instructions sent by the server to help browsers protect visitors. RedirectAudit checks five protections on the final page: HSTS (use HTTPS), CSP (restrict allowed resources), X-Frame-Options or CSP frame-ancestors (control embedding in frames), X-Content-Type-Options (prevent content-type sniffing), and Referrer-Policy (limit information shared with other sites).

“1/5 present” means one of these five protections was detected, not that the site is 20% secure. RedirectAudit checks header presence, not whether the values are properly configured or effective. A missing header does not necessarily prove a vulnerability. These findings are not included in the redirect score out of 100. Headers can usually be configured on your web server, hosting platform or Cloudflare; test changes carefully, especially CSP and HSTS.

See the security headers guide for ready-to-use examples.

The server may hide its PHP version (for example, with expose_php = Off) or may not use PHP at all. If PHP is used, hiding the version is a good security practice because it limits exposed technical information. However, it does not replace updates or other security measures and does not prove the site is secure.

No account is needed. Raw results are only kept for two minutes in Cloudflare’s cache. The checked domain is never sent to our analytics tools. Like any web service, requests may appear for a short time in Cloudflare’s technical logs.