Blog

Jak zablokować indeksowanie strony w Google

Strona nie powinna być widoczna w Google, ale nadal pojawia się w wynikach? To nie jest rzadki przypadek. Najczęściej dotyczy wersji testowych, starych landing page’y po kampanii, paneli klienta, koszyków, filtrów produktów, plików PDF, duplikatów treści albo adresów, które ktoś przypadkiem dodał do mapy strony XML.

Najgorszy ruch to wrzucenie przypadkowej reguły do robots.txt i uznanie sprawy za zamkniętą. Taka blokada może zatrzymać robota Google przed wejściem na adres, ale nie musi usunąć samego URL-a z wyników wyszukiwania. Czasem Google nadal pokazuje adres, tylko bez opisu. Dla właściciela strony wygląda to jak błąd, ale technicznie często wynika z błędnie dobranej metody.

Najpierw trzeba ustalić, co dokładnie ma się stać:

  • strona ma działać dla użytkowników, ale nie ma być w Google;
  • treść ma być ukryta tylko tymczasowo;
  • adres ma zostać usunięty na stałe;
  • roboty mają nie wchodzić do określonego katalogu;
  • treść ma być prywatna i niedostępna dla osób z zewnątrz.

To pięć różnych sytuacji. I pięć różnych decyzji technicznych.

Kiedy użyć noindex, robots.txt, hasła, 404 albo 410

Najważniejsza zasada: robots.txt nie jest narzędziem do pewnego usuwania stron z indeksu Google. Ten plik służy do sterowania crawlowaniem, czyli do informowania robotów, których adresów lub katalogów nie powinny odwiedzać. Nie jest jednak gwarancją, że znany już URL zniknie z wyników wyszukiwania.

Jeżeli Google zna adres z wcześniejszego crawlowania, linków wewnętrznych, linków zewnętrznych albo mapy strony XML, sam wpis w robots.txt może nie wystarczyć. Co gorsza, jeżeli zablokujesz robotowi dostęp do strony, Googlebot może nie zobaczyć dyrektywy noindex, która znajduje się w kodzie tej strony.

W praktyce wybór wygląda tak:

  • meta robots noindex — najlepszy wybór dla zwykłych stron HTML, które mają pozostać dostępne dla użytkowników, ale nie mają być indeksowane;
  • X-Robots-Tag noindex — właściwe rozwiązanie dla plików PDF, dokumentów, obrazów i innych zasobów bez klasycznej sekcji <head>;
  • hasło lub logowanie — najlepsze dla stron prywatnych, paneli, wersji testowych, ofert roboczych i danych, których nie powinien zobaczyć przypadkowy użytkownik;
  • 404 Not Found — poprawny kod dla strony, która nie istnieje;
  • 410 Gone — lepszy wybór przy celowym, trwałym usunięciu treści, bo jasno komunikuje, że adres zniknął na stałe;
  • narzędzie Usunięcia w Google Search Console — szybka blokada widoczności w Google, ale tymczasowa, zwykle na około 6 miesięcy.

Priorytet jest prosty: najpierw zdecyduj, czy Google ma móc wejść na stronę i odczytać dyrektywę. Jeżeli chcesz użyć noindex, nie blokuj tej strony w robots.txt. Googlebot musi ją odwiedzić, żeby zobaczyć tag lub nagłówek.

Praktyczna matryca decyzji:

  • strona ma działać, ale nie ma być w Google — użyj noindex;
  • plik PDF nie ma być w Google — użyj X-Robots-Tag: noindex po stronie serwera;
  • katalog testowy nie ma być dostępny publicznie — użyj HTTP authentication albo innego zabezpieczenia dostępu;
  • produkt, wpis lub landing page został trwale usunięty — zwróć 410 Gone, ewentualnie 404 Not Found;
  • wynik trzeba ukryć natychmiast — użyj Usunięć w Google Search Console, ale równolegle wdroż trwałe rozwiązanie.

Nie mieszaj metod bez potrzeby. Noindex nie zabezpiecza poufnych danych, bo osoba z linkiem nadal może wejść na stronę. Robots.txt nie gwarantuje usunięcia adresu z indeksu. Search Console nie usuwa problemu na stałe, tylko ukrywa wynik na ograniczony czas. 404 na stronie, która ma wrócić za kilka dni, może niepotrzebnie wprowadzić bałagan diagnostyczny.

Osobna decyzja dotyczy kodów 404 i 410. Przy przypadkowo brakującej stronie wystarczy 404. Przy świadomym, trwałym usunięciu treści lepszy jest 410, bo jest mocniejszym sygnałem: „ta treść została usunięta i nie wróci”. Google może usunąć taki adres z indeksu trochę szybciej niż typowy 404, ale nie oznacza to, że robot nigdy więcej nie sprawdzi URL-a. Jeżeli gdzieś nadal prowadzą do niego linki, Googlebot może wracać kontrolnie.

Jak wdrożyć blokadę indeksowania krok po kroku

Najczystszy wariant dla strony HTML to dodanie tagu w sekcji <head>:

<meta name="robots" content="noindex">

Można też użyć wersji skierowanej tylko do Google:

<meta name="googlebot" content="noindex">

W praktyce częściej wybiera się robots, bo taka dyrektywa jest szersza i może być respektowana także przez inne roboty. googlebot ma sens wtedy, gdy decyzja dotyczy wyłącznie Google, a inne wyszukiwarki mają traktować stronę inaczej. W większości serwisów nie ma potrzeby tak komplikować konfiguracji.

Po wdrożeniu sprawdź sześć rzeczy:

  1. Czy tag znajduje się w sekcji <head>, a nie przypadkowo w treści strony.
  2. Czy strona zwraca kod 200 OK, jeśli ma być dostępna dla Googlebota i oznaczona jako noindex.
  3. Czy URL nie jest zablokowany w robots.txt.
  4. Czy system cache, motyw, wtyczka SEO albo szablon nie nadpisuje dyrektywy.
  5. Czy JavaScript nie usuwa albo nie zmienia tagu po wyrenderowaniu strony.
  6. Czy adres nie znajduje się nadal w mapie strony XML jako URL przeznaczony do indeksowania.

Przy stronach renderowanych przez JavaScript samo sprawdzenie źródła przez CTRL+U nie wystarczy. Trzeba użyć narzędzia Sprawdź URL w Google Search Console i obejrzeć wyrenderowany HTML, bo Googlebot najpierw pobiera kod, a później może wykonać JavaScript w osobnym etapie renderowania. Jeżeli tag noindex jest w źródle, ale znika po renderowaniu, Google może zobaczyć inną wersję strony niż tę, którą sprawdza deweloper w przeglądarce.

Dla plików PDF, obrazów, dokumentów i innych zasobów bez HTML-a lepszy jest nagłówek HTTP:

X-Robots-Tag: noindex

To rozwiązanie ustawia się po stronie serwera, hostingu, aplikacji, CDN albo konfiguracji reverse proxy. Nie dodasz klasycznego meta tagu do PDF-a, bo PDF nie ma sekcji <head>. Dlatego przy dokumentach trzeba działać nagłówkiem.

Przykład dla serwera Apache w pliku .htaccess:

<FilesMatch "\.(pdf)$">
  Header set X-Robots-Tag "noindex"
</FilesMatch>

Ważne: moduł headers musi być dostępny na serwerze. Na wielu hostingach współdzielonych działa od razu, ale nie zawsze. Po wdrożeniu trzeba sprawdzić odpowiedź HTTP, np. w DevTools, przez curl -I albo narzędzie do testowania nagłówków.

Przykład dla Nginx:

location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex";
}

Po zmianie konfiguracji Nginx zwykle trzeba przetestować konfigurację i przeładować serwer. Samo zapisanie pliku nie wystarczy. Jeżeli przed serwerem stoi CDN, cache może nadal serwować starą odpowiedź bez nagłówka, więc po wdrożeniu trzeba wyczyścić cache dla plików PDF.

Dla aplikacji generującej wiele adresów dynamicznych, np. filtrów w e-commerce, ręczne dodawanie noindex do każdego URL-a jest stratą czasu. Lepsza jest reguła w szablonie lub logice aplikacji. Przykład: filtr ?kolor=czarny&rozmiar=xl może tworzyć pustą, cienką albo powtarzalną stronę. Taki adres często warto oznaczyć jako noindex. Ale jeżeli filtr tworzy realną stronę z popytem, np. czarne buty skórzane męskie, automatyczne noindex może odciąć wartościowy ruch organiczny.

Dlatego decyzja powinna wyglądać tak:

  • filtry bez popytu, z pustymi wynikami lub duplikujące listing — zwykle noindex;
  • filtry z ruchem, wyszukiwaniami i unikalną ofertą — zostawić do indeksowania;
  • warianty sortowania, np. ?sort=price_asc — zwykle nie indeksować;
  • paginacja — nie blokować automatycznie bez sprawdzenia wpływu na odkrywanie produktów;
  • parametry trackingowe, np. utm_source — obsłużyć kanonikalem lub konfiguracją aplikacji, a nie losowym noindex.

W przypadku stron testowych pierwszym wyborem nie powinien być noindex, tylko blokada dostępu. Strona stagingowa z przyszłą ofertą, cennikiem, danymi klienta albo niedokończonym layoutem nie powinna być publiczna nawet przez chwilę. Noindex ogranicza widoczność w wyszukiwarce, ale nie blokuje wejścia po linku.

Jeżeli strona już jest w Google i trzeba ją szybko ukryć, użyj narzędzia Usunięcia w Google Search Console. To działa jako rozwiązanie awaryjne: ukrywa URL z wyników wyszukiwania na około 6 miesięcy. W tym czasie trzeba wdrożyć właściwą metodę: noindex, 404, 410, hasło, zmianę treści albo usunięcie pliku. Jeżeli tego nie zrobisz, adres może wrócić do wyników po wygaśnięciu blokady.

Najczęstsze błędy, które opóźniają usunięcie strony z Google

Pierwszy błąd: jednoczesne użycie Disallow i noindex. Wygląda bezpiecznie, ale często psuje cały proces. Jeżeli robots.txt blokuje dostęp do strony, Googlebot może nie zobaczyć tagu noindex. Efekt: URL nadal może wisieć w wynikach, mimo że w kodzie strony znajduje się poprawna dyrektywa.

Drugi błąd: oczekiwanie natychmiastowego efektu. Google musi ponownie odwiedzić adres, odczytać dyrektywę i przetworzyć zmianę. Dla popularnej strony może to pójść szybko. Dla głębokiego, rzadko linkowanego URL-a potrwa dłużej. Nie da się zagwarantować konkretnej daty usunięcia z indeksu. Można tylko poprawić warunki: udostępnić stronę robotowi, dodać poprawny noindex, zgłosić adres w Google Search Console i nie blokować crawlowania.

Trzeci błąd: przeniesienie noindex z wersji testowej na produkcję. To klasyk przy migracjach. Zespół ustawia noindex na stagingu, potem wypycha szablon na produkcję, a po kilku dniach zaczyna spadać widoczność kategorii, produktów albo wpisów blogowych. To nie jest kosmetyczna pomyłka. Jeden tag w złym szablonie potrafi wyciąć z Google całe sekcje serwisu.

Czwarty błąd: traktowanie noindex jako zabezpieczenia danych. To nie jest zabezpieczenie. Jeżeli treść jest poufna, powinna być za logowaniem, hasłem albo poza publicznym serwerem. Google może jej nie pokazywać, ale osoba z linkiem nadal może ją otworzyć.

Piąty błąd: brak kontroli po wdrożeniu. Samo dodanie reguły niczego nie kończy. Trzeba sprawdzić, jak adres widzi Googlebot i co faktycznie zwraca serwer.

Po wdrożeniu przejrzyj:

  • źródło HTML;
  • wyrenderowany HTML w Google Search Console;
  • odpowiedź HTTP i nagłówki;
  • kod statusu serwera: 200 OK, 404 Not Found albo 410 Gone;
  • plik robots.txt;
  • mapę strony XML;
  • status URL-a w Google Search Console;
  • to, czy Googlebot poprawnie odczytuje tag noindex lub nagłówek X-Robots-Tag.

Najważniejsza rekomendacja: najpierw usuń sprzeczności. Jeżeli strona ma noindex, pozwól Google ją odwiedzić. Jeżeli strona ma być prywatna, nie licz na noindex, tylko zamknij dostęp. Jeżeli treść została trwale usunięta, nie udawaj, że nadal istnieje — zwróć 410 albo 404. Jeżeli chcesz szybkiego ukrycia w wynikach, użyj Search Console, ale potraktuj to jako działanie tymczasowe, nie rozwiązanie problemu.

FAQ: najczęstsze pytania o blokowanie indeksowania strony w Google

Czy robots.txt usuwa stronę z Google?
Nie zawsze. robots.txt blokuje crawlowanie, ale nie jest pewnym sposobem na usunięcie znanego już adresu z wyników. Jeżeli Google zna URL z linków lub wcześniejszego crawlowania, adres może nadal pojawiać się w wyszukiwarce.

Co jest lepsze: noindex czy robots.txt?
Do usunięcia strony z indeksu zwykle lepszy jest noindex, bo daje wyszukiwarce jasną dyrektywę. robots.txt wybierz wtedy, gdy chcesz ograniczyć crawlowanie, a nie usuwać znany już URL z wyników.

Czy można użyć noindex i robots.txt jednocześnie?
Zwykle nie. Jeżeli robots.txt blokuje dostęp do strony, Google może nie zobaczyć tagu noindex. To jedna z najczęstszych technicznych pułapek przy deindeksacji.

Jak szybko Google usunie stronę po dodaniu noindex?
Nie ma gwarantowanego terminu. Google musi ponownie odwiedzić URL i przetworzyć zmianę. Możesz pomóc przez narzędzie Sprawdź URL w Google Search Console, ale wielokrotne zgłaszanie tego samego adresu nie wymusi natychmiastowego usunięcia.

Na jak długo działa narzędzie Usunięcia w Google Search Console?
Tymczasowe usunięcie działa zwykle przez około 6 miesięcy. To czas na wdrożenie trwałego rozwiązania: noindex, 404, 410, hasła, usunięcia treści albo poprawy dostępu. Jeżeli URL nadal istnieje i nie ma trwałej blokady, może wrócić do wyników po wygaśnięciu zgłoszenia.

Czy noindex ukrywa stronę przed użytkownikami?
Nie. Noindex wpływa na widoczność w wyszukiwarce, ale nie blokuje dostępu do strony. Do ochrony prywatnych treści użyj logowania, hasła, ograniczeń IP albo blokady po stronie serwera.

Jak zablokować indeksowanie pliku PDF?
Najczęściej przez nagłówek X-Robots-Tag: noindex ustawiony po stronie serwera. Meta tag HTML nie zadziała na PDF, bo taki plik nie ma klasycznej sekcji <head>.

Czy dla PDF-a lepszy jest robots.txt czy X-Robots-Tag?
Jeżeli PDF ma zniknąć z indeksu, lepszy jest X-Robots-Tag: noindex, bo Google musi móc pobrać plik i odczytać nagłówek. Blokada w robots.txt może uniemożliwić robotowi sprawdzenie dyrektywy.

Czy 410 jest lepsze od 404?
Przy trwałym, świadomym usunięciu treści — tak. 410 Gone jest czytelniejszym sygnałem, że adres zniknął na stałe, i może zostać usunięty z indeksu szybciej niż zwykły 404. Nie oznacza to jednak, że Googlebot nigdy więcej nie sprawdzi URL-a.

Czy trzeba usuwać adres z mapy strony XML?
Tak, jeżeli adres ma pozostać poza indeksem. Sitemap powinna zawierać URL-e przeznaczone do indeksowania. Wysyłanie Google adresów z noindex robi bałagan diagnostyczny i utrudnia kontrolę.

Jak sprawdzić, czy JavaScript nie psuje noindex?
Użyj narzędzia Sprawdź URL w Google Search Console i sprawdź wyrenderowany HTML. Nie opieraj się wyłącznie na CTRL+U, bo źródło strony może różnić się od wersji po wykonaniu JavaScriptu.

Od czego zacząć, jeśli strona już jest w Google?
Najpierw ustal, czy adres ma zniknąć na stałe, być ukryty tymczasowo, czy zostać zabezpieczony przed dostępem. Potem wybierz metodę: noindex dla działającej strony, 410 lub 404 dla usuniętej, hasło dla prywatnej, Search Console dla pilnego ukrycia. Najgorszy pierwszy ruch to losowe blokowanie wszystkiego w robots.txt.

CMspace to wydawca portali i blogów. Oferujemy publikacje w dobrze przygotowanych, zadbanych lokalizacjach w oparciu o wysokiej jakości treści. Dostarczamy linki z artykułów sponsorowanych w wielotematycznych i tematycznych serwisach przy zachowaniu atrakcyjnych cen publikacji. [ Gravatar ]

Powiązane artykuły

Comments (0)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Back To Top