Вопросы Теги

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

На Вашем сервере:

1) Удостоверьтесь, что подверсия установлена - yum/apt-get/etc, должен сделать это довольно легким.

2) Создайте каталог для содержания репозитория: mkdir /some/repository/path

3) Использовать svnadmin создать расположение репозитория: svnadmin create /some/repository/path

4) Импортируйте свои источники:

$ cd /path/to/your/code
$ svn import -m "initial import" . file:///some/repository/path/trunk

Примечание: это импортирует код в repo, но НЕ создает рабочую копию! Так, затем:

5) Переместите свои исходные файлы из пути и проверьте рабочую копию:

$ cd ..
$ mv /path/to/your/code /path/to/your/code-presvn
$ svn co file:///some/repository/path/trunk code

5.5) Вы, вероятно, хотите удостовериться, что люди не могут просмотреть Ваши .svn каталоги через веб-сервер. Для апача что-то как следующее в httpd.conf должно сделать это:

<Directory ~ "\.svn">
    Order allow,deny
    Deny from all
</Directory>

6) Протестируйте свой сайт, удостоверьтесь, что полномочия корректны и т.д. Проверка новой копии, возможно, создала проблемы. Это - вероятно, хорошая идея зарегистрировать (или еще лучше, сценарий) любые изменения, которые должны будут быть сделаны для надлежащего конфигурирования, недавно проверил копию.

7) Для получения локальной копии для разработки используйте URL репозитория как svn+ssh://username@yourhostname.com/some/repository/path/trunk Я не знаком с tortoisesvn, но если бы Вы использовали стандартные инструменты командной строки, то Вы проверили бы свой проект как:

$ svn co svn+ssh://username@yourhostname.com/some/repository/path/trunk

Затем можно внести изменения в локальную рабочую копию и фиксировать вещь (svn commit -m "description of changes"). Когда Вы хотите переместить те изменения в своей производственной системе, ssh в поле, cd /path/to/your/site, svn -u status (для предварительного просмотра изменений), svn update осовременивать все.

Надо надеяться, это полезно.

Я также не могу предложить достаточно, что Ваше чтение больше документации подверсии для понимания, что продолжается под капотом. Кроме того, удостоверьтесь, что Вы знаете то, что Вы делаете прежде, чем попробовать этот материал на чем-либо важном. Можно создать тестовые репозитории, с поддельными данными, и сделать некоторые эксперименты, пока Вы не уверены, что знаете то, что Вы делаете.

1
задан 25 April 2012 в 16:09
3 ответа

Попробуйте использовать это на своей карте: 

~(crawl|Googlebot|Slurp|spider|bingbot|tracker|click|parser|spider)$ 1;

Насколько я помню, вам нужно использовать $ для завершения регулярного выражения, если вы не используете местоположение - стоит попробовать.

0
ответ дан 4 December 2019 в 01:08

Я считаю, что ваше первое определение не сработало, потому что вы указали это в User-agent: * вместо User-agent: Googlebot. По крайней мере, это, похоже, изменило мое заявление о запрете; go figure.

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

0
ответ дан 4 December 2019 в 01:08

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

  1. Предотвратить создание WordPress недействительных URL-адресов в первую очередь.

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

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

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

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

  3. Для бессмысленных URL, обслужить 410 .

    HTTP-ответ 410 Gone сообщает запрашивающей стороне, что URL-адрес не существует и никогда не возвращается, поэтому прекратите запрашивать его. Поисковые системы могут использовать эти данные для удаления недействительных URL-адресов из своих индексов.

    Пример конфигурации, которая должна делать это (сначала проверьте это!): 

     location ~ # / page / \ d + / page / # {
 return 410;
}
1
ответ дан 4 December 2019 в 01:08

Теги

Похожие вопросы