robots.txt: настройки сканирования без бубна

Как показывает практика, база технического SEO – файл robots.txt, – многими вебмастерами не только заполняется неправильно, но и без понимания, зачем этот файл и как он работает. Статей на эту тему – объективно, тонны, но есть смысл расставить некоторые акценты.

robots.txt: настройки сканирования без бубна

Для чего вообще нужен robots.txt

В интернете можно найти много глупых советов по настройкам robots.txt. Люди советуют управлять с его помощью доступами, предлагают какие-то типовые шаблонные списки инструкций, пытаются что-то удалять таким образом из индекса.

robots.txt предназначен для единственной цели: управлять сканированием сайта на базе «Стандарта исключений для роботов». Это не инструмент для управления индексацией, и если вы попытаетесь управлять с его помощью попаданием ваших страниц в индекс, неизбежно получите ошибки и проблемы. И чем больше и сложнее ваш сайт – тем больше будет ошибок. Для управления индексацией используйте предназначенные для этого инструменты:

  • метатег robots

  • канонические адреса (canonical)

  • редиректы
  • ссылки

С его помощью можно указать поисковым роботам, какие URL не должны сканироваться, а какие сканировать можно и нужно. Это не команды: поисковые роботы могут проигнорировать запрещающие и разрешающие директивы, если получат более весомые сигналы это сделать. Простой пример: если на страницу ведёт достаточное количество ссылок, она появится в выдаче – хотя саму страницу поисковик скачивать и не будет.

Важно понимать: robots.txt – не закон для роботов, а просто список пожеланий с достаточно противоречивой историей. Несмотря на необязательность директив, например, гуглобот не станет сканировать ваш сайт, если сервер ответит технической ошибкой на запрос «роботс». И вместе с тем, легко проигнорирует запреты, если получит сигналы о важности какого-то URL в рамках сайта (наличие ссылок, настройка перенаправлений, постоянный пользовательский трафик и т.п.).

Что не нужно сканировать

  • Системные папки на сервере

  • Дубли: сортировки, UTM-метки, фильтры и прочие URL с параметрами

  • Страницы пользовательских сессий, результаты поиска по сайту, динамические URL
  • Служебные URL
  • Административная часть сайта

К чему должен быть обязательный доступ

  • Посадочные страницы

  • Служебные файлы, отвечающие за рендеринг страницы (js, css, шрифты, графика)

Особое внимание обращу на обязательное наличие разрешений на сканирование JS и CSS. Если поисковые системы не смогут отрисовать страницы сайта в том виде, в каком их получает посетитель-человек, это приведёт к следующим проблемам:

  • Поисковая система может счесть, что сайт не адаптирован для мобильных устройств.

  • Если важная часть контента выводится средствами JS, поисковая система просто не получит к нему доступа. В ряде случаев вместо контента ПС увидят обычную дырку или малую часть контента. В индекс такая страница едва ли попадёт, а если и попадёт – высоко ранжироваться не будет. В обоих случаях результатом будут сниженные позиции в поиске или полное их отсутствие: мусор в поисковой выдаче не нужен.

Зачем нужны отдельные секции для поисковых роботов

Оставлять единый блок директив для всех поисковых роботов – плохая идея, и вот почему.

Поисковые роботы Яндекса и Гугла в ряде случаев совершенно по-разному воспринимают директивы, потому и что и правила сканирования у них разные. Вот лишь несколько главных отличий.

  • Яндекс плохо работает с метатегами robots и каноническими адресами. Директивы в robots.txt для него важнее. Если вы разрешите ему сканировать то, что не должно попасть в индекс, он с большой степенью вероятности проигнорирует всё остальное, и может начать ранжировать вовсе не то, что вам надо. Скажем, нецелевую страницу пагинации - просто потому, что ему что-то не понравилось на целевой странице.

  • Яндекс использует директивы, которые не признаёт Google, например, Clean-param. Есть и директивы, которые понимает только гуглобот.
  • Хорошая идея - минимально блокировать сканирование для гуглобота, индексацией управляя только на уровне страницы. Таким образом Гугл будет лучше понимать ваш сайт, а алгоритмы там достаточно умные, чтобы и без вашего участия разобраться, что к чему. Если же по логам вы отмечаете ненормальную активность гуглобота там, где не надо – это повод подумать, что не так с сайтом.
  • Если гуглобот зайдёт на сайт и не сможет скачать robots.txt, он уйдёт. Яндекс-бот в такой придирчивости не замечен.

Общий принцип: открывайте для Яндекса по необходимости. Для Гугл – по необходимости закрывайте.

Для Яндекса вы должны понимать, что у вас должно быть в индексе. Для Гугл – наоборот, чего в индексе быть не должно.

Активность Яндекс-бота в рунете кратно превышает активность гуглобота, которая в принципе лимитирована. Это ещё одно условие, которое надо учитывать при составлении директив для robots.txt.

Можно ли блокировать на уровне robots.txt зловредных ботов и парсеры

Каждый сайт посещает множество роботов, и не все они вам нужны. Это могут быть роботы-парсеры, которые используют ваши конкуренты для извлечения информации, многочисленные SEO-сервисы, которые могут предоставлять информацию о вашем сайте конкурентам и т.п. Пользы для сайта от них нет, а нагрузку на сервер они создают. Стоит ли пытаться запрещать им сканирование в robots.txt?

Нет. Набор инструкций на базе стандарта исключений имеет рекомендательный характер, и фактически ограничить ничего не может. Если вы хотите заблокировать посторонних роботов – делать это надо на уровне сервера. Чаще всего в robots.txt пытаются заблокировать самых известных официальных ботов типа AhrefsBot, MJ12bot, Slurp, SMTBot, SemrushBot, DotBot, BLEXBot и т.п. Смысла это не имеет, но вы можете попробовать.

Что будет, если robots.txt не заполнен или заполнен неправильно

Недоступность файла с директивами по техническим причинам (ошибки 5**) может привести к тому, что гуглобот не станет сканировать сайт. Отсутствие же файла приведет к тому, что роботы будут обходить всё подряд и накидают в индекс тонны мусора. Чаще всего это не очень страшно. А вот ошибки в директивах могут привести к достаточно широкому спектру проблем. Вот типовые:

  • Поисковая система не сможет отрисовать адаптивную вёрстку вашего сайта, потому что не может получить доступ к файлам шаблона, и решит, что сайт не подходит для просмотра на смартфонах.

  • Часть контента или оформления не будет просканирована или учтена, если выводится она средствами JS, а доступ к ним заблокирован.
  • Если в robots.txt запрещено сканирование страниц, которые вы хотели бы удалить из индекса, деиндексированы они не будут – робот просто не увидит ваших указаний в рамках страницы, а в панели вебмастеров вы увидите соответствующее уведомление («Проиндексировано, несмотря на блокировку в файле robots.txt»).
  • Без запрета на сканирование определенных страниц (пользовательских, с параметрами) поисковая система будет вносить в индекс явный мусор, который через время будет выбрасывать. В случае Яндекса это может быть чревато переклейкой запросов на нецелевые страницы, рост страниц, рассматриваемых как некачественные, и как следствие – снижения доверия к сайту на уровне хоста.
Ошибки в настройках сканирования – и вот уже поисковому роботу недоступен целый блок, куда выводится портфолио веб-студии.
Ошибки в настройках сканирования – и вот уже поисковому роботу недоступен целый блок, куда выводится портфолио веб-студии.

Простенькие сайты на той же «Тильде» чаще всего вообще не нуждаются в правках robots.txt – там разрешено всё, и нет никаких проблем ни с отрисовкой сайта, ни с попаданием в индекс поискового мусора. Интерпретаторы современных ПС довольно снисходительно относятся к возможным ошибкам, однако надеяться на это не стоит.

Основные правила

Заполнение файла директив должно соответствовать правилам, игнорирование которых может привести к критическим ошибкам сканирования и непредсказуемым багам обхода сайта. Перечислим основные.

  • Файл может называться только "robots.txt" с названием в нижнем регистре, быть в кодировке UTF-8 без BOM, и находиться в корне сайта.

  • Никакой кириллицы в robots.txt быть не должно! Если вы используете домен в зоне РФ или кириллические адреса – для настроек robots.txt используйте конвертацию таких URL в пуникод. Например, директива Sitemap в данном случае будет выглядеть примерно так:
    Sitemap: http://xn--80aswg.xn--p1ai/sitemap.xml
  • Каждая новая директива начинается с новой строки.
  • Блок директив для каждого User-agent отделяется от других блоков пустой строкой. Пустая строка между директивами обрывает список, после пустой строки начинается новый блок.
  • Все запрещающие или разрешающие директивы относятся только к боту, указанному для заданного блока.
  • Порядок размещения разрешающих и запрещающих директив особого значения не имеет. В настоящий момент это свойственно и роботам Яндекса, и Google.

Регулярные выражения и подстановочные знаки

Регулярные выражения и подстановочные знаки значительно упрощают процесс настройки сканирования. Официально они не поддерживаются стандартами, и тем не менее, понимают их все роботы. Ваша задача – составить регулярное выражение, блокирующее сканирование всего поискового мусора и разрешить необходимые URL, а не вносить туда десятки и даже сотни URL (как иногда пытаются делать). Отдельные URL, ненужные в выдаче по каким-то причинам, нужно просто запрещать индексировать метатегом.

Пример заполнения robots.txt в стиле "Знай наших" школы SEO-кунгфу "Раззудись плечо" - и это ещё не весь список
Пример заполнения robots.txt в стиле "Знай наших" школы SEO-кунгфу "Раззудись плечо" - и это ещё не весь список

Для формирования регулярных выражений в рамках "роботс" используется всего два знака: * и $.

Знак * означает любую последовательность символов, "что угодно". Примеры.

User-agent: * Disallow: /*?

Это означает, что для любого робота (если для него нет отдельного набора директив) запрещено сканирование любых страниц фильтров.

User-agent: * Allow: */*.jpg*

Разрешено сканирование файлов JPG с любым названием в любой доступной папке сайта, включая кэшированные файлы.

Знак $ соответствует концу заданного URL. Те URL, что содержат какие-то знаки после знака $, могут быть просканированы. Пример:

User-agent: * Disallow: */*.pdf$

Эта директива запрещает сканировать любой файл в формате PDF в рамках сайта. Ещё один пример:

Disallow: */ofis$

Будет заблокирован URL https://сайт-ру/catalog/muzhchinam/ofis

Но URL https://сайт-ру/catalog/muzhchinam/ofis?sort=rate&page=1 будет доступен.

Как составить правильный robots.txt для своего сайта

Как уже было сказано выше, гуглобот не станет сканировать сайт, если не найдёт robots.txt, поэтому для начала можно использовать даже шаблонный «роботс» (как многие и поступают). Однако это явно не оптимальный вариант.

Чтобы составить правильный robots.txt для своего сайта, вы должны чётко понимать два момента:

  • Какова структура вашего сайта, и что поисковый робот должен обходить и понимать;

  • Как поисковый робот видит ваш сайт.

На первый вопрос вам поможет ответить семантическое ядро и структура сайта, созданная на его основе. Мы не будем разбирать здесь вопросы структурирования.

На второй же вопрос вам поможет ответить парсер сайта, способный эмулировать заданных поисковых роботов, показать наглядно, как поисковых робот отрисовывает страницу по актуальным правилам, справляется ли он с рендерингом адаптивной версии сайта и т.п. С этой целью я использую Screaming Frog SEO Spider. Думаю, эти возможности есть и у его конкурентов.

  • В настройках парсинга выбираем Spider - Extraction - HTML (отметить Store HTML и Store Rendered HTML). Там же - вкладка Rendering, выбрать в выпадающем списке JavaScript.

  • Потом в Configuration выбрать User-Agent эмуляцию интересующего робота. Я рекомендую начинать с Googlebot (Smartphone).
  • Хорошая практика – сразу же подключить API Search Console, чтобы выгрузить данные об индексации и оттуда. Для этого, разумеется, у вас должен быть такой доступ, такие данные о чужом сайте вытянуть не получится.
Полноценный рендеринг сайта позволит вам увидеть его глазами поискового робота
Полноценный рендеринг сайта позволит вам увидеть его глазами поискового робота

Можно начинать парсинг. По окончании запустите Crawl Analysis, и можно приступать к изучению результатов.

Поскольку нас в данном случае интересует список проблем с файлом robots.txt начнём с вкладки Rendered Page - там можно посмотреть, как видит робот выбранную страницу.

Если всё совсем плохо, вы увидите тлен и безнадёжность: отсутствие внятной вёрстки, пустые блоки, абсолютно нечитабельный контент.

Как вариант – контент может быть в основном доступен, просто без ожидаемого дизайна, дырками на месте картинок и т.п. Здесь же можно сразу посмотреть, что именно заблокировано и мешает роботу увидеть сайт так, как видите его вы. Если в списке заблокированных ресурсов вы видите js, css, файлы изображений, веб-шрифты – вносите их в список разрешающих директив.

В левом окне мы видим заблокированные папки, содержащие файлы шаблона. Их отсутствие приводит к тому, что робот видит сайт так, как показано в правом окне.
В левом окне мы видим заблокированные папки, содержащие файлы шаблона. Их отсутствие приводит к тому, что робот видит сайт так, как показано в правом окне.

Внимательно изучите все страницы, которые так или иначе помечены как дубли – по тайтлам, по сходству контента и т.п. Вероятно, среди них действительно могут оказаться дубли и поисковый мусор. Дубли могут быть как чисто техническими (например, товары могут выводиться плиткой, а могут списком), а могут быть и качественными, когда полезного контента на странице недостаточно, и она похожа на другие страницы, такие же некачественные с точки зрения ПС. В данном случае вам предстоит решить, что делать: закрыть мусор от сканирования, запретить индексацию метатегом, или оперативно внести правки и отправить URL на переобход.

На следующем шаге вам предстоит изучить данные из панелей вебмастеров. Достаточно удобно и наглядно это реализовано в Яндекс-Вебмастере. Заходим в «Индексирование», «Страницы в поиске», вкладка «Исключенные» – и внимательно оцениваем URL, помеченные как неканонические, дубли, а также МПК. Среди них, как правило, большую часть представляют страницы сортировок, фильтров, пагинации и т.п. Их чаще всего можно смело вносить в список для запрета на сканирование.

Инструменты для тестирования

Любые внесенные правки должны проверяться с помощью соответствующих инструментов поисковых систем.

Принцип действия прост: вы видите актуальную кэшированную версию файла, анализатор, инструмент проверки заданных URL. Если URL заблокирован – вы увидите строку, которая его блокирует.

Заключение

Подытожим основные тезисы.

  • Файл robots.txt не предназначен для управления индексированием сайта. Он нужен для настроек сканирования.

  • Интерпретация синтаксиса файла и имеющиеся директивы зависят от конкретной поисковой системы. Не забывайте проверять, как именно заданная ПС обрабатывает ваши директивы с помощью соответствующих инструментов.
  • Проверяйте доступность файлов css, js, jpg, jpeg, gif, png, svg, woff и прочих, необходимых для правильного рендеринга страницы поисковой системой.
  • Подстановочные знаки и регулярные выражения могут значительно упростить процесс настройки, но ошибки в их использовании могут заблокировать доступ роботов к целым разделам сайта.
  • Запрет сканирования не означает деиндексацию. То, что ПС посчитает важным, будет внесено в индекс, если нет прямых запретов на уровне заголовков Meta Robots Tag или X-Robots-Tag.
  • Маленькие сайты с простой архитектурой могут обойтись без файла инструкций для роботов без ущерба для сканирования и индексации.

UPD. Для настроек индексирования сайта рекомендую использовать метатег Robots, HTTP-заголовок X-Robots-Tag, настройки тега Canonical, а также вполне традиционные средства – редиректы, sitemap.xml и т.п.

37
36 комментариев

Яша часто подтупливает и кидает в индекс урлы с параметрами даже если есть каноникал.

Если стоит cloudflare или льется тьма трафа с utm в секции yandexbot надо дописать это:

Clean-param: __cf_chl_jschl_tk__ /*
Clean-param: __cf_chl_captcha_tk__ /*
Clean-param: __cf_chl_managed_tk__ /*
Clean-param: __cf_chl_tk /*
Clean-param: __cf_chl_f_tk /*
Clean-param: __cf_chl_rt_tk /*
Clean-param: utm

3
Ответить

более того, яндекс возмущается и считает критической ошибкой наличие незакрытых гет-параметров. Хотя казалось бы, вот те каноникал, вот те карта сайта

4
Ответить

каноникал как раз такие вообще не защищает от индексации, если вдруг будет много ссылок на страницы каноникала или она будет в карте сайта или случайно в переобход пустить, проиндексируется как миленька и еще все остальное с собой потянет. Закрывая в роботс страницы фильтрации прекрасно решается проблема с их индексацией. Автор конечно все правильно говорит, но это скорее как по учебнику, какая основная задумка роботс тхт, однако в реальной жизни люди используют роботс для того что бы запретить индексацию или выкинуть из индекса сразу кучу мусора и это вполне нормально.

2
Ответить

Огромное спасибо! Недавно прилетело письмо с критической ошибкой от Веб-мастера. Стоит защита DDoS от CloudFlare.

Ответить

Да, всё верно. С Clean-param - отдельная песня, тут тема на отдельную статейку по идее. Не хотел я отдельные директивы подробно разбирать, это лучше каким-то кейсом оформить, а у меня под рукой подходящего материала нет.

Ответить

О! Годно, спасибо Виктор!
Про Clean можно еще отдельно...я вот часто закидываю в disallow все непонятное, если траф из Гугла на 70%, чтобы руками все не разбирать, когда за это не платят.
Может я и не прав.

3
Ответить

Ну, я тоже Clean-param редко использую, необходимости нет чаще всего. Но если сайт активно рекламой двигается в Яндексе (да и вообще), там без этого никак.

1
Ответить