link-infrastructure

IP and ASN Resolution for Backlink Investigations

Palash Bagchi · Published September 15, 2026 · Updated September 15, 2026 · 17 min read

Short answer

Two backlink domains can use completely different IP addresses and still sit inside the same hosting company's network once those IPs are resolved back to an ASN. This piece covers what an ASN actually is, how IP-to-ASN resolution works in practice, and why a shared ASN means very different things depending on whether the host behind it serves millions of unrelated sites or a few thousand.

A backlink profile can pass the most obvious spam check and still be a private network in disguise. If twenty linking domains each sit on a different IP address, a naive audit calls that diversified — no shared server, no obvious red flag. IP and ASN resolution is the step that naive check skips: tracing each domain's hosting IP back to the Autonomous System Number (ASN) that controls it, which identifies the network operator, not the website owner, actually responsible for that block of addresses. Two domains with completely different IPs can still resolve to the same ASN, meaning the same hosting company or ISP sits underneath both — a pattern individual IP addresses alone will never show.

This isn't a replacement for the checks most backlink audits already run. It's a specific, narrow technique for one specific problem: linking domains that look infrastructurally independent but aren't. Understanding it means understanding what an ASN actually is first, because the term gets thrown around in SEO circles more loosely than the underlying networking concept supports.

What an ASN Actually Represents

An Autonomous System (AS) is not a website, a company brand, or a hosting plan. Cloudflare's own explainer puts it plainly: an AS is "a large network or group of networks that has a unified routing policy," typically run by an internet service provider, a large enterprise, a university, or a government agency. ARIN, the regional internet registry for North America, describes it in almost the same terms — one or more IP prefixes managed by network operators who maintain a single, clearly defined routing policy — and adds that organizations need an ASN mainly for two reasons: to control routing inside their own network, and to exchange routing information with other internet service providers.

Every AS controls a defined range of IP addresses — its IP address space, expressed as prefixes like 192.0.2.0/24 — and every AS is assigned a unique number, the ASN, so other networks can refer to it unambiguously. Cloudflare's own ASN, for example, is AS13335. ASNs come in two formats: an older 16-bit range running from 1 to 65,534, and a newer 32-bit range that extends numbering into the billions, introduced once the internet's growth started to exhaust the smaller pool. By Cloudflare's own estimate, more than 90,000 ASNs are in active use worldwide.

ASNs aren't handed out casually. They're allocated through a hierarchy: the Internet Assigned Numbers Authority (IANA) allocates blocks of ASNs to five Regional Internet Registries — ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC — based on demonstrated regional demand, and each registry then assigns individual ASNs to organizations that can show they operate an independent network with its own routing policy. IANA's own allocation records for RIPE NCC show this demand-based process running in practice, with fresh blocks handed down as each registry's available pool runs low. A small business running a website behind a single hosting account almost never needs or has its own ASN — it simply lives inside its hosting provider's address space, under the hosting provider's ASN.

That last point is the one worth sitting with, because it's the entire reason this technique works for backlink investigations. A domain's IP address tells you which specific machine, or shared server, it's hosted on. The ASN behind that IP tells you which organization — which hosting company, which ISP, which cloud platform — controls the network that machine sits inside. Those are two different layers of the same infrastructure, and a PBN operator who diversifies one without realizing they haven't diversified the other has left a trace that a simple same-IP check will never surface.

How IP and ASN Resolution Actually Works

Every network that wants to exchange traffic with the rest of the internet announces which IP address blocks it's responsible for, using the Border Gateway Protocol (BGP). Other networks' routers collect these announcements into routing tables that answer one question continuously: which ASN currently originates this IP address? IP-to-ASN resolution services are essentially a queryable index built on top of that same live BGP data.

Team Cymru's IP-to-ASN mapping service, one of the older and more widely embedded tools in this space, builds its index from BGP feeds pulled from dozens of peer networks and refreshed every few hours, filling in country code, registry, and allocation date separately from the regional registries' own records. It offers three ways to query: a WHOIS interface suited to bulk lookups piped through a single session, a DNS-based interface the service itself recommends for frequent, automated lookups because it carries less overhead and can be cached, and a plain web form for one-off checks. A single query returns the ASN, the BGP prefix that IP falls inside, the country code, the registry, and the allocation date — not geolocation, which the service explicitly warns shouldn't be inferred from the country field.

For a one-off manual check, Hurricane Electric's BGP Toolkit is the tool most network engineers reach for first: paste in an IP address, a prefix, or a domain, and it resolves the origin ASN and the organization behind it, alongside peering and routing detail. For automated pipelines that need to resolve thousands of linking-domain IPs at once, commercial IP intelligence databases fill the same role at scale. MaxMind's GeoIP2 ISP database, for instance, is built to resolve an IP address to its internet service provider, registering organization, and AS number in a single lookup, returning ISP name, organization name, ASN, and AS organization name together.

Applied to a backlink investigation, the workflow is mechanical:

  1. Pull the list of linking root domains from whatever backlink data source you're auditing.
  2. Resolve each domain's current DNS A record to an IP address — this is a live hosting lookup, not a WHOIS domain-registration lookup, and the two are frequently confused.
  3. Resolve each IP address to its origin ASN and AS organization name, using a bulk WHOIS/DNS service for volume or a one-off tool for spot checks.
  4. Group the linking domains by ASN rather than by raw IP address.
  5. Flag any ASN that recurs across multiple domains in the same suspicious cluster — particularly one already flagged for other reasons, such as templated content or a pattern of interlinking among the domains themselves.

The output of that process is a grouping that a raw IP list can't produce: domains that use twenty different individual addresses can still collapse into two or three ASNs once resolved, and that collapse is the signal.

Why This Matters for PBN Detection

Private blog networks exist specifically to manufacture the appearance of independent links pointing at one target site, commonly called the money site in PBN terminology, and operators running them are generally aware that hosting every domain on one server is an obvious tell. Search Engine Land's guide to PBNs describes the standard evasion: operators spread domains across different hosting providers, IP addresses, and registrars specifically to avoid detection. The same guide is direct about why this often fails anyway — running every domain on its own individual IP address gets expensive fast, which is why PBN operators frequently end up hosting several domains on one shared IP after all — and flags shared hosting as a tell in its own right, particularly when the sites in question mostly link to one another.

That evasion tactic and that tell are worth separating into two different claims. Sharing an IP is trivial to check and correspondingly trivial to avoid once an operator knows it's being checked. Sharing a hosting provider is a different, coarser claim — and it's the one ASN resolution actually tests. An operator can buy twenty hosting accounts at twenty different IP addresses and still be sitting inside four or five hosting companies, because reseller hosting is cheap, familiar, and doesn't require researching a new provider for every domain. Diversifying IPs takes one purchasing decision per domain; diversifying which company issues the IP takes real effort spread across unrelated providers, different signup flows, and often different payment methods — a meaningfully higher bar that a lot of PBN operators never clear, because the naive same-IP check was the only one they were optimizing against.

Ahrefs' own glossary entry for link scheme defines the category as an attempt to manipulate Google Search rankings using unnatural links, and separately calls out PBNs and paid links as the black-hat tactics most associated with manufacturing a link profile. Google's own spam policies don't name private blog networks by their common industry term, but the underlying tactics they list — using automated tools to generate links, or embedding links in widely distributed footers and templates — describe exactly the kind of link manufacturing PBNs exist to do (Google Search Central's spam policies).

To see how the resolution step changes what you'd otherwise conclude, consider a hypothetical link profile: twenty referring domains, no two sharing an IP address — a clean pass on the naive check. Resolve each of those twenty IPs to its origin ASN, and suppose fourteen of them turn out to sit inside the same small hosting reseller's network block. No two domains shared an IP. Fourteen of them shared an ASN. The operator diversified the layer that's cheap to diversify and left the layer underneath it untouched — not necessarily out of carelessness, but because reseller hosting at one company genuinely is the path of least resistance once you're managing more than a handful of domains.

Layer of evidence What you're comparing What it takes to defeat What it misses
Same IP address Exact IP match across linking domains Buy hosting under more than one account Nothing — this check stops at literally one server
Same ASN, different IP The network operator each IP resolves back to Move to genuinely separate hosting companies, not just separate accounts at one host Domains at unrelated companies that still share other footprint signals, like registrar or analytics IDs
Same ASN, weighted by hosting trust evaluation Whether the shared ASN is a small, low-diversity host or a large multi-tenant provider Nothing an operator can do directly — it's an evidence-weighting step, not a pass-or-fail check Whether the shared infrastructure is deliberate; it's still not proof of common ownership on its own

Hosting Trust Evaluation: Why a Shared ASN Isn't One Signal

Resolving a shared ASN answers one question — do these domains sit inside the same network operator's infrastructure — and immediately raises a second one: does that matter? The honest answer is that it depends entirely on which operator, and hosting trust evaluation is the step that turns a bare ASN match into something you can actually weigh.

Some ASNs sit behind an enormous, genuinely unrelated share of the entire web. W3Techs' web hosting market-share survey, which it updates daily, put Shopify at roughly 5.4% of all websites, Hostinger at 5.2%, Amazon at 4.5%, and Wix at 4.2% as of its mid-September 2026 snapshot — with GoDaddy Group and United Internet each around 2.5%. Those aren't small numbers: a single-digit percentage of all websites translates into tens of millions of domains sitting inside one company's IP address space, spanning every industry, language, and quality tier the web contains. Finding that two linking domains in a backlink profile both resolve to Amazon's or GoDaddy's ASN is close to meaningless on its own, precisely because so much of the ordinary, unrelated internet already lives there. Treating that kind of match as PBN evidence would flag an enormous share of entirely legitimate sites.

Hosting provider (ASN operator) Approx. share of all websites
Shopify ~5.4%
Hostinger ~5.2%
Amazon ~4.5%
Wix ~4.2%
GoDaddy Group ~2.5%
United Internet ~2.5%

Figures from W3Techs' web hosting market-share survey, which updates continuously — treat the specific percentages as illustrative of scale rather than a fixed number.

A small reseller with a few thousand total customers sits at the opposite end of that scale, and the same match means something different there. If several domains inside an already-suspicious cluster — thin content, a shared template, a pattern of interlinking mostly with each other — all resolve to one obscure host's ASN, the base rate argument flips: the pool of unrelated domains that could coincidentally land there is small enough that coincidence stops being the most likely explanation.

Independent reputation data can sharpen that judgment further, though it needs to be read carefully. Spamhaus's ASN-DROP list names ASNs its own researchers consider the worst of the worst — networks judged highly likely to originate or carry traffic for botnet infrastructure or other malicious activity. Spamhaus itself frames both its ASN- and IP-level DROP lists as coarse filters rather than a complete solution: being absent from the list is not a clean bill of health, and being on it doesn't damn every address inside that network equally. That caveat matters doubly here, because Spamhaus's abuse data is built around spam, malware, and botnet activity, not link schemes. A clean record on an abuse-reputation list doesn't clear an ASN of hosting a PBN, and a listed ASN doesn't prove any specific domain inside it is one. It's corroborating context for a hosting-trust judgment, not a substitute for one.

Spamhaus's own research on bulletproof hosting adds a further complication worth taking seriously rather than glossing over. It defines bulletproof hosting as service knowingly or tacitly kept running for customers who spam or otherwise engage in cybercrime, and its research notes that today's operators increasingly avoid concentrating in one identifiable network at all — instead spreading operations across resellers and IP brokers specifically to separate liability across companies that look unrelated on paper. The same fragmentation logic applies to a sophisticated PBN operator who's aware that ASN clustering gets checked: spreading domains across several genuinely separate small hosts defeats this technique just as thoroughly as spreading across IPs alone defeats the naive check. ASN resolution catches the operators who stopped one layer short of that, which in practice is a meaningful share of them — but not all.

Backlink intelligence platforms that publish their own authority figure alongside infrastructure signals run into the same weighting problem. bklink, for instance, calls its version of that score Rank rather than DR or DA, specifically because it's built from its own methodology rather than borrowed from either vendor — and a Rank number no more proves common ownership on its own than a shared ASN does. Both are inputs into a judgment call, not a verdict by themselves.

The Practitioner Toolkit, and Its Longer History

Checking whether linking domains share infrastructure isn't a new idea — it predates ASN resolution as commonly practiced in SEO by well over a decade, just at a coarser level. Majestic's Neighbourhood Checker, one of the longer-standing tools built for this, surfaces the most-linked-to domains sharing an IP address or subnet with a given site, letting an investigator judge whether the other sites on that address look reputable or look like a liability. Search Engine Journal covered the tool back when the underlying motive it served was already common knowledge: some site owners deliberately spread a network of blogs across a handful of different hosting providers specifically to keep search engines from noticing the connection.

That IP-neighborhood check operates at the subnet level: same server, or same block of adjacent addresses. ASN resolution is the same idea pushed up one layer of the stack, and it survives exactly the evasion that made the subnet-level check easy to beat — buying separate IP addresses, even separate subnets, at the same underlying host. For practitioners assembling a toolkit today, the practical division of labor tends to be: a free one-off lookup tool like Hurricane Electric's BGP Toolkit for spot-checking a handful of suspicious domains by hand, a bulk WHOIS or DNS interface like Team Cymru's for resolving a full link profile's worth of IPs in one pass, and a commercial IP intelligence database like MaxMind's for teams building this resolution step into an automated pipeline that runs continuously rather than on demand.

Where the Signal Breaks Down

None of this works as a standalone verdict, and it's worth being specific about why, because each limitation changes how much weight a resolved ASN match should actually carry.

Reverse proxies and CDNs mask the real origin server. A large share of the web, including plenty of entirely unrelated small businesses, sits behind Cloudflare or a similar reverse proxy, which means a routine DNS lookup resolves to the proxy's IP address and, in turn, the proxy's ASN — not the actual hosting company behind the site. Two linking domains that both resolve to a popular CDN's ASN are telling you they both use that CDN, which is true of a huge and unrelated swath of the internet, and nothing else. Before treating any ASN match as meaningful, it's worth confirming the resolved IP actually belongs to a hosting provider and not a proxy layer sitting in front of one.

Infrastructure ownership isn't static. Hosting companies get acquired, resell address space to other resellers, and migrate customers between network blocks. An ASN resolution run today reflects today's routing announcements, which may not match who actually controlled that address space when a given backlink was placed months or years earlier. Historical certainty about who hosted what, and when, is harder to establish than a live lookup suggests.

And the deliberate-fragmentation problem described above cuts against relying on this technique too heavily on its own: an operator sophisticated enough to know that ASN clustering gets checked can defeat it, the same way operators who learned about the same-IP check eventually defeated that one too. Detection techniques that work today narrow the pool of operators still exposed to them; they don't close it to zero, and they age as awareness of the technique spreads.

That's why IP and ASN resolution belongs inside a broader process rather than standing on its own. It's one specific technique within a backlink footprint audit — the wider practice of checking linking domains for shared infrastructure signals generally, including hosting, but also shared tracking codes, registrar patterns, and other fingerprints that survive even when IPs and ASNs don't line up. And that footprint work, in turn, sits inside the larger discipline of backlink intelligence: treating link quality as a body of evidence to be weighed, rather than a single score read off a dashboard.

Putting It Into Practice

A workable version of this looks like a pass, not a one-time verdict: resolve the IPs behind any cluster of linking domains that already looks suspicious for other reasons, group by ASN rather than raw IP, and weight whatever clustering shows up by how large and diverse the hosting operator actually is. A match inside a major cloud platform or hosting brand serving a meaningful share of the entire web is close to noise. A match inside a small, low-diversity reseller — especially alongside independent reputation signals or other shared footprint markers — is worth real scrutiny. Either way, treat the result as one input to combine with the rest of a footprint audit, not as the finding that ends the investigation by itself. The operators this technique catches are the ones who solved the easy problem — spreading across IP addresses — and stopped one layer short of solving the harder one underneath it.

Key takeaways

  • An ASN identifies the network operator, such as an ISP, hosting company, or cloud platform, that controls a block of IP addresses and announces routing for it via BGP, not the website owner using that IP.
  • IP-to-ASN resolution traces each linking domain's hosting IP back to its origin ASN, revealing when domains using different individual IPs still sit inside one operator's network.
  • PBN operators commonly diversify IP addresses to defeat a naive same-IP check without diversifying which hosting company or ASN they actually use.
  • A shared ASN is not uniform evidence: sharing a major host's ASN, some of which sit behind several percent of all websites worldwide, is weak on its own; sharing a small, low-diversity host's ASN is comparatively stronger.
  • Independent abuse-reputation data, like Spamhaus's ASN-level lists, can help with hosting trust evaluation, but it targets spam and botnet abuse rather than link schemes, so it is corroborating context, not proof.
  • Reverse proxies and CDNs can mask a domain's real origin IP, so a resolved match against a popular CDN's ASN usually shows nothing more than shared CDN use.
  • ASN resolution is one technique inside a broader footprint audit and should be combined with other shared-infrastructure signals before it is treated as evidence of common ownership.

Frequently asked questions

What is an ASN, in plain terms?

An Autonomous System Number identifies a network operator, typically an ISP, hosting company, or cloud platform, that controls a specific block of IP addresses and announces routing for that block using BGP. It identifies the infrastructure operator behind an IP address, not the website or business using it.

How is IP-to-ASN resolution different from a WHOIS domain lookup?

A domain WHOIS lookup returns registration details about a domain name, such as its registrar and registration date. IP-to-ASN resolution is a different lookup entirely: it takes a hosting IP address and returns which network operator's BGP routing announcement currently covers it, based on live internet routing data rather than domain registry records.

Can two backlink domains share an ASN without being related at all?

Yes, routinely. Large hosting providers and cloud platforms each control the infrastructure behind a meaningful share of all websites, so two completely unrelated domains sharing one of those providers' ASNs is common and, on its own, close to meaningless as evidence of anything.

What tools can I use to resolve an IP address to its ASN?

For one-off checks, Hurricane Electric's BGP Toolkit is a free public lookup tool. For resolving a full backlink profile's worth of IPs at once, Team Cymru's IP-to-ASN mapping service supports bulk WHOIS and DNS-based queries. Commercial IP intelligence databases such as MaxMind's GeoIP2 ISP database are built for teams that want to embed this resolution step into an automated pipeline.

Does finding a shared ASN prove a private blog network?

No. A shared ASN is corroborating evidence at most, not proof of common ownership. It needs to be weighed against how large and diverse the hosting operator is, and combined with other footprint signals, such as shared registrars, tracking codes, templates, or interlinking patterns, before it supports a real conclusion.

Why does diversifying IP addresses fail to protect a PBN from ASN resolution?

Because buying hosting at different IP addresses is a much lower bar than buying hosting from genuinely different companies. Reseller hosting at one provider is cheap and operationally simple, so operators who diversify IP addresses often stay inside the same handful of hosting companies without realizing that ASN resolution can still group their domains together.

How do CDNs or reverse proxies affect this technique?

A domain sitting behind a reverse proxy or CDN, such as Cloudflare, resolves to the proxy's IP address and ASN rather than its real origin server's. Two unrelated domains that both show the same CDN's ASN are telling you they use a popular service, not that they share a hosting relationship, and that needs to be ruled out before a match is treated as meaningful.

Is a shared ASN with a major cloud provider ever a useful signal?

On its own, rarely: major providers host too broad and unrelated a share of the web for a shared ASN alone to mean much. It becomes more useful only alongside other independent evidence, such as abuse-reputation data on that specific network or additional shared footprint signals tying the same domains together.

Sources

  1. 1. Cloudflare Learning Center - What Is an Autonomous System? What Are ASNs?
  2. 2. ARIN - Autonomous System Numbers
  3. 3. IANA - RIPE NCC ASN Allocations
  4. 4. Team Cymru - IP to ASN Mapping and WHOIS Lookup Service
  5. 5. Hurricane Electric - BGP Toolkit
  6. 6. MaxMind - GeoIP2 ISP Database
  7. 7. Search Engine Land - What Are PBNs? Risks, Rewards and SEO Implications Explained
  8. 8. Ahrefs - Link Scheme (SEO glossary)
  9. 9. Google Search Central - Spam Policies for Google Web Search
  10. 10. W3Techs - Usage Statistics and Market Share of Web Hosting Providers
  11. 11. Spamhaus - The Return of the ASN-DROP
  12. 12. Spamhaus - The Anatomy of Bulletproof Hosting: Past, Present, Future
  13. 13. Search Engine Journal - Do You Care Who Your Domain IP Address Neighbors Are?
Palash Bagchi

Written by

Palash Bagchi

Founder, Immortal Reality PA LLC

Palash builds bklink and leads product for Immortal Reality's AI infrastructure work, with a focus on making advanced systems easier to deploy, monitor, and trust.

Part of series

Backlink Intelligence & Infrastructure

Explore this series

Related articles