Поисковик не обязан видеть ваш сайт целиком
Типичная картина: сайт сделан, страницы услуг написаны, карточки товаров заполнены, а в поиске находится главная и ещё пара случайных адресов. Владелец идёт в агентство за ссылками и текстами, хотя проблема лежит на два уровня ниже, в двух служебных файлах, которые никто не открывал с момента запуска. Файл robots txt решает, какие страницы робот вообще пойдёт смотреть, а карта сайта sitemap xml сообщает ему, о каких страницах стоит узнать.
За последние годы мы разбирали десятки сайтов в Алматы, Астане и Караганде, где падение трафика объяснялось одной строкой в robots.txt. Ниже то, что ломается чаще всего, и то, как проверить это у себя за полчаса.
Что делает robots.txt и чего он не делает
Первое заблуждение, из-за которого потом возникают долгие споры с подрядчиком: robots.txt управляет обходом, но не индексированием. Google формулирует это прямо: robots.txt «не является механизмом, позволяющим скрыть веб-страницу из результатов поиска». Если на закрытый адрес ведут ссылки с других сайтов, Google может показать его в выдаче, без описания, одним заголовком со ссылки.
Яндекс говорит то же самое своими словами: ограниченные в robots.txt страницы могут участвовать в поиске Яндекса, а чтобы исключить их, нужна директива noindex в HTML-коде или в HTTP-заголовке.
Отсюда вытекает ловушка, которую мы встречаем почти на каждом втором аудите. Разработчик хочет убрать страницу из выдачи и делает сразу две вещи: ставит на неё метатег noindex и на всякий случай закрывает её в robots.txt. Результат получается обратный. Робот не скачивает HTML закрытой страницы, значит, не видит метатег, и адрес остаётся в базе. Чтобы noindex сработал, страница должна быть открыта для обхода.
Правильное разделение выглядит так. Robots.txt закрывает то, что роботу незачем качать: результаты внутреннего поиска, корзину, личный кабинет, служебные скрипты, бесконечные фильтры. Метатег noindex убирает из выдачи то, что должно оставаться доступным людям, но не должно ранжироваться: страницы благодарности, версии для печати, технические разделы.
Ошибки в robots.txt, из-за которых страницы пропадают
Сайт закрыт целиком после переноса с тестового домена
На стадии разработки в файле стоит Disallow: /, чтобы недоделанный сайт не попал в поиск. При переезде на боевой домен строку забывают убрать. Симптом узнаваемый: сайт работает месяц, а в поиске только старые адреса или вообще пусто. На WordPress к этому добавляется галочка «Попросить поисковые системы не индексировать сайт» в настройках чтения, про которую разработчик тоже забывает.
Закрыты CSS и JavaScript
Наследие старых инструкций по безопасности: закрыть /wp-content/, /bitrix/, /templates/ целиком. Робот в этом случае получает страницу без стилей и скриптов и не может оценить, что видит пользователь, особенно на мобильных. Google рекомендует не блокировать файлы ресурсов, если они важны для понимания страницы. Закрывать служебные каталоги можно, но с исключениями через Allow для файлов оформления.
Файл лежит не там, где его ищут
Правила из robots.txt действуют только для того хоста, протокола и порта, на котором лежит сам файл. То есть https://site.kz/robots.txt ничего не говорит роботу про https://shop.site.kz/. У поддомена должен быть свой файл. Отдельная история, когда сайт остался доступен и на www, и без www, и по http: там легко получить четыре разных robots.txt, из которых обновляется один.
Сервер отдаёт не тот код ответа
Google трактует коды ответа для robots.txt по-разному. Ошибка 4xx (кроме 429) означает «файла нет, ограничений нет», и сайт обходится целиком. Код 5xx хуже: Google приостанавливает обход, до 30 дней использует сохранённую копию файла и только потом считает, что ограничений нет. Хостинг, который под нагрузкой отдаёт 503 вместо robots.txt, тормозит обход всего сайта. Яндекс требует, чтобы файл отвечал кодом 200 OK, редирект на другой robots.txt допускается, если по итогу цепочки приходит 200.
Кириллица в правилах
Яндекс запрещает использовать кириллические символы в robots.txt: домены записываются в Punycode, адреса страниц кодируются. Сайты с человекопонятными русскими URL иногда получают файл, который робот просто не понимает.
Устаревшие директивы
Crawl-delay Яндекс не учитывает с 22 февраля 2018 года, скорость обхода задаётся в Яндекс Вебмастере в разделе «Скорость обхода». Google из директив поддерживает четыре: user-agent, allow, disallow и sitemap. Всё остальное, что вы найдёте в чужих шаблонах robots.txt, для этих двух поисковиков лишнее.
Конфликт правил решается не так, как кажется
Google выбирает наиболее конкретное правило по длине пути, а при равной длине наименее строгое, то есть Allow выигрывает у Disallow. Названия директив регистронезависимы, а вот пути чувствительны к регистру: /Katalog/ и /katalog/ для робота разные адреса. Поддерживаются подстановочный знак * и символ $ для конца адреса. Из-за этого правило вида Disallow: /*?, написанное ради «мусорных параметров», иногда закрывает половину каталога с фильтрами, которые как раз приносили трафик.
Как проверить robots.txt в Google и Яндексе
В Google Search Console есть отчёт robots.txt: он показывает, какие файлы Google нашёл для основных хостов сайта, когда обошёл их последний раз, и подсвечивает ошибки в содержимом. Там же запрашивается повторное сканирование, если файл только что поправили. Это важно, потому что содержимое robots.txt кэшируется примерно на сутки: отредактировали файл утром, не ждите реакции к обеду.
Для проверки конкретного адреса удобнее инструмент проверки URL в той же консоли. Он отвечает, доступна ли страница для робота и что мешает индексированию.
В Яндекс Вебмастере проверка robots.txt живёт в разделе инструментов: туда подставляется содержимое файла и список адресов, а сервис показывает, разрешён каждый из них или запрещён. Полезная деталь: у Яндекса есть отдельная настройка GET-параметров, и если она противоречит robots.txt, робот выберет правило, которое запрещает индексирование адресов с параметрами.
Если вы ведёте сайт сами, заведите привычку открывать site.kz/robots.txt в браузере после каждого обновления CMS и после каждой работы подрядчика. Половина инцидентов ловится этим движением.
Sitemap.xml: откуда он берётся и почему бывает бесполезен
Карта сайта это список адресов, который вы передаёте поисковику, чтобы он быстрее узнал о страницах. Индексирование она не гарантирует, но заметно ускоряет обнаружение новых страниц на крупных сайтах и на сайтах со слабой внутренней перелинковкой.
На WordPress карту обычно генерирует SEO-плагин. У Yoast SEO индекс карты доступен по адресу /sitemap_index.xml и содержит ссылки на отдельные карты записей, страниц, рубрик, меток и авторов, обновляется он автоматически при добавлении и удалении материалов. У 1С-Битрикс карта настраивается в модуле поисковой оптимизации, и там важно помнить про регулярную перегенерацию на боевом сайте. Самый рискованный вариант это статический файл sitemap.xml, который когда-то выгрузили внешним сервисом и положили в корень: он устаревает в тот же день.
Типичная находка на аудите: у сайта одновременно три карты. Одна от плагина, одна старая статическая, одна от предыдущего подрядчика в robots.txt. Робот честно обходит все три и видит в них взаимоисключающие данные.
Ошибки в sitemap.xml
Относительные адреса
В карте должны быть полные адреса вида https://site.kz/uslugi/. Запись /uslugi/ не работает, Google требует абсолютные URL.
В карте страницы, которых там быть не должно
Адреса с редиректами, ошибки 404, страницы с noindex, адреса с canonical на другую страницу. Поисковик получает противоречивый сигнал: в карте вы просите обойти страницу, а на самой странице просите её не индексировать. На доверие к карте это влияет плохо.
Ставка на priority и changefreq
Google игнорирует значения <priority> и <changefreq>. Расставлять приоритеты вручную, надеясь повлиять на порядок обхода, бессмысленно.
Недостоверный lastmod
Google использует значение <lastmod>, когда оно последовательно и достоверно отражает существенные изменения содержимого, структурированных данных или ссылок. Если движок проставляет вчерашнюю дату всем пяти тысячам страниц после каждой пересборки кэша, значение перестаёт что-либо значить. Обратная ошибка тоже встречается: реальное обновление статьи не меняет lastmod, и робот приходит за новой редакцией через месяц.
Превышены лимиты
Один файл карты ограничен 50 000 адресов и 50 МБ в несжатом виде. Для крупного каталога делают несколько карт и индексный файл, который на них ссылается.
Карта закрыта в robots.txt
Курьёзная, но живучая ошибка: правило Disallow: /*.xml$ закрывает и саму карту.
Карта нигде не заявлена
Её можно указать директивой Sitemap: в robots.txt, добавить в отчёте «Файлы Sitemap» в Search Console и в разделе файлов Sitemap Яндекс Вебмастера. Разумно сделать всё сразу, это минуты работы.
Как связать два файла, чтобы они не мешали друг другу
В карте должны быть только те адреса, которые вы хотите видеть в поиске: открытые для обхода, отвечающие кодом 200, с canonical на самих себя. В robots.txt закрываются служебные разделы и указывается путь к карте.
Минимальный работающий файл для сайта услуг на WordPress выглядит примерно так:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /?s= Disallow: /cart/ Disallow: /checkout/ Clean-param: utm_source&utm_medium&utm_campaign Sitemap: https://site.kz/sitemap_index.xml
Директива Clean-param из набора Яндекса, она сообщает роботу, что адреса с этими метками не нужно загружать повторно как дубли. Google её не понимает и просто пропустит. Кстати, базовый набор правил WordPress отдаёт сам: если физического файла robots.txt в корне нет, движок формирует виртуальный с запретом на /wp-admin/ и разрешением на admin-ajax.php. Как только вы кладёте в корень свой файл, виртуальный перестаёт использоваться, и всё содержимое становится вашей ответственностью.
Отдельно про каталоги и фильтры. Универсального шаблона здесь нет: часть фильтрованных страниц приносит целевой трафик по запросам вроде «диван угловой раскладной алматы», а часть плодит тысячи одинаковых адресов. Решение принимается по данным вашего сайта, а не по чужому robots.txt из интернета. Если такую работу нужно сделать один раз и правильно, это часть технического аудита: можно заказать SEO-продвижение сайта и начать с разбора индексации, а не с закупки ссылок.
Почему карта сайта не спасает страницы-сироты
Есть ожидание, что достаточно добавить адрес в sitemap.xml и страница займёт своё место в выдаче. На практике карта работает как подсказка. Поисковик самостоятельно решает, что обходить и что оставлять в индексе, и ориентируется он в первую очередь на ссылки внутри сайта.
Страница, на которую не ведёт ни одна внутренняя ссылка, называется страницей-сиротой. Формально она существует, открывается по прямому адресу и честно перечислена в карте. Но для робота это адрес без контекста: непонятно, насколько он важен, к какому разделу относится, какими словами его описывают на самом сайте. Такие страницы либо обходятся редко, либо попадают в индекс и висят там без показов.
Чаще всего сиротами становятся посадочные страницы под рекламу, старые акции, карточки товаров, выпавшие из категорий после переноса каталога, и статьи блога, которые ушли из ленты после десятка новых публикаций. На сайтах с большим каталогом к этому добавляется пагинация: если ссылки на вторую и последующие страницы списка подгружаются скриптом, робот до карточек в глубине каталога просто не доходит.
Лечится это структурой, а карта тут помогает мало. Раздел должен ссылаться на подразделы, подраздел на карточки, статья на смежные статьи и на страницу услуги. Как только у страницы появляются входящие ссылки с понятным текстом, меняется и частота обхода, и то, по каким запросам страница начинает показываться. Карта при этом остаётся полезной: она ускоряет первое знакомство с новыми адресами, особенно когда сайт большой и обновляется каждый день.
Практический вывод для владельца: если страниц в карте тысяча, а трафик идёт на полсотни, дело чаще в навигации, чем в служебных файлах. Тут помогает связка из двух отчётов: «Страницы» в Search Console и «Страницы в поиске» в Яндекс Вебмастере, где видно, какие адреса поисковики обошли, какие отбросили и по какой причине.
Пример: 1200 страниц каталога и 80 в индексе
Для иллюстрации соберём типичную ситуацию из нашей практики. Интернет-магазин оборудования переехал с самописного движка на новую CMS. Через три месяца после переезда владелец жалуется: трафик из Google упал втрое, в Яндексе позиции держатся по главной, карточки товаров не находятся.
Что обнаруживается при проверке. В корне лежит robots.txt, перенесённый с тестового поддомена, где стоял запрет на весь каталог /catalog/: на тесте это делали, чтобы не плодить дубли. Карта сайта генерируется, но лежит по адресу /sitemap.xml, а в robots.txt указан старый путь к файлу, которого больше нет. Плюс в карте перечислены адреса со старой структурой, которые теперь отдают редирект.
Порядок работ в таком случае: убрать запрет на каталог, привести карту в соответствие с новой структурой, указать актуальный путь директивой Sitemap, отправить карту в обе панели вебмастера и запросить переобход ключевых разделов. Дальше остаётся ждать, обход большого каталога занимает недели, и ускорить его радикально невозможно. Именно поэтому такие вещи проверяют до переезда. Когда мы ведём разработку сайта под ключ, состояние индексации фиксируется до и после запуска, чтобы потери было видно сразу.
Что проверить у себя за полчаса
Откройте site.kz/robots.txt и прочитайте файл целиком. Убедитесь, что там нет Disallow: / и нет запретов на разделы, которые должны продаваться.
Проверьте адрес карты сайта из директивы Sitemap: он должен открываться и отдавать актуальный список страниц.
Возьмите пять важных страниц и прогоните через инструмент проверки URL в Search Console и через проверку в Яндекс Вебмастере. Если робот не может получить страницу, причина будет указана.
Сравните число страниц в карте с числом проиндексированных в отчёте «Страницы» Search Console. Разрыв в разы это повод разбираться дальше.
Посмотрите в Search Console статус «Проиндексировано, несмотря на блокировку в файле robots.txt». Он означает ровно то, что описано выше: адрес закрыт от обхода, но попал в выдачу, и убрать его оттуда запретом в robots.txt не получится.
Проверьте поддомены. У блога, магазина и лендинга на поддоменах свои файлы robots.txt, и про них забывают чаще всего.
Эти проверки не заменяют полноценный технический аудит, но снимают большую часть случаев, когда сайт «не индексируется без причины». Причина почти всегда есть, и лежит она в двух текстовых файлах.
Частые вопросы
Если закрыть страницу в robots.txt, она исчезнет из поиска?
Нет. Robots.txt управляет обходом. Страница, на которую ведут ссылки, может остаться в выдаче без описания. Для исключения из поиска нужен метатег noindex или HTTP-заголовок, и страница при этом должна быть открыта для обхода.
Нужен ли sitemap.xml небольшому сайту на 20 страниц?
Для сайта с нормальной перелинковкой и понятным меню карта меняет мало: робот и так дойдёт до всех страниц. Вреда от неё нет, делается она автоматически, поэтому проще иметь, чем обосновывать отсутствие.
Как быстро поисковик заметит правку в robots.txt?
Google кэширует файл примерно на сутки, ускорить можно запросом повторного сканирования в отчёте robots.txt в Search Console. Яндекс перечитывает файл при очередном обходе сайта.
Что делать с дублями от UTM-меток?
Для Яндекса подойдёт директива Clean-param, для обоих поисковиков корректный canonical на страницу без параметров. Закрывать параметры через Disallow: /*? опасно: под правило попадают полезные фильтры и пагинация.
Можно ли взять готовый robots.txt из интернета?
Для типовой сборки WordPress базовая часть действительно одинакова. Дальше начинается специфика: структура каталога, фильтры, языковые версии, поддомены. Чужой файл с запретом на /catalog/ в вашей CMS способен обнулить весь коммерческий трафик.
Если после проверки картина не сложилась, а страницы по-прежнему не появляются в выдаче, имеет смысл посмотреть на сайт целиком: коды ответов, скорость загрузки, дубли, структуру и внутренние ссылки. С индексации начинается всё остальное, и разбираться с ней обычно дешевле, чем с тем, что идёт дальше.