Nagłówek X-Robots-Tag. Jak zablokować indeksowanie plików PDF i grafik?

Cennik w pliku PDF sprzed kilku sezonów, skan umowy, wewnętrzna instrukcja albo zdjęcie, które nigdy nie miało być publiczne. Takie pliki potrafią pojawić się w Google po wpisaniu nazwy firmy i odebrać ruch właściwym podstronom. W zwykłej podstronie wystarczy metatag w kodzie, ale plik PDF i grafika nie mają sekcji, w której dałoby się go umieścić.

Do tego służy nagłówek X-Robots-Tag. Serwer dołącza go do odpowiedzi razem z plikiem, a robot wyszukiwarki odczytuje z niego, czy plik wolno pokazać w wynikach. Rozwiązanie jest proste, ale łatwo je zepsuć jedną regułą w pliku robots.txt albo wkleić w złe miejsce konfiguracji.

Tekst jest przeznaczony dla właścicieli firm i osób, które opiekują się stroną bez pomocy programisty. Po lekturze będzie wiadomo, jak ustalić, które pliki są w indeksie, jak ustawić nagłówek na serwerze Apache, LiteSpeed i NGINX, jak sprawdzić, czy serwer rzeczywiście go wysyła, oraz co zrobić, gdy plik mimo wszystko nie znika z wyników.

Czym jest nagłówek X-Robots-Tag i kiedy jest potrzebny?

Każda odpowiedź serwera składa się z dwóch części. Pierwsza to nagłówki, czyli krótkie informacje techniczne niewidoczne dla odwiedzającego. Druga to właściwa treść: strona, dokument PDF albo obraz. X-Robots-Tag jest jednym z takich nagłówków i przenosi polecenia dla robotów wyszukiwarek.

Dokumentacja Google podaje wprost, że każda reguła, której można użyć w metatagu robots, może zostać podana także w nagłówku X-Robots-Tag. Ta sama dokumentacja zaleca nagłówek do blokowania zasobów w formacie innym niż HTML, takich jak pliki PDF, pliki wideo i pliki graficzne. Najprostsza odpowiedź serwera z blokadą wygląda tak:

HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex

Nagłówek przydaje się w trzech sytuacjach. Pierwsza to pliki, które mają być dostępne dla osoby znającej adres, ale nie powinny być znajdowane w wyszukiwarce, na przykład regulaminy archiwalne czy materiały dla klientów. Druga to duplikaty: ta sama treść istnieje jako podstrona i jako PDF, a w wynikach wygrywa plik bez menu i bez formularza kontaktowego. Trzecia to grafiki, które nie powinny trafiać do wyszukiwarki obrazów.

Trzeba od razu zaznaczyć granicę tego rozwiązania. Nagłówek nie chroni pliku przed otwarciem. Kto ma adres, ten plik pobierze. Dokumenty poufne, dane osobowe i umowy wymagają hasła albo usunięcia z serwera, a nie reguły dla robotów.

Jakie reguły można umieścić w nagłówku?

Do blokowania plików wystarczą w praktyce dwie lub trzy reguły. Pozostałe są przydatne rzadziej, ale dobrze wiedzieć, że istnieją, bo część wtyczek i gotowych konfiguracji wstawia je automatycznie.

• noindex – plik nie będzie pokazywany w wynikach wyszukiwania. To podstawowa reguła dla PDF i grafik.
• nofollow – robot nie podąża za linkami zapisanymi w dokumencie. W plikach PDF z odnośnikami bywa łączona z noindex.
• none – odpowiednik połączenia noindex i nofollow.
• nosnippet – plik może być w wynikach, ale bez fragmentu tekstu pod tytułem.
• noimageindex – reguła dla stron: obrazy umieszczone na danej stronie nie są indeksowane w jej kontekście.
• unavailable_after – plik przestaje być pokazywany po wskazanej dacie i godzinie.

Reguły można podać w jednym nagłówku, rozdzielając je przecinkami, albo w kilku osobnych nagłówkach. Gdy reguły są ze sobą sprzeczne, Google stosuje bardziej restrykcyjną. Wielkość liter w nazwie nagłówka i w wartościach nie ma znaczenia.

Przed regułą wolno podać nazwę robota, na przykład X-Robots-Tag: googlebot: noindex. Taki zapis dotyczy tylko wskazanego robota. Nagłówek bez nazwy obowiązuje wszystkie roboty, które go respektują, i w większości firmowych stron jest to właściwy wybór.

Osobnej uwagi wymaga reguła noimageindex. Dokumentacja zaznacza, że blokuje ona obrazy tylko na stronie, na której została ustawiona. Jeśli ten sam obraz występuje na innej podstronie, może zostać zindeksowany. Pewność, że grafika jest zablokowana niezależnie od miejsca wyświetlania, daje dopiero nagłówek noindex wysyłany razem z samym plikiem graficznym.

Po czym poznać, że pliki PDF lub grafiki trafiły do Google?

Zanim cokolwiek zostanie zmienione na serwerze, należy ustalić skalę problemu. Najszybciej robi się to bezpośrednio w wyszukiwarce, za pomocą operatorów ograniczających wyniki do jednej domeny i jednego typu pliku.

1. W polu wyszukiwarki Google wpisuje się zapytanie site:nazwafirmy.pl filetype:pdf, podstawiając własną domenę. Lista wyników pokazuje pliki PDF, które wyszukiwarka zna i wyświetla.
2. To samo zapytanie warto powtórzyć dla innych formatów dokumentów, zmieniając końcówkę na filetype:doc, filetype:docx lub filetype:xls.
3. Grafiki sprawdza się w wyszukiwarce obrazów: po wpisaniu site:nazwafirmy.pl należy przejść na kartę „Grafika”.
4. Adresy znalezionych plików trzeba skopiować do arkusza albo notatki. Ta lista posłuży później do kontroli, czy blokada zadziałała.
5. Na koniec należy otworzyć raport „Indeksowanie stron” w Google Search Console i przejrzeć przykładowe adresy zindeksowanych stron pod kątem adresów kończących się na .pdf.

Operator site: nie pokazuje pełnego obrazu indeksu, ale do wstępnej oceny wystarcza. Szerszy opis metod sprawdzania zawiera osobny tekst o tym, jak sprawdzić, czy Google zaindeksował stronę.

Przy okazji warto zapisać, w jakich katalogach leżą znalezione pliki. W WordPressie będzie to najczęściej katalog /wp-content/uploads/. Ta informacja zdecyduje o tym, gdzie trafi reguła i jak szeroko zadziała.

Dlaczego samo robots.txt nie wystarcza i często szkodzi?

Najczęstszy błąd polega na dopisaniu do pliku robots.txt zakazu skanowania plików PDF w przekonaniu, że to usunie je z wyników. Tymczasem robots.txt steruje skanowaniem, a nie indeksowaniem. Zablokowany adres może nadal widnieć w wynikach, jeśli prowadzą do niego linki z innych stron. Wyszukiwarka pokazuje wtedy sam adres bez opisu.

Drugi problem jest poważniejszy. Dokumentacja Google wyjaśnia, że metatagi robots i nagłówki X-Robots-Tag są odczytywane podczas skanowania adresu. Jeśli plik robots.txt zabrania skanowania, robot nie pobierze odpowiedzi serwera, nie zobaczy nagłówka i nie zastosuje się do niego. Obie blokady założone jednocześnie wzajemnie się wyłączają.

Z tego wynika prosta zasada dla plików PDF: albo nagłówek z regułą noindex i otwarta droga dla robota, albo usunięcie pliku. Jak czytać i poprawiać reguły skanowania, opisałem w tekście o tym, jak ustawić plik robots.txt.

W przypadku grafik sytuacja wygląda nieco inaczej. Dokumentacja Google dotycząca usuwania obrazów wskazuje dwa trwałe sposoby: reguły disallow w pliku robots.txt oraz nagłówek noindex X-Robots-Tag. Według niej obie metody dają ten sam efekt i należy wybrać jedną, tę łatwiejszą do wdrożenia. Stosowanie obu naraz nie ma sensu, ponieważ robot musi przeskanować adres, żeby odczytać nagłówek.

Co przygotować, zanim zmieni się konfigurację serwera?

Zmiana w pliku konfiguracyjnym serwera działa natychmiast i dotyczy całej strony. Jeden błędny znak w pliku .htaccess może spowodować błąd 500 na wszystkich podstronach. Dlatego przed edycją trzeba wykonać kilka czynności zabezpieczających.

1. Ustalenie rodzaju serwera. Informację podaje panel hostingu albo pomoc techniczna dostawcy. Apache i LiteSpeed odczytują plik .htaccess, NGINX go nie obsługuje i wymaga zmiany w pliku konfiguracyjnym witryny.
2. Pobranie kopii aktualnego pliku .htaccess na dysk komputera, przez menedżer plików w panelu hostingu albo przez FTP. W razie błędu wystarczy wgrać kopię z powrotem.
3. Sprawdzenie, czy plik robots.txt nie zabrania skanowania katalogów z plikami, które mają dostać nagłówek. Jeżeli zabrania, tę regułę należy usunąć.
4. Ustalenie, czy pliki są serwowane z własnej domeny, czy z sieci CDN pod innym adresem. W drugim przypadku nagłówek ustawia się również po stronie CDN.
5. Decyzja o zakresie: wszystkie pliki danego typu, jeden katalog czy pojedyncze dokumenty. Im węższy zakres, tym mniejsze ryzyko przypadkowego ukrycia czegoś potrzebnego.

Ostatni punkt jest ważniejszy, niż się wydaje. Blokada wszystkich grafik w całej domenie odbiera ruch z wyszukiwarki obrazów, który w sklepach i w branżach wizualnych bywa cenny. Podobnie z dokumentami: katalog produktów w PDF może sprowadzać klientów i nie ma powodu go ukrywać.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: ustalę, które pliki są w indeksie, ustawię nagłówek X-Robots-Tag na serwerze i dopilnuję, żeby wskazane dokumenty i grafiki zniknęły z wyników.

Jak ustawić X-Robots-Tag na serwerze Apache, LiteSpeed i NGINX?

Na serwerach Apache nagłówki dodaje moduł mod_headers, a reguły wpisuje się do pliku .htaccess w katalogu głównym strony. LiteSpeed odczytuje ten sam plik i te same dyrektywy. Przykłady poniżej pochodzą z dokumentacji Google, uzupełniłem je tylko o warunek chroniący stronę przed błędem.

Blokada wszystkich plików PDF

Fragment należy wkleić na samej górze pliku .htaccess, przed blokiem zaczynającym się od wiersza # BEGIN WordPress. Treść między znacznikami BEGIN i END WordPress bywa nadpisywana przez system, więc własne reguły nie powinny tam trafiać.

<IfModule mod_headers.c>
<Files ~ "\.pdf$">
Header set X-Robots-Tag "noindex, nofollow"
</Files>
</IfModule>

Wiersze z IfModule sprawiają, że serwer bez włączonego modułu mod_headers pominie regułę, zamiast wyświetlić błąd 500. Ma to jedną wadę: brak modułu nie da żadnego komunikatu, a nagłówek po prostu się nie pojawi. Dlatego późniejsza kontrola odpowiedzi serwera jest obowiązkowa.

Blokada dokumentów w kilku formatach

Jeśli na serwerze leżą także pliki Worda i Excela, wyrażenie w cudzysłowie można rozszerzyć o kolejne rozszerzenia oddzielone pionową kreską.

<IfModule mod_headers.c>
<Files ~ "\.(pdf|docx?|xlsx?|pptx?)$">
Header set X-Robots-Tag "noindex, nofollow"
</Files>
</IfModule>

Blokada grafik

Dokumentacja Google podaje gotowy wzór dla plików PNG, JPEG i GIF. Radzę stosować go ostrożnie i raczej w wybranym katalogu niż w całej domenie.

<IfModule mod_headers.c>
<Files ~ "\.(png|jpe?g|gif)$">
Header set X-Robots-Tag "noindex"
</Files>
</IfModule>

Jeśli strona serwuje obrazy w nowszych formatach, do listy trzeba dopisać ich rozszerzenia, na przykład webp i avif. W przeciwnym razie blokada obejmie tylko część grafik.

Blokada jednego katalogu albo jednego pliku

Plik .htaccess działa w katalogu, w którym leży, i we wszystkich podkatalogach. Aby ograniczyć regułę do jednego folderu, wystarczy utworzyć w nim osobny plik .htaccess z tym samym fragmentem. Tak blokuje się na przykład katalog z materiałami dla klientów, nie ruszając reszty strony.

Pojedynczy plik wskazuje się po nazwie. Zgodnie z dokumentacją plik .htaccess musi wtedy znajdować się w tym samym katalogu co blokowany dokument.

<IfModule mod_headers.c>
<Files "cennik-archiwalny.pdf">
Header set X-Robots-Tag "noindex, nofollow"
</Files>
</IfModule>

Po zapisaniu zmian należy od razu otworzyć stronę główną i jedną podstronę w przeglądarce. Jeżeli pojawia się błąd 500, trzeba przywrócić kopię pliku i poszukać literówki. Zasady bezpiecznej pracy z tym plikiem omawia tekst o tym, jak wykonać przekierowanie 301 w pliku .htaccess.

Ten sam nagłówek na serwerze NGINX

NGINX nie czyta pliku .htaccess. Reguły trafiają do pliku konfiguracyjnego witryny, do którego dostęp ma administrator serwera. Na hostingu współdzielonym trzeba zwykle poprosić o to pomoc techniczną albo skorzystać z pola na własne dyrektywy w panelu, jeśli dostawca takie udostępnia.

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

Dla grafik dokumentacja Google podaje analogiczny zapis z regułą noindex:

location ~* \.(png|jpe?g|gif)$ {
add_header X-Robots-Tag "noindex";
}

W NGINX są dwie pułapki. Po pierwsze, żądanie obsługuje jeden blok location. Jeżeli w konfiguracji istnieje już blok dla plików statycznych z ustawieniami pamięci podręcznej, nowy blok może przejąć pliki PDF i pozbawić je tamtych ustawień albo sam zostać pominięty. Bezpieczniej dopisać wiersz add_header do bloku, który te pliki już obsługuje.

Po drugie, dyrektywy add_header z wyższego poziomu konfiguracji są dziedziczone tylko wtedy, gdy na bieżącym poziomie nie ma żadnej własnej. Dopisanie jednego nagłówka w bloku location może więc usunąć z odpowiedzi nagłówki bezpieczeństwa ustawione wyżej. Po zmianie należy sprawdzić składnię poleceniem nginx -t, przeładować serwer i porównać pełną listę nagłówków przed zmianą i po niej.

Co z WordPressem, wtyczkami SEO i siecią CDN?

WordPress nie wysyła plików z biblioteki mediów przez własny kod. Plik PDF z katalogu uploads podaje bezpośrednio serwer, z pominięciem systemu i wtyczek. Dlatego ustawienie noindex we wtyczce SEO dotyczy podstron, w tym stron załączników, ale zwykle nie dodaje nagłówka do samego pliku.

W praktyce oznacza to, że dla plików z biblioteki mediów właściwym miejscem pozostaje plik .htaccess albo konfiguracja NGINX. Część wtyczek ma własny edytor pliku .htaccess i ten sposób jest równie dobry jak menedżer plików, pod warunkiem wcześniejszego wykonania kopii.

Odwrotnie jest z dokumentami generowanymi w locie, na przykład fakturami albo ofertami tworzonymi przez wtyczkę pod adresem bez rozszerzenia .pdf. Reguła oparta na rozszerzeniu ich nie obejmie. Nagłówek musi wtedy wysłać skrypt, który tworzy dokument, co wymaga zmiany w kodzie albo ustawienia w samej wtyczce.

Pliki serwowane z CDN

Sieć CDN przechowuje kopie plików razem z nagłówkami, z którymi je pobrała. Po dodaniu reguły na serwerze źródłowym stara kopia bez nagłówka może być podawana jeszcze długo. Trzeba więc wyczyścić pamięć podręczną CDN dla zmienionych plików i sprawdzić odpowiedź pod adresem, pod którym plik faktycznie jest linkowany na stronie.

Jeśli pliki leżą w zewnętrznym magazynie pod osobną domeną, plik .htaccess strony w ogóle ich nie dotyczy. Nagłówek ustawia się wtedy w panelu dostawcy CDN, zwykle w regułach modyfikujących nagłówki odpowiedzi. Dokumentacja Google zaznacza, że gdy nie ma dostępu do miejsca, w którym pliki są hostowane, i nie da się ustawić ani nagłówka, ani robots.txt, może być konieczne całkowite usunięcie plików.

Podobnie działa pamięć podręczna po stronie serwera. Po zmianie konfiguracji należy ją opróżnić, inaczej test pokaże starą odpowiedź i wywoła niepotrzebne poszukiwanie błędu.

Jak sprawdzić, czy serwer naprawdę wysyła nagłówek?

Zapisanie reguły to połowa pracy. Dopóki nagłówek nie jest widoczny w odpowiedzi serwera, dla wyszukiwarki nic się nie zmieniło. Kontrolę wykonuje się w przeglądarce albo w wierszu poleceń.

1. W przeglądarce Chrome należy otworzyć narzędzia dla deweloperów klawiszem F12 i przejść na kartę „Sieć” („Network”).
2. W pasku adresu wpisuje się pełny adres pliku PDF lub grafiki i zatwierdza klawiszem Enter.
3. Na liście żądań trzeba kliknąć pozycję z nazwą pliku i odszukać część z nagłówkami odpowiedzi.
4. Wśród nagłówków powinien znajdować się wiersz X-Robots-Tag: noindex, nofollow albo inna ustawiona wartość.
5. Test należy powtórzyć dla adresu z CDN, dla wersji z www i bez www oraz dla jednego pliku, który nie miał zostać zablokowany.

Osoby korzystające z terminala mogą użyć polecenia curl -I https://nazwafirmy.pl/wp-content/uploads/cennik.pdf. Wynik to sama lista nagłówków, bez pobierania pliku. Jeśli adres przekierowuje, polecenie trzeba powtórzyć dla adresu docelowego, bo nagłówek ma znaczenie przy odpowiedzi z kodem 200.

Kontrola plików, które miały pozostać widoczne, jest równie ważna jak kontrola blokady. Należy otworzyć w ten sam sposób także stronę główną i kilka najważniejszych podstron. W ich nagłówkach nie może być wartości noindex. Zbyt szeroka reguła, która objęła całą witrynę, to najkosztowniejsza pomyłka przy tej pracy.

Narzędzie do sprawdzania adresów URL w Google Search Console pokazuje dla sprawdzanego adresu między innymi pole „Czy indeksowanie jest dozwolone”. Jest ono pomyślane przede wszystkim dla stron internetowych, dlatego przy plikach traktuję je jako uzupełnienie, a za rozstrzygającą uznaję odpowiedź samego serwera.

Jak przyspieszyć zniknięcie plików z wyników i ile to trwa?

Nagłówek działa dopiero wtedy, gdy robot ponownie pobierze plik. Według dokumentacji Google ponowne przeskanowanie może potrwać nawet kilka miesięcy, zależnie od znaczenia adresu w sieci. Pliki PDF i grafiki są odwiedzane rzadziej niż podstrony, więc cierpliwość jest tu potrzebna.

Gdy plik powinien zniknąć szybko, używa się narzędzia „Usunięcia” w Google Search Console. Ukrywa ono adres w wynikach na około 6 miesięcy. To czas na to, żeby robot odczytał nagłówek i trwale wycofał plik z indeksu.

1. W Google Search Console należy otworzyć narzędzie „Usunięcia” i pozostać na karcie „Tymczasowe usunięcia”.
2. Trzeba kliknąć przycisk „Nowa prośba”.
3. W oknie wybiera się „Tymczasowe usunięcie adresu URL” i wkleja pełny adres pliku.
4. Dla pojedynczego pliku zaznacza się „Usuń tylko ten URL”. Dla całego katalogu z dokumentami służy opcja „Usuń wszystkie URL-e z tym prefiksem”.
5. Po kliknięciu „Dalej” i zatwierdzeniu prośba pojawia się w tabeli ze statusem „Przetwarzam prośbę”, a po akceptacji ze statusem „Tymczasowe usunięcie”.

Opcja z prefiksem jest wygodna, ale ukrywa wszystko, co zaczyna się od wpisanego adresu. Wpisanie zbyt krótkiego prefiksu może schować w wynikach całe działy strony. Prośbę da się wycofać w tabeli historii poleceniem „Anuluj prośbę”.

Przy grafikach potrzebny jest adres samego pliku, a nie strony, na której obraz widać. Pomoc Google radzi odszukać obraz w wyszukiwarce grafiki i skopiować adres linku. Ten sam obraz bywa dostępny w kilku rozmiarach pod różnymi adresami i każdy z nich wymaga osobnego zgłoszenia albo wspólnego prefiksu.

Tymczasowe usunięcie nie zastępuje nagłówka. Po wygaśnięciu prośby plik bez trwałej blokady może wrócić do wyników. Jeżeli z kolei w wynikach wisi plik już skasowany z serwera, właściwą drogą jest narzędzie do usuwania nieaktualnych treści.

Co zrobić, gdy plik mimo nagłówka nadal jest w Google?

Jeżeli po kilku tygodniach pliki wciąż pojawiają się w wynikach, przyczyna prawie zawsze należy do krótkiej listy. Każdą z pozycji da się sprawdzić samodzielnie w kilka minut.

• Blokada w robots.txt. Robot nie może pobrać pliku, więc nie widzi nagłówka. W Search Console taki adres bywa oznaczony statusem „Strona zindeksowana, ale zablokowana przez plik robots.txt”. Regułę zakazującą skanowania trzeba usunąć.
• Nagłówek nie jest wysyłany. Brak modułu mod_headers, reguła wklejona w niewłaściwym pliku albo w katalogu, którego nie dotyczy. Rozstrzyga test odpowiedzi serwera.
• Stara kopia w CDN lub w pamięci podręcznej. Serwer źródłowy odpowiada poprawnie, ale użytkownicy i roboty dostają wersję sprzed zmiany. Pomaga wyczyszczenie pamięci.
• Plik dostępny pod innym adresem. Ten sam dokument leży w dwóch katalogach albo na subdomenie, której reguła nie obejmuje. Każdą kopię trzeba zablokować osobno lub usunąć.
• Wzorzec nie pasuje do nazwy. Rozszerzenie zapisane wielkimi literami albo adres z parametrem po znaku zapytania. W Apache dyrektywa Files porównuje nazwę pliku z uwzględnieniem wielkości liter, dlatego dla plików z końcówką .PDF wzorzec wymaga rozszerzenia.
• Robot jeszcze nie wrócił. Konfiguracja jest poprawna, a plik po prostu czeka na ponowne skanowanie. Wtedy pozostaje tymczasowe usunięcie i czas.

O skuteczności świadczą trzy rzeczy. Zapytanie z operatorami site: i filetype: zwraca coraz mniej wyników. Adresy z listy sporządzonej na początku przestają się pojawiać po wpisaniu ich tytułów. W raporcie „Indeksowanie stron” zablokowane adresy trafiają do grupy niezindeksowanych z przyczyną „URL zawiera tag „noindex””.

Ten ostatni wpis w raporcie nie jest błędem do naprawienia, lecz potwierdzeniem zamierzonego stanu. Nie należy uruchamiać dla niego weryfikacji poprawki ani prosić o zindeksowanie tych adresów.

Jakich błędów unikać przy blokowaniu plików?

Pierwszy błąd to nagłówek ustawiony dla całej domeny zamiast dla wybranych plików. Zdarza się po skopiowaniu konfiguracji ze środowiska testowego, gdzie blokada wszystkiego była celowa. Strona znika wtedy z wyników stopniowo, a przyczyny nie widać w kodzie podstron, bo nagłówki nie są częścią kodu HTML.

Drugi błąd to traktowanie reguły noindex jako zabezpieczenia. Dokument z danymi osobowymi nie staje się bezpieczny przez to, że nie ma go w wyszukiwarce. Adres może krążyć w wiadomościach, a część robotów w ogóle nie respektuje tych reguł. Takie pliki powinny być dostępne po zalogowaniu albo usunięte.

Trzeci błąd dotyczy mapy witryny i linków. Zablokowane pliki nie powinny być wymieniane w mapie XML. Jeśli PDF zastępowała podstrona z tą samą treścią, lepiej linkować w serwisie do podstrony, a plik zostawić jako materiał do pobrania.

Czwarty błąd to pochopne kasowanie plików. Usunięcie dokumentu, do którego prowadzą linki z innych stron, kończy się błędem 404 dla odwiedzających. Jeżeli plik ma następcę, właściwsze jest przekierowanie na nową wersję albo na podstronę. Jeżeli nie ma, a treść musi zniknąć całkowicie, usunięcie jest w porządku i daje ten sam skutek w wynikach co noindex.

Piąty błąd to brak ponownej kontroli. Aktualizacja wtyczki, zmiana hostingu albo włączenie CDN potrafią po cichu usunąć nagłówek. Uważam, że test odpowiedzi serwera dla dwóch lub trzech plików warto powtarzać po każdej większej zmianie technicznej na stronie.

Najczęstsze pytania

Czy X-Robots-Tag działa tylko w Google?

Nie. Nagłówek odczytują także inne duże wyszukiwarki, choć zestaw obsługiwanych reguł może się między nimi różnić. Reguła noindex należy do najszerzej respektowanych. Roboty, które nie stosują się do żadnych zasad, zignorują również ten nagłówek, dlatego nie jest on formą ochrony treści.

Czy plik z regułą noindex nadal można otworzyć z linku?

Tak. Nagłówek niczego nie zmienia dla człowieka. Plik otwiera się i pobiera tak samo jak wcześniej, linki na stronie i w wiadomościach działają bez zmian. Różnica dotyczy wyłącznie tego, czy wyszukiwarka pokaże plik w wynikach.

Czy lepiej zablokować grafiki nagłówkiem, czy w pliku robots.txt?

Dokumentacja Google uznaje oba sposoby za równoważne i zaleca wybór jednego. Plik robots.txt jest prostszy, gdy blokada dotyczy całego katalogu. Nagłówek daje pewność, że obraz jest zablokowany niezależnie od tego, na której stronie się wyświetla, i jako jedyny z tych dwóch sposobów sprawdza się również przy plikach PDF.

Czy da się ustawić nagłówek bez dostępu do serwera?

Na hostingu z serwerem Apache lub LiteSpeed wystarcza dostęp do menedżera plików albo FTP, ponieważ plik .htaccess leży w katalogu strony. Na serwerze NGINX zmianę musi wprowadzić administrator lub pomoc techniczna dostawcy. Jeżeli żadna z tych dróg nie jest dostępna, pozostaje usunięcie pliku albo przeniesienie go w miejsce chronione hasłem.

Czy blokada plików PDF może zaszkodzić pozycjom strony?

Zablokowany plik przestaje sprowadzać ruch z wyszukiwarki, więc szkoda powstaje tylko wtedy, gdy ukryty zostanie dokument, który ten ruch przynosił. Przed blokadą warto sprawdzić w raporcie skuteczności w Search Console, czy dany plik ma wyświetlenia i kliknięcia. Jeśli ma, lepiej przenieść jego treść na podstronę, zanim plik zostanie wyłączony z indeksu.

Co oznacza status „URL zawiera tag „noindex”” przy pliku PDF?

Oznacza, że robot pobrał plik, odczytał regułę noindex i nie umieścił adresu w indeksie. Przy plikach zablokowanych celowo jest to stan oczekiwany. Niepokoić powinien dopiero wtedy, gdy na liście znajdują się adresy, które miały pozostać widoczne w wynikach.

Czy po ustawieniu nagłówka trzeba coś zgłaszać w Search Console?

Nie ma takiego obowiązku. Robot sam odczyta nagłówek przy kolejnej wizycie. Zgłoszenie w narzędziu „Usunięcia” jest potrzebne tylko wtedy, gdy plik ma zniknąć z wyników szybko, bez czekania na ponowne skanowanie.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Ustawienie nagłówka to kilka wierszy, ale wokół nich jest sporo drobnych decyzji: które pliki ukryć, które zostawić, gdzie wkleić regułę, jak nie wyłączyć przy okazji całej strony. Chętnie przejmę to w całości. Sprawdzę, jakie dokumenty i grafiki są widoczne w Google, uzgodnię listę plików do ukrycia, wprowadzę blokadę na serwerze i w sieci CDN, potwierdzę, że nagłówek jest wysyłany, zgłoszę pilne adresy do tymczasowego usunięcia i dopilnuję, żeby pliki rzeczywiście zniknęły z wyników.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co da się zrobić i ile to potrwa.