Redirect Trace Report · Grade A
github.com
Latest redirect trace for https://github.com. We followed every Location header up to a 200 response and recorded each hop's status code and timing.
Last updated 1 month ago
Key findings
What the redirect trace tells you about github.com
Every URL on the public web has exactly one canonical landing point — but the path from the first request to that landing point is where SEO equity page-load latency and HTTPS security guarantees quietly leak away usually without anyone noticing until a technical audit catches it.
com follows every Location header in sequence until it reaches a 2xx response and records the status code target URL and elapsed time of each hop along the chain. com we recorded 1 in the chain. The total elapsed time across the chain was 36 ms. com is http 200.
com which is the address that appears in Google's index the URL that gets the canonical authority and the URL that every share button or copied link resolves to. com creates a conflicting signal that costs you indexation authority.
Why redirect quality matters more than people expect
5-second Largest Contentful Paint (LCP) budget and into the needs improvement band for Core Web Vitals. com correctly terminates the chain on HTTPS which ensures the final response is encrypted and browsers don't show a Not Secure warning. The canonical hostname in the chain settles on the apex domain variant.
This should exactly match the preferred domain in Google Search Console and the hostname used in your canonical tags and sitemap — even a www vs. apex mismatch between these signals causes Google to pick its own preferred URL rather than yours.
The choice of redirect status code carries lasting SEO consequences: a 301 (permanent) or 308 (permanent method-preserving) passes essentially full PageRank to the destination and tells Google to consolidate ranking signals within a few crawl cycles.
A 302 (temporary) or 307 (temporary method-preserving) tells Google the original URL is still the canonical one and to keep its index entry — meaning a domain-wide migration served as 302s leaves the old URLs in the index for months diluting authority across both the old and new addresses.
What an A-grade redirect chain looks like for github.com
Best practice in 2026 is a single 301 from every non-canonical form of the URL to the one canonical form — and that's it. com). The goal is to collapse all of these into a single 301 that lands on the correct canonical form in one hop never two or three.
Double-hopping — where http → http-www → https-www instead of http → https-www in one step — is still present on roughly a third of audited domains because the HTTP-to-HTTPS redirect and the apex-to-www redirect fire as separate rules in sequence rather than being combined.
com's origin server make sure only one layer enforces HTTPS — the most common cause of redirect loops we surface is the CDN enforcing HTTPS and the origin also trying to redirect HTTP creating a cycle.
Trailing-slash consistency matters for internal links and search indexing: pick one convention (trailing slash or no trailing slash) and enforce it via a single redirect rule across every URL in the site so Google never sees two addressable versions of the same page.
Once the chain is collapsed to one hop update the canonical tag the XML sitemap and the Search Console preferred domain to all point at the same destination URL — then re-run this report to confirm the chain reflects the change.
js rewrites) are the right mechanism; JavaScript-based redirects and meta-refresh redirects both prevent the browser from pipelining requests and add additional latency on top of the hop cost.
Benchmark and migration playbook for github.com
Across the sites we audit the median domain serves exactly one redirect hop on entry — the HTTP-to-HTTPS upgrade — and that's the right answer.
But the long tail is significant: roughly a third of audited domains double-hop because their apex-to-www rule and their HTTPS rule fire independently and a meaningful minority chain three or more hops because trailing-slash enforcement HTTPS enforcement and www-to-apex enforcement each add a hop rather than being combined.
Every extra hop above the single-hop ideal is dead latency added to every cold-cache first visit and a small fraction of PageRank lost in transit — each 301 is widely understood to pass slightly less than 100% of link equity to the destination and that haircut compounds across a three- or four-hop chain.
com: (1) decide the single canonical form — apex or www trailing slash or no trailing slash — and document it explicitly; (2) write a single redirect rule that takes any starting variant directly to the canonical form in one hop rather than chaining separate rules; (3) if a CDN sits in front of the origin assign the HTTPS enforcement to the CDN only and remove any corresponding origin-side redirect to prevent the loop; (4) update the canonical tag in the page the XML sitemap URLs and the Search Console preferred domain setting to all match the canonical destination exactly; (5) if you are mid-migration from one domain to another serve 301s from every old URL to the corresponding new URL and submit the old sitemap for removal in Search Console so Googlebot re-crawls on the new destination.
Redirect rules are among the first things a platform or hosting migration breaks and the last things anyone thinks to test post-launch so re-run this report immediately after any infrastructure cutover and configure a redirects monitor to detect an unhealthy chain on the cadence available to your plan.
Related reports for github.com
Each tool runs an independent check. Combine them into a single dashboard at /check/github.com.