Файл robots.txt выглядит простым: несколько строк с правилами, которые сообщают поисковым роботам, какие разделы сайта можно обходить, а какие лучше не сканировать. Но именно здесь часто появляются ошибки, из-за которых Google перестает нормально обходить важные страницы. Особенно неприятно, когда проблема возникает после изменения сайта, установки CMS-плагина или редактирования одного правила, а владелец замечает ее только тогда, когда органический трафик уже начал снижаться.
При этом robots.txt часто понимают неправильно. Он управляет доступом поисковых роботов к URL, но не является универсальным способом удалить страницу из поисковой выдачи. Если задача заключается именно в запрете индексации уже доступной страницы, используются другие механизмы, например noindex. Google отдельно указывает, что заблокированный в robots.txt URL в некоторых случаях все равно может появиться в результатах поиска, если поисковая система узнает о нем из других источников.
Поэтому правильная работа с robots.txt начинается не с копирования готового шаблона, а с понимания структуры сайта. Нужно определить, какие страницы действительно должны обходиться Google, какие URL являются техническими, где находятся фильтры и параметры, а какие разделы являются важными посадочными страницами. Только после этого можно составлять правила.
Robots.txt находится в корне сайта и содержит правила для поисковых роботов. С его помощью можно управлять тем, какие URL роботам следует обходить, а какие разделы не нужно посещать. Это особенно полезно для крупных сайтов, где существуют технические страницы, параметры, внутренние результаты поиска, служебные разделы и другие URL, которые не имеют самостоятельной ценности для органической выдачи.
Главная задача robots.txt заключается именно в управлении обходом. Например, если интернет-магазин создает тысячи комбинаций фильтров, часть таких URL может быть технической и не представлять интереса для поискового трафика. В определенных случаях их обход можно ограничить через robots.txt, чтобы поисковый робот не тратил ресурсы на ненужные варианты.
Но robots.txt нельзя воспринимать как команду «не показывать эту страницу в Google». Если URL уже известен поисковой системе, он может оставаться известным даже при запрете обхода. Поэтому для разных задач используются разные инструменты: robots.txt управляет crawling, noindex управляет индексацией доступной страницы, а редирект используется, когда старый URL должен вести на другой адрес.
Эта разница особенно важна при техническом SEO. Неправильный выбор инструмента способен создать ситуацию, когда владелец уверен, что страница закрыта от Google, а поисковая система продолжает знать о существовании URL. Или наоборот, важный раздел оказывается полностью недоступным для робота из-за слишком широкого правила.
Одна из самых распространенных ошибок заключается в том, что robots.txt используют для решения задачи, для которой он изначально не предназначен. Например, владелец хочет убрать из Google страницу фильтра, служебную страницу или старую карточку товара и добавляет ее в Disallow, считая, что после этого URL исчезнет из поиска.
На практике запрет обхода не является надежным способом удаления страницы из поисковой выдачи. Google может узнать о таком URL по ссылке с другой страницы или из внешнего источника. При этом робот не сможет нормально открыть страницу и увидеть ее содержимое или директиву noindex.
Если страницу необходимо оставить доступной для пользователей, но исключить из поисковой выдачи, обычно рассматривается noindex. Важный момент заключается в том, что Google должен иметь возможность просканировать URL и увидеть эту директиву. Если одновременно закрыть страницу через robots.txt, робот не сможет прочитать noindex.
Поэтому перед изменением robots.txt нужно сформулировать задачу. Если необходимо ограничить обход технических URL, robots.txt может быть подходящим инструментом. Если необходимо запретить индексацию конкретной доступной страницы, нужно рассматривать noindex. Если старый URL заменен новым, логичнее использовать редирект.
Самая опасная ошибка выглядит очень просто:
User-agent: *
Disallow: /Такое правило запрещает обход практически всего сайта для соответствующего робота. Если подобная настройка случайно попадает на рабочий домен, Googlebot перестает нормально обходить страницы сайта. Для нового сайта это может привести к тому, что поисковая система не сможет обнаружить и обработать важные URL. Для уже работающего проекта последствия могут проявиться в снижении обновления страниц и проблемах с обходом.
Особенно часто такая ошибка возникает при переносе сайта с тестового домена на основной. На тестовой версии запрет полного обхода может быть вполне оправдан, поскольку разработчики не хотят, чтобы промежуточный сайт индексировался. Но если вместе с сайтом на продакшен переносится тот же robots.txt, запрет начинает действовать уже на реальный ресурс.
Поэтому после запуска нового сайта robots.txt нужно проверять отдельно. Нельзя считать, что файл автоматически изменится вместе с доменом или CMS.
Если сайт внезапно потерял органический трафик после миграции, редизайна или технических работ, robots.txt должен входить в первые проверки. В более широком плане такой сценарий стоит рассматривать вместе с другими причинами падения, описанными в статье «Почему сайт резко просел в поиске».
Для полного блокирования сайта ошибка очевидна, но гораздо чаще проблема выглядит менее заметно. В robots.txt закрывается определенная папка, а внутри нее находятся важные коммерческие страницы.
Например, структура может выглядеть так:
/catalog/
/catalog/iphone/
/catalog/samsung/
/catalog/accessories/Если в robots.txt случайно появится:
User-agent: *
Disallow: /catalog/под запрет попадет весь каталог и все его вложенные URL. Владелец сайта может продолжать открывать страницы в браузере и считать, что все работает нормально, хотя поисковый робот получает совершенно другую картину.
Еще опаснее закрывать слишком широкие папки с названием вроде /content/, /data/, /assets/ или /templates/, не проверив, какие ресурсы реально используются страницами. Название каталога само по себе ничего не говорит о его значимости для Google.
Поэтому каждое правило Disallow необходимо сопоставлять с реальной структурой сайта. Перед добавлением запрета стоит посмотреть, какие URL находятся внутри соответствующего пути и используются ли они важными страницами.
В robots.txt можно задавать правила для определенных роботов или групп роботов. Здесь часто возникает ошибка, когда правило написано не для того User-agent, который владелец сайта рассчитывает ограничить.
Например:
User-agent: Googlebot
Disallow: /catalog/Такое правило относится к Googlebot. Оно не означает автоматически, что тот же запрет будет применяться ко всем поисковым роботам и другим системам.
Если необходимо задать общее правило, обычно используется:
User-agent: *
Disallow: /technical/При сложной конфигурации важно проверять итоговое поведение именно того робота, для которого создается правило. Особенно это актуально для сайтов, которые одновременно работают с Google, Яндексом, рекламными роботами и другими сервисами.
Не стоит также создавать десятки правил для разных User-agent без необходимости. Чем сложнее robots.txt, тем выше вероятность ошибки. Для небольшого сайта чаще всего достаточно понятной структуры с несколькими четкими правилами.
Ошибки возникают не только из-за самого Disallow, но и из-за неправильного понимания того, как поисковая система интерпретирует набор правил. Когда в одном файле много User-agent, Allow и Disallow, становится сложно определить, какой набор правил применяется к конкретному URL.
Например, разработчик может добавить общее правило для каталога, а затем отдельное исключение для одной страницы, рассчитывая, что оно будет работать так же, как обычное правило маршрутизации на сервере. Но robots.txt имеет собственную логику обработки правил.
Поэтому сложные конструкции необходимо тестировать, а не проверять только визуально. Если файл содержит много исключений, параметры и вложенные каталоги, ручного чтения строк недостаточно.
Особенно осторожно следует обращаться с конструкциями, где одновременно используются Allow и Disallow. На практике лучше стремиться к максимально понятной структуре. Чем проще файл, тем легче через несколько месяцев понять, зачем существует каждое правило.
Еще одна распространенная проблема заключается в том, что владелец закрывает не тот путь, который существует на сайте. Например, в robots.txt указывается /catalog/products/, хотя реальные карточки находятся в /products/. В результате правило не решает исходную задачу.
Обратная ситуация гораздо опаснее: путь оказывается шире, чем предполагалось. Например, разработчик хотел закрыть техническую страницу /search/, но из-за ошибки в структуре правил блокируется более крупный раздел.
Проверять нужно реальные URL. Не ориентируйтесь только на структуру меню или названия разделов в CMS. Откройте несколько страниц, посмотрите их адреса и определите общую часть пути, которую действительно необходимо ограничить.
Также учитывайте завершающие слеши, параметры и вложенные директории. Если сайт имеет несколько вариантов URL одного ресурса, сначала стоит разобраться со структурой адресов, а уже затем составлять правила robots.txt.
Особенно внимательно проверяйте сайты после изменения URL. Если старые и новые адреса существуют одновременно, robots.txt не должен случайно блокировать новые страницы, которые должны индексироваться.
Большое количество параметров является одной из основных причин, по которой владельцы интернет-магазинов начинают активно использовать robots.txt. Фильтры могут создавать тысячи URL, и часть из них действительно не имеет самостоятельной ценности для поиска.
Например, каталог может создавать адреса вида:
/catalog/phones/?brand=samsung
/catalog/phones/?brand=samsung&color=black
/catalog/phones/?brand=samsung&sort=priceНо нельзя автоматически закрывать все URL с параметрами. Некоторые фильтры могут соответствовать реальному поисковому спросу и быть полноценными посадочными страницами. Если такой URL закрыть в robots.txt, Google не сможет нормально обходить страницу.
Поэтому сначала необходимо разделить параметры на группы. Одни нужны только для сортировки, другие используются для пользовательской фильтрации, третьи могут формировать ценные SEO-страницы. Для каждой группы выбирается отдельная стратегия.
Также нужно учитывать дубли. Если разные параметры создают практически одинаковые страницы, проблема уже выходит за рамки одного robots.txt. В таком случае полезно дополнительно проверить материал «Дубли страниц на сайте», где рассматриваются canonical, 301, noindex, фильтры и варианты URL.
Главное правило здесь простое: не закрывать URL только потому, что в нем есть знак вопроса. Сначала нужно понять, что находится за этим параметром и зачем он нужен сайту.
Старые шаблоны robots.txt иногда содержат широкие запреты на папки со скриптами, стилями и другими ресурсами. Раньше владельцы сайтов часто закрывали такие директории просто потому, что считали CSS и JavaScript техническими файлами, которые поисковику видеть не нужно.
Для современных сайтов такой подход может быть проблемным. Google должен иметь возможность получить важные ресурсы страницы, чтобы корректно обработать и отобразить ее. Если критически важные ресурсы недоступны, поисковая система может получить неполное представление о странице.
Например, если robots.txt блокирует JavaScript, который формирует основной контент карточки товара, результат может отличаться от того, что видит обычный пользователь. Поэтому перед закрытием папок /js/, /css/, /assets/ и похожих каталогов нужно понять, какие ресурсы там находятся и используются ли они для отображения важного содержимого.
Для интернет-магазинов эта проверка особенно актуальна. Если после изменения robots.txt карточки товаров перестали нормально обрабатываться Google, нужно проверить не только URL самих товаров, но и доступность критических ресурсов. Если проблема касается каталога, дополнительно можно свериться с материалом «Почему карточки товаров не попадают в Google».
Robots.txt и sitemap.xml выполняют разные задачи. Первый управляет обходом URL, второй помогает поисковой системе обнаруживать важные адреса сайта. Поэтому наличие sitemap.xml не компенсирует ошибочный запрет в robots.txt.
Представим ситуацию: важная страница добавлена в sitemap.xml, но одновременно попадает под правило Disallow. Sitemap сообщает Google о существовании URL, однако robots.txt ограничивает его обход. Получается противоречивый набор сигналов.
Для основных страниц сайта нужно добиться понятной логики: важные URL доступны для обхода, присутствуют в нормальной структуре внутренних ссылок и при необходимости включены в sitemap.xml. Технические страницы, которые действительно не должны обходиться, не должны массово попадать в карту сайта.
Особенно полезно проверять эту связку после запуска нового раздела. Добавление сотен товаров или статей может выглядеть успешно в CMS, но если новый каталог оказался закрыт robots.txt, Google не сможет нормально его обработать.
Если новая страница не появляется в поиске, robots.txt является одной из первых проверок. Но не единственной. В отдельном материале «Новая страница не появляется в Google» мы разбирали полный алгоритм проверки новой страницы, включая индексацию, canonical, внутренние ссылки и технические ошибки.
Robots.txt и noindex часто путают. В первом случае речь идет об ограничении обхода URL, во втором о запрете индексации страницы, которую поисковый робот может просканировать.
Например, если есть служебная страница, которую пользователь должен иметь возможность открыть, но ее не нужно показывать в Google, может использоваться:
<meta name="robots" content="noindex">В такой ситуации Google должен получить доступ к странице, чтобы увидеть директиву noindex. Если одновременно закрыть URL через robots.txt, поисковый робот может не увидеть эту директиву.
Это одна из самых важных практических вещей при работе с индексацией. Нельзя просто добавить URL в Disallow и считать, что задача решена. Нужно понимать, требуется ли запрет обхода или запрет показа в поиске.
Для разных задач используются разные механизмы. Robots.txt подходит для управления обходом, noindex для исключения доступной страницы из результатов поиска, а удаление или редирект применяются в зависимости от дальнейшей судьбы URL.
Если страницы уже исчезли из индекса, дополнительно нужно посмотреть, что произошло с ними до появления проблемы. Возможно, изменился robots.txt, появилась директива noindex или URL стали возвращать ошибки. Такие ситуации подробно разобраны в статье «Страницы выпали из индекса: почему и как вернуть».
Проверять robots.txt нужно не только глазами. Для начала откройте сам файл по адресу /robots.txt и убедитесь, что сервер действительно отдает актуальную версию. Затем проверьте правила на конкретных важных URL.
В Google Search Console есть инструменты, позволяющие диагностировать проблемы обхода. Для конкретной страницы можно использовать URL Inspection и проверить, может ли Google получить доступ к URL. Для самого robots.txt Google предоставляет отдельные средства проверки и отчетности.
Проверять нужно не только одну страницу. Возьмите главную, несколько категорий, карточку товара, статью, страницу услуги и URL с параметрами, если они используются. Такой набор быстро показывает, не блокирует ли новое правило целый тип страниц.
После изменения robots.txt полезно повторно пройтись по основным разделам сайта. Особенно это важно после переноса, редизайна, изменения CMS или настройки нового SEO-плагина.
Если сайт крупный, стоит автоматизировать контроль. Например, можно регулярно проверять доступность ключевых URL и сравнивать текущий robots.txt с предыдущей версией. Тогда случайное изменение одного правила не останется незамеченным на несколько недель.
Если после изменения robots.txt страницы перестали индексироваться, сначала нужно восстановить доступ Googlebot к нужным URL. Не стоит сразу отправлять сотни запросов на повторную индексацию, если причина блокировки еще существует.
Сначала исправьте robots.txt и убедитесь, что важные страницы больше не попадают под Disallow. Затем проверьте noindex, HTTP-коды, canonical и доступность самого контента.
После исправления технической причины Google должен снова обнаружить страницы и обработать их. Для отдельных важных URL можно использовать URL Inspection, но массовую проблему лучше решать на уровне причины, а не вручную отправлять каждую страницу.
Если вместе с изменением robots.txt менялась структура сайта, нужно проверить и другие технические факторы. Например, после редизайна могли одновременно измениться URL, canonical, внутренние ссылки и sitemap.xml.
Если органический трафик уже значительно снизился, восстановление необходимо анализировать в комплексе. Помимо robots.txt нужно определить, какие страницы потеряли показы и позиции. Для такой диагностики пригодится материал «Почему сайт резко просел в поиске».
У интернет-магазина robots.txt обычно сложнее, чем у небольшого корпоративного сайта. В каталоге могут существовать фильтры, сортировки, поиск по сайту, корзина, личный кабинет, сравнение товаров, избранное и множество параметрических URL.
Но сложный robots.txt не обязательно означает хороший robots.txt. Наоборот, большое количество исключений повышает риск случайно закрыть полезный раздел.
Перед составлением правил нужно разделить URL по назначению. Карточки товаров, категории и SEO-посадочные страницы должны рассматриваться отдельно от корзины, служебных страниц и технических параметров.
Особое внимание нужно уделять фильтрам. Если фильтр создает страницу, которая имеет самостоятельный поисковый спрос, ее нельзя автоматически закрывать. Если же он генерирует огромное количество почти одинаковых URL, необходимо разработать отдельную стратегию управления такими страницами.
То же относится к карточкам товаров. Если Google перестал находить весь каталог, сначала проверяйте общий шаблон и robots.txt. Если проблема только у отдельных товаров, ищите локальную причину: дубли, canonical, отсутствие ссылок, слабый контент или особенности конкретного URL.
Для интернет-магазинов техническая оптимизация должна проводиться системно. Robots.txt является только одной частью общей структуры, а не самостоятельным способом продвижения.
Шаг 1. Откройте robots.txt. Проверьте, что файл доступен по адресу https://site.ru/robots.txt и сервер отдает актуальную версию.
Шаг 2. Проверьте User-agent. Убедитесь, что правила применяются именно к тем поисковым роботам, которых вы хотите ограничить.
Шаг 3. Найдите широкие Disallow. Особенно внимательно проверьте запреты для корня сайта, каталогов, разделов с товарами и папок, где находятся важные страницы.
Шаг 4. Проверьте Disallow: /. Такое правило требует особого внимания. На рабочем сайте оно может полностью изменить доступ поискового робота к ресурсу.
Шаг 5. Проверьте важные URL. Главная, категории, карточки товаров, услуги и статьи не должны случайно попадать под запрет.
Шаг 6. Проверьте параметры. Не закрывайте все URL со знаком вопроса автоматически. Сначала определите назначение параметров.
Шаг 7. Проверьте фильтры. Разделите полезные SEO-страницы и технические комбинации фильтров.
Шаг 8. Проверьте CSS и JavaScript. Убедитесь, что важные ресурсы страницы не заблокированы широкими правилами.
Шаг 9. Сравните robots.txt и sitemap.xml. В sitemap не должны массово попадать URL, которые одновременно закрыты от обхода.
Шаг 10. Проверьте noindex отдельно. Если задача заключается в исключении страницы из поиска, убедитесь, что выбран правильный механизм.
Шаг 11. Проверьте Search Console. Посмотрите отчет индексирования и используйте URL Inspection для важных страниц.
Шаг 12. Сравните с предыдущей версией. Если падение началось после изменения robots.txt, найдите конкретное изменение и сопоставьте его с датой проблемы.
Шаг 13. Проверьте сайт после исправления. Не ограничивайтесь самим robots.txt. Повторно проверьте важные URL, индексацию и органический трафик.
Если сайт регулярно развивается, появляются новые разделы, карточки товаров и фильтры, проверку robots.txt лучше включить в постоянное техническое обслуживание. При комплексном SEO-продвижении сайта этот файл должен рассматриваться вместе со структурой URL, внутренними ссылками, sitemap.xml, canonical и настройками индексации.
Проведём технический аудит сайта и покажем, какие проблемы мешают росту позиций и заявок.
Получить консультациюОтветы на основные вопросы о robots.txt, запрете обхода, noindex, индексации страниц и влиянии технических настроек на SEO.
Да. Широкое правило вроде Disallow: / для соответствующего User-agent может запретить поисковому роботу обход всего сайта. Поэтому такие правила на рабочем домене необходимо проверять особенно внимательно, особенно после переноса, редизайна или изменения CMS.
Нет. Robots.txt управляет доступом поискового робота к URL, но не является надежным механизмом удаления страницы из результатов поиска. Если Google узнает о заблокированном URL из других источников, сам адрес в некоторых случаях все равно может появиться в поиске.
Эти инструменты решают разные задачи. Если страница доступна Googlebot, но ее не нужно показывать в поиске, обычно используется директива noindex. Robots.txt применяется для управления обходом URL. Поэтому выбор инструмента зависит от того, нужно ли запретить именно обход или исключить доступную страницу из поисковой выдачи.
Не все фильтры нужно автоматически закрывать от поисковых роботов. Сначала необходимо определить, какие комбинации имеют самостоятельный поисковый спрос и могут быть полезны пользователям. Остальные технические варианты можно рассматривать в рамках общей стратегии управления параметрами и индексацией сайта.
Не следует блокировать CSS и JavaScript автоматически. Если эти ресурсы необходимы для отображения страницы или корректного понимания ее содержимого, ограничение доступа может мешать поисковому роботу правильно обработать страницу. Поэтому перед добавлением запрета важно определить назначение конкретного ресурса.
Наличие URL в sitemap.xml не гарантирует его индексацию. Нужно проверить robots.txt, HTTP-код ответа, noindex, canonical, внутренние ссылки и содержание страницы. Sitemap помогает поисковой системе обнаружить URL, но не заменяет остальные технические и контентные сигналы.
Если важные URL оказались под правилом Disallow, Google может перестать нормально обходить их содержимое. Однако само совпадение по времени не доказывает причину падения. Необходимо сравнить предыдущую и текущую версии robots.txt, определить затронутые URL и проверить их состояние через Search Console.
Сначала необходимо определить, действительно ли такой запрет нужен. Если карточки являются важными коммерческими страницами, правило следует исправить, после чего проверить доступность URL и их индексацию. Дополнительно можно изучить статью «Почему карточки товаров не попадают в Google».
Да, если из-за некорректного правила поисковый робот перестает обходить важные страницы или ресурсы, необходимые для их обработки. Но при резком падении трафика не стоит автоматически считать robots.txt причиной. Нужно сопоставить дату изменения файла с просадкой, определить затронутые URL и проверить другие технические факторы.
Универсального интервала для всех сайтов нет. Особенно важно проверять robots.txt после переноса сайта, редизайна, изменения CMS, внедрения фильтров, изменения структуры URL и других крупных технических работ. Для активно развивающихся проектов полезен регулярный автоматический контроль файла.
Да. Для начала достаточно открыть файл, изучить его правила и проверить несколько важных URL с помощью инструментов Google Search Console. На крупных сайтах желательно дополнительно использовать технический сканер, который позволит проверить большое количество адресов и выявить системные ошибки в настройках обхода.