Если на сайте много тегов, WordPress быстро начинает плодить слабые архивы: на странице один-два поста, заголовок почти не отличается от других, а ценности для поиска мало. В итоге в индекс попадают тонкие страницы, которые размывают структуру сайта и забирают краулинговый бюджет на второстепенные URL. Обычно задача решается не одним действием, а комбинацией: закрыть архивы тегов от индексации, при необходимости удалить их из sitemap и аккуратно убрать уже проиндексированные страницы.
Ниже — практический порядок действий для обычного сайта на WordPress. Он подходит, если теги не несут самостоятельной SEO-ценности и вы хотите оставить их только для навигации внутри сайта.
Когда архивы тегов действительно стоит закрывать
Закрывать все теги подряд имеет смысл не всегда. Если у вас крупный контентный проект, где тег — это полноценная тематическая страница с десятками материалов, описанием и внутренней перелинковкой, такие архивы могут работать как посадочные. Но на большинстве сайтов теги создаются автоматически и быстро превращаются в набор слабых страниц.
Признаки, что архивы тегов лучше убрать из индекса:
- на большинстве тегов 1–3 записи;
- теги дублируют рубрики по смыслу;
- в поиске уже есть страницы тегов, но трафика они не дают;
- в отчётах индексирования много URL с низкой ценностью;
- на сайте есть десятки или сотни тегов, которые никто не поддерживает вручную.
Если тегов немного и они реально помогают пользователю находить материалы, можно не закрывать их полностью, а оставить только самые сильные. Но для типичного сайта с «мусорными» архивами лучше убрать их из индекса целиком.
Самый простой способ: noindex для архивов тегов
Для WordPress самый безопасный вариант — поставить для архивов тегов мета-робот noindex,follow. Тогда поисковик не будет держать такие страницы в индексе, но сможет переходить по ссылкам внутри них. Это обычно лучше, чем полностью закрывать их через robots.txt, потому что поисковик видит страницу и может корректно со временем убрать её из выдачи.
Если у вас установлен SEO-плагин, настройка обычно делается в его интерфейсе. Важно искать именно опцию для архивов тегов, а не для отдельных записей. В большинстве случаев достаточно отключить индексацию таксономии «Метки» или «Tags».
Логика настройки простая: архивы тегов должны остаться доступными для пользователей на сайте, но не должны попадать в индекс. Это и есть нужный режим для тонких страниц.
Что проверить после включения noindex
После сохранения настроек откройте несколько страниц тегов в браузере и посмотрите исходный код страницы. В блоке <head> должен появиться мета-тег с noindex. Если используется SEO-плагин, он обычно добавляет и follow, и это нормально.
Ещё один практический способ проверки — открыть страницу тега и посмотреть, не осталась ли она в XML-карте сайта. Если архивы тегов продолжают попадать в sitemap, поисковик будет получать противоречивые сигналы: с одной стороны, вы просите не индексировать, с другой — явно предлагаете URL для обхода.
Как убрать теги из XML-карты сайта
Если sitemap генерируется SEO-плагином, в нём часто можно отдельно отключить таксономию «Метки». Это полезно даже тогда, когда на страницах уже стоит noindex. Для тонких страниц лучше не оставлять их в карте сайта без необходимости.
Почему это важно: sitemap — это не просто список URL, а подсказка поисковику, какие страницы вы считаете важными. Если туда попадают слабые архивы, вы сами подталкиваете робот обходить их чаще, чем нужно.
После отключения проверьте XML-карту вручную. В ней не должно быть ссылок на архивы тегов. Если карта сайта разбита на несколько файлов, проверьте и основной индекс sitemap, и дочерние файлы.
Если нужно убрать уже проиндексированные страницы
Одного noindex недостаточно, если страницы уже сидят в поиске. Тогда нужно дождаться переобхода, либо ускорить процесс через инструменты поисковой системы. Сама страница должна отдавать корректный ответ и содержать noindex; после этого поисковик постепенно исключит её из индекса.
Если задача срочная, можно:
- обновить sitemap без архивов тегов;
- проверить, что на страницах тегов нет внутренних ссылок с важными анкорами, ведущих на мусорные архивы;
- в панели вебмастера отправить страницу на переобход или запросить удаление URL, если такой инструмент доступен;
- не закрывать эти URL через
robots.txtраньше времени, если они уже в индексе: поисковик может не увидетьnoindexна самой странице.
Последний пункт особенно важен. Если вы сначала запретите обход в robots.txt, а потом попытаетесь убрать URL из индекса, робот может не получить сигнал noindex и страница задержится в выдаче дольше.
Когда имеет смысл закрывать теги через robots.txt
Этот вариант подходит реже. robots.txt полезен, если вы хотите снизить обход совсем ненужных URL и уверены, что они не должны индексироваться вообще. Но для уже проиндексированных архивов тегов это не лучший первый шаг.
Закрытие через robots.txt имеет смысл, когда:
- теги создаются автоматически и не должны даже обходиться;
- на сайте очень много технических или бесполезных архивов;
- вы понимаете, что эти URL не нужны ни в индексе, ни в крауле.
Минус у подхода простой: если страница уже в индексе, поисковик может не увидеть на ней noindex, потому что вы закрыли к ней доступ раньше. Поэтому для большинства сайтов правильнее сначала поставить noindex, а уже потом, если нужно, дополнительно ограничивать обход.
Что делать, если теги нужны пользователям, но не поиску
Это самый частый сценарий. Внутри сайта теги удобны: по ним можно перейти к похожим материалам, собрать записи по теме и упростить навигацию. Но для поиска такие страницы часто бесполезны. В этом случае не нужно удалять теги из интерфейса сайта — достаточно убрать их из индекса и из sitemap.
Хорошая практика здесь такая:
- оставить теги в шаблоне записей и в архивных блоках;
- закрыть архивы тегов от индексации;
- не создавать новые теги без необходимости;
- периодически чистить дублирующие и пустые метки;
- оставить только те теги, которые реально используются как навигация.
Если на сайте уже накопилась большая масса мусорных тегов, сначала закройте их от индексации, а потом постепенно наведите порядок в самих терминах. Это безопаснее, чем массово удалять всё сразу.
Как проверить, что тонкие страницы действительно ушли
После настройки не стоит ограничиваться одной проверкой в админке. Нужен короткий контрольный список:
- на странице тега в исходном коде есть
noindex; - архивы тегов не попадают в XML-карту сайта;
- внутренние ссылки на теги остались только там, где они нужны пользователю;
- в панели вебмастера уменьшается число проиндексированных URL этого типа;
- поиск по сайту и навигация не сломались.
Если после всех изменений теги всё ещё индексируются, обычно причина одна из трёх: настройка не сохранилась, sitemap продолжает их отдавать, либо на сайте есть другой плагин, который переопределяет мета-роботы. В таком случае стоит проверить, какой именно плагин управляет SEO-метками, и не дублируют ли друг друга несколько решений.
Что не стоит делать
Самая частая ошибка — удалять теги из шаблона и одновременно оставлять их в индексе. Тогда пользовательские ссылки ломаются, а поисковик ещё какое-то время видит старые URL. Другая ошибка — закрывать всё через robots.txt без предварительного noindex, если страницы уже были в поиске.
Ещё одна типичная проблема — массовое удаление тегов без проверки, где они используются. Если тег был частью навигации или внутренней перелинковки, его удаление может ухудшить связность сайта. Поэтому безопаснее сначала убрать индексирование и только потом чистить структуру.
Если вам нужен именно инструмент для удаления дублей и лишних страниц на WordPress, в таких задачах часто используют Clearfy Pro: он помогает управлять служебными элементами сайта и закрывать от индексации ненужные архивы. Но сам принцип остаётся тем же — сначала определить, какие архивы тегов действительно лишние, а затем убрать их из индекса и карты сайта.
В итоге рабочая схема для большинства сайтов выглядит так: архивы тегов остаются для пользователей, но получают noindex, исключаются из sitemap и постепенно выводятся из индекса. Это убирает тонкие страницы без риска сломать структуру сайта и не требует радикальной переделки контента.