The common misconception
SEO tools often display backlink data as a simple domain relationship: example.com links to yoursite.com. That shorthand is useful for discovery, but it hides the actual evidence.
A referring domain is an aggregate relationship between two domains. Under that aggregate can be one real editorial citation, hundreds of duplicated template links, generated documentation, badges, nofollow links, scraper pages, or links to completely different URLs on the target site.
A referring domain is a lead before it is evidence
The domain-level graph says a relationship exists and may be worth investigating. It does not tell us which page linked, which target URL was linked, what the anchor said, whether the link was nofollow, or whether the source page was HTML.
Page-level enrichment is the follow-up step. It turns the edge into rows a human can audit: source page, target URL, anchor text, follow state, bucket, and link type.
The evidence underneath the github.io -> github.com edge
In the domain graph, github.io -> github.com is one relationship. In the archived HTML, that one relationship expands into 7,214 fetched HTML pages, 3,950 source pages with at least one GitHub link, 17,678 observed link occurrences, and 9,459 distinct target URLs.
The domain edge tells us where to look. Page-level enrichment tells us what was observed: the source page, the target URL, the anchor text, the follow state, the link type, and whether the occurrence is a content link or a technical artifact.
We also ran the same uncapped enrichment for gitbook.io, webflow.io, and readthedocs.io. The contrast matters: some referring domains behave like dense documentation networks; others have many crawlable pages but comparatively few observed target links.
| Referrer | HTML fetched | Source pages | Occurrences | Target URLs | Content / noise / technical | Top target |
|---|---|---|---|---|---|---|
| github.io | 7,214 | 3,950 | 17,678 | 9,459 | 16,234 / 1,345 / 99 | github.com/rust-lang/rust/issues/88674 |
| gitbook.io | 649 | 169 | 5,687 | 3,515 | 5,680 / 7 / 0 | github.com/0xProject/0x-mesh/releases |
| webflow.io | 8,192 | 237 | 407 | 102 | 346 / 52 / 9 | github.com/ |
| readthedocs.io | 79 | 75 | 174 | 59 | 167 / 7 / 0 | github.com/scverse/anndata |
linked to github.com/040code/blog-oidc-github-actions-aws
linked to github.com/0xProject/0x-mesh/releases
linked to github.com/wonderunit/font-thicccboi
linked to github.com/scverse/anndata
How we counted, and what the buckets mean
For each referrer we queried Common Crawl's CDX index for candidate HTML captures in CC-MAIN-2025-51, fetched the archived WARC byte ranges, parsed the HTML, kept links whose target resolved to github.com, and grouped them by source page, target URL, link type, rel state, and classification bucket. These are archived crawl observations, not live verification checks.
The buckets are deliberately neutral. Content means a normal HTML anchor found in page content or structure -- it does not imply an earned editorial citation, only a real, non-boilerplate link. Noise means low-signal links: nofollow, empty-anchor, or links from low-quality referrers. Technical means non-anchor references such as image, script, and stylesheet links pointing at the target.
What surprised us
Reading the same enrichment across four referrers turned up patterns the domain edge alone would never show:
- Crawl volume is not backlink-evidence volume. webflow.io had the most HTML fetched (8,192 pages) yet produced only 407 GitHub link occurrences -- far fewer than github.io (17,678) or gitbook.io (5,687). More archived pages did not mean more links.
- Documentation platforms are dense. gitbook.io produced 5,687 occurrences from just 169 source pages -- about 34 GitHub links per page -- because generated docs cross-reference repositories heavily.
- The split skews to content. Across every referrer, the large majority of occurrences were normal content anchors, not assets or nofollow noise -- the signal is real, but it still needs ranking, not just counting.
Why the distinction matters
If an agency tells a client they gained or lost a referring domain, the next question is obvious: what actually happened? A domain-level edge can help prioritize that question, but it cannot answer it by itself.
For github.io, the underlying evidence is thousands of observed occurrences across thousands of source pages and thousands of GitHub target URLs. Some are useful content references. Some are navigation, generated documentation, badges, or other technical artifacts. Treating all of that as one backlink loses the part a client can actually inspect.
How Linkwake uses Common Crawl without pretending it is a backlink API
Common Crawl's domain graph tells us where to look at web scale. It is excellent for discovery, churn, and competitor gap analysis. But it does not hand over a neat backlink API with source URLs, anchors, and verification state.
For page-level evidence, Linkwake has to do more work: query the CDX index for candidate HTML pages, fetch the archived WARC byte ranges, parse the HTML, extract matching links, classify the occurrence, and store the evidence separately from the domain graph.
The product point
Domain-level data is useful for discovery. Page-level enrichment is what turns discovery into evidence.
Linkwake's workflow is domain-level churn -> page-level evidence -> filtering -> verification -> action. The graph points us at movement. The enriched occurrence table shows what was observed and what is worth checking next.
A referring domain is a lead, not an answer. Counting backlinks tells you a relationship may exist; auditing the evidence underneath it -- source pages, target URLs, anchors, rel states, and link types -- tells you whether it matters. That is the difference between where Ahrefs- and Semrush-style summaries stop and where Linkwake begins.