Every conversation about running multiple websites lands in the same place sooner or later: how much distance between servers is actually enough? The stock answer - one site per C-class - has outlived the conditions that made it sensible. Hosting changed. Address markets changed. And the way search engines figure out that two properties belong to the same person moved past octet arithmetic a long time ago. What follows is how I’d approach subnet diversity for a small portfolio, sorting the measures that reduce real risk from the ones that just feel like progress. You want a threshold you can defend, not a rule you repeat because everyone else does.
What Subnet Diversity Actually Measures
A subnet, in hosting terms, is a contiguous block of addresses handed to an operator. The C-class is the final octet range sharing the first three. The B-class covers a wider span. Behind both sits an autonomous system number identifying the network announcing those routes, plus the physical building where the hardware actually lives. So when a host advertises a “unique IP”, that tells you almost nothing - thousands of unrelated businesses can hold unique addresses inside a single provider allocation. This is also where the shared and dedicated IP hosting stops being a marketing line and starts mattering to how your sites are seen.
Four layers of separation are worth pulling apart:
- Same IP - shared hosting or a single VPS running several sites
- Same C-class - adjacent addresses within one allocation
- Same ASN - different ranges, one announcing network
- Same registrar and DNS infrastructure - independent of any address
Search engines weigh relationships between properties. Not octet distance. Subnet proximity is a proxy signal at best. And CDN edge addresses legitimately repeat across enormous numbers of unrelated sites, which is a completely different situation.
Why the C-Class Rule Became Folklore
The advice made sense once. Back when shared hosting mapped neatly onto contiguous ranges, adjacent addresses reliably meant a shared account, or at minimum a shared box. Guessing ownership from the third octet was crude, but it worked.
Three things killed that assumption. IPv4 exhaustion turned addresses into a traded commodity, so blocks change hands through leasing and reseller markets with no corresponding change in who’s actually using them. Virtualisation and containers cut the link between a physical machine and an organisation, stacking dozens of unrelated tenants behind one allocation. And large operators keep subdividing and reassigning ranges continuously.
The rule survives because it’s trivially verifiable and easy to sell as a service tier. That’s it. Behavioural and relational signals replaced it, and those signals don’t care about the address at all.
The Footprints That Outrank IP Addresses
Want to know what actually links a portfolio? Look at the operational residue, not the routing table.
- Registrar and WHOIS patterns: identical contact records, bulk registration on a single date, sequential domain purchases
- Nameserver reuse: one custom NS pair serving an entire portfolio is a far louder signal than any subnet overlap
- Tracking identifiers: the same analytics property, tag container or advertising ID repeated across properties
- Stack fingerprints: matching themes, plugin sets, footer markup and error pages
- Linking topology: reciprocal patterns, recycled anchor phrasing, publication timestamps that cluster suspiciously
Tip: audit your own portfolio the way an outsider would - request each site as an anonymous visitor and diff the response headers. Server signatures, cookie names and caching directives give away a shared operator that no address lookup would ever surface.
How Far Is Far Enough: A Practical Threshold
Separation requirements scale with portfolio size. A handful of properties needs little beyond basic hygiene. A mid-sized network benefits from genuinely different providers. An editorial group with shared staff and shared systems is going to leak connections no matter where it’s hosted, so the effort belongs somewhere else entirely.
For most small networks, two or three distinct providers on genuinely distinct ASNs beat a dozen scattered addresses pulled from one reseller pool. Once you get past a handful of properties the arithmetic changes, and it helps to work out addresses a fifty-site network needs before committing to a purchase. Work in this order:
- Identify every surface a shared operator touches
- Separate the loudest layer first, usually DNS or registrar data
- Move down through provider, then stack, then content operations
Returns drop off fast. Past provider and DNS separation, extra spend buys you less than the same money put into editorial quality. And when the properties openly belong to one brand? Separation is theatre with a hosting invoice attached.
Legitimate Reasons to Spread a Network Across Providers
Take search out of the picture and the case for diversity gets stronger, not weaker. A single provider outage, a routing incident or an ASN-level block should never take a whole portfolio down at once. That resilience argument stands on its own, no SEO justification needed.
The other reasons are just as concrete. Audiences in different markets benefit measurably from regionally appropriate infrastructure, because latency compounds across every single request. Shared platforms expose you to neighbour effects too: abusive tenants, mail ranges landing on blacklists, crawl rates throttled because of somebody else’s behaviour. Billing risk is real as well - one account suspension over a payment dispute can cascade through every property tied to it. And data residency or compliance obligations can turn provider choice into a hard requirement rather than an optimisation, especially where personal data crosses jurisdictions.
Building the Separation Without Wasting Budget
Spend in priority order: provider and ASN first, then nameservers, then registrar spread, then contact and analytics hygiene. Everything below that line is optional, and if you would rather hand the setup to someone who does it daily, that is what our hosting and network services are built for.
Go with provider-managed DNS per site, or an independent DNS operator, rather than one custom nameserver pair fronting the lot. That pair is the single easiest way to tie a portfolio together, and I’ve seen it undo an otherwise careful setup. Stagger registrations and renewals too, instead of buying the whole portfolio in one checkout.
Tip: maintain separate analytics properties and never reuse one container ID across the network.
Tip: vary the technical stack wherever variation is cheap - different themes, different comment handling, different image pipelines. Small divergences add up.
Tip: document which layers you deliberately share and why, so a future audit doesn’t waste days chasing ghosts you already decided to live with.
Where Subnet Obsession Goes Wrong
The classic failure: paying for scattered hosting while publishing identical thin content everywhere. Infrastructure separation protects nothing when there’s nothing worth protecting, and the pages give the game away long before anybody bothers to examine routing.
Operational fragility comes right behind it. Lots of small accounts means missed renewals, patchy updates and sites that quietly go orphaned. Security debt piles up when every isolated host runs its own update schedule with nobody watching centrally - one neglected installation drags down the reputation of everything around it.
Then there’s the internal linking trap. Heavy cross-linking between properties, recycled anchors, coordinated timing - that undoes every dollar spent on separation in a single afternoon of publishing.
Tip: make each property survive on its own traffic before it joins the portfolio at all.
Closing Assessment
The threshold isn’t complicated. For a small network: separate providers, separate DNS operators, then stop optimising addresses and start optimising what visitors actually read. Past that point, address arithmetic is busywork dressed up as strategy.
Subnet diversity is a hygiene item. It removes a weak correlation signal and gives you genuine resilience against outages, suspensions and noisy neighbours, which justifies the modest cost. What it can’t do is rescue properties that exist only to link to each other.
The protection that lasts is unglamorous: sites a reader would visit on purpose, because they’re worth visiting. Before you buy more hosting, run a relational audit of what you already own - registrar records, nameservers, tracking IDs, linking patterns. Nine times out of ten the results show the money belongs somewhere other than a new server, usually in the kind of groundwork covered in our SEO writing.
