Short answer
A hosting bandwidth cap is a monthly ceiling on the total bytes that leave the hosting account to visitors — HTML, CSS, JavaScript, images, video, downloads, API responses — and the cap resets on the billing-cycle anniversary. Most entry shared plans cap at 100 GB to 3 TB per month and bill the overage at $0.05 to $0.50 per GB or throttle the site when the cap is hit, mid-tier plans cap at 3 TB to 10 TB or advertise unmetered bandwidth with a fair-use clause, and high-tier shared, VPS, and dedicated plans typically advertise truly unmetered bandwidth with no per-GB charge. When a site hits its cap, the host applies one of three policies: throttling (the site stays online but loads at dial-up speeds), metered overage (the host bills the per-GB rate and the site stays online), or suspension (the site is taken offline until next cycle or until the overage is paid). The cheapest way to recover from a cap hit is CDN offload, not a hosting upgrade, because a free or paid CDN takes 60% to 90% of the static-asset traffic off the origin server. The second cheapest is image compression (WebP, lazy loading, srcset), and the third cheapest is hotlink protection. The buyer's pre-purchase audit projects the worst-case monthly traffic over the last 12 months, adds 50% to 100% headroom, confirms the overage policy in the host's terms of service, and verifies the unmetered clause is genuine (not throttled or fair-use gated) before signing.
How monthly bandwidth caps actually work on shared, VPS, and managed hosting
The word "bandwidth" on a hosting pricing page is one of the most consistently misread numbers in the consumer hosting market, and the misreading shows up in three different ways. First, "bandwidth" usually means total bytes transferred out of the hosting account per month, not the connection speed in megabits per second that the same word is used for in other contexts. Second, "unmetered" usually means the host applies a fair-use threshold above which the policy changes from a hard GB cap to a throttle or a tier upgrade, not that the site can serve infinite bytes. Third, the cap resets on the billing-cycle anniversary, so the spike that hits the cap on day 28 of a 30-day cycle is paid twice (or paid with an overage and again the next month) rather than carrying over. The clarifications below are worth stating explicitly because they shape the buyer's mental model of what the cap actually means in production.
- Bandwidth is total bytes out, not connection speed. A 100 Mbps connection does not consume 100 Mbps of bandwidth every second; it consumes as many bytes as the served pages request, summed across all visitors, all pages, and all assets. The same connection can serve a 1 GB-per-month site or a 1 TB-per-month site, depending on the page weight and the visitor count.
- Metered means a hard GB cap. A 1 TB metered cap means the host counts every byte the site serves and stops serving (or bills the overage) once the counter crosses 1 TB. The cap is enforced server-side, not advisory; the site cannot exceed the cap without action by the host.
- Unmetered usually means fair-use. A plan that advertises "unmetered bandwidth" usually applies a fair-use threshold (often 10 TB to 100 TB per month depending on the plan tier) above which the host reserves the right to throttle, suspend, or require a plan upgrade. Fair-use is enforced case by case, but the threshold is real and the policy is enforceable.
- The cap is monthly, not daily. The counter resets on the billing-cycle anniversary, so the spike that hits the cap on day 28 does not carry over to the next month; the site either pays the overage or faces the throttle/suspension immediately. The monthly math is the right basis for sizing, not a daily or weekly math.
- Email bandwidth counts on most shared plans. SMTP traffic (inbound and outbound) and IMAP/POP traffic (mailbox sync) usually count toward the same monthly cap on shared plans. A site with a high-volume newsletter or contact form can consume 5% to 30% of the monthly bandwidth on email alone, before any web traffic.
- API calls count toward the cap on shared plans. A WordPress site with the REST API exposed, a JSON-driven front end, or a third-party integration pulling data on a schedule consumes bandwidth with every API call. The bytes are small per call but compound across thousands of calls per day.
These clarifications are not hidden, but they are usually buried in the host's acceptable use policy or the plan-comparison footnote rather than on the pricing page. The pricing page says "10 TB per month" or "unmetered," and the buyer assumes the plan covers any reasonable traffic, which is usually true but not always true at the spike.
Where hosting bandwidth caps actually sit across the plan tiers
The table below lines up the bandwidth caps that are typical for each tier of consumer and small-business hosting, the typical overage policy when the cap is hit, and the monthly cost difference between the lowest and highest tier of each category. Numbers are illustrative ranges across common shared, VPS, and managed hosting providers; verify the actual cap, the overage rate, and the unmetered clause in the host's pricing page and acceptable use policy before signing up.
| Plan tier | Typical monthly cap | Overage policy (typical) | Overage cost (typical) | Typical renewal range |
|---|---|---|---|---|
| Entry shared hosting | 100 GB to 1 TB | Throttle or metered overage | $0.05 to $0.50 per GB overage, or throttle to dial-up speeds | $10 to $20 per month |
| Mid-tier shared hosting | 3 TB to 10 TB | Metered overage, sometimes unmetered on higher mid-tier | $0.05 to $0.25 per GB overage | $18 to $35 per month |
| High-tier shared hosting | 10 TB+ or "unmetered" with fair-use | Fair-use throttle or plan upgrade request | $0 (fair-use throttle instead of charge) | $35 to $70 per month |
| Unmanaged VPS (entry) | 1 TB to 5 TB; sometimes unmetered on a per-provider basis | Metered overage or network throttle | $0.02 to $0.15 per GB overage | $20 to $40 per month (often flat-rate) |
| Managed VPS (entry) | 2 TB to 10 TB; usually unmetered on mid-tier or higher | Fair-use throttle or plan upgrade request | $0 (fair-use throttle instead of charge) | $40 to $80 per month (often flat-rate) |
| Managed WordPress hosting (entry) | 25 GB to 250 GB of "visits" or "bandwidth" (provider-defined) | Metered overage, sometimes a hard cut-off | $0.05 to $1.00 per 1,000 visits over the cap | $25 to $50 per month |
| Managed WordPress hosting (mid-tier) | 250 GB to 500 GB of visits or bandwidth | Metered overage | $0.05 to $1.00 per 1,000 visits over the cap | $50 to $100 per month |
| Cloud hosting (entry) | 1 TB to 5 TB, with usage-based egress pricing on top of the cap | Metered overage at per-GB cloud egress | $0.05 to $0.12 per GB egress (region-dependent) | $30 to $80 per month |
| Dedicated server | Unmetered on most providers (subject to port speed) | Port speed limit, no per-GB charge | $0 (port speed is the limit, not a GB cap) | $100 to $300 per month |
| CDN offload (free tier, e.g., Cloudflare) | Unmetered on the free tier for basic static assets | N/A (free tier does not throttle on bandwidth) | $0 | $0 |
| CDN offload (paid) | Unmetered on most providers, sometimes with first TB included | Per-GB egress on tiers above the included quota | $0.005 to $0.10 per GB egress | $0 to $20 per month depending on usage |
The cheapest way to read this table is that mid-tier and high-tier plans usually have the most generous caps (often unmetered with fair-use), and the entry plans are the most likely to enforce a hard throttle on a spike. The upgrade path that clears the cap most reliably is the next plan tier at the same host, not a jump to a VPS, because the next plan tier usually doubles the cap at 1.5x to 2x the renewal price and keeps the bandwidth math inside the same control panel.
Where the bandwidth actually goes on a typical site
The byte counters on a hosting control panel do not show what the bytes are made of, but the pattern of what consumes bandwidth is consistent across most sites. Knowing the pattern saves the buyer from guessing at where to cut.
- Images. 50% to 80% of the average page weight on a typical blog, portfolio, or small e-commerce site is images. A 200 KB hero image served on every page view, multiplied by 10,000 visitors per month, is 2 GB of bandwidth on its own. A 4 MB hero image served on every page view is 40 GB. Replacing a 4 MB JPEG with a 200 KB WebP image (lazy-loaded below the fold) typically cuts the served weight per page by 70% to 90%.
- Self-hosted video. A 5-minute video at 720p is roughly 50 MB to 150 MB; a 5-minute video at 1080p is roughly 150 MB to 500 MB. Self-hosting video consumes 100x to 1,000x the bandwidth of embedding the same video from YouTube, Vimeo, or a paid video host (Wistia, Mux, Vidyard). Self-hosting is almost always the wrong answer for bandwidth reasons alone.
- Hotlinked images. A third-party site (forum, Reddit thread, small blog) that links directly to the buyer's image URLs serves every visitor's request from the buyer's hosting account. A single Reddit mention can drive 5 GB to 50 GB of unearned bandwidth, depending on the image weight and the post engagement. Hotlink protection (a .htaccess rule or a host control panel toggle) blocks this traffic with a one-time configuration change.
- Downloads (PDFs, ZIPs, installers). A 10 MB PDF downloaded 1,000 times per month is 10 GB of bandwidth. A 100 MB installer downloaded 1,000 times per month is 100 GB. Downloads are usually a small fraction of total visitors but a large fraction of total bandwidth. The cheapest pattern is to offload downloads to a CDN or a file host (S3 + CloudFront, BunnyCDN, Dropbox, Google Drive) so the origin hosting does not pay for them.
- Embedded third-party widgets. Social-share widgets, chat widgets, analytics scripts, A/B testing scripts, and ad networks each pull 50 KB to 500 KB per page load. The widget host serves the bytes, not the buyer's hosting, so the widgets do not count toward the buyer's cap. The widgets do slow the page, which is a separate cost.
- Bot scrapes. Aggressive bots (search engine crawlers, AI scrapers, SEO tools, uptime monitors, security scanners) can consume 10% to 40% of the monthly bandwidth on a small site. Bots are polite most of the time, but a single misconfigured crawler can request every URL on the site thousands of times per day. Bot mitigation (rate limiting, robots.txt discipline, fail2ban, Cloudflare bot protection) cuts bot traffic without affecting real visitors.
- Email attachments and forwards. Inboxes that contain large attachments, forwarded mail, and accumulated years of mail can consume noticeable bandwidth on a shared plan. A 2 MB forwarded to a 5-person mailing list is 10 MB of outbound traffic per send, before any replies. Mailbox storage and attachment policy matter at scale.
The cumulative picture is that images, self-hosted video, and hotlinked files are the three biggest bandwidth levers, and all three are fixable without changing the hosting plan. Cut the biggest sources first, then re-measure, and the upgrade is usually unnecessary.
Throttled vs metered vs suspended: what each policy actually costs
The overage policy differs across hosts and across plan tiers, and the policy determines whether hitting the cap costs the buyer a few dollars, a few hundred dollars, or a day's lost revenue. The three policies below are the ones most hosts apply.
Throttled. The host caps the connection speed per request (often to 50 KB/s to 500 KB/s, sometimes slower) and the site stays online but loads at dial-up speeds. A page that loads in 2 seconds on a normal connection can take 30 to 60 seconds on a throttled connection, which is enough to lose most visitors before they see the page. The throttle lasts until the next billing cycle, so the buyer loses a partial month of revenue or attention. The cost is usually indirect (lost conversions, lost ad revenue, lost SEO during the throttle window) and is rarely a refundable invoice line. Most entry shared plans default to throttle rather than metered overage.
Metered overage. The host bills the overage at a per-GB rate ($0.05 to $0.50 per GB on entry shared, $0.02 to $0.15 per GB on VPS, $0.05 to $0.12 per GB on cloud) and the site stays online at full speed. A site that exceeds a 1 TB cap by 200 GB on a $0.10 per GB overage rate pays $20 in overage charges, which is the cheapest answer. The overage is added to the next invoice, and the buyer can usually dispute it within 30 days if the spike was an outlier. Metered overage is the cleanest answer because the cost is transparent and the site stays online.
Suspended. The host takes the site offline (a 503 or a parked page) until the next billing cycle or until the overage is paid. The suspension is the most punitive policy because it cuts off revenue entirely and the buyer cannot collect the lost revenue from the host. Suspension is rare on most modern hosts but is still the default policy on a few budget shared providers, on free hosting tiers that hit their caps, and on plans whose acceptable use policy reserves the right to suspend for any spike above the cap. The cost is the full revenue of the suspended window, which is usually much larger than any overage charge would have been.
The cheapest policy for the buyer is metered overage, the most common policy on entry shared is throttle, and the most punitive is suspension. The buyer's job is to confirm the policy in the host's acceptable use policy before signing up, not at the moment the cap is hit, because the policy is the variable that determines whether hitting the cap is a $20 inconvenience or a multi-thousand-dollar revenue loss.
What recovery from hitting the cap actually costs
The recovery cost depends on the cause of the spike and the cheapest fix the buyer can apply in the moment. The list below lines up the most common recovery paths, in roughly the order they pay off, and what each one typically costs in real time, real dollars, or real work hours.
| Recovery path | What it actually fixes | Typical cost in time | Typical cost in dollars | Typical bandwidth recovered |
|---|---|---|---|---|
| Set up a free CDN (Cloudflare, Jetpack) | Serves 60% to 90% of static-asset traffic from CDN edge | 30 to 90 minutes | $0 (free tier) | Cut hosting bandwidth by 50% to 85% |
| Set up a paid CDN (BunnyCDN, short.io) | Same as above, with global edge and lower per-GB cost | 30 to 60 minutes | $0 to $5 per month for typical site traffic | Cut hosting bandwidth by 60% to 90% |
| Compress images to WebP, lazy-load below-the-fold | Reduces per-page served weight | 2 to 8 hours for a typical site | $0 (free tools and plugins) | Cut hosting bandwidth by 30% to 70% |
| Enable hotlink protection in .htaccess or host panel | Blocks third-party sites from using the buyer's image URLs | 10 to 20 minutes | $0 | Cut hosting bandwidth by 5% to 50%, depending on traffic |
| Offload self-hosted video to YouTube/Vimeo/Mux | Removes the largest single bandwidth item on most media-heavy sites | 2 to 8 hours for embed migration | $0 to $50 per month for paid video host | Cut hosting bandwidth by 20% to 80% |
| Offload downloads (PDFs, ZIPs) to S3 + CloudFront or file host | Removes large-file downloads from the origin hosting meter | 1 to 3 hours | $0 to $5 per month for typical download volume | Cut hosting bandwidth by 5% to 30% |
| Block aggressive bots in robots.txt, fail2ban, or Cloudflare bot protection | Stops bot scrapers from inflating bandwidth counts | 1 to 4 hours | $0 to $20 per month for a paid bot-protection tier | Cut hosting bandwidth by 10% to 40% |
| Disable XML-RPC on WordPress if not needed | Stops brute-force pingbacks and DDoS amplification | 5 to 15 minutes | $0 | Cut hosting bandwidth by 5% to 15% on a typical WordPress site |
| Tier upgrade at the same host (entry to mid-tier shared) | Doubles or triples the cap; throttling or overage is deferred | 10 to 30 minutes | $5 to $15 per month more at renewal | Cap rises from 1 TB to 3 TB or 10 TB |
| Pay the overage on the next invoice | Restores the site to full speed on metered plans | 0 minutes (automatic) | $0.05 to $0.50 per GB overage; $10 to $200 typical | Full restoration for one cycle |
| Switch hosts to a plan with unmetered bandwidth on mid-tier or higher | Removes the cap from the buyer's planning horizon | 2 to 8 hours for migration | $0 to $30 per month more for a higher tier | Cap effectively unlimited at fair-use threshold |
The cheapest way to read this table is that the first three rows (CDN offload, image compression, hotlink protection) recover more than 50% of the bandwidth for zero dollars, and they should be in place before the buyer considers a tier upgrade or a host switch. The tier upgrade is the right answer only after the cheap fixes have been applied and the bandwidth is still above the cap.
CDN offload: the cheapest single fix for a bandwidth cap
CDN offload is the cheapest single fix for a bandwidth cap because it changes the math without changing the plan, the price, or the control panel. A free CDN (Cloudflare free tier, Jetpack Site Accelerator, Fastly free tier for static assets) serves cached copies of the site's static assets (images, CSS, JavaScript, downloads) from edge servers around the world, and the origin hosting server only pays for the bytes that miss the CDN cache. A site that serves 80% of its traffic from the CDN cache only uses 20% of the original bandwidth on the origin server, which means a 1 TB monthly cap stretches to roughly 5 TB of effective capacity.
The setup time for a free CDN is 30 to 90 minutes: create the account, add the site, change the nameservers to the CDN's nameservers, and verify that the cache is hitting on the major assets. The verification step is the most important, because a misconfigured CDN that misses most requests leaves the bandwidth meter unchanged. The cheapest way to verify is to check the hosting bandwidth graph before and after enabling the CDN, with the same daily traffic pattern, and to confirm the hosted bandwidth dropped by 50% or more.
A paid CDN (BunnyCDN, short.io, KeyCDN) costs $0 to $5 per month for typical small-business traffic and adds features that the free tier does not: image optimization on the edge, custom cache rules, per-region pricing, real-time analytics, and a higher cache-hit ratio on dynamic content. The paid tier is the right answer when the free tier misses too many requests or when the site serves most of its traffic from a single region that the free CDN does not cover well.
The bandwidth savings from a CDN are usually 50% to 90% on a typical blog or small e-commerce site, and the savings grow as the site adds pages and assets. The savings are the same regardless of the hosting plan, which means a CDN enables the buyer to stay on an entry shared plan even as the site's traffic grows, deferring the tier upgrade by 12 to 24 months. The savings compound across the lifetime of the site, not just at the moment of a cap hit.
Image compression: the second-cheapest fix for a bandwidth cap
Image compression is the second-cheapest fix because the typical image on a small-business site is 2x to 10x larger than it needs to be, and a single afternoon of work can cut the served weight per page by 50% to 80%. The compression path below is the cheapest sequence to follow.
Convert JPEG and PNG to WebP. WebP produces files that are 25% to 35% smaller than equivalent JPEG and 50% to 80% smaller than equivalent PNG, with no visible quality loss on most images. The conversion can be batch-applied to existing media libraries with a plugin (ShortPixel, Imagify, Smush) or a CLI tool, and the served weight drops immediately. WebP is supported by every modern browser, so the format change is safe for any site built in the last five years.
Lazy-load below-the-fold images. Images that are below the fold (hero image above the fold, gallery below the fold, footer logo below the fold) do not need to load until the visitor scrolls. Lazy-loading defers the bytes until they are needed, which means a visitor who scrolls halfway down the page loads half the images, and a visitor who leaves the page on the hero loads only the hero. The cumulative bytes saved are 30% to 60% on a typical long-scroll page.
Use srcset for responsive sizes. A single image served at a fixed width (e.g., a 1,200 px wide hero on a 400 px wide phone screen) wastes bytes. srcset serves a smaller image on smaller screens and a larger image on larger screens, which typically cuts the served weight on mobile by 50% to 70%. The cumulative bytes saved are 20% to 40% across the visitor mix.
Compress the originals before upload. A 4 MB JPEG straight from a camera or a designer is much larger than it needs to be for the web. Compressing to 200 KB to 500 KB before upload (or batch-compressing on import with a plugin) ensures the bytes are not served larger than needed. The cumulative bytes saved across the media library are 60% to 90%.
The combined image work typically recovers 50% to 80% of the bandwidth that images consume, with no hosting change and no CDN required. The work is mostly one-time, but the savings compound across every new page and every new visitor.
Hotlink protection: the cheapest fix for stolen bandwidth
Hotlink protection is a one-time configuration change that stops third-party sites from serving the buyer's images on their own pages. A forum, a Reddit thread, or a small blog that links directly to the buyer's image URLs (e.g., https://example.com/wp-content/uploads/hero.jpg instead of uploading the image itself) serves every visitor's request from the buyer's hosting account, and the buyer pays for the bandwidth the third-party site is consuming.
The protection is enabled in two places. The first is a .htaccess rule that blocks requests whose Referer header is not the buyer's own domain:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteRule \.(jpe?g|png|gif|webp|svg)$ - [F,L]
The second is a control-panel toggle in most modern host dashboards (often under "Security" or "Hotlink Protection") that wraps the same rule in a GUI. The .htaccess version is preferred because it works on hosts that do not expose the toggle, and because it can be customized per file type.
The bandwidth saved by hotlink protection varies from 5% (a site whose images are rarely hotlinked) to 50% (a site whose images are frequently hotlinked on forums and image hosts). The protection is one-time, costs nothing, and requires zero ongoing maintenance.
Self-hosted video: the largest single bandwidth item on most media-heavy sites
Self-hosted video is the largest single bandwidth item on most media-heavy sites, and the size of the item is large enough that removing it usually clears the cap by itself. A 5-minute video at 720p is 50 MB to 150 MB; at 1080p, the same video is 150 MB to 500 MB. A site that serves 100 video views per day consumes 5 GB to 50 GB per day on self-hosted video alone, which is 150 GB to 1,500 GB per month. The same 100 views on embedded YouTube or Vimeo consumes zero hosting bandwidth, because the video host serves the bytes.
The cheapest answers, in order, are: (1) embed from YouTube, Vimeo, or a paid video host (Wistia, Mux, Vidyard) and let the video host count the bandwidth, (2) offload the video file to a CDN or to S3 + CloudFront so the origin hosting does not pay for it, (3) replace the video with an animated GIF or a static image if the audio and motion are not essential to the page. The answer depends on whether the buyer needs the customization, the analytics, and the no-ads experience of a paid video host, or just needs the bytes off the origin hosting meter.
The right answer for most small-business sites is embed from a paid video host, because the paid host offers adaptive bitrate, player customization, email-gate integration, and analytics that self-hosted video cannot match at the same bandwidth cost. The cost of a paid video host is $0 to $50 per month for typical small-business video volume, which is much less than the cost of serving the same videos from a hosting plan that does not have the bandwidth to spare.
Bot mitigation: the cheapest fix for unexpected bandwidth spikes
Bot traffic is the most common cause of an unexpected bandwidth spike on a small-business site, and the spike can be large enough to trip the cap with no warning. Aggressive bots (search engine crawlers on an over-crawling day, AI scrapers, SEO tools, uptime monitors, security scanners) request thousands of URLs per hour, and each request consumes bandwidth that the visitor counter never sees.
The cheapest mitigation is robots.txt discipline. A well-configured robots.txt blocks the crawlers that are not wanted, slows the crawlers that are wanted, and reduces the total request count by 20% to 50% on most small-business sites. The discipline is free, requires no third-party tool, and can be applied in 30 minutes.
The next-cheapest mitigation is rate limiting in .htaccess, fail2ban, or the host's WAF (Web Application Firewall). Rate limiting caps the requests per IP per minute, which stops a single bot from inflating the bandwidth count and stops brute-force login attempts from triggering bandwidth spikes. The setup is 1 to 4 hours depending on the host's tooling, and the savings are 10% to 30% on most small-business sites.
The third-cheapest mitigation is Cloudflare bot protection (free tier, or paid tier at $20 per month) or a paid bot-management service. The paid tier adds machine-learning-based bot detection, challenge pages for suspicious traffic, and granular control per bot category. The savings are 20% to 50% on sites with significant bot traffic, which is common for any site that has been online for more than a year.
When the tier upgrade is genuinely worth paying for
The tier upgrade is worth paying for when the cheap fixes have been applied and the bandwidth is still above the cap, or when the buyer's traffic pattern is volatile enough that no CDN configuration or image compression can keep the meter below the cap reliably. The cases below are the most common where the upgrade is the right answer.
- The site has crossed 50,000+ visits per month. A site at this scale consumes 50 GB to 500 GB of bandwidth per month depending on page weight, which is at or above the cap of most entry shared plans. A CDN offload cuts the hosting bandwidth by 50% to 80%, but the remaining 20% to 50% is still above the entry cap. The next tier is the right answer.
- The site runs WooCommerce or a real application stack. A typical WordPress blog runs comfortably on entry shared for years. A WooCommerce store with 1,000+ SKUs, a live search, and a heavy checkout consumes 5x to 20x the bandwidth of a typical blog at the same visitor count. The mid-tier plan is the right starting point, not the upgrade end-point.
- The site self-hosts large files or video. A site that genuinely needs to self-host PDFs, installers, or video (for compliance or customization reasons) consumes bandwidth at a rate that no CDN offload can fully absorb. The next tier or a dedicated plan is the right answer for the self-hosted assets.
- The site has bot traffic that no robots.txt discipline can resolve. Some sites attract bot traffic for reasons outside the buyer's control (the industry is competitive, the site ranks for high-value keywords, the site has been online long enough to be in every crawl database). The next tier with unmetered bandwidth and a fair-use clause is the right answer when the bot traffic cannot be cleaned up.
- The site spikes regularly on a known schedule. A site that runs a weekly newsletter blast, a monthly product announcement, or an annual event (a conference, a launch, a sale) consumes noticeably more bandwidth on the spike day than on the average day. The next tier with a 5x to 10x higher cap absorbs the spike without throttling, and the buyer does not have to optimize around the spike every cycle.
The unifying rule is that the tier upgrade is worth paying for when the bandwidth is recurrently above the cap, the cap is structural to the plan, and the cheap fixes have been applied without clearing the cap. The tier upgrade is not worth paying for at the first cap hit, because the first cap hit is often a spike that does not recur, and the cheap fixes usually resolve the spike with no plan change.
Common bandwidth-limit mistakes to avoid
The pattern of mistakes below shows up repeatedly in user reports and support tickets. They are listed here because each one is cheap to avoid once you see it.
- Assuming "unmetered" means unlimited. Unmetered on most hosts means the host applies a fair-use clause above which the policy changes to throttle, suspend, or require a plan upgrade. The threshold is real, the policy is enforceable, and the buyer should verify the threshold in the host's acceptable use policy.
- Ignoring self-hosted video as a bandwidth item. A 5-minute 1080p video is 150 MB to 500 MB. A site that serves 100 video views per day consumes 5 GB to 50 GB per day on video alone. Embed the video from a paid video host or a CDN, and the bytes move off the origin hosting meter.
- Skipping hotlink protection. A forum or Reddit thread that links to the buyer's image URLs drains bandwidth the buyer did not budget for. Hotlink protection is a one-time .htaccess change that stops the drain with zero ongoing maintenance.
- Paying for a tier upgrade before applying the cheap fixes. CDN offload, image compression, and hotlink protection recover more bandwidth for zero dollars than most tier upgrades. Apply the cheap fixes first, measure again for 7 to 14 days, and only upgrade if the bandwidth is still above the cap.
- Sizing the cap to the average month, not the spike month. A site that averages 30 GB per month may spike to 200 GB in a single month after a viral post or a Reddit mention. Size the cap to the worst-case monthly traffic over the last 12 months, plus 50% to 100% headroom, not to the average.
- Skipping the cache-hit verification on the CDN. A misconfigured CDN misses most requests and leaves the bandwidth meter unchanged. Check the cache-hit ratio in the CDN dashboard and the hosting bandwidth graph before and after enabling the CDN, with the same traffic pattern, to confirm the CDN is serving the bytes.
- Forgetting that email and API bandwidth count on shared plans. A site with a high-volume newsletter, a contact form, or an exposed REST API consumes bandwidth with every send and every call. Mailbox policy, API rate limits, and contact-form spam filters matter at scale.
Buyer checklist: sizing the bandwidth cap to the site's worst-case traffic
- Pull the last 12 months of hosting bandwidth usage from the control panel. Identify the average monthly usage, the highest monthly usage (spike month), and the typical visitor-to-bandwidth ratio. The cap should be sized to the spike month plus 50% to 100% headroom, not to the average month.
- Confirm the cap on the current plan and the overage policy in the host's acceptable use policy. Metered overage ($0.05 to $0.50 per GB) is the cleanest answer. Throttling and suspension are punitive. The policy determines whether hitting the cap is a $20 invoice or a day's lost revenue.
- Set up a free CDN (Cloudflare, Jetpack) or a paid CDN (BunnyCDN, short.io) before considering a tier upgrade. Verify the cache-hit ratio in the CDN dashboard and the hosting bandwidth graph before and after enabling the CDN, with the same daily traffic pattern, to confirm the CDN is serving 50% to 90% of the static-asset traffic.
- Compress the existing media library to WebP, enable lazy-loading for below-the-fold images, and use srcset for responsive sizes. A single afternoon of work typically cuts the served weight per page by 50% to 80%. Add new uploads to the conversion pipeline so the savings persist across the lifetime of the site.
- Enable hotlink protection in .htaccess or the host's control panel toggle. The one-time configuration change blocks third-party sites from serving the buyer's images on their own pages, recovering 5% to 50% of the bandwidth depending on how often the site's images are hotlinked.
- Offload self-hosted video to a paid video host or embed it from YouTube or Vimeo. A 5-minute 1080p video served 100 times per day consumes 15 GB to 50 GB on the origin hosting, which is enough to clear a cap by itself on an entry shared plan. Replace or embed if at all possible.
- Confirm the unmetered clause is genuine if the plan advertises unmetered bandwidth. Check the host's acceptable use policy for a fair-use threshold and the throttle/suspension policy above the threshold. The threshold is real and the policy is enforceable; verify before relying on the unmetered advertising.
- Re-measure the bandwidth monthly for the first 3 months after any change (CDN setup, image compression, hotlink protection, plan upgrade). The meters confirm whether the changes are working and whether the next change is needed. A site that consistently runs above 70% of the cap is signaling a tier upgrade, regardless of which cheap fixes have been applied.
Affiliate disclosure: PriceGap is an independent buyer-education site. This article contains no advertiser checkout links, does not claim a current sponsor relationship with any hosting provider, and does not quote fixed live bandwidth caps, overage rates, fair-use thresholds, or CDN egress prices. Bandwidth caps, overage rates, throttle policies, suspension policies, fair-use thresholds, CDN egress prices, and unmetered clauses change frequently and vary by plan tier, host, and region; verify current terms, your real bandwidth usage data, and the cap-and-overage policy directly with the host before signing up, upgrading, or relying on an unmetered clause.