Hosting for affiliate sites: how many sites per plan?

Hosting for affiliate sites is hosting sized by how many independent niche sites a plan can run without one of them starving the others - not by how much traffic those sites get. A static comparison page and a WooCommerce review store consume wildly different CPU, memory, and database capacity even at identical visitor counts. As a rough rule, a shared multi-site plan comfortably holds anywhere from a handful to well over a hundred landers depending entirely on what each site is built with - the number on a pricing page is a starting point, not a physics law.

This matters because most affiliate marketers buy hosting the way they buy a domain: by the count. Ten sites, fifty sites, a hundred and fifty sites - the plan names practically beg you to think in units. But a shared plan doesn't allocate resources per site name, it allocates PHP workers, memory, and database connections across whatever is actually running at that moment. Get the mix wrong and the tenth site can feel slower than the first, even though nothing about your plan changed.

What actually limits how many sites fit on one plan

Three things determine the real ceiling, and none of them is disk space:

• PHP worker processes. Every dynamic page request (WordPress, a PHP redirect script, a server-side tracking pixel) ties up a worker for the duration of the request. A shared pool has a finite number of workers; if they're all busy, the next visitor - on any site in the account - waits.
• Database connections and query load. A static HTML lander touches no database. A WordPress site with a plugin-heavy stack can run a dozen queries per pageview. Multiply that by concurrent visitors across several sites and the database, not the CPU, is usually the first thing to bottleneck.
• Cacheability. A page that can be served from a full-page cache costs almost nothing per repeat view. A page with per-visitor dynamic content (live pricing tables, geo-targeted offers, logged-in states) has to be regenerated every time, which multiplies the first two costs.

Our own tiers are sized against a realistic mix of the first two rows, which is what most niche-site portfolios actually look like - a handful of content hubs and a lot of lightweight comparison pages. If your portfolio leans toward the bottom two rows, treat the site count on any plan, ours included, as a ceiling to plan around rather than a target to fill.

When one slow lander drags down the rest

The "noisy neighbor" problem isn't really about neighbors - it's about one site on your own account suddenly needing more than its share. A launch-day traffic spike to one WooCommerce store, a plugin update that turns a cached page into an uncached one, or a bot crawling every URL parameter on a quiz funnel can each quietly consume the worker pool that your other nineteen landers were counting on. The fix is process isolation per site (so one site's overload can't starve another's workers) plus catching the heavy site early and either optimizing its caching or moving it to a plan with dedicated capacity.

Does shared hosting hurt my rankings?

Not directly. A shared IP address or a shared hosting account is not itself a ranking signal - search engines don't average quality scores across every site that happens to share infrastructure. What can hurt rankings is anything that degrades page speed, and an over-stuffed or badly isolated shared plan is a common, avoidable cause of exactly that: slow Time to First Byte, poor Largest Contentful Paint, visitors bouncing before the page finishes rendering. The honest framing is that shared hosting is fine; shared hosting without proper per-site isolation is the actual risk, and it's a hosting-configuration problem, not a law of shared infrastructure.

Do I need separate IPs per site?

Almost never, for the hosting side of things. Modern TLS uses SNI (Server Name Indication), so dozens of domains - each with its own automated, free certificate, or one wildcard certificate for subdomains of a single root - can share one IP address without any warning or downgrade for visitors. Search engines don't require a unique IP per site either. Separate IPs occasionally matter for outbound email sending reputation, but that's a mail-server concern, not a web-hosting one, and it has nothing to do with how many landers you run on a plan.

SSL and domain economics: the wildcard math

If your portfolio is many subdomains under one root domain (niche1.yourbrand.com, niche2.yourbrand.com), a single wildcard certificate covers all of them - one thing to manage, zero incremental cost per new subdomain you spin up. If instead your portfolio is many separate root domains (the more common pattern for niche-site builders, since exact-match domains matter for SEO and brand separation), each domain gets its own automated certificate. That's still free and automatic on modern hosting, but it is more things to track - which is exactly what a proper multi-site dashboard should be doing for you, not something you should be renewing by hand.

When you should split hosting accounts entirely

Keep everything on one plan until one of these becomes true:

• Resource mismatch. One site (a real store, a heavy funnel) would otherwise crowd out a dozen lightweight ones. Give it its own capacity instead of hoping the shared pool copes.
• Blast-radius risk. If a compromised plugin or a leaked credential on one site should never be able to touch the others, a separate account is a harder boundary than per-site isolation on a shared plan.
• Reputational separation. Some niches (finance, health, anything with heavier compliance scrutiny) benefit from being visibly, structurally separate from the rest of your portfolio - different account, different billing trail, no shared footprint to trace.
• A genuinely separate client or business. If someone else needs their own login, billing, and access boundary, that's a new account, full stop.

Outside those cases, one well-isolated plan is simpler to run, cheaper per site, and easier to manage from a single dashboard than juggling several logins for landers that don't actually need separating.

What our tiers actually assume

All three tiers below include wildcard SSL, NVMe storage, HTTP/3, and staging clones per site - the isolation and speed floor described above, not just a site-count cap. Net prices, excl. VAT.