Ржанский Д.
Связаться

Нужно ли закрывать папки /feed/ и /wp-json/ от индексации в robots.txt?

Почему Disallow не гарантирует исключение URL из поиска, как WordPress обрабатывает REST API и чем корректно закрывать RSS- и Atom-ленты.

Дмитрий Ржанский Дмитрий Ржанский 1 просмотров

Закрывать /wp-json/ и /feed/ в robots.txt по умолчанию не нужно. Для /wp-json/ это обычно избыточно: WordPress Core уже отправляет для REST API заголовок X-Robots-Tag: noindex. Для RSS- и Atom-лент решение зависит от цели: если требуется исключить их из поиска, корректнее оставить URL доступными для сканирования и добавить X-Robots-Tag: noindex; robots.txt следует использовать только при подтверждённой необходимости сократить обход этих URL.

Почему robots.txt не решает задачу деиндексации

Disallow управляет сканированием: он просит робота не загружать URL. Это не гарантирует удаление адреса из индекса. Google прямо указывает, что заблокированный URL может появиться в результатах, если поисковик обнаружил его по ссылкам. Яндекс также предупреждает, что закрытые в robots.txt страницы могут участвовать в поиске.

Для исключения URL из поиска нужен noindex. У HTML-страниц это может быть <meta name="robots" content="noindex">; для XML- и JSON-ответов удобнее HTTP-заголовок:

X-Robots-Tag: noindex

Робот должен получить ответ, чтобы прочитать заголовок. Поэтому сочетание Disallow и X-Robots-Tag: noindex создаёт конфликт: запрет обхода мешает поисковику увидеть запрет индексирования. Это правило документировано и Google, и Яндексом.

Что делать с /wp-json/

В WordPress /wp-json/ — не физическая папка на сервере, а пространство REST-маршрутов, через которое WordPress, темы, плагины и внешние приложения получают JSON-данные. REST API используется редактором блоков и может применяться интерактивными фронтендами и интеграциями.

WordPress Core отправляет на REST-ответах:

X-Robots-Tag: noindex

Соответствующая инструкция присутствует в текущем исходном коде WP_REST_Server. Она была добавлена в ядро WordPress в 2016 году специально для предотвращения индексирования REST-ответов.

Поэтому базовое решение:

User-agent: *
# Disallow: /wp-json/ — не добавлять

Сначала проверьте фактический ответ сайта:

curl -I https://example.com/wp-json/

В заголовках должно быть:

X-Robots-Tag: noindex

Если заголовок отсутствует, проблема находится не в robots.txt: фактический HTTP-ответ отличается от стандартного поведения WordPress. Нужно восстановить X-Robots-Tag: noindex на уровне WordPress, сервера, прокси или CDN.

Закрытие /wp-json/ не защищает данные. robots.txt доступен публично и не является механизмом контроля доступа. Непубличные данные должны защищаться авторизацией, проверкой разрешений REST-маршрутов и серверными средствами. WordPress отдельно указывает, что публичный контент обычно доступен через REST API, тогда как приватные и защищённые данные требуют аутентификации.

Запрет обхода /wp-json/ также может быть нежелателен, если индексируемый фронтенд получает часть контента через REST API.

Что делать с /feed/

WordPress создаёт несколько типов RSS- и Atom-лент: общую ленту записей, общую ленту комментариев, ленты рубрик, меток, авторов и отдельных записей. Типичные адреса включают:

/feed/
/comments/feed/
/category/news/feed/
/post-name/feed/

WordPress также поддерживает варианты с параметром feed, например ?feed=rss2.

Следовательно, правило:

Disallow: /feed/

закрывает только URL, путь которых начинается с /feed/. Оно не охватывает /comments/feed/, /category/news/feed/ или /post-name/feed/. По стандарту Robots Exclusion Protocol сопоставление начинается с начала пути URL.

На большинстве небольших и средних сайтов ленты можно оставить открытыми. Они являются штатной функцией WordPress и используются RSS-ридерами и интеграциями. Сам факт существования feed-URL не доказывает проблему с краулинговым бюджетом. Google относит расширенное управление crawl budget преимущественно к крупным и быстро обновляемым сайтам.

Если ленты появляются в поиске и не должны там находиться, добавьте для feed-ответов X-Robots-Tag: noindex. В текущей обработке feed-запросов WordPress Core задаёт Content-Type, Last-Modified и ETag, но не добавляет общий X-Robots-Tag: noindex для всех лент.

Минимальный вариант для MU-плагина или кода проекта:

<?php

add_action( 'send_headers', static function (): void {
    if ( is_feed() ) {
        header( 'X-Robots-Tag: noindex', true );
    }
}, 99 );

Хук send_headers предназначен для отправки дополнительных HTTP-заголовков.

После внедрения не закрывайте эти URL в robots.txt, пока поисковые системы не перечитают заголовок и не исключат известные адреса из результатов. Иначе робот не сможет увидеть noindex.

Когда Disallow всё-таки оправдан

Запрет обхода feed-URL может быть оправдан на крупном или часто обновляемом сайте, если серверные логи и отчёты Google Search Console показывают значительный объём бесполезных запросов к лентам и это мешает обработке важных URL.

Google указывает, что расширенная оптимизация краулингового бюджета прежде всего актуальна для:

  • сайтов примерно от миллиона URL с регулярно изменяемым контентом;

  • сайтов примерно от 10 000 URL с ежедневными изменениями;

  • сайтов с большим количеством URL в статусе Discovered — currently not indexed.

Эти значения названы ориентировочными, а не точными порогами.

Последовательность действий в таком сценарии:

  1. Добавить X-Robots-Tag: noindex на feed-ответы.

  2. Дождаться переобхода и исключения уже известных feed-URL.

  3. Определить реальные шаблоны лент по access-логам.

  4. Добавить узкие правила Disallow для подтверждённых шаблонов.

  5. Проверить, что не заблокированы REST-запросы или ресурсы, необходимые фронтенду.

Не следует копировать универсальный WordPress-шаблон robots.txt: набор URL зависит от структуры постоянных ссылок, плагинов, типов записей и фактического поведения краулеров.

Как проверить результат

Проверьте несколько URL:

curl -I https://example.com/wp-json/
curl -I https://example.com/feed/
curl -I https://example.com/comments/feed/
curl -I https://example.com/category/news/feed/

Контролируйте:

  • HTTP-статус;

  • Content-Type;

  • наличие X-Robots-Tag: noindex;

  • отсутствие непредусмотренных редиректов;

  • доступность REST API для функций сайта.

В Google используйте проверку URL и отчёт об индексировании страниц. В Яндекс Вебмастере проверьте обработку правил через анализ robots.txt и инструменты индексирования. Обычный оператор site: не следует использовать как единственное доказательство окончательной деиндексации.

Критерий корректной настройки: REST API продолжает работать, feed-URL отвечают штатно, нежелательные XML- и JSON-ответы содержат X-Robots-Tag: noindex, а robots.txt не мешает поисковику прочитать этот заголовок.

Разобрать проблему на вашем сайте

Опишите проблему — найду вероятную причину и предложу понятный план исправлений без лишних работ.

Связаться