Бюджет сканирования Googlebot и спрос на него: как это влияет на видимость вашего сайта в результатах поиска и как вы можете улучшить его

1. Как Google Crawl Budget подходит для SEO и как сайты сканируются, индексируются и ранжируются?
2. Должен ли я заботиться об этом? Является ли что-нибудь из этого действенным?
3. Что такое ограничение скорости сканирования Google?
4. Как Google определяет ограничение скорости сканирования сайта?
5. Можете ли вы изменить ограничение скорости сканирования вашего сайта?
6. Скорость сервера и скорость страницы
7. Ошибки сервера
8. Запрос изменения ограничения скорости сканирования в Google Search Console
9. Что такое спрос Google на сканирование?
10. Работа с лимитом скорости сканирования вашего сайта и требованием сканирования: как обеспечить быстрый...
11. Делаем URL доступными для обнаружения
12. Управление тем, что сканирует робот Googlebot
13. Фасетная навигация
14. Бесконечные URL
15. Бесконечные Следующие Ссылки
16. Бесконечные результаты поиска
17. Soft 404s
18. Бесконечные вариации URL
19. Что делать дальше?

Google недавно опубликовал информацию о «бюджете сканирования» робота Googlebot , который они определяют как комбинацию «ограничения скорости сканирования» сайта и «требования сканирования» Google для URL этого сайта. Эта публикация содержит много полезной информации, но как вы можете наилучшим образом применить эту информацию к особенностям вашего сайта?

Уже более 10 лет я помогаю группам сайтов с проблемами сканирования (в том числе и тогда, когда я работал в Google и помогал запускать такие инструменты, как Отчет об активности робота Googlebot и контроль скорости сканирования в 2006 году (сейчас называется Статистика ползания а также Скорость сканирования )) и ниже мои выноски для сайтов всех размеров.

Как Google Crawl Budget подходит для SEO и как сайты сканируются, индексируются и ранжируются?

Googlebot - это система, которая сканирует страницы веб-сайта (URL). Процесс в основном идет так:

1. Google «обнаруживает» URL различными способами ( XML Sitemaps , внутренние ссылки , внешняя ссылка, угадывание на основе общих веб-шаблонов и т. д.).
2. Google объединяет URL-адреса, найденные в различных источниках, в один консолидированный список, а затем сортирует этот список в порядке очередности.
3. Google устанавливает так называемый «бюджет сканирования», который определяет, как быстро они могут сканировать URL-адреса на сайте.
4. «Планировщик» предписывает роботу Google сканировать URL-адреса в порядке приоритета в соответствии с ограничениями бюджета сканирования.

Этот процесс продолжается. Таким образом, URL-адреса всегда добавляются в список, а список всегда имеет приоритет (так как URL-адреса из списка сканируются, новые URL-адреса добавляются и т. Д.), А бюджет сканирования корректируется.

Как отмечается в сообщении Google, «бюджет сканирования» основывается как на «предельном количестве просмотров» (технические ограничения), так и на «требовании сканирования» (насколько важно Google находит URL-адреса). Google может сканировать меньше URL, чем позволяет ограничение скорости сканирования, в зависимости от того, какие URL, по их мнению, стоит потратить на сканирование ресурсов.

Должен ли я заботиться об этом? Является ли что-нибудь из этого действенным?

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

• URL не могут ранжироваться, если они не проиндексированы, и они не будут проиндексированы, если они не просканированы
• Если вы хотите, чтобы URL сканировался (и индексировался и ранжировался), убедитесь, что:
  • URL доступен для обнаружения
  • Google считает URL-адрес ценным (поэтому он имеет высокий приоритет в списке сканирования)
  • Google не тратит весь бюджет сканирования на URL, которые вас не интересуют
  • бюджет сканирования максимально велик

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

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

Что такое ограничение скорости сканирования Google?

Google сканирует URL-адреса сайта, используя комбинацию параметров:

• Количество открытых соединений за один раз (количество одновременных запросов от Google к серверу вашего сайта)
• Количество времени между запросами

Например, если Google настроил ваш сайт для бюджета обхода в 10 соединений и 5 секунд между запросами, то Google может сканировать не более 120 URL-адресов за 60 секунд (10 запросов каждые 5 секунд).

Вы можете увидеть это в действии, зайдя на сайт в Google Search Console, затем щелкнув Настройки сайта . Ниже приведены примеры с двух сайтов: первый снимок экрана в каждой строке - самый медленный параметр, доступный для сайта, а второй снимок экрана в каждой строке - самый быстрый доступный параметр для сайта.

В этом объяснении отсутствует то, что Google не сканирует каждый сайт постоянно. Google не предоставил подробную информацию о том, как долго робот Googlebot проводит сканирование сайтов, но это частично основано на спросе на сканирование (подробнее об этом ниже).

Как Google определяет ограничение скорости сканирования сайта?

Google не хочет случайно отключить ваш сервер. Ограничение скорости сканирования предназначено для предотвращения этого. Факторы, влияющие на ограничение скорости сканирования сайта:

• Как быстро сервер, на котором размещается сайт, отвечает на запросы
• Возвращает ли сервер ошибки сервера или тайм-ауты в ответ на запросы

Можете ли вы изменить ограничение скорости сканирования вашего сайта?

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

Скорость сервера и скорость страницы

В SEO вы много слышите о «скорости страницы». Это не то же самое, что скорость сервера. «Скорость страницы», как правило, относится к времени загрузки страницы (сколько времени требуется странице для отображения для посетителя), тогда как скорость сервера - это сколько времени сервер отвечает на запрос страницы. Время загрузки страницы зависит от скорости сервера, но это не одно и то же.

Google рекомендует сокращение времени отклика сервера до 200 мс и отмечает, что «десятки потенциальных факторов» могут замедлить работу сервера.

Джон Мюллер из Google отметил в прошлом году что время отклика сервера, превышающее две секунды, является «чрезвычайно высоким временем отклика», что приводит к «серьезному ограничению количества URL-адресов, которые Google будет сканировать с сайта». Он позже разработаны в обсуждении этого комментария что время отклика сервера и скорость загрузки страницы «очень разные вещи, имеют разные эффекты и часто путаются».

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

Ошибки сервера

Вы можете узнать, получает ли робот Googlebot ошибки сервера при сканировании вашего сайта с Отчет об ошибках сканирования в консоли поиска Google ,

• Отчет об ошибках URL> Ошибка сервера покажет вам URL-адреса, которые Google пытался сканировать, код ответа (например, 502 или 504) и график, который поможет вам определить, увеличивается ли количество ошибок.
• Раздел «Ошибки сайта» покажет вам больше критических ошибок, которые не позволили Google-боту вообще получить доступ к сайту, включая проблемы с общим подключением, тайм-ауты и проблемы DNS.

Увидеть Справочная документация Google для получения более подробной информации об этих типах ошибок и как их исправить.

С помощью отчетов об ошибках сканирования Google может быть трудно понять, насколько серьезна проблема с ошибками URL (ошибки сайта всегда указывают на серьезную проблему). Вы определенно хотите уменьшить количество ошибок сервера, чтобы Google не снизил ограничение скорости сканирования, но проблема более критична, если 80% запросов вернули ошибку, чем если 2% запросов вернули ошибку.

Единственный способ узнать этот уровень детализации - это проанализировать журналы доступа вашего сервера (поскольку он предоставляет данные как по успешно просканированным URL-адресам, так и по URL-адресам, которые вернули ошибки). Keylime Toolbox обеспечивает это с нашими Инструмент Crawl Analytics (а также множество других замечательных инструментов). Keylime Toolbox Crawl Analytics составляет 49 долларов в месяц за ежедневный анализ (либо как отдельный инструмент, либо как дополнение к другому плану ). Если вы хотите настроить план Crawl Analytics, просто напишите нам по адресу [email protected] и мы поможем вам начать.

Часто я обнаруживаю, что URL-адреса, перечисленные с ошибками сервера, в отчетах об ошибках сканирования Google выявляют проблемы с неверной настройкой сервера. Например, группа URL-адресов может быть указана как возвращающая тайм-аут сервера, но на самом деле сервер не имеет тайм-аута, эти URL-адреса просто неправильно настроены для возврата ответа 504 вместо 404.

Как правило, это хороший совет SEO, многие ошибки при сканировании не повредят вашему сайту в целом - они просто означают, что эти конкретные URL-адреса, возвращающие ошибку, не будут проиндексированы. Но в случае ошибок сервера ваш сайт в целом может быть поврежден, поскольку эти конкретные URL-адреса не только не будут проиндексированы, но если Google встречает много ошибок сервера, они уменьшат ограничение скорости сканирования и просканируют меньше URL-адресов в целом.

Запрос изменения ограничения скорости сканирования в Google Search Console

Если Google сканирует ваш сайт слишком много, вы можете попросить их уменьшить количество посещений, перейдя к настройки сайта в консоли поиска Google ,

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

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

В приведенном ниже примере кажется, что ограничение скорости сканирования установлено на 6 запросов в секунду с 0,167 секундами между запросами:

Но я могу переместить белый индикатор на «низкий», и дисплей изменится на .5 запросов в секунду и 2 секунды между запросами:

И я могу переместить ползунок на «высокий», и дисплей меняется на 10 запросов в секунду и 0,1 секунды между запросами:

Что такое спрос Google на сканирование?

Ограничение скорости сканирования Google основано на технических ограничениях, но Google может не сканировать все URL-адреса на вашем сайте, даже если робот Google не ограничен.

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

В сообщении Google отмечается, что более «популярные» страницы сканируются чаще и что такие события, как перемещение сайта, могут вызвать и увеличить спрос на сканирование.

Конечно, все это более нюансировано, чем это. Планировщик упорядочивает сканирование URL-адресов сайта в соответствии с приоритетом. Порядок всегда меняется, так как URL-адреса сканируются, и о страницах собирается больше информации. Приоритет основан на многочисленных факторах, таких как:

• Является ли URL домашней страницей? Google любит часто сканировать домашнюю страницу сайтов, чтобы URL оставался в верхней части списка даже после повторного сканирования. Просматривая отчеты Crawl Analytics для наших клиентов Keylime Toolbox, мы обнаруживаем, что домашние страницы обычно сканируются каждый день.
• Является ли URL ценным / популярным? Google будет сканировать URL-адреса, которые он считает «ценными» довольно часто, чтобы поддерживать их актуальность в индексе, и будет сканировать URL-адреса, которые он считает некачественными, гораздо реже. То, как алгоритмы Google определяют «популярность», постоянно меняется, и они не предоставляют конкретных данных, но вы можете использовать свои собственные метрики, чтобы определить, считают ли посетители ваши страницы ценными. Есть ли у них PageRank, ценные внешние ссылки, ранжирование по множеству запросов, много кликов в результатах поиска, много общего в социальных сетях, низкий показатель отказов? У него много качественного контента или он в основном пустой / дубликат / спам?
• URL часто меняется? Если Google определит, что страница часто обновляется, эта страница может сканироваться чаще. Иногда маркетологи слышат об этом и устанавливают поверхностные или искусственные обновления для страниц, чтобы Google их пересматривал, но это не имеет значения. То, что страница сильно меняется, может сканироваться чаще, но вам не нужно пересматривать страницу, если она не изменилась. Более частое сканирование не приводит к улучшению рейтинга. (Обратите внимание, что для некоторых запросов, которые ищут свежесть (например, тематические новостные запросы), новые страницы могут опережать старые страницы в некоторых случаях, но это другая проблема. Большинство запросов не попадают в эту категорию.)
• Прошло ли много времени с момента сканирования URL? Если страница не была просканирована в течение некоторого времени (Google не считает ее очень важной, поэтому она находится в конце списка приоритетов, и робот Googlebot исчерпал выделение из-за ограничения скорости сканирования во время каждого сканирования) в конечном итоге он поднимется до верха очереди, поэтому индекс Google не станет слишком устаревшим.

Единственный способ узнать, какие URL-адреса сканирует робот Googlebot и как часто просматриваются URL-адреса, - это просмотреть журналы сервера (что опять же можно анализировать с помощью множества сторонних инструментов, включая отчеты Crawl Analytics в Keylime Toolbox).

Работа с лимитом скорости сканирования вашего сайта и требованием сканирования: как обеспечить быстрый просмотр нужных страниц

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

Делаем URL доступными для обнаружения

Первый шаг - убедиться, что страницы, которые вам нужны, «открыты»:

• Убедитесь, что никакие страницы на сайте не являются «осиротевшими»: чтобы посетитель мог просматривать все страницы сайта через внутреннюю структуру ссылок (например, никакие страницы не должны быть доступны только через окно поиска).
• Убедитесь, что все URL включены в XML Sitemap ,

Управление тем, что сканирует робот Googlebot

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

Фасетная навигация

В сообщении Google в блоге перечислено «многогранная навигация» как тип «URL-адреса с низкой добавленной стоимостью», который может «негативно повлиять на сканирование и индексацию сайта» и «может привести к значительной задержке в обнаружении отличного контента». Это немного расплывчато и тревожно, поскольку многие высококачественные сайты используют многогранную навигацию, и удалить ее не практично (или не удобно для пользователя).

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

В итоге:

• Определите, какие грани вы хотите индексировать отдельно (возможно, вы хотите, чтобы фасеты «синие платья» и «красные платья» были проиндексированы отдельно, но не индексируемые отдельно «платья синего цвета 10» и «платья красного размера 10»).
• использование канонические атрибуты чтобы указать фасеты, которые вы не хотите индексировать, на ваши вариации (например, каноническим значением для всех вариаций размера «синих платьев» будет URL-адрес страницы синих платьев). Вы также можете настроить сайт, чтобы включить все размеры на одной странице, как Google В шаге 6 своего поста Мэйл Ойе рассказывает о SEO для сайтов электронной коммерции ,
• Если фасеты используют стандартные параметры пары ключ / значение в URL, установите их в Инструмент обработки параметров консоли поиска Google ,
• Не указывайте параметры фасетов, если результат дает 0 результатов (пустая страница).

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

Бесконечные URL

Бесконечные URL может случиться разными способами.

Бесконечные Следующие Ссылки

Это может произойти, например, с календарями или нумерацией страниц. Если возможно, динамически прекратите указывать следующую ссылку, если дополнительного содержимого не существует. Например, убедитесь, что пагинационные ссылки не обеспечивают «следующий» навсегда.

Бесконечные результаты поиска

Google рекомендует блокировать результаты поиска через robots.txt. Это гарантирует, что результаты поиска (которые обычно всегда могут быть бесконечными, потому что посетитель может искать что угодно) не используют весь бюджет сканирования, а также исключает результаты поиска из результатов поиска Google ,

Если вы используете результаты поиска для страниц категорий, используйте другую структуру URL для заданных страниц категорий по сравнению с результатами поиска в произвольной форме (если это возможно) или ограничьте поиск только теми ключевыми словами, которые соответствуют существующей таксономии.

Еще раз, вы можете просмотреть журналы доступа к серверу, чтобы увидеть, тратит ли Google много времени на страницы результатов поиска. Ниже приведен пример отчета об аналитике сканирования Keylime Toolbox, показывающий, что робот Googlebot сканирует чаще всего для сайта:

Для приведенного ниже примера сайта 4,7% сканирования (28 079 из 605 244 выборок) - это / search URLs.

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

Soft 404s

Если страница, которая не найдена, возвращает 404, Google будет сканировать ее гораздо реже (снизит приоритет в очереди) и не будет индексировать ее. Но если эта страница «не найдена» возвращает 200 Google продолжит сканировать его. Это может привести к бесконечным URL-адресам, поскольку любая несуществующая страница возвращает 200.

Наиболее очевидный случай - неправильная настройка сервера для возврата кода состояния 200 для страниц, которые не найдены. Ниже приведен пример:

Но другие сценарии могут быть труднее обнаружить. Например, сервер может быть настроен для обработки недействительных URL-адресов как запросов, поэтому example.com/puppies будет выполнять поиск «щенков» и возвращать страницу результатов поиска (которая может не содержать релевантных результатов). Это может показаться удобным для пользователя, но обычно это не так. В этих случаях лучше либо просто вернуть удобную пользовательскую страницу с ошибкой (с ответом 404), либо перенаправить на реальную страницу результатов поиска (которая заблокирована robots.txt, чтобы избежать бесконечных проблем при сканировании).

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

Бесконечные вариации URL

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

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

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

Что делать дальше?

Более эффективное сканирование может привести не только к более полной индексации, но и к обновлению страниц в индексе Google. И если вы вносите улучшения в свой сайт (технические улучшения, исправления проблем со штрафами и т. Д.), Чем эффективнее сканирование, тем быстрее Google подберет эти изменения.

• Оцените текущее состояние:
  • Представить канонический, всеобъемлющий XML Sitemap в консоль поиска Google. Google сообщит, сколько из этих URL проиндексировано. Если большинство из них, вам, вероятно, не нужно беспокоиться об этом все это время.
  • Проверьте результаты поиска для недавно обновленных страниц, а затем проверьте кеш этих страниц , Сканировал ли их Google с тех пор, как вы сделали обновления? Если даты кэширования старые, то более эффективное сканирование может помочь быстрее обновлять страницы в индексе Google.
  • Обзор Журналы доступа к серверу, чтобы увидеть, что сканируется , Это страницы, которые наиболее важны для индексации? (Напишите нам по адресу [email protected] если вы хотите настроить анализ журнала за 49 долларов в месяц).
• Убедитесь, что каждая страница на вашем сайте доступна по крайней мере по одной внутренней ссылке
• Проверьте Отчет об ошибках сканирования Google Search Console для ошибок сайта и ошибок сервера:
  • Исправьте все ошибки сайта и неправильную настройку сервера.
  • Улучшить время отклика сервера если возможно
  • Просмотрите URL-адреса ошибок сервера, чтобы определить, не настроены ли определенные URL-адреса, чтобы вернуть неправильный код состояния.
• Ищите бесконечные проблемы с URL (и разрешайте их), используя:
• Прочитайте больше:
• Задайте вопрос в комментариях ниже!

Похожие

Комментарии