Коротко. Самая частая и самая разрушительная ошибка — строка Disallow: /, забытая после разработки сайта на тестовом сервере: она закрывает от индексации вообще всё, и трафик может обнулиться за 1-3 недели. Следом идут закрытие CSS и JS через Disallow: /wp-content/ или аналог, слишком широкие маски вроде Disallow: /*?* и путаница между robots.txt и тегом noindex — файл лишь просит робота не заходить, но не гарантирует, что страница не попадёт в индекс, если на неё ведут внешние ссылки. Проверка занимает 5 минут в панели вебмастера и должна входить в стандартный чек-лист после каждого изменения файла.
Disallow: / — ошибка, которая обнуляет весь трафик
Это правило запрещает сканирование абсолютно всех страниц сайта и чаще всего появляется не по злому умыслу, а по забывчивости: на этапе разработки сайт специально закрывают от индексации, чтобы черновая версия не попала в выдачу раньше времени, а после запуска строку забывают убрать. Такое нередко случается при передаче сайта после разработки, если в чек-листе запуска нет отдельного пункта на проверку robots.txt. Результат виден не сразу — робот заходит на сайт не каждый день, поэтому первые дни после запуска сайт может ещё работать по инерции на старых данных индекса. Затем трафик начинает падать, и через 2-3 недели может обнулиться почти полностью. Это единственная ошибка в списке, которую стоит проверять вручную сразу после каждого релиза сайта, а не ждать планового аудита — достаточно открыть site.ru/robots.txt в браузере и убедиться, что там нет одинокой строки Disallow: / без уточняющего пути.
Блокировка CSS и JS от робота
Раньше практика закрывать технические папки типа /wp-content/ или /bitrix/templates/ целиком считалась нормой — они казались «служебными» и неважными для индексации. Сейчас это ошибка: и Google, и Яндекс рендерят страницу как браузер, то есть подгружают стили и скрипты, чтобы понять, как страница выглядит и работает для живого посетителя. Если робот не может скачать CSS, он видит страницу как неструктурированный текст без вёрстки — и может решить, что сайт технически неисправен или не адаптирован под мобильные устройства, что скажется на оценке качества. Проверить эту ошибку просто: инструмент «Проверка страницы» в Google Search Console или «Проверка ответа сервера» в Яндекс.Вебмастере показывает, как робот в реальности видит страницу — если вёрстка «съехала» или отсутствует, вероятная причина — заблокированные ресурсы.
Слишком широкие маски с wildcard
Символ * в директиве Disallow — мощный инструмент, который легко использовать неаккуратно. Правило Disallow: /*?* задумывается как блокировка страниц с параметрами вроде UTM-меток или сортировки, но на практике блокирует вообще любой URL со знаком вопроса — включая страницы с ЧПУ, где вопросительный знак случайно оказался частью корректного адреса, или страницы пагинации с параметром страницы. Правильный подход — блокировать конкретный параметр по имени: Disallow: /*?sort= вместо общего Disallow: /*?*. Это уже, но предсказуемо и не задевает страницы, которые не должны быть закрыты.
Путаница между robots.txt и noindex
Частое заблуждение: если закрыть страницу в robots.txt, она гарантированно не попадёт в поиск. На деле это не так. Robots.txt запрещает роботу сканировать страницу — то есть заходить и скачивать её содержимое. Но если на закрытую страницу ведут ссылки с других сайтов, поисковая система может добавить URL в индекс на основании этих внешних сигналов, даже не увидев содержимое — просто как «ссылку, о существовании которой известно». В выдаче такая страница показывается без описания, часто с пометкой вроде «нет информации об этой странице». Если задача — гарантированно убрать страницу из поиска, а не просто сэкономить краулинговый бюджет, нужен тег <meta name="robots" content="noindex"> в коде самой страницы — а не (или не только) блокировка в robots.txt.
Отсутствие или неверный путь к Sitemap
Строка Sitemap: https://site.ru/sitemap.xml в конце файла — не обязательна по стандарту, но её отсутствие или ошибка в адресе усложняет роботу поиск карты сайта, особенно на молодых доменах, у которых ещё нет истории посещений. Частые промахи: указан http вместо https после переезда сайта на защищённый протокол, указан неактуальный путь после смены структуры сайта, или адрес ведёт на пустой sitemap.xml, оставшийся от старой версии сайта. Эту строку стоит сверять с реальным содержимым файла sitemap каждый раз, когда меняется домен или протокол сайта.
Таблица: как быстро распознать проблему
| Симптом | Вероятная ошибка в robots.txt |
|---|---|
| Резкое падение трафика за 2-3 недели после релиза | Disallow: / — сайт закрыт целиком |
| Страница в выдаче показывается без описания | Смешана блокировка сканирования и индексации, нужен noindex вместо Disallow |
| В индексе много мусорных URL с параметрами | Слишком узкая или отсутствующая маска для параметров каталога |
| Google Search Console показывает «страница не оптимизирована для мобильных» | Заблокированы CSS/JS через Disallow технической папки |
| Робот долго не находит новые страницы | Неверный или отсутствующий путь Sitemap в файле |
Как проверять файл на регулярной основе
Разовой проверки недостаточно — robots.txt может измениться при обновлении CMS, установке нового плагина или ручной правке разработчиком, который не в курсе истории файла. Рабочая привычка — раз в месяц открывать инструмент проверки robots.txt в панели Яндекс.Вебмастера или Google Search Console и прогонять через него 5-7 ключевых URL сайта: главную, карточку товара, страницу категории, страницу блога, страницу с параметром фильтра. Если хотя бы одна из значимых страниц оказывается заблокированной — файл требует правки. Такая проверка логично входит в состав регулярного технического аудита, наравне с проверкой скорости загрузки и SEO-аудита сайта в целом. На сайтах, где изменения вносятся часто, эту рутину обычно берёт на себя техническая поддержка сайта.
FAQ
Как быстро поисковик заметит ошибку в robots.txt после её исправления?
Обычно за 1-3 дня робот заново скачает файл — это происходит при каждом визите на сайт. Но восстановление трафика после серьёзной ошибки вроде Disallow: / может занять недели, потому что страницы нужно заново просканировать и вернуть в индекс.
Может ли ошибка в robots.txt привести к штрафу или пессимизации?
Нет, это не санкция — это просто потеря видимости из-за того, что страницы физически не в индексе. После исправления файла восстановление идёт естественным путём, без дополнительных действий по снятию ограничений.
Как проверить старые версии robots.txt, если ошибку заметили не сразу?
История файла хранится в отчёте «robots.txt» Google Search Console — там видно, какая версия действовала в конкретную дату. Это помогает понять, совпадает ли момент появления ошибки с моментом падения трафика.
Стоит ли закрывать в robots.txt PDF-файлы и документы на сайте?
Только если они не должны участвовать в поиске — например, внутренние прайсы для отдела продаж. Публичные документы вроде каталогов или сертификатов закрывать не стоит, они тоже приносят трафик по своим запросам.
Что делать, если непонятно, кто и когда менял robots.txt?
Проверить журнал изменений в системе управления сайтом, если она это поддерживает, либо сверить дату изменения файла на сервере с датой начала проблем в аналитике — это сузит круг поиска причины.
Найти ошибки в robots.txt своего сайта
Бесплатный аудит проверит файл на типичные промахи и покажет, какие страницы реально теряют видимость в поиске.
Готовый robots.txt для WordPress
Базовый набор правил: закрываем служебные каталоги, оставляем открытым ajax-обработчик и указываем карту сайта.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /?s=
Disallow: /*?replytocom
Allow: /wp-content/uploads/
Sitemap: https://example.ru/sitemap_index.xml