Генератор добавил /api/products/ вместе с карточками товаров. Ответ содержит JSON, поэтому открывается успешно, но не является пользовательской карточкой. Исправление требует карты назначений маршрутов: данные приложения, публичный документ и служебный endpoint нельзя объединять по одному признаку HTTP 200.
Классифицируйте маршруты по назначению
Для каждой записи определите, что должен увидеть посетитель из поиска. Пользовательская HTML-страница и API могут отдавать похожие сведения, но выполнять разные задачи. Служебные endpoints исключайте из карты по назначению, а не по случайному наличию слова api в пути.
Sitemap помогает сообщить поисковой системе о выбранных URL, но не гарантирует их индексацию. Официальная документация.
CMS может хранить в одной таблице /products/a/, /api/products/a и /downloads/a.pdf. Первый адрес служит карточкой, второй — источником данных приложения, третий — инструкцией. Начните с этой классификации, а не с универсальной фильтрации расширений. У каждого маршрута должен быть понятный пользователь и ожидаемый ответ. Если адрес нужен только внутреннему обмену приложения, его появление в sitemap обычно показывает ошибку выбора источника. Но сам формат JSON не является достаточным объяснением назначения: решение опирается на архитектуру конкретного сайта.
API, страница и публичный документ
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| /product/a/ | HTML-карточка | Оставить по назначению | Контент и canonical |
| /api/products/a | JSON-данные | Исключить служебный URL | Не подменять карточку |
| /api/account | Личные сведения | Проверить авторизацию | Карта не защита |
| /manual.pdf | Публичный документ | Решить отдельно | Формат сам не запрет |
В учебной таблице добавьте поиск, кабинет, экспорт и открытый PDF. Укажите публичность, полезность входа из поиска и наличие самостоятельного содержания. Документ может быть намеренно доступен поиску, хотя не является HTML. API с публичными данными может быть доступен технически, но не предназначаться как поисковая посадочная. Не пытайтесь уместить эти решения в один признак HTTP 200. Отдельная политика позволяет генератору включать нужные страницы и документы, оставляя служебные маршруты вне предлагаемого списка.
Проверьте тип ответа и фактическое содержание
Сопоставьте Content-Type, тело ответа, видимую страницу и источник генерации URL. Проверьте маршруты загрузки данных, авторизации и экспорта отдельно. Публичные документы нестандартного формата также требуют осознанного решения об индексации.
Сохраните Content-Type и начало тела каждого подозрительного loc. У JSON проверьте, что перед вами данные, а не HTML-страница ошибки, ошибочно названная API. Для HTML откройте гостевой интерфейс и сравните назначение. Посмотрите, нет ли перенаправления с служебного адреса на экран входа. В некоторых системах расширение отсутствует, поэтому вид /data/a не объясняет формат. Источник генерации URL должен быть известен: маршруты приложения, записи CMS или результаты обхода. От этого зависит, где исправлять избыточный состав.
Учебный тест генератора маршрутов
Учебная таблица маршрутов CMS включает карточку, её JSON-источник и PDF-инструкцию. Генератор должен выбирать записи по назначению. Правило «всё кроме JSON» не заменяет решение о публичности PDF и доступе к API.
На тестовой копии подайте генератору три записи: публичную карточку, служебный endpoint и опубликованную инструкцию. Выпишите ожидание для каждой до запуска. После построения карты проверьте фактические loc. Затем добавьте приватный endpoint и черновик документа: они не должны появиться только потому, что имеют зарегистрированный маршрут. Такой опыт выявляет фильтр по назначению и публикации. Если правило работает по строке /api/, измените имя тестового служебного маршрута и посмотрите, останется ли классификация правильной.
Исправьте выборку вместо запрета по имени пути
Сформируйте список разрешённых публичных типов маршрутов для генератора. Проверьте, что URL API больше не попадают из общей таблицы маршрутов. Для конфиденциальных ответов отдельно сохраняйте контроль доступа.
Используйте явные типы публичных ресурсов или предусмотренный список включения. Не берите все зарегистрированные маршруты framework без фильтра: среди них находятся callbacks, формы, служебные ответы и панели. Для CMS проверьте статус публикации и SEO-исключения соответствующего типа. Если генератор получает адреса из обхода, выясните, почему публичные страницы ссылаются на API как на навигационное назначение. Тогда одной очистки sitemap недостаточно: нужно исправить источник таких ссылок. Сохраняйте API-доступ приложения, который требуется реальным пользовательским функциям.
Контроль доступа остаётся отдельной задачей
Исключение API из sitemap не закрывает endpoint от пользователей или роботов. Если ответ содержит приватную информацию, настройка карты не заменяет авторизацию.
Удаление записи из sitemap не делает endpoint закрытым. Для пользовательских данных проверьте авторизацию и отсутствие утечки в ответах, но не публикуйте сами значения. Если endpoint нужен браузеру с cookies, отделите это от возможности получить его как анонимный запрос. Не добавляйте пароль только ради улучшения SEO-списка, не поняв зависимые функции. Приватность — самостоятельное условие архитектуры. В отчёте очистки карты достаточно указать, что служебный маршрут исключён, а его контроль доступа проверен отдельно или передан ответственному владельцу.
Приёмка пользовательских входов из поиска
После правки откройте контрольные пользовательские страницы по прямым URL и через обычную навигацию. Они должны сохраниться в предусмотренных картах и отвечать своему назначению. Служебные endpoints больше не перечисляются, но приложение продолжает получать нужные данные. Проверьте повторную генерацию и новую публикацию типа записи. Установите владельца политики включения, чтобы очередной API-маршрут не стал поисковой страницей автоматически. Индексация оставшихся loc оценивается отдельно: правильный состав карты только описывает выбранные ресурсы и не гарантирует появление каждого в выдаче.
Критерии завершения проверки
Карта содержит нужные пользовательские страницы; служебные маршруты отсутствуют. Контрольные карточки остаются доступны и обнаружимы, правила безопасности API проверяются независимо.
- /product/a/: Контент и canonical. Зафиксируйте фактический результат и адрес проверенного сценария.
- /api/products/a: Не подменять карточку. Зафиксируйте фактический результат и адрес проверенного сценария.
- /api/account: Карта не защита. Зафиксируйте фактический результат и адрес проверенного сценария.
- /manual.pdf: Формат сам не запрет. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Sitemap.xml: полное руководство по созданию и оптимизации для SEO и HTTP статус-коды: полный справочник (200, 301, 404, 500...). Отдельные проверки сайта собраны на странице технического аудита reChecker.