Техническое SEO: как улучшить видимость в поисковиках?

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

В конце прошлого века я работал на компанию "Инктоми" (Inktomi). Многие знают эту компанию как поисковик, однако у нее были и другие направления деятельности. Одним из таких направлений являлась продажа сетевого программного обеспечения, включая и прокси-кэш под названием Traffic Server.

Как улучшить видимость в поисковиках при помощи хэдеров Cache Control?

Сейчас это может показаться странным, но данная компания делала больше денег на программе Traffic Server, чем на самом поисковике. Именно такой была экономическая ситуация в догугловском Интернете.

Это был выгодный бизнес до тех пор, пока:

  • доступ в интернет стал по-настоящему дешевым,
  • практически все клиенты потеряли интерес к этому бизнесу в конце 2000/начале 2001. (Inktomi была приобретена Yahoo! в 2002 году, а Traffic Server выложили в открытый доступ в 2009 году).

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

Обратите внимание: Когда я говорю о том, что страница находится в кэше, это не означает, что в кэше Google или Bing находится ссылка. Я говорю о том, что временно сохраненная версия страницы находится в поисковике, прокси кэше или веб браузере.

Примером типичного "недружелюбного" сайта является один из моих, где мы видим HTTP ответ, который выдает стандартную настройку Apache и Wordpress:

Пример недружелюбного ответа

Три обведенные линии HTTP обозначают следующее: "Не кэшировать это никогда, и ни при каких условиях".

Давайте рассмотрим эти "хэдеры" более детально:

  • Expires: указывает на то, как долго прокси-кэш или браузеры могут рассматривать данный документ как "свежий", не возвращаясь к нему. Если откатить данную дату на 2 десятка лет назад, то сервер будет регулярно выдавать сигналы о том, что информацию тут никогда не следует принимать за свежую.
  • Cache-control: используется для того, чтобы дать прокси-кэшу или браузерам информацию о кэшировании документа. "no-store" и "no-cache" запрещают кэширование документа. "must-revalidate" означает, что документ нельзя читать без проверки ответа от сервера. "post-check" и "pre-check" являются специальными настройками под IE, которые сообщают браузеру, что документ всегда должен загружаться с сервера.
  • Pragma: является хэдером HTTP и не оказывает никакого влияния на кэш.

Хэдеры кэш контрол и техническое SEO

Итак, а как связаны хэдеры кэш контрол (cache control) и техническая сторона SEO? Они связаны двумя способами:

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

Для начала давайте посмотрим на эффективность "проходимости".

Эффективность "проходимости" сайта

На индексирование поисковиком влияет только две строчки хэдеров кэш контрол. Эти типы запросов называются "условными GETами". Называются они так потому, что ответ на данный GET (получать) будет разным в зависимости от того, изменялась страница или нет.

Searchengineland поддерживает оба метода, поэтому именно этот сайт я буду использовать в примерах ниже.

Last-Modified/If-Modified-Since

Это самый распространенный и поддерживаемый условный GET. Он поддерживается поисковыми пауками и Google, и Bing, и Yandex (а также всеми знакомыми мне браузерами и прокси кэшами).

Вот как это работает. Первый раз, когда документ запрашивается, HTTP хэдер Last-Modified возвращает ответ в виде даты последнего изменения документа.

HTTP хэдер Last-Modified возвращает ответ в виде даты последнего изменения документа

В следующий раз, когда документ будет запрошен вновь, Googlebot или Bingbot добавить хэдер If-Modified-Since, содержащий ответ изменялся ли документ с момента последнего посещения или нет.

хэдер If-Modified-Since, содержащий ответ изменялся ли документ с момента последнего посещения или нет

Если документ не изменялся с момента последнего посещения, тогда сервер выдаст код 304 Page Not Modified (страница не изменялась) и не выдаст поисковику документ. В этом случае, клиент, будь то Googlebot, Bingbot или браузер будет загружать ту версию страницы, которую он загружал в первый раз.

Если же документ изменялся, то сервер выдаст код 200 OK вместе с документом.

то Googlebot, Bingbot или браузер будет загружать ту версию страницы, которую он загружал в первый раз

ETag/If-None-Match

If-None-Match работает подобно Last-Modified. Если документ запрашивается впервые, то выдается хэдер Etag. По своей сути Etag – это смесь атрибутов разных файлов.

Если документ запрашивается впервые, то выдается хэдер Etag

Второй запрос включает в себя If-None-Match хэдер, содержащий значение Etag. Если его значение совпадает с Etag, тогда сервер возвращает ответ 304 Page Not Modified (страница не изменялась).

Если его значение совпадает с Etag, тогда сервер возвращает ответ 304 Page Not Modified

Если же Etag не совпадает, тогда сервер выдает нормальный код 200 OK.

Если же Etag не совпадает, тогда сервер выдает нормальный код 200 OK

Etag/If-None-Match точно поддерживается Bing, но не понятно, поддерживается ли он Google. Опираясь на свой анализ логовых файлов, я могу точно сказать, что запросы Googlebot не поддерживают это (Возможно, пауки Google поддерживают это, я все еще занят исследованием).

Проблема с Etag/If-None-Match возникает, когда сайт использует несколько серверов одновременно. Каждый сервер будет генерировать свой Etag и они будут разные. Это в значительной степени снижает объем кэша сайтов, а количество запросов одной и той же страницы будут гораздо больше, пропорционально количеству серверов.

По ряду вышеперечисленных причин, вместо Etag/If-None-Match я рекомендую использовать Last-Modified/If-Modified-Since. Тем более, что последний распространен более широко.

Когда использовать эти условные GETы

Условные GETы могут быть использованы на любых статических веб-ресурсах, включая HTML страницы, XML карты сайта, файлы изображений, внешние файлы JavaScript и внешние CSS файлы.

  • Для работы на Apache должен быть установлен модуль mod_cache. Если после установки модуля сервер все еще не поддерживает GETы, тогда проверьте линию CacheDisable в файле httpd.conf или .htaccess.
  • В IIS7, кэширование контролируется элементом <caching> в конфигурационном файле сайта. Я не знаю точно, как включить кэширование в IIS6, кажется оно должно быть включено там по умолчанию.

Для динамических, программно-генерируемых файлов, HTTP хэдеры GETов посылаются специальным кодом страницы. Понять, стоит ли использовать хэдеры в данном случае, можно проведя подсчеты по двум факторам:

  • Требуется ли большое количество ресурсов (например, обращение к базам данных) для того, чтобы определить изменялась страница или нет?
  • Изменяется ли страница так же часто, как ее посещают поисковики?

Если ответ на оба вопроса ДА, тогда вводить условные GETы в ваши динамические страницы не целесообразно.

Скорость загрузки страницы

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

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

Есть два способа, для того, чтобы установить дату изменения при помощи HTTP хэдеров кэш-контрол:

  • Expires: <date>, указывает на дату, до которой можно сохранять копию документа.
  • Cache-control: max-age=<seconds>, количество секунд, за которые можно сохранять ресурс.

Согласно особенностям HTTP, максимальное время в Expires может быть установлено до 1 года. Я рекомендую устанавливать его минимум на несколько месяцев.

Конфигурирование времени Expiry

Для установки времени изменения в Apache, следует установить тег mod_expires и создать строки ExpiresDefault или ExpiresByType. Кэш-контрол также требует mod_headers.

Настроить IIS7 можно при помощи IIS менеджера или некоторых других коммандных инструментов.

Для ресурсов, которые генерируются динамически, данные хэдеры могут быть добавлены программно, по аналогии с другими хэдерами. Запомните, что дата в Expires: должна быть в правильном формате или она будет проигнорирована.

Другие ресурсы

Ниже представлены дополнительные ресурсы по кэшированию, так как эта статья затрагивает только протокол HTTP cache control. Чтобы узнать больше, вы можете пройти по ссылкам ниже.

  • Redbot.org – лучший софт по проверке кэша, о котором знаю я. Его я использую регулярно.
  • У Microsoft также есть неплохой инструмент.
  • Стандартный для российский вебмастеров инструмент Be1.ru.

Источник: How To Improve Crawl Efficiency With Cache Control Headers

Перевод: SEOM.info