Назад | Перейти на главную страницу

Блокировка `` хороших '' ботов в nginx с несколькими условиями для определенных запрещенных URL-адресов, по которым люди могут заходить

После 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. Кто-нибудь может выложить несколько минут своей жизни и подтолкнуть меня в правильном направлении, пожалуйста?

я действительно ценю ЛЮБОЙ ответ, который заставляет задуматься ;-)

Я думаю, что лучшее решение этой проблемы - это несколько вещей. Ни один из них не предусматривает блокировку ботов.

  1. Прежде всего, не позволяйте WordPress генерировать недействительные URL-адреса.

    Выясните, что вызвало создание этих URL-адресов, и устраните проблему.

  2. Определите, можно ли правильно переписать URL-адреса. Если да, попросите WordPress отправить редирект 301.

    Для некоторых из этих URL-адресов вы можете отправить 301 для перенаправления на канонический URL-адрес. Однако для других это будет не так просто, поскольку URL-адрес не имеет никакого смысла.

    Хотя последние версии WordPress отправляют 301 редирект для некоторых страниц, такие плагины, как Перенаправление постоянной ссылки может помочь в освещении того, чего не делает WordPress. (Этот плагин может нуждаться в обновлении или некоторой настройке; сначала тщательно протестируйте.)

  3. Для бессмысленных 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 Надеюсь, я не нарушу никаких правил с этой ссылкой здесь, потому что она связана). Это исправление было симптоматическим, поэтому я до сих пор не понимаю истинную причину. Кто-нибудь узнал что-нибудь еще об этой проблеме с тех пор?