Krótka odpowiedź i jej warunki

Usługa działająca jako pośrednik między użytkownikiem a Twoim serwerem to dziś standard i w domyślnej konfiguracji nie jest dla wyszukiwarki przeszkodą. Roboty pobierają wtedy strony tak samo jak przeglądarka, a buforowanie treści zwykle poprawia czasy odpowiedzi, co widoczności sprzyja.

Warunek jest jednak istotny: ryzyko nie wynika z pośrednika, a z reguł, które ktoś na nim ustawił. Każda taka usługa daje kilkadziesiąt przełączników, z których część działa na wszystkich klientów bez wyjątku, a część modyfikuje treść odpowiedzi. To one decydują, czy robot dostanie stronę, czy zagadkę do rozwiązania.

Drugi warunek dotyczy sposobu wdrożenia. Przełączenie serwisu na nowego pośrednika to zmiana ścieżki, którą idą wszystkie żądania — wraz z certyfikatem, przekierowaniami i regułami buforowania. Błąd w którymkolwiek z tych elementów potrafi wyglądać dokładnie jak kara albo aktualizacja algorytmu, którą akurat w tym samym tygodniu ktoś opisał w branżowych mediach.

Dlatego przy każdym spadku pytam najpierw o daty wdrożeń technicznych z ostatniego kwartału i porównuję je z wykresem.

Co konkretnie powoduje spadki

Lista jest krótsza, niż się wydaje, i uporządkowana według tego, jak często ją spotykam.

• Wyzwania stawiane automatom. Tryby, w których każdy klient nieprzypominający przeglądarki dostaje stronę pośrednią z testem, obejmują też roboty wyszukiwarek, jeśli nie ma dla nich wyjątku. Robot nie przechodzi testu i nie widzi treści.

• Błędna konfiguracja połączenia z serwerem źródłowym. Klasyk: pośrednik łączy się z serwerem bez szyfrowania, serwer wymusza przekierowanie na wersję szyfrowaną, powstaje pętla. Użytkownik z pamięcią podręczną przeglądarki może tego nie zauważyć, robot widzi pętlę przy każdym żądaniu.

• Reguły buforowania obejmujące zbyt wiele. Trafiłem na konfiguracje, w których z pamięci podręcznej podawano zalogowanym użytkownikom cudze strony, a robotom — wersję sprzed tygodnia. Widoczność spada, bo indeksowana jest treść, której na stronie już nie ma.

• Ograniczenia liczby żądań ustawione globalnie. Robot pobiera więcej stron na minutę niż człowiek i przy limicie skrojonym pod ludzi natychmiast dostaje odmowę.

• Ochrona odsyłaczy do plików graficznych. Zabezpieczenie przed wykorzystywaniem cudzych zdjęć zwykle odcina też pobieranie obrazów przez roboty, co kończy widoczność w wynikach graficznych.

Wspólny mianownik jest jeden: reguła napisana pod ruch ludzki, zastosowana bez wyjątku do wszystkiego, co ludzkie nie jest.

Tryby, których nie zostawia się włączonych

Osobno wymieniam ustawienia przeznaczone do obrony w trakcie ataku, bo one szkodzą najbardziej i najczęściej zostają włączone dłużej, niż powinny.

Tryb awaryjny, w którym każdy klient przechodzi kontrolę przed dostępem do serwisu, jest sensownym narzędziem na godziny. Zostawiony na dni zaczyna działać jak zamknięcie serwisu dla wyszukiwarki, bo robot za każdym razem dostaje stronę pośrednią zamiast treści.

Podobnie z prostszymi mechanizmami wykrywania automatów, dostępnymi w niższych planach. Ich tania wersja opiera się na wykonaniu skryptu przez klienta i nie odróżnia zweryfikowanego robota wyszukiwarki od scrapera. Wersje rozbudowane potrafią to rozdzielić i mają osobną kategorię botów zweryfikowanych, które przepuszczają — ale to trzeba włączyć świadomie i sprawdzić, że działa.

Do tej samej grupy należy podniesiony poziom bezpieczeństwa całej witryny. Wygląda niewinnie, bo to jeden suwak, a w praktyce oznacza wyzwanie dla znacznie szerszej grupy klientów, w tym dla części zapytań pochodzących od robotów.

Zasada, którą stosuję: tryb obronny ma datę wygaśnięcia zapisaną w zgłoszeniu. Jeśli nikt nie ustalił, kiedy go zdejmujemy, nie zostanie zdjęty nigdy.

Modyfikacje treści i renderowania

Ta kategoria jest podstępna, bo nie blokuje niczego — po prostu zmienia to, co robot dostaje.

Usługi pośredniczące oferują automatyczną optymalizację: łączenie i minimalizowanie skryptów, opóźnianie ich wykonania, przenoszenie ładowania obrazów na moment przewinięcia strony, ukrywanie adresów e-mail. Każda z tych funkcji ingeruje w kod strony. Zwykle nieszkodliwie, ale zdarzają się przypadki, w których po włączeniu opóźniania skryptów treść generowana po stronie przeglądarki przestaje pojawiać się w tym, co widzi robot.

Osobne ryzyko to funkcje podające całą stronę z pamięci podręcznej brzegu sieci dla serwisów opartych na popularnych systemach zarządzania treścią. Przy nieostrożnej konfiguracji potrafią serwować wersję nieaktualną tygodniami — i to właśnie tę wersję wyszukiwarka zapisuje.

Sprawdzenie jest prostsze niż dyskusja o tym: pobieram stronę tak, jak zrobiłby to robot, i szukam w otrzymanym kodzie zdań, które mają być zaindeksowane, oraz odnośnika kanonicznego. Jeśli treść jest, sprawa ustawień optymalizacyjnych jest zamknięta.

Blokowanie robotów AI a obecność w wyszukiwarce

Temat, który od pół roku dokłada do tej rozmowy niepotrzebnego zamieszania, więc rozdzielę pojęcia.

Od lipca tego roku Cloudflare domyślnie pyta nowe domeny o zgodę na dostęp robotów zbierających treść dla modeli i uruchomił w wersji testowej mechanizm pobierania opłat za takie pobrania. To zmiana w podejściu do udostępniania treści, nie zmiana w indeksowaniu — i tego rozróżnienia trzyma się cała reszta.

Robot indeksujący Google, na którego danych opierają się wyniki wyszukiwania wraz z podsumowaniami generatywnymi i trybem AI, jest osobnym klientem niż mechanizm kontrolujący wykorzystanie treści do trenowania modeli. Zablokowanie tego drugiego nie usuwa serwisu z wyników i nie usuwa go z podsumowań. Zablokowanie pierwszego usuwa z obu.

Po stronie asystentów sprawa wygląda analogicznie: jeden robot zbiera dane szerzej, inny pobiera stronę na potrzeby konkretnej odpowiedzi. Blokada tego drugiego oznacza po prostu, że w odpowiedziach nie będzie Twojej strony jako źródła. To decyzja biznesowa, w której trzeba zważyć wartość ruchu z cytowań przeciw wartości treści jako aktywa — i warto ją podjąć świadomie, a nie odziedziczyć po domyślnym ustawieniu panelu.

W praktyce sprawdzam dziś przy każdym audycie, jakie reguły dotyczące tych robotów są ustawione i czy ktokolwiek w firmie o nich wie. Zdarzało się, że klient jednocześnie blokował dostęp i pytał, dlaczego nie widać go w odpowiedziach asystentów.

Diagnostyka w kolejności od najtańszej

Gdy indeksowanie spada, a warstwa ochronna jest podejrzana, przechodzę cztery kroki i rzadko potrzebuję piątego.

Krok pierwszy: zestawienie daty wdrożenia lub zmiany ustawień z dniem, w którym zmienił się wykres. Zbieżność w ciągu tygodnia to mocna przesłanka, brak zbieżności zamyka wątek i oszczędza dni pracy.

Krok drugi: raport o kodach odpowiedzi, jakie robot dostaje przy pobieraniu serwisu. Odmowy dostępu i błędy serwera, których wcześniej nie było, wskazują wprost na regułę zapory. Warto zwrócić uwagę także na pliki, które muszą być dostępne bezwarunkowo — mapa witryny i robots.txt bywają objęte tymi samymi ograniczeniami co reszta.

Krok trzeci: rejestr zdarzeń bezpieczeństwa w panelu usługi, przefiltrowany po ruchu robotów. Tu widać nazwę reguły, która zadziałała, i to jest dowód, a nie hipoteza.

Krok czwarty: sprawdzenie z zewnątrz, jak serwis odpowiada na żądanie pozbawione cech przeglądarki — bez ciasteczek, bez nagłówka odsyłającego. Uwaga na pułapkę: żądanie wysłane z Twojego biurowego łącza może zostać potraktowane inaczej niż to samo żądanie z adresu, którego usługa nie rozpoznaje, więc test z jednego miejsca nie jest rozstrzygający.

Higiena wdrożenia: co ustawić na starcie

Lista, którą przechodzę przy każdym uruchomieniu warstwy ochronnej przed serwisem.

• Kategoria zweryfikowanych robotów przepuszczana bezwarunkowo, a jeśli usługa jej nie ma — własna reguła oparta na potwierdzonych zakresach adresów, nie na nazwie klienta.

• Szyfrowane połączenie z serwerem źródłowym w trybie pełnej weryfikacji, żeby nie powstawały pętle przekierowań.

• Mapa witryny i robots.txt wyłączone z reguł ograniczających oraz sprawdzone z zewnątrz po wdrożeniu.

• Reguły buforowania z jawnym wykluczeniem obszarów zalogowanych, koszyka i wyników wyszukiwania wewnętrznego.

• Ograniczenia liczby żądań tylko na ścieżkach kosztownych, nigdy jako reguła obejmująca cały serwis.

Na koniec rzecz, która nie jest ustawieniem: rejestr zmian. Wystarczy notatka z datą, nazwą przełącznika i powodem, dla którego został włączony. Przy trzech osobach mających dostęp do panelu i jednym incydencie w środku nocy jest to jedyna informacja, która za pół roku pozwoli odpowiedzieć, czy usługa ochronna zaszkodziła widoczności — czy zaszkodził jej ktoś, kto ją konfigurował.