Ever since we’ve been notified about the changes to the bandwidth pricing for Webflow, we’ve seen surges of traffic from bots in non-Canadian regions (primarily Brazil and US). Attached is a screenshot from our GA4, which shows almost 400k “users” from Brazil vs 16k from Canada. Sure, you can make up an excuse that perhaps Brazilians want to visit our site, but our website is literally the pre-owned Genesis vehicle inventory for Canada, so there’s no reason why there should be that much of a gap between a different market and our actual market. There is growing suspicion online that Webflow is creating (or at least doing nothing to prevent) this traffic since it pushes users to your enterprise plans by soaking up bandwidth. We have over 30 websites that are approaching this precipice and there is no way our clients can afford enterprise nor justify it considering the cost for us to just switch platforms or build out our own CMS. We implore you to look into this and provide a solution as it makes it very hard to back Webflow if this kind of shady behaviour isn’t addressed. Considering we aren’t allowed to add our own protection without running a reverse proxy, etc. is just ridiculous. A quick Google search shows this sentiment is shared online.
I’ve been recommending Webflow to clients for years. I was about to recommend it to a new client who operates three large charities, but the bandwidth reduction of last year combined with these bot issues means I don’t think I can do that for fear of being responsible for recommending a service that could backfire financially, leaving them in the situation your clients are now in.
Let’s see if there is an offical response to your post…
If you both get stuck, feel free to reach out for options that remove these limitations. I tailor solutions to meet requirements and have decades of experience doing so and +6.5 years on Webflow. Just finished some large projects and have some gaps in my schedule I would like to fill.
No update yet, but even today… it says 20GB of bandwidth has been consumed but when I export the csv containing the bandwidth stats for today, it only shows ~10GB.
THE MOST RIDICULOUS PART is that yesterday we somehow had 19k unique users from Brazil on our site, whereas today there’s only been 4. Riddle me that. In fact, yesterday it says we consumed 20.1 GB and we had about ~20k unique users, but today we’ve used 20.5 GB from only ~250 users. So somehow we used MORE bandwidth even though we’ve had 98% less traffic. It seems like Webflow’s bandwidth tracking is pulling numbers out of nowhere and sending fake traffic. Like what the heck is going on?
… and so there is silence from Webflow…
@jakemorrisonkanvas this sounds like a nightmare that makes no sense at all. Did you get any private response from Webflow?
Hey Jake, I’ve been keeping an eye on your message to see how Webflow responds- but I’ve just noticed this part, which looks like you’re trying to catch Webflow’s attention here in the community forum? That’s very unlikely.
The way to reach Webflow is by opening a support ticket, have you done that yet? They may have more visibility into your Brazil traffic.
What I’m seeing across all sites ( not just WF sites ) is an increase in volatility on content- rich sites, often caused by search engines in different countries, or by AI bots like Claude that download everything for their model.
As you observed in your GA4 report, that can lead to weird countries appearing- but that also frequently happens due to mis-classified cell towers as new ones come online. I see a lot of traffic from the US for AU/NZ-only sites that is actually local mobile traffic.
From your comments it looks like that is not correlating with your bandwidth, which is normal in these cases.
- Webflow’s bandwidth reports do not show traffic, and do not care about HTML downloads, only assets / js / css
- GA4’s cannot measure bandwidth or assets, only HTML page hits.
They’re reporting apples and oranges.
But if the traffic were normal users, following normal SEO and ad clicks and navigating the site normally, it’s reasonable to expect some loose correlation between user count and bandwidth.
In general I don’t have any issues with bandwidth including some large sites- but there are a lot of practices I follow;
- Optimize all images
- Off-host all vids, never use WF’s background vid
- Minimize the use of custom uploaded fonts
- Minimize SVG and Rive use, or off-host them
Webflow’s report is very good at tell you where the hit is, and what needs your attention.
Thanks for the detailed response Michael!
I started by creating a support ticket, I just copied and pasted my message from my ticket into this forum for more exposure and to hopefully increase the urgency.
Unfortunately the nature of our website is that 30+ dealerships feed their vehicles via a dealer management system which doesn’t compress their vehicle images before they reach our CMS, I do compress them to AVIF once they reach our CMS but they are still relatively large images.. and a lot of them. An individual listing will have up to 30 images.
I’d compress them at the middle tier, before they reach the CMS. Also constrain them to a maximum size like 1600 x 1600, larger than that is probably useless and means a lot of wasted bytes.
You could also just store these images elsewhere like Amazon S3 or Cloudflare R2, or Bunny.net, and store the URL in the CMS. That keeps them off WF hosting entirely.
If you resize & compress them well, you’re probably good with multi-image fields.
If you’re hosting the images externally, you’ll need URLs which can be stored a number of ways.
- If your listing data is < 30 fields, you could use 30 individual links
- Or if you need better field economy, I’d probably stick them all in a plain text field as a JSON chunk, and pull that with script. That keeps each listing as 1 record, however feasibility depends on admin processes.
- You could use a separate collection for the images with 30 more records, which is easier for metdata and in-designer admin. But likely you’d need good housekeeping to remove old listing data to stay under the 10k limit.
That’s actually really helpful — thanks so much Michael! I might try the approach of hosting elsewhere. But would that still use similar bandwidth since I have to load them each time the user visits the page? Like I don’t think I’m concerned with the way they’re stored as much as the hit on the server for when they’re loaded, but I’m a newb with this stuff so feel free to put me in my place haha!
It wouldn’t involve Webflow’s bandwidth limits, which designers with media-heavy traffic-heavy sites sometimes struggle with.
Most services ( S3, bunny ) do have costs but they are generally quite cheap in comparison. Look at Cloudinary as well since you’re focused on images- it allows some nice features like watermarking images, auto resizing them, that kind of thing. Could be perfect for this.
Hey @jakemorrisonkanvas Just read through the post and responses and saw that its been about 2 weeks and was wondering if you ever got much in the way of a response from your support ticket? Also, is it possible for y’all to require the dealerships to use images with certain sizes/properties to help from that end also like Michael suggested? Over 1k views in a month on this post makes me feel like there are a lot of people out there dealing with a similar issue. I’m curious what the official response was and appreciate you sharing with everyone.
There has been absolutely zero response. They do not seem to be alarmed at all AND last week they automatically upgraded us to a USD $4k plan and charged our billing for it. Today we just got notified they’re bumping up another one as well, this one will be around $1k. All they care about is making money, it is so sad and crushing — our agency is now being forced to seriously consider a different system going forward instead of getting bullied by Webflow. The worst part is that I can’t even compress my images, when I try to it, it doesn’t allow me to select them for compression (only about 40% of my images can be selected, even though the ones I can’t select are JPEG/PNG). It shows a weird little book icon at the top left of the thumbnail which means I can’t select it, when I preview the image it just doesn’t appear and can’t be compressed within Webflow (see screenshot).
April 10 2025 update: I realized that the little book icon I mentioned along with the inability to preview the files and compress was because I’m using a shared library. Everything on my site I can duplicate without issue, it’s just the shared library assets.
@jakemorrisonkanvas that’s very distressing. I’m seeing quite a few others struggling with phantom traffic as well.
Regarding image optimization, that should not be an issue- what you’re seeing there is a “broken image” indicator by your web browser which means it cannot find or display that image. Here that’s most likely an issue with your browser cache, or perhaps a router or VPN configuration that’s blocking that image for some reason.
Even so it should not affect your ability to optimize images that exist in your project, since that’s done server-side.
Make sure you’re working on images in batches, if you’re optimizing to AVIF’s then large JPEGs can fail due to the heavy resource constraints.
Note that WF now has an image replace feature which might be useful here too, you can do the AVIF conversion locally and then upload and replace your biggest offenders.
I’m doing a lot of work in this space if you need some pro help, drop me a message.
Some tips here on using WF’s optimization tools-
After doing some thorough digging with a couple colleagues, we think we’ve found the issue but unfortunately it isn’t good news. When we compare our site traffic via various analytics to the bandwidth being consumed according to Webflow, there’s heavy discrepancies. For example, on another site that we run for the same car manufacturer, it shows in the analytics that there were roughly 5k views of a particular webpage. But, in Webflow’s site usage it says that an image on that same page was loaded roughly 30k times, despite it being the only instance (so the asset is being loaded 6x the actual page views). In our opinions, we believe the asset itself (ie. https://cdn.prod.website-files.com/…) is being pulled via AI scraping and other scraping methods. Which if that’s the case, even if we reverse proxy with Cloudflare and then set up Hotlink Protection from Cloudflare; that won’t prevent the assets from being accessed since they are hosted on cdn.prod.website-files.com domain. So the only solution for us is to host our images elsewhere and just point to them from our Webflow project. If this is the case, now we have to not only manage this new database and dedicate a heavy amount of additional time to reconfigure our existing websites, but also every update will be that much more strenuous. In our eyes, Webflow is doing nothing to protect our assets from abuse since they can use this for leverage towards upgrading our plans. I don’t want to push this too far, but if we’re incurring costs due to Webflow’s clear lack of security, then this might be a whole other can of worms.
There are other possible causes for assets being retrieved independently of the HTML.
The most common ones I see are RSS feeds, if you’re using them, or anything that would cause recurring reloads- scripting issue, or SEO tools that can cause recurring download of certain images when in editor view.
I’ve listed a few others I’ve seen here under mystery bandwidth;
Note you might be able to get some temporary relief by doing a kingside castle- clone your site, and then transfer your plan. Make sure you get redirects, apps, domains, etc.
This “moves” all of your assets to new URLs in case you have a leeching problem- someone else hosting your images in their website, etc. Webflow doesn’t have any protection for this.
Hey Jake, sorry to hear you didn’t receive a response. That doesn’t sound right. Can you please DM me your ticket number(s). I would like to take a look here.
Hi Jake,
Veronica here from Webflow’s community team. First off, I want to apologize that it’s taken longer than it should have to get back to you and we truly appreciate your patience. Our Support team is actively looking into this and will follow up directly with more details and next steps.
Thanks again for bringing this to our attention – we’re committed to working with you on the best path forward.
@jakemorrisonkanvas just wanted to close the loop here – thanks so much for your patience while we dug deeper into this issue. After further investigation, our team has proposed an interim solution in your original Support ticket to address the concerns you’ve raised. Please take a look when you have a moment.
We’re committed to doing right by our customers so thanks again for bringing this to our attention and helping us improve. If you have any other questions or concerns, we’re here to help.