Gdy agencja premium zamyka boty AI w limbo, wyrzucając sklep z indeksu bez wiedzy klienta

DISCLAIMER: Nie ma NDA w tej sprawie i nasz klient wyraził zgodę na publikację fragmentów w celach edukacyjnych. Natomiast CEO firmy XXXXX wykonującej sklep nie jest dla nas stroną, nigdy nie byłem podwykonawcą takiej firmy. Przedstawione logi i fragmenty kodu zostały zanonimizowane, ale zachowują oryginalną strukturę problemu. Moim zdaniem nazwa wykonawcy nie ma znaczenia, ponieważ tego typu błędy w kontekście indeksacji AI natrafiamy u wszystkich wykonawców oraz firmach bawiących się w hosting aplikacji, sklepów, stron internetowych.

Rok 2024, ale także 2025, to przełomowy okres dla specjalistów ogarniających aplikacje i rozwiązania w internecie. Jeśli chodzi o indeksowanie w AI search, monitorowanie anomalii i dbanie o to, aby treści były poprawnie interpretowane, mamy prawdziwą “gorączkę”. Realizujemy działania na poziomie aplikacji, wdrażamy rebranding w erze AI, ale przede wszystkim non stop czuwamy nad procesem indeksacji i reindeksacji, co realizujemy dzięki budowie customowych rozwiązań. W tym konkretnym przypadku klient zatrudnił mnie jako “bezpiecznik”, aby dopilnować, że renomowany wykonawca sklepów e-commerce dowiezie gotowy produkt. Nie mam intencji krzywdzenia kogokolwiek, dlatego ze względów biznesowych anonimizuję wykonawcę. Serwer, optymalizacja i DevOps leżały po naszej stronie. Ale przede wszystkim analiza problemów, których - jak widać - sam wykonawca nie do końca rozumiał, co w erze AI ma dramatyczne konsekwencje.

Jak się znaleźliśmy w tym bałaganie

Na początku 2025 roku, o czym pisałem w jednym z artykułów, zaczęło się poważne skanowanie sklepów pod kątem AI-search. Na dużych wdrożeniach z setkami tysięcy linków i środowiskiem multidomain dawało to miliony URL-i i dziesiątki jednoczesnych wejść na serwery, powodując gwałtowne skoki utylizacji zasobów (CPU/IOPS), co wymuszało nie tylko gimnastykę optymalizacyjną i skalowanie, ale także szukanie dziury w całym jeśli chodzi o źle napisane aplikacje. Dzisiaj opisuję projekt, który miał być dowieziony przez firmę XXXXX w drugiej połowie zeszłego roku, ale jak to bywa z cudami developmentu, termin był przesuwany wielokrotnie, aż wersja produkcyjna weszła w drugim kwartale 2025 z wielkim bólem i płaczem.

Monitorując sklepy za pomocą Prometheus, grafana, Uptime oraz konkretnych logów i własnych rozwiązań, widzieliśmy, że od początku nowa aplikacja zachowywała się delikatnie mówiąc dalece niestabilnie jak na coś nowego i mającego przebić poprzedni produkt tej firmy sprzed kilku lat. Zgłosiliśmy szereg uwag. Na początku zwracaliśmy klientowi uwagę, że wykonawca niepoprawnie obsługuje framework PHP, używając override’ów w miejscach, które nie są bezpieczne i zgodne ze sztuką - powodowało to kuriozalne żądania zmiany polityki dostępu do plików przez usługę NGINX, niezgodnej z zasadami bezpieczeństwa i rozsądkiem. Jednak tutaj focus to przede wszystkim indeksacja i reputacja w wynikach wyszukiwania, dlatego klient dał zielone światło na analizę problemów na tym polu. Logi serwera, debug php, mysql slowlog oraz kilka innych autorskich rozwiązań nakierowało mnie na szereg poważnych błędów, bo dla mnie serwer to zawsze wąskie gardło indeksacji.

Zróbmy sobie DDOSa głupim błędem i zablokujmy indeksowanie

Czytając sygnały z serwera i analizując logi, zauważyłem niepokojącą anomalię na wielu poziomach. Ale przede wszystkim skupiłem się na botach AI, które wpadały w limbo, ale również proces indeksacji w Google Search nie przebiegał tak, jak powinien. Widzieliśmy cały czas “oranie” zasobów i powtarzające się odwołania do modułu ####_######## autorstwa renomowanego, żeby nie powiedzieć topowego, software house’u. W raporcie przedstawionym klientowi napisaliśmy:

“Analizując logi wykryliśmy znaczący problem wydajnościowy związany ze sposobem generowania adresów URL dla obrazków i GIF-ów, które są zarządzane bezpośrednio w module. Nieprawidłowa implementacja mechanizmu zapobiegania buforowaniu (cache-busting) skutkuje całkowitym brakiem buforowania grafik po stronie przeglądarek użytkowników, co prowadzi do niepotrzebnego obciążania serwera.”

W plikach modules/####_########/src/Entity/BoxImage.php i modules/####_########/src/Entity/BoxGif.php znaleźliśmy ten oto fragment:

$link = \Context::getContext()->shop->getBaseURL(true) . 'modules/####_########/img/'.$hash.'.jpg?rand='.time();

Jeśli skorelować to z anomaliami w logach i utylizacją zasobów, to już nie jest niewinna technika cache-busting. To jej karykatura. Boty w kółko odpytywały o te same zasoby, bo te przy każdym odpytaniu były inne. Dodawanie znacznika czasu time() do URL-a sprawia, że każda sekunda generuje unikalny adres dla tego samego pliku. W audycie ujęliśmy to następująco:

“Błąd wynika z nieoptymalnej i niepoprawnej implementacji mechanizmu cache-busting. (…) Przeglądarki internetowe traktują każdy taki URL jako nowy zasób, co całkowicie uniemożliwia ich buforowanie.”

Co najgorsze, ta “technika” była kompletnie zbędna. System obsługiwał tak nazwy plików, że zawierały już unikalny hash (np. ddaf4fab11387b0956cb83.jpg), który jest poprawnym i wystarczającym mechanizmem wersjonowania. Ktoś nie tyle nie rozumiał mechanizmu cache systemu w którym robił produkcyjne rozwiązania za ciężkie pieniądze, co nie rozumiał wdrażanych przez siebie rozwiązań i nie analizował ich konsekwencji przepalając bezmyślnie dziesiątki roboczogodzin.

Kaskada problemów - Wąskie gardło jeszcze węższe

Wadliwy kod prowadził do kaskady problemów, które paraliżowały sklep na trzech kluczowych płaszczyznach.

1. Palenie zasobów serwera w czasach AI

Każde odświeżenie strony, zarówno przez klienta, jak i w panelu administracyjnym, zmuszało serwer do ponownego serwowania wszystkich grafik, ignorując cache. W audycie wskazaliśmy na bezpośrednie konsekwencje:

“Zwiększona liczba operacji I/O (odczyt z dysku) i wywołań systemowych. Wzrost utylizacji CPU. (…) W panelu administracyjnym, gdzie często renderowane są listy z wieloma obrazkami (np. 10 obrazków zarządzanych przez ten moduł), oznacza to 10 niepotrzebnych operacji time() i 10 operacji file_exists() przy każdym załadowaniu listy.”

2. Rujnowanie SEO i Core Web Vitals

Brak buforowania grafik to prosta droga do katastrofy wskaźników Core Web Vitals. Strona ładowała się wolniej, co bezpośrednio uderzało w doświadczenie użytkownika (UX) i negatywnie wpływało na metrykę LCP (Largest Contentful Paint) - kluczowy czynnik rankingowy Google ale także AI, który jest łakomy na dane ale wartościowe. To prosta droga do obniżenia reputacji SEO w Google oraz AI search.

3. Mielenie botów AI w cyfrowym czyśćcu (Limbo)

To najciekawszy i najbardziej aktualny aspekt problemu. Analiza logów Nginx pokazała smutną prawdę. Boty w tym między innymi OpenAI, GPTBot/1.2, wpadał w nieskończoną pętlę, co sekundę pobierając ten sam obrazek pod nowym adresem URL. Generowało to pętle indeksowania, powodując nie tylko, że bot obniżał scoring strony, ale po prostu “zajeżdżał” sklep z ponad pół milionem linków. Ciekawe doświadczenie patrząc na taki DDOS.

Fragment z logów serwera:

20.171.207.141 - - [11/Jun/2025:15:48:11 +0200] "GET
/modules/xxx_xxxxxxxx/img/d660c5fdf9db6e050e71145baa5288bd.jpg?
rand=1749440056 HTTP/2.0" 200 1290 "-" "Mozilla/5.0 AppleWebKit/537.36
(KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"
20.171.207.141 - - [11/Jun/2025:15:48:12 +0200] "GET
/modules/xxx_xxxxxxxx/img/d660c5fdf9db6e050e71145baa5288bd.jpg?
rand=1749536867 HTTP/2.0" 200 1290 "-" "Mozilla/5.0 AppleWebKit/537.36
(KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"
20.171.207.141 - - [11/Jun/2025:15:48:13 +0200] "GET
/modules/xxx_xxxxxxxx/img/e1108cd8ab63f69d6b3424ef92bbfc1c.jpg?
rand=1749442057 HTTP/2.0" 200 1383 "-" "Mozilla/5.0 AppleWebKit/537.36
(KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"
20.171.207.141 - - [11/Jun/2025:15:48:14 +0200] "GET
/modules/xxx_xxxxxxxx/img/d660c5fdf9db6e050e71145baa5288bd.jpg?
rand=1749451667 HTTP/2.0" 200 1290 "-" "Mozilla/5.0 AppleWebKit/537.36
(KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"
20.171.207.141 - - [11/Jun/2025:15:48:15 +0200] "GET
/modules/xxx_xxxxxxxx/img/e1108cd8ab63f69d6b3424ef92bbfc1c.jpg?
rand=1749579404 HTTP/2.0" 200 1383 "-" "Mozilla/5.0 AppleWebKit/537.36
(KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"
20.171.207.141 - - [11/Jun/2025:15:48:16 +0200] "GET
/modules/xxx_xxxxxxxx/img/d660c5fdf9db6e050e71145baa5288bd.jpg?
rand=1749531699 HTTP/2.0" 200 1290 "-" "Mozilla/5.0 AppleWebKit/537.36
(KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"

Wydawało mi się, że prosta analiza logów, ale także w przypadku problemów z dowiezieniem niestabilnej aplikacji, jakiś elementarny przymus i przyzwoitość zmuszą do przemyślenia, co powoduje drenowanie potencjału indeksowania. Wykonawca w postaci CEO w rozmowie stwierdził, że w logach jest zbyt duży szum, aby dało się z nich wyczytać coś sensownego (pozwólcie, że nie będę tego komentował). W audycie podsumowaliśmy to zagrożenie jednoznacznie:

“Skutkuje to nieefektywnym zużyciem zasobów przeznaczonych na indeksowanie strony (crawl budget), wielokrotnym pobieraniem tych samych zasobów pod różnymi URL-ami oraz brakiem możliwości utrzymania stabilnego indeksu dla danego widoku. W efekcie, może to negatywnie wpłynąć na reputację wyników, sugerując występowanie duplikatów zasobów.”

Absurdalnie proste rozwiązanie krytycznego błądu implementacji

Naprawa tego krytycznego błędu generującego dziesiątki roboczogodzin po stronie wykonawcy jest trywialna i zajmuje dosłownie 15 sekund. Chociaż zaznaczam, że to nie jedyny problem - znaleźliśmy znacznie więcej na poziomie zapytań do MySQL. W tym konkretnym przypadku wystarczyło usunąć wadliwy fragment kodu.

PRZED:

$link = $baseURL . 'modules/####_########/img/'.$hash.'.jpg?rand='.time();

PO:

$link = $baseURL . 'modules/####_########/img/'.$hash.'.jpg';

Tyle. Po tej zmianie należało jedynie wyczyścić pamięć podręczną sklepu i zacząć na nowo reindeksację. Utylizacja CPU spadła znacząco przy wejściach botów AI.

Brak zainteresowania w optymalizacji procesów biznesowych

Przygotowałem szczegółowy, 9-stronicowy raport techniczny, zawierający analizę kodu, dowody z logów, wykresy obciążenia i precyzyjne instrukcje naprawcze. Raport powstał na życzenie klienta, ponieważ renomowany software house twierdził, że “to wina serwera, bo u nich działa”. Dokument trafił do mojego klienta oraz do CEO agencji odpowiedzialnej za wdrożenie. Zaproponowałem symboliczne wynagrodzenie za wskazanie błędu, który funkcjonuje na szeregu sklepów ich klientów. Dałem im kilka dni na odpowiedź.

CEO nie był finalnie zainteresowany. Pomimo że tego typu błędy znaleźliśmy na innych sklepach tego wykonawcy, uznał, że problem go nie dotyczy, bo fix został wdrożony (co nie było prawdą) i zaoferował w zamian opłatę 1000 zł za wskazanie tego błędu, co jest kwotą, która chyba adekwatnie odzwierciedla ich ogólne standardy jakości kodu. Prowadząc 15 lat firmę nie pamiętam takiej sytuacji… na szczęście kient, który płaci za pilnowanie tematu zapłacił za nadzór nad premium wykonawcą. Natomiast problem na pewno dotyczy klientów zawierających engine tego sklepu z customowymi przeróbkami, ponieważ ich widoczność w indeksie jest rażąco obniżona, co można zweryfikować.

Myślcie o AI, zanim AI zapomni o Was

Dlatego ten case study trafia do Was. Jako przestroga i lekcja dla całej branży, bo mamy teraz kluczowy moment i zakładam, że firmy nieogarniające takich problemów również zanikną.

Wykryty błąd uczy nas kilku rzeczy:

1. Fundamenty są wszystkim: Cache-busting to potężne narzędzie, ale użyte bez zrozumienia staje się bronią masowego rażenia dla wydajności. Jeśli czegoś nie rozumiesz nie wdrażaj tego.
2. Era AI Search już tu jest: Ignorowanie tego, jak boty AI indeksują sieć, to prosta droga do cyfrowego niebytu. Problemy techniczne, które kiedyś uchodziły płazem, dziś mogą całkowicie wyciąć Cię z wyników w ChatGPT, Claude czy Perplexity. Szczególnie ma to znaczenie dla e-commerce. Dziś jest ciężko, a nawet źle, ale za rok będzie jeszcze ciekawiej. To się dzieje.
3. Kultura ignorancji jest droga: Najbardziej szokujący jest brak reakcji agencji. Profesjonalizm polega nie na byciu nieomylnym albo unikaniu odpowiedzialności, ale na umiejętności przyznawania się do błędów i ich naprawiania. Zwłaszcza gdy klient płaci za audyt, który podaje gotowe rozwiązanie na tacy. Widać, że ktoś nie potrafi wyliczyć, ile roboczogodzin przepalił na kręcenie się za własnym ogonem, gdy nie dowoził sklepu albo odpisywał na tickety klienta opisującego niestabilną aplikację. Zostawiam to jednak i idę dalej, bo mam co robić.

A, i jeszcze jedno. Wycinanie botów AI, co właśnie robią renomowane agencje i firmy hostingowe, nie jest rozwiązaniem. To krótkoterminowa strategia ze smutnym finałem dla obu stron. Zresztą sporo hostingów i devopsów wycina teraz z uśmiechem boty AI. Moim zdaniem to nieetyczne.

Firmy, które nie zaadaptują swoich procesów i wiedzy technicznej do nowej rzeczywistości, w której AI jest głównym pośrednikiem informacji, po prostu znikną. A ich klienci znikną razem z nimi.

… to be continued…?

• Seo
• Ai Search