Continuing the site-crawl series, I ran the free RankForge crawler against four developer-tooling sites — go.dev, nginx.org, gitlab.com, and typescriptlang.org — 10 pages each, starting from the homepage. The same-URL self-redirect pattern documented in prior installments (python.org, rust-lang.org, redis.io, cloudflare.com) showed up again here, more consistently than ever: 22 of the 23 tracked redirects across all four sites resolved to a URL identical to the one that was linked.
What I ran
No account needed, so this is reproducible:
-
POST https://rankforge.cc/api/analyzerwith{"seed_url": "..."}, then pollGET /api/analyzer/<id>untilstatusiscompleted. - The crawler follows internal links breadth-first from the seed, caps at 10 pages for the anonymous tier, audits every internal redirect to its final destination, and separately classifies every outbound external link as followed or nofollowed.
- Raw JSON for all four runs:
content/analyzer_20260927_<host>.json.
Same-URL redirects: 22 of 23, across every site
-
nginx.org: 3 of 3 tracked redirects are same-URL —
/en,/en/docs,/ruall 301 to themselves. -
gitlab.com: 8 of 8 — every tracked redirect on the marketing site (
/community,/ai-transparency-center,/customers,/demo-hub,/company,/de-de,/calculator,/dedicated) 307s to the identical URL it was linked from. -
typescriptlang.org: 8 of 8 —
/branding,/play,/download,/why-create-typescript,/community,/docs,/tools,/tsconfigall 301 to themselves. -
go.dev: 3 of 4 same-URL (
/learn,/doc,/talks), plus the one genuine exception this round:/securityis a real 2-hop redirect that lands on/doc/security— a real destination change, not a same-URL artifact.
Four installments and sixteen sites into this series now, and every single site checked has shown at least some same-URL redirect activity. It's clearly not a one-off quirk of any single CMS or framework — go.dev, nginx.org, gitlab.com, and typescriptlang.org don't share a stack, yet all four exhibit the identical pattern: internal links pointing at a URL that 30x-redirects to itself, typically because of a trailing-slash, locale-prefix, or HTTPS-canonicalization rule that fires on every request regardless of whether the linked URL already matches the canonical form.
gitlab.com also had a genuine orphan page
Unlike the last two installments (zero orphans each), this round surfaced one real orphan: https://about.gitlab.com/cloud-partner-marketplaces was reachable during the crawl but never linked to from any of the 10 pages crawled. A page a crawler can only find by already knowing the URL is invisible to normal site navigation — and to whatever share of search authority internal links would otherwise pass to it.
All 4 sites: still 0% of external links are nofollowed
Same finding as the last installment, now on a completely different site category (dev-tooling vendors instead of big consumer-tech platforms): across all four sites and all 40 crawled pages combined (917 total outbound external links: 552 go.dev, 25 nginx.org, 174 gitlab.com, 166 typescriptlang.org), every single one was dofollow — total_nofollowed_external came back 0 on every site, every time.
go.dev alone sent 284 dofollow links to github.com and 46 to pkg.go.dev; none of it nofollowed, even though a chunk of that traffic is effectively site-to-site navigation rather than a genuine third-party editorial citation.
Why this keeps showing up
Five installments into this series now (twenty sites total), the recurring theme hasn't changed: structural link-graph properties — same-URL self-redirects, orphaned pages, a site-wide absence of nofollow policy — are invisible from a normal page-by-page walkthrough. They only surface once something actually crawls the link graph and reads every link's real destination, status code, and rel attribute.
Try it on your own site
Same checks (orphan pages, near-orphans, internal authority distribution, redirect-chain hops, external nofollow audit) run in one pass, no signup: rankforge.cc/audit.
Top comments (0)