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

Автор: Ирина Крылова | Опубликовано: 04.09.2026

Если на сайте появились служебные разделы, тестовые каталоги, внутренние архивы или страницы, которые не должны тратить краулинговый бюджет, robots.txt — первый файл, который стоит проверить. Но это не кнопка «скрыть от поиска»: он управляет сканированием, а не гарантирует удаление из индекса. Поэтому задача всегда одна и та же — правильно разделить, что можно обходить, а что лучше не отдавать поисковым роботам вообще.

Для WordPress это особенно актуально, когда в корне уже лежат стандартные пути вроде /wp-admin/, /wp-includes/, архивы плагинов, внутренние фильтры, тестовые поддомены или временные директории после миграции. Ниже — рабочая схема: как диагностировать проблему, что именно писать в robots.txt, как проверить результат и где чаще всего ошибаются.

Когда robots.txt действительно нужен

Сначала полезно понять, что вы пытаетесь решить. Если URL уже в индексе, один robots.txt его не уберёт. Если страница должна быть доступна пользователю, но не попадать в поиск, иногда правильнее использовать noindex через мета-тег или заголовок X-Robots-Tag. А robots.txt нужен там, где важно ограничить именно сканирование: закрыть служебные каталоги, уменьшить шум в логах и не тратить обход на мусорные URL.

Типовые сценарии

тестовый сайт или staging, который случайно открыт для роботов;
директории плагинов с публичными файлами, которые не должны обходиться;
внутренние поисковые страницы, фильтры, параметры сортировки;
служебные URL после импорта, миграции или разработки темы;
отдельные каталоги с приватными документами, PDF или выгрузками.

Диагностика: что именно сейчас индексируется и сканируется

Перед правкой файла проверьте, что проблема реальная. В WordPress часто путают три вещи: доступность URL, сканирование и индексирование. Страница может быть открыта в браузере, но не индексироваться. Или наоборот — уже попасть в индекс, хотя robots.txt позже запретил её обход.

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

откройте /robots.txt сайта и посмотрите, не перекрывает ли он важные разделы;
проверьте, нет ли в файле слишком широких правил вроде Disallow: /;
посмотрите в Google Search Console отчёт по страницам и проверку URL;
сравните список служебных URL в логах сервера или в отчётах краулера;
убедитесь, что нужные страницы не закрыты случайно через плагин SEO или хостинговый firewall.

Минимальная проверка через curl

curl -I https://example.com/robots.txt

Ответ должен быть 200 OK, а не редирект на HTML-страницу, не 403 и не 404. Если файл отдается через кэш/CDN, важно проверить именно финальную версию, которую видит бот.

Как правильно написать robots.txt для WordPress

Базовый файл должен быть коротким и понятным. Не стоит копировать случайные шаблоны из старых статей: они часто закрывают слишком много или дублируют правила. Для обычного сайта WordPress достаточно аккуратного набора директив.

Пример безопасной основы

User-agent: *

Disallow: /wp-admin/

Allow: /wp-admin/admin-ajax.php

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

Здесь важно два момента. Во-первых, /wp-admin/ закрывает административную часть, но admin-ajax.php часто нужен фронтенду и плагинам, поэтому его обычно разрешают отдельно. Во-вторых, ссылка на sitemap помогает роботам быстрее находить нужные URL, если карта сайта у вас реально генерируется и доступна.

Как закрыть конкретный приватный каталог

Если у вас есть, например, каталог /private-docs/, добавьте отдельное правило:

User-agent: *

Disallow: /private-docs/

Disallow: /wp-admin/

Allow: /wp-admin/admin-ajax.php

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

Такой подход лучше, чем закрывать весь сайт. Он точечный и не мешает индексации публичных страниц.

Если robots.txt генерируется не вручную

На WordPress robots.txt может отдаваться виртуально, без физического файла в корне. Это нормально, пока вы понимаете, кто его формирует. Часто это делает SEO-плагин, хостинг или кастомный код темы. Если вы правите файл по FTP, а изменения не видны, значит, у вас либо виртуальная генерация, либо кэш на уровне сервера/CDN.

Когда нужен физический файл

Физический robots.txt в корне удобен, если вы хотите полностью контролировать содержимое. Но если его уже генерирует плагин, не стоит держать два источника правды. Сначала выясните, кто отдаёт ответ на запрос /robots.txt, и только потом меняйте логику.

Если нужен программный контроль, можно добавить фильтр в тему или мини-плагин. В WordPress для этого есть хук robots_txt.

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $lines = array(
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /private-docs/',
        'Sitemap: https://example.com/sitemap_index.xml',
    );

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

Такой вариант полезен, если вы хотите централизованно управлять правилами из кода, а не через ручное редактирование файлов. Но если сайт ведётся не разработчиком, проще и безопаснее держать правила в одном понятном месте, чтобы их не потеряли при обновлении темы.

Сравнение подходов: файл, плагин или код

Подход	Когда подходит	Плюсы	Минусы
Физический robots.txt	Нужен полный ручной контроль	Просто проверить, легко передать другому администратору	Можно случайно перезаписать при деплое
Плагин SEO	Уже используется для sitemap и мета-тегов	Удобно в админке, меньше ручной работы	Правила могут меняться после обновлений или настроек
Хук `robots_txt`	Нужна логика из кода	Гибко, можно собирать правила динамически	Требует контроля в репозитории и тестирования

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

Составьте список URL, которые реально не должны сканироваться.
Проверьте, не нужны ли для них не Disallow, а noindex.
Посмотрите, кто сейчас отдаёт /robots.txt: файл, плагин или сервер.
Сделайте резервную копию текущего содержимого.
Добавьте только точечные правила, без широких запретов.
Сохраните sitemap-ссылку, если она у вас используется.
Проверьте ответ curl -I и просмотром самого файла в браузере.
После обновления отправьте robots.txt на повторную проверку в Search Console.

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

Проверка должна быть не по ощущениям, а по факту ответа сервера и поведению робота.

откройте https://site.ru/robots.txt и убедитесь, что там именно ваш текст;
проверьте, что закрытый URL возвращает 200 OK для пользователя, но путь присутствует в Disallow;
в Search Console используйте проверку URL и посмотрите, видит ли бот запрет на сканирование;
если URL уже был в индексе, отслеживайте, как он исчезает только после повторного обхода и/или дополнительных сигналов noindex;
проверьте логи сервера: робот должен перестать активно ходить по закрытым каталогам.

Если цель — убрать именно индексирование, а не только сканирование, одного robots.txt недостаточно. В таком случае для уже опубликованных страниц нужен другой механизм: noindex, удаление ссылки на страницу, либо корректный ответ 404/410 в зависимости от сценария.

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

Слишком широкий запрет

Ошибка выглядит так: Disallow: / или запрет на целые разделы, которые должны индексироваться. В результате поисковик перестаёт обходить важные страницы, а новые материалы не попадают в поиск. Исправление простое: уберите общий запрет и оставьте только точечные каталоги.

Надежда на robots.txt для удаления из индекса

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

Конфликт с SEO-плагином

Иногда плагин генерирует свой robots.txt, а вы редактируете физический файл. В итоге видите одно, а бот получает другое. Решение: оставьте один источник и отключите лишнюю генерацию, если это возможно в настройках плагина.

Закрыт `admin-ajax.php`

Это частая поломка после копирования чужого шаблона. Фронтенд-скрипты и некоторые плагины используют AJAX-запросы, и их нельзя бездумно закрывать. Если в правилах есть Disallow: /wp-admin/, обязательно проверьте разрешение для /wp-admin/admin-ajax.php.

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

Robots.txt не защищает от атак и не скрывает чувствительные данные. Если каталог действительно приватный, его нужно закрывать на уровне доступа: авторизация, basic auth, ограничение по IP, правильные права на файлы. Для производительности robots.txt полезен только как способ уменьшить лишнее сканирование, но не как универсальная оптимизация.

Если на сайте много технических дублей, фильтров и служебных URL, имеет смысл дополнительно почистить SEO-настройки. В таких случаях удобно использовать инструменты, которые помогают убрать лишние архивы, системные страницы и дубли без ручного редактирования каждого шаблона. Например, у Clearfy Pro есть функции для технической чистки WordPress и управления дублями, но применять их стоит только после проверки, какие URL реально нужны вашему сайту.

Что делать, если robots.txt уже сломан

Если после правки сайт начал терять трафик или перестали индексироваться нужные страницы, не пытайтесь «доправить на глаз». Верните предыдущую версию файла, проверьте, не закрыт ли sitemap, и сравните ответ сервера до и после изменения. В WordPress это особенно важно после обновлений темы, SEO-плагина или миграции на другой хостинг: robots.txt может меняться не там, где вы ожидаете.

Самый надёжный порядок такой: сначала понять, кто формирует файл, затем внести точечные правила, потом проверить ответ сервера и только после этого ждать переобхода. Для robots.txt нет магии — только аккуратная настройка и проверка фактического результата.