Sitemap.xml должен обновляться вместе с сайтом, а агенты проверяют попадание новых страниц

Карта сайта помогает поисковику найти страницы, которые компания хочет показать в поиске. Google прямо пишет, что наличие адреса в sitemap не гарантирует обход и индексацию. Отсутствие адреса тоже не доказывает невидимость: робот мог прийти по ссылке.

Для руководителя это разные предметы приёмки. Разработчик подтверждает, что опубликованный адрес попал в карту и доступен роботу. Статус страницы в поиске проверяют отдельно, в Google Search Console или Яндекс Вебмастере.

Зелёный статус файла подтверждает, что поисковик смог его обработать. Он не отвечает на вопрос, забыли ли разработчики новый раздел. Проверять нужно адреса внутри файла.

Список для карты нужно получать там, где сайт создаёт страницы. У vibecoding.ru часть адресов задана кодом, часть приходит из каталогов, а новости публикуются из базы. Одна сборка объединяет эти источники и передаёт результат генератору sitemap.

Разовый генератор полезен, когда надо получить первый файл. XML-Sitemaps и sitemap-xml.ru предлагают такую генерацию. Для сайта, который меняется, следующая задача другая: связать файл с публикацией новых страниц.

Отдельный список «не забудьте вписать в карту» создаёт повторную работу при каждом выпуске. Такая ручная связь становится частью технического долга. Агент может убрать её, если источник адресов и правила исключений уже определены.

На vibecoding.ru тест сравнивает статические страницы приложения с реестром публичных адресов. Новый маршрут должен попасть в реестр либо иметь осознанное исключение. Если разработчик забыл оба действия, тест перечислит пропущенный путь.

Проверка идёт от страниц к реестру, поэтому забытый адрес можно обнаружить. Если сравнивать карту только с тем же списком, из которого её собрали, получится проверить перенос записей, но не полноту исходного списка.

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

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

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

Сбой базы тоже может скрыть часть адресов. У нас в этом случае статическая часть карты остаётся доступной; положительный ответ сервера не подтверждает наличие новостей. Проверка должна замечать потерю динамической части отдельно.

В поручении агенту нужен результат, который можно проверить. Для sitemap это адрес новой страницы в опубликованной карте и отсутствие служебных адресов. «Сгенерировать XML» описывает только файл.

Повторяемую часть закрепляют в правилах для агентов: публичная страница принимается вместе с записью в источнике адресов и проверкой. Определять публичность должен проект; агент не получает право считать любой открывающийся кабинет страницей для поиска.

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

Успешная сборка ещё не подтверждает, что новый файл увидит поисковик. После выпуска агент получает sitemap с рабочего домена и ищет добавленный адрес. Затем проверяет саму страницу: она открывается по основному адресу и разрешена для индексации.

Дата lastmod должна отражать содержательное изменение страницы. Google использует её, когда она соответствует реальным обновлениям; дата каждой пересборки XML для этого не подходит. У неизменённой статьи дата должна остаться прежней.

Когда часть карты пропала, руководителю нужен список отсутствующих URL и причина. Чинить приходится источник, лимит выборки или опубликованную версию генератора. Порядок действий при поломке связан с проверкой и откатом, а не с повторным скачиванием того же файла.

Контроль полезен, когда найденный пропуск становится задачей. В отчёте после выпуска должны быть URL, время проверки и результат. Сообщение «sitemap обновлён» без списка проверенных адресов руководителю мало помогает.

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

Ответственного назначают заранее: за генерацию и пропуски отвечает разработка, за интерпретацию поисковых статусов отвечает тот, кто ведёт поиск. Это часть работы руководителя разработки. Сообщение о сбое должно попасть тому, кто его устранит.

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

Для такого потока в подписке на разработку есть тариф «Один проект»: 250 000 ₽ в месяц, один продукт и один поток работы, условия проверены 07.10.2026. Это цена подписки, а не смета ремонта карты.

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

Если нужно понять, готова ли разработка принимать задачи с проверками, начните с теста для руководителя. Практический результат по sitemap всё равно тот же: новые адреса появляются в карте, а пропуски получают проверку и ответственного.

1. Собирайте sitemap из источников публичных страниц; исключения задавайте явно.

2. Сверяйте карту с перечнем страниц и публикаций: исправный XML ещё может быть неполным.

3. Принимайте новую страницу вместе с адресом в живой карте и проверкой после выпуска.

4. Разделяйте пропуск в карте и отсутствие в индексе; каждому сигналу назначьте ответственного.