Sitemap для новостей

Происхождение и история термина

20 ноября 2006 года Google объявил о News Sitemaps для англоязычных сайтов, уже включённых в Google News. Анонс связывал новостную карту со свежестью материалов: издатель мог передать дату и время публикации, а также увидеть ошибки обхода. Это документированная веха появления механизма, а не установленное первое употребление английского словосочетания. ^[6]

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

Суть и механизм

XML, расширяемый язык разметки, представляет данные с помощью элементов: у них есть обозначенные тегами начало и конец, а внутри могут находиться текст и другие элементы. ^[3] В карте сайта внешний элемент urlset объединяет записи url, каждая из которых содержит loc — адрес страницы, или URL. Файл записывают в кодировке UTF-8, а служебные символы внутри значений экранируют, то есть заменяют безопасными последовательностями. ^[2]

Новостное расширение добавляет блок news:news. Приставка news связана с пространством имён — обозначением набора элементов, к которому относятся новостные поля. ^{[1] [2]} Представьте анкету: адрес отвечает на вопрос «где статья», а дополнительные поля — «кто, на каком языке, когда и под каким заголовком её опубликовал». Это учебная аналогия, объясняющая связь полей, а не отдельная классификация стандарта.

Google ограничивает новостные записи публикациями последних двух дней и тысячей блоков news:news в одном файле. Более старый адрес удаляют из новостной карты либо оставляют без новостного блока. Дату берут из первой публикации на сайте, а не из момента экспорта. ^[1]

Виды и классификации

Google допускает два варианта: отдельный новостной файл или новостные элементы внутри существующей карты. ^[1] Различие касается организации файлов. Например, в учебной редакции отдельная карта удобна сотруднику, который сравнивает сегодняшний выпуск с выгрузкой: ему не приходится искать свежие записи среди других страниц.

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

Как применяется на практике

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

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

Российская справка Яндекса описывает общую карту сайта. Сравнивать её с новостным расширением Google нужно с учётом предмета каждого руководства:

В Яндекс Вебмастере добавляют адрес доступного файла; затем отдельно отображается результат обработки. Например, статус ошибки оформления отличается от ситуации, когда сервер не отдаёт файл с успешным ответом HTTP 200. ^[4] Это помогает решить, кому передать проблему: сотруднику, формирующему документ, или администратору сервера. Таблица не устанавливает, как Яндекс трактует каждый тег расширения Google.

Как измерить или проверить

Предлагаемая редакционная проверка состоит из четырёх последовательных вопросов. Читается ли XML? Соответствует ли структура карте сайта? Верны ли сведения о публикациях? Доступен ли размещённый файл поисковику? Порядок позволяет не смешивать разные причины отказа: исправление синтаксиса не восстановит доступ к серверу.

W3C различает правильно оформленный XML и документ, удовлетворяющий дополнительным условиям валидности. ^[3] Для карты проверяют также её схему — описание разрешённых элементов и их расположения; протокол публикует схемы в формате XSD, языке описания структуры XML. ^[2] Поэтому успешное чтение файла обычным XML-парсером, программой разбора XML, — лишь первый результат.

В приложенном генераторе укажите название издания, код языка и записи вида «адрес | дата | заголовок», по одной на строку. Он принимает дату без времени либо дату со временем до секунд и часовым поясом; это ограниченный набор форматов ввода. Поле момента проверки необязательно. Если оно заполнено, дата должна содержать время и пояс. Кнопка сброса очищает поля и результат.

Генератор отклоняет пустой ввод, повторяющиеся адреса, разные хосты или протоколы, невозможные даты и более тысячи строк. Хост — имя узла в адресе, например example.test. Проверка языка ограничена формой кода: соответствие реальному языку остаётся за пользователем. Инструмент не выполняет полную проверку по XSD и не открывает статьи.

Учебная проверка экранирования: введите заголовок «Школа & музей». В XML амперсанд должен превратиться в &. ^[2] Исходный смысл заголовка при этом сохраняется. Если вручную вставить уже экранированный текст в поле, результат будет описывать именно введённую строку: форма ожидает обычный заголовок, а не готовую XML-разметку.

Другой учебный тест касается времени. Между 28 октября в 09:00 и 30 октября в 12:00 при одинаковом часовом поясе проходят 51 час: двое суток дают 48 часов, ещё три часа дают итог. Генератор предупреждает при возрасте более 48 часов. Это справочный порог приложения; он не подтверждает реальную дату статьи и не заменяет проверку правила платформы.

При размещении файла администратор может проверить заголовок ответа Content-Type, указывающий тип содержимого. Тип application/xml зарегистрирован IANA. ^[5] Однако верное обозначение типа не доказывает, что внутри находятся нужные записи: это отдельная проверка содержимого.

Ошибки, ограничения и спорные вопросы

Частая смысловая ошибка — считать число выгруженных записей числом проиндексированных статей. Индексация означает включение материала в поисковый индекс; карта лишь помогает обнаруживать адреса и не гарантирует обхода и индексации всех записей. ^[7] В учебном примере две строки означают две подготовленные записи, а не два подтверждённых результата в поиске.

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

Частые вопросы

Связанные термины

• Карта сайта (sitemap.xml)
• Микроразметка NewsArticle
• RSS-лента
• Индексация