Поисковые системы. Поисковая оптимизация. События в мире SEO

Эндрю Вустер провел интересное исследование файлов robots.txt на сайтах из каталога Dmoz. В ходе своего исследования HTTP заголовков он разработал собственного паука и собрал большую базу доменов. Скормив своему пауку (написанному на Python с использованием PycURL) эту базу сайтов из Дмоза, Эндрю Вустер получил MySQL базу, в которой сохранялись содержание robots.txt, HTTP заголовки и полный ответ сервера. Полный дамп базы составил 12 Gb. После получасовой работы анализатора были получены интересные данные и статистика о содержании robots.txt на более чем 4.6 миллионах доменов.

Статус коды

HTTP коды статуса (возвращаемые сервером значения) говорят веб браузерам и роботам поисковых систем какого рода ответ они получают при загрузке страницы. Например, код “200″ значит, что все нормально, а “404″ (file not found) - что веб сервер не смог найти файл по заданному адресу (например на этом блоге при вводе неправильного адреса происходит перенаправление на 404 страницу). IETF спецификация robots.txt говорит о том, что 404 код возврата (по-другому - код ошибки) по адресу robots.txt значит отсутствие ограничений для загрузки сайта роботами, а коды 2ХХ говорят о том, что роботу следует руководствоваться правилами, прописанными в robots.txt.

Статус коды интересны в первую очередь тем, что с их помощью можно быстро подсчитать количество сайтов, имеющих файл robots.txt. Исследовав 4.6 миллиона сайтов, можно по статус кодам определить у скольких сайтов есть robots.txt и у скольких его нет:

Класс	Число сайтов	В % от всех
5xx	4,338	0.09
4xx	3,035,454	65.86
3xx	350,946	7.61
2xx	1,217,559	26.42
1xx	12	0.00
invalid	21	0.00

Как мы можем видеть, более 65% сайтов возвращают код 4ХХ, говорящий о том, что на сайте нет файла robots.txt. Еще 7.6% сайтов перенаправляют на другой URL (смотрите например редирект 301) - обычно на главную страницу или страницу ошибок (т. н. 404 страницу). Это значит, что только 26% владельцев сайтов поработали над тем, чтобы обеспечить свои сайты правильным файлом robots.txt. Конечно, некоторые сайты могут возвращать код 200 даже для страницы ошибок, поэтому такой подсчет может быть использован для быстрой оценки.

MIME типы

MIME типы (типы содержания) возвращаются веб серверами в HTTP заголовках, чтобы сообщить клиентам какой передается документ. Они состоят из типов (text, image и так далее), подтипов (html или jpeg) и некоторых необязательных параметров, таких как кодировка документа. Например, HTML файл обычно имеет MIME тип “text/html”, а текстовый файл - “text/plain”. Изображения могут иметь MIME типы “image/gif” или “image/jpeg”. Список всех зарегистрированных MIME типов можно посмотреть на IANA.

Единственный MIME тип, который должен возвращать файл robots.txt - это текст. По правде говоря, спецификация специально не упоминает это правило, но сайты типа Google следуют общему правилу, что “если это не text/*, то это не простой текст”. 109,780 из исследованных файлов robots.txt имели MIME тип, отличный от text/plain. Поэтому неудивительно, что крупнейшие поисковые системы, такие как Google, Yahoo! и MSN, стараются парсить файл robots.txt независимо от возвращаемого типа. Например, robots.txt на сервере Дигга имеет тип “text/html; charset=UTF-8″. И поисковые роботы следуют правилам этого файла.

Кроме text/html и text/plain, были среди исследованных файлов и другие MIME типы, например, application/octet-stream, application/x-httpd-php, text/x-perl (в основном страницы ошибок), video/x-ms-asf, application/x-httpd-cgi, image/gif и image/jpeg.

Даже среди файлов, обозначенных как текст, было множество вариантов MIME типов, часто с ошибками в написании типа:
application/txt, application/x-txt, file/txt, internal-gopher-text, plain/text, text, text/R*ch, text/aleph_save, text/ascii, text/asp, text/css, text/dhtml, text/enriched, text/htm, text/illegal, text/javascript, text/octet-stream, text/plane, text/rtf, text/ssi html, text/svg, text/text, text/txt, text/vnd.wap.wml, text/x-component, text/x-invalid, text/x-log, text/x-perl, text/x-python, text/x-server-parsed-html, text/xml, txt

Robots.txt - текстовый файл?

Еще одна ошибка, помимо использования неправильного content-type - это загрузка robots.txt в нетекстовом формате. Популярные ошибки - это загрузка robots.txt в формате Word документа (примеры: 1, 2, 3), RTF (примеры: 1, 2, 3) и HTML. Были найдены даже файлы роботса в форматах LaTex и KOffice (unix-based текстовый формат).

Некоторые серверные программы (т. н. Cougar, что-то вроде Microsoft Small Business Server или IIS) на запрос файла robots.txt даже выдают потоковое видео в формате ASF (примеры: 1, 2). Ужос .

Неправильная кодировка

Кодировка символов определяет какие знаки соответствуют определенным наборам бит. Сайты определяют кодировку, устанавливая ее в переменной content-type в заголовке. Robots.txt на некоторых сайтах был написан в редко используемых кодировках типа UTF-16. UTF-16 редко используется по многим причинам, хотя бы из-за неоднозначности определения последних бит кодировки символа. Из 463 файлов в формате UTF-16 примерно 10% были нечитабельны, хотя и содержали UTF16 BOM.

С другой стороны, некоторые сервера вообще определяют свои множества символов и называют кодировку по-своему, например “nf_z_62-010″, “ibm-939″ и “fi_fi.iso-8859-15@euro”.

Комментарии

В robots.txt можно использовать только один вид комментариев - комментарием считается строка после знака “#”. При этом среди исследованных сайтов были найдены HTML коментарии “< !- - >“, комментарии в стиле C++ “//” и многие другие, включая просто вставленные в текст строки комментариев.

Совершенно непонятные ошибки

Некоторые люди наверное вообще не имеют представления о том, что должно содержаться в файле robots.txt. Например, одна из распространенных ошибок - файлы robots.txt, в которые скопировано содержание страницы базы данных роботов. Речь идет не о нескольких сайтах. Такой robots.txt найден примерно на одном из каждых 1000 сайтов. Это просто сумасшествие. Это часть еще более распространенной общей ошибки, когда в robots.txt копируют какие-то инструкции по его настройке. Вот пара примеров: 1, 2, 3, 4, 5.

Есть совершенно “левые” файлы. В robots.txt пишут религиозные тексты и описания каких-то церквей. Или каталог MIDI треков.

ASCII арт: красивые и не очень.

Список видеоигр. Несколько файлов .htaccess - иногда вставляют код вместе с конструкциями роботса, иногда используют синтаксис .htaccess для описания User-Agent.

Списки ключевых слов и описаний сайта, включая просто перемешанные кейворды. PHP и Bash скрипты, и все что угодно.

Даже изображения. Не говоря о e-mail и сообщениях гостевых книг.

Есть даже одно описание плавательного бассейна (по-немецки).

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

info.txt

По-видимому, есть еще один протокол, подобный robots.txt, для рекламы и размещения контактной информации о владельце сайта. Эта информация используется Alexa для определения владельца сайта. Много таких записей было найдено в файлах robots.txt.

Регулярные выражения

В спецификации robots.txt не описаны регулярные выражения, но многие поисковые системы сейчас поддерживают такие возможности.

Например, Google, Yahoo! и MSN Search понимают * как соответствие любой строке символов, а знак доллара $ как знак окончания URL. Поэтому для блокировки пауков при попытке загрузить jpeg файлы можно использовать следующую конструкцию:

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

Блокировка доступа к отдельным форматам файлов - самое распространенное применеие для регулярных выражений. И большинство людей часто используют регулярные выражения когда они совсем не нужны. Например, многие сайты прописывают такое правило:

Disallow: /secret/*

Использовать нестандартное выражение здесь бесполезно, потому что такое правило эквивалентно более простому:

Disallow: /secret/

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

Обычные синтаксические ошибки

Какие еще есть ошибки кроме перечисленных выше? Спецификация говорит о том, что записи должны разделяться пустыми строками, и большинство ошибок вращаются вокруг этого. Во-первых, многие оставляют пустую строку между строкой User-agent и правилами для этого робота - это 74,043 из проанализированных файлов. Во-вторых, часто пишут правило Disallow/Allow не упоминая перед ними агента, или в одной строке с агентом - эта ошибка допущена в 64,921 файлах. В-третьих, часто пишут строку с агентом после правила Disallow/Allow, не разделяя их пустой строкой - еще 32,656 файлов. Строки слвсем левого текста (не комментарии, не правила или агенты) встретились в 22,269 файлах.

Это кстати не показатель, ведь за ошибочный текст могло быть принято и недавно введенное Google правило sitemap, которого автор эксперимента не учел.

Задержка сканирования

Пауки также иногда обращают внимание на директивы управления, например Crawl-delay (задержка сканирования, чтобы робот не положил сервак). MSN, Yahoo! и Ask поддерживают эту директиву, ее записывают так:

User-agent: *
Crawl-delay: 5

Это значит пауку следует ждать 5 секунд между загрузками. Были найдены десятки тысяч таких записей.

Опечатки

Было найдено очень много файлов с опечатками. Опечаток команды Disallow набралось целых 69 видов! Это не считая опечаток когда одни буквы в середине слова заменяют другими.

Ошибки в движках сайтов

Часто ошибки роботса закладываются при разработке движков сайтов (например advancedaccess). Например на многих сайтах файл robots.txt содержит только строку:

this file placed here so you don't fill up my error log looking for it

Примеры: 1, 2, 3, 4, 5.

Подобных примеров много. Скорее всего такие строки нужны для статистики использования движка. Это как мета тег generator=Wordpress на движках Wordpress - для сбора статистики. Но создание заведомо невалидного robots.txt по-моему не очень красиво по отношению к пользователям.

Выводы

Какие выводы мы можем сделать исходя из этих данных? Главный вывод я думаю состоит в том, что Robots Exclusion Protocol намного более сложный чем кажется. На месте паука для того, чтобы правильно распарсить множество совершенно разных и сумасшедших robots.txt по всему Интернету, вам нужно написать исключительно гибкий парсер (следуя Robustness Principle), в большинстве случаев игнорировать тип содержания (content-type), уметь распознавать множество кодировок (и в большинстве случаев просто игнорировать возвращаемую сервером кодировку), распознавать HTML и другие виды контента в файлах robots.txt и потенциально поддерживать множество расширений к принятому стандарту.

А что насчет высказанного выше утверждения, что пауки должны спрашивать разрешения на индексацию у вебмастера? Недавний проигранный иск правительства Бельгии против Google еще раз подтвердил верность позиции поисковых систем:

“Из-за огромного размера Интернета для поисковой системы невозможно персонально спросить каждого вебмастера можно загрузить ту или иную страницу или нельзя. Если бы такое разрешение было обязательным, то Интернет бы развалился.” - Andrew McLaughlin, глава отдела Google по конфиденциальности.

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

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

Полезно:
A Standard for Robot Exclusion - главный документ по robots.txt
Описание на русском языке и правильное использование robots.txt