Ситуация типовая: сайт уже живёт, sitemap включён, а в поисковую выдачу начинают попадать служебные URL, архивы, тестовые CPT или страницы, которые вообще не должны индексироваться. Самый частый ответ — «отключить sitemap целиком». Это грубый вариант: он убирает карту сайта, но не решает проблему структуры. Правильнее точечно исключить лишние сущности и оставить в карте только то, что реально нужно поисковику.
Когда sitemap нужно чистить точечно
Не каждый URL должен попадать в XML sitemap. Если в карте есть страницы с фильтрами, внутренние типы записей, черновые разделы или архивы без ценности, поисковик тратит краулинговый бюджет на мусор. Это особенно заметно на сайтах с большим количеством таксономий, кастомных типов записей и шаблонных страниц.
Проверять нужно не только наличие URL в карте, но и логику: индексируется ли этот тип, нужен ли он в поиске, не дублирует ли он основной контент. Если страница закрыта от индексации через noindex, но всё ещё торчит в sitemap, это плохой сигнал для диагностики: карта и мета-указания начинают спорить друг с другом.
Диагностика проблемы перед правкой
Сначала посмотрите, что именно попадает в sitemap. Если используется встроенный XML sitemap WordPress, откройте /wp-sitemap.xml. Если карту генерирует SEO-плагин, проверьте его отдельный sitemap index. Важно понять, кто именно формирует карту: ядро, SEO-плагин или код темы.
Что проверить вручную
- есть ли в sitemap типы записей, которые не должны индексироваться;
- попадают ли туда архивы авторов, дат, тегов или служебные таксономии;
- не дублируются ли одни и те же URL в нескольких sitemap;
- совпадает ли содержимое sitemap с настройками
noindexи каноникалами; - не возвращает ли страница sitemap ошибку 404 или пустой ответ после правок.
Если у вас уже есть SEO-плагин, сначала проверьте его настройки. Во многих случаях проще отключить лишний тип записи в интерфейсе плагина, чем писать код. Но если нужна точечная логика, код надёжнее и прозрачнее.
Как убрать отдельный тип записей из XML sitemap через код
Встроенный sitemap WordPress можно фильтровать через wp_sitemaps_post_types. Это рабочий способ убрать конкретный тип записей из карты, не отключая sitemap целиком.
<?php
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
// Убираем служебный тип записей из sitemap.
unset( $post_types['portfolio'] );
// Если нужно, можно убрать ещё один тип.
unset( $post_types['landing'] );
return $post_types;
} );Код можно добавить в functions.php дочерней темы или в небольшой mu-plugin. Для продакшена mu-plugin обычно удобнее: он не зависит от темы и не исчезнет при обновлении шаблона.
Как убрать таксономии из sitemap
Если проблема не в записях, а в таксономиях, используйте фильтр wp_sitemaps_taxonomies. Это полезно, когда в карту попадают теги, служебные рубрики или внутренние классификаторы без поисковой ценности.
<?php
add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
unset( $taxonomies['post_tag'] );
unset( $taxonomies['internal_topic'] );
return $taxonomies;
} );Если вы используете SEO-плагин, у него могут быть собственные фильтры и настройки. Но логика остаётся той же: сначала исключаете сущность из генерации карты, потом проверяете, не остались ли на неё ссылки из других sitemap.
Сравнение вариантов: плагин, код или смешанный подход
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Настройки SEO-плагина | Нужно быстро убрать типы записей без разработки | Просто и наглядно | Не всегда хватает точности |
| Код через фильтры WordPress | Нужна точечная логика по типам и таксономиям | Контроль и предсказуемость | Нужно аккуратно тестировать |
| Смешанный вариант | Часть сущностей убирается в плагине, часть — кодом | Гибкость | Легко запутаться в источниках правил |
Если сайт поддерживает несколько редакторов или разработчиков, лучше зафиксировать правило в одном месте. Иначе через пару месяцев никто не вспомнит, почему один тип скрыт в плагине, а другой — через фильтр в теме.
Пошаговое решение без лишнего риска
- Определите, кто генерирует sitemap: ядро WordPress или SEO-плагин.
- Составьте список типов записей и таксономий, которые не должны индексироваться.
- Сначала отключите лишнее в настройках плагина, если это возможно.
- Если настройки не дают нужной точности, добавьте фильтры в код.
- Очистите кеш сайта и, если есть, серверный кеш или CDN.
- Проверьте итоговый sitemap вручную и через инструменты для вебмастеров.
Если у вас есть отдельный sitemap index, проверьте не только главную карту, но и дочерние файлы. Иногда тип записи убрали из индекса, но его старый sitemap-файл ещё отдаётся из кеша или остался в поисковой консоли.
Как проверить, что всё сработало
После внедрения откройте sitemap в браузере и убедитесь, что лишний тип записей исчез. Затем проверьте HTTP-ответ: карта должна отдавать 200 OK, а не редирект или ошибку. Если используется SEO-плагин, убедитесь, что его sitemap index обновился и не ссылается на старые файлы.
Дальше проверьте несколько URL вручную:
- страницы нужного типа всё ещё присутствуют в sitemap;
- убранные типы больше не перечисляются;
- архивы и таксономии не возвращаются в карте через другой источник;
- в Search Console или аналогичном сервисе нет новых ошибок по sitemap.
Если есть доступ к серверным логам, полезно посмотреть, не продолжает ли бот ходить по старым sitemap-файлам. Это помогает понять, не остался ли где-то кеш или старый URL в индексе.
Частые ошибки и как их исправить
Убрали тип записей из sitemap, но он всё ещё индексируется
Это нормально: исключение из sitemap не удаляет URL из индекса мгновенно. Если страница должна исчезнуть из поиска, дополнительно проверьте noindex, внутренние ссылки и каноникал. Иногда URL держится в индексе только потому, что на него активно ссылаются из меню или связанных материалов.
Отключили sitemap целиком вместо точечной правки
Так делают, когда не хотят разбираться в структуре. В результате теряется полезная карта для нормальных страниц, а проблема мусорных URL остаётся решённой лишь частично. Лучше убрать только лишние сущности.
Правка в теме слетела после обновления
Если код добавили прямо в functions.php родительской темы, обновление может его перезаписать. Для постоянной логики используйте дочернюю тему или mu-plugin.
Кеш мешает увидеть изменения
После правки sitemap часто продолжает отдавать старую версию из кеша. Очистите кеш плагина, серверный кеш и CDN, если он есть. Без этого легко сделать ложный вывод, что фильтр не работает.
Безопасность и производительность
С точки зрения производительности фильтрация sitemap почти не нагружает сайт, если вы не строите сложную логику на каждом запросе. Не стоит делать в фильтре тяжёлые запросы к базе или внешним API. Задача здесь простая: убрать лишнее на этапе генерации.
С точки зрения безопасности важно не открывать в sitemap то, что должно быть скрыто. Если в карту попадают служебные страницы, тестовые разделы или внутренние архивы, вы сами подсказываете поисковику, что на сайте есть лишние точки входа. Для закрытых разделов лучше использовать нормальную комбинацию: отсутствие ссылки, noindex там, где это уместно, и исключение из sitemap.
Если на сайте много технического мусора, иногда проще сначала навести порядок в структуре, а потом уже править карту. Для чистки дублей и технических хвостов в экосистеме WordPress часто используют Clearfy Pro, но даже с ним полезно понимать, какие именно сущности вы убираете и почему: автоматическая настройка без проверки легко прячет не то, что нужно.
Когда лучше не трогать sitemap кодом
Если у вас нет доступа к теме, нет уверенности в источнике генерации карты или сайт поддерживается через SEO-плагин с понятными настройками, сначала используйте штатный интерфейс. Код нужен там, где требуется точная логика и повторяемость. Если задача решается галочкой в плагине, это обычно безопаснее для команды без разработчика.
Но если проблема повторяется после каждого обновления плагина или темы, кодовый фильтр надёжнее. Он не зависит от интерфейса и не исчезает после очередной миграции настроек.