Thirty sites, thirty footprints — am I overthinking the hosting side of this?

Building out to thirty properties this year and I've reached the part of the plan where I have to decide how paranoid to be about the hosting.

The received wisdom, which I've been repeating myself since about 2015, is one IP per site, different providers, different registrars, different everything. The received wisdom is also expensive and a nightmare to administer, and I genuinely do not know how much of it is still load-bearing versus how much of it is scar tissue from a 2013 penalty that nobody has re-tested since.

What are people actually doing at this scale in 2025? I'd rather be told I'm wasting money than find out in eight months.

Depends what you're running. Thirty sites that never link to each other or thirty sites in a wheel?

They link. Not in a wheel, but they link, and about eight of them point at the same two money sites.

Then the IP is the least interesting thing you own.

Thirty boxes at thirty providers with thirty IPs, all paid from the same wallet, all provisioned in the same hour, all running the same stack with the same PHP version and the same TLS cipher order, all with nameservers at the same registrar. You have not built thirty footprints. You have built one footprint with thirty addresses, and you've paid thirty times for it.

The correlatable surface is: billing, timing, software fingerprint, DNS, analytics IDs, cert issuance pattern, and the outbound IP of whatever you administer them from. IP diversity addresses exactly one of seven and it's the one that's cheapest to fake and cheapest to detect around.

Decide which of those seven you can actually vary before spending money on the one everyone talks about.

nullroute's list is right and I'd add the practical shape of what people actually do at thirty, because "all different" is not a plan anyone sustains past month four.

What tends to survive contact with reality is three or four clusters rather than thirty singletons. Say ten sites at ExtraVM, eight at Virtualine, seven at Servury, five somewhere else — different providers, different ranges, different billing, and crucially different dates, because you build the clusters over months rather than in one weekend.

Within a cluster you're not pretending they're unrelated. You're pretending they're an unremarkable small hosting account, which is what they are. Thirty separate accounts at thirty providers is anomalous in a way that ten normal-looking accounts is not, and the anomaly is the thing you're trying to avoid.

On providers specifically: ExtraVM from $3.50 with no documents on crypto payment is the workhorse for this and multiple regions helps. Virtualine is the price-per-performance pick at about €4 and takes Monero, with the old kycnot.me note about the billing panel being a nulled WHMCS copy — I keep that on the record but it hasn't caused anyone I know an operational problem. Njalla at €15 is triple the money and you'd only put the sites that matter there.

The variable I'd actually spend the admin effort on is the stack fingerprint, not the provider count. Three different web servers across the clusters costs you nothing but attention and breaks a correlation that IP diversity doesn't touch.

I have not run a network above about twenty properties, so treat the cluster sizes as a shape rather than a rule.

This is the answer. I'd only add: buy them in different months, from different browsers, and don't do the whole lot on the same afternoon because you finally had time.

Has anyone here actually had a network deindexed and traced it back to shared hosting? Genuinely asking. I've read the theory for years and never seen a post-mortem.

I had one in 2016 and I'd love to tell you it was the IPs, but honestly the sites were also terrible and interlinked like a spiderweb, so it proves nothing. That's sort of my problem with the whole doctrine.

FWIW the operational cost is the part that decides this, not the theory, and thirty single boxes is a lot more than three times the work of ten.

# if the answer to this is "manually", you do not have thirty sites, you have thirty problems
# how do you patch all of them the week a PHP CVE lands?
ansible -i inventory all -m shell -a 'php -v' 

Whatever topology you pick, pick one where a security update is one command. The network that dies isn't usually the one that got correlated, it's the one where six boxes stayed on an unpatched version for a year because nobody could face logging into them.

This. My friend lose four site in one week, not from Google, from someone who find old plugin.

And whatever you use to run that command becomes the single point that connects all thirty. There is no free move here, only trades you've chosen consciously and trades you haven't.

Three weeks on, in case it's useful to anyone reading this later.

Went with four clusters instead of thirty singletons, spread the buying across March and April rather than one weekend, and spent the money I saved on varying the stacks instead. Two web servers, three PHP versions, different cert issuers.

The thing I'd have got wrong without this thread is the billing. I was about to pay for all of it from one wallet on one day, which nullroute is right that I'd never have thought about, and which would have made the whole exercise theatre.

No idea yet whether any of it works. Ask me in a year and I'll probably still not know, which is the honest state of this entire discipline.