Jak zablokować strony internetowe? Najpierw rozróżnij 3 typy blokad

Zanim cokolwiek zmienisz, odpowiedz na cztery pytania: kogo blokuję (siebie, pracownika, Googlebota, konkurencję), na jakim poziomie (urządzenie, sieć, serwer), na jak długo (godzina, tydzień, na stałe) i po co (skupienie, bezpieczeństwo, porządek w indeksie). Zła odpowiedź na którekolwiek z nich kosztuje ruch.

Trzy typy blokad, które trzeba rozdzielić:

1. Blokada dostępu na urządzeniu lub w sieci — użytkownik nie otworzy strony, bo żądanie nie wychodzi z jego komputera, telefonu albo firmowego routera. Serwer nie widzi żadnego ruchu i nic nie może o tym wiedzieć.
2. Blokada indeksowania przez Google i boty — człowiek wejdzie, wyszukiwarka nie zapisze adresu w wynikach. Narzędzia: robots.txt, meta robots noindex, nagłówek X-Robots-Tag.
3. Blokada ruchu lub scrapingu — ograniczenie liczby żądań z jednego IP i odsiewanie automatów kopiujących ofertę. Narzędzia: WAF, rate limiting, reguły w Cloudflare.

Przykład z e-commerce: podstronę koszyka blokujesz przed Google (noindex), ale nie przed klientem — inaczej nikt nie dokończy zakupu. Odwrotnie przy migracji sklepu na nowy serwer: wtedy chcesz zatrzymać wszystkich, łącznie z Googlebotem, i wysyłasz odpowiedź 503 z nagłówkiem Retry-After, a nie 403 dla każdego. 403 na cały serwis przy pracach trwających dwa dni to najprostsza droga do wypadnięcia z wyników.

Najczęstsza pułapka: łączysz Disallow w robots.txt z noindex na tej samej stronie. Googlebot nie pobierze strony, więc nie zobaczy noindex — adres zostanie w indeksie. Wybierasz jedno narzędzie, nie oba. Zasady oceny treści po stronie Google opisują wytyczne dla twórców treści, a kolejność zmian warto przejść przez checklistę przed wdrożeniem.

Blokowanie stron na komputerze i telefonie: hosts, przeglądarka, DNS

Dla jednego komputera najszybsze jest wpisanie domeny do pliku hosts. Na Windows edytujesz go jako administrator: C:\Windows\System32\drivers\etc\hosts, na macOS i Linuksie: /etc/hosts. Dopisujesz dwie linie — 127.0.0.1 przyklad.pl oraz 127.0.0.1 www.przyklad.pl — i czyścisz cache DNS: ipconfig /flushdns w Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder w macOS. Bez drugiej linii z www najczęściej blokada nie działa i wygląda na awarię.

Na telefonie: iPhone ma Czas przed ekranem → Ograniczenia treści i prywatność → Treści z internetu, gdzie wpisujesz własną listę witryn („Nigdy nie zezwalaj” + adres), a Tryb skupienia wycina powiadomienia bez blokowania domeny. Android: Cyfrowa równowaga, Family Link albo Prywatny DNS w Ustawieniach sieci (wpisujesz nazwę hosta, np. profil NextDNS). Chrome sam nie prowadzi listy zablokowanych stron — w Ustawieniach witryn blokujesz pojedyncze uprawnienia dla domeny (powiadomienia, JavaScript, cookies), a pełną blokadę załatwia rozszerzenie lub polityka profilu zarządzanego.

Dla domu i małego biura wygodniejszy jest DNS filtrujący ustawiony na routerze: OpenDNS, CleanBrowsing albo NextDNS z profilami per urządzenie. Zaleta jest jedna i konkretna — blokada obejmuje telewizor, konsolę i telefon gościa, na których nie zainstalujesz rozszerzenia.

Ograniczenia są realne: VPN, DNS-over-HTTPS wbudowany w przeglądarkę, tryb incognito (omija rozszerzenia), druga przeglądarka, drugie urządzenie, LTE zamiast Wi-Fi. Blokada na poziomie urządzenia działa tylko na osobę, która nie chce jej obejść. Jeśli blokada ma być twarda, przenieś ją do sieci — i nie zapomnij, że każda blokada domeny oparta na IP przestaje działać w dniu, gdy usługa zmieni adresy.

Blokowanie stron w routerze i całej sieci firmowej

W routerach konsumenckich filtrowanie zwykle nie działa po domenie. TP-Link ma kontrolę dostępu i kontrolę rodzicielską (blokada po MAC), a filtr domenowy tylko w wybranych modelach. Asus udostępnia AiProtection i Filtr internetowy z listą domen i słów kluczowych, przypisywaną do profilu urządzenia. MikroTik w RouterOS nie ma blokady po nazwie domeny — pracujesz na /ip firewall filter z adresami IP, a domeny rozwiązujesz listą address-list aktualizowaną skryptem DNS. Zasada jest jedna: router blokuje po IP, MAC albo porcie, nie po adresie z paska przeglądarki.

Jeśli chcesz blokować po domenie dla całej sieci, postaw Pi-hole albo AdGuard Home jako DNS sinkhole. Pi-hole na Raspberry Pi z listami blokad rozwiąże domenę na własny adres i odetnie ją dla każdego urządzenia korzystającego z tego DNS. AdGuard Home ma dodatkowo filtry rodzicielskie i osobne reguły dla klientów. Warunek: DHCP musi rozdawać ten adres jako DNS, a urządzenia nie mogą mieć ustawionego własnego resolvera.

W firmie schodzisz na firewall, np. OPNsense, pfSense czy FortiGate. Reguły na portach 80 i 443 rozdzielasz na VLAN-y: goście, pracownicy, magazyn, urządzenia IoT. W praktyce sklep internetowy blokuje w sieci biurowej dostęp do paneli administracyjnych na domenach zewnętrznych i do serwisów streamingowych, ale nie do własnego backendu i płatności. Każda reguła potrzebuje logu i terminu przeglądu, inaczej po pół roku nikt nie wie, po co jest.

Uwaga na DNS-over-HTTPS i DNS-over-TLS. Chrome, Firefox, Edge i telefony z Androidem domyślnie potrafią użyć własnego szyfrowanego resolvera i ominąć filtr routera w kilkanaście sekund. Kontrola wygląda tak: blokada portu 853 (DoT), wyłączenie DoH w przeglądarkach, Prywatny DNS wyłączony w zarządzanych telefonach, a w Windows wymuszenie serwerów DNS przez politykę grupy. Bez tego filtr sieciowy jest deklaracją, a nie zabezpieczeniem. Zanim zamkniesz sieć, ustal, kto w firmie ma dostęp do panelu sklepu i CMS-a — to zadanie z zakresu organizacji wdrożenia i cennika, nie samej konfiguracji routera.

Jak zablokować stronę lub podstronę przed Google (robots.txt, noindex)

Plik robots.txt leży w katalogu głównym domeny (twojadomena.pl/robots.txt) i działa jak instrukcja dla botów. Typowy zestaw wpisów dla sklepu wygląda tak:

• User-agent: * — reguła dla wszystkich robotów; możesz też wskazać konkretnego, np. User-agent: Googlebot.
• Disallow: /panel/ — panel klienta i strefa zalogowanego użytkownika.
• Disallow: /koszyk/ oraz Disallow: /checkout/ — koszyk i finalizacja zamówienia.
• Disallow: /*?orderby= i /*?sort= — warianty sortowania i filtrów, które generują tysiące adresów z tą samą treścią.

Zmiany w pliku nie działają natychmiast — Google odświeża robots.txt z opóźnieniem, czasem kilku dni.

Najczęstszy błąd: Disallow nie usuwa strony z wyników, jeśli adres jest już zaindeksowany. Google potrafi trzymać wpis bez opisu, a gdy ktoś linkuje do takiego URL-a z zewnątrz, bot zaindeksuje go mimo blokady. Groźniejszy wariant to łączenie Disallow z noindex na tej samej podstronie — bot nie pobierze strony, więc nie zobaczy znacznika i nigdy jej nie usunie. Wybierz jedno z dwóch.

Do wykluczenia z indeksu służą dwie rzeczy: znacznik meta robots noindex, nofollow w sekcji head oraz nagłówek HTTP X-Robots-Tag: noindex, nofollow. Nagłówek działa też dla plików PDF, przekierowań i podstron generowanych przez aplikację — wszędzie tam, gdzie nie wstawisz meta. W Google Search Console Usuwanie adresów URL to rozwiązanie tymczasowe (mniej więcej pół roku) i awaryjne; docelowo liczy się noindex, a efekt weryfikujesz w raporcie Indeksowanie stron. Status „Zaindeksowano, mimo że zablokowano przez robots.txt” oznacza dokładnie konflikt Disallow z noindex.

W e-commerce blokady indeksowania dotyczą przede wszystkim koszyka, checkoutu, panelu klienta, filtracji, wersji testowych i stagingu. Samo noindex nie chroni stagingu przed podejrzeniem — o tym niżej. Przy większych projektach warto przejść uporządkowaną checklistę wdrożenia strony, żeby nie zablokować ruchu, który zarabia. Pomocne są też ogólne wytyczne Google dotyczące treści tworzonych dla ludzi — pokazują, czego Google chce od podstron, zamiast ich ukrywać.

Blokowanie dostępu do podstron sklepu: hasło, IP, geolokalizacja

Staging, subdomena testowa i panel administracyjny nie mogą być publicznie dostępne. Pierwsza linia obrony to hasło na poziomie serwera, jeszcze przed aplikacją.

• W Apache w pliku .htaccess w chronionym katalogu: AuthType Basic, AuthName "Staging", AuthUserFile /sciezka/.htpasswd, Require valid-user.
• Zamknięcie dla wszystkich po adresie IP: w Apache 2.2 Order deny,allow z Deny from all, w Apache 2.4 Require all denied i Require ip 203.0.113.10. Wpisanie składni z 2.2 na serwerze 2.4 kończy się błędem 500 — klasyczna pułapka przy przenoszeniu starych plików.
• W Nginx odpowiednik to allow 203.0.113.10; i deny all; w bloku location.

Druga linia to Cloudflare: reguły WAF, IP Access Rules, blokada po kraju i Managed Challenge dla ruchu wyglądającego podejrzanie. Reguła krajowa przydaje się, gdy nie sprzedajesz poza Polską, ale odetnie też klientów z VPN-ów i część integracji — włączaj ją świadomie.

W PrestaShop tryb utrzymania włącza się w parametrach sklepu i wpisuje tam własne IP, żebyś widział sklep mimo blokady; szczegóły opisuje dokumentacja PrestaShop dla deweloperów. WooCommerce nie ma natywnego trybu utrzymania — używa się wtyczki albo reguły serwera, a sam plik .maintenance w WordPressie bywa zawodny.

Każdy staging i subdomena testowa muszą mieć jednocześnie noindex i hasło. To dwie różne funkcje: noindex ukrywa przed Google, hasło chroni przed ludźmi.

Przed włączeniem zrób test z innego IP, na telefonie (poza firmowym Wi-Fi) i w trybie incognito, bez cache. Nie zablokuj płatności (webhooki operatora płatności przychodzą z konkretnych adresów), kurierów, ERP ani monitoringu dostępności. Jeden Deny from all w złym miejscu potrafi wyłączyć zamówienia na kilka godzin. Jeśli wdrożenie ma kilka środowisk, kolejność prac opisuje checklista wdrożenia i koszty.

Blokowanie botów i scrapingu: robots.txt to za mało

robots.txt to instrukcja, nie zabezpieczenie. Respektują ją duże wyszukiwarki; scrapery komercyjne i proste skrypty ignorują ją całkowicie. Ochrona cen, opisów i zasobów serwera wymaga działań po stronie serwera i sieci.

• Rate limiting. W Nginx: limit_req_zone i limit_req; w Cloudflare reguły Rate Limiting. Poprawna odpowiedź to 429 Too Many Requests, a dla stałych intruzów 403 Forbidden.
• CAPTCHA (reCAPTCHA, hCaptcha) na formularzach, wyszukiwaniu i logowaniu — najlepiej tylko dla ruchu podejrzanego, żeby nie karać klientów.
• Honeypot. Ukryte pole w formularzu: człowiek go nie wypełni, prosty bot owszem.
• Wymagany JavaScript. Utrudnia curl, ale headless Chrome i Puppeteer to obchodzą — traktuj jako spowalniacz, nie zabezpieczenie.
• Cloudflare Bot Management (lub Super Bot Fight Mode) i reguły WAF z challenge dla ruchu, który nie zachowuje się jak przeglądarka.

Zacznij od logów serwera. Szukasz wzorców: jedno IP generujące dziesiątki tysięcy żądań na dobę, równy odstęp między żądaniami, brak pobierania CSS i obrazków, user-agent typu python-requests. Sprawdź reverse DNS i ASN — to odsiewa część botów podszywających się pod Googlebota.

Czego nie blokować: Googlebota, Bingbota, botów płatności i narzędzi monitorujących dostępność. Blokada Googlebota to spadek ruchu, którego nie odzyskasz w tygodniach; blokada bota płatności to zamówienia bez potwierdzenia. Zanim uznasz, że blokujesz robota, sprawdź w Google Search Console raport statystyk pobierania — podmiana user-agenta to najprostszy trik scraperów. Reguły WAF i limity warto ustalić na etapie organizacji wdrożenia i cennika, bo dokładane później potrafią zaskoczyć integracje.

7 pułapek przy blokowaniu stron internetowych

W praktyce blokady psują się z trzech powodów: pliki kopiowane między środowiskami, sprzeczne sygnały dla wyszukiwarki i reguły sieciowe, które odcinają nie tych użytkowników, co trzeba.

1. „Disallow: /” na produkcji przez pomyłkę. robots.txt ze stagingu albo „chwilowe” zamknięcie witryny przed Google. Googlebot przestaje pobierać stronę, a adresy wypadają z indeksu po dniach. Naprawa: usuń linię, wgraj plik, poproś o zindeksowanie w Search Console — widoczność wraca od kilku dni do kilku tygodni.
2. Disallow i noindex jednocześnie na tej samej podstronie. Zablokowany crawling oznacza, że Googlebot nie wczyta meta robots, więc noindex nie zadziała. Najpierw dopuść crawling i wstaw noindex (meta lub X-Robots-Tag), poczekaj na usunięcie adresu z wyników, a blokadę dostępu rozważ na końcu.
3. Blokada całego sklepu przed Google na dłużej niż krótki test. Dwa tygodnie „Disallow: /” w czasie prac serwisowych to spadek widoczności na kolejne tygodnie. Do serwisu użyj kodu 503 albo Basic Auth dla całej witryny.
4. Zapomnienie o stagingu, subdomenie, CDN i starych kopiach witryny. Sklep na staging.domena.pl bez noindex to dla Google druga wersja tej samej treści — tak samo jak porzucona kopia na starym hostingu. Reguły blokujące ustawiasz też w WAF i na CDN, więc sprawdzaj oba miejsca.
5. Blokada IP klientów B2B, kurierów lub systemów ERP. Ban na cały zakres adresów ubija synchronizację zamówień z ERP, etykiety kurierskie i panel klienta hurtowego. Najpierw wypisz adresy i dodaj whitelistę (Require ip w .htaccess, reguła „skip” w WAF).
6. Brak testu w incognito i z innej sieci. Zalogowany administrator widzi stronę z pominięciem cache, a biuro często ma whitelistowany adres IP. Testuj w incognito, z telefonu na danych komórkowych oraz przez curl -I i curl z user-agentem Googlebot.
7. Brak daty odwrócenia blokady i osoby odpowiedzialnej. W .htaccess dopisz komentarz z datą, autorem i powodem, np. „# blokada IP hurtowni, 2025-06-30, MK”, i załóż zgłoszenie z terminem przeglądu. Inaczej blokada „na tydzień” zostaje na rok. Ustal wcześniej koszt i proces wdrożenia i wskaż osobę odpowiedzialną.

Sklepom dochodzi jedna pułapka: w PrestaShop robots.txt generuje back office (SEO i URL-e), więc plik na serwerze to nie jedyne miejsce do sprawdzenia — zajrzyj do dokumentacji dla deweloperów PrestaShop.

Checklista: jak zablokować stronę internetową krok po kroku

Ta kolejność działa i dla strony firmowej, i dla sklepu na WooCommerce czy PrestaShop. Podstawowa zasada: każdy krok da się cofnąć.

Krok 0: kopia zapasowa. Zapisz robots.txt i .htaccess z serwera oraz eksport strefy DNS z wartościami TTL, w plikach z datą w nazwie. W WordPressie robots.txt jest generowany dynamicznie — kopia z serwera pokazuje to, co naprawdę widzi robot, a fizyczny plik ma sens tylko jako świadome nadpisanie. W PrestaShop reguły ustawiasz w back office (SEO i URL-e), więc zapisz też ten stan.

Krok 1: cel i zakres. Jedno zdanie: kogo blokujesz (Google, scrapery, ruch z danego kraju, konkretne adresy IP) i na jakim poziomie (cała witryna, katalog, pojedynczy plik). Brak tego zdania to najczęstsza przyczyna blokady „wszystkiego”.

Krok 2: metoda. robots.txt wstrzymuje crawling, ale nie usuwa z indeksu. noindex (meta lub X-Robots-Tag) usuwa z indeksu i wymaga, by robot wczytał stronę. .htaccess, Basic Auth i 503 blokują dostęp. Rate limiting chroni przed scrapowaniem bez odcinania klientów.

Krok 3: wdrożenie. Jedna zmiana naraz, poza szczytem sprzedaży, z informacją dla zespołu i wpisem w zgłoszeniu. Zapisz stan przed i po, żeby cofnięcie zajęło minutę, nie godzinę.

Krok 4: test. Sprawdź kolejno: site:domena.pl (sygnał pomocniczy, nie wyrocznia), Search Console — „Sprawdzenie adresu URL” i raport pliku robots.txt, logi serwera (czy Googlebot dostaje 200, a nie 403), incognito oraz telefon na danych komórkowych, curl -I na nagłówki.

Krok 5: monitoring, alerty i zaplanowane odwrócenie blokady. Ustal datę przeglądu, np. +7 dni, i konkretną osobę. Dodaj alert na błędy 5xx oraz sprawdzanie kluczowych adresów. Jeśli blokada ma się skończyć 30 czerwca, wpisz to do kalendarza i do treści zgłoszenia — nie polegaj na pamięci.

Kiedy blokowanie stron wymaga wsparcia technicznego

Prosty wpis w robots.txt albo blokada jednego adresu IP to kilkanaście minut pracy. Te same narzędzia użyte odrobinę inaczej potrafią zatrzymać sprzedaż.

• Wdrożenia PrestaShop i WooCommerce, niestandardowe moduły. W PrestaShop robots.txt generuje panel, a reguły w .htaccess dotykają też zaplecza, modułów płatności i koszyka. W WooCommerce wtyczki bezpieczeństwa potrafią zablokować REST API i webhooki płatności, o których nikt nie pamięta przy pisaniu reguł — zanim wpiszesz wyjątek, sprawdź dokumentację WooCommerce. Skutek błędu jest zawsze taki sam: blokada „na boty” wyłącza płatności.
• Administracja VPS. Fail2ban, reguły nginx, firewall dostawcy i WAF w chmurze to cztery miejsca, w których można zablokować ten sam ruch. Zmiana w jednym bez sprawdzenia pozostałych kończy się odcięciem Googlebota albo klientów.
• SEO techniczne, migracje, integracje z ERP, płatnościami i kurierami. Blokady przy przenoszeniu sklepu, wyłączanie indeksowania starych adresów, whitelisty dla systemów ERP i kurierów. Test końcowy jest jeden: zamówienie testowe przechodzi, status wraca do ERP, etykieta się generuje, a produkty nadal widać w wyszukiwarce.

Wycena opiera się na liczbie godzin i przed startem dostajesz zakres prac. Pojedyncza blokada z testem i cofnięciem to zwykle 2–4 godziny. Pełny zestaw dla sklepu — robots.txt, noindex, WAF, staging, monitoring i dokumentacja odwrócenia — 6–12 godzin. Migracja z blokadami i integracjami bywa dłuższa. Po wdrożeniu zostaje opieka z jasnym SLA: czas reakcji na zgłoszenie i osoba, która je prowadzi.

Możemy przejąć całość — wdrożenie profesjonalnej strony internetowej krok po kroku pokazuje, jak to wygląda w praktyce. Jeśli ciekawi Cię, skąd wzięły się dzisiejsze zasady, zobacz materiał o tym, kiedy powstały strony internetowe.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Nazwij cel blokady — Przed wyborem narzędzia ustal, kogo blokujesz (siebie, pracowników, Google, boty) i po co. Bez tego łatwo użyć metody nieadekwatnej do problemu.
• Określ zakres — Zapisz, czy blokujesz jedną podstronę, całą domenę, pojedyncze urządzenie, czy całą sieć. Sprawdź, czy zmiana obejmie też subdomeny i wersje testowe.
• Sprawdź stan indeksu — Przed blokadą dla Google ustal, co już jest zaindeksowane. Pomocny jest raport Indeksowanie stron i narzędzie Sprawdź adres URL w Google Search Console.
• Zrób kopię konfiguracji — Skopiuj plik hosts, .htaccess, konfigurację Nginx i reguły routera przed zmianą. Bez kopii wycofanie blokady zajmuje wielokrotnie więcej czasu.
• Zmień ustawienia na jednym środowisku — Najpierw staging albo jedno urządzenie testowe. Nigdy nie wdrażaj reguły blokującej od razu na całej produkcji.
• Sprawdź nagłówki odpowiedzi — Użyj narzędzia deweloperskiego lub polecenia curl -I, żeby potwierdzić, czy zwracany jest kod 403, 401 lub nagłówek X-Robots-Tag: noindex.
• Test w trybie incognito — Sprawdź blokadę bez cache i bez zalogowanej sesji. Jeśli strona nadal działa w incognito, blokada jest nieaktywna albo omijana.
• Test na telefonie i innej sieci — Sprawdź na urządzeniu mobilnym i z sieci poza firmą (hotspot). Blokada działająca tylko w biurze to filtr sieciowy, nie zabezpieczenie strony.
• Sprawdź integracje krytyczne — Zweryfikuj płatności, kurierów, ERP, monitoring i pozycjonowanie. To one najczęściej padają pierwsze po zbyt szerokiej regule.
• Przejrzyj logi po 24–48 godzinach — Szukaj odpowiedzi 403, 429 i skoków ruchu botów. Reakcja tylko na podstawie testu z jednego komputera bywa myląca.
• Sprawdź obejścia: VPN i DoH — Ustal, czy użytkownicy mogą włączyć DNS-over-HTTPS lub VPN. Jeśli tak, filtr DNS w routerze nie wystarczy.
• Dopisz wpis do rejestru zmian — Data, autor, powód, zakres i planowany termin przeglądu. Każda blokada powinna mieć właściciela.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja