В WordPress robots.txt часто правят по привычке: копируют готовый шаблон, добавляют пару строк и надеются, что поисковик «сам поймёт». На практике именно здесь появляются ошибки, из-за которых в индекс попадают служебные URL, а нужные страницы начинают обходиться хуже. Если задача — закрыть технические разделы без вреда для SEO, нужен не «красивый» файл, а понятная схема: что запрещаем, что оставляем открытым и как проверяем, что правило реально работает.
Какие страницы обычно стоит закрывать
robots.txt не удаляет URL из индекса и не заменяет noindex. Его задача — управлять обходом. Поэтому закрывают только то, что не должно тратить краулинговый бюджет и не несёт ценности для поиска.
/wp-admin/— административная часть сайта;/wp-includes/— служебные файлы ядра;- служебные параметры и внутренние поисковые страницы, если они создают мусорные URL;
- технические каталоги плагинов, если они доступны по прямым ссылкам и не нужны в выдаче.
Не стоит закрывать в robots.txt CSS и JS, которые нужны для рендеринга страниц. Если поисковик не может загрузить стили и скрипты, он хуже понимает страницу, а это уже мешает индексации и оценке качества.
Диагностика: что именно мешает индексации
Перед правкой robots.txt полезно посмотреть, какие URL реально создаёт сайт. В WordPress источником мусора часто становятся архивы тегов, страницы автора, вложения, параметры сортировки, внутренний поиск и дубли пагинации. Если у вас уже есть статьи про canonical и attachment, это не значит, что robots.txt можно игнорировать: файл нужен для обхода, а не для каноникализации.
Что проверить до изменений
- есть ли в индексе служебные URL из
/wp-admin/или/wp-includes/; - создаёт ли тема или плагин отдельные технические разделы;
- не закрыты ли случайно важные каталоги, например
/wp-content/uploads/; - не блокируются ли файлы статики, без которых страницы отображаются некорректно.
Если сайт уже в поиске, откройте отчёт по страницам в Google Search Console и посмотрите, какие URL попадают в обход и индекс. Это даст более полезную картину, чем правка robots.txt «на глаз».
Рабочая схема robots.txt для WordPress
Базовый файл должен быть коротким и предсказуемым. Не нужно перечислять всё подряд. Ниже — безопасный стартовый вариант, который можно адаптировать под конкретный сайт.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /cgi-bin/
Sitemap: https://example.com/sitemap_index.xmlЗдесь важно два момента. Первый — admin-ajax.php обычно оставляют доступным, потому что его используют темы и плагины на фронтенде. Второй — строка с sitemap помогает поисковику быстрее находить карту сайта, но сама по себе не решает проблемы индексации.
Если нужно закрыть внутренний поиск
У WordPress внутренний поиск часто создаёт бесполезные URL вида /?s=.... Их можно ограничить в robots.txt, но лучше дополнительно проверить, не нужны ли они вам для пользователей и не попадают ли они в sitemap через сторонний плагин.
User-agent: *
Disallow: /?s=
Disallow: /*?s=Такой вариант не идеален для всех серверов и всех поисковиков, поэтому после внедрения обязательно проверьте, как именно ваш сайт отдаёт поисковые URL. Если есть сомнения, лучше решать это на уровне шаблонов и мета-роботов, а не только через robots.txt.
Пошаговое решение: как внести правки без риска
Самый надёжный путь — редактировать robots.txt через файловый доступ или через SEO-плагин, если он действительно управляет этим файлом без конфликтов. Важно не потерять текущие правила, которые могли добавить плагин кеша, карта сайта или защита от ботов.
- Сделайте копию текущего robots.txt.
- Проверьте, не генерируется ли файл автоматически плагином.
- Уберите дублирующиеся и противоречивые правила.
- Оставьте только те запреты, которые реально нужны.
- Сохраните файл и сразу проверьте ответ сервера.
Если вы работаете через код, можно отдать статический файл из корня сайта. Для WordPress это обычно проще, чем пытаться собирать robots.txt на лету без необходимости.
<?php
// Пример: если нужно сгенерировать robots.txt через хук robots_txt.
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-includes/',
'Sitemap: https://example.com/sitemap_index.xml',
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Этот вариант подходит, если вы точно понимаете, что файл должен формироваться программно. Но если сайт уже использует SEO-плагин, сначала проверьте, не перезапишет ли он ваш код или наоборот.
Сравнение подходов: плагин, файл или код
| Подход | Когда уместен | Минус |
|---|---|---|
| Ручной robots.txt в корне | Нужен простой и прозрачный контроль | Можно случайно потерять правила после деплоя |
| SEO-плагин | Файл уже управляется из админки | Риск конфликтов с другими плагинами |
Хук robots_txt | Нужна генерация на уровне кода | Сложнее сопровождать без разработчика |
Если сайт небольшой, обычно достаточно ручного файла. Если проект с несколькими ролями и нестандартной логикой, удобнее держать правила в коде или в одном SEO-инструменте, а не размазывать их по нескольким плагинам.
Проверка результата после внедрения
После сохранения robots.txt не ограничивайтесь открытием файла в браузере. Нужна проверка ответа сервера и фактического поведения поискового робота.
- откройте
/robots.txtи убедитесь, что файл отдается без редиректов и ошибок; - проверьте, что в нём нет лишних
Disallowдля важных разделов; - в Search Console используйте проверку robots.txt, если она доступна в вашем наборе инструментов;
- посмотрите логи сервера, если нужно понять, какие URL реально обходятся ботом;
- проверьте, не исчезли ли из обхода CSS и JS, нужные для рендеринга.
Если после правки страницы продолжают попадать в индекс, причина, скорее всего, не в robots.txt. Тогда нужно смотреть canonical, мета-robots, sitemap и внутренние ссылки. robots.txt здесь только ограничивает обход, но не управляет индексацией напрямую.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить целые каталоги темы или плагина, а потом обнаружить, что сайт стал рендериться без стилей или скриптов. Исправление простое: уберите лишние Disallow и проверьте, какие файлы нужны фронтенду.
Пытаются убрать страницы из индекса только через robots.txt
Если URL уже в поиске, одного запрета на обход недостаточно. Для удаления из индекса обычно нужен noindex или корректный canonical, а robots.txt — лишь вспомогательный слой.
Конфликтуют правила плагина и ручного файла
Иногда SEO-плагин генерирует свой robots.txt, а вы редактируете физический файл в корне. В итоге поисковик видит не то, что вы ожидаете. Проверьте, какой источник реально отдаёт /robots.txt, и оставьте только один способ управления.
Закрыли sitemap
Карта сайта должна быть доступна поисковику. Если она случайно попала под запрет, индексация новых страниц может замедлиться. Sitemap лучше оставлять открытым и просто указывать на него в robots.txt.
Практические советы по безопасности и производительности
robots.txt не защищает сайт от атак, поэтому не используйте его как замену реальной безопасности. Админку защищают правами доступа, двухфакторной аутентификацией, ограничением логинов и обновлениями. Для производительности же важнее не перегружать файл десятками правил, которые потом никто не поддерживает.
- держите robots.txt коротким и читаемым;
- не копируйте чужие шаблоны без проверки структуры сайта;
- не блокируйте ресурсы, нужные для отображения страницы;
- после обновления темы или SEO-плагина перепроверяйте файл;
- если используете несколько плагинов для SEO и кеша, убедитесь, что они не спорят за генерацию robots.txt.
Если вам нужен более широкий технический аудит WordPress — от дублей и индексации до чистки служебных страниц — такие задачи удобнее закрывать одним инструментом, а не набором разрозненных правок. В этом сценарии часто используют Clearfy Pro: он помогает убирать часть технического шума и упрощает контроль над SEO-настройками, но всё равно требует ручной проверки после изменений.
Главная проверка здесь простая: откройте /robots.txt, сравните его с тем, что вы планировали, и убедитесь, что поисковик видит только нужные ограничения. Если это так, значит файл работает как инструмент, а не как источник новых проблем.