301 перенаправить на страницу 404 или установить код состояния на 404 и остаться на странице?

У меня есть несколько страниц на моем веб-сайте, доступ к которым могут получить только администраторы, и доступ к ним предоставляется, если значение строки запроса найдено и правильно установлено. Например:

http://www.mydomain.com/show-daily-statistics?key=abc

Приведенная выше ссылка покажет содержимое страницы, но ничего другого, такого как ниже, не будет:

http://www.mydomain.com/show-daily-statistics

Теперь я думал о том, что делать, если поисковые машины и / или пользователи без прав администратора каким-либо образом попадают на эти скрытые страницы.

Конечно, я могу либо изменить код состояния страницы на 404, либо 301 перенаправить на:

http://www.mydomain.com/404-error

Какое лучшее решение в отношении Google и SEO?

Правильный код будет 401 не авторизован

Согласно спецификации HTTP

10.4.2 401 Несанкционированный

Запрос требует аутентификации пользователя. Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрашиваемому ресурсу. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка Авторизация (раздел 14.8). Если в запрос уже включены учетные данные авторизации, то ответ 401 указывает, что в авторизации было отказано для этих учетных данных. Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации по крайней мере один раз, тогда пользователю СЛЕДУЕТ представить объект, который был указан в ответе, поскольку этот объект может включать в себя соответствующую диагностическую информацию. Аутентификация доступа HTTP объясняется в разделе «Аутентификация HTTP: базовая и дайджест-аутентификация доступа» [43].

или альтернативно

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (не найден).

Оба они семантически правильнее, чем 404. Ресурс существует, так что это 404не правильно. 401должно быть правильно, но вы не требуете аутентификации. Безопасность по неизвестности - это не безопасность. 403также правильно, поскольку запрос понимается, ресурс существует, он просто отказывается обслуживать запрос. 404уместно, если вы не хотите раскрывать, почему 403это происходит.

В любом случае 301перенаправления не подходят, ресурс не перемещен.

Поскольку это страница для администраторов, с параметром «ключ» или без него, страницы не могут и не должны индексироваться. Поэтому веб-страница для не-администратора может отправить 404 код состояния, и вы можете оставить тот же URL в целости и сохранности. Не перенаправляйте, поскольку вы сообщаете Google, что страница переместилась, но затем на страницу, которая не существует.

Так Google это делает. Посмотрите, что происходит, когда вы переходите на фиктивную страницу: http://www.google.com/analytics/asdsas.

Семантически правильный код ответа HTTP для этой ситуации будет 403 Запрещено :

Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (не найден).

(Хотя определение ответа 403 говорит, что «авторизация не поможет», IMO это следует понимать как относящуюся к HTTP Basic / Digest-аутентификации , для которой вместо этого следует использовать код состояния 401 Unauthorized . Поскольку вы не используете любой из этих методов аутентификации, 403 - это соответствующий код состояния в вашем случае.)

Однако, используя код 403 состояния показывает (или по крайней мере сильно подразумевает) тот факт , что это страница с этим URL, даже если сервер отказывается доставить его. Поскольку это то, что вы, возможно, захотите скрыть от потенциальных злоумышленников, стандарт HTTP / 1.1 явно разрешает вместо этого возвращать код состояния 404 Not Found ( выделено мое):

Сервер не нашел ничего, соответствующего Request-URI. Не указано, является ли состояние временным или постоянным. Код состояния 410 (Унесенные) СЛЕДУЕТ использовать, если сервер через некоторый внутренне конфигурируемый механизм знает, что старый ресурс постоянно недоступен и не имеет адреса пересылки. Этот код состояния обычно используется, когда сервер не хочет точно указывать, почему запрос был отклонен или когда другой ответ не применим.

Конечно, чтобы сделать такое маскирование эффективным, страница с ошибкой 404, которую вы возвращаете, должна выглядеть идентично тому, что вы возвращаете для реальных несуществующих страниц. В противном случае, это обманет только самых глупых и случайных атакующих. (Если ваша цель - просто исключить страницы из индекса Google, ответ 403 сделает то же самое.)

Как насчет других возможных ответов, предложенных в вашем вопросе и других ответах?

Как я отмечал ранее, я не считаю, что ответ 401 уместен здесь. Он может работать на практике, поскольку в большинстве браузеров и поисковые системы будут относиться к любым искаженным или непризнанным 4 хм кодам ответа серии , как если бы он был 404, но она по - прежнему не действует в соответствии с HTTP спецификация, и нет никаких практических причин предпочесть его более 403 или 404.

Что касается использования перенаправления 301 (или 302) на отдельную страницу «Ошибка 404», то это ужасная практика, распространяемая неаккуратными учебниками mod_rewrite, и не имеет абсолютно никаких функций выкупа по сравнению с возвратом ответа 404 напрямую:

• Это сбивает с толку посетителей, так как URL, который они пытались посетить, заменяется URL страницы с ошибкой. Таким образом, они видят сообщение о том, что они достигли несуществующей страницы, но не имеют четко видимого указания на то, какой страницей они пытались посетить, и поэтому не могут легко попытаться применить любые стратегии восстановления, такие как исправление любых очевидных опечаток в URL, или скопируйте и вставьте его в Google или Wayback Machine.

• Это может сбить с толку поисковые системы, особенно если ваша страница 404 запрещена в файле robots.txt или если она неправильно возвращает ответ 200 OK вместо реального кода состояния 404 ( «soft 404» ), что может привести к тому, что ваша страница 404 появится в поиске результаты для случайных поисковых терминов.

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

• Это не имеет никакой пользы для SEO, так как любой «сок ссылок» со страниц, перенаправленных на страницу 404, все равно теряется.

(Конечно, одна ситуации , когда вы делаете хочет использовать 301 редирект вместо 404 ответа , когда страница фактически была перемещена, и вы можете перенаправить посетитель на правильное место. Но это не тот случай обсуждается здесь.)

Наконец, я хотел бы повторить мнение, выраженное во многих комментариях, о том, что простое «скрытие» ваших страниц администратора, как это, не является адекватной заменой для правильной аутентификации на основе пароля . Тем не менее, если у вас уже настроена защищенная система аутентификации, скрытие страниц может быть полезным в качестве дополнительного слоя, хотя и довольно слабого, в подходе глубокоэшелонированной защиты .

Я бы использовал noindex,nofollow,noarchiveтег в заголовке страниц, которые вы хотите убрать из поиска.

Я обнаружил, что noarchiveтег имеет тенденцию чертовски быстро выводить данные из поиска, тогда как он noindexможет помешать его поиску, но если он уже есть, вам нужно удалить его из результатов поиска.

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