Visitor Control: Blocking Bad Bots and Unwanted Traffic

Open your PrestaShop back office, go to Stats → Visitors online on a quiet afternoon, and you may see more "visitors" than you have real customers. A large slice of traffic to any store is automated — crawlers, scrapers, scripts, and probes that never intend to buy anything. Some of that automation is the lifeblood of your business: Googlebot has to crawl you to rank you. The rest costs you money. It burns CPU and bandwidth on your hosting, fills your cart tables with junk, skews every conversion number you report, and — in the case of credential stuffers and vulnerability scanners — is the opening move of an actual attack. This guide is about telling those two populations apart on a PrestaShop store, spotting the bad one in your own logs and database, and shutting it out without accidentally locking out Google or a real customer.

This is the bot-and-automation chapter of our security cluster. It deliberately stays in its lane: blocking individual human troublemakers by IP is covered in Customer Extra Info and IP Bans; stopping form spam with a challenge is in reCAPTCHA for PrestaShop; the specific crawler-driven faceted-search overload has its own deep-dive in surviving the ?q= flood; and the web-server rules live in PrestaShop .htaccess security rules. For where bot filtering sits in the bigger picture, start at the complete security hardening checklist.

Reviewed June 2026 against current PrestaShop Stats and SQL Manager behaviour and the verify-Googlebot-by-reverse-DNS guidance still in force.

Not all bots are the enemy — and blocking the wrong ones hurts

The single most expensive mistake merchants make with bot blocking is over-blocking. Ban Googlebot in a fit of "stop the bots" enthusiasm and you don't get a more secure store — you get a store that disappears from search. So the first job is a clear taxonomy, because your blocking rules will treat these two groups in opposite ways.

Notice the implication: a blunt instrument that blocks "bots" by reputation alone is dangerous, because the good and bad lists overlap on the same techniques. Effective filtering is about identity and behaviour, not a single on/off switch.

Spotting bad-bot traffic inside PrestaShop specifically

You don't need a third-party dashboard to see the problem — PrestaShop already records most of it, and your hosting records the rest. Three places to look, in order of effort.

1. The back office stats (the two-minute check)

Under Stats, the Visitors origin, Pages not found, and Best-viewed pages panels are quiet tells. A flood of 404s on paths your store never had (/wp-login.php, /.env, /administrator/) is a vulnerability scanner walking a generic exploit list — those are not even PrestaShop paths, which is exactly how you know it's an indiscriminate bot. A "best viewed page" that is suddenly your login or password-recovery page, not a product, is a credential-stuffing signature.

2. The database (the honest numbers)

PrestaShop logs sessions to ps_connections and ps_guest. Note that ps_guest stores parsed browser and OS attributes (browser, version, operating system, screen resolution) rather than a raw User-Agent string — there is no http_user_agent column in standard PrestaShop, so don't expect to read the literal agent out of the database. What the tables do give you is request volume per IP, which is enough to surface a source that is hammering the store. A query like the one below (run it in Advanced Parameters → SQL Manager, adjust the prefix) ranks recent visitors by hit count:

SELECT c.ip_address, COUNT(*) AS hits FROM ps_connections c WHERE c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY c.ip_address ORDER BY hits DESC LIMIT 50;

A single IP with hundreds of hits in one day is not a customer. A real shopper loads a handful of pages; a scraper walks your entire catalogue in order. To see the actual User-Agent each IP sent — which is where scrapers give themselves away with empty, generic, or scripted agents — read the raw server access log (covered below) or a module that records the raw User-Agent, since PrestaShop's own tables don't keep it verbatim.

3. The cart tables (the PrestaShop tell-tale)

Here is a symptom that is almost unique to PrestaShop and confuses thousands of merchants: dozens of abandoned carts with no customer and no products, appearing in Orders → Shopping Carts. PrestaShop creates a cart row through its cart and session flows the moment an add-to-cart endpoint is touched. Empty guest carts can be generated by a number of things — bots and crawlers, modules that pre-create carts, or ordinary session behaviour — so don't assume a specific crawler is responsible. Confirm from your logs which source actually hit the endpoint before you blame, block, or whitelist any one crawler. The carts are real database rows, but in these cases they are artefacts, not lost sales, and the fix is to recognise and purge them rather than to block a crawler you haven't confirmed created them. We pulled this apart in our note on bot-created carts; the practical takeaway is that empty guest carts are usually a logging quirk, not an emergency.

4. The server access log (the ground truth)

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Your raw access log shows every request with its IP, User-Agent, and timing — the ground truth your analytics can't fake because JavaScript-based analytics never even fires for most bots. Look for one IP requesting product pages in perfect sequential order, requests with no User-Agent, and bursts of hits to /login, /password-recovery and create-account. That log is also where you'll confirm whether a "Googlebot" is the real thing — genuine Googlebot resolves to a googlebot.com / google.com host on a reverse DNS lookup; a fake one claims the name but resolves to a random data-centre IP.

The defense ladder: cheapest and broadest first

Bot filtering works in layers, and the smart order is to start with the controls that stop the most traffic for the least effort and the lowest risk of a false positive. You climb the ladder only as far as your problem demands.

robots.txt — set expectations, not a barrier

PrestaShop can generate a sensible robots.txt for you under Shop Parameters → Traffic & SEO → SEO & URLs → Generate robots.txt. It tells well-behaved crawlers to skip your cart, checkout, search results, and account pages — which trims crawl waste from the bots you want to keep. Understand its limit clearly: it is honoured by good bots and ignored by bad ones, so it is a crawl-budget tool, never a security control. Don't list a path there hoping to hide it; you're publishing a map of what you'd rather people didn't see.

The edge WAF — the highest-leverage step

Putting Cloudflare (or a comparable WAF) in front of the store moves the fight off your hosting entirely: known-bad IPs, requests that don't look like a real browser, and volumetric floods get filtered at the edge before they ever reach PHP. On the free tier you get bot-fight mode, an IP reputation database, browser-integrity checks, and basic rate-limiting rules — enough to take the majority of junk automation off your server's plate. For most small and mid-size PrestaShop stores this one move does more than everything else combined, and it's the same edge layer you'd lean on harder when crawler traffic turns into the faceted-search ?q= flood that can knock a store over.

Rate limiting — separating humans from scripts by speed

A real customer browsing loads maybe five to ten pages a minute; a scraper walking your catalogue loads a hundred. A per-IP rate limit (returning HTTP 429 once a threshold is crossed) catches that gap automatically. It's most reliable at the edge (Cloudflare) or web-server level. Tune it generously — set the ceiling well above human browsing so a shared office or mobile-carrier IP, where many real customers sit behind one address, isn't punished for being busy.

Form challenges and honeypots — for the targeted forms

Scrapers want your pages; spam bots want your forms. The registration, login, contact, and newsletter forms are where automated submissions concentrate, and an invisible challenge stops them without nagging real shoppers — that's its own topic in reCAPTCHA for PrestaShop. A honeypot complements it: a hidden field a human never sees but a dumb form-filler obligingly completes, flagging itself as a bot at zero cost to your customers.

Blocking by identity, from the PrestaShop back office

The layers above are infrastructure. But you also want a control you can reach without SSH or a developer — a place to say "this country sends me only fraud and scrapers, challenge it" or "this hosting-range User-Agent is hammering my login, block it" directly from the admin. That's the application layer, and it's where doing it natively in PrestaShop pays off: the block happens with full session context (it knows the customer group, the country, the agent), and it survives theme and core upgrades because it isn't bolted into server config files you'll forget about.

One caution before you reach for an IP block: be surgical with IP bans. Residential and mobile IPs are recycled — today's scraper IP can be tomorrow's paying customer on the same carrier. Block individual residential IPs only as a short, reviewed measure; reserve permanent IP-range blocks for data-centre and VPN ranges where no real customer lives. (Banning a specific abusive person by IP is a different job, handled in Customer Extra Info and IP Bans.) For broad strokes, country and user-agent rules are usually safer and lower-maintenance than chasing individual addresses.

Where Visitor Control fits

Visitor Control stores shop-specific block decisions in the back office.

Whitelisting trusted networks keeps broad block rules from catching your own team.

The collected visitor table is ps_mprvc_info. This quick check shows whether one country or device type is dominating recent traffic:

SELECT country_code, device_type, COUNT(*) AS hits
FROM ps_mprvc_info
WHERE date_add > DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY country_code, device_type
ORDER BY hits DESC
LIMIT 20;

This is exactly the gap our Visitor Control module was built to close. It does two jobs from inside the back office, with no server-level configuration and no external service to wire up. First, it blocks unwanted visitors by IP, country, or User-Agent — so you can quietly turn away a known scraper agent or a country that only ever sends you card-testing traffic, using PrestaShop's own request handling rather than hand-edited .htaccess lines. Second, it surfaces who your visitors actually are: device, IP, and country shown right on the customer profile, so when you're deciding whether a pattern is a bot or a real buyer, you're working from evidence instead of a guess. So what does that get you? The decision to block or allow stops being a server-admin task you put off and becomes a two-minute call you make from the same screen where you run the store — and because it's a module, the rules ride through your next PrestaShop upgrade intact.

For the PrestaShop-specific bot-cart noise described earlier — the empty guest carts that distort your back-office counters — the dedicated tools are on the cart side of the house, tagging and purging bot carts without blocking the crawlers that legitimately create them. The point of separating these jobs is precision: you filter the traffic you don't want while keeping the bots that earn you rankings and the indexing that earns you sales.

A practical layered setup for a normal store

You do not need an enterprise bot-management contract to handle the everyday flood. For a typical PrestaShop store, this stack stops the large majority of bad automation with little setup and essentially no risk to real customers:

• Put Cloudflare's free tier in front of the store — the biggest single reduction in junk traffic, at the edge, before it costs you a CPU cycle.
• Generate a proper robots.txt from Traffic & SEO so good crawlers skip cart, search, and account pages and spend their budget on products.
• Add an invisible challenge to register, login, contact, and newsletter forms.
• Block by country and User-Agent for the patterns you've confirmed are bots, from the back office, and keep IP bans short and targeted.
• Skim your logs and the SQL Manager query monthly — block confirmed repeat offenders, and verify any suspicious "Googlebot" by reverse DNS before you trust it.

Frequently asked questions

Will blocking bots hurt my Google ranking?

Only if you block the wrong ones. Search crawlers (Googlebot, Bingbot) and social unfurlers need to reach you — block them and your pages drop out of search over the following weeks, or shared links render with no preview. The whole job is telling those apart from scrapers, credential stuffers, and vulnerability scanners. Block by confirmed identity and behaviour, verify any "Googlebot" by reverse DNS before trusting it, and you reduce junk traffic without touching the bots that bring customers.

Why does my store have so many empty abandoned carts with no customer?

PrestaShop creates a cart row the moment an add-to-cart endpoint is touched, so empty guest carts can come from bots, crawlers, modules that pre-create carts, or ordinary session behaviour. They're real rows but usually artefacts, not lost sales. Don't assume a specific crawler is responsible — confirm from your access log which source actually hit the endpoint, then purge the noise rather than blindly blocking a crawler you haven't confirmed created it.

Is robots.txt enough to keep bad bots out?

No. robots.txt is honoured by good crawlers and ignored by bad ones, so it's a crawl-budget tool, never a security control. It's worth generating (Traffic & SEO → Generate robots.txt) to stop polite crawlers wasting budget on cart, search, and account URLs — but never list a path there hoping to hide it, because you're publishing a map of what you'd rather people didn't see. For the bots that ignore it, you need the edge WAF, rate limiting, and identity-based blocking.

What's the single highest-impact thing I can do?

For most small and mid-size stores, put Cloudflare's free tier (or a comparable WAF) in front of the store. It filters known-bad IPs, obvious non-browsers, and volumetric floods at the edge before they ever reach PHP, and on the free tier you still get bot-fight mode, IP reputation, browser-integrity checks, and basic rate limiting. That one move typically does more than everything else combined.

Should I ban scraper IP addresses permanently?

Be surgical. Residential and mobile IPs are recycled — today's scraper IP can be tomorrow's paying customer on the same carrier — so block individual residential IPs only as a short, reviewed measure. Reserve permanent range blocks for data-centre and VPN ranges where no real customer lives, and prefer country and User-Agent rules for broad strokes, since they're safer and lower-maintenance than chasing individual addresses.

The mindset that keeps this safe is the one we opened with: the goal is never "block bots," it's "block the bots that take from you while welcoming the ones that bring customers." Get the taxonomy right, read your own store's evidence before you swing the hammer, and add layers only as far as your traffic forces you to. Done that way, bot filtering is one of the quieter wins in store security — invisible to the customers who matter, and a steady drain stopped on the resources, the analytics, and the attack surface you'd otherwise be handing to scripts. When you're ready to fit this into the rest of your defenses, the security hardening checklist and the plain-English store-owner security guide tie the whole cluster together.