Реален WooCommerce казус: bot traffic, add-to-cart заявки, Action Scheduler и 503 грешки

Един онлайн магазин може да изглежда сравнително малък по брой реални посетители и въпреки това да изчерпва процесор, памет и PHP ресурси на сървъра.

Причината невинаги е „лош хостинг“, тежка тема или прекалено много клиенти едновременно. Понякога истинският проблем е автоматизираният трафик.

Crawler-и, SEO роботи, AI ботове, социални мрежи, кеширащи услуги и автоматизирани клиенти могат да генерират десетки хиляди заявки към WordPress. А когато тези заявки достигат до динамични WooCommerce функции като add-to-cart, натоварването вече може да бъде многократно по-високо от обикновено зареждане на изображение или CSS файл.

В тази статия разглеждаме реален случай от поддръжката на WooCommerce магазин, при който периодични HTTP 503 Service Unavailable грешки се оказаха резултат не от един конкретен проблем, а от съвпадението на няколко различни източника на автоматизирано натоварване.

Първият сигнал: огромен процент robot traffic

Проблемът започна с наблюдение, че делът на посещенията, определяни от системата като Unknown robot, е необичайно висок.

При първоначалния анализ за едно денонощие бяха отчетени 90 266 GET заявки, от които над 57 000 bot/crawler заявки. Само четири мрежи, свързани с WP Rocket SaaS, бяха генерирали повече от 50 000 заявки.

На този етап първият логичен въпрос беше: трябва ли просто да блокираме всички ботове? Отговорът е не.

Не всеки бот е лош бот

Това е едно от най-важните правила при оптимизацията на WordPress сайт. Сред автоматизираните клиенти може да има Googlebot, Google AdsBot, Bingbot, Applebot, Meta crawler, AI crawler-и, SEO crawler-и, кеширащи услуги, uptime monitoring системи и собствени WordPress background процеси.

В разглеждания случай логовете показаха Google AdsBot, Googlebot, Applebot, GPTBot и ClaudeBot. Не е добра практика всички подобни роботи да бъдат блокирани автоматично.

Googlebot е важен за органичното индексиране. AdsBot-Google може да бъде необходим за проверка на landing страниците в Google Ads. Meta crawler е необходим за Facebook и Instagram previews.

Първият голям виновник: WP Rocket SaaS

В първия етап бяха блокирани редица ненужни crawler-и, както и WP Rocket bot. По-късно обаче се появи важна подробност.

В рамките на приблизително 16 часа WP Rocket SaaS беше генерирал 23 613 заявки от един User-Agent и 13 966 от друг – общо над 37 000 заявки.

Оказа се, че WP-Rocket-SaaS е бил свързан с функцията Remove Unused CSS. След изключването на тази функционалност новите заявки са спрели. Това е добър пример защо при WordPress не трябва да се блокира механично по User-Agent.

503 не означава задължително „сървърът е слаб“

През следващите седмици магазинът продължава периодично да връща 503 Service Unavailable.

При един от анализите са установени 45 128 HTTP 200 заявки, 8 187 HTTP 429 и 23 HTTP 503. 503 отговорите не са били само към една конкретна страница, а към публични страници, WordPress/WooCommerce заявки и административната част.

Когато 503 започне да се появява на различни места, трябва да се разгледа възможността за изчерпване на PHP workers, CPU/RAM лимити, Entry Processes, IOPS, много едновременни заявки, background tasks и database bottleneck.

Следващата следа: Facebook crawler добавя продукт в количката

През август в логовете се появи особено интересна заявка към продуктов URL, завършващ с ?add-to-cart=3981, при User-Agent meta-externalagent.

Тоест crawler на Meta е посещавал URL, съдържащ WooCommerce параметъра add-to-cart=. Поддръжката също определя това като неправилно поведение за crawler и предприема ограничителни действия.

/produkt/…/?add-to-cart=3981
User-Agent: meta-externalagent

Защо ?add-to-cart= е по-опасен от обикновен crawler URL

Обикновена заявка към /wp-content/uploads/product.jpg може да бъде обслужена директно от web server-а, без да се стартира PHP.

При WooCommerce add-to-cart заявка WordPress трябва да стартира PHP, да зареди WooCommerce, да инициализира session, да прочете cookies, да провери продукта, да обработи cart, да изпълни hooks и често да комуникира с базата данни.

Затова 100 заявки към изображения и 100 add-to-cart заявки могат да имат напълно различен ефект върху сървъра. Анализът само на requests per second не е достатъчен – трябва да се види какъв тип заявки получава сайтът.

Критичният момент: CPU 167%

През септември беше регистриран конкретен resource spike. За интервала приблизително 01:40-01:45 хостинг системата отчита CPU 167%, физическа памет 1.5 GB, 14 PMem faults, максимум 27 процеса и IOPS 1024.

За същите пет минути access log показва 118 HTTP заявки, от които 71 са add-to-cart. От тях 36 завършват с HTTP 200, 34 с HTTP 500 и 1 с HTTP 301.

Това е показателно: не са необходими десетки хиляди заявки за пет минути. Малък брой скъпи динамични операции може да е достатъчен, за да доведе акаунта до resource limits.

Разпределеният bot traffic е по-труден за спиране

Заявките не идваха от един IP адрес, а от множество различни адреси. Част от тях се идентифицираха като Googlebot, Bingbot и YandexBot, а други използваха стандартни Chrome, Edge или Firefox User-Agent-и.

На следващ етап само за част от деня бяха установени add-to-cart заявки от 666 различни IP адреса, като значителна част нямаха referrer.

Това прави класическото IP blocking неефективно. При distributed bot traffic правилният подход е да се блокира поведение, а не конкретен IP.

Важна уговорка: празният Referrer не доказва, че посетителят е бот

HTTP Referer може да липсва и при реален човек – например при посещение от email, Viber, Messenger, mobile application или privacy browser.

Следователно „няма referrer“ не означава автоматично „100% бот“. Но когато едновременно наблюдаваме стотици add-to-cart заявки, стотици различни IP адреси, сходни URL шаблони, празен referrer, необичайно бързо обхождане и resource spikes, това е силен индикатор за автоматизирано поведение.

Допълнителният проблем: WordPress Action Scheduler

Успоредно с външния трафик беше открит и втори източник на натоварване. WordPress Action Scheduler съдържаше 609 pending задачи, от които 561 бяха Rank Math Analytics с hook rank_math/analytics/get_inspections_data.

Имаше и задачи от WooCommerce, MailChimp, Facebook for WooCommerce и други plugins.

Това е важен урок: понякога „бот натоварването“ не идва само отвън. WordPress сам може да генерира сериозен вътрешен товар чрез wp-cron, Action Scheduler, imports, analytics, email queues, feeds, backups и image optimization.

Cron + bot traffic = лошо съвпадение

При един от най-сериозните resource spikes точно в началото на периода е стартирал wp-cron.php. Cron е бил конфигуриран на всеки 10 минути.

Така в един и същ момент са се срещнали WordPress background задачи и динамичен WooCommerce bot traffic. От наличните логове не може категорично да се докаже кой фактор е единствената причина, но комбинацията съвпада с периода на повишено потребление.

При production WordPress системите сривовете често възникват не от един виновник, а от съвпадение на няколко средни по размер натоварвания.

Какво направихме

1. Ограничаване на ненужни crawler-и

Бяха блокирани роботи, които нямаха практическа бизнес стойност за сайта. Сред тях впоследствие беше и ExaSearchBot. Блокирането се прави избирателно, а не по принципа „всичко, което е bot, се блокира“.

2. Спиране на ненужни Rank Math Analytics задачи

След анализ на Action Scheduler бяха спрени ненужните rank_math/analytics/get_inspections_data задачи. След това голямата група Rank Math Action Scheduler задачи изчезна.

3. Спиране на ненужни интеграции

Когато определена интеграция няма реална бизнес стойност, не трябва да остава активна само защото е била инсталирана преди години. В разглеждания случай беше спрян и Mailchimp компонент.

4. Анализ на access log, а не само на WordPress dashboard

Access log показа IP, URL, timestamp, status code, referrer и User-Agent. Именно там се виждаше моделът ?add-to-cart= от огромен брой различни адреси.

Решението на LiteSpeed ниво

Тъй като сайтът работи на LiteSpeed, беше избрано решение чрез .htaccess. Хостинг поддръжката добави следното правило:

<IfModule mod_rewrite.c>
RewriteEngine On

# Проверява дали в Query String-а се съдържа add-to-cart
RewriteCond %{QUERY_STRING} (^|&)add-to-cart= [NC]

# Проверява дали Referrer-ът е празен
RewriteCond %{HTTP_REFERER} ^-$ [OR]
RewriteCond %{HTTP_REFERER} ^$

# Блокира заявката с код 403
RewriteRule ^ – [F,L]
</IfModule>

Правилото проверява две условия: URL съдържа add-to-cart= и заявката няма HTTP referrer. Ако и двете условия са изпълнени, LiteSpeed връща 403 Forbidden.

Защо е важно блокирането да стане преди WordPress

Ако проверката се прави чак чрез PHP plugin, WordPress вече е стартиран, PHP процесът работи, плъгините са започнали да се зареждат и е възможно вече да има заявки към MySQL. При .htaccess/LiteSpeed заявката може да бъде прекратена значително по-рано.

Схема: разлика между блокиране на ниво LiteSpeed/.htaccess и блокиране чак в PHP/WordPress.

Защо не блокирахме всички add-to-cart заявки

WooCommerce използва add-to-cart като легитимен механизъм. Правило, което блокира всяка заявка с add-to-cart, може да засегне и реални клиенти.

По-добрият подход е да се комбинират няколко признака: add-to-cart + липсващ referrer + необичайно автоматизирано поведение. При по-сложни инфраструктури могат да се използват ModSecurity, LiteSpeed anti-DDoS настройки, server-level rate limiting, reverse proxy, WAF или behavioral bot detection.

Защо просто увеличаването на хостинг плана не решава проблема

Ако причината са ненужни автоматизирани заявки, по-мощният сървър просто позволява на ботовете да изразходват повече ресурси.

Правилният ред е: намаляване на безполезния трафик; оптимизация на WordPress; оптимизация на PHP/MySQL/cache; анализ на реалния товар; едва тогава оценка дали е нужен по-висок хостинг план.

Как диагностицираме подобен проблем

Какво означават 403, 429, 500 и 503

HTTP 403

Сървърът съзнателно отказва заявката. В нашия случай това е желан резултат за определен bot pattern.

HTTP 429 – Too Many Requests

Rate limiting или protection layer вече реагира.

HTTP 500

WordPress/PHP обработката е стигнала до вътрешна грешка.

HTTP 503

Сървърът временно не може да обслужи заявката. При shared hosting това често е свързано с достигане на resource limits.

Най-важните уроци от този казус

• Не гледайте само броя посетители – малко на брой динамични заявки могат да бъдат по-тежки от хиляди static assets.
• Не всеки bot traffic трябва да се блокира – част от crawler-ите имат реална SEO, рекламна или социална функция.
• Анализирайте URL-а, а не само IP адреса – distributed bot networks правят IP blocking почти безполезен.
• WooCommerce endpoints заслужават специално внимание – add-to-cart, checkout и AJAX заявки са скъпи.
• Проверявайте Action Scheduler – понякога проблемът е вътре в WordPress.
• Background task + bot spike може да срине иначе нормален сайт.
• Блокирайте възможно най-рано – LiteSpeed/Apache/WAF е за предпочитане пред PHP, когато pattern-ът може безопасно да бъде разпознат там.

Заключение

Периодичната 503 грешка в WooCommerce не трябва автоматично да се диагностицира като „слаб хостинг“.

В този реален случай трябваше последователно да бъдат открити десетки хиляди WP Rocket SaaS заявки, ненужни crawler-и, Meta crawler към add-to-cart, distributed browser-like трафик, стотици WooCommerce add-to-cart заявки, натрупани Rank Math Action Scheduler задачи и съвпадение между WP-Cron и HTTP натоварване.

Едва когато тези данни бъдат поставени върху една времева линия, картината започва да става ясна. Това отличава реактивната от професионалната WordPress поддръжка.

Не е достатъчно сайтът просто да бъде „рестартиран“. Трябва да се установи кой генерира натоварването, към какво, кога, защо и как да бъде ограничен, без да бъде засегнат реалният клиент.

Нуждаете се от WordPress или WooCommerce поддръжка?

В ЛИП Трейд анализираме WordPress и WooCommerce проблеми не само на ниво plugin и административен панел, а и чрез server/access logs, resource usage, PHP и MySQL натоварване, WordPress Cron, Action Scheduler, bot/crawler traffic, caching, security и WooCommerce performance.

Когато онлайн магазинът периодично забавя, връща 500/503 или достига ресурсните лимити, причината рядко може да се открие само чрез „деактивирайте плъгините един по един“. Необходим е анализ на цялата верига – от HTTP заявката до PHP, WordPress, WooCommerce и базата данни.