Тысячи robots.txt 404 ошибки от ботов, пытающихся проверять старый многоузловой
Вы пытались вернуться к режиму оценки, включить удаленную техническую поддержку SSH и затем обратно к Вашей бесплатной лицензии?
Используя оценку режим является большим, это позволяет Вам использовать некоторые функции предприятия в течение максимум 60 (абсолютно отдельных) дней!:)
При выполнении тех перенаправлений, которые вы делаете, есть только один применимый код ответа HTTP, а именно 301 перемещен навсегда . RFC 2616 , стандарт, который определяет протокол HTTP, определяет код ответа 301 таким образом (мой акцент):
Запрошенному ресурсу был назначен новый постоянный URI и любой в будущих ссылках на этот ресурс СЛЕДУЕТ использовать один из возвращенных URI. Клиенты с возможностями редактирования ссылок должны автоматически повторно связывать ссылки на Request-URI с одной или несколькими новыми ссылками , возвращаемыми сервером, где это возможно. Этот ответ кэшируется , если не указано иное.
Новый постоянный URI ДОЛЖЕН быть указан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый (е) URI.
Если код состояния 301 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых запрос был отправлен.
Сравните это с перенаправлением HTTP 302 Найдено , который очень часто используется при простой настройке «перенаправления» и определяется как (опять же, мой акцент):
Запрошенный ресурс находится временно под другим URI. Поскольку перенаправление может иногда изменяться, клиент ДОЛЖЕН продолжать использовать Request-URI для будущих запросов. Этот ответ кэшируется, только если указано полем заголовка Cache-Control или Expires.
Временный URI ДОЛЖЕН быть задан полем Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый (е) URI.
Если код состояния 302 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых запрос был отправлен.
Следовательно, правильный способ перенаправления HTTP в вашем сценарии - настроить веб-сервер для возврата ответа 301 , указывающего новое местоположение, а не ответа 302 . Затем подходящие клиенты сохранят новый URL-адрес и будут использовать его для любых будущих запросов.
Я думаю, вам лучше не перенаправлять запросы на /robots.txt , но перенаправлять все остальное. Если на старом сайте был файл /robots.txt , вам, вероятно, следует просто сохранить его. В противном случае подойдет пустой файл. Но вы также можете решить, что пора немного очистить и поместить файлы /robots.txt в старые домены, которые запрещают сканирование страниц, которые были удалены во время или после консолидации.