Джон Мюллер предложил практическую проверку того, был ли отрывок проиндексирован и технически доступен для ранжирования.
Джона Мюллера из Google спросили, сколько мегабайт HTML-кода робот Googlebot сканирует на страницу. Вопрос заключался в том, индексирует ли робот Googlebot два мегабайта (МБ) или пятнадцать мегабайт данных. Ответ Мюллера свел к минимуму технический аспект вопроса и сразу затронул суть проблемы, а именно, сколько контента индексируется.
GoogleBot и другие боты
В разгар продолжающейся дискуссии в Bluesky кто-то возобновил вопрос о том, сканирует ли робот Google и индексирует 2 или 15 мегабайт данных.
<п>Они написали:стр>
“Надеюсь, вы получили то, что заставило вас запустить 🙂
<п>Было бы очень полезно иметь больше точности и примеры из реальной жизни, такие как “Моя страница имеет длину X МБ, она обрезается после X МБ, она также загружает ресурс A: 15 КБ, ресурс B: 3 МБ, ресурс B загружен не полностью, но ресурс A – это потому, что 15 КБ < 2 МБ”.”
Паника по поводу превышения лимита в 2 мегабайта
Мюллер сказал, что нет необходимости взвешивать байты, и намекнул, что в конечном итоге важно не ограничение количества байтов на странице, а то, индексируются ли важные отрывки.
<п>Кроме того, Мюллер сказал, что редко сайт превышает два мегабайта HTML, отвергая идею о том, что контент веб-сайта может не быть проиндексирован из-за его слишком большого размера.
Он также сказал, что Googlebot — не единственный бот, который сканирует веб-страницу, очевидно, чтобы объяснить, почему 2 мегабайта и 15 мегабайт не являются ограничивающими факторами. Google публикует список всех сканеров, которые они используют для различных целей.
Как проверить, проиндексированы ли фрагменты контента
Наконец, ответ Мюллера подтвердил простой способ проверить, индексируются ли важные отрывки.
Мюллер ответил:
“У Google много сканеров, поэтому мы разделили их. Крайне редко сайты сталкиваются с проблемами в этом отношении: 2 МБ HTML (для тех, кто ориентирован на робота Googlebot) — это совсем немного. Обычно я проверяю важную цитату внизу страницы – обычно нет необходимости взвешивать байты.”
Проходы для ранжирования
У людей короткая продолжительность концентрации внимания, за исключением случаев, когда они читают на тему, которая им интересна. Именно тогда обширная статья может пригодиться тем читателям, которые действительно хотят углубиться, чтобы узнать больше.стр> <п>С точки зрения SEO, я могу понять, почему некоторые могут подумать, что всеобъемлющая статья может быть не идеальной для ранжирования, если документ глубоко освещает несколько тем, любая из которых может быть отдельной статьей.
<п>Издателю или SEO-специалисту необходимо сделать шаг назад и оценить, удовлетворен ли пользователь глубоким освещением темы или пользователям требуется более глубокое ее рассмотрение. Существуют также разные уровни полноты: один с подробными деталями, а другой с обзорным уровнем освещения деталей со ссылками на более глубокое освещение.
Другими словами, иногда пользователям нужен вид на лес, а иногда им нужен вид на деревья.
Google уже давно умеет ранжировать отрывки документов с помощью своих алгоритмов ранжирования отрывков. В конечном итоге, по моему мнению, все сводится к тому, что будет полезно для пользователей и, скорее всего, приведет к более высокому уровню удовлетворенности пользователей.
<стр>Если всестороннее освещение темы волнует людей и вызывает у них достаточно энтузиазма, чтобы поделиться ими с другими людьми, то это победа.стр><стр>Если всестороннее освещение бесполезно для этой конкретной темы, возможно, лучше разделить контент на более короткие материалы, которые лучше соответствуют причинам, по которым люди приходят на эту страницу, чтобы прочитать об этой теме.стр> <ч2>Выносч2>
Хотя большая часть этих выводов не представлена в ответе Мюллера, они, на мой взгляд, представляют собой передовую практику для SEO.
<ул>
<ли>Поиск отличительных отрывков — практичный способ подтвердить индексацию
мл>
Обеспокоенность по поводу того, сколько мегабайт является жестким пределом сканирования для робота Googlebot, отражает неуверенность в том, индексируется ли важный контент в длинном документе и доступен ли он для ранжирования в поиске. Сосредоточение внимания на мегабайтах отвлекает внимание от реальных проблем, на которых должны сосредоточиться оптимизаторы, а именно: насколько глубина охвата темы лучше всего соответствует потребностям пользователя.
Ответ Мюллера подтверждает тот факт, что веб-страницы, слишком большие для индексации, встречаются редко, а фиксированные ограничения в байтах не являются ограничением, о котором оптимизаторам следует беспокоиться.
По моему мнению, оптимизаторы и издатели, вероятно, получат лучший охват поиска, если сместят свое внимание с оптимизации предполагаемых ограничений сканирования и вместо этого сосредоточатся на ограничениях потребления пользовательского контента.
Но если издатель или оптимизатор обеспокоен тем, проиндексирован ли отрывок в конце документа, есть простой способ проверить статус, просто выполнив поиск по точному совпадению для этого отрывка.
Всестороннее освещение темы не является автоматически проблемой ранжирования и не всегда является лучшим (или худшим) подходом. Размер HTML на самом деле не имеет значения, если только он не начинает влиять на скорость страницы. Важно то, является ли контент ясным, актуальным и полезным для целевой аудитории на том уровне детализации, который соответствует целям пользователя.
