После 2 дней поиска / попыток / неудач я решил опубликовать это здесь, я не нашел ни одного примера того, что кто-то делает то же самое, и то, что я пробовал, похоже, работает нормально. Я пытаюсь отправить 403 ботам, не соблюдающим файл robots.txt (даже после его загрузки несколько раз). В частности, Googlebot. Он будет поддерживать следующее определение robots.txt.
User-agent: *
Disallow: /*/*/page/
Намерение состоит в том, чтобы позволить Google просматривать все, что они могут найти на сайте, но возвращать 403 для следующего типа запроса. Робот Googlebot, кажется, постоянно вкладывает эти ссылки, добавляя блок подкачки за блоком:
my_domain.com:80 - 66.x.67.x - - [25/Apr/2012:11:13:54 +0200] "GET /2011/06/
page/3/?/page/2//page/3//page/2//page/3//page/2//page/2//page/4//page/4//pag
e/1/&wpmp_switcher=desktop HTTP/1.1" 403 135 "-" "Mozilla/5.0 (compatible; G
ooglebot/2.1; +http://www.google.com/bot.html)"
Кстати, это сайт на wordpress. Я не хочу, чтобы эти страницы отображались, хотя после прохождения информации robots.txt они останавливались на некоторое время, чтобы потом снова начать сканирование. Это просто никогда не прекращается .... Я хочу, чтобы это видели реальные люди. Как видите, Google получает 403, но когда я сам пробую это в браузере, я получаю 404 обратно. Хочу, чтобы браузеры прошли.
root@my_domain:# nginx -V
nginx version: nginx/1.2.0
Я пробовал разные подходы, используя карту и старый добрый nono if, и они оба действуют одинаково: (в разделе http)
map $http_user_agent $is_bot { default 0; ~crawl|Googlebot|Slurp|spider|bingbot|tracker|click|parser|spider 1; }
(в разделе сервера)
location ~ /(\d+)/(\d+)/page/ { if ($is_bot) { return 403; # Please respect the robots.txt file ! } }
Недавно мне пришлось отточить свои навыки работы с Apache для клиента, где я сделал примерно то же самое:
# Block real Engines , not respecting robots.txt but allowing correct calls to pass # Google RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ Googlebot/2\.[01];\ \+http://www\.google\.com/bot\.html\)$ [NC,OR] # Bing RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ bingbot/2\.[01];\ \+http://www\.bing\.com/bingbot\.htm\)$ [NC,OR] # msnbot RewriteCond %{HTTP_USER_AGENT} ^msnbot-media/1\.[01]\ \(\+http://search\.msn\.com/msnbot\.htm\)$ [NC,OR] # Slurp RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ Yahoo!\ Slurp;\ http://help\.yahoo\.com/help/us/ysearch/slurp\)$ [NC] # block all page searches, the rest may pass RewriteCond %{REQUEST_URI} ^(/[0-9]{4}/[0-9]{2}/page/) [OR] # or with the wpmp_switcher=mobile parameter set RewriteCond %{QUERY_STRING} wpmp_switcher=mobile # ISSUE 403 / SERVE ERRORDOCUMENT RewriteRule .* - [F,L] # End if match
Это немного больше, чем я просил сделать nginx, но это примерно тот же принцип, мне трудно понять это для nginx.
Итак, мой вопрос: почему nginx будет обслуживать мой браузер с кодом 404? Почему не проходит, регулярное выражение не соответствует моему UA:
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.30 Safari/536.5"
Есть масса примеров для блокировки только на основе UA, и это легко. Также похоже, что совпадение местоположения окончательное, например это не «проваливается» для обычного пользователя, я почти уверен, что это имеет некоторую корреляцию с 404, которое я получаю в браузере.
В качестве вишенки я также хочу, чтобы Google игнорировал параметр wpmp_switcher = mobile, wpmp_switcher = desktop - это нормально, но я просто не хочу, чтобы один и тот же контент сканировался несколько раз.
Хотя я закончил тем, что добавил wpmp_switcher = mobile через страницы инструментов Google для веб-мастеров (требуя от меня регистрации ....). это тоже прекратилось на время, но сегодня они вернулись к работе с мобильными секциями.
Короче говоря, мне нужно найти способ для nginx обеспечить соблюдение определений robots.txt. Кто-нибудь может выложить несколько минут своей жизни и подтолкнуть меня в правильном направлении, пожалуйста?
я действительно ценю ЛЮБОЙ ответ, который заставляет задуматься ;-)
Я думаю, что лучшее решение этой проблемы - это несколько вещей. Ни один из них не предусматривает блокировку ботов.
Прежде всего, не позволяйте WordPress генерировать недействительные URL-адреса.
Выясните, что вызвало создание этих URL-адресов, и устраните проблему.
Определите, можно ли правильно переписать URL-адреса. Если да, попросите WordPress отправить редирект 301.
Для некоторых из этих URL-адресов вы можете отправить 301 для перенаправления на канонический URL-адрес. Однако для других это будет не так просто, поскольку URL-адрес не имеет никакого смысла.
Хотя последние версии WordPress отправляют 301 редирект для некоторых страниц, такие плагины, как Перенаправление постоянной ссылки может помочь в освещении того, чего не делает WordPress. (Этот плагин может нуждаться в обновлении или некоторой настройке; сначала тщательно протестируйте.)
Для бессмысленных URL-адресов используйте 410.
HTTP-ответ 410 Gone сообщает запрашивающей стороне, что URL-адрес не существует и больше не возвращается, поэтому перестаньте его запрашивать. Поисковые системы могут использовать эти данные для удаления недействительных URL-адресов из своих индексов.
Пример конфигурации, которая должна это сделать (сначала проверьте это!):
location ~ #/page/\d+/page/# {
return 410;
}
Попробуйте использовать это на своей карте:
~(crawl|Googlebot|Slurp|spider|bingbot|tracker|click|parser|spider)$ 1;
Насколько я помню, вам нужно использовать $ для завершения регулярного выражения, если вы не используете местоположение - стоит попробовать.
Я считаю, что ваше первое определение не сработало, потому что вы поместили его в User-agent: * вместо User-agent: Googlebot. По крайней мере, это, похоже, изменило мое заявление о запрете; иди разбери.
Я добавил следующее в свой robots.txt в разделе User-agent: Googlebot
Disallow: / *?
Это предположительно блокирует сканирование любого URL-адреса, содержащего вопросительный знак, потому что все они содержат вопросительный знак, а законные URL-адреса не содержат, по крайней мере, в моем случае.
Недавно я столкнулся с очень похожей проблемой, и у меня также были «& wpmp_switcher = desktop» или «& wpmp_switcher = mobile», но также «mobile? Pw_post_layout» в этих бессмысленных вложенных обходах URL (подробнее см. http://defectcio.com/8013/googlebot-gone-crazy-maybe-not-its-fault Надеюсь, я не нарушу никаких правил с этой ссылкой здесь, потому что она связана). Это исправление было симптоматическим, поэтому я до сих пор не понимаю истинную причину. Кто-нибудь узнал что-нибудь еще об этой проблеме с тех пор?