Отсутствующий публичный документ должен показывать понятное объяснение и возвращать соответствующий HTTP-статус, обычно 404. На Mac можно проверить оба параметра в Chrome, выявить несоответствие и дать системе публикации точное исправление.

Этот рабочий процесс предназначен для человека, поддерживающего публичные страницы документов: руководства, справочные заметки или простые инструкции. Его задача — сделать так, чтобы запрошенный адрес, ответ сервера и отображаемое сообщение совпадали. Все примеры путей ниже синтетические.

Какой ответ должен возвращать отсутствующий документ?

Сначала решите, что должно происходить по адресу документа. Страница, которая переместилась, требует другой обработки, чем страница, которой больше не существует. Используйте эту таблицу решений перед изменением дизайна страницы отсутствующего документа.

Состояние документа Преднамеренный ответ Что должны видеть читатели
Существует по запрошенному адресу 200 OK Полный документ
Есть явная постоянная замена 301 перенаправление Документ-замена по его новому адресу
Не может быть найден, эквивалентной замены нет 404 Not Found Полезное объяснение об отсутствующем документе
Удален намеренно, и его отсутствие, вероятно, постоянно 410 Gone уместен Понятное объяснение об удалении и полезная навигация

HTTP определяет 404, не указывая, является ли отсутствие временным или постоянным. Он определяет 410 для ресурса, недоступность которого, вероятно, постоянна; когда постоянство неизвестно, используйте 404. Эти значения взяты из RFC 9110, разделы 15.5.5 и 15.5.11.

Google рекомендует постоянное перенаправление, когда документ перемещен или имеет явную замену. Если он удален без похожей замены, Google рекомендует 404 или 410. См. руководство Google по устранению ответов с отсутствующим контентом.

Например, предположим, что /documents/paper-folding-notes стал /documents/paper-folding-guide со существенно эквивалентными инструкциями. Постоянное перенаправление подходит для такого изменения. Если заметки удалены без замены, сохраните ответ об отсутствующем документе по старому адресу. Общий каталог документов можно предложить как ссылку на этой странице.

Почему убедительный дизайн страницы отсутствия недостаточен

Страница может визуально говорить Документ не найден, в то время как её сервер возвращает 200. Google называет такое несоответствие «soft 404»; пустая страница или страница без основного контента также может вызвать такую классификацию. Прочитайте объяснение Google ошибок soft 404.

Статус является частью HTTP-ответа, отдельно от поясняющего контента. Следовательно, изменение заголовка или добавление большой метки 404 не может установить код ответа. Проверьте фактический запрос документа перед тем, как решить, что проблема исправлена. RFC 9110 описывает роль кодов состояния ответа.

Как проверить ответ документа на Mac?

Используйте встроенные инструменты Chrome для этой проверки. Подготовьте один известный рабочий адрес документа и один намеренно несуществующий путь на том же публичном сайте. Например, отсутствующий путь может быть /documents/missing-paper-example-731. Выберите адрес, который вы знаете, не имеет опубликованного документа.

  1. Откройте публичную страницу в Chrome.
  2. Нажмите Command + Option + I, чтобы открыть DevTools.
  3. Выберите панель Network (Сеть).
  4. С открытыми DevTools введите тестовый адрес в адресной строке и загрузите его.

Chrome документирует ярлык для Mac в статье Открыть Chrome DevTools. Сетевая активность записывается, пока DevTools открыты, как объясняется в обзоре панели Network.

  1. Выберите Disable cache (Отключить кэш), чтобы не полагаться на кэшированный ответ браузера во время этой проверки.
  2. Включите Preserve log (Сохранять журнал), если нужно отслеживать навигацию через перенаправления.
  3. Перезагрузите тестовый адрес.
  4. Выберите его основной запрос документа, затем откройте Headers (Заголовки). В разделе General (Общее) прочтите адрес запроса и код статуса.

Эти элементы управления и расположение информации о статусе задокументированы в справочнике по функциям Network Chrome.

Внимательно проверьте запрос документа. Журнал также содержит запросы скриптов, стилей и других ресурсов. Отсутствующий вспомогательный файл не означает, что сам документ вернул 404. Таблица запросов Chrome различает HTTP-код в Status и категорию ресурса в Type; см. Проверка сетевой активности.

Теперь сравните три наблюдения: изначально запрошенный адрес, код ответа для этого документа и страницу, видимую после загрузки. Запишите их вместе. Если навигация меняет адрес, проверьте исходный запрос и пункт назначения, а не только финальную страницу.

Как превратить наблюдения в исправление?

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

Наблюдаемый результат Что исследовать Преднамеренное исправление
200 с сообщением об отсутствующем документе Обработчик отсутствующего маршрута или запасной вариант Вернуть 404 с объяснением
404 с видимым ожидаемым документом Ответ, присвоенный существующему маршруту Обслуживать этот документ успешно с 200
Перенаправление в общий каталог Существует ли эквивалентная замена Перенаправить на эквивалентный документ или показать страницу отсутствия
200 с пустым или неполным документом Загрузка и рендеринг контента Восстановить предполагаемый контент, если документ всё ещё существует
404 с полезным сообщением на странице отсутствия Является ли адрес действительно отсутствующим Сохранить это поведение, если отсутствие намеренно

Документация Google по устранению неполядок явно разделяет недоступные документы, перемещенные документы и документы, которые всё ещё существуют, но не загружаются корректно. Это различие предотвращает ситуацию, когда неполная рабочая страница рассматривается как намеренно удаленная. См. Устранение ошибок сканирования Google Search.

Для конкретной передачи задачи напишите: «Для синтетического отсутствующего пути /documents/missing-paper-example-731 верните 404 и отобразите пользовательскую страницу отсутствующего документа по этому адресу. Сохраните существующие пути документов успешными. Применяйте постоянные перенаправления только там, где идентифицирована эквивалентная замена». Добавьте наблюдаемый статус и видимое сообщение из вашей проверки.

Этот запрос описывает требуемое поведение без угадывания названий меню вашего издателя. Реализация находится в конфигурации хостинга, маршруте приложения или системе публикации, создающей ответ. Google объясняет, что коды состояния HTTP генерируются сервером хостинга, в своей документации по кодам состояния HTTP.

Что делать, если редактор позволяет менять только контент страницы?

Редактор, меняющий текст или метаданные документа, может не управлять HTTP-ответами. Стандарт HTML WHATWG определяет специфические поведения для директив meta с использованием http-equiv; установка HTTP-статуса ответа не в их числе. Поэтому добавление http-equiv="status" не является поддерживаемым способом создания 404. См. HTML Standard: Pragma directives.

Когда элементы управления ответом недоступны в редакторе, используйте документированный механизм страницы отсутствия в слое хостинга или приложения. Спросите, обслуживает ли он пользовательский контент с 404 по запрошенному отсутствующему адресу. Настройка, просто выбирающая макет страницы ошибки, не отвечает на этот вопрос; проверьте её результат с помощью рабочего процесса в браузере.

Документированный пример для статических страниц на Netlify

Для существующего статического сайта на Netlify документированный механизм — файл с именем 404.html. Netlify автоматически использует его для неудачных путей, которые не разрешаются в статический файл. Это пример, специфичный для провайдера, с предварительными условиями: доступ к готовому выводу сайта и существующая сборка статических страниц. Netlify документирует пользовательскую обработку 404.

  1. Используйте существующий шаблон страницы сайта, чтобы создать страницу отсутствующего документа.
  2. Убедитесь, что готовый вывод включает 404.html в корне каталога публикации.
  3. Проверьте, что ни одно более раннее правило маршрутизации не отправляет неизвестные адреса на другую страницу.
  4. После того как исправленный вывод станет доступен по публичному адресу, проверьте как отсутствующий путь, так и рабочий документ.

Проверка маршрутизации важна, потому что Netlify обрабатывает маршрутизацию до достижения обработки статических файлов и финального обработчика отсутствующей страницы. Запрос, уже обработанный ранее, не достигнет этого финального обработчика. Его документация Request Chain объясняет порядок. Этот пример описывает путь исправления; он не указывает на то, что какой-либо сайт был изменён.

Граница для приложений с маршрутизацией в браузере

Некоторые приложения обнаруживают, что документ отсутствует, только после выполнения JavaScript. Google признает, что значимые коды статуса могут быть непрактичны в клиентской маршрутизации. Его документированные альтернативы: JavaScript-перенаправление на адрес, чей сервер возвращает 404, или добавление метаданных noindex на страницу ошибки. См. руководство Google по JavaScript SEO.

Эти альтернативы имеют разные результаты. Перенаправление достигает нового адреса с настоящим ответом страницы отсутствия. Подход с метаданными решает вопрос индексации, оставляя исходный HTTP-статус неизменным. Если требование — сохранить исходный адрес документа и вернуть 404 там, ответ хостинга или приложения должен поддерживать это поведение.

Что должно говорить на странице отсутствующего документа?

Используйте короткое, конкретное сообщение, например Этот документ не найден. Добавьте одно полезное следующее действие: ссылку на каталог документов или другой проверенный пункт навигации. Сохраните привычную навигацию и внешний вид сайта. Google рекомендует понятный язык, последовательный дизайн и полезные ссылки для пользовательских страниц отсутствия.

Для синтетического примера с бумагоплетением подходящий текст: Мы не нашли этот документ по бумагоплетению. Просмотрите каталог документов, чтобы выбрать другое руководство. Описывайте документ как постоянно удалённый только тогда, когда это известно. Держите объяснение видимым, а не сразу отправляйте каждый отсутствующий адрес куда-то ещё.

Как проверить, что ответ и страница согласуются?

Повторите проверку с небольшим набором сравнения. Ожидаемые результаты ниже — иллюстративные критерии приёмки; это не сообщённые результаты тестов.

Тестовый случай Ожидаемый ответ и страница
Известный рабочий документ 200, с полным документом
Намеренно несуществующий путь 404, с объяснением об отсутствующем документе
Удалённый документ без замены 404, или 410 когда уместно, с точным объяснением
Перемещённый документ с эквивалентной заменой Постоянное перенаправление, за которым следует успешный ответ замены

Повторно проверьте, вводя каждый адрес напрямую и перезагружая его, включая документы, обычно доступные через навигацию на странице. Это проверяет ответ, который получает новый запрос документа. Держите адрес, код и видимый результат вместе, чтобы успешный пункт назначения не скрыл некорректный ответ ранее в навигации.

Если старый результат сохраняется, разграничьте кэш браузера от других кэшей. Отключение кэша Chrome решает проблему с его кэшем браузера. HTTP-кэширование также может хранить негативные ответы, такие как 404, поэтому устаревший ответ об отсутствии может потребовать проверки документированного поведения кэша системы публикации. RFC 9111 объясняет кэшируемые негативные результаты.

Для Google Search настоящий ответ об отсутствии имеет намеренное последствие: Google не индексирует URL, возвращающие 404 или 410, а ранее проиндексированные URL удаляются по мере обработки этих ответов. Успешный ответ 200 также не гарантирует индексацию. См. Как коды состояния HTTP влияют на сканеры Google.

Завершите, когда каждый проверенный адрес рассказывает последовательную историю: доступные документы загружаются успешно, перемещённые документы ведут к своим заменам, а отсутствующие документы возвращают соответствующий ответ об отсутствии с полезной навигацией. Это даёт вам конкретную, повторяемую проверку публикации на вашем Mac.

Источники