Zacznij od oczekiwanego rezultatu
Przed zmianą konfiguracji odpowiedz na proste pytanie: co ma stać się z danym adresem? Możesz chcieć, aby wyszukiwarka poznała nowy poradnik, przestała pokazywać techniczną stronę albo ograniczyła pobieranie niepotrzebnych wariantów. Te potrzeby nie są równoważne. Stosowanie jednej reguły do wszystkich sytuacji prowadzi do sprzeczności, które później trudno zdiagnozować.
Robots.txt opisuje zasady pobierania zasobów przez roboty, noindex dotyczy wykluczenia z indeksowania, a sitemap wskazuje adresy, które chcesz pomóc odkryć. Żaden z tych mechanizmów nie jest systemem ochrony poufnych danych. Panel administracyjny i prywatne pliki muszą być zabezpieczone po stronie serwera. Ukrycie adresu przed robotem nie uniemożliwia otworzenia go osobie, która pozna lub odgadnie URL.
Robots.txt nie jest przyciskiem usuwania z wyników
Plik robots.txt znajduje się w katalogu głównym odpowiedniego hosta i zawiera reguły odnoszące się do ścieżek. Zanim dodasz szeroką blokadę, sprawdź jej zakres na kilku przykładach. Reguła obejmująca cały katalog może przypadkowo dotyczyć także ważnych artykułów lub zasobów potrzebnych do odtworzenia strony. Przechowuj poprzednią wersję pliku, żeby móc przywrócić konfigurację po pomyłce.
Google wyjaśnia, że adres zablokowany przed pobieraniem może nadal zostać rozpoznany i pojawić się w wynikach na podstawie informacji z innych miejsc. Dlatego robots.txt nie zastępuje noindex. Nie próbuj również ukrywać w nim listy prywatnych katalogów jako jedynego środka ochrony: sam plik jest publiczny. Najpierw stosuj uwierzytelnienie i kontrolę dostępu, a dopiero później dodatkowe ustawienia dla robotów.
Noindex musi zostać odczytane
Dla publicznej strony, która nie powinna trafiać do wyników, można zastosować noindex w metadanych lub odpowiednim nagłówku HTTP. Wybór sposobu zależy od rodzaju zasobu i architektury serwisu. Istotne jest to, co serwer rzeczywiście wysyła, a nie tylko nazwa opcji w CMS. Po zapisaniu ustawień sprawdź publiczny HTML i nagłówki odpowiedzi.
Robot potrzebuje dostępu do zasobu, aby zobaczyć regułę noindex. Połączenie jej z blokadą pobierania tej samej strony może więc utrudniać osiągnięcie celu. Przykładowo strona potwierdzająca zapis do formularza może być publiczna, lecz nieprzeznaczona do indeksowania. Nie należy przy tym umieszczać w jej adresie jawnych danych klienta. Prywatność i indeksowanie są odrębnymi zagadnieniami, które trzeba rozwiązać równolegle.
Sitemap pokazuje preferowany zestaw treści
Mapa witryny powinna zawierać adresy, które uznajesz za ważne, publiczne i przeznaczone do indeksowania. W typowym serwisie będą to podstrony oferty, poradniki i inne samodzielne materiały. Nie dodawaj automatycznie każdego parametru filtrowania, linku sesyjnego i strony błędu. W przeciwnym razie mapa przestaje być czytelnym zestawem preferowanych dokumentów.
Według Google sitemap pomaga odkrywać zasoby, ale nie gwarantuje ich pobrania ani indeksowania. Używaj jej obok poprawnego linkowania wewnętrznego, nie zamiast niego. Jeżeli poradnik istnieje wyłącznie w XML i nie ma do niego sensownej drogi z witryny, problem z architekturą pozostaje. Dla rozbudowanej bazy wiedzy osobna mapa artykułów ułatwia kontrolę, czy nowe materiały faktycznie zostały uwzględnione.
Rozwiąż typowe sprzeczności
Pierwsza sprzeczność to adres w sitemap z ustawionym noindex. Druga: mapa wskazuje stary URL, który przekierowuje do nowego. Trzecia: canonical preferuje inny wariant niż linki wewnętrzne. Każdy przypadek wymaga ustalenia jednego pożądanego stanu. Nie dokładaj kolejnych reguł bez uporządkowania istniejących, bo poprawienie jednego raportu może pogorszyć inną część konfiguracji.
Zbuduj małą tabelę kontrolną: adres, status HTTP, możliwość pobrania, reguła indeksowania, canonical i obecność w mapie. Dla strony przeznaczonej do indeksowania te elementy powinny tworzyć spójny obraz. Dla zasobu usuniętego właściwa będzie inna konfiguracja niż dla strony czasowo niedostępnej. Kody HTTP mają określone znaczenie dla robotów, więc nie zwracaj automatycznie 200 dla każdego komunikatu.
Sprawdź konfigurację na reprezentatywnej próbce
Wybierz po jednym adresie z każdej grupy: strona główna, oferta, poradnik, archiwum, formularz i strona techniczna. Dodaj przykłady z parametrami, gdy serwis je generuje. Sprawdź odpowiedź bez logowania, ponieważ sesja administratora może omijać niektóre ograniczenia. Przy większej witrynie rozszerz test na całe klasy adresów po potwierdzeniu zasad na próbce.
Podczas wdrożenia zapisz, gdzie ustawiono każdą regułę. Noindex może pochodzić z pliku szablonu, konfiguracji serwera lub pola CMS. Bez tej wiedzy następna aktualizacja może przypadkowo przywrócić błąd. Ustal także, kto odpowiada za mapy i kiedy są odświeżane. Poprawny plik istniejący na dysku nie wystarczy, gdy publiczny endpoint nadal serwuje starą kopię albo odpowiedź HTML zamiast XML.
Utrzymuj porządek po publikacji nowych wpisów
Przy dodawaniu artykułu sprawdź jego publiczny adres, odnośnik z listy i obecność w mapie. Po zmianie sluga uporządkuj linki wewnętrzne i reguły przekierowania. Po usunięciu treści zdecyduj, czy istnieje rzeczywisty zamiennik. Nie kieruj wszystkich nieaktualnych poradników na stronę główną tylko po to, aby uniknąć komunikatów o błędach.
W bazie wiedzy DR-BOOST kolejne strony archiwum powinny prowadzić do odrębnych zestawów artykułów. Starsze wpisy nie mogą zniknąć z nawigacji po publikacji nowych. To dobry przykład współpracy mechanizmów: paginacja daje zwykłe linki, sitemap opisuje adresy, a metadane porządkują ich interpretację. Każdy element pełni własną funkcję. Dopiero sprawdzenie całego układu pozwala ocenić, czy witryna jest gotowa do dalszego rozwoju treści i odnośników.
