We took on what looked like a straightforward job. A news publisher we work with was having ongoing technical trouble with their WordPress site and wanted an agency to take it over and make it easier to maintain. The original plan was to fix WordPress.
After digging in, we suggested something different. Their problems were the kind that keep coming back on WordPress, and Webflow suited how their team worked. So, we moved the whole site across and launched it in the middle of June. Two weeks later we opened the Webflow usage dashboard and stopped what we were doing.
The number that stopped us: 1.05 terabytes in sixteen days. Their plan came with 50GB a month. They had burned through a full month’s allowance in well under a day, then done it again every day since, roughly 40× what they were paying for.
Nobody had done anything wrong
Here is the part that took us a while to accept. Nothing had gone wrong with the migration. The site worked. Traffic was normal. There was no bug.
The traffic behind the bill had been there all along, back on WordPress too. It never showed up as a number, because their old hosting quietly absorbed it. But the traffic did not stop existing just because nobody was billed for it. It was still hammering the server every second of every day, dragging on performance, and it included scrapers and probes that are a security concern in their own right. WordPress was not shielding but hiding the client from any of that. This was worse because a problem you cannot see is a problem you cannot fix.
Webflow did the opposite. By metering bandwidth against a clear monthly cap, it turned an invisible liability into a number on a dashboard. That number is exactly what let us catch these two weeks in rather than two months in. Webflow shows you your real traffic, even when the first look is alarming. You cannot fix what you cannot measure, and WordPress had kept this problem comfortably off the books.
So, who was visiting?
We pulled apart the request logs, and the answer was almost nobody human.
The site was being requested around 1.6 million times a day. It has about 192 pages. Real people do not read the same 192 pages a million and a half times a day. Roughly 99% of it was automated: search engines doing their job, systems watching for breaking news, and commercial scrapers working through every article, repeatedly, around the clock.
The client was paying to deliver their journalism to robots. Those robots do not subscribe, do not read ads, and do not come back as readers. They just ran up the bill.
We could have told the client to buy a bigger plan. We decided to fix it instead.
The clock nobody noticed
Webflow does not punish you the moment you go over. They have something called surge protection, and it is generous. Go over your limit for one month and you are not charged. Go over for a second month in a row and your site is automatically upgraded to a plan that matches what you are using.
We found this about two weeks into the first of those two months. So, a countdown was running that nobody had noticed. If usage had carried on through the next billing cycle, the upgrade would have fired on its own, no conversation required. And when you are running at 40× your allowance, a plan that matches your usage is a very different bill from the one you signed up for.
The window we were working against: Their billing cycle rolled over on the 18th of July. The last of the fixes went live on the 16th. Two days.
Fix one: stop answering the door every time
We put a middleman in front of the site using Cloudflare. Think of it as a receptionist who keeps photocopies. The first time someone asks for a document, it fetches the original. For the next thousand people who ask, it hands out copies and never bothers the original again.
All those bot requests started hitting the receptionist instead of the client’s hosting. Their bill only counts the originals, and those dropped from millions to almost nothing. This is exactly what Cloudflare is built for. When a site really is fielding traffic at this scale, putting Cloudflare in front of it acts as a shield, soaking up the overwhelming majority of requests so they never reach the site itself, never slow it down, and never bill against it.
In a case like this one, that is the difference between a problem you manage and a problem that quietly manages you.
Fix two: a handful of enormous images
A few pages carried large, animated images, several megabytes each. Not much on their own but multiply them by relentless bot traffic and those files accounted for most of what was left.
We suggested converting them to video, which would have cut them by about 95%. The client preferred to keep them as they were, which is entirely their call. So, we solved it another way. We now keep our own permanent copies of every image. Each file gets fetched from the client’s hosting once, ever, and served from our copy after that.
Then it got strange
The numbers still would not settle. Some days spiked for no clear reason. Sites like this have a side entrance, a technical address sitting behind the public one that visitors never see. Someone had found theirs and was pulling articles straight through it, going around Cloudflare and everything we had built. So, we closed it. Anything arriving there now without the right credentials gets turned away before it costs anything
The door nobody thought to check
The bill still moved, and this one took us longest to find, because it was in the last place anyone looks. Most sites have a staging version, a private copy for previewing changes before they go live. It is not linked anywhere and does not show up in search, so everyone forgets it is there.
Theirs was switched on. It was serving a complete second copy of the site, with a public index listing every single page, effectively a menu for anyone who wanted to download the lot. The scraper had found it and was working through it methodically. Every page came off the client’s bill, and because that copy sat outside everything we had built, none of our defences could even see it happening.
We switched it off. It stopped within the hour.
Where it landed
Their 50GB monthly plan now comfortably covers a full month with room to spare. No upgrade, no add-ons, no awkward invoice. The scraper is still out there. We watched it hitting the site again this week. It just does not cost anybody anything now.
What we would tell anyone migrating a site
- Check what the new platform charges for. Same site, same visitors, completely different bill. That is not a reason to fear metering. It is a reason to want it.
- Treat a platform that meters you as an ally. The metering did not put this traffic on the site. It made it visible, which is the only reason we could shut it down. A platform that hides your real traffic is not saving you money, it is deferring a bill you cannot see and cannot fix.
- Find out who your traffic really is. For this client, 99% of requests were not people. If you pay per visit, that ratio matters enormously.
- Check the doors you forgot about. The most expensive problem here was not the clever one. It was a staging site someone left switched on, quietly handing out free copies for weeks.
The takeaway: A migration is a change of billing rules as much as a change of platform. Know your real traffic, and audit every door, public, private, and forgotten before the meter starts.
