Bandwidth, Transfer, and ‘Unlimited’: Reading Hosting Fine Print

Almost every hosting page advertises “unlimited bandwidth” or “unlimited transfer” somewhere above the fold. It sounds generous, and it usually is, but the word is doing a lot of quiet work. Understanding what these plans actually meter, and where the fine print kicks in, will save you from surprises when your traffic grows or a post goes wider than expected.

What the words actually mean

Hosts use a few overlapping terms, and they are not always interchangeable:

• Bandwidth technically refers to the capacity of a network connection, measured in bits per second. In hosting marketing, it is almost always used loosely to mean data transfer.
• Data transfer is the actual volume of data (images, HTML, CSS, JS, video, API responses) sent from the server to visitors over a period, usually measured monthly in gigabytes or terabytes.
• Requests or hits count how many times a resource is fetched, regardless of size. A page with fifty small assets generates fifty requests even if the total payload is tiny.
• CPU/process limits govern how much server compute your account can use at once, which is a separate ceiling from transfer entirely.

When a plan says “unlimited,” it is almost always referring to data transfer, not requests and not compute. Those other limits are where fair-use policies live.

Why “unlimited” rarely means unlimited

Shared infrastructure has physical limits. A host running many sites on a server has finite network capacity, disk I/O, and CPU to divide among tenants. “Unlimited transfer” is a marketing simplification for “we do not meter transfer for typical WordPress usage patterns.” What is typical is defined by a fair-use clause, usually described in vaguer language like “resources appropriate for a standard website” or “no single account should degrade performance for others.”

In practice, fair-use enforcement tends to trigger on sustained resource abuse rather than a single traffic spike: constant high CPU from bad plugin code, video or large file hosting used as a public CDN, cron jobs running in tight loops, or bot traffic hammering endpoints. A legitimate blog that gets a large but temporary traffic surge is rarely the target of these clauses. A site quietly serving gigabytes of video downloads to third parties every day is a more likely candidate.

The practical takeaway: read for language about CPU seconds, concurrent processes, inode counts, or storage type, not just the transfer number. Those are the limits that actually constrain a WordPress site day to day.

Estimating your real monthly transfer

You do not need a guess when you can calculate a reasonable estimate. The basic formula:

monthly transfer (approx) = average page weight x average pages per visit x monthly visits

To get real numbers:

• Check your average page weight using browser dev tools (Network tab, look at total transferred size for a typical page, not just the HTML).
• Check average pages per session in your analytics tool.
• Check monthly sessions or visits from the same source.

For example, a page averaging 1.5 MB, 2.5 pages per visit, and 40,000 monthly visits works out to roughly 150 GB of theoretical transfer if every request hit the origin server uncached. In reality, caching cuts that number dramatically, which is the next piece of the puzzle.

Caching changes the math more than plan size does

Full-page caching and edge delivery are what actually determine how much of that theoretical transfer touches your server versus a cache layer:

• Full-page caching (LiteSpeed Cache on a LiteSpeed or OpenLiteSpeed stack, for example) serves a static, pre-rendered copy of a page for anonymous visitors, so PHP and the database are not touched on repeat views.
• Object caching via Redis or Memcached, installed as a persistent drop-in, reduces the cost of dynamic queries that still need to run (logged-in users, WooCommerce carts, personalized content) even when full-page caching does not apply.
• Edge caching and a CDN, such as Cloudflare sitting in front of your origin, serves static assets and often full HTML from edge locations close to the visitor. This is the biggest transfer saver: bytes served from the edge never touch your hosting account’s transfer at all.

Put differently, a well-cached site with Cloudflare in front might see the origin server handle a small fraction of total visitor traffic, with the CDN absorbing the rest. This is also why keeping your origin IP unpublished matters beyond DDoS resilience: it keeps traffic funneled through the protective, transfer-absorbing edge layer rather than hitting your server directly.

Checking your actual usage

Most hosting control panels show bandwidth graphs, but you can also verify from the command line if you have SSH access. A quick way to see how much data your web server has actually sent from access logs:

awk '{sum += $10} END {print sum/1024/1024/1024 " GB"}' access.log

This sums the response size field (adjust the column number to match your log format) across a log file and converts it to gigabytes. It only reflects origin transfer, so if a CDN sits in front, your real visitor-facing transfer is higher than what this number shows, and that is exactly the gap you want caching to create.

For a rough sense of what your site is asking the server to do, wp-cli can help too. Checking media library size and plugin count gives a proxy for how heavy your typical page load is:

wp media list --format=count
wp plugin list --status=active

Neither command measures transfer directly, but a bloated media library and a long list of active plugins are reliable predictors of heavier pages and more origin requests, which is where transfer estimates go wrong most often.

Reading a plan honestly

When comparing hosting plans, a few questions matter more than the headline transfer number:

• Does the plan include a CDN or edge caching by default, or is that an extra step you configure yourself?
• What are the CPU, process, and storage limits, since these usually bind before transfer does?
• Is storage NVMe or spinning disk? Disk speed affects real-world performance far more than most people expect, especially for database-heavy sites.
• What does the fair-use clause actually list as prohibited usage, versus vague language?

A managed WordPress host that bundles LiteSpeed caching, Redis object caching, and Cloudflare integration out of the box (which is the approach ServerBorn takes) removes most of the guesswork here, since the caching layers doing the heavy lifting are already configured rather than left for you to wire together.

The takeaway

“Unlimited” bandwidth is a real offer, but it is shorthand for “we do not meter typical usage,” not a literal absence of limits. The numbers that actually constrain a WordPress site day to day are CPU, concurrent processes, and storage type, and those are worth reading closely in any plan’s fine print. More importantly, your actual transfer needs are smaller than raw math suggests once full-page caching, object caching, and a CDN are doing their job. Measure your real page weight and traffic, layer on proper caching, and the transfer question mostly answers itself.