Технический аудит сайта: как устроен обход и индексирование

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

Что робот делает с сайтом: обход, рендеринг, индексирование

Googlebot проходит три отдельные стадии. Обход: скачивание URL и разбор исходного HTML на ссылки. Рендеринг: выполнение JavaScript в headless-Chromium. Индексирование: разбор уже отрендеренного HTML. Стадии разнесены во времени, поэтому страница может быть обойдена, но не отрендерена неделями.

Ограничения зафиксированы в документации. Googlebot скачивает первые 2 МБ поддерживаемого типа файла и первые 64 МБ PDF, остальное отбрасывается; каждый ресурс, на который ссылается HTML, запрашивается отдельно и подпадает под тот же лимит. В очередь рендеринга попадают все страницы с кодом 200, и Google пишет, что страница может пролежать в ней несколько секунд, а может и дольше. Вывод: всё, чего нет в первых 2 МБ исходного ответа, попадает в индекс только после второй стадии, сроки которой не гарантированы.

Краулинговый бюджет: как он назначается и куда утекает

Google описывает бюджет как пересечение предела ёмкости обхода (сколько соединений сервер выдерживает без деградации) и спроса на обход. Ёмкость подстраивается автоматически: сервер отвечает быстро и стабильно, лимит растёт; появляются 5xx и таймауты, лимит падает. Круг сайтов, которым это вообще важно, очерчен прямо: свыше 1 000 000 уникальных страниц с умеренно меняющимся содержимым и свыше 10 000 уникальных страниц с очень быстро меняющимся. Лендинг на 40 страниц в этот круг не входит.

Утекает бюджет на дубли, soft 404, длинные цепочки редиректов и медленную отдачу. Там же два приёма, о которых забывают: закрывать неважные разделы через robots.txt, а не через noindex (noindex робот увидит, только потратив на страницу запрос), и поддерживать HTTP-кеширование, отдавая 304 Not Modified для неизменившихся страниц.

У Яндекса есть встречный рычаг. Настройка «Скорость обхода» задаёт количество запросов в секунду, которое робот отправляет на сайт; по умолчанию включена опция «Доверять Яндексу». Задаётся она отдельно для основного домена и для каждого поддомена, поэтому ограничение на главном хосте ничего не говорит о нагрузке от обхода поддоменов.

Логи сервера: что видно только там

Панель вебмастера показывает агрегат, лог показывает событие. Отчёт «Статистика сканирования» в Google Search Console оперирует окном в 90 дней и группирует запросы по коду ответа, типу файла, цели (обнаружение нового адреса или обновление известного) и типу робота, но конкретные URL там не назвать: примеры показательные, а не полные. В access-логе nginx или Apache считается то, чего нет ни в одной панели:

• доля запросов робота, ушедших на адреса с параметрами, пагинацию и служебные разделы, против доли на канонические страницы;
• случаи, когда роботу отдаётся 5xx или 429, а браузеру с того же URL отдаётся 200. Так проявляют себя WAF, rate-limit и антибот-правила хостинга;
• время ответа именно на запросы робота, а не усреднённое по всем посетителям;
• частота обращений к давно удалённым страницам и к цепочкам редиректов.

Перед подсчётом лог фильтруется от подделок под робота. Google описывает двухшаговую проверку: обратный DNS-запрос по IP должен дать имя в зоне googlebot.com, google.com или googleusercontent.com, после чего прямой DNS-запрос по этому имени обязан вернуть исходный IP. Для автоматической сверки Google публикует диапазоны в CIDR отдельными JSON-файлами (common-crawlers.json, special-crawlers.json). Яндекс проверяется тем же обратным DNS: имя должно оказаться в зонах yandex.ru, yandex.net или yandex.com.

SEO-оптимизация сайтов под поисковые системы: что делает каждая директива и чего не делает

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

Отсюда ловушка: если страница закрыта в robots.txt, робот не скачает её HTML и не увидит noindex внутри. Google пишет, что правила индексирования в этом случае просто не будут найдены. Яндекс формулирует то же: «Если страница запрещена в файле robots.txt, то директива метатега или заголовка не действует». Чтобы убрать страницу из индекса, её сначала надо открыть для обхода.

Google разбирает четыре поля robots.txt: user-agent, disallow, allow, sitemap, и отдельно оговаривает, что прочие, включая crawl-delay, не поддерживаются. Яндекс работает с User-agent, Disallow, Allow, Sitemap и Clean-param. Строки Crawl-delay сегодня не значат ничего ни там, ни там. Требования к самому файлу почти совпали: Google разбирает первые 500 кибибайт и кеширует содержимое обычно до 24 часов, Яндекс требует размер не более 500 КБ и ответ 200 OK, а при несоответствии считает сайт открытым для индексирования. На 5xx у Google отдельный сценарий: обход приостанавливается примерно на 12 часов, недоступный файл заменяется закешированной версией на срок до 30 дней.

Для не-HTML работает только X-Robots-Tag: прайс в PDF, выгрузка в XLS, схема в SVG закрываются заголовком, метатегу там негде разместиться. Тем же заголовком задаются ограничения сниппета: max-snippet со значением 0 отключает текстовый сниппет, -1 отдаёт длину на усмотрение Google, max-image-preview принимает none, standard или large.

Канонический адрес и Clean-param: рекомендация, а не команда

rel=»canonical» не приказывает. Google называет его сильным сигналом и ранжирует источники по убыванию веса: редиректы, затем rel=»canonical», затем присутствие адреса в sitemap; там же просьба не задавать разными способами разные канонические адреса одной страницы. Яндекс формулирует жёстче: «Робот Яндекса воспринимает указание на канонический адрес как рекомендацию и может проигнорировать его». Указание игнорируется, если:

• канонический адрес ведёт на другой домен или поддомен, кросс-доменный canonical не поддерживается;
• содержимое канонической страницы значительно отличается от неканонической;
• каноническая страница редиректит дальше или закрыта от индексирования;
• указано несколько канонических адресов или каноникалы выстроены в цепочку вида /1 на /2, /2 на /3.

Для параметров, не меняющих содержимое, у Яндекса есть инструмент, аналога которому в Google нет. Директива Clean-param перечисляет незначащие параметры (метки ysclid, yrclid, семейство utm_ и любые собственные), и робот перестаёт многократно перезагружать одно и то же под разными адресами. Ограничение на длину одного правила: 500 символов, поэтому длинный список разбивается на несколько строк.

Система SEO-оптимизации сайта на уровне сервера: 301, 302, 404, 410 и мягкие ошибки

Коды ответа задаются в конфигурации веб-сервера, а не в шаблоне. Что Google делает с ними:

• 301 обрабатывается как сильный сигнал в пользу того, что канонической надо считать целевую страницу; 308 ему эквивалентен.
• 302 обрабатывается как слабый сигнал, целевая страница не наследует канонический статус автоматически; 307 эквивалентен 302.
• По умолчанию роботы Google проходят до 10 переходов в цепочке редиректов. Всё, что дальше, не будет обойдено.
• 404 и 410 обрабатываются одинаково: как все 4xx, кроме 429, они сообщают дальнейшим системам, что содержимого не существует. Расхожее утверждение, что 410 удаляет быстрее, документацией не подтверждается.
• 429 трактуется как признак перегруженного сервера и относится к серверным ошибкам, а не к клиентским.
• 5xx и 429 заставляют роботов замедлить обход пропорционально количеству URL с ошибкой; адреса, устойчиво отдающие серверную ошибку, из индекса удаляются.

Последний пункт задаёт границу для аварийного приёма. Google допускает отдавать 500, 503 или 429, чтобы срочно сбить нагрузку от обхода на пару часов или на 1-2 дня, и предупреждает: если робот видит эти коды на одном URL несколько дней подряд, адрес может быть выброшен из индекса.

Отдельная категория поломок, не видная по кодам, это мягкие ошибки: Search Console помечает страницу как soft 404, если содержимое выглядит как сообщение об ошибке или пустая страница, а сервер отдаёт 200. Классический источник: массовый редирект удалённых страниц на главную. Корректно для исчезнувшего адреса отдавать 404 или 410, если замены нет, и 301 на близкую по смыслу страницу, если замена есть. У Яндекса причина исключения «Ошибка HTTP» описана как ошибка при загрузке или обработке страницы, если ответ содержал статус 3XX, 4XX или 5XX, то есть редирект для него тоже основание убрать исходный адрес из поиска.

Продвижение сайта и настройка рендеринга: почему SPA индексируется иначе

Одностраничное приложение отдаёт роботу почти пустой HTML с точкой монтирования и бандлом. Содержимое появляется после выполнения JavaScript, то есть на второй стадии, асинхронно и в очереди: пока рендеринг не случился, для индекса страница пуста, а ссылки, которые рисует роутер, не существуют как ссылки. Ошибки, которые ломают индексирование SPA сильнее всего:

• маршрутизация через фрагмент URL. Google прямо просит не использовать фрагменты для подгрузки разного содержимого, потому что адреса в такой схеме не резолвятся надёжно;
• подстановка содержимого только после действия пользователя (клик, скролл), которого робот не совершает;
• зависимость первого экрана от cookie или localStorage, которые между запросами не сохраняются;
• ответ 200 на несуществующий маршрут, потому что роутер отдаёт оболочку на любой путь. Тот же soft 404, сгенерированный фронтендом.

Лечится серверным рендерингом (SSR) или предрендером критичных маршрутов. Google отмечает, что серверный или предварительный рендеринг остаётся хорошей идеей: он ускоряет сайт и для пользователей, и для роботов, и не все роботы вообще выполняют JavaScript. За пределами Google это критично: краулеры агрегаторов, соцсетей и части ответных систем берут исходный HTML как есть. Проверяется не глазами: инструмент проверки URL в Search Console и Rich Results Test показывают отрендеренный HTML, и в нём должны быть текст, ссылки и метатеги, которые вы рассчитываете видеть в индексе.

Серверный слой скорости: TTFB, сжатие, кеш и приоритет LCP-ресурса

Core Web Vitals состоят из трёх метрик с порогами «хорошо»: LCP не более 2,5 секунды, INP не более 200 миллисекунд, CLS не более 0,1. Оценка берётся по 75-му процентилю загрузок и считается раздельно для мобильных и десктопа, поэтому средняя по сайту цифра не говорит ничего. Внутри LCP рекомендуемое распределение времени такое: около 40 процентов на TTFB, менее 10 процентов на задержку до начала загрузки LCP-ресурса, около 40 процентов на его загрузку, менее 10 процентов на отрисовку элемента. Отдельный ориентир по TTFB: 0,8 секунды и меньше по тому же процентилю. Что настраивается вне фронтенда:

• Сжатие ответа. Brotli или gzip на HTML, CSS, JS и SVG. Кратное сокращение объёма без единой правки в коде.
• Кеш на уровне заголовков. Корректные ETag и Last-Modified позволяют отдавать 304 Not Modified, чего Google в рекомендациях по краулинговому бюджету прямо просит.
• CDN. Уменьшает сетевую составляющую TTFB для географически разбросанной аудитории. Для одного города с дата-центром рядом эффект околонулевой.
• Приоритет LCP-ресурса. Атрибут fetchpriority=»high» ставится на элемент img, который вероятнее всего окажется LCP, и не более чем на одну-две картинки; слайды карусели, наоборот, помечаются fetchpriority=»low».
• Отложенная загрузка мимо главного изображения. Формулировка в документации категорична: никогда не откладывайте загрузку LCP-изображения. Автоматический loading=»lazy» на всех картинках шаблона регулярно попадает именно на LCP-элемент.

Mobile-first: паритет версий как техническое требование

31 октября 2023 года Google объявил перевод индекса на мобильного робота завершённым: сайты обходятся преимущественно Googlebot Smartphone, обход устаревшим десктопным роботом сокращается и остаётся только для небольшого списка сайтов, которые на мобильных не работают вовсе. Отдельной десктопной версии в индексе больше нет, отсюда требование к шаблону: содержимое мобильной версии должно совпадать с десктопной. Google предупреждает прямо: если десктопная страница отдаёт содержимое, а мобильная версия того же адреса отдаёт ошибку, страница пропадёт из индекса. Речь не о вёрстке, а о том, что попадает в HTML. Типичные расхождения:

• блок с текстом, отзывами или характеристиками, который на мобильном не выводится в разметку вовсе, а не просто скрыт стилями;
• урезанные title, description и заголовки в мобильном шаблоне;
• структурированные данные, которые генерируются только в десктопной ветке шаблона;
• отдельный поддомен m., у которого robots.txt, canonical и sitemap живут своей жизнью.

Проверка сводится к сравнению исходного HTML, полученного мобильным и десктопным user-agent, а не к взгляду на страницу в узком окне браузера.

Сигналы об обновлении: sitemap, lastmod и IndexNow

Карта сайта не заставляет индексировать, она сообщает адреса. Ограничения формата жёсткие: один файл вмещает не более 50 000 URL и не более 50 МБ в несжатом виде, при превышении любого порога карта делится на несколько файлов с индексным сверху. С lastmod тоньше: Google использует значение, только если оно последовательно и проверяемо точное. Значимым изменением считается правка основного содержимого, структурированных данных или ссылок; обновление года в копирайте значимым не является. CMS, которая при каждой пересборке проставляет всем страницам сегодняшнюю дату, обесценивает сигнал целиком.

Быстрее карты работает IndexNow, который поддерживают Яндекс и ряд других систем, но не Google. На сайте размещается ключ длиной от 8 до 128 символов из набора a-z, A-Z, 0-9 и дефиса, после чего адреса отправляются запросом, до 10 000 URL за один POST. Два ограничения, о которые спотыкаются: ключевой файл в подкаталоге разрешает отправлять только адреса внутри этого подкаталога, а ответ 429 означает слишком частые обращения. Яндекс отдельно оговаривает, что сообщать надо только о новых, изменившихся или удалённых страницах и что передача адреса не гарантирует индексирования.

Частые вопросы

Почему страница, закрытая в robots.txt, всё равно есть в выдаче Google?

Потому что robots.txt запрещает обход, а не индексирование: содержимое таких страниц Google проиндексировать не может, но сам URL может показать без сниппета. Чтобы убрать адрес, надо открыть его для обхода и отдать noindex метатегом или заголовком X-Robots-Tag.

410 удаляет страницу из индекса быстрее, чем 404?

Документация Google этого не подтверждает: все коды 4xx, кроме 429, обрабатываются одинаково. Выбирать 410 имеет смысл ради ясности намерения, а не ради скорости.

Сколько редиректов в цепочке допустимо?

По умолчанию роботы Google проходят до 10 переходов. Практический ориентир жёстче: один переход, каждый лишний прыжок это дополнительный запрос за счёт краулингового бюджета.

Нужен ли SSR, если Google умеет выполнять JavaScript?

Умеет, но во вторую очередь: в очередь рендеринга попадают все страницы с кодом 200, и время ожидания в ней не гарантировано. Google сам называет серверный или предварительный рендеринг хорошей идеей, в том числе потому, что не все роботы выполняют JavaScript.

Какие пороги Core Web Vitals считать целевыми?

LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1, по 75-му процентилю загрузок и отдельно для мобильных и десктопа. Для серверной части ориентир по TTFB: 0,8 секунды и меньше на том же процентиле.