Рассуждают часто так: раз страница опубликована, поисковик её найдёт и покажет. Но между публикацией и показом лежит конвейер из нескольких стадий, и ранжирование - выбор места в выдаче - начинается лишь в самом конце, когда страница уже обнаружена, загружена и понята. Застряла на ранней стадии - и никакие ключевые слова и ссылки не помогут: ранжировать нечего.
Путь к выдаче складывается из обнаружения URL, загрузки содержимого, при необходимости - рендеринга JavaScript, извлечения контента, выбора канонической версии и, наконец, индексирования. Любая стадия способна отсеять страницу, и до ранжирования она тогда просто не дойдёт. Конвейер стоит держать перед глазами целиком: большинство проблем поиска - это не ранжирование, а обрыв на ранней ступени.
| Стадия | Что происходит | Частый обрыв |
|---|---|---|
| Обнаружение | URL найден по ссылкам и sitemap | на страницу ниоткуда нет ссылок |
| Сканирование | робот скачивает HTML | путь закрыт в robots.txt |
| Рендеринг | выполняется JavaScript | контент так и не появляется |
| Каноникализация | выбор основной версии из дублей | выбран чужой canonical |
| Индексирование | страница попадает в индекс | стоит noindex |
Обнаружение опирается на ссылки и карты сайта: поисковик узнаёт об URL по ссылке с известной страницы или из sitemap. Страница без единой входящей ссылки для краулера почти не существует. Дальше сканирование - робот делает HTTP-запрос и скачивает HTML. Но сначала Googlebot читает robots.txt: если путь запрещён, запрос не отправляется и содержимого робот не видит.
Современный сайт часто отдаёт пустой каркас, а контент дорисовывает JavaScript в браузере. Googlebot это умеет - у него сервис рендеринга на движке актуального Chromium, - но рендеринг откладывается и стоит ресурсов, так что происходит не сразу. Возьмём карточку товара в мультиязычном магазине: если цена, описание и заголовок приходят только после запроса к API из клиентского кода, поисковик увидит их лишь дождавшись рендера. Пока критичный контент и ссылки не выживают в отрендеренном HTML, для поиска их нет - надёжнее отдавать их сервером.
После извлечения контента поисковик решает, какая версия каноническая. Один товар часто доступен по нескольким адресам - с параметрами сортировки, с меткой кампании, в разном регистре, - и все они дубли одного содержимого. Система выбирает один canonical и индексирует его, а rel=canonical в разметке - подсказка, а не приказ: при противоречивых сигналах поисковик вправе выбрать другой URL. Лишь пройдя эту ступень, страница попадает в индекс и становится кандидатом на показ.
Два механизма постоянно путают, а цена ошибки высока. robots.txt управляет сканированием - пускать ли робота к URL, - но убрать страницу из выдачи им нельзя. Запрещённый адрес всё равно попадёт в индекс, если на него ссылаются извне: поисковик покажет голый URL без описания. Чтобы страница гарантированно не индексировалась, нужен meta robots с noindex или заголовок X-Robots-Tag - и вот парадокс: страница при этом обязана оставаться открытой для сканирования. Закрыв её в robots.txt, робот не дойдёт до noindex и о запрете не узнает.
Классический провал: служебный раздел прячут, закрыв в robots.txt и одновременно поставив noindex, - и получают обратное. Робот, наткнувшись на запрет, страницу не скачивает, noindex не видит, а по внешним ссылкам всё равно заносит голый URL в выдачу. Раздел, который прятали, оказывается на виду. Дисциплина сводится к порядку стадий: сначала убедиться, что страница обнаружима и её контент выживает в отрендеренном HTML; каноническую версию задать явно и непротиворечиво; robots.txt и noindex применять строго по назначению и никогда не заглушать вторым то, что уже перекрыл первый.
# robots.txt - управляет сканированием, не индексированием
User-agent: *
Disallow: /cart/
<!-- Чтобы страница не индексировалась, robots.txt НЕ должен её блокировать -->
<meta name="robots" content="noindex">
# Тот же смысл HTTP-заголовком:
X-Robots-Tag: noindex