Sitemap

В июне 2005 года Google опубликовал формат Sitemaps 0.84, чтобы владельцы сайтов могли перечислять адреса своих страниц для робота компании. Формат был закрытым и действовал только для поиска Google; пресс-релиз 2006 года называл этот выпуск первым шагом, на котором позднее построили общий протокол^[3].

16 ноября 2006 года Google, Yahoo! и Microsoft объявили о совместной поддержке Sitemaps 0.90 — первой совместной открытой инициативе по улучшению процесса обхода веба поисковыми системами, представив протокол как бесплатный и простой для веб-мастеров способ уведомления поисковых систем о своих сайтах. Компании переместили протокол на совместно поддерживаемый сайт sitemaps.org, подняли номер версии и договорились вместе развивать формат и публиковать его дополнения. Любая компания, публикующая динамический контент на тысячах адресов — например, цены и наличие товаров, — может с его помощью сообщать роботам, какие страницы появились и изменились^[3].

Главный редактор Search Engine Watch Дэнни Салливан отметил в пресс-релизе, что на отраслевых конференциях веб-мастера давно просили именно такие открытые стандарты и что это развитие отвечает реальной потребности сообщества. По его словам, инициатива должна привести к большей кооперации в отрасли, в том числе вокруг файла robots.txt, который задаёт направления для веб-роботов^[3].

Руководители присоединившихся компаний подчеркнули разные стороны инициативы. Нараянан Шивакумар (Google) назвал совместную поддержку важной вехой: она помогает веб-мастерам и поисковым системам лучше понимать друг друга, обеспечивая более качественный обход и лучшие результаты. По его словам, начальные усилия дали веб-мастерам полезные сведения об их сайтах, а полученная в ответ информация улучшила качество поиска Google^[3]. Тим Мейер (Yahoo! Search) назвал запуск значительным, поскольку протокол даёт сайтам единый простой способ передавать содержание и метаданные поисковым системам: карта помогает владельцам показывать контент, который роботам трудно обнаружить самостоятельно, что делает результаты поиска более полными. Кен Мосс (Windows Live Search) заметил, что качество индекса определяется качеством источников^[3]. Сайт sitemaps.org планировалось разместить на хостинге Yahoo Small Business^[3].

В апреле 2007 года поисковые системы поддержали автоматическое обнаружение карт: строка с полным адресом файла в robots.txt избавила владельцев от подачи карты в каждую систему отдельно. К соглашению присоединилась поисковая машина Ask.com, после чего автообнаружение поддерживали все крупные поисковые системы^[4].

В июне 2023 года Google объявил о закрытии пинг-эндпоинта протокола: изучение показало, что большая часть неаутентифицированных заявок является спамом, и через полгода запросы к сервису начали возвращать ответ 404^[5]. В том же сообщении компания раскрыла отношение к необязательным полям карты: частота обновления и приоритет не учитываются вовсе, а дата изменения засчитывается только при соответствии фактическому значимому изменению страницы. Компания рекомендовала указывать lastmod лишь при действительных изменениях и подчеркнула, что сам протокол остаётся без изменений^[5].

Версия 0.9 с 2006 года не пересматривалась: изменение формата происходило за счёт расширений с собственными пространствами имён, а не новых версий протокола^[5][1]. Протокол опирается на идеи работы 2000 года о «дружественных к роботам» серверах: её авторы предлагали, чтобы сервер хранил опись собственных страниц с отметками времени изменения и сообщал роботу, какие адреса и в каком порядке запрашивать. Такой обмен превращает обход в инкрементальный — робот запрашивает прежде всего изменившиеся страницы, не тратя запросы на перебор всего сайта^[6].

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

Адрес пространства имён в примерах протокола использует схему HTTP, а не HTTPS, и это сделано намеренно: идентификатор служит справочником для разбора элементов XML, а не адресом загрузки^[5]. Поле приоритета охарактеризовано как глубоко субъективное: по внутренним исследованиям компании, оно обычно не отражает фактическую важность страницы относительно других страниц того же сайта, а частота обновления концептуально пересекается с датой изменения^[5].

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

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

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

Специалисты по поисковой оптимизации рассматривают карту как часть технической подготовки сайта наряду с файлом robots.txt^[9]. Для сайтов с большим числом страниц карта систематизирует обход: робот получает маршрут, в котором первыми идут приоритетные разделы^[10].

Обзорные исследования используют карту как выражение структуры сайта: методы интеллектуального анализа данных восстанавливают по картам иерархию разделов, утраченную при изменении структуры. Такие методы опираются на представление о карте как об иерархической организации концептов сайта^[11]. Карту обычно определяют на ранних стадиях проектирования, однако сайты со временем меняют структуру, содержание и навигационные пути, и карта перестаёт отражать фактическое содержание. Сопоставление фактически связанных страниц с задуманной картой позволяет планировать реорганизацию сайта; помимо иерархии концептов карта фиксирует основные сценарии перемещения посетителей^[11].

Файл карты — документ XML в кодировке UTF-8^[1][12]. В открывающем элементе urlset указывается пространство имён протокола 0.9 с сайта sitemaps.org; для каждой страницы в карту входит элемент url, содержащий обязательный элемент loc с полным адресом. Остальные теги необязательны, и их поддержка может различаться между поисковыми системами^[1].

Допустимые элементы файла карты перечислены в таблице^[1].

Ниже приведён пример файла карты с одним адресом и всеми необязательными тегами; необязательные поля можно комбинировать произвольно^[1].

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>http://www.example.com/</loc>
    <lastmod>2006-11-16</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

Файл может содержать произвольное число записей; в примере ниже адреса используют разные сочетания необязательных полей, включая маскирование амперсанда^[1].

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>http://www.example.com/catalog?item=12&amp;desc=vacation_hawaii</loc>
    <changefreq>weekly</changefreq>
  </url>
  <url>
    <loc>http://www.example.com/catalog?item=73&amp;desc=vacation_new_zealand</loc>
    <lastmod>2004-12-23</lastmod>
  </url>
  <url>
    <loc>http://www.example.com/catalog?item=74&amp;desc=vacation_newfoundland</loc>
    <lastmod>2004-12-23T18:00:15+00:00</lastmod>
    <priority>0.3</priority>
  </url>
</urlset>

Дата в элементе lastmod записывается в формате W3C Datetime: за счёт опускания сегмента времени стандарта ISO 8601 допускается сокращение до вида ГГГГ-ММ-ДД^[13]. Значение должно отражать дату последнего изменения самой страницы, а не момент создания карты; связи с заголовком If-Modified-Since, который возвращает сервер, нет, и поисковые системы могут использовать эти два источника по-разному. Для часто изменяющихся сайтов рекомендуется указывать и время, чтобы сканеры получили более полную информацию о сайте^[1].

Дату последнего изменения вычисляют в зависимости от типа страницы: для статических файлов это фактическая дата обновления, для динамических адресов — дата изменения исходных данных или приближённая оценка. Полезна даже приблизительная отметка: сканер пропускает заведомо неизменённые адреса, что снижает нагрузку на канал и процессор веб-сервера^[14]. Элемент changefreq указывает вероятную частоту изменения страницы одним из значений always, hourly, daily, weekly, monthly, yearly или never. Значение always описывает документы, изменяющиеся при каждом обращении, а never — архивные адреса. Протокол называет это значение подсказкой, а не командой: сканер может обходить страницу с пометкой «ежечасно» реже указанного, а «ежегодно» — чаще, и даже архивные адреса периодически проверяются на неожиданные изменения^[1].

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

В файле карты применяется маскирование символов: амперсанд заменяется последовательностью &, апостроф — ', кавычка — ", знаки больше и меньше — > и <. Адреса должны соответствовать стандарту RFC-3986^[15] для URI и RFC-3987^[16] для IRI, а длина значения loc не должна превышать 2048 символов. Для адресов с символами вне ASCII применяется процентное кодирование: один и тот же адрес с буквой «ü» в кодировках ISO-8859-1 и UTF-8 даёт разные последовательности. Помимо маскирования символов, адрес кодируется для удобочитаемости веб-сервером, на котором он размещён. Если адреса создаются сценариями или инструментами, маскирование применяется к ним автоматически^[1].

Элементы и атрибуты файлов задают опубликованные XML-схемы протокола: sitemap.xsd описывает файл карты^[17], а siteindex.xsd — файл индекса^[18]. По этим схемам проверяют структуру файлов ряд инструментов для работы с XML^[1].

Необязательные поля Google не использует: частота обновления и приоритет не учитываются вовсе, а дата в lastmod засчитывается только при согласованности с реальными изменениями — незначимые правки оформления не требуют обновления поля^[5].

Основной формат протокола — XML-карта; её рекомендуют как формат с наибольшей подробностью, поскольку она сообщает о страницах сведения, недоступные в иных вариантах. Помимо неё стандарт допускает текстовый файл, где каждая строка содержит один адрес, а также выдачу свежих страниц в форматах синдикации RSS и Atom^[1].

Текстовая карта содержит по одному полному адресу в строке, включая префикс протокола, и не должна включать иных данных, заголовков или конечных строк. Файлу можно дать любое имя, а разместить его следует в каталоге самого высокого из обходимых уровней; действуют те же ограничения в 50 000 адресов и 50 МБ, что и для XML-карты, допустима упаковка gzip^[1].

http://www.example.com/catalog?item=1
http://www.example.com/catalog?item=11

Как карту можно передать канал RSS 2.0 либо Atom 0.3 или 1.0 — обычно если такой канал на сайте уже ведётся. Канал перечисляет только последние адреса, поэтому полной картины сайта он не даёт; адрес несёт поле link, а дату изменения — поле pubDate у RSS и элемент обновления у Atom; использование поля даты необязательно. Канал следует размещать в каталоге самого высокого уровня, а прочие страницы робот находит по ссылкам из него^[1].

Формат выбирают исходя из доступных сведений: канал синдикации используют как карту лишь при уже ведущемся канале, в остальных случаях предпочтительна XML-карта с её подробностью^[1].

Для посетителей сайта создают HTML-карту — страницу с перечнем разделов в иерархическом виде, размещаемую в нижней части сайта; роботы также обходят ссылки из неё^[10]. HTML-карта сайта выполняет навигационную функцию, сходную с функцией оглавления книги: карта в HTML помогает посетителю найти раздел, а карта в XML — роботу^[10].

Хлебные крошки дополняют HTML-карту: они показывают, на какой глубине находится конкретная страница^[10].

Один файл карты вмещает не более 50 000 адресов, а его размер без сжатия не превышает 50 МБ (52 428 800 байт); для уменьшения требований к пропускной способности канала допускается упаковка архиватором gzip; архиватор zip протоколом не предусмотрен. Размер файла в несжатом виде не должен выходить за тот же предел^[1][14].

Если адресов больше, чем входит в один файл, сайт разделяет карту на несколько файлов, которые перечисляются в отдельном файле индекса; его формат похож на формат карты, а открывающий элемент называется sitemapindex. В файле индекса может быть перечислено не более 50 000 карт, а его размер также ограничен 50 МБ; робот читает индекс и обходит перечисленные в нём файлы^[1]. Индекс вправе перечислять только файлы карт, размещённые на том же сайте, что и он сам, а каждый из перечисленных файлов также может быть упакован^[1].

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>http://www.example.com/sitemap1.xml.gz</loc>
    <lastmod>2004-10-01T18:23:17+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>http://www.example.com/sitemap2.xml.gz</loc>
    <lastmod>2005-01-01</lastmod>
  </sitemap>
</sitemapindex>

Дата в элементе lastmod файла индекса относится к самому файлу карты, а не к перечисленным в нём страницам. Отметка времени позволяет сканеру извлекать только те файлы карт, которые изменились после определённой даты; такой механизм частичного извлечения ускоряет обнаружение новых адресов на сайтах больших размеров^[1]. Файл индекса описывают элементы: обязательные sitemapindex, инкапсулирующий сведения о файлах карт, sitemap со сведениями об отдельном файле и loc с местоположением файла карты, а также необязательный lastmod — время изменения соответствующего файла^[1]. Ограничения призваны исключить остановку веб-сервера при отдаче очень больших файлов. Файл индекса рекомендуют использовать и для небольшого сайта, если предполагается, что число адресов или размер файлов превысят установленные пределы^[14]. Для сайтов с десятками миллионов адресов часто изменяемые страницы перечисляют в отдельных файлах карт и помечают эти файлы датами в индексе — поисковые системы последовательно сканируют только изменённые файлы карт^[14].

Все адреса в карте должны быть полными URL того же хоста и протокола, что и сама карта; для поддоменов создают отдельные карты^[1][10]. Адреса, не отвечающие правилам, исключаются из рассмотрения^[1]. Адрес в карте указывают полностью, с префиксом протокола и концевой косой чертой, если она требуется серверу; запись без префикса недопустима^[14]. При наличии вариантов адреса с префиксами http и https перечисляют одну версию: несколько версий одного адреса, как и идентификаторы сеансов в адресах, приводят к неполному и излишнему сканированию^[14].

Основной способ — директива Sitemap с полным адресом карты в файле robots.txt; она не зависит от строки агента пользователя, поэтому её положение в файле не важно. При наличии файла индекса достаточно указать только его, не перечисляя отдельные файлы карт, а в одном robots.txt допускается несколько таких директив^[1][4].

Sitemap: http://www.example.com/sitemap.xml

Карту также подают через панели веб-мастеров поисковых систем, включая Яндекс Вебмастер, — они показывают обработку файла и обнаруженные ошибки^[4][10]. Третий способ — HTTP-запрос к пинг-эндпоинту протокола, не требовавший проверки подлинности отправителя; Google закрыл его в 2023 году из-за доли спама в заявках, и подача карты осталась через robots.txt и панели^[5].

Подача через Яндекс Вебмастер требует подтверждения прав на сайт. Файл отправляется в блоке «Индексирование» — «Файлы Sitemap»; после обработки статус меняется с «В обработке» на «Готово», а ошибки показываются перечнем: недоступные адреса, неверный формат файла, превышение лимита размера. Инструмент «Анализ файлов Sitemap» проверяет файл до отправки на индексацию^[10]. Запись в robots.txt и подачу через панель можно использовать одновременно — это повышает вероятность, что робот обнаружит карту быстрее^[10].

Полнота перечисления улучшает представление сайта: робот может пропустить адреса, не охваченные внутренними ссылками или скрытые за формами поиска по сайту^[7][2]. Сообщения об изменениях ускоряют появление новых страниц в индексе, а опознание неизменившихся страниц избавляет робота от лишних запросов^[3]. Компании-разработчики протокола отмечали, что ускоренное обнаружение контента увеличивает переходы с поиска и повышает эффективность поискового маркетинга^[3]. Для страниц, собранных из фреймов, перечисляют адреса и набора фреймов, и их содержания^[14]. Положение адреса внутри файла карты не влияет на его рассмотрение: значим сам факт перечисления, порядок строк робот не интерпретирует^[14]. Разработчики протокола отмечали, что использование карты может повысить эффективность обнаружения страниц и планирования их обхода^[4][7].

Карта не гарантирует индексацию: перечисленные страницы оцениваются общими алгоритмами поисковой системы^[1]. Отдельно карта не влияет на ранжирование: необязательные поля приоритета поисковые системы не учитывают^[5][9].

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

Карты создают генераторы, обходящие сайт, и встроенные средства систем управления контентом. Выделяют статические карты, создаваемые один раз, и динамические, обновляемые при изменении сайта; для крупных ресурсов предпочтительны вторые^[10]. Применению карт в системах управления контентом посвящены отдельные главы практических руководств по поисковой оптимизации^[19]. Официальные документации поисковых систем описывают построение файла карты и его подачу^[20], а сравнительные исследования рассматривают карту сайта как элемент дизайна веб-сайтов^[21]. Инструменты проверяют файл на соответствие схеме, а панели веб-мастеров показывают перечень обработанных адресов^[9].

Онлайн-генераторы создают файл по адресу сайта: сервис обходит ресурс, собирает доступные адреса и формирует XML-файл. Возможности бесплатных версий обычно ограничены размером сайта, а динамический контент, загружаемый через JavaScript, генераторы обрабатывают не всегда корректно^[10]. Для сайтов на популярных системах управления контентом используют плагины: карта обновляется при публикации материалов и удалении старых, типы включаемого контента настраиваются, служебные разделы исключаются из перечня^[10].

Приложения карт выходят за пределы поисковой оптимизации: исследования описывают навигацию по сайту через карту в интерфейсе обозревателя^[22] и автоматическое восстановление структуры сайта из карт. В таком подходе карты генерируются анализом веб-графа сайта: замкнутые частые последовательности ссылок извлекаются из «веб-списков» — меню, навигационных панелей и оглавлений страниц. На трёх реальных наборах данных такие карты оказались ближе к картам, составленным редакторами сайтов, чем результаты конкурирующих алгоритмов^[11].

В русскоязычной литературе по поисковой оптимизации карту рассматривают в паре с файлом robots.txt: один файл задаёт маршрут робота по приоритетным страницам, другой исключает адреса из обхода^[8][10].