Google обнародовал исходники парсера файлов robots.txt


Содержание материала:

Google открыла код парсера robots.txt: как заполучить коды

Google всегда стремится к улучшению интернет стандартов. Поэтому компания открыла исходный код своего парсера файлов robots.txt по лицензии Apache 2.0.

Файл robots.txt — это текстовый файл, который обычно находится в корневом каталоге сайта (адрес вида www.example.com/robots.txt). Вообще, он указывает поисковым роботам, какие файлы и страницы можно сканировать, а какие — нет. Соответственно, все, что разрешено сканировать, появится в поисковой выдаче. Об этом сообщает Информатор Tech со ссылкой на Google .

«Мы открываем библиотеку C++ , которую наши системы используют для парсинга и проверки правил в файлах robots.txt. Этой библиотеке — уже 20 лет, в ней содержатся куски кода, написанные еще в 90-х», — сообщили в компании. Вместе с библиотекой вебмастерам также предложили код утилиты для проверки правильности правил в robots.txt. Код библиотеки и сопутствующих инструментов можно посмотреть на GitHub .

Напомним, что Google тестирует новую функцию для панели инструментов Chrome. Пока это доступно только для браузера Canary. Также Google Photos в скором времени получит множество новых функций.

Узнать еще больше актуальных новостей из мира технологий и игр можно в нашем Telegram-канале и на Facebook.

Google обнародовал исходники парсера файлов robots.txt

Собственно сам код:

Сегодня компания Google анонсировала черновик RFC стандарта Robots Exclusion Protocol (REP), попутно сделав доступным свой парсер файла robots.txt под лицензией Apache License 2.0. До сегодняшнего дня какого-либо официального стандарта для Robots Exclusion Protocol (REP) и robots.txt не существовало (ближайшим к нему было вот это), что позволяло разработчикам и пользователям интерпретировать его по-своему. Инициатива компании направлена на то, чтобы уменьшить различия между реализациями.

забавный момент, что гугл учитывает даже описки сделанные людьми:

Google открыла исходный код парсера Robots.txt

Google намеревается помочь веб-девелоперам более грамотно парсить файлы robots.txt. Для этого корпорация открыла исходный код библиотеки на C++, которая используется для парсинга файлов robots.txt и проверки соблюдения правил.

«На протяжении 25 лет “Стандарт исключений для роботов“ (Robots Exclusion Protocol, REP) был стандартом де-факто, что имело свои неприятные последствия как для веб-разработчиков, так и для поисковых роботов. Например, что делать, если файлы robots.txt весят сотни мегабайт», — пишет корпорация в блоге.

«Сегодня мы объявляем, что хотим сделать REP интернет-стандартом. Это очень важный шаг, который, однако, потребует дополнительной работы от разработчиков, которые парсят файлы robots.txt».

«Но мы готовы помочь и с этим. Мы открыли исходный код библиотеки на C++, которая используется нашими внутренними системами для парсинга robots.txt, а также проверки соответствия правилам синтаксиса этих файлов».

Стоит отметить, что библиотека, о которой говорит Google, используется уже около 20 лет. Она содержит строки кода, написанные еще в 90-х годах.

Читайте также

Утёкшие документы, раскрывающие суть гражданского иска против Facebook, показали, как социальная сеть использовала данные пользователей для манипуляции своими конкурентами.

Согласно опубликованной NBC News информации, Цукерберг с командой награждали своих партнёров доступом к персональным данным юзеров социальной площадки. В то же время они лишали этого доступа своих конкурентов.

Слитые документы датируются 2011 годом. Подразумевалось, что эта информация не должна дойти до общественности, однако утечка раскрыла людям глаза на практики Facebook.

Например, упоминается случай, когда Facebook предоставил Amazon персональный доступ к пользовательским данным благодаря тому, что тот купил рекламу на площадке социальной сети.

В то же время приложению MessageMe такой доступ был запрещён. Причина — его популярность выросла настолько, что Facebook уже рассматривал MessageMe в качестве конкурента.

На тот момент иск на интернет-гиганта подал ныне несуществующий стартап Six4Three, который разрабатывал провалившееся приложение под названием Pikinis.

Robots.txt

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

Для начала короткое видео, которое создаст общее представление о том, что такое файл robots.txt.

Как влияет robots.txt на индексацию сайта

Поисковые роботы будут индексировать ваш сайт независимо от наличия файла robots.txt. Если же такой файл существует, то роботы могут руководствоваться правилами, которые в этом файле прописываются. При этом некоторые роботы могут игнорировать те или иные правила, либо некоторые правила могут быть специфичными только для некоторых ботов. В частности, GoogleBot не использует директиву Host и Crawl-Delay, YandexNews с недавних пор стал игнорировать директиву Crawl-Delay, а YandexDirect и YandexVideoParser игнорируют более общие директивы в роботсе (но руководствуются теми, которые указаны специально для них).

Максимальную нагрузку на сайт создают роботы, которые скачивают контент с вашего сайта. Следовательно, указывая, что именно индексировать, а что игнорировать, а также с какими временны́ми промежутками производить скачивание, вы можете, с одной стороны, значительно снизить нагрузку на сайт со стороны роботов, а с другой стороны, ускорить процесс скачивания, запретив обход ненужных страниц.

К таким ненужным страницам относятся скрипты ajax, json, отвечающие за всплывающие формы, баннеры, вывод каптчи и т.д., формы заказа и корзина со всеми шагами оформления покупки, функционал поиска, личный кабинет, админка.

Для большинства роботов также желательно отключить индексацию всех JS и CSS. Но для GoogleBot и Yandex такие файлы нужно оставить для индексирования, так как они используются поисковыми системами для анализа удобства сайта и его ранжирования (пруф Google, пруф Яндекс).

Директивы robots.txt

Директивы — это правила для роботов. Есть спецификация W3C от 30 января 1994 года и расширенный стандарт от 1996 года. Однако не все поисковые системы и роботы поддерживают те или иные директивы. В связи с этим для нас полезнее будет знать не стандарт, а то, как руководствуются теми или иными директивы основные роботы.

Давайте рассмотрим по порядку.

User-agent

Это самая главная директива, определяющая для каких роботов далее следуют правила.

Для всех роботов:
User-agent: *

Для конкретного бота:
User-agent: GoogleBot

Обратите внимание, что в robots.txt не важен регистр символов. Т.е. юзер-агент для гугла можно с таким же успехом записать соледующим образом:
user-agent: googlebot

Ниже приведена таблица основных юзер-агентов различных поисковых систем.

Бот Функция
Google
Googlebot основной индексирующий робот Google
Googlebot-News Google Новости
Googlebot-Image Google Картинки
Googlebot-Video видео
Mediapartners-Google Google AdSense, Google Mobile AdSense
Mediapartners Google AdSense, Google Mobile AdSense
AdsBot-Google проверка качества целевой страницы
AdsBot-Google-Mobile-Apps Робот Google для приложений
Яндекс
YandexBot основной индексирующий робот Яндекса
YandexImages Яндекс.Картинки
YandexVideo Яндекс.Видео
YandexMedia мультимедийные данные
YandexBlogs робот поиска по блогам
YandexAddurl робот, обращающийся к странице при добавлении ее через форму «Добавить URL»
YandexFavicons робот, индексирующий пиктограммы сайтов (favicons)
YandexDirect Яндекс.Директ
YandexMetrika Яндекс.Метрика
YandexCatalog Яндекс.Каталог
YandexNews Яндекс.Новости
YandexImageResizer робот мобильных сервисов
Bing
Bingbot основной индексирующий робот Bing
Yahoo!
Slurp основной индексирующий робот Yahoo!
Mail.Ru
Mail.Ru основной индексирующий робот Mail.Ru
Rambler
StackRambler Ранее основной индексирующий робот Rambler. Однако с 23.06.11 Rambler перестает поддерживать собственную поисковую систему и теперь использует на своих сервисах технологию Яндекса. Более не актуально.

Disallow и Allow

Disallow закрывает от индексирования страницы и разделы сайта.
Allow принудительно открывает для индексирования страницы и разделы сайта.

Но здесь не все так просто.

Во-первых, нужно знать дополнительные операторы и понимать, как они используются — это *, $ и #.

* — это любое количество символов, в том числе и их отсутствие. При этом в конце строки звездочку можно не ставить, подразумевается, что она там находится по умолчанию.
$ — показывает, что символ перед ним должен быть последним.
# — комментарий, все что после этого символа в строке роботом не учитывается.

Примеры использования:


Disallow: *?s=
Disallow: /category/$

Следующие ссылки будут закрыты от индексации:
http://site.ru/?s=
http://site.ru/?s=keyword
http://site.ru/page/?s=keyword
http://site.ru/category/

Следующие ссылки будут открыты для индексации:
http://site.ru/category/cat1/
http://site.ru/category-folder/

Во-вторых, нужно понимать, каким образом выполняются вложенные правила.
Помните, что порядок записи директив не важен. Наследование правил, что открыть или закрыть от индексации определяется по тому, какие директории указаны. Разберем на примере.

Топ-пост этого месяца:  Как восстановить показ по меткам после кастомных циклов вывода постов

Allow: *.css
Disallow: /template/

http://site.ru/template/ — закрыто от индексирования
http://site.ru/template/style.css — закрыто от индексирования
http://site.ru/style.css — открыто для индексирования
http://site.ru/theme/style.css — открыто для индексирования

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

Allow: *.css
Allow: /template/*.css
Disallow: /template/

Повторюсь, порядок директив не важен.

Sitemap

Директива для указания пути к XML-файлу Sitemap. URL-адрес прописывается так же, как в адресной строке.

Директива Sitemap указывается в любом месте файла robots.txt без привязки к конкретному user-agent. Можно указать несколько правил Sitemap.

Директива для указания главного зеркала сайта (в большинстве случаев: с www или без www). Обратите внимание, что главное зеркало указывается БЕЗ http://, но С https://. Также если необходимо, то указывается порт.
Директива поддерживается только ботами Яндекса и Mail.Ru. Другими роботами, в частности GoogleBot, команда не будет учтена. Host прописывается только один раз!

Пример 1:
Host: site.ru

Пример 2:
Host: https://site.ru

Crawl-delay

Директива для установления интервала времени между скачиванием роботом страниц сайта. Поддерживается роботами Яндекса, Mail.Ru, Bing, Yahoo. Значение может устанавливаться в целых или дробных единицах (разделитель — точка), время в секундах.

Пример 1:
Crawl-delay: 3

Пример 2:
Crawl-delay: 0.5

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

Чем больше значение, тем меньше страниц робот загрузит за одну сессию. Оптимальное значение определяется индивидуально для каждого сайта. Лучше начинать с не очень больших значений — 0.1, 0.2, 0.5 — и постепенно их увеличивать. Для роботов поисковых систем, имеющих меньшее значение для результатов продвижения, таких как Mail.Ru, Bing и Yahoo можно изначально установить бо́льшие значения, чем для роботов Яндекса.

Clean-param

Это правило сообщает краулеру, что URL-адреса с указанными параметрами не нужно индексировать. Для правила указывается два аргумента: параметр и URL раздела. Директива поддерживается Яндексом.

Clean-param: author_id http://site.ru/articles/

Clean-param: author_id&sid http://site.ru/articles/

Яндекс также рекомендует использовать эту директиву для того, чтобы не учитывались UTM-метки и идентификаторы сессий. Пример:

Другие параметры

В расширенной спецификации robots.txt можно найти еще параметры Request-rate и Visit-time. Однако они на данный момент не поддерживаются ведущими поисковыми системами.

Смысл директив:
Request-rate: 1/5 — загружать не более одной страницы за пять секунд
Visit-time: 0600-0845 — загружать страницы только в промежуток с 6 утра до 8:45 по Гринвичу.

Закрывающий robots.txt

Если вам нужно настроить, чтобы ваш сайт НЕ индексировался поисковыми роботами, то вам нужно прописать следующие директивы:

Проверьте, чтобы на тестовых площадках вашего сайта были прописаны эти директивы.

Правильная настройка robots.txt

Для России и стран СНГ, где доля Яндекса ощутима, следует прописывать директивы для всех роботов и отдельно для Яндекса и Google.

Чтобы правильно настроить robots.txt воспользуйтесь следующим алгоритмом:

  1. Закройте от индексирования админку сайта
  2. Закройте от индексирования личный кабинет, авторизацию, регистрацию
  3. Закройте от индексирования корзину, формы заказа, данные по доставке и заказам
  4. Закройте от индексирования ajax, json-скрипты
  5. Закройте от индексирования папку cgi
  6. Закройте от индексирования плагины, темы оформления, js, css для всех роботов, кроме Яндекса и Google
  7. Закройте от индексирования функционал поиска
  8. Закройте от индексирования служебные разделы, которые не несут никакой ценности для сайта в поиске (ошибка 404, список авторов)
  9. Закройте от индексирования технические дубли страниц, а также страницы, на которых весь контент в том или ином виде продублирован с других страниц (календари, архивы, RSS)
  10. Закройте от индексирования страницы с параметрами фильтров, сортировки, сравнения
  11. Закройте от индексирования страницы с параметрами UTM-меток и сессий
  12. Проверьте, что проиндексировано Яндексом и Google с помощью параметра «site:» (в поисковой строке наберите «site:site.ru»). Если в поиске присутствуют страницы, которые также нужно закрыть от индексации, добавьте их в robots.txt
  13. Укажите Sitemap и Host
  14. По необходимости пропишите Crawl-Delay и Clean-Param
  15. Проверьте корректность robots.txt через инструменты Google и Яндекса (описано ниже)
  16. Через 2 недели перепроверьте, появились ли в поисковой выдаче новые страницы, которые не должны индексироваться. В случае необходимости повторить выше перечисленные шаги.

Пример robots.txt

Как добавить и где находится robots.txt

После того как вы создали файл robots.txt, его необходимо разместить на вашем сайте по адресу site.ru/robots.txt — т.е. в корневом каталоге. Поисковый робот всегда обращается к файлу по URL /robots.txt

Как проверить robots.txt

Проверка robots.txt осуществляется по следующим ссылкам:

  • В Яндекс.Вебмастере — на вкладке Инструменты>Анализ robots.txt
  • В Google Search Console — на вкладке Сканирование>Инструмент проверки файла robots.txt

Типичные ошибки в robots.txt

В конце статьи приведу несколько типичных ошибок файла robots.txt


  • robots.txt отсутствует
  • в robots.txt сайт закрыт от индексирования (Disallow: /)
  • в файле присутствуют лишь самые основные директивы, нет детальной проработки файла
  • в файле не закрыты от индексирования страницы с UTM-метками и идентификаторами сессий
  • в файле указаны только директивы
    Allow: *.css
    Allow: *.js
    Allow: *.png
    Allow: *.jpg
    Allow: *.gif
    при этом файлы css, js, png, jpg, gif закрыты другими директивами в ряде директорий
  • директива Host прописана несколько раз
  • в Host не указан протокол https
  • путь к Sitemap указан неверно, либо указан неверный протокол или зеркало сайта

Если у вас есть дополнения к статье или вопросы, пишите ниже в комментариях.
Если у вас сайт на CMS WordPress, вам будет полезна статья «Как настроить правильный robots.txt для WordPress».

Полезное видео от Яндекса (Внимание! Некоторые рекомендации подходят только для Яндекса).

Google открывает исходный код парсера robots.txt 01.07.2020 21:34

Сегодня компания Google анонсировала черновик RFC стандарта Robots Exclusion Protocol (REP), попутно сделав доступным свой парсер файла robots.txt под лицензией Apache License 2.0. До сегодняшнего дня какого-либо официального стандарта для Robots Exclusion Protocol (REP) и robots.txt не существовало (ближайшим к нему было вот это), что позволяло разработчикам и пользователям интерпретировать его по-своему. Инициатива компании направлена на то, чтобы уменьшить различия между реализациями.

Черновик нового стандарта можно просмотреть на сайте IETF, а репозиторий доступен на Github по ссылке https://github.com/google/robotstxt.

Парсер представляет собой исходный код, который Google используют в составе своих продакшн-систем (за исключением мелких правок — вроде убранных заголовочных файлов, используемых только внутри компании) — парсинг файлов robots.txt осуществляется именно так, как это делает Googlebot (в том числе то, как он обращается с Юникод-символами в паттернах). Парсер написан на С++ и по сути состоит из двух файлов — вам потребуется компилятор, совместимый с C++11, хотя код библиотеки восходит к 90-ым, и вы встретите в ней «сырые» указатели и strbrk. Для того, чтобы его собрать, рекомендуется использовать Bazel (поддержка CMake планируется в ближайшем будущем).
Сама идея robots.txt и стандарта принадлежит Мартейну Костеру, который создал его в 1994 году — по легенде, причиной тому стал поисковый паук Чарльза Стросса, который «уронил» сервер Костера при помощи DoS-атаки. Его идея была подхвачена другими и быстро стала стандартом де-факто для тех, кто занимался разработкой поисковых систем. Тем же, кто хотел заниматься его парсингом, иногда приходилось заниматься реверс-инженирингом работы Googlebot — в их числе компания Blekko, написавшая для своей поисковой системы собственный парсер на Perl.

В парсере не обошлось и без забавных моментов: взгляните к примеру на то, сколько труда пошло на обработку «disallow».

PVS-Studio хотел, но не смог найти баги в robots.txt

На днях Google опубликовал исходники парсера robots.txt. Почему бы не прогнать уже проверенный всеми вдоль и поперек проект через PVS-Studio и, возможно, найти ошибку. Сказано — сделано. Жаль, что ничего значимого найти не удалось. Ну что ж, тогда пусть это будет просто повод похвалить разработчиков Google.

robots.txt – индексный файл, который содержит правила для поисковых роботов. Он действует для протоколов https, http и FTP. Google сделала доступным для всех свой парсер файла robots.txt. Подробнее об этой новости можно почитать здесь: Google открывает исходный код парсера robots.txt

Думаю, большинству читающих наши статьи известно, что делает PVS-Studio. Но на случай, если вы впервые в нашем блоге, дадим краткую справку. PVS-Studio – статический анализатор кода, который позволяет находить разнообразные ошибки, уязвимости и недочеты в проектах, написанных на С, С++, С# и Java. Другими словами, PVS-Studio является SAST решением и может работать как на пользовательских машинах или сборочных серверах, так и в облаке. А ещё команда PVS-Studio очень любит писать статьи о проверке различных проектов. Так что перейдем к делу и попробуем найти ошибки в исходном коде парсера от Google.

К нашему сожалению, и, к радости всех остальных, каких-либо ошибок найти не удалось. Найдена только пара несущественных недочётов, о которых мы и расскажем. Надо ведь хоть про что-то написать :). Отсутствие ошибок объясняется малым объёмом проекта и высоким качеством самого кода. Это не значит, что там не прячутся какие-то ошибки, но статический анализ оказался в данный момент бессилен.

Топ-пост этого месяца:  Что такое Next js основные принципы работы фреймворка для приложений React

В общем эта статья получилась в духе другой нашей публикации «Самая короткая статья о проверке nginx».

Нашлась возможность небольшой оптимизации:

V805 Decreased performance. It is inefficient to identify an empty string by using ‘strlen(str) > 0’ construct. A more efficient way is to check: str[0] != ». robots.cc 354

Вызов функции strlen для того, чтобы узнать, является ли строка непустой — это неэффективный способ. Такую проверку можно произвести гораздо проще: if (*key[0] != »), и не нужно будет проходить по всем элементам строки, если она непустая.

V808 ‘path’ object of ‘basic_string’ type was created but was not utilized. robots.cc 123

Строка path объявляется, но далее не используется. В некоторых случаях неиспользованные переменные могут указывать на ошибку. Но тут похоже на то, что раньше эта переменная как-то использовалась, но после внесения изменений стала не нужна. Таким образом, анализатор зачастую еще и помогает сделать код чище и помочь избежать ошибок, попросту убрав предпосылки для их появления.

В следующем случае анализатор, по сути, дает рекомендацию добавить дефолтный return после того, как весь main будет отработан. Возможно, стоило бы добавить return в самом конце, чтобы можно было понять, что все действительно отработало. Однако если данное поведение и было задумано, и изменять ничего не нужно, а сообщение анализатора видеть бы не хотелось, то в случае PVS-Studio можно подавить это предупреждение и никогда его больше не видеть :).

V591 The ‘main’ function does not return a value, which is equivalent to ‘return 0’. It is possible that this is an unintended behavior. robots_main.cc 99

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

V524 It is odd that the body of ‘MatchDisallow’ function is fully equivalent to the body of ‘MatchAllow’ function. robots.cc 645

Это единственное место, которое вызывает у меня какое-то подозрение. Его стоит проверить авторам проекта.

Таким образом, проверка парсера robots.txt от Google показала, что столь активно используемый и, скорее всего, многократно проверенный на ошибки проект, имеет высокое качество кода. А найденные недочеты совсем не могут испортить впечатление от того, какие крутые кодеры из Google занимались этим проектом :).

Предлагаем и вам скачать и попробовать PVS-Studio на интересующем вас проекте.

Google прекращает поддержку директивы noindex в robots.txt

После 1.09.2020 года, поисковый гигант прекратит следовать директивам, которые не поддерживаются и не опубликованы в robots exclusion protocol. Изменения были анонсированы в блоге компании (https://webmasters.googleblog.com/2020/07/a-note-on-unsupported-rules-in-robotstxt.html). Это значит, что Google не будет учитывать файлы robots с записанной внутри директивой “noindex”.

Что произошло? В течение многих лет файл robots позволял ограничивать доступ к некоторым (или всем) страницам сайта для разного рода роботов, парсеров, пауков или скраулеров. Крупные поисковики следовали этим правилам, но не всегда были понятны принципы их обработки, поскольку отсутствовал официальный стандарт. Теперь же компания Google решила официально утвердить протокол REP для возможностей его расширения в будущем и предотвращения разных толкований одной записи. Основные изменения:

  • Директивы теперь используются для любого протокола: кроме HTTP/HTTPS, они распространяются на FTP и прочие;
  • Поисковые пауки обязательно сканируют первые 512Кб файла robots.txt. Если файл большой, то дальше они могут его не сканировать..
  • Все записи в файле кешируются сроком до 24 часов. Это сделано, чтобы не загружать сервер запросами, а также, чтобы SEO-специалист мог обновлять файл по мере необходимости и в удобные сроки. Срок кеширования можно задавать, используя директиву Cache-Control.
  • Если файл по какой-то причине перестал сканироваться — правила продолжают работать. Согласно новой спецификации, в течение продолжительного времени используется последняя кэшированная копия.

Также, были пересмотрены правила для файла robots.txt. Теперь поисковой машиной Google не учитываются директивы, которые не указаны в стандарте. Первой записью, которая не попала в документ, стала директива noindex.

Каковы же альтернативы? Google такие варианты, которые, вероятно, уже использовались в любом случае:

1) noindex в метатегах. Данная директива, поддерживаемая в HTTP-ответах/HTML-коде — самый эффективный способ, чтобы удалить ссылки из индекса, если парсинг разрешен.

2) 404 и 410 коды ответов. Оба HTTP-ответа означают, что по данному URL отсутствует страница, и приведут к удалению страниц с такой ошибкой из поискового индекса если они будут или были просканированы.

3) Защита паролем. Если разметка не указывает на подписку или платный контент (https://developers.google.com/search/docs/data-types/paywalled-content), то сокрытая за формой авторизации страница со временем удалится из индекса Google.

4) Disallow в robots.txt. Поисковики индексируют известные им страницы. Поэтому, блокирование доступа к странице для краулеров означает, что контент никогда не будет проиндексирован. В то же время, поисковик также может индексировать URL-адрес, основываясь на переходах с других страниц (внутренних или внешних), не видя при этом непосредственно контент. Так что, при использовании директивы disallow рекомендую сделать страницы, закрытые ею, менее видимыми в целом.

5) Инструмент удаления URL в Google Search Console (https://support.google.com/webmasters/answer/1663419). С его помощью можно легко и быстро (но временно) убрать страницы из результатов поиска.

Новый стандарт. За день до этой новости, Google анонсировал, что компания также работает над разработкой стандарта, основанного на robots exclusion protocol, что является первым существенным изменением в данном направлении. Также, компания выложила исходный код парсера robots.txt в открытый доступ одновременно с новостью о разработке стандарта.

Почему Google вводит эти изменения сейчас? Поисковый гигант искал возможности для этих изменений в течение нескольких лет и со стандартизацией протокола он наконец-то может двигаться вперед. В Google сказали, что «провели анализ по использованию разных директив в файле robots» и теперь сфокусированы на удалении основных неподдерживаемых директив – crawl-delay, nofollow, noindex.

«Поскольку эти правила никогда официально не разъяснялись компанией, их использование может плохо влиять на сканирование Googlebot’а. Также, такие ошибки плохо влияют на присутствие сайтов в поисковой выдаче»


Стоит ли переживать? Самое главное на данный момент – избавиться от директивы noindex в файле robots.txt. Если же без нее никак, то стоит воспользоваться одной из перечисленных выше альтернатив до 1 сентября. Также, обратите внимание на использование nofollow или crawl-delay команд и если они есть, то переделайте также их с использованием поддерживаемых директив. Поисковый гигант дал достаточно времени для того, чтобы все ознакомились с вносимыми изменениями и поменяли свои файлы robots.txt, поэтому нет поводов для беспокойства.

Тем не менее, все равно интересно как коллеги решают данную проблему. Со статическими сайтами все понятно, там и в хедере можно написать все нужные метатеги. Но для SPA-сайтов было гораздо удобнее закрывать страницы по определенной маске (например https://ntile.app/some_id/*) или же скрывать целые разделы (например, https://ntile.app/taynaya-komnata-5d2ec134e12fd4000146d3ec-5d2ec134e12fd4000146d3ee, изначально созданный не для индексации, а для тестов по переспаму). С кодами ответов в заголовках много мороки получается. Да и скрывать всё за формой авторизации несколько усложняет разработку.

Подскажите, кто как решает такого рода проблемы?

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

Google обновляет правила для robots.txt. Что изменится и что делать?

Поисковые краулеры сканируют любой сайт согласно правилам, которые прописаны в файле robots.txt.

Правила прописываются на основе протокола Robots Exclusion Protocol.

Google внес изменения в данный протокол. Например, теперь не поддерживается директива noindex.

Что еще изменяется и что делать?

Разберемся с вопросами далее.

Что произошло?

Поисковые оптимизаторы создают директивы для поисковых краулеров согласно правилам протокола Robots Exclusion Protocol. Такие директивы прописываются в файле robots.txt.

На протяжении 25 лет протокол REP являлся важным инструментом для поисковых оптимизаторов, так как позволял запрещать различным роботам доступ к некоторым страницам сайта.

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

Поисковые системы такие как Yandex, Bing и Google следовали правилам из robots.txt.

Но протокол не был закреплен на официальном уровне.

Утверждает такие протоколы на официальном уровне организация под названием Internet Engineering Task Force (Инженерный совет интернета).

Так как стандарт не был закреплен, то и правила обработки были не всегда понятными для всех.

Google решил задокументировать протокол REP и направил стандарт в соответствующую организацию на рассмотрение и регистрацию.

Такие действия призваны решить ряд целей:

  • Расширить базу функциональных возможностей, чтобы можно было задавать более точные правила;
  • Определить четкие стандарты, чтобы избежать различных спорных сценариев по использованию. В результате все причинно-следственные связи по использованию файла robots должны стать ясными для всех.

Что изменяется?

Список из наиболее существенных изменений:

  • Теперь директивы можно использовать для любого URI. Например, теперь помимо HTTP/HTTPS правила можно применять к FTP или CoAP;
  • Поисковые краулеры должны сканировать первые 512 килобайт файла. Роботы могут, но не обязаны сканировать весь файл если файл большой. Также роботы не обязаны сканировать весь файл, если соединение не стабильное;
  • Размещенные в файле директивы подлежат кешированию. Делается так, чтобы не нагружать сервер запросами. По умолчанию кеширование проводится на срок не более чем 24 часа, чтобы дать возможность поисковому оптимизатору в приемлемые сроки обновлять файл. Значение по кешированию можно задавать самостоятельно используя директиву кеширования посредством заголовка Cache-Control;
  • Если файл не доступен, то директивы продолжают работать. Спецификация предусматривает, что если файл robots.txt стал не доступен для поискового краулера, то правила описанные ранее будут продолжать действовать еще на протяжении длительного времени.
Топ-пост этого месяца:  Франшиза - что это такое Как создать и продать франшизу

Далее были пересмотрены директивы, которые допускаются к использованию в файле robots.txt.

Правила, которые не опубликованы в стандарте, не будут поддерживаться Google.

В результате правило noindex больше не будет поддерживаться Google.
Поддержка отключается с 1 сентября 2020 года.

Еще был открыт исходный код парсера robots.txt. Данный парсер используется краулером Google для парсинга данных из robots.txt.

Если покопаться в коде, то можно найти информацию о том, что директива disallow будет работать, даже если ключевая фраза написана с опечаткой. Значит, указывать на такие ошибки в аудите сайта является бессмысленной затеей 🙂

Что делать?

Теперь для реализации noindex на практике следует использовать такие способы:

  • Задавать noindex в мета-теге robots;
  • Задавать noindex в HTTP заголовках.

Директива noindex является наиболее эффективным способом для удаления страниц из индекса.

Как задать директиву через HTTP заголовок? Требуется использовать заголовок X-Robots-Tag.

К примеру, если требуется запретить индексацию страницы indexoid, следует указать так:

Если есть только доступ к шаблону сайта, следует использовать мета-тег robots. Например, если для сайта 2yachts.com требуется запретить индексацию страниц, следует использовать такой код:

Данный код указывает на запрет индексации для Google.

Если требуется запретить индексацию для разных ботов, а не только для Google, то в name следует использовать значение robots вместо googlebot.

Какой способ для удаления страниц из индекса поисковой системы является наиболее эффективным? Наиболее эффективным является манипуляция с кодом ответа. Если для страницы задать код ответа 404 или 410, то страница будет удалена из индекса поисковой системы.

Как задать время на которое файл robots.txt будет кешироваться? Следует использовать заголовок Cache-Control.

Директива задает период времени, в течение которого скачанный ответ может быть повторно использован.

Отсчет начинается с момента запроса.

max-age=[n секунд] означает, что ответ может быть закеширован и использован в течение n секунд.

Применив на практике вариант с кешированием процесс обработки файла будет выглядеть так:

Вопросы и ответы


Как проверить правильность настройки robots.txt?

Проверить директивы из файла robots.txt на валидность можно используя инструментарий для тестирования от Google.

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

И обратите внимание, что ссылки в файле robots.txt чувствительны к регистру.

Например такие ссылки считаются разными:

  • ru.megaindex.com/SEO
  • ru.megaindex.com/seo

Тест делает проверку как валидатор, поэтому на подобные нюансы не указывает.

Поддерживают ли другие поисковые системы noindex?

Yandex и Bing не поддерживают директиву в robots.txt.

Yandex рекомендует использовать noindex в метатеге robots или X-Robots-Tag.

Нужно ли закрывать файлы CSS и JavaScript в robots?

Файлы стилей и скрипты закрывать не рекомендуется.

В поисковой системе используется рендеринг сайта. Рендеринг происходит перед ранжированием. Если запретить доступ к стилям и скриптам, поисковая система все равно проведет рендеринг сайта, но результат будет не корректным, что скажется на позициях в поисковой выдаче.

Весь процесс до старта алгоритма ранжирования выглядит так:

Рекомендованные материалы в блоге MegaIndex по теме краулинга страниц сайта поисковыми системами по ссылкам далее:

Влияет ли запрет robots.txt на краулинговый бюджет?

На краулинговый бюджет влияют два главных фактора:

  • Авторитетность доменного имени;
  • Пропускная способность сервера сайта.

Авторитетность сайта зависит от качества внешней ссылочной массы.

Выгрузить и проанализировать список всех внешних ссылок по любому сайту можно используя сервис MegaIndex.

Еще в MegaIndex есть методы API, позволяющие обращаться к базе для выгрузки данных. Пример запроса к базе MegaIndex через API для сайта wixfy.com:

Директивы в robots.txt не меняют значение по краулинговому бюджету.

Если посредством директивы Disallow в robots.txt исключается часть ненужных страниц, то краулинговый бюджет расходуется более рационально, что качественно влияет на индексацию сайта.

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

Директивы robots.txt распространяются только на верхний уровень хоста.

Например, если файл размещен на хосте smmnews.com, то все директивы будут применимы лишь для smmnews.com. Директивы не будут применены для www.smmnews.com и подобных хостов.

Указывать в файле robots.txt не имеет смысла.

Для указания директив на поддоменах файл robots.txt следует размещать на поддомене.

Выводы

25 лет директивы robots.txt использовались де-факто, но не были зафиксированы как стандарт. Теперь стандарт будет создан, а значит появится официальная документация и будет снята неопределенность по нюансам.

Например, теперь определен оптимальный размер файла — до 512 килобайт.

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

Теперь протокол Robots Exclusion Protocol станет стандартом для интернета.

Google больше не станет поддерживать директиву noindex, если ее использовать в файле robots.txt.

Для запрета индексации используйте заголовок или специальный мета-тег.

Новые сайты до запуска следует закрывать от индексации на уровне сервера.

Если сайт переведен на HTTPS, следует провести проверку на предмет доступности файла robots.txt по протоколу HTTPS. Если сайт переведен на HTTPS, но файл robots.txt доступен только по HTTP, то директивы для HTTPS страниц сайта действовать не будут.

Рекомендованный материал в блоге MegaIndex по теме перевода сайта на HTTPS по ссылке далее — Зачем и как перевести сайт на HTTPS бесплатно и без ошибок?.

Если говорить о практике, то в сухом остатке список действий следующий:

  • Удалить из файла robots.txt директивы noindex;
  • Разместить noindex в заголовке X-Robots-Tag или мета-теге с значением content=»noindex»;
  • Если файл превышает 512 килобайт, то уменьшить размер файла за счет использование масок;
  • Удалить из файла директивы на запрет индексации CSS и JavaScript файлов;
  • Если требуется убрать страницу из индекса и запретить индексацию, следует использовать 404 или 410 код ответа;
  • Задать время кеширования файла через Cache-Control.

Остались ли у вас вопросы, замечания или комментарии по теме robots.txt?

Интересно ли вам было бы узнать подробную информацию про краулинговый бюджет?

Исходники парсера файлов robots.txt оказались в свободном доступе

Поисковик опубликовал на GitHub программные исходники парсера файлов robots.txt. В их состав входят библиотеки анализатора, написанные на C++. Они используются для парсинга и идентификации правил, указанных в robots.txt.

В посте, размещенном в Webmaster Central Blog, отмечается, что основной код библиотек парсера был написан больше двадцати лет назад. Но остальная часть исходников неоднократно модифицировалась. Все эти изменения также были добавлены в версию парсера, которую Google предоставил IETF для присвоения ему статуса интернет-стандарта.

В исходниках на GitHub также имеется специальный инструмент для тестирования. С его помощью веб-разработчики могут поэкспериментировать с различными настройками парсера.

Google™ открывает исходный код парсера robots™.txt

Сегодня компания Google™ анонсировала черновик RFC стандарта Robots™ Exclusion Protocol (REP), попутно сделав™ доступным свой парсер™ файла robots™.txt под лицензией Apache™ License 2.0. До сегодняшнего дня какого™-либо официального стандарта для Robots™ Exclusion Protocol (REP) и robots™.txt не существовало (ближайшим к нему было вот это), что позволяло разработчикам и пользователям интерпретировать его по-своему™. Инициатива компании направлена на то, чтобы уменьшить различия между реализациями.

Черновик нового™ стандарта можно просмотреть на сайте IETF, а репозиторий доступен на Github™ по ссылке™ https://github™.com/google™/robotstxt.

Парсер™ представляет собой исходный код, который Google™ используют в составе своих продакшн-систем™ (за исключением мелких™ правок™ — вроде убранных заголовочных файлов™, используемых только™ внутри™ компании) — парсинг файлов™ robots™.txt осуществляется именно™ так, как это делает™ Googlebot (в том числе то, как он обращается с Юникод™-символами в паттернах). Парсер™ написан на С++ и по сути состоит из двух файлов™ — вам потребуется компилятор, совместимый с C++11, хотя код библиотеки восходит к 90-ым, и вы встретите в ней «сырые» указатели и strbrk™. Для того, чтобы его собрать, рекомендуется использовать Bazel (поддержка CMake планируется в ближайшем будущем).

Сама идея robots™.txt и стандарта принадлежит Мартейну Костеру, который создал™ его в 1994 году — по легенде, причиной тому стал поисковый паук Чарльза Стросса, который «уронил™» сервер™ Костера при помощи™ DoS-атаки. Его идея была подхвачена другими и быстро™ стала стандартом де-факто для тех, кто занимался разработкой поисковых систем™. Тем же, кто хотел заниматься его парсингом, иногда™ приходилось заниматься реверс™-инженирингом работы™ Googlebot — в их числе компания Blekko™, написавшая для своей поисковой системы собственный парсер™ на Perl.

В парсере не обошлось и без забавных моментов: взгляните к примеру на то, сколько труда пошло на обработку «disallow».

Добавить комментарий