You open your analytics and something is badly wrong. There are fifty people on the site at once. They are in countries you have never sold to. Each one arrives, stays a few seconds, and vanishes. By the end of the day you have had twenty thousand visitors instead of the usual few hundred.
The first thought is almost always the same one: have we been hacked?
Usually, no. What you are looking at is a scraper, and it is worth understanding because the obvious defences do not work on it.
Someone wants your product catalogue. Your prices, your descriptions, your stock levels, your images. They might be a competitor watching what you charge, a marketplace building a comparison listing, or a reseller planning to undercut you.
Rather than visit your site politely from one address, they rent access to a proxy network. These sell exactly what the name suggests: a pool of ordinary residential and mobile internet connections, all over the world, that traffic can be routed through. The scraper sends one or two requests through an address in Bangladesh, then a couple more through South Africa, then Thailand, then Brazil, and on through tens of thousands of addresses in a day.
That is why your analytics look so strange. Every one of those addresses is counted as a separate visitor, arriving from wherever the exit node happens to be, staying only as long as it takes to fetch a page. Nobody is really there.
Worth saying plainly, because it is the part that keeps people awake. A scraper is not logging in. It is not attacking your admin area, it is not probing for injection flaws, and it is not touching customer data. It is reading the same public pages any shopper can read, just far faster and far more thoroughly.
Your store is not compromised. What you are paying is a different bill: server load, bandwidth, and analytics that have become useless. If the crawl is heavy enough it can slow the site for real customers, and on a busy shared server it can push an account into its resource limits.
There is also a commercial cost that is easy to miss. Somebody is building a copy of your catalogue, and they did not ask.
This is the useful part, because the three things most people try first all miss.
Blocking countries. The natural reaction to a list of unfamiliar countries is to block them. It rarely helps. A proxy network has exits nearly everywhere, so a rule covering fifteen or twenty countries simply means the traffic arrives from the ones you did not list. We have watched exactly this: a country rule covering seventeen countries, and the crawl arriving from a dozen others, none of them on the list. You can keep adding countries until you have blocked most of the internet, and real customers will start hitting the wall long before the scraper does.
Turning the security level up. Cloudflare and similar services can challenge visitors whose IP address has a poor reputation. That is genuinely effective against compromised servers and known-bad hosts. It is much weaker against residential proxies, because the whole point of that product is that the addresses belong to ordinary broadband and mobile customers with clean reputations. Turning the dial up is worth doing anyway, but do not expect it to solve this on its own.
Rate limiting. Limiting how many requests one address may make in a minute is a sound defence against a noisy bot hammering you from one place. It does nothing here. When more than nine in ten of the addresses make fewer than five requests each before rotating away, there is no per-address rate left to limit.
The scraper can change its address, its country and the browser it claims to be. What it cannot change is what it came to do.
A scraper harvesting a catalogue behaves in a way no shopper does. It walks methodically through every product. On a store that offers several currencies and languages, it will often fetch every product in every currency and every language, because it wants the complete data set. That multiplies the number of pages enormously, which is why the visit count looks so absurd.
A real customer might switch currency once at the start of a session. A scraper switches currency on thousands of pages in an hour. That difference is the signature, and it is a far more reliable one than an address or a country.
The fix is to challenge that specific behaviour at the edge, before it ever reaches the site. A challenge is not a block: a real browser solves it automatically in the background, and the visitor carries on, typically without seeing anything more than a brief pause. Most automated tools cannot solve it at all, and a scraper rotating through thousands of fresh addresses is challenged again every single time, because it never keeps the clearance it would need.
Done this way the crawl stops reaching the server almost immediately, while genuine shoppers keep browsing, keep switching currency, and keep checking out.
We see it often on CubeCart stores, and there is a reason. A CubeCart shop with several currencies, several languages and filterable categories has a very large number of valid URLs for what is really the same catalogue. That is excellent for customers and unfortunately just as convenient for anyone harvesting it.
But nothing here is specific to CubeCart. Any site with parameters in its URLs has the same shape of exposure. A WordPress site with filtered archives, a property site with search facets, a directory with sort options, a booking system with date ranges. If the same content can be reached through many URL variations, a scraper can and will enumerate them.
Start by confirming what it is rather than assuming. Two questions settle it quickly. How many distinct addresses are involved, and how many requests did each one make? A handful of addresses making thousands of requests is a different problem with a different fix. Tens of thousands of addresses making one or two requests each is a rotating proxy network, and you should stop thinking about addresses altogether.
Then look at what they are requesting. If there is a pattern that no human would produce, that pattern is your defence.
Check whether it is actually costing you anything before you panic. Scraping is annoying and it distorts your reporting, but if the server is comfortably absorbing it, you have time to fix it properly rather than in a hurry.
Finally, be careful about what you measure afterwards. When the fix works your visitor numbers will fall sharply, and that is not lost business. It is the fake traffic leaving. Your real sales figures will not move, which is precisely the point.
If you host with us and your traffic has done something inexplicable, open a ticket and we will look at the logs with you. Working out whether it is a scraper, a genuine attack or an unexpected burst of real interest takes us a few minutes, and it is much better than guessing.