Что должно быть в файле robots.txt для WordPress?

Четыре вещи и ничего больше: строка user-agent со звёздочкой, Disallow для /wp-admin/, Allow для /wp-admin/admin-ajax.php и директива Sitemap с полным адресом карты сайта. Всё остальное необязательно, а большинство длинных блок-листов, гуляющих по интернету, создают больше проблем, чем решают.

WordPress создаёт robots.txt автоматически?

Да, но только виртуальный. WordPress формирует ответ в памяти, когда приходит запрос на /robots.txt и реального файла на диске нет. В нём есть правила для wp-admin, а начиная с версии 5.5 — строка Sitemap для wp-sitemap.xml. На сервер при этом ничего не записывается.

Почему мой robots.txt не совпадает с тем, что должен отдавать WordPress?

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

Нужно ли закрывать wp-content или wp-includes в robots.txt?

Нет. В этих папках лежат CSS, JavaScript и картинки, без которых страница не отрисуется. Закрыв их, вы лишаете Google доступа к этим файлам, и он оценивает сломанную версию вашей вёрстки. Несколько лет назад так советовали, а сейчас это откровенно вредно.

Можно ли с помощью robots.txt убрать страницу из Google?

Нет. robots.txt управляет сканированием, а не индексацией. Закрытый адрес всё равно может попасть в индекс, если на него ссылаются другие страницы, и покажется в выдаче без описания. Чтобы убрать страницу из индекса, наоборот, разрешите сканирование и отдайте мета-тег robots с noindex или заголовок X-Robots-Tag.

robots.txt — это средство защиты?

Нет, скорее наоборот. Файл публичен по адресу yoursite.com/robots.txt, прочитать его может кто угодно, так что упоминание приватной папки — это указатель на неё. Приличные краулеры соблюдают его добровольно, а вредоносные сканеры игнорируют полностью. Закрывайте чувствительные пути аутентификацией или правилами на сервере.

robots.txt для WordPress в 2026 году: что туда действительно нужно писать

Хороший robots.txt для WordPress занимает примерно пять строк. Закройте /wp-admin/, откройте admin-ajax.php, укажите краулерам карту сайта — и на этом всё. Раздутые сорокастрочные блок-листы с форумов в основном ломают рендеринг или не делают вообще ничего. Весь файл целиком:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Замените домен, а если у вас SEO-плагин, который берёт карты сайта на себя, укажите в строке Sitemap его индекс. Вот и всё. Если ваш файл длиннее, лишние строки, скорее всего, чего-то вам стоят.

WordPress уже генерирует его сам — пока вы не создадите реальный файл

WordPress отдаёт виртуальный robots.txt. Когда приходит запрос на /robots.txt, а реального файла в корне сайта нет, WordPress перехватывает запрос и печатает ответ прямо в памяти. На диск ничего не пишется. По умолчанию это блок с wp-admin, показанный выше, плюс строка Sitemap: для wp-sitemap.xml, которую ядро выводит начиная с WordPress 5.5.

Изменить этот вывод могут две вещи. Если в Настройки → Чтение → Попросить поисковые системы не индексировать сайт стоит галочка, WordPress заменяет весь файл на Disallow: /, что закрывает всё. Этот чекбокс — самая частая причина исчезновения сайта из поиска после запуска. Второе: плагины и темы могут менять виртуальный вывод через фильтр robots_txt — именно так SEO-плагины подставляют свои строки с картой сайта и собственные правила.

Теперь то, на чём люди теряют полдня. Физический файл robots.txt в корне сайта молча перекрывает всё вышесказанное. Веб-сервер находит настоящий файл на диске, отдаёт его, и WordPress вообще не загружается. Виртуальный генератор не работает. Фильтр robots_txt не срабатывает. Редактор robots.txt в вашем SEO-плагине при этом может показывать красивый интерфейс с правильными правилами — и ничто из этого до краулера не доходит.

Где живут правила	Редактируется в админке WordPress	Побеждает при живом запросе
Виртуальный (файла на диске нет)	Да, через фильтр `robots_txt` или плагин	Только когда физического файла нет
Физический файл в корне сайта	Только если плагин пишет на диск	Всегда

Поэтому прежде чем что-либо отлаживать: откройте https://yoursite.com/robots.txt в браузере, потом подключитесь по SFTP или через файловый менеджер хостинга и проверьте, не лежит ли настоящий robots.txt рядом с wp-config.php и .htaccess. Если лежит — это и есть ваш robots.txt. Правьте его там либо удалите и отдайте управление WordPress, но выберите что-то одно. Именно от работы «на два фронта» на сайтах остаётся устаревший адрес карты сайта, который никто не может найти.

Почему /wp-admin/ закрыт, а admin-ajax.php открыт

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

admin-ajax.php лежит внутри той же папки, но админ-страницей не является. Это точка входа, через которую плагины и темы обрабатывают AJAX-запросы фронтенда: кнопки «показать ещё», отфильтрованные каталоги товаров, калькуляторы, формы. Если краулер не может её запросить, он не увидит контент, который эти механизмы подгружают, и Google отрисует страницу так, как её видел бы посетитель со сломанной функцией.

Нужно ли Google на вашем конкретном сайте реально запрашивать admin-ajax.php, зависит от того, использует ли его фронтенд. Честный ответ: на многих современных сайтах это вообще не имеет значения, потому что тема работает через REST API по адресу /wp-json/. Строка Allow — дешёвая страховка от вполне реального сценария поломки, а не фактор ранжирования. Оставьте её, потому что она ничего не стоит.

Не закрывайте /wp-content/ и /wp-includes/

Это худший совет по robots.txt из всё ещё гуляющих по сети, и он родом из времён, когда Google не отрисовывал страницы.

В /wp-content/ лежат ваши темы, плагины и загрузки — стили, скрипты и картинки, благодаря которым страницы выглядят страницами. В /wp-includes/ лежит JavaScript ядра, от которого зависят плагины. Google отрисовывает страницы в headless-браузере, прежде чем их оценивать. Закройте эти папки — и рендерер получит страницу без CSS и без изображений. Google будет оценивать неоформленную стену текста со сломанной вёрсткой, а это влияет и на понимание вашего контента, и на оценку удобства для мобильных.

Если вам достался файл с такими строками — удалите их:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Убедиться в ущербе можно самостоятельно в инструменте проверки URL в Google Search Console. Запустите живую проверку любой страницы, посмотрите скриншот отрисовки и загляните в список ресурсов страницы — там будут помечены заблокированные. Если ваш CSS показан как заблокированный, причина именно в этом.

Директива Sitemap

Одна строка, абсолютный адрес, и стоять она может где угодно в файле — к группе User-agent она не привязана.

Sitemap: https://example.com/wp-sitemap.xml

Указывайте адрес, который реально открывается. Ядро WordPress отдаёт wp-sitemap.xml. Большинство SEO-плагинов отключают карты ядра и отдают свой индекс по другому пути, обычно sitemap_index.xml. Откройте свой адрес в браузере, прежде чем вписывать его: строка Sitemap, ведущая на 404, хуже, чем её отсутствие, потому что при аудите выглядит правильной.

Перечислять несколько карт сайта можно, по одной в строке. Отправлять карты через Search Console всё равно стоит отдельно; директива в robots.txt — это способ, которым их находят краулеры, никогда не видевшие вашего аккаунта в Search Console.

robots.txt — это не noindex и не защита

Эти два заблуждения приносят основную часть вреда от robots.txt.

Закрытие адреса не удаляет его из Google. robots.txt управляет сканированием. Если на закрытый адрес ссылается другой сайт, Google может проиндексировать сам адрес — вы получите результат с голой ссылкой и пометкой, что информация недоступна. И есть ловушка похуже: если на странице уже стоит мета-тег noindex, а вы после этого закрыли её в robots.txt, Google не может её просканировать, не видит noindex, и страница может оставаться в индексе бесконечно. Чтобы убрать страницу, разрешите сканирование и отдайте мета-тег robots с noindex в head страницы либо HTTP-заголовок X-Robots-Tag. Директивы noindex внутри robots.txt Google перестал поддерживать в 2019 году.

Закрытие пути не защищает его. Ваш robots.txt публичен по определению. Строка /private-client-files/ сообщает каждому посетителю и каждому сканеру, куда именно смотреть, а соблюдение правил добровольно: Google их уважает, враждебные боты — нет. Всё, что нужно защищать, требует аутентификации, ограничения по IP или правил уровня сервера в .htaccess, а не строки в текстовом файле, которая указывает на цель.

Правила, которые стоит добавить, и те, которые стоит пропустить

Два дополнения действительно полезны на многих сайтах. Закрытие пути результатов поиска не даёт краулерам плодить бесконечные малоценные адреса из вашего внутреннего поиска. Закрытие корзины и оформления заказа на WooCommerce убирает из обхода адреса с параметрами сессии.

Disallow: /?s=
Disallow: /search/

А вот это пропустите:

Crawl-delay — Google игнорирует её полностью. Если у вас реальная проблема с нагрузкой на сервер, используйте настройки частоты обхода в Search Console.
Закрытие /feed/ или /trackback/ — адреса безобидные, а ленты полезны.
Длинные списки отдельных имён ботов — большинство ботов, которых так пытаются закрыть, всё равно не представляются честно.
Закрытие /wp-json/ — вполне возможно, именно через него ваша тема отрисовывает контент.

Соберите файл в генераторе robots.txt для WordPress: он выдаёт минимальную корректную версию и позволяет добавить правила для поиска и магазина, не правя синтаксис руками.

После изменений

Откройте https://yoursite.com/robots.txt напрямую и убедитесь, что отданные байты — это именно то, что вы ожидаете, а не то, что показывает редактор плагина. Затем запустите живую проверку URL в Search Console на обычной странице и проверьте, что ни один CSS- или JavaScript-ресурс не возвращается заблокированным. Google кеширует robots.txt примерно на сутки, так что исправление подействует не мгновенно — но и ошибка тоже. Именно из-за этой задержки стоит проверять внимательно, а не тестировать на живом сайте в надежде подождать.