В 2026 году robots.txt уже давно перестал быть просто файлом для поисковых роботов. Я у себя на проектах вижу, что через него до сих пор пытаются управлять не только Googlebot и YandexBot, но и целым зоопарком AI-crawlers: GPTBot, ClaudeBot, PerplexityBot, Amazonbot, Bytespider, Meta-ExternalAgent и ещё десятком менее известных. И вот тут начинается путаница: одни боты нужны, другие только жрут ресурсы, третьих лучше пускать выборочно. Грубо говоря, robots.txt сегодня — это не “для SEO”, а уже часть технической политики сайта.
На моей практике самый частый косяк — когда файл либо закрывает вообще всех подряд, либо наоборот оставляет сайт открытым для агрессивных краулеров, которые могут делать сотни тысяч запросов в сутки. Особенно это чувствуется на WordPress с тяжёлыми плагинами, на Bitrix с нестандартными фильтрами и на Laravel-проектах с большим количеством динамики. Если у вас сайт на WordPress или нужна поддержка Bitrix, я бы советовал к robots.txt относиться так же серьёзно, как к настройке кеша или HTTPS-редиректов.
Зачем в 2026 году вообще нужен robots.txt для AI-crawlers
Честно говоря, сам robots.txt не даёт железобетонной защиты. Это не firewall и не auth-слой. Но он остаётся первым и самым простым сигналом для большинства честных ботов. И для поисковиков, и для AI-краулеров, которые собирают данные для обучения, ответов, индексации или генерации кратких карточек, этот файл — первое место, куда они смотрят.
Почему это важно именно сейчас? Потому что AI-crawlers стали вести себя как отдельный класс нагрузки. Раньше вы могли видеть в логах в основном Googlebot, YandexBot и пару парсеров. А теперь у одного клиента на сайте с PHP 8.2 и MySQL 8.0 я за неделю увидел больше запросов от ClaudeBot и GPTBot, чем от обычных поисковых роботов. В результате выросла нагрузка на БД, а PageSpeed на мобайле просел с 82 до 61 просто потому, что сервер начал чаще уходить в пиковые задержки.
И ещё момент. Многие AI-сервисы не просто читают страницы, а массово обходят сайт заново, особенно если контент часто обновляется. Если у вас есть статьи, товары, фильтры, документация, FAQ и ленты обновлений, то без нормальной настройки robots.txt и sitemap-стратегии сайт может быстро превратиться в источник лишней нагрузки. Тут очень в тему будет моя статья про XML sitemap для SEO и про анализ логов сайта.
Какие боты стоит учитывать в 2026 году
Я обычно делю ботов на три группы. Первая — поисковые: Googlebot, YandexBot, Bingbot. Вторая — AI-crawlers и ассистенты: GPTBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Perplexity-User, Meta-ExternalAgent, Bytespider, Amazonbot, CCBot. Третья — мусор: парсеры, спам-боты, скрипты, которые маскируются под “нормальных” клиентов.
Важно понимать, что не все AI-краулеры одинаковые. Одни приходят за контентом для обучения моделей, другие — для поиска ответов, третьи — для построения сниппетов и генерации цитат. На практике я советую сначала определить, что вы хотите: полностью закрыться, разрешить только часть разделов, или пускать ботов к публичному контенту, но не к PDF, архивам, параметрам фильтрации и внутренним API.
Если у вас, например, интернет-магазин, однозначно стоит закрывать от лишнего обхода корзину, кабинет, поиск по параметрам, страницы с бесконечной фасетной навигацией и все технические URL. Кстати, если ещё не делали это системно, посмотрите статью про SEO-фильтры и faceted navigation. Там хорошо видно, почему роботам нельзя отдавать всё подряд.
Базовая структура robots.txt для сайта в 2026
Классический robots.txt в 2026 году всё ещё строится на тех же элементах: User-agent, Allow, Disallow, Sitemap. Но нюансов стало больше. Например, многие забывают, что для некоторых ботов можно задавать отдельные правила, а для всех остальных — общий блок. Это уже не просто “разрешить/запретить”, а настройка приоритетов.
Я обычно начинаю с базового файла, а потом добавляю отдельные секции под поисковики и AI-краулеры. Вот рабочий пример, который можно взять за основу и адаптировать под WordPress, Bitrix или Laravel:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /bitrix/admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search/
Disallow: /filter/
Disallow: /?*
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xml
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Bingbot
Allow: /
User-agent: Googlebot
Allow: /Этот вариант жёсткий. Он подходит, если вы не хотите, чтобы AI-компании использовали ваш контент. Но на деле я редко ставлю полный запрет всем подряд. Для контентных сайтов лучше делать более тонкую схему: разрешать поисковикам, ограничивать AI-crawlers, закрывать служебные разделы и технические страницы.
Если у вас проект на Laravel или кастомной CMS, я ещё советую добавить отдельные правила под служебные префиксы: /api/, /admin/, /storage/, /tmp/, /debug/. И да, не забывайте о редиректах и каноникалах. Статьи про 301-редиректы и про HTTPS-редиректы и HSTS здесь очень к месту, потому что кривые URL-цепочки в логах потом превращаются в кашу.
Как закрыть или ограничить AI-crawlers точно и без лишней паники
Самый частый вопрос от клиентов звучит так: “Павел, а можно вообще запретить всем AI-ботам заходить на сайт?” Можно. Но я всегда спрашиваю: вы точно хотите закрыть весь публичный контент? Потому что если у вас контентный проект, блог или медиа, AI-crawlers иногда дают дополнительный трафик через упоминания и цитирования. А вот если это корпоративный сайт, закрытая база знаний или коммерческий каталог, запрет часто вполне оправдан.
На практике я делаю так: для GPTBot, ClaudeBot, PerplexityBot и подобных — отдельные блоки. Для поисковиков — отдельные правила. Для “подозрительных” ботов, которые маскируются, уже подключаю nginx, rate limiting и иногда fail2ban. Тут robots.txt — только первый слой. Реальную нагрузку и безопасность лучше разруливать комплексно, особенно если сайт уже посещаемый. У меня был клиент на Bitrix с трафиком около 180 тысяч визитов в месяц, и один только PerplexityBot умудрялся съедать до 12% CPU в пиковые часы. После настройки robots.txt, кеша и лимитов запросов ситуация заметно улучшилась.
Вот пример более мягкой конфигурации:
User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /tmp/
Disallow: /search?
Disallow: /*?sort=
Disallow: /*?filter=
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: PerplexityBot
Disallow: /private/
Disallow: /admin/
Allow: /blog/
Allow: /articles/
User-agent: Googlebot
Allow: /
User-agent: YandexBot
Allow: /Если у вас WordPress, я ещё часто закрываю от AI-ботов служебные пути плагинов, автогенерируемые медиассылки и вложения, если они не несут самостоятельной ценности. Если Bitrix — обязательно смотрю на /bitrix/cache/, /bitrix/managed_cache/ и административную часть. И да, если вы делаете доработки самостоятельно, лучше свериться с гайдом по доработке сайта, чтобы не сломать публичную индексацию вместе с защитой.
robots.txt для WordPress, Bitrix и Laravel: как я делаю на практике
На WordPress всё обычно упирается в wp-admin, wp-login.php, xmlrpc.php и служебные параметры. Я однозначно советую закрывать XML-RPC, если он вам не нужен. Отдельно это разбирал в статье про защиту wp-login и xmlrpc. AI-боты туда обычно не лезут, но общая гигиена от лишнего трафика и брутфорса сильно помогает.
Для Bitrix картина другая. Там надо учитывать не только /bitrix/admin/, но и динамические URL, фильтры, поиск, личный кабинет, корзину. Ещё я нередко смотрю на интеграции с CRM, потому что когда сайт активно обменивается данными через API, лишние обходы увеличивают нагрузку. Если интересно, у меня есть отдельная статья про интеграцию CRM с сайтом.
Для Laravel обычно всё проще в плане публичной структуры, но сложнее в плане API, JSON-эндпоинтов, служебных роутов и SPA-приложений. Тут robots.txt должен быть аккуратным: не закрыть лишнее и не забыть про /storage/, /bootstrap/cache/, /vendor/ — хотя эти папки и так не должны быть доступны снаружи при нормальной настройке сервера. Если у вас есть staging-среда, её лучше закрывать вообще полностью, а не надеяться на robots.txt. Я об этом подробно писал в материале про staging-сайт.
Из моей практики: на одном интернет-магазине на WordPress с PHP 8.3 и Redis-кешем мы добились снижения количества бесполезных обращений к серверу примерно на 28% только за счёт нормального robots.txt и закрытия нескольких краулеров. Но самое смешное, что основной эффект дал не запрет GPTBot, а отсечение бесконечных search-параметров и служебных страниц. То есть люди часто ищут “великое решение”, а выигрывают на банальной дисциплине.
Nginx, Apache и заголовки: когда robots.txt уже мало
Если бот агрессивный или просто тупо игнорирует правила, robots.txt не спасёт. Тогда я иду на уровень nginx или Apache. Это особенно актуально для AI-crawlers, которые могут делать очень частые запросы. В таких случаях помогает rate limiting, отдельные локации и иногда даже возврат 403 или 429 для конкретных user-agent.
Вот рабочий пример для nginx, когда вы хотите ограничить подозрительные боты и не перегружать сайт:
map $http_user_agent $block_ai_bot {
default 0;
~*GPTBot 1;
~*ClaudeBot 1;
~*PerplexityBot 1;
~*Bytespider 1;
}
server {
listen 443 ssl http2;
server_name example.com;
if ($block_ai_bot) {
return 403;
}
location / {
limit_req zone=one burst=20 nodelay;
try_files $uri $uri/ /index.php?$args;
}
location = /robots.txt {
add_header Content-Type text/plain;
}
}Да, я знаю, что многие не любят if в nginx. И правильно делают, если используют его бездумно. Но для простого кейса с user-agent он работает нормально. Если хотите совсем чисто, можно вынести логику в map и отдельные location-блоки. А ещё лучше — комбинировать с rate limiting и firewall.
Для Apache иногда достаточно жёсткого robots.txt, но если бот наглый, я добавляю правила в .htaccess. Например, можно заблокировать конкретные user-agent так:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} GPTBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ClaudeBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} PerplexityBot [NC]
RewriteRule .* - [F,L]Ещё один момент: если у вас стоят CDN и кеширующие прокси, проверьте, не отдаёте ли вы robots.txt из старого кеша. Был случай, когда клиент месяц жил со старой версией файла после правок. На CDN всё кэшировалось по 24 часа, а robots.txt вообще обновлялся раз в сутки. В итоге Google и Яндекс видели старые инструкции, а команда думала, что “мы всё уже поменяли”. На деле — нет. Тут помогает и контроль заголовков, и грамотная настройка CDN. У меня есть статья про CDN и про кеширование статических файлов.
Типичные ошибки при настройке robots.txt в 2026
Самая грубая ошибка — закрыть весь сайт через Disallow: / и забыть об этом на проде. Такое я видел не раз, и это всегда оборачивается падением видимости. Вторая ошибка — надеяться, что robots.txt спрячет личные данные, закрытую документацию или тестовый контент. Не спрячет. Если URL попал в индекс или его знает кто-то извне, он может быть доступен по ссылке, через sitemap, через историю браузера, через кэш. Тут нужна полноценная защита, а не косметика.
Третья ошибка — хаотично копировать чужие файлы. У одного клиента я увидел robots.txt, скопированный из Shopify, хотя сайт был на Bitrix. Там были бессмысленные блоки и запреты для путей, которых на проекте вообще не существовало. И самое смешное, что вместе с этим случайно запретили индексацию полезных разделов. Пришлось вручную пересобирать правила, проверять логи и заново отправлять сайт на переобход.
Четвёртая ошибка — не проверять синтаксис. Одна лишняя звёздочка, неправильно поставленный слэш, отсутствие перевода строки или дублирующийся блок User-agent могут изменить логику целиком. И да, разные боты интерпретируют файл не одинаково. Что-то проглотит Google, а что-то проигнорирует Yandex. Поэтому я всегда тестирую файл отдельно, потом смотрю логи, потом уже выкатываю в прод.
Как проверить, что всё работает, и не сломать индексацию
После настройки я обычно делаю три проверки. Первая — открываю robots.txt в браузере и смотрю, отдаётся ли он с правильным кодом 200 и без редиректов. Вторая — проверяю его через инструменты для вебмастеров. Третья — смотрю логи сервера. И вот последний шаг самый важный, потому что только там видно, кто реально приходит, с каким user-agent и с какой частотой.
Если сайт крупный, я вообще советую завести отдельный мониторинг для robots.txt. Это можно сделать через cron, Uptime Robot или любой другой чекер. Если файл вдруг изменится после деплоя или миграции, вы должны узнать об этом сразу. У меня был случай, когда после переноса сайта на новый хостинг robots.txt вернулся к дефолтному файлу CMS. Индексация не умерла, но за две недели ботам открыли служебные URL, и потом пришлось разгребать последствия. На такие вещи отлично ложится правильная миграция сайта и мониторинг uptime.
Я ещё советую периодически проверять файл после обновлений CMS. Для WordPress — после обновления ядра и плагинов. Для Bitrix — после модулей и патчей. Для Laravel — после деплоя и изменения nginx-конфига. Если у вас есть CI/CD, можно вообще хранить robots.txt в репозитории и доставлять его вместе с кодом. Это дисциплина, а не паранойя.
Кстати, когда работаю с клиентами на поддержке, я часто вижу одну и ту же картину: в dev/staging robots.txt закрыт, а на проде уже нет. Или наоборот. Поэтому я всегда советую держать разные конфиги для окружений и не полагаться на память. Если нужна системная доработка сайта под SEO и технику, это лучше делать один раз нормально, чем потом чинить на ходу.
Практический шаблон robots.txt на 2026 год
Ниже я дам универсальный шаблон, который можно взять за основу. Он не идеален для всех проектов, но для большинства корпоративных сайтов, блогов и интернет-магазинов подходит хорошо. Потом вы его уже подгоняете под свою CMS, структуру URL и политику по AI-crawlers.
User-agent: *
Disallow: /admin/
Disallow: /bitrix/admin/
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Disallow: /cart/
Disallow: /checkout/
Disallow: /search
Disallow: /search?
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?page=
Disallow: /private/
Allow: /wp-admin/admin-ajax.php
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: PerplexityBot
Disallow: /private/
Disallow: /admin/
Disallow: /bitrix/admin/
Disallow: /wp-admin/
Allow: /blog/
Allow: /articles/
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /
User-agent: YandexBot
Allow: /
Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-images.xmlЕсли говорить по-честному, я бы не советовал слепо копировать даже этот шаблон. У каждого сайта свои исключения. Где-то нужно оставить open graph-превью, где-то закрыть PDF, где-то отдельно защитить языковые версии. А на мультиязычных проектах ещё и hreflang нужно не забыть. Об этом у меня есть отдельная статья: hreflang для многоязычного сайта.
И последнее. robots.txt — это часть общей системы, а не самодостаточная защита. Он должен идти вместе с нормальными редиректами, HTTPS, заголовками безопасности, кешированием, мониторингом и логированием. Если всё это собрано вместе, сайт живёт спокойнее, сервер не захлёбывается, а индексация становится предсказуемой. Если нет — потом будете героически тушить пожар, который можно было не разжигать.
Если вам нужна помощь с настройкой robots.txt, проверкой логов, защитой от AI-crawlers или доработкой сайта под Bitrix, WordPress или Laravel, я бы на вашем месте не откладывал это на потом. На проектах 2026 года такие вещи решаются один раз и нормально, а не “когда станет совсем больно”.
Нужно настроить robots.txt под AI-crawlers?
Поможем корректно ограничить или разрешить доступ ботам и AI-crawlers, чтобы сохранить контроль над индексацией.