# 166 000 посещения за един ден и нито една продажба > Canonical: https://jethost.bg/blog/woocommerce-bot-traffic-cloudflare/ · Last modified: 2026-09-18T12:59:27+00:00 Високият трафик към един онлайн магазин обикновено е добра новина. Но когато сайтът започне да се бави точно в момента, в който статистиката показва рязък скок в посещенията, картината може да се окаже съвсем различна. Наскоро попаднах точно на такъв случай при WooCommerce магазин на наш клиент. Сайтът ту се зареждаше нормално, ту започваше да се бави, а в статистиките се виждаха над 166 000 посещения само за един ден - необичайно много за иначе сравнително спокоен онлайн магазин. На пръв поглед изглежда като страхотен ден за магазина. Само че зад тези посещения не стояха потенциални клиенти, а ботове, които обхождаха продуктовите филтри и генерираха огромен брой заявки към сървъра. В тази статия ще покажа как открихме откъде идва натоварването, какво общо имаха WooCommerce филтрите с него и как едно Cloudflare правило промени ситуацията. ## Какво всъщност се случваше Ако имаш WooCommerce магазин (в случая с тема WoodMart), филтрите за цвят, размер, цена, наличност и подредба генерират URL адреси с query параметри, като това: `/shop/?filter_color=black` `/shop/?filter_size=large&query_type_size=or` `/shop/?min_price=50&max_price=100&orderby=price` `/shop/?filter_category=lighting&stock_status=instock` За човек това са няколко клика. За ботовете е като детска площадка. Комбинираш няколко цвята, два размера, ценови диапазон и подредба, и изведнъж имаш десетки хиляди уникални адреса. Всеки от тях изглежда като нова страница. Тези адреси почти не се кешират. Кеш плъгинът пази нормалните страници, но всяка нова комбинация филтри е „студена" заявка. След първо зареждане, тя се кешира, но почти няма втора заявка с тази комбинация. Google описва точно този проблем под името faceted navigation и е добре известен казус. Накратко - изглеждаше като трафик. А всъщност беше атака, само че възпитана, в по-учтивата си версия. ## Как изглежда това от гледна точка на сървъра Нека да погледнем и графиките на натоварването. Времето на скриптовете и базата достигаше от около 5000 до 6000 минути на ден. Това не е CPU процент, а чисто време, в което процесорите са заети с обработка на заявките. Няма грешки в логовете, няма проблемен плъгин. CPU-то е на 100%, паметта е на максимум, а причината са заявките с `?filter_` в адреса. ## Решението с Cloudflare правило Наскоро попаднах на статия в блога на WoodMart, в която екипа споделят за казуса и дават обяснение. Тествах я с реален казус и си свърши работата, затова я разказвам от първо лице. В Cloudflare отиваш на **Security → Security rules → Create rule → Custom rules** и пускаш **Managed Challenge** за заявки, които съдържат филтърните параметри: `(http.request.uri.query contains "filter_") or ` `(http.request.uri.query contains "per_page=") or ` `(http.request.uri.query contains "per_row=") or ` `(http.request.uri.query contains "shop_view=") or ` `(http.request.uri.query contains "stock_status=") or (http.request.uri.query contains "min_price=") or ` `(http.request.uri.query contains "max_price=") or ` `(http.request.uri.query contains "orderby=")` Какво прави това? Когато има заявка с филтър в адреса, Cloudflare показва Managed Challenge, преди тя изобщо да стигне до сървъра. Истинският посетител минава през него веднъж и продължава към сайта. Ботовете не преминават тази проверка. Резултатът - от над 184 хиляди заявки, над 179 хиляди бяха блокирани. Пиковете на потребление на процесорите, които виждах преди, просто изчезнаха. И най-важното - сайтът спря да се бави. ## Бъди внимателен, когато го прилагаш Преди да копираш правилото едно към едно, прочети нататък. Има няколко особености. **Managed Challenge и AJAX не са най-добри приятели.** WoodMart филтрите работят през AJAX, а challenge страниците на Cloudflare не се разбират идеално с XHR заявки. На практика първата филтърна заявка се отваря като нормална страница с challenge, минаваш го, и оттам нататък AJAX филтрирането работи нормално. Точно затова го тествай - провери първия филтър, после още няколко, на десктоп и на телефон. Ако се покаже challenge съдържание, не пускай правилото в този вид. **„filter\_" е широко обхватно, и то нарочно.** Хваща `filter_color`, `filter_size`, `filter_category` и всичко друго, което започва с `filter_`. Удобно е, но ако някъде другаде в сайта се използва същият текст, може да се филтрира и легитимен трафик. След като пуснеш правилото, гледай Security Events в Cloudflare няколко дни и пренареди при нужда. **Правилото пази магазина, но не мисли вместо теб за SEO.** То спира натоварването, не управлява индексирането. Затова са `robots.txt`, canonical адресите и SEO настройките на магазина. Пример за robots.txt: `User-agent: * ` `Disallow: /*?*filter_ ` `Disallow: /*?*min_price= ` `Disallow: /*?*max_price= ` `Disallow: /*?*orderby=` И понеже злонамерените ботове весело пренебрегват robots.txt, той не замества Cloudflare правилото, а върви заедно с него. **Googlebot е отделен разговор.** Cloudflare може да разпознава верифицирани ботове (`cf.client.bot`). Можеш да пуснеш Googlebot да минава без challenge, за да не пипаш обхождането, но тогава пращаш повече заявки към сървъра. Или го ограничаваш и пестиш ресурс, но внимаваш какво става с индексирането. Зависи от SEO стратегията на конкретния магазин, универсален отговор няма. ## И така Не всеки скок в статистиките е добра новина. Понякога 166 000 „посещения" означават натоварен сървър и нула продажби. Хубавото е, че за този конкретен сценарий, WooCommerce и WoodMart филтри, обхождани от ботове, решението е сравнително просто с Cloudflare. Оригиналната статия на екипа на WoodMart, върху която стъпих: