Когда в XML sitemap попадают служебные страницы, черновые CPT, пустые таксономии или архивы, карта сайта перестаёт помогать поисковику и начинает шуметь. На небольшом сайте это обычно незаметно, но на проектах с кастомными типами записей и плагинами для SEO карта быстро разрастается и усложняет контроль индексации.
Ниже — практический разбор: как понять, что именно лишнее в sitemap, чем отличается настройка в SEO-плагине от решения кодом, и как проверить, что после правки карта сайта стала чище, а нужные URL не пропали.
Когда sitemap нужно чистить вручную
Проблема обычно проявляется не в Google Search Console, а раньше — в самой структуре сайта. В sitemap внезапно оказываются:
- служебные записи кастомных типов, которые не должны индексироваться;
- архивы автора на сайтах с одним автором;
- пустые рубрики и теги;
- страницы пагинации, если они не нужны в поиске;
- медиа-вложения, которые дублируют контент записи;
- старые CPT после миграции, которые уже не используются.
Если карта сайта содержит такие URL, поисковик тратит обход на мусорные страницы. Это не всегда критично, но на больших сайтах лишний шум мешает быстрее находить важные обновления.
Диагностика: что именно попало в XML sitemap
Сначала не меняйте настройки наугад. Откройте сам sitemap и посмотрите, какие разделы туда включены. В WordPress с современными ядровыми sitemap адрес обычно выглядит как /wp-sitemap.xml. Если используется SEO-плагин, у него может быть свой индекс карт.
Что проверить в первую очередь
- какие post type присутствуют в sitemap;
- есть ли там архивы таксономий;
- не попали ли media attachment URL;
- не дублируются ли записи через несколько карт;
- не отдаются ли в sitemap URL с
noindex, если плагин это умеет корректно исключать.
Удобно открыть sitemap в браузере и пройтись по ссылкам вручную. Если карт много, проверьте индексную карту и отдельные XML-файлы. Часто проблема видна сразу: в карте есть разделы, которые вообще не нужны для поиска.
Что лучше: настройка плагином или кодом
Если сайт уже использует SEO-плагин, проще сначала решить задачу через его интерфейс. Код нужен, когда:
- нужно убрать из sitemap только один конкретный CPT;
- плагин не даёт точечной настройки;
- вы поддерживаете тему или mu-plugin и хотите предсказуемое поведение без зависимости от интерфейса.
| Подход | Плюсы | Минусы |
|---|---|---|
| Настройка в SEO-плагине | быстро, без правки кода, удобно для редактора | не всегда есть точечный контроль |
| Код через фильтры WordPress | точно, прозрачно, можно версионировать | нужен доступ к теме или mu-plugin |
| Отключение целых типов контента | простое решение для служебных сущностей | можно случайно убрать нужные URL |
Пошаговое решение через код WordPress
Если вы используете ядровой sitemap WordPress, можно исключить ненужные типы записей через фильтр wp_sitemaps_post_types. Это рабочий вариант для кастомных типов, которые не должны попадать в карту сайта.
<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
// Убираем служебный CPT из sitemap.
unset( $post_types['landing'] );
// Если нужно, можно убрать ещё один тип.
unset( $post_types['faq'] );
return $post_types;
} );
Этот код лучше размещать в небольшом mu-plugin или в дочерней теме, а не в functions.php активной темы, если сайт живёт долго и тема может меняться.
Если нужно убрать отдельные таксономии, используйте фильтр wp_sitemaps_taxonomies:
<?php
add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
unset( $taxonomies['post_tag'] );
unset( $taxonomies['city'] );
return $taxonomies;
} );
Такой подход полезен, когда теги или служебные таксономии создаются автоматически, но не несут самостоятельной поисковой ценности.
Если нужно убрать отдельные записи, а не весь тип
Иногда тип записей нужен в sitemap, но часть объектов — нет. Тогда удобнее фильтровать URL на уровне sitemap entries. Для ядрового sitemap есть фильтр wp_sitemaps_posts_query_args, но он работает на уровне запроса. Если задача точечная, проще исключать записи по метаполю или статусу публикации ещё до формирования карты.
Пример: не включать записи с метаполем _exclude_from_sitemap:
<?php
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
if ( 'post' !== $post_type ) {
return $args;
}
$args['meta_query'] = array(
array(
'key' => '_exclude_from_sitemap',
'compare' => 'NOT EXISTS',
),
);
return $args;
}, 10, 2 );
Это не универсальная серебряная пуля: если у вас уже есть сложные meta_query, их нужно аккуратно объединять, а не затирать.
Как сделать то же самое в SEO-плагине
Если на сайте стоит SEO-плагин, сначала проверьте его настройки XML sitemap. Обычно там можно отключить:
- отдельные post type;
- таксономии;
- авторов;
- медиа-вложения;
- архивы.
Плюс такого подхода в том, что редактор или контент-менеджер может поддерживать настройку без разработчика. Минус — после обновления плагина логика может меняться, поэтому важно перепроверять sitemap после апдейта.
Если вам нужен не только контроль sitemap, но и чистка дублей, служебных страниц и лишних элементов в head, иногда проще использовать один инструмент для нескольких задач. Например, Clearfy Pro закрывает часть технических настроек в одном интерфейсе, но всё равно требует проверки результата руками.
Проверка результата после внедрения
После правки не ограничивайтесь открытием главной карты сайта. Проверьте три уровня:
- индексную sitemap;
- отдельные XML-файлы для постов, таксономий и архивов;
- фактический ответ сервера для исключённых URL.
Полезно убедиться, что нужные записи остались в карте, а лишние исчезли. Если вы убирали CPT, проверьте хотя бы одну опубликованную запись этого типа и одну исключённую.
Быстрая проверка через WP-CLI возможна не всегда для sitemap напрямую, но можно проверить, что нужные типы записей всё ещё существуют и опубликованы:
wp post list --post_type=landing --post_status=publish --fields=ID,post_title
Для ручной проверки откройте sitemap в браузере и найдите конкретный URL. Если он всё ещё есть, значит фильтр не сработал или применяется не к тому уровню.
Что считать нормальным результатом
- в sitemap остались только публичные и полезные для поиска URL;
- исключённые типы записей больше не отображаются в XML;
- карта сайта открывается без ошибок 404 и 500;
- в Search Console нет резкого роста ошибок сканирования после изменений.
Частые ошибки и как их исправить
Удалили не тот post type
Часто в коде путают slug типа записи. Например, в админке он называется по-человечески, а в коде используется другой ключ. Проверьте регистрацию CPT в register_post_type() и используйте именно внутренний slug.
Сломали sitemap после обновления плагина
Если плагин сам генерирует sitemap, ядровые фильтры WordPress могут не влиять на результат. В этом случае нужно искать настройки именно плагина, а не ядра. Не смешивайте два механизма без понимания, какой из них активен.
Ожидали, что noindex уберёт URL из sitemap
Это не всегда так. Некоторые решения исключают noindex-страницы автоматически, но полагаться на это нельзя. Лучше явно убрать ненужный тип или архив из генерации sitemap.
Спрятали важные страницы вместе с мусором
Если вы отключаете целый taxonomy archive, проверьте, не используется ли он как основная посадочная страница. На небольших сайтах тег или рубрика иногда даёт трафик, и удаление из sitemap без анализа может ухудшить обнаружение страниц.
Практические советы по безопасности и производительности
Не редактируйте sitemap-фильтры прямо в боевой теме через FTP без бэкапа. Если код невалиден, можно получить белый экран или сломать генерацию карты сайта. Безопаснее:
- добавлять код в mu-plugin;
- проверять изменения на staging;
- держать правки в git;
- после деплоя сразу пересматривать sitemap и логи ошибок.
Если сайт большой, не пытайтесь решать всё через тяжёлые запросы к базе на каждом открытии sitemap. Фильтры должны быть простыми и предсказуемыми. Чем сложнее логика исключения, тем выше шанс получить медленную генерацию или конфликт с другим плагином.
Для сайтов, где техническая чистка идёт вместе с SEO-настройками, удобно держать под рукой инструменты, которые не мешают ядру WordPress и не подменяют его поведение без необходимости. Но в любом случае итог надо проверять по факту: открыл sitemap, нашёл нужные URL, убедился, что лишние исчезли.