Jak w WordPress zablokować boty - Digital ocean inc. Z Google analytics

Jeśli raporty GA4 pokazują nagłe skoki ruchu z nieznanych regionów, identyczne długości sesji albo strony docelowe, których nikt nie udostępnia, często patrzysz na boty, które mimo wszystko odpalają tag analityki. Celem nie jest zablokowanie każdego crawlera. Celem jest wycięcie śmieci, które psują decyzje, przy zostawieniu w spokoju Googlebota, Bingbota i prawdziwych odwiedzających.

Ten poradnik dotyczy WordPressa na droplecie DigitalOcean (albo podobnym VPS) z nginx, opcjonalnie z fail2ban, oraz GA4. Traktuje robots.txt, firewall serwera, wtyczki WordPressa i narzędzia CDN do botów jako osobne warstwy z osobnymi zadaniami. Jeśli potrzebujesz pracy nad crawlowaniem i cytowaniami wykraczającej poza higienę ruchu, zobacz usługi optymalizacji SEO i GEO w WPPoland.

#Dlaczego złe boty zawyżają Google Analytics

GA4 liczy trafienie, gdy przeglądarka (albo przeglądarka headless, która zachowuje się jak zwykła) uruchomi tag i wyśle zdarzenia. To oznacza, że trzy różne populacje pojawiają się w różnych miejscach:

• Scrapery wykonujące JavaScript i narzędzia do fałszywych kliknięć mogą pojawić się w GA4 jako sesje, odsłony, a nawet konwersje, jeśli trafią w odpowiednie adresy.
• Proste scrapery HTTP często w ogóle nie wykonują JavaScriptu, więc omijają GA4, a mimo to uruchamiają PHP, MySQL i każdy szablon bez cache na serwerze.
• Nazwane crawlery wyszukiwarek powinny być widoczne w logach serwera i w Search Console, a nie jako duża część “Użytkowników” w GA4.

Gdy rośnie grupa wykonująca JavaScript, raporty pozyskania i zaangażowania zaczynają się rozjeżdżać. Współczynnik odrzuceń i średni czas zaangażowania wyglądają dziwnie. Raporty płatne i organiczne robią się zaszumione. Zespół zaczyna optymalizować pod ruch, który nigdy niczego nie kupi.

Typowe kształty złego ruchu (bez wymyślania konkretnych adresów IP):

• Duża liczba żądań z niewielkiego zbioru chmurowych ASN, bez referrera i z dziwnymi User-Agentami
• Powtarzane wejścia na /wp-login.php, xmlrpc.php, zapytania wyliczające autorów albo stare ścieżki wtyczek
• Sesje, które lądują tylko na cienkich adresach i odbijają się w niecałą sekundę, a mimo to tworzą w GA4 zdarzenia page_view
• Ruch “organiczny”, który w tym samym okresie nie zgadza się z danymi zapytań w Search Console

Dostawcy chmurowi, tacy jak DigitalOcean i AWS, hostują mnóstwo legalnych stron. Hostują też scrapery. To nakładanie się jest powodem, dla którego hurtowe reguły w stylu “zablokuj całe /16” są ryzykowne. Wybieraj źródła potwierdzone we własnych logach zamiast list przepisanych ze starych wpisów na blogach.

#Jak wykryć ruch botów w GA4 i w logach serwera

Zmiana bez punktu odniesienia to opowiadanie historii. Zbierz dane bazowe z co najmniej siedmiu dni, a jeśli ruch jest sezonowy, z pełnego tygodnia roboczego.

#Jak rozpoznać ruch botów w raportach GA4

Zanim zaczniesz edytować nginx albo fail2ban, przygotuj prosty widok porównawczy:

1. Zanotuj Użytkowników, Sesje, Sesje z zaangażowaniem i Wyświetlenia z ostatnich 7 i 28 dni.
2. Otwórz Pozyskiwanie ruchu i poszukaj źródeł z absurdalnym zaangażowaniem (czas zaangażowania bliski zeru, odrzucenia bliskie 100% na każdej stronie docelowej).
3. Sprawdź Technologia > Przeglądarka i Urządzenie pod kątem pustych, nieznanych albo wyraźnie skryptowych klientów.
4. Przejrzyj Stronę docelową pod kątem ścieżek, które lubią tylko boty (/?author=1, stary spam w parametrach, nieistniejące ID produktów).
5. Wyeksportuj albo zrób zrzut ekranu okresu, żeby później porównać to samo z tym samym (ta sama długość, ten sam układ dni tygodnia).

GA4 sam usuwa znane boty (o tym w następnej sekcji), ale ta lista nie łapie każdego uciążliwego klienta, który wykonuje JavaScript. Traktuj GA4 jako jeden sygnał, nie jedyny.

#Jak znaleźć IP botów w logach dostępu nginx

Na DigitalOcean zwykle masz logi dostępu nginx i, jeśli są włączone, jaile fail2ban. Przydatne sprawdzenia:

# Najczęstsze adresy w ostatnim logu dostępu (dostosuj ścieżkę)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

# Ścieżki wyglądające na sondy
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -40

# Dominujące User-Agenty
awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Zestaw skoki w GA4 ze znacznikami czasu w tych logach. Jeśli GA4 skacze o 03:00 UTC, a log dostępu pokazuje te same IP walące w xmlrpc.php, masz problem po stronie serwera, którego same filtry analityki nie rozwiążą.

Zanotuj też obciążenie CPU serwera i długość kolejki PHP-FPM w czasie skoku. Szum botów, który nigdy nie trafia do GA4, i tak potrafi wyczerpać mały droplet.

#Czy GA4 automatycznie filtruje ruch botów

Częściowo. Artykuł pomocy Google o ruchu znanych botów mówi, że GA4 automatycznie wyklucza ruch znanych botów i pająków. Lista, na której to się opiera, łączy własne badania Google z listą International Spiders and Bots List prowadzoną przez Interactive Advertising Bureau (IAB).

Dwa szczegóły z tej strony są tu ważne. Tego wykluczenia nie da się wyłączyć i nie da się zobaczyć, ile ruchu usunęło. Jeśli więc GA4 nadal pokazuje śmieciowe sesje, tych klientów nie było na liście znanych botów: zwykle są to przeglądarki headless na wynajętych serwerach, które uruchamiają tag jak zwykły odwiedzający. Automatyczne wykluczenie nic też nie robi z żądaniami, które nie wykonują JavaScriptu, bo GA4 w ogóle ich nie dostaje.

Tę lukę omawia reszta poradnika. GA4 radzi sobie z crawlerami, które się przedstawiają; z klientami ukrywającymi, czym są, musi sobie poradzić serwer i brzeg sieci.

#Jak wykluczyć zakresy IP botów filtrami danych w GA4

Filtry danych w GA4 występują w trzech typach: ruch deweloperski (tryb debugowania), ruch wewnętrzny (po adresie IP lub zakresie) i niechciane nazwy hostów. Nie ma typu “boty”, więc jedynym narzędziem opartym na IP jest filtr ruchu wewnętrznego.

Działa w dwóch krokach opisanych w przewodniku Google po definiowaniu ruchu wewnętrznego. Najpierw w Admin, w sekcji Data collection and modification, otwierasz Data streams, wybierasz strumień internetowy, przechodzisz do Configure tag settings, potem do Define internal traffic i tworzysz regułę. Pasujące zdarzenia dostają parametr traffic_type. Domyślna wartość to internal, ale możesz ustawić własną, na przykład bot_do, żeby reguła dla botów nigdy nie mieszała się z regułą dla biura. Warunki IP przyjmują dokładne dopasowanie, początek, koniec, zawieranie, zakres CIDR albo wyrażenie regularne. W drugim kroku w Data filters tworzysz filtr Internal Traffic, który wyklucza tę wartość traffic_type.

Ograniczenia, które warto znać, zanim się na tym oprzesz:

• Usługa może mieć najwyżej 10 filtrów danych.
• Każdy filtr ma stan Testing, Active albo Inactive. W stanie testowym pasujące zdarzenia dostają wymiar Test data filter name, który możesz obejrzeć w Explore, zanim cokolwiek zostanie usunięte.
• Aktywny filtr zmienia przychodzące dane na stałe i nie działa wstecz na dane historyczne. Według Google zadziałanie filtra może potrwać od 24 do 36 godzin.
• Do tymczasowego widoku bez utraty danych Google wskazuje filtry raportów.

Bezpieczniejsza kolejność: trzymaj regułę dla IP botów w stanie testowym przez pełny tydzień, porównaj oznaczone sesje z tym, co log nginx pokazuje dla tych samych adresów, i przełącz filtr na aktywny dopiero wtedy, gdy oznaczony ruch jest jednoznacznie śmieciowy. Lista reguł powinna być krótka, z datą dodania każdego zakresu. Pamiętaj też, czym ten filtr jest: poprawką raportowania. Żądania nadal trafiają do nginx, PHP i MySQL; GA4 po prostu przestaje je liczyć.

#Jak sprawdzić, do kogo należy IP, zanim je zablokujesz

Pojedynczy adres w logu mówi niewiele, dopóki nie wiesz, kto go ogłasza. whois daje wpis z rejestru. API danych RIPEstat pokazuje widok routingu, czyli prefiks i system autonomiczny (AS), który go teraz ogłasza:

whois 5.101.96.1 | grep -iE "orgname|org-name|netname"
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=5.101.96.1"
curl -s "https://stat.ripe.net/data/as-overview/data.json?resource=AS14061"

Gdy 14 października 2026 uruchomiłem oba zapytania do API, RIPEstat zwrócił prefiks 5.101.96.0/21 ogłaszany przez AS14061, a jako właściciela AS14061 podał DIGITALOCEAN-ASN, DigitalOcean, LLC. Endpoint network-info jest bezpłatny i odpowiada dla adresów ze wszystkich regionalnych rejestrów, nie tylko z RIPE.

Zanim gdziekolwiek wkleisz zakres, przeczytaj sufiks CIDR. Liczba po ukośniku to liczba stałych bitów prefiksu, więc /24 obejmuje 256 adresów, /16 obejmuje 65 536, a /14 obejmuje 262 144. Jedna stara linia w rodzaju deny from 104.236.0.0/16 odcina 65 536 adresów, z których prawie żaden nie ma związku z klientem, który ci przeszkadzał.

#Gdzie znaleźć aktualne zakresy IP DigitalOcean

DigitalOcean publikuje swoją przestrzeń adresową jako plik CSV, podlinkowany jako DigitalOcean IP Ranges w dokumentacji platformy, i zaznacza, że plik aktualizuje się automatycznie. Każdy wiersz zawiera prefiks, kod kraju, region, miasto i kod pocztowy.

14 października 2026 plik zawierał 1234 prefiksy, w tym 148 IPv6. Według krajów 654 wiersze dotyczyły Stanów Zjednoczonych, 224 Holandii, 111 Niemiec, 90 Singapuru i 67 Wielkiej Brytanii. Ta skala to praktyczny argument przeciw hurtowemu blokowaniu: w tych samych prefiksach działają droplety agencji, narzędzi SaaS, monitorów dostępności, runnerów CI i zwykłych firm, obok scraperów.

Używaj tego pliku do sprawdzania, a nie jako listy blokad. Gdy jeden adres dominuje w logu dostępu, sprawdź, czy leży w przestrzeni DigitalOcean:

curl -s -o do-ranges.csv https://www.digitalocean.com/geo/google.csv
python3 -c 'import csv,ipaddress,sys; nets=[ipaddress.ip_network(r[0]) for r in csv.reader(open("do-ranges.csv")) if r]; ip=ipaddress.ip_address(sys.argv[1]); print(any(ip in n for n in nets))' 5.101.96.1

Wynik True mówi, że klient działa na serwerze DigitalOcean. Nie mówi, że jest złośliwy; o tym decyduje jego zachowanie w logu.

#Czy robots.txt zablokuje złe boty

robots.txt to protokół dobrowolny. Współpracujące crawlery go czytają i pomijają zabronione ścieżki. Uciążliwi klienci go ignorują.

Używaj robots.txt do prowadzenia dobrych botów:

• Wyłącz z indeksowania ścieżki stagingu, adresy wyników wyszukiwania i punkty administracyjne, których nie chcesz w indeksie
• Bądź oszczędny z crawl-delay i szerokimi regułami Disallow; nadmierne blokowanie potrafi ukryć strony, które nadal chcesz mieć w wynikach
• Wrażliwe obszary chowaj za uwierzytelnianiem, a nie tylko za linią Disallow

Nie oczekuj, że reguła Disallow zatrzyma credential stuffing na /wp-login.php. Takie żądanie w praktyce nie zagląda do robots.txt. Firewall, limit żądań i uwierzytelnianie należą do serwera albo do brzegu sieci.

Praktyczny podział:

#Jak zweryfikować Googlebota przed zablokowaniem IP

Blokowanie Googlebota po ciągu User-Agent to klasyczny samobój. Podszywanie się pod Googlebot jest powszechne; prawdziwego Googlebota weryfikuje się odwrotnym DNS i potwierdzeniem w przód. Google opisuje to w dokumencie Weryfikowanie Googlebota.

Zanim zablokujesz IP, które przedstawia się jako Googlebot:

1. Wykonaj odwrotne zapytanie DNS dla tego IP.
2. Sprawdź, czy nazwa hosta kończy się domeną Google zgodnie z dokumentacją Google.
3. Rozwiąż tę nazwę hosta w przód i potwierdź, że zwraca pierwotne IP.
4. Dopiero wtedy traktuj klienta jako Googlebota (albo nie).

Nigdy nie dodawaj reguły typu “zablokuj, jeśli User-Agent zawiera Googlebot” jako zabezpieczenia. Zablokuje prawdziwego crawlera, gdy ktoś gdzie indziej podszyje się pod ten ciąg, a nie zatrzyma podszywających się, którzy używają innego.

Ta sama ostrożność dotyczy Bingbota i innych nazwanych crawlerów, na których ci zależy. Listy dozwolonych zakresów zweryfikowanych crawlerów stosuj tylko wtedy, gdy starannie je utrzymujesz; do całej reszty lepsze są limity oparte na zachowaniu.

#Jak limitować boty na DigitalOcean za pomocą nginx i fail2ban

Na typowym droplecie LEMP najtańsze miejsce do odcięcia nadużyć to nginx, zanim ruszy PHP-FPM i autoload WordPressa.

#nginx limit_req dla wp-login.php i xmlrpc.php

Moduł ngx_http_limit_req_module ogranicza tempo żądań według klucza (zwykle IP). Ostrożny wzorzec dla logowania i XML-RPC wygląda tak:

# kontekst http
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=wp_xmlrpc:10m rate=1r/s;

# przykłady dla server / location
location = /wp-login.php {
    limit_req zone=wp_login burst=5 nodelay;
    include fastcgi_params;
    # ... istniejąca obsługa PHP ...
}

location = /xmlrpc.php {
    limit_req zone=wp_xmlrpc burst=2 nodelay;
    # Wiele stron zwraca tu 403, jeśli w ogóle nie potrzebuje XML-RPC
}

Dostrój wartości na podstawie danych bazowych. Redakcja z wieloma autorami za wspólnym NAT potrzebuje większego burst niż strona wizytówka. Loguj odrzucenia limit_req i obserwuj fałszywe alarmy z adresów wyjściowych biura.

Inne nawyki nginx, które pomagają na dropletach DO:

• Wyłącz albo mocno ogranicz xmlrpc.php, jeśli go nie używasz
• Limituj żądania POST do admin-ajax.php od anonimowych klientów, jeśli wtyczki na to pozwalają
• Kończ TLS na nginx (albo w Cloudflare) i zostaw otwarte w chmurowym firewallu DigitalOcean tylko potrzebne porty

#Jaile fail2ban dla logowania WordPressa i ścieżek sondujących

fail2ban obserwuje logi i dodaje tymczasowe bany w firewallu, gdy pasuje filtr. Typowe jaile pod WordPress obserwują logi nginx pod kątem powtarzanych 401/403/404 na logowaniu i ścieżkach sondujących. Trzymaj jaile wąsko:

• Banuj na minuty albo godziny, nie na zawsze, dopóki nie zaufasz filtrowi
• Wyklucz VPN biura i narzędzia monitorujące
• Sprawdzaj ponownie po aktualizacjach WordPressa albo wtyczek, które zmieniają format logów

fail2ban świetnie radzi sobie z hałaśliwymi skanerami. Słabo zastępuje naprawę wystawionego punktu wtyczki, który na każdą sondę odpowiada 200.

#Które porty otworzyć w chmurowym firewallu DigitalOcean

Użyj firewalla DO (albo odpowiednika), żeby otworzyć 22/80/443 dla całego świata tylko wtedy, gdy musisz, i preferuj SSH na klucze ze znanych IP. Blokady sieciowe zatrzymują pakiety przed nginx. Nadal nie powinny wyglądać jak “zablokuj każde /16 DigitalOcean na świecie”, bo złapią klientów, agencje i runnery CI hostowane u tego samego dostawcy.

#Czy wtyczki firewall do WordPressa zatrzymują ruch botów

Wtyczki takie jak Wordfence, Sucuri i porządne pakiety bezpieczeństwa dodają ochronę logowania, skanowanie malware i reguły aplikacyjne. Pomagają. Działają jednak dopiero wtedy, gdy nginx już przyjął połączenie, a PHP wystartowało.

Zastrzeżenia ważne przy czyszczeniu analityki:

• Koszt CPU: każde zablokowane żądanie i tak zapłaciło za start PHP, chyba że coś odrzuciło je wcześniej.
• Fałszywe alarmy: agresywne reguły typu “blokuj nieznane kraje” albo “blokuj wszystkie chmurowe ASN” potrafią odciąć freelancerów, agencje i operatorów płatności.
• Nakładanie się z WAF na brzegu: zdublowane reguły w Cloudflare i we wtyczce utrudniają debugowanie, gdy legalny użytkownik dostaje wyzwanie dwa razy.
• Szum w logach: logi wtyczki i GA4 nie będą się zgadzać, bo widzą różne warstwy.

Wskazówki z podręcznika hardeningu WordPressa nadal obowiązują: aktualizuj rdzeń i wtyczki, dawaj użytkownikom bazy danych minimalne uprawnienia i ograniczaj uprawnienia plików. Wtyczka firewall nie zastępuje tych podstaw.

Praktyczna kolejność działań:

1. Napraw wystawione punkty końcowe i słabe hasła.
2. Dodaj limity w nginx i fail2ban dla hałaśliwych ścieżek.
3. Dodaj firewall WordPressa dla reguł świadomych aplikacji i alertów.
4. Dodaj narzędzia Cloudflare do botów, jeśli już korzystasz z tego CDN.

#Jak blokować boty w Cloudflare, zanim dotrą do WordPressa

Jeśli strona stoi za Cloudflare, korzystaj z ich dokumentacji o botach zamiast wymyślać listy blokad User-Agent na serwerze. Reguły na brzegu sieci potrafią:

• Rzucić wyzwanie albo zablokować oczywisty ruch automatyczny, zanim dotrze do DigitalOcean
• Limitować konkretne ścieżki (/wp-login.php, /xmlrpc.php)
• Przepuszczać zweryfikowane boty wyszukiwarek, jeśli starannie to skonfigurujesz

Reguły nginx na serwerze nadal mają znaczenie jako obrona warstwowa, gdyby ktoś ominął proxy (szara chmurka w DNS, bezpośrednie IP serwera). W trybie pełnego proxy zamknij firewall dropletu tak, żeby z portami 80/443 mogły rozmawiać tylko zakresy IP Cloudflare (albo twoje adresy administracyjne).

Cloudflare sam nie sprawi, że GA4 będzie magicznie dokładne. Ogranicza uciążliwe trafienia, które uruchomiłyby tagi albo wyczerpały PHP. Po zmianie Bot Fight Mode albo reguł WAF mierz zarówno analitykę brzegu, jak i GA4, bo wyzwania mogą też zmienić to, jak prawdziwi użytkownicy kończą sesję.

#Jak rzucić wyzwanie ruchowi z DigitalOcean regułami WAF w Cloudflare

Reguły niestandardowe WAF w Cloudflare potrafią dopasować sieć, z której przychodzi żądanie. Służy do tego pole ip.src.asnum, czyli numer AS adresu IP klienta, a sieć DigitalOcean to AS14061. Jedna reguła wymierzona w AS zastępuje ręczne utrzymywanie 1234 prefiksów.

Trzymaj zakres wąsko. Reguła, która dotyka ruchu z DigitalOcean tylko na ścieżkach nadużywanych przez boty, wygląda tak:

(ip.src.asnum eq 14061 and http.request.uri.path in {"/wp-login.php" "/xmlrpc.php"})

Jako akcję wybierz Managed Challenge, a nie Block. Człowiek pracujący przez VPN postawiony na droplecie przejdzie wyzwanie; prosty skrypt zwykle nie. Block kończy żądanie, a ponieważ Cloudflare sprawdza reguły niestandardowe po kolei, zatrzymuje też wszystkie późniejsze reguły niestandardowe dla tego żądania.

O tym, ile takich reguł możesz mieć, decyduje plan. Cloudflare podaje 5 reguł niestandardowych w planie Free, 20 w Pro, 100 w Business i 1000 w Enterprise, a operator wyrażeń regularnych tylko w Business i Enterprise. W darmowej strefie jedna reguła na wyzwanie ASN dla ścieżek logowania zostawia cztery na problemy, których nie rozwiążesz na serwerze.

#Czy blokować zakresy IP DigitalOcean i AWS

Starsze porady wklejały do .htaccess długie listy deny from dla całych zakresów DigitalOcean albo AWS. To podejście źle się starzeje:

• Zakresy dostawców się zmieniają
• Legalny ruch korzysta z tych samych zakresów
• Składnia Apache deny nic nie daje, jeśli serwujesz WordPressa przez nginx bez Apache

Jeśli nadal używasz Apache, wybieraj potwierdzone pojedyncze adresy albo małe bloki CIDR z twoich logów, a nie skopiowaną megalistę:

# Tylko przykład kształtu - zastąp adresami potwierdzonymi we własnych logach
# Dyrektywy RequireAll / Require zależą od składni autoryzacji Apache 2.4
<RequireAll>
    Require all granted
    # Require not ip 203.0.113.10
</RequireAll>

W nginx używaj deny wewnątrz bloku geo/map albo fail2ban i zostaw krótki komentarz z datą i powodem bana. Przeglądaj bany co kwartał.

Nigdy nie publikuj ani nie opieraj się na tabelach “znanych IP botów” z przypadkowych wpisów bez weryfikacji. Starzeją się i prowadzą do szkód ubocznych.

Granice blokowania po IP pokazał atak na Read the Docs z czerwca 2026, który David Fischer opisał 8 września 2026. W szczycie przychodziło ponad 5,5 miliona żądań na minutę, około 100 razy więcej niż zwykle, przez prawie dziesięć dni, z milionów unikalnych adresów IP w setkach sieci (ASN). Atakujący celowali w ścieżki 404 i przekierowania 302, których nie obsługiwał cache; zespół w około pół godziny przeniósł przekierowania na brzeg Cloudflare, a według Fischera największą różnicę zrobiła prawdopodobnie reguła “penalty box”, która limituje klientów zbierających dużo odpowiedzi 404 i przekierowań. Pierwszy wniosek z jego tekstu brzmi: “blokowanie IP jest przestarzałe przy rozproszonych atakach” (tłumaczenie własne), a najostrzejszą reakcją Read the Docs jest wyzwanie JavaScript. Na WordPressie działa ta sama logika: trzymaj odpowiedzi 404 i przekierowania w cache na brzegu i limituj podejrzanych klientów, zamiast blokować całe zakresy chmur.

#Jak sprawdzić w GA4, że ruch botów spadł

Po wdrożeniu limitów albo banów odczekaj tyle samo, ile trwał okres bazowy (7 albo 28 dni). Potem porównaj:

1. Użytkownicy / Sesje / Sesje z zaangażowaniem: szukaj spadku śmieciowego wolumenu przy stałej albo rosnącej liczbie sesji z zaangażowaniem.
2. Strony docelowe: adresy sond powinny skurczyć się w GA4, jeśli ci klienci wykonywali JS; w logach nginx powinny skurczyć się tak czy inaczej.
3. Pozyskiwanie ruchu: tajemnicze źródła z zerowym zaangażowaniem powinny spaść.
4. Metryki serwera: liczba zajętych workerów PHP-FPM i odsetek błędów 5xx poza godzinami pracy powinny spaść, jeśli nadużycia na serwerze były prawdziwe.
5. Search Console: statystyki indeksowania i pokrycie nie powinny się załamać. Jeśli się załamią, prawdopodobnie zablokowałeś prawdziwego crawlera; wycofaj zmianę i poprawnie zweryfikuj Googlebota.

Zapisz datę zmiany w GA4 (Admin > Adnotacje albo dziennik zmian zespołu), żeby później pamiętać, co poruszyło wykres.

Jeśli GA4 prawie się nie zmienia, a odrzuceń w nginx przybywa, boty nigdy nie wykonywały twojego tagu. To nadal zysk dla zdrowia serwera, nawet gdy wykres analityki wygląda spokojnie.

Jeśli GA4 mocno spada, a w Search Console rosną błędy indeksowania, najpierw cofnij ostatnią regułę deny. Czysta analityka nic nie jest warta, jeśli psuje się indeksowanie.

#Lista kontrolna zatrzymania ruchu botów w WordPressie

Przejdź ją po kolei:

1. Zbierz dane bazowe GA4 (7/28 dni) i próbkę logów dostępu nginx.
2. Ustal, czy szum wykonuje JS (GA4), czy dotyczy tylko serwera (logi).
3. Zaostrz limity dla xmlrpc.php i logowania w nginx.
4. Dodaj jaile fail2ban dla powtarzanych sond; wyklucz własne IP.
5. Trzymaj robots.txt przy wskazówkach dla crawlerów, a nie przy pozornym bezpieczeństwie.
6. Dodaj albo dostrój firewall WordPressa bez blokowania całych dostawców chmurowych.
7. Opcjonalnie włącz narzędzia Cloudflare do botów i WAF, jeśli strona już korzysta z Cloudflare.
8. Zmierz ponownie GA4 i logi w porównywalnym okresie; obserwuj Search Console.

Jeśli chcesz przejrzeć szum crawlerów, reguły serwera i higienę analityki razem z szerszą pracą nad SEO i GEO, to lepszy wybór niż wklejanie wiecznych list blokad do katalogu głównego WordPressa. Sprawdź też moje usługi tworzenia stron WordPress, żeby pchnąć projekt do przodu.