Robot odwiedza stronę bez konta użytkownika
Robot wyszukiwarki zwykle pobiera adres tak, jak niezalogowany odwiedzający: nie ma konta klienta ani jego aktywnej sesji. Jeśli wejście na podstronę wymaga uwierzytelnienia, robot nie zobaczy treści dostępnej dopiero po zalogowaniu. Może natomiast zobaczyć stronę logowania, komunikat o braku dostępu albo publiczny fragment strony, zależnie od sposobu działania serwisu.
Wyobraź sobie sklep z historią zamówień pod adresem /moje-konto/zamowienia. Niezalogowana osoba może zostać przekierowana do formularza logowania. Robot napotka tę samą przeszkodę, ale nadal może poznać sam adres, na przykład z publicznego linku. Znajomość adresu nie oznacza dostępu do historii zakupów ani tego, że jej zawartość trafi do wyników wyszukiwania.
Warto rozdzielić dwa pytania: czy robot może pobrać zawartość adresu oraz czy wyszukiwarka może uwzględnić ten adres w indeksie. Odpowiedzi zależą między innymi od odpowiedzi serwera, widocznych linków i treści dostępnej bez logowania.
Co zwraca serwer przy próbie wejścia?
Serwis może przekierować niezalogowanego użytkownika na publiczną stronę logowania. Wtedy robot zamiast prywatnej treści otrzymuje przekierowanie i ewentualnie widzi formularz. Inną możliwością jest odpowiedź HTTP 401, wskazująca, że wymagane jest uwierzytelnienie, albo 403, gdy dostęp jest zabroniony. Te odpowiedzi komunikują ograniczenie dostępu wyraźniej niż wyświetlenie komunikatu „zaloguj się” pod adresem, który jednocześnie zwraca kod 200.
Kod 200 mówi, że serwer zwrócił stronę, choć nie przesądza, co się na niej znajduje. Jeśli każdy prywatny adres zwraca z tym kodem niemal identyczny formularz, robot może widzieć wiele adresów o podobnej treści. Nie należy zakładać, że sam formularz ukryje tytuł, opis czy fragment danych umieszczonych w publicznie dostępnej części odpowiedzi.
Sprawdź również, czy treści nie da się pobrać inną drogą. Strona może wymagać logowania, podczas gdy plik PDF, obraz lub odpowiedź interfejsu API są dostępne pod osobnym, publicznym adresem. Ochrona samego widoku w przeglądarce nie wystarcza, jeśli zasoby zawierające prywatne informacje pozostają otwarte.
Blokada indeksowania nie zastępuje kontroli dostępu
Plik robots.txt służy do przekazywania robotom zasad pobierania adresów, a nie do ochrony danych. Wpisanie tam ścieżki panelu nie uniemożliwia człowiekowi ani innemu programowi otwarcia publicznie dostępnej strony. Co więcej, wyszukiwarka może znać zablokowany adres dzięki linkom, nawet jeśli nie pobierze jego treści. Nie umieszczaj w robots.txt listy wrażliwych adresów z myślą, że pozostaną tajne.
Dyrektywa noindex dotyczy indeksowania, lecz robot musi móc odczytać stronę lub odpowiedni nagłówek, aby ją zobaczyć. Jeśli pobieranie adresu jest zablokowane w robots.txt, robot może nie dotrzeć do noindex umieszczonego w jego treści. Z kolei noindex nie ogranicza dostępu do danych: każdy, kto może otworzyć publiczną stronę, nadal może ją przeczytać.
Mapa witryny i znacznik canonical także nie tworzą bariery dostępu. Pierwsza pomaga wskazywać adresy, a drugi sugeruje preferowany adres dla podobnych treści. Dla panelu klienta podstawą jest prawidłowo egzekwowane logowanie i sprawdzanie uprawnień przy każdym żądaniu chronionego zasobu.
Co warto udostępnić publicznie?
Nie każda witryna z logowaniem musi chować wszystko. Serwis kursowy może mieć publiczny opis programu, listę tematów i stronę zapisu, a same lekcje udostępniać wyłącznie uczestnikom. Podobnie sklep może pokazywać informacje o dostawie i zwrotach bez ujawniania historii zamówień. Taki podział pomaga użytkownikom zrozumieć ofertę bez osłabiania ochrony treści prywatnych.
Jeśli stosujesz zapowiedź materiału, sprawdź dokładnie, co trafia do odpowiedzi dla niezalogowanego gościa. Ukrycie akapitu za oknem logowania po stronie przeglądarki nie oznacza, że tekst nie został wcześniej pobrany w kodzie strony lub w danych skryptu. Publiczna zapowiedź powinna zawierać tylko informacje, które rzeczywiście chcesz udostępnić każdemu.
Krótka lista kontroli dla właściciela witryny
Zacznij od kilku przykładowych adresów: strony logowania, panelu użytkownika, pojedynczej prywatnej podstrony i powiązanego z nią pliku. Otwórz je w oknie prywatnym bez logowania. Zanotuj, czy widzisz przekierowanie, komunikat o odmowie, publiczny podgląd czy pełną treść. Następnie sprawdź kod odpowiedzi HTTP oraz to, czy po wylogowaniu nadal da się pobrać plik albo dane przez bezpośredni adres.
Przejrzyj publiczne menu, linki, mapę witryny i robots.txt. Upewnij się, że mapa zawiera adresy przeznaczone do publicznego odkrywania, a robots.txt nie jest jedyną „ochroną” panelu. Jeśli masz dostęp do narzędzia diagnostycznego wyszukiwarki, możesz dodatkowo sprawdzić, jak przedstawia ono wybrany adres. Traktuj taki test jako uzupełnienie kontroli serwera, nie jako test bezpieczeństwa.
Na koniec sprawdź różnicę między kontem zalogowanym a niezalogowanym. Użytkownik powinien otrzymać swoje dane dopiero po poprawnym uwierzytelnieniu, a dostęp do cudzych zasobów powinien być odrzucony. Jeśli prywatna treść była wcześniej dostępna publicznie, najpierw zamknij dostęp u źródła; samo wykluczenie adresu z indeksu nie rozwiązuje problemu ujawnienia danych.
