Wrażliwe ścieżki w robots.txt

Jak działa ta kontrola

Scanaris pobiera Twój /robots.txt i najpierw sprawdza, czy to prawdziwy robots: odpowiada 200, nie jest HTML-em i zawiera co najmniej jedną dyrektywę (User-agent, Disallow, Allow lub Sitemap). Potem przechodzi przez każdy wiersz Disallow: i patrzy, czy ścieżka zawiera któryś z tych wskaźników: wp-admin, phpmyadmin, /admin, backup, .git, .env, /private, /secret, dump, .sql, password lub credential. Jeśli któryś pasuje, otwiera ustalenie o niskiej wadze ze znalezionymi ścieżkami. Lista jest celowo krótka: słowa jak test, old, tmp czy logs pojawiają się w całkowicie legalnych plikach robots i dawały fałszywe alarmy.

Dlaczego to ważne

robots.txt jest publiczny z definicji: każdy może go przeczytać i faktycznie jest jednym z pierwszych plików, do których zagląda narzędzie rekonesansu. Gdy piszesz Disallow: /backups/ albo Disallow: /stary-admin/, nie ukrywasz tych ścieżek; wskazujesz je temu, kto ich szuka, z dodatkową gwarancją, że są dla Ciebie ważne. Google ich nie przeskanuje, ale atakujący nie czyta robots, żeby go słuchać, tylko żeby wiedzieć, dokąd iść. To ustalenie o niskiej wadze, bo wymienienie ścieżki nie czyni jej dostępną; problem pojawia się, gdy wymieniona ścieżka jest na dodatek niezabezpieczona.

Jak to naprawić

• Usuń z robots.txt ścieżki, których nie chcesz ogłaszać. Jeśli nie chcesz, żeby Google indeksował prywatną strefę, właściwe jest, żeby ta strefa wymagała logowania; to, co jest za uwierzytelnianiem, i tak nie jest indeksowane.
• Jeśli dostępna strona ma nie pojawiać się w wyszukiwarkach bez ogłaszania jej, użyj nagłówka X-Robots-Tag: noindex lub meta robots na tej stronie. Wyszukiwarki to respektują i nic nie jest zapisane w publicznym pliku.
• Zabezpiecz ścieżkę naprawdę. Panel pod /admin potrzebuje uwierzytelniania, nie wiersza w robots. Katalog /backups/ w ogóle nie powinien być w publicznym katalogu; kontrole wrażliwe pliki i listowanie katalogów pokrywają te przypadki.
• WordPress: wirtualny robots, który generuje, zawiera domyślnie Disallow: /wp-admin/. To nic poważnego, bo wp-admin i tak wymaga logowania i wysyła noindex; możesz to zostawić albo zastąpić robots własnym bez tego wiersza. Ważne, żeby logowanie miało silne hasła, limit prób i, jeśli możesz, drugi składnik.

Zdrowy robots.txt jest zwykle krótki: User-agent: *, może kilka Disallow dla wyszukiwarki wewnętrznej lub parametrów, i wiersz Sitemap:. Jeśli Twój ma dwadzieścia wierszy „prywatnych" ścieżek, robi robotę systemu uprawnień, i to źle.

Sprawdź, czy naprawione

curl -s https://twojadomena.pl/robots.txt | grep -iE "^disallow:.*(admin|phpmyadmin|backup|\.git|\.env|private|secret|dump|\.sql|password|credential)"

Nic nie powinno się pojawić. A dla każdej usuniętej ścieżki sprawdź, czy naprawdę wymaga uwierzytelniania albo zwraca 404:

curl -s -o /dev/null -w "%{http_code}\n" https://twojadomena.pl/admin/

Często zadawane pytania

Jeśli usunę /admin z robots.txt, czy Google go zindeksuje?

Jeśli /admin wymaga logowania, Google widzi tylko ekran logowania, a ten zwykle ma noindex. Jeśli nie wymaga logowania, problemem nie jest indeksowanie, tylko to, że Twój panel jest otwarty.

Czy mogę zablokować wszystko i wymienić tylko to, co publiczne?

Dla strony, która chce ruchu organicznego, nie: zablokowanie wszystkiego przez Disallow: / wyrzuca ją z wyszukiwarek. Jeśli chcesz kontrolować skanowanie, kontrola robots i sitemap pilnuje, żebyś nie blokował sam siebie.

A boty AI?

Blokowanie lub dopuszczanie GPTBot, ClaudeBot i spółki to osobna decyzja biznesowa i trafia do tego samego pliku. Nie ma związku z tą kontrolą, która patrzy tylko na wrażliwe ścieżki.