Краулинг в декабре: CDN и краулинг

Вторник, 24 декабря 2024 г.

Сети доставки контента (CDN) особенно хорошо подходят для снижения задержки вашего веб-сайта и в целом избавления от головной боли, связанной с веб-трафиком. В конце концов, в этом их основная цель: быстрая доставка вашего контента, даже если ваш сайт получает много трафика. “D”
в CDN предназначен для доставки или распространения контента по всему миру, поэтому время передачи вашим пользователям также ниже, чем просто хостинг в каком-то центре обработки данных. В этом посте мы собираемся изучить, как использовать CDN таким образом, чтобы улучшить краулинг и пользовательский опыт на вашем сайте, а также рассмотрим некоторые нюансы краулинга сайтов на базе CDN.

Резюме: Что такое CDN?

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

CDN могут значительно ускорить работу вашего сайта , обслуживая пользователей из близкого к ним места. Скажем, если пользователь из Австралии получает доступ к сайту, размещенному в Германии, CDN будет обслуживать этого пользователя из своих кэшей в Австралии, сокращая время кругового пути по всему миру. Со скоростью света или нет,
расстояние все еще довольно велико.

И наконец,
CDN — это фантастический инструмент для защиты вашего сайта от перегрузки и некоторых угроз безопасности. Учитывая объем глобального трафика, которым управляют CDN, они могут создавать надежные модели трафика для обнаружения аномалий трафика и блокирования доступов, которые кажутся чрезмерными или вредоносными. Например, 21 октября 2024 г.,
Системы Cloudflare
автономно обнаружил и смягчил 4.2
Tbps
(ред.: это много) DDoS-атака, которая длилась около минуты.

Как CDN могут помочь вашему сайту

У вас могут быть самые быстрые серверы и лучший канал связи, который можно купить за деньги, и вы можете думать, что вам ничего не нужно ускорять, но CDN могут сэкономить вам деньги в долгосрочной перспективе, особенно если ваш сайт большой:

• Кэширование на CDN: если такие ресурсы, как мультимедиа, JavaScript и CSS, или даже ваш HTML обслуживаются из кэшей CDN, вашим серверам не нужно тратить вычислительные мощности и пропускную способность на обслуживание этих ресурсов, что снижает нагрузку на сервер в процессе. Обычно это также означает, что страницы загружаются быстрее в браузерах пользователей, что
  коррелирует с лучшими конверсиями.
• Защита от наводнений трафика: CDN особенно хороши в выявлении и блокировании чрезмерного или вредоносного трафика, позволяя вашим пользователям посещать ваш сайт даже тогда, когда плохо себя ведут боты или злоумышленники, перегружающие ваши серверы.
  Помимо защиты от наводнений, те же элементы управления, которые используются для блокировки плохого трафика, также могут использоваться для блокировки трафика, который вам просто не нужен, будь то определенные краулеры, клиенты, которые соответствуют определенному шаблону, или просто тролли, которые продолжают использовать один и тот же IP-адрес. Хотя вы можете сделать это на своем сервере или брандмауэре, обычно намного проще использовать пользовательский интерфейс CDN.
• Надежность: некоторые CDN могут предоставлять ваш сайт пользователям, даже если ваш сайт не работает. Это, конечно, может работать только для статического контента, но этого уже может быть достаточно, чтобы гарантировать, что они не перенесут свой бизнес в другое место.

Короче говоря, CDN — ваши друзья, и если ваш сайт большой или вы ожидаете (или даже уже получаете!) большие объемы трафика, вы можете найти тот, который соответствует вашим потребностям на основе таких факторов, как цена, производительность, надежность, безопасность, поддержка клиентов, масштабируемость, будущее расширение. Узнайте у своего хостинг-провайдера или поставщика CMS, каковы ваши варианты (и используете ли вы его уже).

Как краулинг влияет на сайты с CDN

Что касается краулинга, CDN также могут быть полезны, но они могут вызывать некоторые проблемы с краулингом (хотя и редко). Оставайтесь с нами.

Влияние CDN на скорость краулинга

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

Допустим, вы сегодня запускаете сайт стоковых фотографий и у вас случайно оказывается 1 000 007 картинок… на складе. Вы запускаете свой веб-сайт с целевой страницей, страницами категорий и страницами с подробной информацией для всех ваших материалов — в итоге у вас получается много страниц. Мы объясняем в нашей документации по
предел емкости краулинга
что, хотя Google Поиск хотел бы сканировать все эти страницы как можно быстрее, краулинг также не должен перегружать ваши серверы. Если ваш сервер начинает отвечать медленно при столкновении с увеличенным количеством запросов краулинга, на стороне Google применяется регулирование, чтобы предотвратить перегрузку вашего сервера. Порог для этого регулирования намного выше, когда наша инфраструктура краулинга обнаруживает, что ваш сайт поддерживается CDN, и предполагает, что отправлять больше одновременных запросов нормально, потому что ваш сервер, скорее всего, сможет с этим справиться, тем самым ускоряя краулинг вашего интернет-магазина.

Однако при первом доступе к URL кэш CDN является «холодным», что означает, что поскольку никто еще не запрашивал этот URL, его содержимое еще не было закешировано CDN, поэтому вашему исходному серверу все равно придется обслуживать этот URL хотя бы один раз, чтобы «разогреть» кэш CDN. Это очень похоже на
как работает кэширование HTTP, тоже.

Короче говоря, даже если ваш интернет-магазин работает на базе CDN, вашему серверу придется обслужить эти 1 000 007 URL-адресов хотя бы один раз. Только после этого первого обслуживания ваш CDN сможет помочь вам со своими кэшами. Это значительная нагрузка на ваш «краулинговый бюджет», и скорость сканирования, скорее всего, будет высокой в течение нескольких дней; имейте это в виду, если вы планируете запустить много URL-адресов одновременно.

Влияние CDN на рендеринг

Как мы объясняли в нашем первом
декабрьском посте блога о сканировании ресурсов, выделение ресурсов на их собственное доменное имя или доменное имя CDN (cdn.example.com) может позволить нашей службе веб-рендеринга (WRS) рендерить ваши страницы более эффективно. Однако здесь есть оговорка: эта практика может негативно повлиять на производительность страницы из-за накладных расходов на соединение с другим доменным именем, поэтому вам нужно тщательно взвесить
пользовательский опыт в сравнении с производительностью рендеринга.

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

В конце концов, выберите решение, которое лучше всего подходит для вашего бизнеса: используйте отдельное доменное имя (cdn.example.com) для статических ресурсов, защитите свой основной хост с помощью CDN или сделайте и то, и другое. Инфраструктура сканирования Google без проблем поддерживает любой из вариантов.

Когда CDN слишком бдительны

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

Жесткие блокировки

Жесткие блокировки — это когда CDN отправляет в ответ на запрос сканирования ошибку той или иной формы. Это могут быть:

• HTTP 503/429 коды состояния: отправка
  этих кодов состояния является предпочтительным способом
  сигнализировать о временной блокировке. Это даст вам некоторое время на то, чтобы отреагировать на непреднамеренные блокировки со стороны CDN.
• Тайм-ауты сети: сетевые тайм-ауты со стороны CDN приведут к удалению затронутых URL-адресов из индекса поиска Google, поскольку эти
  сетевые ошибки считаются фатальными, «жесткими» ошибками. Кроме того, они также могут существенно повлиять на скорость сканирования вашего сайта, так как сигнализируют нашей инфраструктуре сканирования о том, что сайт перегружен.
• Случайное сообщение об ошибке с кодом состояния 200 HTTP: также известное как
  мягкие ошибки, это особенно плохо. Если Google приравняет сообщение об ошибке к «жесткой» ошибке (скажем, HTTP 500), Google удалит URL-адрес из поиска. Если Google не сможет распознать сообщения об ошибках как «жесткие» ошибки, все страницы с одинаковым сообщением об ошибке могут быть удалены из индекса поиска Google как дубликаты. Поскольку у индексации Google мало стимулов запрашивать повторное сканирование дубликатов URL-адресов, восстановление после этого может занять больше времени.

Мягкие блокировки

Похожая проблема может возникнуть (каламбур вполне намеренный), когда ваш CDN показывает эти межстраничные объявления «вы точно человек?»

Наши краулеры на самом деле убеждены, что они НЕ люди, и они не притворяются ими. Они просто хотят сканировать. Однако, когда появляется межстраничное объявление, это все, что они видят, а не ваш потрясающий сайт. В случае таких межстраничных объявлений с проверкой ботов мы настоятельно рекомендуем отправлять автоматизированным клиентам, таким как краулеры, четкий сигнал в виде кода состояния HTTP 503 о том, что контент временно недоступен. Это гарантирует, что контент не будет автоматически удален из индекса Google.

Устранение неполадок с блокировками

В случае как жестких, так и мягких блокировок самый простой способ проверить, все ли работает правильно,
использовать инструмент проверки URL в Search Console
и посмотреть на отрендеренное изображение: если оно показывает вашу страницу — все в порядке; если оно показывает пустую страницу, ошибку или страницу с капчей для ботов, возможно, вам стоит обсудить это с вашим CDN.

Кроме того, чтобы помочь с этими непреднамеренными блокировками, Google, другие поисковые системы и другие операторы краулеров публикуют
наши IP-адреса чтобы помочь вам идентифицировать наши краулеры и, если вы считаете это уместным, удалить заблокированные IP-адреса из правил WAF или даже добавить их в белый список. Где именно это можно сделать, зависит от используемого вами CDN; к счастью, у большинства CDN и автономных WAF есть отличная документация. Вот некоторые из них, которые нам удалось найти с помощью небольшого поиска (на момент публикации этого поста):

• Cloudflare: https://developers.cloudflare.com/bots/get-started/free/#visibility
• Akamai: https://www.akamai.com/products/bot-manager
• Fastly: https://www.fastly.com/products/bot-management
• F5: https://clouddocs.f5.com/bigip-next/20-2-0/waf_management/waf_bot_protection.html
• Google Cloud: https://cloud.google.com/armor/docs/bot-management

Если вам нужно, чтобы ваш сайт отображался в поисковых системах, мы настоятельно рекомендуем проверить, могут ли важные для вас краулеры получить доступ к вашему сайту. Помните, что IP-адреса могут автоматически попасть в черный список без вашего ведома, поэтому время от времени проверять черные списки — отличная идея для успеха вашего сайта в поиске и за его пределами. Если черный список очень длинный (впрочем, как и этот пост в блоге), попробуйте поискать только первые несколько сегментов диапазонов IP, например, вместо того чтобы искать 192.168.0.101 вы можете просто поискать 192.168.

Это был последний пост в нашей
серии публикаций в блоге Crawling December, надеемся, они понравились вам так же сильно, как нам их писать. Если у вас… бла-бла-бла… вы сами знаете.

Опубликовано
Martin Splitt и
Gary Illyes

Хотите узнать больше о сканировании? Ознакомьтесь со всей серией Crawling December: