все разделы
Robots.txt – текстовый файл, который сообщает поисковым роботам, какие URL можно обходить, а какие лучше не запрашивать. В статье разберём назначение и директивы User-agent, Disallow, Allow, Clean-param и Sitemap, покажем, как создать файл robots.txt для сайта, разместить и проверить его на реальных адресах. Отдельно рассмотрим настройку robots.txt для обычного сайта, 1С-Битрикс, Tilda и WordPress, а также объясним разницу между обходом, индексацией, noindex и Sitemap. Владелец сайта может начать с минимального файла и постепенно добавлять только обоснованные ограничения. Главное – проверять итоговый ответ сервера, область действия домена и совпадение правил с настоящими URL, а не ориентироваться на внешний вид шаблона.
Robots.txt – общедоступный текстовый файл с правилами для поисковых роботов. Если коротко отвечать на вопрос «robots txt что значит», владелец сайта указывает в нём, какие URL можно сканировать, а какие запрашивать не следует. Файл управляет обходом, но не защищает данные: его может открыть любой пользователь.
Перед обходом сайта робот запрашивает /robots.txt, находит группу для своего User-agent и сопоставляет адрес страницы с правилами Allow и Disallow. Если отдельной группы нет, используется User-agent: *. Специальная группа не наследует автоматически общие правила: нужные ограничения в ней задают явно.
Robots.txt управляет сканированием, а не гарантированным удалением из результатов поиска. Поисковик может узнать закрытый URL из ссылок или других источников и показать его без полноценного описания. Если страницу нужно исключить из индекса, робот должен получить сигнал noindex в HTML или заголовке X-Robots-Tag. Закрыв эту же страницу через Disallow, владелец сайта может помешать роботу увидеть noindex.
Файл robots.txt используется для ограничения обхода технических и повторяющихся адресов. Типичные кандидаты: административные разделы, внутренний поиск, корзина, оформление заказа, личный кабинет, страницы предпросмотра, служебные URL и бесконечные сочетания фильтров. Цель состоит не в том, чтобы «закрыть побольше», а в том, чтобы не расходовать ресурсы робота и сервера на страницы, не имеющие поисковой ценности.
URL с параметрами оценивают по смыслу. Если параметр лишь отмечает источник перехода и не меняет страницу, для Яндекса можно рассмотреть Clean-param. Если от него зависят товары, цена, регион или полезная посадочная страница, общий запрет создаст проблему. По той же причине нельзя без проверки закрывать CSS, JavaScript, изображения и шрифты: эти ресурсы могут быть нужны поисковику для обработки страницы.
Файл размещают в корне хоста. Для сайта https://site.ru стандартный адрес: https://site.ru/robots.txt. Файл в /blog/robots.txt или папке шаблона его не заменяет. Правила для HTTPS не распространяются автоматически на HTTP, www или другой порт.
Для поддомена нужен отдельный адрес, например https://shop.site.ru/robots.txt. Файл должен открываться без авторизации и возвращать обычный текст, а не HTML-страницу входа или ошибку. Практически безопасный вариант – ответ 200 OK, Content-Type: text/plain и кодировка UTF-8.
Синтаксис robots.txt построчный. Группа начинается с одной или нескольких строк User-agent, а за ней идут правила доступа. Пустые строки и комментарии допустимы, но внутри группы лучше придерживаться простого формата без лишнего оформления. Директивы чувствительны к смыслу и написанию: User-agent, Disallow, Allow, Sitemap и Clean-param нужно писать точно.
User-agent указывает, для какого робота предназначена следующая группа. Запись User-agent: * означает общее правило на случай, когда отдельной группы для робота нет. Для главного робота Google используется Googlebot, а не расплывчатое Google. В Яндексе YandexBot – основной индексирующий робот; это не название всех роботов Яндекса. Для специализированных роботов нужно сверяться с актуальной документацией конкретной системы.
Пример общей группы:
Главная блога
Интернет-маркетинг
Отдел продаж
ТОП сервисы.svg)
Новости
User-agent: *
Disallow: /account/
Disallow: /checkout/Пример отдельной группы допустим только тогда, когда действительно нужен другой набор правил:
User-agent: Googlebot
Disallow: /private/В последнем случае не следует ожидать автоматического добавления запретов из User-agent: *. Если Googlebot должен соблюдать и общие ограничения, их повторяют в его группе. Дублирующиеся группы для одного имени робота также не стоит создавать без необходимости: правила лучше собрать в одной группе, чтобы при поддержке файла не возникало разночтений.
Disallow задаёт путь, который робот не должен обходить. Например:
User-agent: *
Disallow: /admin/
Disallow: /search/Disallow: /admin/ совпадает с /admin/ и вложенными URL, но не с /administrator/. Запись Disallow: /search шире: она может совпасть с /search, /search/, /search?q=seo и /search-guide. Поэтому завершающий слеш полезен для обозначения каталога, но отсутствие слеша не делает правило недействительным.
Disallow: / закрывает всю область действия файла для выбранной группы. Это критичная строка: в рабочем robots.txt она должна появляться только при осознанной задаче, например на тестовом сайте. Пустая директива Disallow: не запрещает обход. Фактически она означает отсутствие пути для блокировки, поэтому сайт остаётся открытым по этому правилу.
Без символа $ правило сопоставляется как префикс. Disallow: /private/file затронет также /private/file-copy. Если нужен конец пути, можно использовать $, но результат следует проверять на конкретной системе и наборе URL. Строка параметров тоже важна: окончание URL и правила с параметрами могут давать неожиданные совпадения.
Allow разрешает обход исключения внутри более широкого запрета. В примере ниже каталог закрыт, но один файл доступен:
User-agent: *
Disallow: /catalog/private/
Allow: /catalog/private/public-manual.pdfДля public-manual.pdf срабатывает более длинный и точный Allow; остальные URL внутри /catalog/private/ закрыты. При равной длине совпадений выбирается разрешение. Пустой Allow: не блокирует сайт, а Allow: / обычно лишний: если запрет не совпал, обход уже разрешён.
Clean-param – расширение Яндекса, а не универсальная директива и не правило Google. Оно помогает сократить обход дублей, созданных параметрами URL, которые не меняют содержание страницы. Синтаксис допускает несколько параметров через & и необязательный путь:
Clean-param: ref /catalog/Здесь ref считается служебной меткой в каталоге. Если параметр влияет на цену, регион, наличие или контент, правило применять нельзя. Без пути оно действует на всём сайте.
Вариант без ограничения по пути:
Clean-param: utm_source&utm_medium&utm_campaignОн синтаксически допустим для Яндекса и действует на весь сайт. Копировать его автоматически не нужно: распространённые UTM-метки Яндекс во многих случаях обрабатывает сам.
Строка Sitemap сообщает поисковой системе адрес XML-карты сайта:
Sitemap: https://site.ru/sitemap.xmlМожно указать несколько карт:
Sitemap: https://site.ru/sitemap-pages.xml
Sitemap: https://site.ru/sitemap-products.xmlGoogle и Яндекс принимают полный URL карты. Sitemap помогает обнаружить важные адреса, но не гарантирует обход или индексацию. Это не команда «ходить только сюда». Google также не использует <priority> и <changefreq> для выбора очередности обхода. Sitemap не отменяет запреты Disallow.
Sitemap можно размещать между группами и после правил. Это дополнительная запись, поддерживаемая Google и Яндексом. Адрес карты должен вести на реально опубликованный файл нужного проекта.
Символ * означает последовательность любых символов в поддерживаемом поисковиком шаблоне. Символ $ обозначает конец совпадения. Например:
User-agent: *
Disallow: /private/*
Disallow: /*.pdf$Вторая запись предназначена для URL, заканчивающихся на .pdf; адрес /docs/manual.pdf?download=1 уже не имеет .pdf в самом конце. Проверяйте такие маски на матрице URL, потому что query-параметры, кодирование и реальные пути влияют на результат.
Символ # начинает комментарий. Это не директива и не часть пути после позиции комментария:
Disallow: /private/ # служебный раздел
Настройка robots.txt начинается не с копирования шаблона, а с инвентаризации URL. Один и тот же путь /filter/, /search/ или /api/ имеет разную роль на разных проектах. Сначала определите, какой контент должен быть доступен роботам, затем добавляйте минимальные запреты.
Составьте список типов страниц: главная, категории, карточки товаров, статьи, посадочные страницы, пагинация, изображения и другие ресурсы, нужные для отображения. Отметьте URL, которые приносят органический трафик или должны быть обнаружены через Sitemap. Отдельно зафиксируйте поддомены, HTTP/HTTPS и возможные зеркала.
Проверьте, что полезные разделы не закрыты широким префиксом. Например, Disallow: /catalog/ заблокирует и важные товарные карточки. Если закрывается техническая ветка, определите вложенные исключения и проверьте их фактическую длину. Не закрывайте CSS и JS только потому, что они находятся в каталоге с техническим названием.
Кандидатами могут быть авторизация, корзина, оформление заказа, внутренний поиск, страницы предпросмотра, технические адреса обратных вызовов и дублирующие URL с параметрами. Для каждого кандидата ответьте на два вопроса: должен ли поисковик обходить этот URL и меняет ли параметр содержание? Если ответ зависит от типа параметра, правила нельзя формулировать одним общим запретом.
Соберите таблицу «URL – назначение – решение – причина». В ней должны быть как минимум разрешённая посадочная, закрытый служебный URL, адрес со строкой параметров, разрешённое исключение внутри запрета и ресурс CSS или JS. Такая матрица защищает от ошибки, когда текст кажется аккуратным, но совпадает с другим префиксом.
Создайте обычный текстовый файл без HTML, XML и Markdown-обёртки. Минимальный безопасный каркас:
User-agent: *
Sitemap: https://site.ru/sitemap.xmlВ файле указывают карту именно своего проекта. Второй домен в такой минимальный пример не добавляют.
Затем добавляйте только проверенные правила:
User-agent: *
Disallow: /account/
Disallow: /checkout/
Disallow: /search/
Sitemap: https://example.com/sitemap.xmlСохраните файл в UTF-8. Не добавляйте автоматически Allow: /, Host, Crawl-delay или Disallow: / «для полноты». Каждый символ должен иметь понятную причину. Название файла – robots.txt, а не robot.txt; поисковая фраза «пример файла robot txt» встречается часто, но стандартное имя остаётся robots.txt.
Разместите файл в корне нужного домена. После загрузки откройте его в браузере и через HTTP-клиент. Убедитесь, что адрес не перенаправляет на страницу входа, HTML-документ или другой хост, если это не предусмотрено. Проверьте код ответа, итоговый URL после перенаправлений, Content-Type, кодировку и размер тела. Для обычного файла ожидается простой текст в UTF-8.
Если сайт работает через CDN, WAF или кэш, убедитесь, что они отдают новую версию. Для поддомена повторите проверку на его собственном хосте и протоколе.
Проверить robots.txt нужно до публикации и после выкладки. Минимальный набор: главная страница, важная посадочная, закрытый служебный URL, URL с параметром, URL внутри вложенного каталога, исключение после Allow, CSS/JS-ресурс и похожий, но не совпадающий путь. Например, если закрыт /search/, обязательно протестируйте /search/ и /search-guide/.
Для спорных адресов сохраните ожидаемый результат рядом с фактическим: разрешён, закрыт или требует отдельного решения.
Сравните ожидаемый результат с фактическим анализатором Яндекса и инструментами Google. После исправлений снова проверьте HTTP-ответ и сохраните версию файла в системе контроля изменений. Не обещайте точный срок, когда робот перечитает robots.txt: кэширование и повторный обход зависят от поисковой системы и состояния сайта.
Перед изменением зафиксируйте текущую версию и сделайте резервную копию. После публикации проверьте несколько URL из логов обхода: это помогает заметить, что правило затронуло не тот префикс. Для разных протоколов и поддоменов повторите тест отдельно. Если сомневаетесь, начинайте с одного узкого запрета, а не закрывайте крупный раздел целиком.
Ниже приведены учебные конфигурации. Они рабочие только при совпадении с указанной URL-архитектурой. Перед публикацией замените домен, пути и смысл параметров данными своего проекта.
Предположим, что на информационном сайте внутренний поиск, личный кабинет, preview и приватная папка ресурсов не должны обходиться, а один публичный файл внутри последней папки нужен для отображения:
User-agent: *
Disallow: /search/
Disallow: /account/
Disallow: /preview/
Disallow: /assets/private/
Allow: /assets/private/public-logo.svg
Sitemap: https://example.com/sitemap.xmlОжидаемая матрица выглядит так:
| URL | Результат | Причина |
/ | разрешён | нет совпадения |
/articles/robots-txt | разрешён | нет совпадения |
/search/?q=robots | закрыт | /search/ |
/account/orders | закрыт | /account/ |
/assets/private/secret.pdf | закрыт | /assets/private/ |
/assets/private/public-logo.svg | разрешён | более точный Allow |
/search-guide/ | разрешён | /search/ не совпадает |
Не называйте этот блок универсальным шаблоном: на конкретном сайте /preview/ может быть публичной SEO-страницей, а /search/ может иметь отдельную ценность.
Предположим, что фильтры в проекте создают только технические комбинации, а страница /catalog/filter/size-guide/ является полезной справочной страницей. Параметр ref не меняет товарный контент:
User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search/
Disallow: /catalog/filter/
Allow: /catalog/filter/size-guide/
Clean-param: ref /catalog/
Sitemap: https://shop.example.com/sitemap.xmlClean-param учитывает только Яндекс. Google проигнорирует эту дополнительную запись и применит базовые правила. Если фильтр по бренду или размеру создаёт ценную посадочную, закрывать всю ветку нельзя. Если ref меняет цену, регион, наличие или описание, его нельзя объявлять незначимым. Не закрывайте все URL со знаком ? без классификации параметров.
Контрольные URL для этого примера:
| URL | Яндекс | Причина | |
/catalog/shoes/ | разрешён | разрешён | запрета нет |
/cart/ | закрыт | закрыт | /cart/ |
/checkout/payment/ | закрыт | закрыт | /checkout/ |
/search/?q=boots | закрыт | закрыт | /search/ |
/catalog/filter/red/ | закрыт | закрыт | /catalog/filter/ |
/catalog/filter/size-guide/ | разрешён | разрешён | более точный Allow |
/catalog/shoes/?ref=partner | разрешён | разрешён, ref очищается | Clean-param действует только в Яндексе |
Sitemap заменяют на карту нужного хоста. Ожидаемые результаты полезно хранить вместе с версией файла, чтобы повторить проверку после изменений CMS или структуры URL.
В 1С-Битрикс файл можно настроить через встроенный SEO-интерфейс. Но наличие поля в панели не означает, что современный поисковик поддерживает каждую предложенную директиву. Поэтому настройки CMS нужно проверять по документации Google и Яндекса.
Актуальный путь в административной панели: Маркетинг → Поисковая оптимизация → Настройка robots.txt. В интерфейсе доступны генерация и ручное редактирование. После сохранения откройте публичный https://домен/robots.txt, потому что итоговый ответ может зависеть от окружения, кэша и настроек проекта.
Некоторые версии или элементы интерфейса могут показывать поля Host и Crawl-delay. Не включайте их только потому, что они видны: директива Host устарела в Яндексе, а Crawl-delay не поддерживается современными Google и Яндексом. Минимальная версия редакции Битрикс и точные права доступа зависят от установленного продукта; не следует обещать универсальный номер версии без проверки конкретного проекта.
Проверьте административные URL, авторизацию, персональный раздел, внутренний поиск, AJAX и каталоги. Не закрывайте весь /bitrix/ без аудита: внутри могут находиться CSS, JavaScript и другие ресурсы, необходимые для корректной обработки страницы. Закрывайте конкретные административные пути, а не всю техническую область по названию.
Проверьте ЧПУ и параметры каталога. В Битрикс одинаковая задача может реализовываться разными URL в зависимости от шаблона, инфоблоков и настроек фильтра. Для каждого правила нужны реальные примеры из access log, карты сайта и обхода проекта.
User-agent: *
Disallow: /bitrix/admin/
Disallow: /search/
Disallow: /personal/
Disallow: /auth/
Allow: /personal/help/
Sitemap: https://example.com/sitemap.xmlВ таком учебном проекте /personal/help/ – публичная справка внутри закрытого персонального раздела. /bitrix/js/main/core/core.js не блокируется, чтобы робот мог получить необходимый ресурс. Все пути нужно адаптировать: на другом сайте /auth/ может быть частью публичной страницы, а /personal/help/ – отсутствовать.
Контрольные URL: / и /catalog/item-1/ разрешены; /bitrix/admin/index.php, /search/?q=test, /personal/orders/ и /auth/ закрыты; /personal/help/ разрешён более точным Allow; /bitrix/js/main/core/core.js остаётся доступным. Если на сайте несколько доменов, тестируйте каждый хост и протокол отдельно. Любой запрет для каталога товаров согласуйте с SEO-структурой и Sitemap.
Tilda отличается от CMS с файловым редактором: платформа сама генерирует /robots.txt и /sitemap.xml. На обычном хостинге Tilda нет произвольного штатного редактора, куда можно вставить собственный конфиг. Поэтому инструкция «откройте robots.txt в Tilda и замените строки» будет недостоверной.
Проверить сгенерированный файл можно по адресу https://ваш-домен/robots.txt после публикации проекта. Sitemap обычно доступен по стандартному адресу /sitemap.xml. Содержимое зависит от настроек сайта и страниц, поэтому его нужно читать в опубликованной версии, а не восстанавливать по чужому примеру.
Для отдельной страницы используйте путь: Настройки страницы → SEO → Отображение в поисковой выдаче → Задать специальные метаданные → Индексация → Запретить поисковикам индексировать страницу. Сохраните настройку и опубликуйте страницу.
Для всего сайта: Настройки сайта → SEO → Запретить поисковикам индексировать сайт. Сохраните изменения и опубликуйте проект. Затем откройте реальный /robots.txt, исходный код страницы и HTTP-заголовки, чтобы проверить фактически сгенерированные сигналы. Формулировка «как изменить robots txt в тильде» на практике означает настройку индексации через доступные SEO-переключатели, а не ручную правку произвольного файла.
Если нужен полный контроль над физическим файлом, рассматривают экспорт кода на собственный хостинг при подходящих условиях тарифа. После экспорта robots.txt обслуживается уже вашим сервером, и порядок настройки зависит от выбранного хостинга. Точные возможности тарифа лучше сверить в текущей справке Tilda.
Вместо вымышленного блока используйте фактический сценарий проверки:
Страница /thank-you/
Настройки страницы → SEO → Отображение в поисковой выдаче
→ Задать специальные метаданные → Индексация
→ Запретить поисковикам индексировать страницу
→ Сохранить → Опубликовать
Проверка:
https://ваш-домен/robots.txt
исходный код и заголовки страницы /thank-you/Ожидается, что после публикации платформа сформирует соответствующее ограничение или другой предусмотренный сигнал. Точную строку нельзя придумывать без чтения опубликованного файла: документация подтверждает механизм, но не даёт универсальный текст для каждого проекта.
WordPress может отдавать виртуальный robots.txt, сформированный ядром, даже если физического файла в корне нет. Физический файл может перекрыть виртуальный ответ. На результат также влияют плагины, сервер и кэш, поэтому проверять нужно публичный URL.
Ядро WordPress формирует базовый ответ примерно такого вида:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpCore Sitemaps может добавить адрес карты сайта. Фильтр robots_txt позволяет разработчику изменить виртуальный вывод программно. Если в корне уже лежит физический robots.txt, он способен иметь приоритет над виртуальным механизмом. Поэтому сначала выясните, какой источник реально отдаётся сервером.
Вручную физический файл можно изменить на сервере, если есть права и понятен процесс деплоя. В Yoast SEO документированный путь: Yoast SEO → Tools → File Editor. Пункт может отсутствовать при отключённом редактировании файлов или недостаточных правах.
В Rank Math включите Advanced Mode и откройте Rank Math SEO → General Settings → Edit robots.txt. Rank Math редактирует виртуальный файл; физический файл может не дать изменениям плагина примениться. Не смешивайте инструкции Yoast и Rank Math: интерфейсы и ограничения у них разные.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /search/
Disallow: /?s=
Sitemap: https://wp.example.com/wp-sitemap.xml/search/ и /?s= в этом примере являются решением конкретного проекта, а не обязательной частью WordPress. Проверьте реальные URL поиска и адрес Sitemap: плагин SEO может использовать собственную карту. Не добавляйте без аудита Disallow: /wp-content/ или Disallow: /wp-includes/, потому что там могут находиться ресурсы, нужные поисковику для обработки страницы.
Контрольные URL: / и обычная статья разрешены; /wp-admin/ и /wp-admin/edit.php закрыты; /wp-admin/admin-ajax.php разрешён более точным правилом; CSS из /wp-content/ и JavaScript из /wp-includes/ доступны; /search/robots/ закрыт. После изменения очистите кэш и сравните публичный ответ с настройкой WordPress: физический файл может перекрыть виртуальную версию плагина.
Проверка robots.txt состоит из двух уровней: HTTP-доступ и логика правил. Красивый текст бесполезен, если сервер отдаёт не тот файл, а корректный HTTP-ответ не спасает от случайного Disallow: /.
Откройте URL в браузере и выполните запрос с HTTP-клиентом. Проверьте исходный и итоговый URL, протокол, хост и порт, цепочку перенаправлений, статус, Content-Type, кодировку, размер ответа и первые символы тела. Ожидается обычный текст в UTF-8 без HTML, страницы WAF и формы входа.
Пример командной проверки:
curl -sS -L --max-redirs 10 -D robots-headers.txt -o robots.txt -w 'final_url=%{url_effective}\nhttp_status=%{http_code}\ncontent_type=%{content_type}\nsize_download=%{size_download}\n' https://site.example/robots.txt
wc -c robots.txtЗатем вручную или парсером сопоставьте контрольные URL. Учитывайте, что разные поисковые системы могут иметь детали реализации для редиректов, ошибок и кэша. Не переносите без оговорок поведение Google на Яндекс.
Откройте Инструменты → Анализ robots.txt. Можно указать сайт или вставить содержимое файла, посмотреть правила обхода и ошибки, а затем проверить доступ к набору абсолютных или относительных URL. Тестируйте не только закрытый адрес, но и похожий путь, который должен остаться открытым.
После публикации сравните результат анализатора с фактическим /robots.txt. История версий помогает увидеть, какой вариант файла уже был получен сервисом, но не означает мгновенное применение каждого изменения всеми роботами.
В Google Search Console используйте robots.txt report для диагностики обнаруженного файла, ошибок и доступных версий. Для вопроса о конкретном URL применяйте URL Inspection или открытый robots parser, а не старые инструкции, которые отправляют в устаревший Tester. Для noindex дополнительно проверяйте, что Googlebot может получить HTML или HTTP-ответ с этим сигналом.
Проверка в интерфейсе не заменяет HTTP-тест: Search Console может показывать состояние своей версии, тогда как браузер и CDN уже отдают другой ответ. После исправления критичной ошибки запросите повторное получение файла там, где такой вариант предлагает текущий инструмент, и затем перепроверьте URL.
Полезно проверять и отрицательные, и положительные сценарии. Если закрыт /private/, протестируйте /private/file, /private-public/ и разрешённое исключение внутри каталога. Если используются маски, добавьте URL со строкой параметров и URL с похожим расширением. Результат фиксируйте вместе с версией файла, чтобы при изменении можно было понять, какое правило дало наблюдаемый эффект.
Нет, Яндекс получает robots.txt с публичного адреса /robots.txt. Вебмастер не является местом, где файл становится доступным поисковому роботу. Он нужен для анализа: показывает ошибки, правила, историю и результат проверки URL. Источником истины остаётся опубликованный ответ сервера.
В настройках инструмента важно выбрать именно проверяемый сайт и его протокол. Файл для www не подтверждает состояние версии без www, а адрес поддомена нужно анализировать отдельно. Сравните результат с публичным ответом сервера.
Нельзя обещать точный срок в минутах или часах. Робот должен повторно запросить файл, а кэш и состояние сайта могут повлиять на момент применения. После публикации проверьте доступность и версию в Вебмастере, затем наблюдайте за обходом. Если в файле была аварийная блокировка, сначала убедитесь, что новая версия действительно отдаётся по нужному хосту и протоколу.
Если анализатор показывает ошибку, сначала исправьте доступность и формат публичного файла, затем повторите тест правил. Для диагностики полезно сравнить версию, которую видит Вебмастер, с ответом curl и браузера. Различие обычно указывает на кэш, перенаправление, разные хосты или вмешательство WAF. Не считайте отображение файла в интерфейсе заменой публикации на сервере.
При работе с несколькими зеркалами отдельно проверьте каждый протокол и домен: анализ одного адреса не подтверждает состояние остальных. Так связка robots.txt и Вебмастера остаётся диагностическим инструментом, а не заменой серверной проверки.
Самая опасная ошибка – Disallow: / в общей группе. Она запрещает обход всей области действия файла. Такое правило нельзя использовать как временную «защиту от публикации»: для тестовой версии применяйте авторизацию и ограничения сервера, а перед запуском удаляйте блокировку. После исправления сразу проверьте главную, ключевые посадочные и отчёты поисковых систем. Убедитесь также, что запрет не остался в отдельной специфичной группе робота.
Широкий префикс может захватить коммерческие страницы и CSS/JS, необходимые для обработки страницы. Примеры /catalog/, /static/, /wp-content/ и /wp-includes/ нельзя закрывать без аудита. Проверяйте URL, которые похожи на запрет, и исключения внутри него. Allow должен соответствовать настоящему пути, а не предполагаемому имени файла.
Disallow ограничивает crawl, но не является гарантией удаления из индекса. Если адрес должен исчезнуть из поиска, робот должен получить noindex через HTML meta robots или X-Robots-Tag. Не закрывайте страницу в robots.txt до того, как поисковик успел прочитать этот сигнал. Для приватных данных ни robots, ни noindex не заменяют авторизацию.
Чужой файл отражает чужие URL, поддомены, параметры и CMS. Копирование может закрыть весь каталог товаров, открыть служебную страницу или направить Sitemap не на тот домен. Используйте чужой пример только как иллюстрацию синтаксиса, затем составьте собственную матрицу URL.
Локальная версия не равна опубликованной. CMS, CDN, кэш, редиректы, WAF и права сервера могут изменить ответ. После каждого изменения открывайте /robots.txt, сверяйте заголовки и тестируйте реальные URL в Яндекс Вебмастере и актуальных инструментах Google. Отдельно проверяйте, что в файле не появились Host, Crawl-delay или noindex из старого шаблона.
Отдельный риск – считать пустые строки или визуальное выравнивание доказательством правильности. Поисковик анализирует группы и совпадения путей, а не намерение автора. Ошибка в одном префиксе может быть незаметна на главной, но закрыть сотни карточек. Поэтому проверяйте URL разных уровней вложенности и повторяйте аудит после миграции CMS, смены ЧПУ или добавления фильтров.
Robots.txt, noindex и Sitemap решают разные задачи:
| Механизм | Основная задача | Где задаётся | Нужен доступ робота к URL | Гарантия результата |
robots.txt | ограничить обход | /robots.txt | к robots-файлу – да; к закрытой странице – нет | не гарантирует удаление из индекса |
noindex | сообщить не включать URL в индекс | HTML meta или X-Robots-Tag | да | indexing signal для поддерживающей системы |
| Sitemap | сообщить важные и предпочтительные URL | XML-карта | карта должна быть доступна | не гарантирует обход и индексацию |
Если нужно сократить технический обход, используйте robots.txt. Если нужно исключить страницу из индекса, обеспечьте доступ и настройте noindex. Если нужно помочь поисковику обнаружить канонические и важные адреса, поддерживайте Sitemap. В реальном проекте эти инструменты могут работать вместе, но не подменяют друг друга. Перед публикацией создаём robots.txt от структуры сайта, затем проверяем его на HTTP-уровне и на контрольной матрице URL.
Эти сигналы нужно согласовать по цели страницы. Не добавляйте URL в Sitemap, если он закрыт без понятной причины, и не закрывайте robots.txt страницу, на которой поисковику требуется прочитать noindex. Для временных или приватных страниц применяйте серверные ограничения, а для SEO-решений учитывайте canonical, метатеги и заголовки в зависимости от задачи.
Отдельно проверьте доступность канонического адреса и отсутствие противоречивых сигналов. Sitemap не должен подсказывать один URL, пока robots.txt системно закрывает другой необходимый маршрут.
07.09.2026
67
33 мин
00000
