PBN & footprints
What "footprint-free" PBN hosting actually means
A footprint is any signal that links your sites to each other or to a hosting pattern search engines have learned to distrust — here is where those signals hide and how we design them out.
A footprint is a correlation, not a single tell
"Footprint-free" gets used loosely, so it is worth being precise. A footprint is any signal that lets a third party — a search engine, a competitor running a tool, a manual reviewer — group your sites together, or group them with a hosting pattern that is already associated with manipulation. Deindexing rarely comes from one damning artefact. It comes from correlation: a dozen sites that individually look fine but share the same generator tag, the same nameserver pair, the same /24, the same theme fingerprint and the same publishing cadence. Any one of those is noise. Stacked, they are a network.
That reframes the whole problem. You are not hunting for a single thing to hide; you are trying to break correlation across every layer at once — the HTML the site emits, the network path it resolves through, the account that fronts it, and the blast radius it shares with its neighbours. Miss a layer and the others still line up. This is why bolting a CDN in front of a cheap shared box does almost nothing: it changes one variable while leaving the on-site fingerprint, the DNS pattern and the shared-fate isolation identical across the estate.
On-site footprints: what the HTML gives away
The cheapest footprints to detect are the ones a site announces in its own output. A default WordPress install broadcasts its version in a meta generator tag and in the query strings on its assets, links out to wp-json discovery endpoints and an XML-RPC interface, ships pingback headers, and returns an X-Powered-By header naming the stack. None of that is visible to a human reader, but all of it is trivially scriptable — you can fingerprint ten thousand sites for these tells in an afternoon.
Our footprint remover strips exactly this surface on every deploy: the version and generator tag, the discovery links, XML-RPC, pingbacks and X-Powered-By all come off, so each site presents a clean, generic surface rather than a WordPress-shaped one. Because it runs as part of the deploy rather than as a one-time cleanup, a plugin update or a theme change cannot quietly reintroduce a header you thought you had removed. The point is not secrecy for its own sake — it is denying the cheapest, most scalable correlation signal there is.
Theme and structure fingerprints matter too. A network where every site is the same theme with the same widget layout and the same footer text correlates on layout alone. Static-HTML delivery helps here: serving a site as flat HTML removes the live-stack tells entirely and lets each site's markup stand on its own.
Network footprints: IPs, CDNs and DNS
The layer most operators get wrong is the network. Hosting a hundred sites on one box puts them on one IP, in one /24, behind one reverse-DNS pattern — a textbook cluster. Spreading them across a handful of servers you own barely helps, because a small pool of IPs is still a pool. And routing everything through a single CDN account, or a single DNS provider, simply moves the cluster up a layer: now the correlation is the account, or the nameserver set, instead of the IP.
Footprint-free network design means distribution across many accounts and many providers, not one. Our CDN and DNS account pools spread sites across multiple Cloudflare, bunny.net, CDN77 and KeyCDN accounts and across DNS providers including ClouDNS — and you can bring your own accounts into the pool as well. The distribution is recomputed from live account state at every deploy, so as the estate grows it does not quietly drift into a cluster on whichever account happened to be default. Origin IPs sit behind the CDN, so the server actually serving the content is never the thing a lookup returns.
The word doing the work there is pool. A footprint-free network is not one clever hiding place; it is enough independent surfaces, assigned with enough intent, that no single account, nameserver or subnet accumulates a suspicious share of your sites.
Why footprints must be managed per deploy, not set once
Networks are not static. You add domains, retire others, migrate a batch in, change a theme, move a tier. Every one of those events is a chance for a footprint to creep back — a re-enabled XML-RPC endpoint, a new site landing on an over-used CDN account, a restored backup carrying an old generator tag. A footprint audit that was clean at launch is worthless six months and two hundred deploys later.
This is why we treat footprint management as a property of the deploy pipeline rather than a checklist you run occasionally. The on-site removal, the account-pool balancing and the plugin baseline are reapplied every time a site is provisioned or changed, computed against the current state of the estate — not against a snapshot from setup. Balance is recalculated from live account data at each deploy, so the hundredth site is placed with full knowledge of where the previous ninety-nine went. Set-and-forget is the failure mode; continuous, per-deploy enforcement is the fix.
Shared-fate isolation: the footprint of collapse
There is a footprint that only shows itself under stress. If a hundred sites share one filesystem and one PHP pool, then one compromised site, one runaway process or one resource spike takes the neighbours down with it — and a whole subnet going soft-404 or slow at the same moment is itself a correlation signal, quite apart from the malware or the outage. Shared-fate hosting turns a single-site problem into a network-wide event.
Per-site isolation puts every site inside its own containment boundary so one site cannot reach another's files, processes or memory, with malware scanning and DDoS protection on by default. That protects the sites you did not touch from the one that got hit, and it also means the estate does not fail as a block — which is both an availability property and, quietly, a footprint one. Caching plays a related role: with LiteSpeed Enterprise and a per-site object cache absorbing most traffic, a spike on one site rarely becomes a resource event that ripples outward in the first place.
Bringing aged domains back without importing their footprint
Aged expired domains are a staple of network building, and they carry their own footprint risk. Rebuilding one from a generic template throws away the very history that made the domain worth acquiring, and a cluster of expired domains all rebuilt on the same skeleton correlates on that skeleton. The cleaner approach is to restore the domain's original site from the Internet Archive and serve it as static HTML — the fastest route to getting an aged domain back online and re-indexed with its own real structure rather than a network-standard one.
Restoring as static HTML has a footprint dividend too: there is no live CMS to fingerprint, no version to leak, no discovery endpoint to probe. The site presents as what it historically was. Combined with account-pool distribution and per-deploy on-site removal, a revived domain rejoins your network without inheriting the tells that would have grouped it with the rest of it.
None of this is exotic. Footprint-free hosting is just the discipline of breaking correlation at every layer — HTML, network, account, isolation and history — and re-enforcing it on every change, at the scale of a real network rather than a handful of sites.
Frequently asked questions
Does putting a CDN in front of my sites make them footprint-free?
No. A single CDN account in front of a shared server changes one variable — the IP a lookup returns — while leaving the on-site fingerprint, the DNS pattern and the shared-fate isolation identical across every site. Worse, routing a whole network through one CDN or DNS account just relocates the cluster to that account. Footprint-free design needs distribution across many accounts and providers, on-site removal, and per-site isolation working together, not a single proxy layer.
What on-site footprints does the footprint remover actually strip?
On every deploy it removes the WordPress version and generator tag, the wp-json discovery links, XML-RPC, pingbacks and the X-Powered-By header — the cheap, scriptable tells that let anyone fingerprint a WordPress estate at scale. Because it runs as part of the deploy rather than as a one-off cleanup, a plugin or theme update cannot quietly reintroduce a signal you had already removed.
Why does footprint management have to happen on every deploy?
Because networks change constantly — new domains, migrations, theme swaps, tier moves — and each change is a chance for a footprint to creep back or for a new site to land on an over-used account. A footprint audit that was clean at launch is meaningless after hundreds of later deploys. We reapply on-site removal, account-pool balancing and the plugin baseline on every provisioning event, computed against the live state of the estate rather than a setup-time snapshot.
Can I use my own Cloudflare or CDN accounts instead of your pool?
Yes. You can bring your own CDN and DNS accounts into the pool alongside ours, and distribution is still recomputed from live account state at every deploy so nothing drifts into a cluster. This suits operators who already hold aged or trusted accounts they want kept in rotation.
Related
Try it free for 7 days
Spin up your first sites free for 7 days — no card. Moving an existing network? Your first migration is on us.
Start free