В перерывах бегло читаю всяко-разные сеошные каналы, чтоб быть, так скажем, на острие прогресса. Некоторые находят исследования и делятся ими. Один из авторов — канал Людкевича (хотел бы сказать, что реклама, ха). И вот у него узнал про несколько исследований, пытающихся понять, как ИИ сканируют наши сайты. Ссылка1, ссылка2, ссылка3.
Прочитав подробнее, пришёл к выводу: порядок и объём кода стали важнее, чем были раньше.
В чём соль. ИИ-бот не обязан выкачивать вашу страницу целиком.
Во-первых, живой агент читает её кусками: в первое чтение попадает всего ~5–6к знаков линеаризованного (в одну строку без форматирования) текста, а глубже он лезет, только если решил, что страница того стоит. Если в это первое окно попал один код и менюхи, а не смысл — агент может плюнуть и уйти.
Во-вторых, тяжёлую страницу бот может не докачать вообще. Он тянет первые N байт тела, а не всё подряд. И если полезный текст в исходнике стоит после кучи мусора — он в скачанное просто не войдёт.
Отсюда простое правило для техаудита: смотрим не только на вес, но и на то, что стоит в коде раньше текста. Я условно разделил вредные блоки на два типа.
Тип первый: раздувают вес и толкают текст вниз. Тут вред в том, что бот тупо не догрузит важный контент или отвалится по таймауту.
1.
Картинки в data:image, а не ссылкой. Одна такая картинка может весить 200–500 кб, и весь исходник картинки сидит прямо в теле страницы. Если его положили в начале, то код картинки сжирает бюджет закачки, и текст ниже в скачанное не попадает.2.
Огромные инлайновые SVG прямо в теле. Сложная иконка или иллюстрация в виде инлайн-svg — простыня координат в path, сотни строк кода. Здесь аналогично картинкам: раздутие веса и толкание смыслового текста вниз, ближе к границе того, что бот успеет скачать. Тяжёлую графику надо хранить файлами, а не вшивать в разметку.3.
CSS, распиханный по телу. Когда стили не вынесены в .css, а живут <style>-блоками и простынями прямо в body — классика вёрстки на отъебись.Тип второй: не только весят, но и сами лезут в окно чтения ссылками. Ссылки в линеаризованном тексте не выкидываются, каждая приходит маркером и тратит символы из того самого окна ~5–6к.
4.
Мега-меню интернет-магазина, сквозняком на всех страницах. Полное меню каталога со всеми категориями и подкатегориями, зашитое в каждую страницу — это сотни ссылок в исходнике, причём обычно в самом верху, до контента. По весу такое раздувает код. По окну — сотни ссылок-маркеров съедают первое чтение, и до текста товара/статьи агент доходит уже с полупустым бюджетом (а то и не доходит). Это лечится загрузкой мега-меню по клику через ajax. В исходнике при отдаче — только сам пункт, раскрытие должно подтягиваться событием. Бот видит лёгкий верх, ваш контент — сразу.5.
Модные хлебные крошки с полным перечнем соседних разделов. Частая история на Битриксе — крошки, где при наведении на пункт выпадает список всех соседних категорий раздела. То есть в исходнике зашита не «родитель → текущая», а вообще все категории ветки. То же самое, что мега-меню, только исподтишка — визуально это скромная строчка крошек, а в коде десятки лишних ссылок, и снова в начале страницы, перед контентом. Съедает окно и вес. Лечение аналогичное: в исходнике — нормальная цепочка «родитель → текущая страница», а выпадающие соседние разделы подтягивать по наведению/клику через ajax, а не рендерить сразу.Я и раньше советовал избавляться от говнокода, но в эпоху GEO это стало критичнее. Вывод простой: чем ближе к началу исходного кода стоит текст, передающий смысл, тем выше шанс, что вы попадёте в ответ ИИ.
Для ИИ код — это и есть текст. Он не видит разницы между стихотворением Пушкина и координатами векторной графики. Вот и выходит, что раньше следили за объёмом статьи — теперь ещё и за тем, чтобы код не выталкивал этот текст за границу того, что бот вообще прочитает.