Как настроить robots.txt в WordPress для закрытия от индексации технических страниц

|

Если сайт на WordPress начал отдавать в поиск мусорные URL, первым делом обычно смотрят не на плагины SEO, а на базовую технику: robots.txt. Но здесь легко сделать хуже — закрыть то, что должно индексироваться, и потерять полезные страницы из обхода.

Ниже разберём рабочий сценарий: какие технические разделы имеет смысл закрывать, как собрать безопасный robots.txt и чем проверить, что он действительно работает.

Когда проблема именно в robots.txt

Сначала стоит убедиться, что речь не о другой причине дублей. robots.txt не удаляет страницы из индекса сам по себе и не заменяет noindex. Он только управляет обходом. Если страница уже в поиске, а вы просто закрыли её в robots, она может ещё долго оставаться в выдаче без переобхода.

Типичные симптомы

  • в индексе есть URL вида /wp-admin/, /wp-json/, ?replytocom=;
  • в отчётах по сканированию много служебных страниц, которые не должны попадать в обход;
  • поисковый робот тратит краулинговый бюджет на архивы, параметры и внутренние служебные разделы;
  • после установки SEO-плагина в robots.txt появились лишние правила, которые конфликтуют с вашей логикой.

Что не стоит закрывать

Не закрывайте в robots.txt CSS, JS и изображения без причины. Современные поисковые системы используют рендеринг, и если им не хватает ресурсов страницы, это может ухудшить понимание контента. Закрывать стоит именно технические и бесполезные для поиска URL, а не всё подряд.

Что обычно закрывают в WordPress

У WordPress есть несколько типовых зон, которые часто не нужны в обходе. Набор зависит от сайта, но базовый список выглядит так:

  • /wp-admin/ — административная часть;
  • /wp-login.php — форма входа;
  • /wp-json/ — REST API, если у вас нет задачи индексировать его ответы;
  • /xmlrpc.php — если XML-RPC не используется;
  • служебные параметры вроде ?replytocom=;
  • внутренние страницы поиска, если они создают мусорные результаты;
  • архивы автора, меток, дат — если они не несут ценности и не нужны в поиске.

Важно: архивы автора и меток лучше закрывать не только через robots, а ещё и через meta robots или настройки SEO-плагина. Для страниц, которые уже попали в индекс, robots.txt сам по себе не всегда достаточно жёсткий инструмент.

Диагностика перед правкой robots.txt

Перед изменением файла проверьте, где он лежит и что уже в нём записано. На большинстве сайтов WordPress файл доступен по адресу /robots.txt, а если физического файла нет, WordPress или SEO-плагин может отдавать виртуальную версию.

Что проверить вручную

  1. Откройте https://ваш-домен/robots.txt в браузере.
  2. Посмотрите, нет ли там правил от SEO-плагина или хостинга.
  3. Проверьте, не закрыт ли случайно wp-content/uploads или другие нужные разделы.
  4. Сравните правила с фактической структурой сайта.

Если у вас уже стоит SEO-плагин, он может генерировать robots.txt автоматически. В этом случае не надо одновременно править и файл на сервере, и настройки плагина без понимания приоритета. Иначе получите две разные версии, а в итоге будет использоваться не та, которую вы ожидали.

Рабочий вариант robots.txt для WordPress

Ниже — аккуратная база, которую можно адаптировать под проект. Она не закрывает лишнего и не ломает доступ к публичным ресурсам.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Disallow: /?replytocom=
Disallow: /*?replytocom=
Disallow: /search/

Sitemap: https://example.com/sitemap_index.xml

Здесь есть несколько важных моментов:

  • Allow: /wp-admin/admin-ajax.php нужен, если фронтенд и плагины используют AJAX-запросы;
  • правило для replytocom помогает убрать дубли комментариев;
  • /search/ имеет смысл только если у вас именно такой формат внутренних поисковых страниц;
  • строка Sitemap должна указывать на реальную карту сайта.

Если нужен более строгий вариант

На некоторых сайтах дополнительно закрывают служебные параметры и архивы, но делать это надо только после проверки структуры URL. Например, если у вас есть пагинация архивов, не стоит случайно закрыть весь раздел через слишком широкое правило.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Disallow: /*?replytocom=
Disallow: /*?s=
Disallow: /author/
Disallow: /tag/
Disallow: /date/

Sitemap: https://example.com/sitemap_index.xml

Этот вариант подходит не всем. Например, если на сайте авторские архивы или метки реально дают трафик, закрывать их не нужно. Сначала смотрите аналитику и Search Console, потом меняйте правила.

Как закрыть robots.txt через код, если файл генерируется WordPress

Если вы хотите управлять содержимым robots.txt из темы или мини-плагина, используйте фильтр robots_txt. Это безопаснее, чем вручную править файл на хостинге, когда WordPress отдаёт виртуальный robots.

<?php
add_filter('robots_txt', function ($output, $public) {
    $lines = [
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /wp-login.php',
        'Disallow: /xmlrpc.php',
        'Disallow: /*?replytocom=',
        'Sitemap: ' . home_url('/sitemap_index.xml'),
    ];

    return implode("\n", $lines) . "\n";
}, 10, 2);

Такой подход удобен, если вы ведёте проект через git и хотите, чтобы правила были частью кода. Но есть нюанс: если SEO-плагин тоже фильтрует robots.txt, надо проверить, кто отдаёт итоговый текст. Иначе вы можете перезаписать чужую логику.

Пошаговая настройка без лишнего риска

  1. Снимите текущую версию robots.txt и сохраните копию.
  2. Определите, какие URL реально создают мусор в индексе или обходе.
  3. Соберите минимальный набор правил, а не «запретить всё служебное».
  4. Добавьте строку с sitemap.
  5. Проверьте файл по адресу /robots.txt.
  6. Отправьте страницу на повторную проверку в Search Console, если меняли важные правила.

Проверка результата после внедрения

Проверять нужно не только сам файл, но и реакцию поисковика. Иначе можно долго думать, что всё настроено, хотя робот продолжает видеть старую версию.

Что проверить руками

  • открывается ли /robots.txt без редиректов и ошибок;
  • есть ли в нём нужная строка Sitemap;
  • не закрыт ли случайно публичный контент;
  • не исчез ли доступ к admin-ajax.php, если он нужен фронтенду;
  • не появились ли в Search Console новые ошибки сканирования после правки.

Как понять, что правило сработало

Если вы закрыли, например, /wp-admin/, проверьте, что робот действительно видит запрет. Для этого достаточно открыть /robots.txt и убедиться, что правило присутствует. Для более точной проверки используйте инструменты для тестирования robots в поисковых панелях. Если страница уже была в индексе, дополнительно смотрите статус переобхода и наличие старых URL в отчётах.

ПодходКогда подходитМинус
Правка robots.txtНужно быстро закрыть обход технических URLНе удаляет уже проиндексированные страницы
Фильтр robots_txt в кодеФайл генерируется WordPress или нужен контроль через gitМожет конфликтовать с SEO-плагином
Настройки SEO-плагинаНужна админская правка без кодаМеньше прозрачности и сложнее отлаживать

Частые ошибки и как их исправить

Закрывают сайт целиком

Самая типичная ошибка — правило Disallow: /. После этого робот не обходит вообще ничего. Если это не staging-сайт, такое правило почти всегда лишнее. Исправление простое: удалите его и проверьте файл заново.

Путают robots.txt и noindex

Если задача — убрать страницу из индекса, а не только из обхода, нужен noindex на самой странице или через SEO-плагин. robots.txt не гарантирует удаление URL из выдачи.

Закрывают CSS и JS

Иногда в robots по старой привычке запрещают папки со статикой. Это мешает рендерингу и может ухудшить оценку страницы. Если нет явной причины, не закрывайте /wp-content/themes/ и /wp-includes/ целиком.

Оставляют два источника правды

Когда часть правил лежит в файле на сервере, а часть — в SEO-плагине, отладка становится бессмысленной. Выберите один способ управления и придерживайтесь его.

Практические советы по безопасности и производительности

Если вы закрываете /wp-login.php и /xmlrpc.php от обхода, это не делает сайт защищённым. Но это убирает лишний шум в логах и уменьшает количество бесполезных запросов от ботов. Для реальной защиты входа используйте ограничение попыток входа, двухфакторную аутентификацию и нормальную политику паролей.

Для производительности полезно держать robots.txt коротким и понятным. Чем больше в нём сложных шаблонов, тем выше шанс ошибиться. Если у вас много дублей, параметров и служебных страниц, иногда проще сначала почистить генерацию URL на уровне темы или плагина, а уже потом дополнять robots.

Если нужен более системный подход к чистке дублей, индексации и техническим настройкам, в проектах на WordPress часто используют инструменты уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=2wp.ru&utm_medium=article&utm_campaign=kak-nastroit-robots-txt-v-wordpress-dlya-zakrytiya-ot-indeksacii-tekhnicheskikh-stranic. Но даже с плагином важно понимать, какие правила он генерирует и зачем.

Мини-чек-лист перед публикацией

  • robots.txt открывается по публичному URL;
  • в нём нет Disallow: / без причины;
  • не закрыты CSS, JS и изображения;
  • есть ссылка на sitemap;
  • проверены wp-admin, wp-login.php, xmlrpc.php и параметры дублей;
  • после правки проверен статус в Search Console или другом инструменте для вебмастеров.

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

⭐⭐⭐⭐⭐