Тысячи ошибок robots.txt 404 от ботов, пытающихся сканировать старый мультисайт
В настоящее время мы получаем тысячи и 404 ошибки от ботов, которые ищут файл robots.txt в разных местах на нашем сайте из-за переадресации домена.
Наш старый веб-сайт представлял собой лабиринтный мультисайт, работающий на dotnetnuke с несколькими доменными именами. Мы перешли на один сайт на Wordpress с одним доменным именем. Остальные доменные имена теперь просто перенаправляют на категории на сайте. Это означает, что googlebot, bingbot и многие другие неоднократно пытаются проиндексировать домены, которые раньше были полноценными сайтами, и перенаправляются.
www.EXAMPLE.co.uk перенаправляет на www.EXAMPLE.co.uk/challenge/
и поэтому /challenge/robots.txt имеет более тысячи 404
то же самое с другими перенаправлениями, которые заканчиваются в /walktoschool/robots.txt и т. д. и т. д.
Есть ли умный способ перенаправить ботов? Или другим способом, которым это должно было быть обработано или заставить ботов остановиться? Наш новый веб-сайт даже не использует robots.txt, он использует htaccess в сочетании с Better WP Security. Я отправил запросы в Google и Bing на повторное сканирование нового веб-сайта, но это было результатом.
Я - веб-мастер-любитель в некоммерческой организации, и мне действительно пришлось взяться за дело, любая помощь будет с благодарностью получена!
2 ответа
При выполнении вида перенаправления, который вы делаете, есть только один код ответа HTTP, который применим, а именно 301 Moved Permanently, RFC 2616, стандарт, который определяет протокол HTTP, определяет код ответа 301 таким образом (мой акцент):
Запрошенному ресурсу был назначен новый постоянный URI, и любые будущие ссылки на этот ресурс ДОЛЖНЫ использовать один из возвращенных URI. Клиенты с возможностями редактирования ссылок должны автоматически связывать ссылки на Request-URI с одной или несколькими новыми ссылками, возвращаемыми сервером, где это возможно. Этот ответ кешируется, если не указано иное.
Новый постоянный URI ДОЛЖЕН быть задан в поле Location в ответе. Если метод запроса не является HEAD, объект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылкой на новый URI.
Если код состояния 301 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых был выполнен запрос.
Сравните это с HTTP 302 Found redirect, который очень часто используется при простой настройке "перенаправления" и который определяется как (опять же, мой акцент):
Запрашиваемый ресурс временно находится под другим URI. Поскольку перенаправление может иногда изменяться, клиент ДОЛЖЕН продолжать использовать Request-URI для будущих запросов. Этот ответ может быть кэширован, только если он указан в поле заголовка Cache-Control или Expires.
Временный URI ДОЛЖЕН быть задан полем Location в ответе. Если метод запроса не является HEAD, объект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылкой на новый URI.
Если код состояния 302 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых был выполнен запрос.
Следовательно, правильный путь для перенаправления HTTP в вашем сценарии - настроить веб-сервер так, чтобы он возвращал ответ 301, указывающий новое местоположение, а не 302 ответ. Способные клиенты будут хранить новый URL и использовать его для любых будущих запросов.
Я думаю, вам лучше не перенаправлять запросы на /robots.txt в то же время перенаправляя все остальное. Если старый сайт имел /robots.txt файл, вы, вероятно, должны просто сохранить его. В противном случае подойдет пустой файл. Но вы также можете решить, что пришло время для небольшой очистки и положить /robots.txt файлы на старых доменах, которые запрещают сканирование страниц, которые были удалены во время или после консолидации.