Быстрая CMS
Обратная связь Карта сайта
Главная Создание сайтов Практика Строим CMS Наивное О проекте Блог

Роботы и как с ними дружить

Поисковые роботы – не враги, а помощники и это каждому ясно. Даже Yahoo, о котором так много злословят, приводит посетителей на сайт. Не нужно страдать максимализмом и считать, что кроме Яндекса, Google и Рамблера вам никто не нужен. Полезный трафик приходит и с других поисковиков – совершенно неразумно от него отказываться только потому, что его маловато. А значит, с роботами нужно дружить.

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

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

Хостинг тоже должен соответствовать вашим представлениям о посещаемости. Если вы выбираете хостинг по принципу «лишь бы подешевле», не удивляйтесь, когда выделенных вам ресурсов не хватит. Или готовьтесь сменить тарифный план на более дорогой, а то и переехать на выделенный сервер. Вам нужно малое время отклика сервера, иначе робот может уйти от вас ни с чем. Да и посетитель, которого вы ждали, тоже.

Но это все было предисловие, связанное с явными «тормозами» сайта. Есть еще и скрытые. Например, есть такое мнение: чем чаще робот будет переиндексировать сайт, тем лучше. Мнение верное – при частых визитах робота быстрее будут обнаружены и попадут в индекс новые документы, а значит, и посетителей станет побольше. И как это реализуют? Часто просто смехотворными способами.

Некоторые до сих пор вставляют в код страниц мета-тег Revisit-after: – в надежде, что робот придет через указанный срок. На этот мета-тег роботы не обращают внимания. У них свой график обхода сайтов, расчитанный исходя из реальной частоты пополнения контентом. Я сейчас набиваю статью за статьей, робот заходит на сайт, находит новые страницы, а в индексах ПС понемногу складывается «мнение» о скорости, с которой я пишу и о сроках, в которые нужно высылать робота за новой порцией писанины. Если я на пару месяцев прекращу пополнять сайт, боты станут ходить реже.

Следующее мнение: «А если в качестве времени последнего обновления документа (Last-Modified) отдавать текущее время, то робот будет считать, что контент часто обновляется и будет заходить чаще». Чепуха полнейшая. Просто роботу придется заново считать уже известную ему страницу, сравнить контент с сохраненной с прошлого раза копией и решить, изменилась она или нет. То есть, он будет перечитывать одно и то же, а новые страницы от этого в индексе быстрее не появятся. Уж лучше отдать ему время последней редакции в заголовке, чтобы не делал лишних движений.

С той же целью старательно запрещают кэширование документов сервером. Причем, запрещают со всей строгостью – отправляют заголовки "Cache-control: no-cache, no-store, must-revalidate". Донесем, мол, до робота самую свежую и актуальную версию. Это уместно на часто пополняемых форумах, да и там не стоит делать запрет кэширования настолько полным. А уж на страницах, где единожды написанная статья не меняется потом годами, это вообще бессмысленно.

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

Больше всего ресурсов забирает обработка запросов к базе данных – и работа сервера БД и разборка полученного результата запроса. Необходимые издержки. Но так ли они необходимы? Впереди рассказ о том, как сделать «умный» файловый кэш, который позволит обращаться к базе данных только один раз после обновления контента страницы. Или обновлять данные в кэше периодически – один сеанс работы с базой данных за несколько суток вместо одного сеанса при каждом вызове страницы.