What Counts as One Referring Domain

Referring domains is the most trustworthy headline number in link reporting, for the reasons in referring domains versus total backlinks. It is also the number whose definition nobody checks. Before you can count distinct websites, something has to decide what a website is, and that decision is a rule applied to a string.

Change the rule and the count changes, on identical data, without a single link being gained or lost.

Three rules, three different counts

Count hosts. Every distinct hostname is one referring domain. blog.example.com, shop.example.com, and example.com are three.

Count registrable domains. Fold every host up to the name someone registered. Those same three are one.

Count registrable domains with exceptions. Fold up to the registered name, except where the registered name is a hosting platform, in which case treat each customer subdomain as its own site. alice.example-blogs.com and bob.example-blogs.com become two, not one.

The third rule is what most people actually mean by “distinct websites,” and it’s the hardest to implement, because the exception list is the entire problem.

The mechanism: public suffixes

The boundary between “part of the registry” and “part of someone’s site” is not derivable from a hostname. co.uk is a registry suffix; example.co.uk is a site. Nothing in the string says so.

The published answer is the Public Suffix List — a community-maintained list of the suffixes under which names are registered, covering both country structures like co.uk and com.au and platform suffixes that hosting providers have submitted so that each customer subdomain is treated as a separate site. It’s the standard input for anyone computing “registrable domain plus one label,” and it’s why browsers can tell that two subdomains of a shared platform are different origins for cookie purposes.

Three things follow, and all three show up in link data:

The list is incomplete by construction. A platform only appears on it if someone adds it. New site builders, regional blog hosts, and internal subdomain-per-tenant products often aren’t there, so their customers get folded into one referring domain.

Vendors may use it, a variant of it, or their own list. None of them publishes the exact version and date in effect for your export.

It changes. Entries get added. A count computed with this month’s list is not strictly comparable to last month’s, which is one more member of the family of moves described in when a metric moves but nothing changed.

Where the counts diverge most

Platform-heavy profiles. If a large share of your links come from blog hosts, forum platforms, code-hosting pages, or storefront subdomains, the host-versus-registrable choice can move your referring-domain count by a substantial fraction. Hypothetically: 600 rows at host level collapsing to 410 at registrable-domain level, because 190 of them sit on four platforms. Same links, two defensible counts, a 32% difference. (Illustrative figures, not measurements.)

Large organisations with many subdomains. A university, a government body, or a multinational with per-country and per-department subdomains. Host counting reads these as dozens of independent sites; they’re one institution making one decision about you. Folding them up is nearly always the more honest reading here — and the opposite of the right answer for the platform case.

Internationalised domains. The same site reachable as an IDN and as its punycode form, or across country-code equivalents. Whether these normalise to one row depends on the vendor.

Country second-level structures. Any rule that just takes the last two labels turns example.co.uk into co.uk and merges every British site into a single referring domain. Naive implementations do this, and it’s obvious when it happens because one row will have an absurd link count.

Why this is worth ten minutes

It explains a specific class of discrepancy that otherwise looks like a coverage difference. If two tools report referring-domain counts that differ far more than their link counts do, the boundary rule is a likelier cause than the crawl — and that’s testable, because it predicts the exclusive rows will cluster on platforms rather than spread evenly. That test is a variant of the overlap procedure in benchmarking two link indexes.

It also changes what a comparison means. Comparing your referring domains to a competitor’s is only valid if both counts used the same boundary rule — which they did, if you pulled both from the same tool on the same day with the same filters, and may not have otherwise. The filter-state discipline in sampling, export caps, and missing rows applies to this as much as to row limits.

Doing it yourself

If the count matters enough to defend, compute it from a link-level export rather than reading the vendor’s aggregate:

1. Extract the host from each source URL. Lowercase it, strip a leading www., strip a trailing dot.
2. Reduce to the registrable domain using a public-suffix implementation. Do not split on the last two labels.
3. Keep both columns. Host and registrable domain, side by side. You now have both counts and can report either with its rule named.
4. Look at the biggest collapses. Sort by how many hosts folded into each registrable domain. The top of that list is either a hosting platform you should be splitting or an organisation you should be folding — and you can only tell by looking.
5. Decide once, write it down, keep it. The rule belongs next to the number, in the provenance line described in building a link report you can defend.

Step 4 is the one that pays. It takes a couple of minutes and it’s how you find out that a fifth of your “distinct websites” are subdomains of one platform — a fact that changes the interpretation of the profile far more than the count does.

What this is not

It’s not a quality judgment. Two hundred domains folded from one platform aren’t worthless, and one institution’s forty subdomains aren’t a link scheme. The boundary rule decides how you count, not how you value. Valuation needs the composition view, and it needs the assumption checked in unique IPs and Class-C metrics, which failed for exactly this reason: a network-level proxy for independence stopped tracking independence once shared hosting became normal.

What nobody outside the vendor knows

Which suffix list each vendor uses, at what version, with what private additions, and when it last changed. Whether subdomain folding is applied at index time or query time. Whether the aggregate count in the interface uses the same rule as the export you download.

The durable part is the question, and it’s worth asking out loud the next time a referring-domain figure gets quoted: one referring domain according to which rule?