Если в XML sitemap попадают URL, которые не должны индексироваться, проблема обычно не в поисковике, а в настройках темы, плагина SEO или в том, как WordPress регистрирует типы записей и таксономии. На практике чаще всего нужно убрать из карты сайта не весь контент, а только отдельные типы страниц: вложения, служебные архивы, внутренние таксономии, тестовые CPT или страницы фильтров.
Ниже разберём, как понять источник лишних URL, чем отличается отключение sitemap от запрета индексации, и как сделать это без лишних побочных эффектов.
Когда sitemap начинает раздуваться лишними URL
Симптом обычно видно сразу: в отчёте Search Console появляются страницы, которые не должны участвовать в поиске, а в XML-карте сайта есть архивы, вложения или служебные записи. Иногда это заметно и без инструментов — достаточно открыть sitemap и увидеть там URL с параметрами, пустые архивы или страницы, которые не несут ценности.
Что проверить в первую очередь
- какой плагин генерирует sitemap: встроенный WordPress, Yoast SEO, Rank Math, All in One SEO или другой;
- какие типы записей зарегистрированы как
publicиpublicly_queryable; - есть ли у лишних URL отдельный шаблон архива или страницы вложений;
- не добавляет ли их в sitemap сам SEO-плагин, даже если на сайте они уже закрыты от индексации;
- не дублируются ли URL в нескольких источниках sitemap.
Важно не путать два действия: убрать URL из sitemap и закрыть страницу от индексации. Это разные задачи. Если страница должна существовать для пользователей, но не должна попадать в карту сайта, достаточно исключить её из sitemap. Если страница вообще не нужна в поиске, дополнительно ставят noindex или отключают саму страницу на уровне шаблона/типа записи.
Диагностика: откуда именно берётся лишний URL
Сначала определите источник. Это экономит время, потому что у WordPress sitemap может быть несколько уровней: базовый индекс, карты по типам записей, карты по таксономиям и отдельные карты, которые добавляет SEO-плагин.
Откройте:
/wp-sitemap.xml— если используется встроенный генератор WordPress;/sitemap_index.xml— если sitemap отдаёт SEO-плагин;- отдельные карты внутри индекса, например для постов, страниц, категорий или пользовательских типов записей.
Если лишний URL есть только в одной карте, значит, править нужно не весь sitemap, а конкретный тип записи или таксономию. Если URL появляется и в sitemap, и в выдаче, тогда проблема шире: нужна ещё настройка индексации.
Пошаговое решение без лишних рисков
Вариант 1. Отключить sitemap для конкретного типа записи через код
Если вы используете встроенный sitemap WordPress, можно исключить нужный тип записи через фильтр wp_sitemaps_post_types. Это удобно, когда у вас есть служебный CPT, который не должен попадать в карту сайта вообще.
<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
unset( $post_types['landing'] ); // пример: служебный CPT
unset( $post_types['faq'] ); // пример: внутренний тип записей
return $post_types;
} );После этого WordPress перестанет генерировать sitemap для указанных типов записей. Но если эти типы уже доступны по прямым URL, они всё ещё могут индексироваться, если на них ведут ссылки или если они открыты для обхода.
Вариант 2. Убрать отдельную таксономию из sitemap
Для архивов таксономий используется фильтр wp_sitemaps_taxonomies. Это полезно, если в sitemap попадают служебные рубрики, теги или внутренние классификаторы, которые не нужны в поиске.
<?php
add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
unset( $taxonomies['internal_tag'] );
unset( $taxonomies['product_group'] );
return $taxonomies;
} );Здесь важно проверить, не используется ли эта таксономия как навигационный слой на сайте. Если архивы нужны пользователям, но не нужны поисковику, лучше оставить их доступными и закрыть через noindex, а не удалять из sitemap без анализа.
Вариант 3. Исключить отдельные URL из встроенного sitemap
Если проблема не в типе записи целиком, а в конкретных URL, используйте фильтр wp_sitemaps_posts_query_args для ограничения выборки. Это уже более точечная настройка, когда нужно убрать, например, записи с определённым статусом или меткой.
<?php
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
if ( 'post' === $post_type ) {
$args['post__not_in'] = array( 123, 456 );
}
return $args;
}, 10, 2 );Такой подход полезен, если в sitemap случайно попадают тестовые записи, дубли или страницы, которые были созданы для внутренней работы и не должны индексироваться.
Вариант 4. Если sitemap генерирует SEO-плагин
У SEO-плагинов логика своя, и фильтры WordPress могут не сработать. Тогда нужно править настройки самого плагина: отключить тип записи, таксономию или архив в его интерфейсе. Если плагин позволяет, это предпочтительнее кода — меньше шансов сломать обновления.
Если интерфейс не даёт нужной точности, смотрите документацию конкретного плагина. Здесь не стоит гадать по названию опции: у разных решений разные фильтры и разные способы исключения URL.
Что выбрать: плагин, код или настройка типа записи
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройка в SEO-плагине | Нужно убрать целый тип записи или таксономию без кода | Не всегда хватает точности |
| Фильтры WordPress | Используется встроенный sitemap или нужен точечный контроль | Нужно аккуратно тестировать после обновлений |
| Изменение регистрации CPT/таксономии | Служебный тип вообще не должен участвовать в публичной индексации | Может повлиять на фронтенд и внутренние ссылки |
Проверка результата после внедрения
После изменения конфигурации не ограничивайтесь визуальной проверкой sitemap. Нужно убедиться, что URL действительно исчезли из карты сайта и не сломали остальную структуру.
- откройте sitemap в браузере и проверьте, что лишний тип записи или таксономия больше не выводится;
- проверьте HTTP-ответ sitemap: он должен открываться без ошибок;
- обновите sitemap в Search Console, если используете Google;
- сравните старую и новую карту сайта, чтобы не потерять нужные URL;
- проверьте, что страницы, которые должны индексироваться, остались в sitemap.
Если вы исключали только часть URL, полезно сделать точечную проверку через поиск по sitemap: откройте индекс и найдите нужный тип записи по имени. Это быстрее, чем вручную просматривать весь файл.
Частые ошибки и как их исправить
Удалили URL из sitemap, но страница всё ещё индексируется
Это нормальная ситуация. Sitemap не управляет индексацией напрямую. Если страница доступна по ссылкам, поисковик может оставить её в индексе. В этом случае добавьте noindex или закройте страницу на уровне шаблона, если она действительно не нужна в поиске.
Сломали sitemap целиком
Чаще всего это происходит, когда в фильтре удаляют не тот ключ массива или возвращают не массив. Перед внедрением проверьте, какой тип данных приходит в фильтр, и не используйте агрессивные unset() без понимания структуры.
Отключили таксономию, а пропали важные архивы
Такое бывает, если служебная и пользовательская логика смешаны в одной таксономии. Тогда лучше разделить их: оставить публичную таксономию для контента, а внутреннюю — скрыть из sitemap и, при необходимости, из поиска.
Проверяли не тот sitemap
На одном сайте может одновременно существовать /wp-sitemap.xml и /sitemap_index.xml. Если вы меняете настройки WordPress, а смотрите карту от SEO-плагина, кажется, что ничего не работает. Сначала определите источник sitemap, потом вносите правки.
Практические советы по безопасности и производительности
Если вы правите sitemap кодом, лучше держать изменения в дочерней теме или в небольшом mu-plugin, а не в файле основной темы. Тогда обновление темы не затрёт настройку. Для служебных сайтов и проектов с частыми релизами это особенно важно.
Не добавляйте в sitemap всё подряд ради «полноты». Чем больше мусорных URL, тем сложнее анализировать отчёты и тем выше шанс, что поисковик потратит обход на неважные страницы. Для больших сайтов полезно регулярно сверять sitemap с реальной структурой контента: какие типы записей публичные, какие архивы нужны, а какие лучше убрать.
Если вы используете плагины для SEO и чистки сайта, проверьте, не дублируют ли они друг друга. Например, один плагин может закрывать архивы от индексации, а другой — снова добавлять их в sitemap. В таких конфигурациях всегда сначала смотрят на итоговый XML, а не на отдельные настройки по памяти.
В итоге рабочая схема простая: сначала находите источник лишнего URL, потом исключаете именно его — тип записи, таксономию или конкретные записи — и только после этого проверяете sitemap в браузере и в Search Console. Такой порядок экономит время и не ломает индексацию нужных страниц.