Cnsearch стандарт исключений для роботов


Содержание

Стандарт исключений для роботов

Стандарт исключений для роботов ( robots.txt ) — файл ограничения доступа роботам к содержимому на http-сервере. Файл должен находиться в корне сайта (то есть иметь путь относительно имени сайта /robots.txt). При наличии нескольких поддоменов файл должен располагаться в корневом каталоге каждого из них.

Использование файла добровольно. Стандарт был принят консорциумом W3C 30 января 1994 года в списке рассылки robots-request@nexor.co.uk и с тех пор используется большинством известных поисковых машин.

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

Содержание

Описание структуры

Файл состоит из записей. Записи разделяются одной или более пустых строк (признак конца строки: символы CR, CR+LF, LF). Каждая запись содержит непустые строки следующего вида:

В директиве User-agent указываются роботы, которые должны следовать указанным инструкциям (например, User-agent: Yandex, User-agent: YandexBot, User-agent: * ).

Сравнение производится методом простого поиска подстроки. Например, запись Disallow: /about запретит доступ как к разделу http://example.com/about/, так и к файлу http://example.com/about.php, а запись Disallow: /about/ — только к разделу http://example.com/about/.

Проверка синтаксиса

Неправильно составленный robots.txt может привести к отрицательным последствиям. Например, весь сайт может «выпасть» из поискового индекса. Для проверки синтаксиса и структуры файла robots.txt существует ряд специализированных онлайн-служб:

  • Яндекс.Вебмастер — Анализ robots.txt (рус.) (выполняет проверку синтаксиса и разрешения для каждой отдельной страницы)
  • Google Search Console – Инструмент проверки файла robots.txt (рус.) (позволяет проверить разрешения для каждой отдельной страницы)

Примеры

Запрет доступа всех роботов ко всему сайту:

Запрет доступа определённого робота к каталогу /private/:

Нестандартные директивы

Allow: имеет действие, обратное директиве Disallow — разрешает доступ к определенной части ресурса. Поддерживается всеми основными поисковиками. В следующем примере разрешается доступ к файлу photo.html, а доступ поисковиков ко всей остальной информации в каталоге /album1/ запрещается.

Crawl-delay: устанавливает время, которое робот должен выдерживать между загрузкой страниц. Если робот будет загружать страницы слишком часто, это может создать излишнюю нагрузку на сервер. Впрочем, современные поисковые машины по умолчанию задают достаточную задержку в 1-2 секунды. На данный момент эта директива не учитывается Googlebot.

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

Еще не зарегистрированы?

Что такое robots.txt?

Robots.txt (стандарт исключений для поисковых роботов) — один из важнейших системных файлов веб-сайта, представляет собой TXT-файл, содержащий правила индексирования для роботов поисковых систем. Был впервые представлен и принят консорциумом W3C 30 июня 1994 года. С тех пор используется большинством известных поисковых машин, хотя не является обязательным стандартом и используется на добровольной основе.

Для чего нужен robots.txt?

Robots.txt является своего рода “маршрутной картой” для поисковых ботов и инструктирует их на этапах индексации сайта. Он объясняет роботам, какие директории или страницы сайта индексировать, а какие нет. С его помощью можно закрыть от индексации:

  • важные директории и файлы на сайте, например панель администратора, личные кабинеты пользователей и т.д.;
  • технические, служебные страницы (напр. страница 404, версии страниц для печати, скрипты);
  • страницы регистрации и авторизации;
  • страницы внутреннего поиска по сайту;
  • формы заказов, квитанции, данные по доставке и т.д.;
  • разные конфиденциальные файлы;
  • дублированные или пустые страницы;
  • текстовые документы, например PDF и другие части сайта, которые не должны попадать в поиск.

Как создать robots.txt?

Создается robots.txt с помощью любого текстового редактора, поддерживающего веб-код, например Notepad++ (рекомендую) или AkelPad.

Название файла допускается только в нижнем регистре (lower-case) — «robots.txt», но не Robots.txt или ROBOTS.TXT.

Файл нужно сохранить в кодировке UTF-8 или ASCII.

Robots.txt должен располагаться в корневой директории сайта и открываться по адресу: https://www.вашдомен.com/robots.txt

При наличии нескольких поддоменов или доменов с нестандартными портами, robots должен располагаться в корневой директории для каждого из них отдельно:

http://поддомен.вашдомен.com/robots.txt
http://вашдомен.com:8181/robots.txt

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

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

Синтаксис robots.txt

Синтаксис файла robots довольно прост. Он состоит из директив, каждая начинается с новой строки, через двоеточие задается необходимое значение для директивы.

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

Основными являются три директивы, которые рекомендуется применять в такой последовательности:

    User-agent:указывается название поискового робота, для которого будут применятся правила

В одном файле robots можно использовать сразу несколько User-agent, обязательно разделяя их пустой строкой, к примеру:

User-agent: Yandex
Disallow: /administrator/
Allow: /wp-content/uploads/

User-agent: Google
Disallow: /administrator/
​Allow: /libraries/

  • Disallow:указывается относительный путь директории или файла сайта, которые нужно запретить индексировать
  • Allow:указывается относительный путь директории или файла, которые нужно разрешить поисковику индексировать (не является обязательной)

  • Для более гибкой настройки директив можно использовать дополнительные выражения:

    • * (звездочка) — перебор всех значений, любая последовательность символов;
    • $ (доллар) — конец строки;
    • # (решетка) — позволяет вставить комментарий. Все что идет за этим символом — робот не воспринимает до конца следующей строки;

    User-agent: * # правила будут действовать для всевозможных поисковых роботов
    Disallow: /script$ # заблокирован ‘script’, но открыт ‘/script_public.pl’

    Примечание: Файл robots.txt не рекомендуется сильно засорять, он не должен быть слишком габаритным (Google — до 500 кб, Yandex — до 32 кб), иначе поисковик его просто проигнорирует.

    Дополнительные директивы robots.txt

    Clean-Param: указывается параметр URL (можно несколько), страницы с которым нужно исключить из индекса и не индексировать

    Данная директива используется только для User-agent: Yandex ! В Google параметр URL можно указать в Search Console или же использовать канонические ссылки (rel=»canonical»).

    Clean-Param позволит избавиться от дублей страниц, которые возникают в результате генерации динамических URL (реферальные ссылки, сессии пользователей, идентификаторы и т.д.).

    К примеру, если у вас на сайте появилось много страниц такого типа:

    www.mywebsite.com/testdir/index.php?& > www.mywebsite.com/testdir/index.php?& > www.mywebsite.com/testdir/index.php?& >

    И вы хотите, чтобы робот индексировал только www.mywebsite.com/testdir/index.php

    Создаем правило для очистки параметров «id», «catid» и «Itemid», например:

    User-agent: Yandex
    Disallow: /administrator/
    Allow: /wp-content/uploads
    Sitemap: https://www.mywebsite.com/sitemap.xml
    Host: https://mywebsite.com
    Clean-param: id&catid&Itemid /testdir/index.php
    Можно так же создать правило очистки параметров URL не только для определенной страницы, но и для всего сайта. Например, создать правило очистки UTM-меток:

    Crawl-delay: указывается время задержки в секундах между сканированием страниц

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

    User-agent: Yandex
    Disallow: /administrator/
    Allow: /wp-content/uploads
    Sitemap: https://www.mywebsite.com/sitemap.xml
    Host: https://mywebsite.com
    Clean-param: id&catid&Itemid /testdir/index.php
    Crawl-delay: 3
    Таким образом, только через три секунды краулер перейдет к индексированию следующей страницы.

      Sitemap:указываетcя полный путь к XML карте сайта

      Данная директива сообщает ботам, что у сайта есть карта сайта, что поможет ботам быстро обнаруживать новые страницы при индексации. Если сайт часто наполняется, это особенно актуально, так как ускорит и улучшит индексацию (напомню, вы можете проверить индексацию страницы в нашем сервисе).

      User-agent: Yandex
      Disallow: /administrator/
      Allow: /wp-content/uploads
      Sitemap: https://www.mywebsite.com/sitemap.xml

      Host: указывается главное «зеркало» сайта, то есть его предпочтительная версия

      Например, сайт доступен по http и https версии, чтобы краулер не запутался в “зеркалах” при индексации и не наделал дублей, указываем главный домен в директиве Host.

      Данная директива используется только для User-agent: Yandex

      User-agent: Yandex
      Disallow: /administrator/
      Allow: /wp-content/uploads
      Sitemap: https://www.mywebsite.com/sitemap.xml
      Host: https://mywebsite.com

      Если сайт не на https, тогда указываем домен без протокола http: mywebsite.com

      Примечание: 20 марта 2020 года Яндекс заявил, что директива Host не обязательна, и вместо нее можно теперь использовать 301-й редирект.

      Примеры robots.txt для WordPress и Joomla

      Перейдем к конкретным примерам правильной настройки robots для двух популярных CMS:

      WordPress

      User-agent: *
      Disallow: /cgi-bin
      Disallow: /?
      Disallow: /search/
      Disallow: /author/
      Disallow: /users/
      Disallow: */trackback
      Disallow: */feed
      Disallow: */rss
      Disallow: /wp-
      Disallow: *?s=
      Disallow: *&s=
      Disallow: */embed
      Disallow: /xmlrpc.php
      Disallow: *utm=
      Disallow: *openstat=
      Disallow: /tag/
      Allow: */uploads

      User-agent: Yandex
      Disallow: /cgi-bin
      Disallow: /?
      Disallow: /wp-
      Disallow: *?s=
      Disallow: *&s=
      Disallow: /search/
      Disallow: /author/
      Disallow: /users/
      Disallow: */trackback
      Disallow: */feed
      Disallow: */rss
      Disallow: */embed
      Disallow: /xmlrpc.php
      Allow: /wp-*.jpg
      Allow: /wp-admin/admin-ajax.php
      Allow: */uploads
      Allow: /wp-*.jpeg
      Allow: /wp-*.gif
      Allow: /*/*.js
      Allow: /*/*.css
      Allow: /wp-*.png
      Sitemap: https://путь к вашей карте XML формата
      Host: https://mywebsite.com

      User-agent: GoogleBot
      Disallow: /cgi-bin
      Disallow: /?
      Disallow: /search/
      Disallow: /author/
      Disallow: /users/
      Disallow: /wp-
      Disallow: *?s=
      Disallow: *&s=
      Disallow: */trackback
      Disallow: */feed
      Disallow: */rss
      Disallow: */embed
      Disallow: /xmlrpc.php
      Disallow: *utm=
      Disallow: *openstat=
      Allow: */uploads
      Allow: /*/*.js
      Allow: /*/*.css
      Allow: /wp-*.png
      Allow: /wp-*.jpg
      Allow: /wp-*.jpeg
      Allow: /wp-*.gif
      Allow: /wp-admin/admin-ajax.php
      Sitemap: https://путь к вашей карте XML формата

      Joomla

      User-agent: Yandex
      Disallow: /administrator/
      Disallow: /cache/
      Disallow: /includes/
      Disallow: /installation/
      Disallow: /language/
      Disallow: /libraries/
      Disallow: /modules/
      Disallow: /plugins/
      Disallow: /tmp/
      Disallow: /layouts/
      Disallow: /cli/
      Disallow: /bin/
      Disallow: /logs/
      Disallow: /components/
      Disallow: /component/
      Disallow: /component/tags*
      Disallow: /*mailto/
      Disallow: /*.pdf
      Disallow: /*%
      Disallow: /index.php
      Clean-Param: utm_source&utm_medium&utm_campaign
      Clean-Param: openstat
      Sitemap: https://путь к вашей карте XML формата
      Host: https://mywebsite.com

      User-agent: Googlebot
      Allow: /*.css?*$
      Allow: /*.js?*$
      Allow: /*.jpg?*$
      Allow: /*.png?*$
      Disallow: /administrator/
      Disallow: /cache/
      Disallow: /includes/
      Disallow: /installation/
      Disallow: /language/
      Disallow: /libraries/
      Disallow: /modules/
      Disallow: /plugins/
      Disallow: /tmp/
      Disallow: /layouts/
      Disallow: /cli/
      Disallow: /bin/
      Disallow: /logs/
      Disallow: /components/
      Disallow: /component/
      Disallow: /*mailto/
      Disallow: /*.pdf
      Disallow: /*%
      Disallow: /index.php
      Sitemap: https://путь к вашей карте XML формата

      Robots.txt или meta robots?

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

      Пример:

      Чтобы такого не произошло, страницы желательно дополнительно закрывать от индексации в meta robots:

      Ссылочный вес страницы можете закрывать (nofollow) или открывать (follow) на свое усмотрение, но если нужно полностью убрать страницу из поиска, то лучше применять: noindex, nofollow

      Проверка и тестирование robots.txt

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

      Эти инструменты позволяют проверить валидность robots.txt и на лету покажут ошибки, если они есть. Файл robots можно редактировать онлайн и сразу протестировать. Затем, если ошибок нет — просто скопируйте себе все строки и обновите robots.txt.

      Читайте также: A/B тест рассылки

      Google Search Console


      Заключение

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

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

      Ну и в завершение, официальные документации от самих поисковиков:

      Стандарт исключений для роботов

      • Стандарт исключений для роботов (robots.txt) — файл ограничения доступа роботам к содержимому на http-сервере. Файл должен находиться в корне сайта (то есть иметь путь относительно имени сайта /robots.txt). При наличии нескольких поддоменов файл должен располагаться в корневом каталоге каждого из них.

      Использование файла добровольно. Стандарт был принят консорциумом W3C 30 января 1994 года в списке рассылки robots-request@nexor.co.uk и с тех пор используется большинством известных поисковых машин.

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

    Связанные понятия

    В информатике трансклюзией называют включение одного электронного документа или его части в другие электронные документы посредством гипертекстовой ссылки. Трансклюзия обычно подразумевает отображение документа, на который делается ссылка. Документ (запись) отображается автоматически и доступен конечному пользователю. Кажется, что в результате трансклюзии образуется единый сложный документ, в то время как на самом деле его части были оперативно собраны из разных источников, которые могут храниться.

    U2F (англ. Universal 2nd Factor) — открытый, бездрайверный протокол для двухфакторной аутентификации, основанный на вызов-ответной аутентификации, позволяющий интернет-пользователям использовать U2F устройство как второй фактор для аутентификации на большом количестве онлайн-сервисов.

    Программа-вымогатель, программа-шантажист (англ. ransomware — контаминация слов ransom — выкуп и software — программное обеспечение) — тип зловредного программного обеспечения, предназначен для вымогательства, блокирует доступ к компьютерной системе или предотвращает считывание записанных в нём данных (часто с помощью методов шифрования), а затем требует от жертвы выкуп для восстановления исходного состояния.

    Могу ли я использовать robots.txt, чтобы отправить робот в определенную папку?

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

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

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

    Вы, вероятно, хотите использовать сайтмепы для достижения этой цели

    Стандарт исключений для роботов

    Стандарт исключений для роботов — стандарт ограничения доступа роботам к содержимому на http-сервере при помощи текстового файла robots.txt , находящегося в корне сайта (то есть имеющего путь относительно имени сайта /robots.txt ). Действие файла не распространяется на сайты, расположенные на поддоменах.

    Следование стандарту добровольно. Стандарт был принят консорциумом W3C 30 января 1994 года в списке рассылки robots-request@nexor.co.uk и с тех пор используется большинством известных поисковых машин.

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

    Содержание

    Файл состоит из записей. Записи разделяются одной или более пустых строк (признак конца строки: символы CR, CR+LF, LF). Каждая запись содержит непустые строки следующего вида:

    где поле — это либо User-agent , либо Disallow .

    В директиве User-agent указываются роботы, которые должны следовать указанным инструкциям (например, User-agent: Yandex , User-agent: YandexBot , User-agent: * ).

    Сравнение производится методом простого поиска подстроки. Например, запись

    запретит доступ как к разделу http://example.com/about/ (недоступная ссылка) , так и к файлу http://example.com/about.php (недоступная ссылка) , а запись

    — только к разделу http://example.com/about/ (недоступная ссылка) .

    Файл может содержать комментарии. Комментарием является часть строки, начинающаяся с символа #.

    Неправильно составленный robots.txt может привести к отрицательным последствиям. Например, весь сайт может «выпасть» из поискового индекса. Для проверки синтаксиса и структуры файла robots.txt существует ряд специализированных онлайн-служб:

    • Яндекс.Вебмастер — Анализ robots.txt (рус.) (выполняет проверку синтаксиса и разрешения для каждой отдельной страницы)
    • Google Search Console – Инструмент проверки файла robots.txt (рус.) (позволяет проверить разрешения для каждой отдельной страницы)

    Запрет доступа всех роботов ко всему сайту:

    Запрет доступа определённого робота к каталогу /private/:

    Allow: имеет действие, обратное директиве Disallow — разрешает доступ к определенной части ресурса. Поддерживается всеми основными поисковиками. В следующем примере разрешается доступ к файлу photo.html, а доступ поисковиков ко всей остальной информации в каталоге /album1/ запрещается.

    Crawl-delay: устанавливает время, которое робот должен выдерживать между загрузкой страниц. Если робот будет загружать страницы слишком часто, это может создать излишнюю нагрузку на сервер. Впрочем, современные поисковые машины по умолчанию задают достаточную задержку в 1-2 секунды. На данный момент эта директива не учитывается Googlebot.

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

    Настраиваем robots.txt правильно

    Правильная индексация страниц сайта в поисковых системах одна из важных задач, которая стоит перед владельцем ресурса. Попадание в индекс ненужных страниц может привести к понижению документов в выдаче. Для решения таких проблем и был принят стандарт исключений для роботов консорциумом W3C 30 января 1994 года — robots.txt.

    Что такое Robots.txt?

    Robots.txt — текстовый файл на сайте, содержащий инструкции для роботов какие страницы разрешены для индексации, а какие нет. Но это не является прямыми указаниями для поисковых машин, скорее инструкции несут рекомендательный характер, например, как пишет Google, если на сайт есть внешние ссылки, то страница будет проиндексирована.

    На иллюстрации можно увидеть индексацию ресурса без файла Robots.txt и с ним.

    Что следует закрывать от индексации:

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

    Как создать и добавить Robots.txt на сайт?


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

    Файл нужно добавить в корневой каталог сайта и он должен быть доступен по адресу: http://www.site.ru/ robots.txt

    Синтаксис файла robots.txt

    Инструкции для поисковых роботов задаются с помощью директив с различными параметрами.

    Директива User-agent

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

    Где * является спецсимволом для обозначения любого робота.

    Список популярных поисковых роботов:

    • Googlebot — основной робот Google;
    • YandexBot — основной индексирующий робот;
    • Googlebot-Image — робот картинок;
    • YandexImages — робот индексации Яндекс.Картинок;
    • Yandex Metrika — робот Яндекс.Метрики;
    • Yandex Market— робот Яндекс.Маркета;
    • Googlebot-Mobile —индексатор мобильной версии.

    Директивы Disallow и Allow

    С помощью данных директив можно задавать какие разделы или файлы можно индексировать, а какие не следует.

    Disallow — директива для запрета индексации документов на ресурсе. Синтаксис директивы следующий:

    В данном примере от поисковиков были закрыты от индексации все страницы из раздела site.ru/site/

      Для запрета папки сайта следует указать следующее:
      Disallow: /folder/Для запрета только одного файла нужно написать:
      Disallow: /folder/img.jpgЕсли нужно запретить файлы только определенного разрешения:
      Disallow: /*.css$Allow напротив является разрешающей инструкцией для индексации.
      User-agent: *
      Allow: /site
      Disallow: /

    Такая инструкция запрещает индексировать весь сайт, за исключением папки site.

    Директива Sitemap

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

    Директиву можно указать в любой из инструкций для любого робота.

    Директива Host

    Host является инструкцией непосредственно для робота Яндекса для указания главного зеркала сайта. Данная директива необходима в том случае, если у сайта есть несколько доменов, по которым он доступен. Указывать Host необходимо в секции для роботов Яндекса:

    В роботсе директива Host учитывается только один раз. Если в файле есть 2 директивы HOST, то роботы Яндекса будут учитывать только первую.

    Директива Clean-param

    Clean-param дает возможность запретить для индексации страницы сайта, которые формируются с динамическими параметрами. Такие страницы могут содержать один и тот же контент, что будет являться дублями для поисковых систем и может привести к понижению сайта в выдаче.

    Директива Clean-param имеет следующий синтаксис:

    Рассмотрим пример, на сайте есть динамические страницы:

    Для того, чтобы исключить подобные страницы из индекса следует задать директиву таким образом:

    Директива Crawl-delay

    Если роботы поисковиков слишком часто заходят на ресурс, это может повлиять на нагрузку на сервер (актуально для ресурсов с большим количеством страниц). Чтобы снизить нагрузку на сервер, можно воспользоваться директивой Crawl-delay.

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

    Особенности файла Robots.txt

    • Все директивы указываются с новой строки и не следует перечислять директивы в одной строке
    • Перед директивой не должно быть указано каких-либо других символов ( в том числе пробела )
    • Параметры директив необходимо указывать в одну строку
    • Правила в роботс указываются в следующей форме: [Имя_директивы]:[необязательный пробел][значение][необязательный пробел]
    • Параметры не нужно указывать в кавычках или других символах
    • После директив не следует указывать “;”

    • Пустая строка трактуется как конец директивы User-agent, если нет пустой строки перед следующим User-agent, то она может быть проигнорирована
    • В роботс можно указывать комментарии после знака решетки # (даже если комментарий переносится на следующую строку, на след строке тоже следует поставить #)
    • Robots.txt нечувствителен к регистру
    • Если файл роботс имеет вес более 32 Кб или по каким-то причинам недоступен или является пустым, то он воспринимается как Disallow: (можно индексировать все)
    • В директивах «Allow», «Disallow» можно указывать только 1 параметр
    • В директивах «Allow», «Disallow» в параметре директории сайта указываются со слешем (например, Disallow: /site)
    • Использование кириллицы в роботс не допускаются

    Спецсимволы robots.txt

    При указании параметров в директивах Disallow и Allow разрешается использовать специальные символы * и $, чтобы задавать регулярные выражения. Символ * означает любую последовательность символов (даже пустую).

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

    Особенности настройки robots.txt для Яндекса

    Особенностями настройки роботса для Яндекса является только наличие директории Host в инструкциях. Рассмотрим корректный роботс на примере:

    В данном случаем директива Host указывает роботам Яндекса, что главным зеркалом сайта является www.site.com (но данная директива носит рекомендательный характер).

    Особенности настройки robots.txt для Google

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

    С помощью директив Allow роботам Google доступны файлы стилей и скриптов, они не будут проиндексированы поисковой системой.

    Проверка правильности настройки роботс

    Проверить robots.txt на ошибки можно с помощью инструмента в панели Яндекс.Вебмастера:

    Также при помощи данного инструмента можно проверить разрешены или запрещены к индексации страницы:

    Еще одним инструментом проверки правильности роботс является “Инструмент проверки файла robots.txt” в панели Google Search Console:

    Но данный инструмент доступен только в том случае, если сайт добавлен в панель Вебмастера Google.

    Заключение

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

    Правильный robots.txt для WordPress должен быть составлен таким образом (все, что указано в комментариях не обязательно размещать):

    User-agent: Yandex
    Disallow: /cgi-bin # служебная папка для хранения серверных скриптов
    Disallow: /? # все параметры запроса на главной
    Disallow: /wp- # файлы WP: /wp-json/, /wp-includes, /wp-content/plugins
    Disallow: *?s= # результаты поиска
    Disallow: /search # результаты поиска
    Disallow: */page/ # страницы пагинации
    Disallow: /*print= # страницы для печати
    Host: www.site.ru

    User-agent: Googlebot
    Disallow: /cgi-bin # служебная папка для хранения серверных скриптов
    Disallow: /? # все параметры запроса на главной
    Disallow: /wp- # файлы WP: /wp-json/, /wp-includes, /wp-content/plugins
    Disallow: *?s= # результаты поиска
    Disallow: /search # результаты поиска
    Disallow: */page/ # страницы пагинации
    Disallow: /*print= # страницы для печати
    Allow: *.css # открыть все файлы стилей
    Allow: *.js # открыть все с js-скриптами

    User-agent: *
    Disallow: /cgi-bin # служебная папка для хранения серверных скриптов
    Disallow: /? # все параметры запроса на главной
    Disallow: /wp- # файлы WP: /wp-json/, /wp-includes, /wp-content/plugins
    Disallow: *?s= # результаты поиска
    Disallow: /search # результаты поиска
    Disallow: */page/ # страницы пагинации
    Disallow: /*print= # страницы для печати

    Sitemap: http://site.ru/sitemap.xml
    Sitemap: http://site.ru/sitemap1.xml

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

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

    Чтобы избежать подобных проблем, которые могут повлиять на позицию сайта в выдаче, следует правильно настроить файл robots.txt. Ниже приведен пример robots.txt для CMS 1C-Bitrix:

    User-Agent: Yandex
    Disallow: /personal/
    Disallow: /search/
    Disallow: /auth/
    Disallow: /bitrix/
    Disallow: /login/
    Disallow: /*?action=
    Disallow: /?mySort=
    Disallow: */filter/
    Disallow: */clear/
    Allow: /personal/cart/
    HOST: https://site.ru

    User-Agent: *
    Disallow: /personal/
    Disallow: /search/
    Disallow: /auth/
    Disallow: /bitrix/
    Disallow: /login/
    Disallow: /*?action=
    Disallow: /?mySort=
    Disallow: */filter/
    Disallow: */clear/
    Allow: /personal/cart/
    Sitemap: https://site.ru/sitemap.xml

    User-Agent: Googlebot
    Disallow: /personal/
    Disallow: /search/
    Disallow: /auth/
    Disallow: /bitrix/
    Disallow: /login/
    Disallow: /*?action=
    Disallow: /?mySort=
    Disallow: */filter/
    Disallow: */clear/
    Allow: /bitrix/js/
    Allow: /bitrix/templates/
    Allow: /bitrix/tools/conversion/ajax_counter.php
    Allow: /bitrix/components/main/
    Allow: /bitrix/css/
    Allow: /bitrix/templates/comfer/img/logo.png
    Allow: /personal/cart/
    Sitemap: https://site.ru/sitemap.xml

    Правильный robots.txt для OpenCart должен быть составлен таким образом:

    User-agent: Yandex
    Disallow: /*route=account/
    Disallow: /*route=affiliate/
    Disallow: /*route=checkout/
    Disallow: /*route=product/search
    Disallow: /index.php
    Disallow: /admin
    Disallow: /catalog
    Disallow: /download
    Disallow: /export
    Disallow: /system
    Disallow: /*?sort=
    Disallow: /*&sort=
    Disallow: /*?order=
    Disallow: /*&order=
    Disallow: /*?limit=
    Disallow: /*&limit=
    Disallow: /*?filter_name=
    Disallow: /*&filter_name=
    Disallow: /*?filter_sub_category=
    Disallow: /*&filter_sub_category=
    Disallow: /*?filter_description=
    Disallow: /*&filter_description=
    Disallow: /*?tracking=
    Disallow: /*&tracking=
    Disallow: /*?page=
    Disallow: /*&page=
    Disallow: /wishlist
    Disallow: /login
    Host: site.ru

    User-agent: Googlebot
    Disallow: /*route=account/
    Disallow: /*route=affiliate/
    Disallow: /*route=checkout/
    Disallow: /*route=product/search
    Disallow: /index.php
    Disallow: /admin
    Disallow: /catalog
    Disallow: /download
    Disallow: /export
    Disallow: /system
    Disallow: /*?sort=
    Disallow: /*&sort=
    Disallow: /*?order=
    Disallow: /*&order=
    Disallow: /*?limit=
    Disallow: /*&limit=
    Disallow: /*?filter_name=
    Disallow: /*&filter_name=
    Disallow: /*?filter_sub_category=
    Disallow: /*&filter_sub_category=
    Disallow: /*?filter_description=
    Disallow: /*&filter_description=
    Disallow: /*?tracking=
    Disallow: /*&tracking=
    Disallow: /*?page=
    Disallow: /*&page=
    Disallow: /wishlist
    Disallow: /login
    Allow: *.css
    Allow: *.js

    User-agent: *
    Disallow: /*route=account/
    Disallow: /*route=affiliate/
    Disallow: /*route=checkout/
    Disallow: /*route=product/search
    Disallow: /index.php
    Disallow: /admin
    Disallow: /catalog
    Disallow: /download
    Disallow: /export
    Disallow: /system
    Disallow: /*?sort=
    Disallow: /*&sort=
    Disallow: /*?order=
    Disallow: /*&order=
    Disallow: /*?limit=
    Disallow: /*&limit=
    Disallow: /*?filter_name=
    Disallow: /*&filter_name=
    Disallow: /*?filter_sub_category=
    Disallow: /*&filter_sub_category=
    Disallow: /*?filter_description=
    Disallow: /*&filter_description=
    Disallow: /*?tracking=
    Disallow: /*&tracking=
    Disallow: /*?page=
    Disallow: /*&page=
    Disallow: /wishlist
    Disallow: /login

    Правильный robots.txt для Umi CMS должен быть составлен таким образом (проблемы с дублями страниц в таком случае не должно быть):

    User-Agent: Yandex
    Disallow: /?
    Disallow: /emarket/addToCompare
    Disallow: /emarket/basket
    Disallow: /go_out.php
    Disallow: /images
    Disallow: /files
    Disallow: /users
    Disallow: /admin
    Disallow: /search
    Disallow: /install-temp
    Disallow: /install-static
    Disallow: /install-libs
    Host: site.ru

    User-Agent: Googlebot
    Disallow: /?
    Disallow: /emarket/addToCompare
    Disallow: /emarket/basket
    Disallow: /go_out.php
    Disallow: /images
    Disallow: /files
    Disallow: /users
    Disallow: /admin
    Disallow: /search
    Disallow: /install-temp
    Disallow: /install-static
    Disallow: /install-libs
    Allow: *.css
    Allow: *.js

    User-Agent: *
    Disallow: /?
    Disallow: /emarket/addToCompare
    Disallow: /emarket/basket
    Disallow: /go_out.php
    Disallow: /images
    Disallow: /files
    Disallow: /users
    Disallow: /admin
    Disallow: /search
    Disallow: /install-temp
    Disallow: /install-static
    Disallow: /install-libs

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

    User-agent: Yandex
    Disallow: /administrator/
    Disallow: /cache/
    Disallow: /components/
    Disallow: /component/
    Disallow: /includes/
    Disallow: /installation/
    Disallow: /language/
    Disallow: /libraries/
    Disallow: /media/
    Disallow: /modules/
    Disallow: /plugins/
    Disallow: /templates/
    Disallow: /tmp/
    Disallow: /*?start=*
    Disallow: /xmlrpc/
    Host: www.site.ru

    User-agent: Googlebot
    Disallow: /administrator/
    Disallow: /cache/
    Disallow: /components/
    Disallow: /component/
    Disallow: /includes/
    Disallow: /installation/
    Disallow: /language/
    Disallow: /libraries/
    Disallow: /media/
    Disallow: /modules/
    Disallow: /plugins/
    Disallow: /templates/
    Disallow: /tmp/
    Disallow: /*?start=*
    Disallow: /xmlrpc/
    Allow: *.css
    Allow: *.js

    User-agent: *
    Disallow: /administrator/
    Disallow: /cache/
    Disallow: /components/
    Disallow: /component/
    Disallow: /includes/
    Disallow: /installation/
    Disallow: /language/
    Disallow: /libraries/
    Disallow: /media/
    Disallow: /modules/
    Disallow: /plugins/
    Disallow: /templates/
    Disallow: /tmp/
    Disallow: /*?start=*
    Disallow: /xmlrpc/


    Как правильно работать с исключениями в DDD

    В рамках недавно прошедшей конференции DotNext 2020 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.

    Также, изучая множество ресурсов, начиная от вопросов на stackoverflow и заканчивая платными курсами по архитектуре, можно наблюдать, что в IT-сообществе сложилось неоднозначное отношение к исключениям и к тому, как их использовать.

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

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

    Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.

    В данной статье я расскажу о практиках, принятых в нашей команде (если кратко — мы используем все подходы и ни один из них не является догмой).

    Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.

    На работу с исключениями мы посмотрим с трех ракурсов:

    1. Общие правила работы с исключениями
    2. Исключения, ошибки и луковая архитектура
    3. Частные случаи для Web-приложений

    Общие правила работы с исключениями

    Исключения, ошибки и луковая архитектура

    В последующих разделах рассмотрим ответственности и правила выброса/обработки исключений/ошибок для следующих слоев:

    • Application Hosts
    • Infrastructure
    • Application Services
    • Domain core

    Application Host

    За что отвечает

    • Composition root, настраивающий работу всего приложения.
    • Граница взаимодействия с внешним миром — пользователи, другие сервиса, запуск по расписанию.

    Поскольку это достаточно сложные ответственности, стоит ими и ограничиться. Остальные ответственности отдаем внутренним слоям.

    Как обрабатывает ошибки из Result

    Транслирует во внешний мир, преобразуя в соответствующий формат (например в http response).

    Как генерирует Result

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

    Как обрабатывает исключения

    1. Скрывает детали и преобразует в формат, пригодный для отправки во внешний мир
    2. Логирует.

    Как выбрасывает исключения

    Никак, данный слой самый внешний и не содержит логики — ему некому отдать исключение.

    Infrastructure

    За что отвечает

    1. Адаптеры к портам, или попросту реализации Domain-интерфейсов, дающие доступ к инфраструктуре — сторонним сервисам, базам данных, active directory и пр. Данный слой должен быть по возможности “глупым” и содержать как можно меньше логики.
    2. При необходимости может выступать как Anti-corruption layer.

    Как обрабатывает ошибки из Result

    Мне неизвестны провайдеры к базам данных и прочим сервисам, работающие на монаде Result. Однако, некоторые сервисы работают на кодах возврата. В таком случае преобразуем их в формат Result, требуемый портом.

    Как генерирует Result

    В общем случае данный слой не содержит логики, значит, и ошибки не генерирует. Но в случае использования в качестве anti corruption layer возможны самые разные варианты. Например, разбор исключений от legacy-сервиса и преобразование в Result тех исключений, которые являются простыми сообщениями валидации.

    Как обрабатывает исключения

    В общем случае выбрасывает дальше, при необходимости залогировав детали. Если реализуемый порт допускает в контракте возврат Result, то инфраструктура преобразует в Result те типы исключений, которые могут быть обработаны.

    Например, используемый в проекте брокер сообщений бросает исключения при попытке отправить сообщение, когда брокер недоступен. Слой Application Services готов к такой ситуации и в состоянии обработать ее политикой Retry, Circuit Breaker-ом или ручным откатом данных.

    В таком случае слой Application Services декларирует контракт, возвращающий Result в случае ошибки. А слой Infrastructure реализует данный порт, преобразуя исключение от брокера в Result. Естественно, преобразует только конкретные типы исключений, а не все подряд.

    Используя такой подход, мы получаем два преимущества:

    1. Явно декларируем возможность ошибки в контракте.
    2. Избавляемся от ситуации, когда Application Service знает, как обработать ошибку, но не знает тип исключения, поскольку абстрагирован от конкретного брокера сообщений. При этом строить блок catch на базовый System.Exception означает захватить все типы исключений, а не только те, с которыми может справиться Application Service.

    Как выбрасывает исключения

    Зависит от специфики системы.

    Например, LINQ-операторы Single и First при запросе несуществующих данных выбрасывают исключение InvalidOperationException. Но этот тип исключения используется в .NET повсеместно, что лишает возможности выполнять его обработку гранулированно.

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

    Если же запрошенные данные не найдены и это допустимо — это стоит явно декларировать в контракте порта. Например, с использованием монады Maybe.

    Application Services

    За что отвечает

    1. Валидация входных данных.
    2. Оркестрация и координация сервисов — старт и завершение транзакций, реализация распределенных сценариев и т.д.
    3. Загрузка domain-объектов и внешних данных через порты к Infrastructure, последующий вызов команд в Domain Core.



    Как обрабатывает ошибки из Result

    Ошибки от domain core транслирует во внешний мир без изменений. Ошибки от Infrastructure может обрабатывать посредством политик Retry, Circuit Breaker или транслировать наружу.

    Как генерирует Result

    Может реализовать валидацию в виде Result.

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

    Как обрабатывает исключения

    Предполагая, что исключения инфраструктуры, которые приложение в состоянии обработать, уже преобразованы слоем Infrastructure в Result — никак не обрабатывает.

    Как выбрасывает исключения

    В общем случае — никак. Но есть пограничные варианты, описанные в финальном разделе статьи.

    Domain core

    За что отвечает

    Реализация бизнес-логики, “ядро” системы и основной смысл ее существования.

    Как обрабатывает ошибки из Result

    Поскольку слой внутренний и ошибки возможны только от объектов в том же домене, обработка сводится либо к бизнес-правилам, либо к трансляции ошибки наверх в исходном виде.

    Как генерирует Result

    При нарушении бизнес-правил, которые инкапсулированы в Domain Core и не покрываются валидацией входных данных на уровне Application Services. Вообще в данном слое Result используется наиболее часто.

    Как обрабатывает исключения

    Никак. Исключения из инфраструктуры уже обработаны слоем Infrastructure, данные уже пришли структурированные, полные и проверенные благодаря слою Application Services. Соответственно, все исключения, которые могут вылететь, будут действительно исключениями.

    Как выбрасывает исключения

    Обычно здесь работает общее правило: чем меньше исключений — тем лучше.

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

    Как правило, речь идет о выполнении команд, недопустимых для текущего состояния объекта.

    Конечно, соответствующая кнопка на UI не должна быть видна в данном состоянии. Мы не должны получить команду из шины в данном состоянии. Все это верно при условии, что внешние слои и системы выполнили свою функцию нормально. Но в Domain Core мы не должны знать о существовании внешних слоев и верить в корректность их работы, мы должны защищать инварианты системы.

    Какие-то из проверок можно разместить в Application Services на уровне валидации. Но это может превратиться в defensive programming, который в крайних проявлениях приводит к следующему:

    1. Ослабляется инкапсуляция, поскольку определенные инварианты должны быть проверены на внешнем слое.
    2. В наружный слой “протекают” знания о предметной области, проверки могут дублироваться обоими слоями.
    3. Проверка допустимости выполнения команды из внешнего слоя может быть более сложной и менее надежной, чем проверка доменным объектом невозможности выполнить команду в текущем состоянии.

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

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

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

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

    Какой тип или типы исключений использовать в данном случае? По логике, это должен быть отдельный тип исключения, чтобы мы смогли выделить его среди других и чтобы его случайно не зацепило обработками исключений из внешнего слоя. Иерархия или множество исключений нам тоже не нужны, суть одна — произошло нечто недопустимое. Мы в своих проектах создаем для этого тип CorruptedInvariantException, и используем его в соответствующих ситуациях.

    Частные случаи для Web-приложений

    Существенным отличием web-приложений от других (desktop, демоны и windows сервиса и т.д.) является взаимодействие с внешним миром в форме краткосрочных операций (обработки HTTP-запросов), по выполнении которых приложение тут же “забывает” о произошедшем.

    Также после завершения обработки запроса всегда формируется ответ. Если выполняемая нашим кодом операция не возвращает данные, платформа все равно вернет response, содержащий status code. Если операция была прервана исключением, то платформа все равно вернет ответ, содержащий соответствующий status code.

    Чтобы реализовать подобное поведение, обработка запросов в Web-платформах построена в виде конвейеров (pipe). Сначала выполняется последовательная обработка запроса (request), а затем подготовка ответа (response).

    Мы можем использовать middleware, action filter, http handler или ISAPI filter (в зависимости от платформы) и встроиться в этот конвейер на любом этапе. И на любом этапе обработки запроса мы можем прервать обработку и конвейер перейдет к формированию ответа.

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

    Какое все это имеет отношение к работе с исключениями, спросите вы?

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

    Исключения использовать плохо, потому что это семантика goto.

    Повсеместное использовании Result приводит к тому, что мы таскаем его (Result) по всем слоям приложения, а при формирования ответа нужно как-то Result разобрать, чтобы понять, какой вернуть status code. Еще этот код разбора желательно обобщить и затолкать в Middleware или ActionFilter, что становится отдельным приключением. То есть Result мало чем лучше исключений.

    Что делать в такой ситуации?

    Не возводить абсолют. Мы устанавливаем правила себе на благо, а не во вред.

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

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

    Ранее мы упомянули два кастомных типа, которые используем: ItemNotFoundException (трансформируем в 404) и CorruptedInvariant (преобразуется в 500).

    Если вы проверяете права пользователей, потому что они не ложатся на модель ролей или claim-ов, то допустимо создать кастомный ForbiddenException (Status code 403).

    И, наконец, валидация. Мы все равно не можем ничего сделать, пока пользователь не модифицирует свой запрос, эта семантика описана кодом 422. Значит мы прерываем операцию и отправляем запрос прямиком на выход. Это также допустимо сделать, используя exception. Например, в библиотеке FluentValidation уже есть встроенный тип исключения, который передает на клиент все детали, необходимые, чтобы внятно отобразить пользователю, что не так с запросом.


    На этом все. А как вы работаете с исключениями?

    Могу ли я использовать robots.txt для отправки роботов в определенную папку?

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

    Блог находится в каталоге /blog и нет ссылок с основного сайта на блог. Поэтому я полагаю, что роботы просто не могут добраться туда.

    Есть ли способ отправить роботов в конкретный каталог с помощью robots.txt ? Есть ли какое-либо другое решение, кроме ссылки на основной сайт?

    Вероятно, вы захотите использовать sitemaps для

    Cnsearch стандарт исключений для роботов

    Martijn Koster , перевод А. Аликберова

    Статус этого документа

    Этот документ составлен 30 июля 1994 года по материалам обсуждений в телеконференции robots-request@nexor.co.uk (сейчас конференция перенесена на WebCrawler. Подробности см. Robots pages at WebCrawler info.webcrawler.com/mak/projects/robots/) между большинством производителей поисковых роботов и другими заинтересованными людьми.Также эта тема открыта для обсуждения в телеконференции Technical World Wide Web www-talk@info.cern.ch Сей документ основан на предыдущем рабочем проекте под таким же названием.

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

    Последнюю версию этого документа можно найти по адресу info.webcrawler.com/mak/projects/robots/robots.html

    Поисковые роботы (wanderers, spiders) — это программы, которые индексируют веб-страницы в сети Internet.

    В 1993 и 1994 годах выяснилось, что индексирование роботами серверов порой происходит против желания владельцев этих серверов. В частности, иногда работа роботов затрудняет работу с сервером обычных пользователей, иногда одни и те же файлы индексируются несколько раз. В других случаях роботы индексируют не то, что надо, например, очень «глубокие» виртуальные директории, временную информацию или CGI-скрипты. Этот стандарт призван решить подобные проблемы.

    Для того, чтобы исключить посещение сервера или его частей роботом необходимо создать на сервере файл, содержащий информацию для управления поведением поискового робота. Этот файл должен быть доступен по протоколу HTTP по локальному URL /robots.txt. Содержание этого файла см. ниже.

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

    Выбор именно такого URL мотивирован несколькими критериями:

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

    Формат и семантика файла /robots.txt следующие:

    Файл должен содержать одну или несколько записей (records), разделенных одной или несколькими пустыми строками (оканчивающимися CR, CR/NL или NL). Каждая запись должна содержать строки (lines) в форме:

    Поле является регистронезависимым.

    Комментарии могут быть включены в файл в обычной для UNIX форме: символ # означает начало комментария, конец строки — конец комментария.

    Запись должна начинаться с одной или нескольких строк User-Agent, следом должна быть одна или несколько строк Disallow, формат которых приведен ниже. Нераспознанные строки игнорируются.

    • значением этого поля должно являться имя поискового робота, которому в этой записи устанавливаются права доступа.
    • если в записи указано более одного имени робота, то права доступа распространяются для всех указанных имен.
    • заглавные или строчные символы роли не играют
    • если в качестве значения этого поля указан символ «*», то заданные в этой записи права доступа распространяются на любых поисковых роботов, запросивших файл /robots.txt
    • значением этого поля должен являться частичный URL, который не должен индексироваться. Это может быть полный путь или частичный; любой URL, начинающийся с такого пути не должен индексироваться. Например, Disallow: /help закрывает и /help.html, и /help/index.html, тогда как
      Disallow: /help/- только /help/index.html.
    • если значение Disallow не указано, то это означает, что индексируется все дерево каталогов сервера

    Любая запись (record) должна состоять хотя бы из одной строки (line) User-Agent и одной — Disallow

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

    В примере 1 закрывается от индексации содержимое директорий /cyberworld/map/ и /tmp/.

    В примере 2 закрывается от индексации содержимое директории /cyberworld/map/, однако поисковому роботу cybermapper все разрешено.

    В примере 3 любому поисковому роботу запрещается индексировать сервер.

    В настоящее время стандарт несколько изменился, например, можно записывать в строке User-Agent несколько имен роботов, разделенных пробелами или табуляторами.

    Cnsearch стандарт исключений для роботов

    Note that «recursive» here doesn’t limit the definition to any specific traversal algorithm; even if a robot applies some heuristic to the selection and order of documents to visit and spaces out requests over a long space of time, it is still a robot.

    Normal Web browsers are not robots, because the are operated by a human, and don’t automatically retrieve referenced documents (other than inline images).

    Web robots are sometimes referred to as Web Wanderers, Web Crawlers, or Spiders. These names are a bit misleading as they give the impression the software itself moves between sites like a virus; this not the case, a robot simply visits sites by requesting documents from them.

    What is an agent?

    What is a search engine?

    What other kinds of robots are there?

    So what are Robots, Spiders, Web Crawlers, Worms, Ants

    Aren’t robots bad for the web?

    So no, robots aren’t inherently bad, nor inherently brilliant, and need careful attention.

    Are there any robot books?

    Its coverage of HTTP, HTML, and Web libraries is a bit too thin to be a «how to write a web robot» book, but it provides useful background reading and a good overview of the state-of-the-art, especially if you haven’t got the time to find all the info yourself on the Web.

    Published by New Riders, ISBN 1-56205-463-5.

    Bots and Other Internet Beasties by Joseph Williams I haven’t seen this myself, but someone said: The William’s book ‘Bots and other Internet Beasties’ was quit disappointing. It claims to be a ‘how to’ book on writing robots, but my impression is that it is nothing more than a collection of chapters, written by various people involved in this area and subsequently bound together.


    Published by Sam’s, ISBN: 1-57521-016-9

    Web Client Programming with Perl by Clinton Wong This O’Reilly book is planned for Fall 1996, check the O’Reilly Web Site for the current status. It promises to be a practical book, but I haven’t seen it yet. A few others can be found on the The Software Agents Mailing List FAQ

    Where do I find out more about robots?

    While this is hosted at one of the major robots’ site, it is an unbiased and reasoneably comprehensive collection of information which is maintained by Martijn Koster .

    Of course the latest version of this FAQ is there.

    You’ll also find details and an archive of the robots mailing list, which is intended for technical discussions about robots.

    Indexing robots

    How does a robot decide where to visit?

    Most indexing services also allow you to submit URLs manually, which will then be queued and visited by the robot.

    Sometimes other sources for URLs are used, such as scanners through USENET postings, published mailing list achives etc.

    Given those starting points a robot can select URLs to visit and index, and to parse and use as a source for new URLs.

    How does an indexing robot decide what to index?

    We hope that as the Web evolves more facilities becomes available to efficiently associate meta data such as indexing information with a document. This is being worked on.

    How do I register my page with a robot?

    Fortunately you don’t have to submit your URL to every service by hand: Submit-it will do it for you.

    For Server Administrators

    How do I know if I’ve been visited by a robot?

    If your server supports User-agent logging you can check for retrievals with unusual User-agent heder values.

    Finally, if you notice a site repeatedly checking for the file ‘/robots.txt’ chances are that is a robot too.

    I’ve been visited by a robot! Now what?

    If you think you have discovered a new robot (ie one that is not listed on the list of active robots, and it does more than sporadic visits, drop me a line so I can make a note of it for future reference. But please don’t tell me about every robot that happens to drop by!

    A robot is traversing my whole site too fast!

    First of all check if it is a problem by checking the load of your server, and monitoring your servers’ error log, and concurrent connections if you can. If you have a medium or high performance server, it is quite likely to be able to cope a high load of even several requests per second, especially if the visits are quick.

    However you may have problems if you have a low performance site, such as your own desktop PC or Mac you’re working on, or you run low performance server software, or if you have many long retrievals (such as CGI scripts or large documents). These problems manifest themselves in refused connections, a high load, performance slowdowns, or in extreme cases a system crash.

    If this happens, there are a few things you should do. Most importantly, start logging information: when did you notice, what happened, what do your logs say, what are you doing in response etc; this helps investigating the problem later. Secondly, try and find out where the robot came from, what IP addresses or DNS domains, and see if they are mentioned in the list of active robots. If you can identify a site this way, you can email the person responsible, and ask them what’s up. If this doesn’t help, try their own site for telephone numbers, or mail postmaster at their domain.

    If the robot is not on the list, mail me with all the information you have collected, including actions on your part. If I can’t help, at least I can make a note of it for others.

    How do I keep a robot off my server?

    Robots exclusion standard

    Why do I find entries for /robots.txt in my log files?

    If you don’t care about robots and want to prevent the messages in your error logs, simply create an empty file called robots.txt in the root level of your server.

    Don’t put any HTML or English language «Who the hell are you?» text in it — it will probably never get read by anyone :-)

    How do I prevent robots scanning my site?

    Where do I find out how /robots.txt files work?

    The first paragraph specifies that the robot called ‘webcrawler’ has nothing disallowed: it may go anywhere.

    The second paragraph indicates that the robot called ‘lycra’ has all relative URLs starting with ‘/’ disallowed. Because all relative URL’s on a server start with ‘/’, this means the entire site is closed off.

    The third paragraph indicates that all other robots should not visit URLs starting with /tmp or /log. Note the ‘*’ is a special token; its not a regular expression.

    Two common errors:

    • Regular expressions are _not_ supported: instead of ‘Disallow: /tmp/*’ just say ‘Disallow: /tmp’.
    • You shouldn’t put more than one path on a Disallow line (this may change in a future version of the spec)

    Will the /robots.txt standard be extended?

    What if I can’t make a /robots.txt file?

    The basic idea is that if you include a tag like:

    Availability

    Where can I use a robot?

    Where can I get a robot?

    In the meantime, two indexing robots that you should be able to get hold of are Harvest (free), and Verity’s.

    Where can I get the source code for a robot?

    Alternatively check out the libwww-perl5 package, that has a simple example.

    I’m writing a robot, what do I need to be careful of?


    I’ve written a robot, how do I list it?

    Несколько слов о том, как работают роботы (spiders) поисковых машин

    Эта статья вовсе не является попыткой объяснить, как работают поисковые машины вообще (это know-how их производителей). Однако, по моему мнению, она поможет понять как можно управлять поведением поисковых роботов (wanderers, sp > Первой причиной того, что я решился написать эту статью, явился случай, когда я исследовал файл логов доступа к моему серверу и обнаружил там следующие две строки:

    lycosidae.lycos.com — — [01/Mar/1997:21:27:32 -0500] «GET /robots.txt HTTP/1.0» 404 —
    lycos > то есть Lycos обратился к моему серверу, на первый запрос получил, что файла /robots.txt нет, обнюхал первую страницу, и отвалил. Естественно, мне это не понравилось, и я начал выяснять что к чему.

    Оказывается, все «умные» поисковые машины сначала обращаются к этому файлу, который должен присутствовать на каждом сервере. Этот файл описывает права доступа для поисковых роботов, причем существует возможность указать для различных роботов разные права. Для него существует стандарт под названием Standart for Robot Exclusion.

    По мнению Луиса Монье (Louis Monier, Altavista), только 5% всех сайтов в настоящее время имеет не пустые файлы /robots.txt если вообще они (эти файлы) там существуют. Это подтверждается информацией, собранной при недавнем исследовании логов работы робота Lycos. Шарль Коллар (Charles P.Kollar, Lycos) пишет, что только 6% от всех запросов на предмет /robots.txt имеют код результата 200. Вот несколько причин, по которым это происходит:

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

    Формат файла /robots.txt.

    Файл /robots.txt предназначен для указания всем поисковым роботам (sp > Если робот Lycos не нашел своего описания в /robots.txt — он поступает так, как считает нужным. Как только робот Lycos «увидел» в файле /robots.txt описание для себя — он поступает так, как ему предписано.

    При создании файла /robots.txt следует учитывать еще один фактор — размер файла. Поскольку описывается каждый файл, который не следует индексировать, да еще для многих типов роботов отдельно, при большом количестве не подлежащих индексированию файлов размер /robots.txt становится слишком большим. В этом случае следует применять один или несколько следующих способов сокращения размера /robots.txt:

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

    Записи (records) файла /robots.txt

    Общее описание формата записи.

    [ # comment string NL ]*

    User-Agent: [ [ WS ]+ agent_id ]+ [ [ WS ]* # comment string ]? NL

    [ # comment string NL ]*

    Disallow: [ [ WS ]+ path_root ]* [ [ WS ]* # comment string ]? NL

    # comment string NL

    Disallow: [ [ WS ]+ path_root ]* [ [ WS ]* # comment string ]? NL

    Описание параметров, применяемых в записях /robots.txt

    [. ]+ Квадратные скобки со следующим за ними знаком + означают, что в качестве параметров должны быть указаны один или несколько терминов.

    Например, после «User-Agent:» через пробел могут быть указаны один или несколько agent_ > [. ]* Квадратные скобки со следующим за ними знаком * означают, что в качестве параметров могут быть указаны ноль или несколько терминов.

    Например, Вы можете писать или не писать комментарии.

    [. ]? Квадратные скобки со следующим за ними знаком ? означают, что в качестве параметров могут быть указаны ноль или один термин.

    Например, после «User-Agent: agent_ > ..|.. означает или то, что до черты, или то, что после.

    WS один из символов — пробел (011) или табуляция (040)

    NL один из символов — конец строки (015) , возврат каретки (012) или оба этих символа (Enter)

    User-Agent: ключевое слово (заглавные и прописные буквы роли не играют).

    Параметрами являются agent_ > Disallow: ключевое слово (заглавные и прописные буквы роли не играют).

    Параметрами являются полные пути к неиндексируемым файлам или директориям

    # начало строки комментариев, comment string — собственно тело комментария.

    agent_ > path_root любое количество символов, не включающих WS и NL, которые определяют файлы и директории, не подлежащие индексированию.

    Расширенные комментарии формата.

    Каждая запись начинается со строки User-Agent, в которой описывается каким или какому поисковому роботу эта запись предназначается. Следующая строка: Disallow. Здесь описываются не подлежащие индексации пути и файлы. КАЖДАЯ запись ДОЛЖНА иметь как минимум эти две строки (lines). Все остальные строки являются опциями. Запись может содержать любое количество строк комментариев. Каждая строка комментария должна начинаться с символа # . Строки комментариев могут быть помещены в конец строк User-Agent и Disallow. Символ # в конце этих строк иногда добавляется для того, чтобы указать поисковому роботу, что длинная строка agent_ > Если не учитывать специфику работы каждого поискового робота, можно указать исключения для всех роботов сразу. Это достигается заданием строки

    Если поисковый робот обнаружит в файле /robots.txt несколько записей с удовлетворяющим его значением agent_ > Каждый поисковый робот будет определять абсолютный URL для чтения с сервера с использованием записей /robots.txt. Заглавные и строчные символы в path_root ИМЕЮТ значение.

    Disallow: /cgi-bin/ /tmp/

    В примере 1 файл /robots.txt содержит две записи. Первая относится ко всем поисковым роботам и запрещает индексировать все файлы. Вторая относится к поисковому роботу Lycos и при индексировании им сервера запрещает директории /cgi-bin/ и /tmp/, а остальные — разрешает. Таким образом сервер будет проиндексирован только системой Lycos.

    User-Agent: Copernicus Fred

    В примере 2 файл /robots.txt содержит две записи. Первая разрешает поисковым роботам Copernicus и Fred индексировать весь сервер. Вторая — запрещает всем и осебенно роботу Rex индексировать такие директории и файлы, как /tmp/, /tea-time/, /top-cat.txt, /traverse.this и т.д. Это как раз случай задания маски для директорий и файлов.

    # This is for every spider!

    # stay away from this

    Disallow: /spiders/not/here/ #and everything in it

    Disallow: # a little nothing

    Disallow: #This could be habit forming!

    # Don’t comments make code much more readable.

    В примере 3 — одна запись. Здесь всем роботам запрещается индексировать директорию /spiders/not/here/, включая такие пути и файлы как /spiders/not/here/really/, /spiders/not/here/yes/even/me.html. Однако сюда не входят /spiders/not/ или /spiders/not/her (в директории ‘/spiders/not/’).

    Некоторые проблемы, связанные с поисковыми роботами.

    Незаконченность стандарта ( Standart for Robot Exclusion ).

    К сожалению, поскольку поисковые системы появились не так давно, стандарт для роботов находится в стадии разработки, доработки, ну и т.д. Это означает, что в будущем совсем необязательно поисковые машины будут им руководствоваться.

    Эта проблема не слишком актуальна для российского сектора Internet, поскольку не так уж много в России серверов с таким серьезным трафиком, что посещение их поисковым роботом будет мешать обычным пользователям. Собственно, файл /robots.txt для того и предназначен, чтобы ограничивать действия роботов.

    Не все поисковые роботы используют /robots.txt.

    На сегодняшний день этот файл обязательно запрашивается поисковыми роботами только таких систем как Altavista, Excite, Infoseek, Lycos, OpenText и WebCrawler.

    Использование мета-тагов HTML.

    Начальный проект, который был создан в результате соглашений между программистами некоторого числа коммерческих индексирующих организаций (Excite, Infoseek, Lycos, Opentext и WebCrawler) на недавнем собрании Distributing Indexing Workshop (W3C) , ниже.

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

    • Неопределенности в спецификации файла /robots.txt
    • Точное определение использования мета-тагов HTML, или дополнительные поля в файле /robots.txt
    • Информация «Please visit»
    • Текущий контроль информации: интервал или максимум открытых соединений с сервером, при которых можно начинать индексировать сервер.

    Этот таг предназначен для пользователей, которые не могут контролировать файл /robots.txt на своих веб-сайтах. Таг позволяет задать поведение поискового робота для каждой HTML-страницы, однако при этом нельзя совсем избежать обращения робота к ней (как возможно указать в файле /robots.txt).

    robot_terms — это разделенный запятыми список следующих ключевых слов (заглавные или строчные символы роли не играют): ALL, NONE, INDEX, NOINDEX, FOLLOW, NOFOLLOW.

    NONE — говорит всем роботам игнорировать эту страницу при индексации (эквивалентно одновременному использованию ключевых слов NOINDEX, NOFOLLOW).

    ALL — разрешает индексировать эту страницу и все ссылки из нее (эквивалентно одновременному использованию ключевых слов INDEX, FOLLOW).

    INDEX — разрешает индексировать эту страницу

    NOINDEX — неразрешает индексировать эту страницу

    FOLLOW — разрешает индексировать все ссылки из этой страницы

    NOFOLLOW — неразрешает индексировать ссылки из этой страницы

    Если этот мета-таг пропущен или не указаны robot_terms, то по умолчанию поисковый робот поступает как если бы были указаны robot_terms= INDEX, FOLLOW (т.е. ALL). Если в CONTENT обнаружено ключевое слово ALL, то робот поступает соответственно, игнорируя возможно указанные другие ключевые слова.. Если в CONTENT имеются противоположные по смыслу ключевые слова, например, FOLLOW, NOFOLLOW, то робот поступает по своему усмотрению (в этом случае FOLLOW).

    Если robot_terms содержит только NOINDEX, то ссылки с этой страницы не индексируются. Если robot_terms содержит только NOFOLLOW, то страница индексируется, а ссылки, соответственно, игнорируются.

    phrases — разделенный запятыми список слов или словосочетаний (заглавные и строчные символы роли не играют), которые помогают индексировать страницу (т.е. отражают содержание страницы). Грубо говоря, это те слова, в ответ на которые поисковая система выдаст этот документ.

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

    Предполагаемые варианты исключения повторных посещений с помощью мета-тагов HTML

    Некоторые коммерческие поисковые роботы уже используют мета-таги, позволяющие осуществлять «связь» между роботом и вебмастером. Altavista использует KEYWORDS мета-таг, а Infoseek использует KEYWORDS и DESCRIPTION мета-таги.

    Индексировать документ один раз или делать это регулярно?

    Вебмастер может «сказать» поисковому роботу или файлу bookmark пользователя, что содержимое того или иного файла будет изменяться. В этом случае робот не будет сохранять URL, а броузер пользователя внесет или не внесет это файл в bookmark. Пока эта информация описывается только в файле /robots.txt, пользователь не будет знать о том, что эта страница будет изменяться.

    Мета-таг DOCUMENT-STATE может быть полезен для этого. По умолчанию, этот мета-таг принимается с CONTENT=STATIC.

    Как исключить индексирование генерируемых страниц или дублирование документов, если есть зеркала сервера?

    Генерируемые страницы — страницы, порождаемые действием CGI-скриптов. Их наверняка не следует индексировать, поскольку если попробовать провалиться в них из поисковой системы, будет выдана ошибка. Что касается зеркал, то негоже, когда выдаются две разные ссылки на разные сервера, но с одним и тем же содержимым. Чтобы этого избежать, следует использовать мета-таг URL с указанием абсолютного URL этого документа (в случае зеркал — на соответствующую страницу главного сервера).

    Источники

      Charles P.Kollar, John R.R. Leavitt, Michael Mauldin, Robot Exclusion Standard Revisited , www.kollar.com/robots.html

    Стандарт исключений для роботов

    Martijn Koster , перевод А. Аликберова

    Статус этого документа

    Этот документ составлен 30 июля 1994 года по материалам обсуждений в телеконференции robots-request@nexor.co.uk (сейчас конференция перенесена на WebCrawler. Подробности см. Robots pages at WebCrawler info.webcrawler.com/mak/projects/robots/) между большинством производителей поисковых роботов и другими заинтересованными людьми.Также эта тема открыта для обсуждения в телеконференции Technical World Wide Web www-talk@info.cern.ch Сей документ основан на предыдущем рабочем проекте под таким же названием.

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

    Последнюю версию этого документа можно найти по адресу info.webcrawler.com/mak/projects/robots/robots.html

    Поисковые роботы (wanderers, spiders) — это программы, которые индексируют веб-страницы в сети Internet.

    В 1993 и 1994 годах выяснилось, что индексирование роботами серверов порой происходит против желания владельцев этих серверов. В частности, иногда работа роботов затрудняет работу с сервером обычных пользователей, иногда одни и те же файлы индексируются несколько раз. В других случаях роботы индексируют не то, что надо, например, очень «глубокие» виртуальные директории, временную информацию или CGI-скрипты. Этот стандарт призван решить подобные проблемы.

    Для того, чтобы исключить посещение сервера или его частей роботом необходимо создать на сервере файл, содержащий информацию для управления поведением поискового робота. Этот файл должен быть доступен по протоколу HTTP по локальному URL /robots.txt. Содержание этого файла см. ниже.

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

    Выбор именно такого URL мотивирован несколькими критериями:

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

    Формат и семантика файла /robots.txt следующие:

    Файл должен содержать одну или несколько записей (records), разделенных одной или несколькими пустыми строками (оканчивающимися CR, CR/NL или NL). Каждая запись должна содержать строки (lines) в форме:

    Поле является регистронезависимым.

    Комментарии могут быть включены в файл в обычной для UNIX форме: символ # означает начало комментария, конец строки — конец комментария.

    Запись должна начинаться с одной или нескольких строк User-Agent, следом должна быть одна или несколько строк Disallow, формат которых приведен ниже. Нераспознанные строки игнорируются.

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

    • значением этого поля должен являться частичный URL, который не должен индексироваться. Это может быть полный путь или частичный; любой URL, начинающийся с такого пути не должен индексироваться. Например, Disallow: /help закрывает и /help.html, и /help/index.html, тогда как
      Disallow: /help/- только /help/index.html.
    • если значение Disallow не указано, то это означает, что индексируется все дерево каталогов сервера

    Любая запись (record) должна состоять хотя бы из одной строки (line) User-Agent и одной — Disallow

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

    В примере 1 закрывается от индексации содержимое директорий /cyberworld/map/ и /tmp/.

    В примере 2 закрывается от индексации содержимое директории /cyberworld/map/, однако поисковому роботу cybermapper все разрешено.

    В примере 3 любому поисковому роботу запрещается индексировать сервер.

    В настоящее время стандарт несколько изменился, например, можно записывать в строке User-Agent несколько имен роботов, разделенных пробелами или табуляторами.

    Перевод: Андрей Аликберов, info@citmgu.ru

    Популярность: 10, Last-modified: Thu, 28 May 1998 14:14:05 GMT

    Илон Маск рекомендует:  Изменение текста в INPUT
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL