What you gain and give up by consolidating sites onto fewer IPs
Collapsing an estate onto fewer addresses is a genuine saving, and for a lot of portfolios it is the correct move. What it costs you is optionality: the sites you merge now share one fate, one public record and one migration whenever you want to pull one of them back out. Decide it per group of sites, not for the whole account at once.
What actually improves
The savings are real but they are not only financial, and the non-financial ones tend to matter more over a couple of years. A smaller set of addresses means fewer certificates approaching expiry, fewer reverse records to keep tidy, fewer entries in whatever you use for uptime checks, and fewer places to apply the same patch. Administration cost scales with the number of things you own, and most operators underestimate how much of their week that consumes.
What you give up
Each line in the left column has a matching line on the right. Read them as pairs rather than as two separate lists.
| What you gain | What you give up |
|---|---|
| One recurring charge instead of several | The freedom to cancel or downgrade one site without touching the rest |
| Fewer renewal dates, invoices and expiry alerts | Nothing, if your tracking was good. A lot, if it was not, since one missed renewal now takes the whole group offline |
| One set of certificates and DNS records to maintain | A shared blast radius: an outage, a block, or a suspension caused by one site lands on all of them |
| A single monitoring target and one place to patch | Discoverable adjacency, since anyone querying the address sees the full occupant list in one step |
| Simpler backups and a smaller restore drill | Slower separation later: selling or handing off one site means migrating it first, not just changing the invoice |
| Less time spent on estate admin overall | Weaker evidence that two properties are operationally independent, if you ever need to show that |
Worth being blunt about one thing: none of this is a ranking question in either direction. Separate addresses are a footprint and blast-radius control. Merging them does not cost you visibility, and keeping them apart does not buy you any.
When consolidating is clearly right
- The sites already read as one operation in public, cross-linked under a visible brand, with the same company name in every footer.
- They are all yours, with no client relationship and no plan to sell any of them individually.
- They are small and low-traffic, so a shared outage costs you a few hours of brochure traffic rather than orders.
- You bought separate addresses out of habit and have never been able to state what a shared one would break.
When it is clearly wrong
- Any site belongs to a paying client. Their neighbours become visible to them and to anyone who looks, and that is not yours to decide.
- One site is being prepared for sale. A buyer inheriting a shared address inherits an unwanted migration.
- The properties are meant to read as independent businesses. Shared hosting adjacency is the cheapest possible way to connect them.
- One site earns materially more than the others. It should not sit downstream of a neighbour you would not miss.
The question that settles most cases
For each pair you are thinking of merging, ask: if this address went dark for six hours tomorrow, or ended up on a shared block list because of the noisier site, would that be an inconvenience or an incident? Merge the inconveniences. Keep the incidents apart. Then repeat the question with money in it: what does an hour of downtime cost across the merged group, and does that number stay comfortably under what the extra address costs you per year?
Most estates land on a middle answer. One address carries the revenue site alone, one carries the cluster of small properties that already share a brand, and client work stays separate on principle. That shape is worth planning deliberately rather than drifting into; see network planning. If you are also choosing between a shared plan and your own machine, load decides that, not address count, so compare multi-IP hosting against a VPS on resources first.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.