Текущая ситуация такова, что мы получаем тысячи и тысячи ошибок 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 на повторное сканирование нового веб-сайта, но это был результат.
Я веб-мастер-любитель в некоммерческой организации, и мне действительно пришлось взяться за дело, любая помощь будет принята с благодарностью!
При выполнении тех перенаправлений, которые вы делаете, применим только один код ответа 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 файлы на старых доменах, запрещающие сканирование страниц, удаленных во время или после консолидации.