3.1.1Индексация и управление обходом: какой рычаг за что отвечает

Компания по ремонту квартир год назад перевела сайт на защищённое соединение. В поиске Яндекса до сих пор стоит старый адрес, в Google — новый, а десяток страниц в обеих системах показывается с адресом тестового поддомена, о котором все забыли. Разработчик говорит, что перенаправления настроены, SEO-специалист — что карта сайта обновлена. Оба правы, и обоих не хватило.

Индексацией управляют несколько механизмов, и каждый из них можно сломать одной строкой. Ломают их не новички, а занятые люди, которые путают, какой механизм за что отвечает. Путь страницы — обход → обработка → индекс → ранжирование — разобран в главе 1. У первых трёх этапов есть рычаги, и у каждого своя зона: что он делает, чего не делает и как по шагам найти, почему конкретная страница не в индексе.

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

Что влияет на индексацию: полная карта

Причин, по которым страница может не попасть в поиск, конечное число. Их полезно держать одним списком, отсортированным не по алфавиту и не по этапам, а по тому, как часто они встречаются на живых сайтах и сколько стоят, если их пропустить. Порядок ниже — порядок, в котором я проверяю сайт, когда клиент говорит «нас нет в поиске».

Таблица причин исключения в главе 1 отвечает на вопрос, что значит статус; эта — с чего начинать проверку. Две вещи в ней важнее остальных. Первая: самые разрушительные причины — не самые частые. Запрет индексации по ошибке случается редко, но выключает сайт целиком, поэтому его проверяют первым и после каждого релиза. Вторая: две строки из восьми — «признана ненужной» и «санкция» — не лечатся техникой. Если диагностика упирается в них, техническая работа заканчивается, и это надо сказать владельцу прямо, а не продолжать править карту сайта. Что поисковая система решит о технически исправной странице, не контролирует ни разработка, ни SEO: на это влияют содержание и спрос, а остаток — неопределённость.

robots.txt: логика, а не синтаксис

Файл с правилами для роботов — самый известный и самый неправильно понятый инструмент SEO. Вокруг него больше всего уверенных ошибок, и почти все они происходят из одного: люди думают, что этот файл управляет тем, что есть в поиске. Он управляет тем, куда робот ходит.

Что файл делает и чего не делает

Запрет в robots.txt говорит роботу: не скачивай эти адреса. Почему это не убирает страницу из поиска, разобрано в главе 1; здесь важно, что обе системы говорят об этом прямо. В справке Яндекса: «Ограниченные в robots.txt страницы могут участвовать в поиске Яндекса». Google пишет, что такой адрес может оказаться в выдаче без описания.

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

Как принимать решение, что закрывать

Закрывать в robots.txt стоит то, что роботу не нужно скачивать никогда и что не нужно убирать из поиска, потому что оно туда и не попадало: служебные разделы, корзину, личный кабинет, результаты внутреннего поиска, бесконечные сочетания фильтров и сортировок, которые генерирует движок. Критерий простой: если страница не должна быть в поиске и робот тратит на неё обход — закрыть от обхода. Если страница уже в поиске и её надо оттуда убрать — сначала noindex или код «страницы нет», дождаться выпадения, и только потом, если нужно, закрыть от обхода.

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

Не закрывают от обхода файлы, без которых страница не собирается: стили, скрипты, изображения. Робот, которому запретили их скачивать, видит страницу сломанной — без вёрстки, без содержимого, которое подгружает скрипт, — и оценивает её такой. Раньше это делали ради «экономии обхода»; теперь это ошибка, которая стоит дороже любой экономии.

Где Яндекс и Google расходятся

Логика файла у систем общая, но набор правил — нет, и одно расхождение меняет решения. Яндекс поддерживает правило Clean-param, которое говорит роботу, какие параметры в адресе не меняют содержимого страницы — метки рекламных кампаний, идентификаторы сессий, служебные параметры. Робот Яндекса склеивает такие адреса с основным и не тратит на них обход. Google этого правила не понимает: для него те же адреса — отдельные страницы, и лечить их надо каноническим адресом и тем, чтобы во внутренних ссылках параметров не было вовсе. Если сайт работает на обе системы, полагаться только на яндексовское правило нельзя.

Второе решение, которого десять лет назад не было, — что делать с роботами компаний, обучающих нейросети. AI-боты — роботы компаний-разработчиков нейросетей, которые обходят сайты: одни собирают данные для обучения моделей, другие ищут ответы в реальном времени. Пускать или закрывать — решается в robots.txt; закрытый поисковый бот не процитирует сайт. Для сайта услуг закрывать поисковых ботов ассистентов невыгодно: цитирование — новый канал. Ботов для обучения сайту услуг закрывать тоже не нужно: на поиск в Яндексе и Google это не влияет, а то, что модель знает о компании, — часть того, как ассистенты её описывают. Неверно это для сайта, который продаёт сам контент, — портала, платных материалов: там данные для обучения — то, что у вас забирают бесплатно, и закрывать их — нормальное решение.

Синтаксис директив, различия систем по каждой директиве и примеры файлов — в техническом справочнике (П1) и в уроке «robots.txt, sitemap.xml и метатег robots».

Три файла с ошибками

Три случая из практики, по одному на каждую частую ошибку, — и сколько стоила каждая строка.

Правило с тестового сервера. Сервис по ремонту бытовой техники перезапустил сайт. На тестовом сервере файл запрещал обход всего сайта — правильно, чтобы копия не попала в поиск. При выкладке файл переехал вместе с остальным. Две недели всё выглядело нормально: робот просто перестал приходить, а страницы ещё стояли в индексе. На третьей неделе Google начал показывать страницы без описаний, Яндекс — исключать их из поиска. Заявки из поиска упали с сорока в неделю до шести. Строку нашли за пять минут, когда наконец посмотрели; восстановление заняло месяц. Ошибка — не в строке, а в том, что в чек-листе выкладки не было пункта «проверить файл для роботов и метатеги на боевом сервере».

Закрытые стили и скрипты. Компания по ремонту квартир много лет назад закрыла от обхода папку с файлами оформления — тогда это советовали ради экономии. Сайт потом перевели на новую вёрстку, где блок цен и примеры работ подгружались скриптом из той же папки. Робот видел страницы услуг без цен и без примеров. В Яндексе, где коммерческие факторы весят много, страницы услуг стояли на второй-третьей странице выдачи при содержании, которое было лучше, чем у соседей по первой, и давали 20–25 заявок в месяц. Открыли папку — через полтора месяца основные страницы поднялись в первую десятку, заявки из поиска Яндекса выросли до 40 с небольшим в месяц. Это тот случай, когда техническая ошибка действительно была проблемой: она обрывала путь страницы на этапе обработки.

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

sitemap.xml: когда нужен, когда бесполезен

Карта сайта — второй по известности инструмент и второй по количеству завышенных ожиданий. Её считают способом «ускорить индексацию», и это верно ровно наполовину.

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

Что включать: только адреса, которые должны быть в поиске. Каждый адрес в карте — заявление «эта страница основная, её нужно индексировать». Карта, в которой лежат страницы с noindex, адреса с перенаправлением, дубли, страницы с ошибками, противоречит сама себе и теряет смысл как подсказка. Дата изменения в карте имеет смысл, только если она честная: если движок ставит сегодняшнюю дату всем страницам при каждой генерации, робот быстро учится эту дату игнорировать.

Для больших проектов карта разбивается на несколько файлов с общим оглавлением — по разделам, типам страниц или датам. Это не только требование формата: раздельные карты позволяют видеть в панелях вебмастеров, какая доля каждого раздела в индексе. Карта по разделу «услуги», в которой из трёхсот адресов в индексе сто двадцать, — готовый диагноз.

И последнее: карта должна генерироваться автоматически, из того же источника, что и сами страницы. Ручные карты умирают первыми: через полгода в них нет новых страниц, зато есть удалённые, и карта из инструмента превращается в источник ошибок. Формат, поля и специальные типы карт — в техническом справочнике (П1).

Метатеги и заголовки управления индексацией

Если robots.txt управляет обходом, то метатеги и заголовки ответа сервера управляют индексом. Это второй уровень, и путают их с первым постоянно — отчасти потому, что метатег тоже называется robots.

Noindex из главы 1 работает на уровне индекса: робот страницу скачивает, но в выдачу не берёт. Указание можно дать метатегом или заголовком ответа сервера (X-Robots-Tag). Заголовок делает то же, что метатег, но работает для любых файлов, а не только для HTML-страниц, — в этом его единственное, но важное преимущество.

Nofollow — атрибут ссылки, который просит поисковик не учитывать её как рекомендацию. Google в справке пишет, что по таким ссылкам, как правило, не переходит, а в блоге 2019 года назвал атрибут подсказкой: страница может быть найдена иначе. Его часто ставят на внутренние ссылки, чтобы «не передавать вес» на служебные страницы, и это бесполезно: ни одна из систем не обещает, что вес перераспределится на остальные ссылки страницы, а страница, на которую ведёт ссылка, всё равно может быть найдена.

Здесь есть расхождение, которое меняет решение. Если на странице противоречивые указания — один метатег разрешает индексацию, другой запрещает, — Яндекс, по своей справке, учитывает разрешающее, Google — более строгое. Одна и та же ошибка в шаблоне даёт в двух системах противоположный результат, поэтому противоречивых указаний на странице не должно быть вовсе.

Когда что применять

Отдельно о документах. Обе системы индексируют PDF, документы и таблицы и показывают их в выдаче. Это бывает полезно — прайс или инструкция в поиске приводят людей, — а бывает вредно: старый прайс с ценами двухлетней давности стоит в выдаче выше страницы услуги, или внутренний документ с реквизитами клиентов оказался доступен по ссылке. Решение принимает бизнес: что из файлов должно быть в поиске. Исполнение — заголовок ответа для тех, что не должны, и ссылка с файла на страницу услуги для тех, что должны.

Коды ответа сервера

На каждый запрос робота сервер отвечает числом, и робот верит этому числу больше, чем содержимому страницы. Код ответа — самый короткий разговор между сайтом и поисковой системой, и в нём проще всего соврать, не заметив этого.

200, который врёт

Код 200 означает «страница есть, вот она». Проблема начинается, когда сервер отвечает 200 на то, чего нет: на удалённую страницу, на опечатку в адресе, на любой выдуманный адрес. Человек видит текст «страница не найдена» и уходит, а робот видит нормальную страницу с этим текстом и индексирует её. Поисковые системы научились распознавать такие страницы — в Search Console это статус «Ложная ошибка 404», — но распознают не все и не сразу. А пока распознают, каждая такая страница тратит обход и создаёт дубль.

Хуже, когда сервер на любой несуществующий адрес отдаёт главную страницу или страницу каталога с кодом 200. Тогда сайт для робота бесконечен: любая битая ссылка, любой мусорный адрес становится страницей с реальным содержимым, и все они — копии друг друга.

Перенаправления: что выбирать

301-редирект — постоянная переадресация с одного адреса на другой. Используется при переезде сайта, смене URL и склейке дублей; передаёт новой странице большую часть накопленных сигналов. Временное перенаправление (302 и его аналог 307) говорит «страница временно в другом месте, старый адрес остаётся основным». Справка Google описывает временное перенаправление в двух местах по-разному: в одном — как слабый сигнал, что основной адрес новый, в другом — как вовсе не сигнал: робот по нему проходит, но в выдаче, скорее всего, останется старый адрес, а новый попадёт туда, только если на него указывают другие сигналы. Вывод один: временное перенаправление ничего не «обнуляет», как считает рынок, но и переезда не означает.

Правило выбора: если старый адрес не вернётся — постоянное. Временное — только если вернётся: акция, техническое обслуживание раздела, сезонная страница. И главная ошибка в этой части — цепочки: адрес перенаправляет на адрес, который перенаправляет дальше. Каждое звено — потеря времени робота и риск, что на каком-то шаге он остановится. После переездов и смен структуры цепочки накапливаются годами, и их надо схлопывать в одно перенаправление сразу на конечный адрес. Что происходит с перенаправлениями при переезде — глава о миграциях.

404 против 410

Ошибка 404 — ответ сервера, означающий, что страницы по адресу нет. Сами по себе 404 нормальны, вредны битые внутренние ссылки на них и удалённые страницы с трафиком без редиректа. Код 410 означает «страницы нет и не будет». Google в справке пишет, что все ошибки группы 4xx, кроме «слишком много запросов», обрабатывает одинаково: проиндексированные адреса с такими кодами удаляются из индекса. Разница между 404 и 410 для поиска невелика; 410 однозначнее для тех, кто читает логи и для других роботов. Если движок умеет отдавать 410 для удалённых навсегда страниц — хорошо; если не умеет, переделывать ради этого не стоит.

Гораздо важнее другое решение: что делать с удалённой страницей, у которой были трафик, ссылки или заявки. Ей нужен не код ошибки, а постоянное перенаправление на ближайшую по смыслу живую страницу. Не на главную — перенаправление всего удалённого на главную поисковые системы распознают как мягкую ошибку, и сигналы старых страниц пропадают так же, как при 404.

Ошибки сервера и долгая недоступность

Коды группы 5xx означают «сервер не смог ответить». Разовая ошибка ничего не стоит. Серия ошибок заставляет робота снизить частоту обхода: поисковая система бережёт чужой сервер. Если ошибки продолжаются долго, уже проиндексированные страницы начинают выпадать из индекса. Google в справке не называет срок, а пишет «со временем»; на практике счёт идёт на дни, а не на часы, и неделя недоступности для небольшого сайта — уже реальный риск потерять часть страниц.

Отсюда два правила для бизнеса и разработки. Плановые работы — короткие и с кодом «временно недоступен», а не с ошибкой и не с пустой страницей с кодом 200. И мониторинг доступности — обязательный: о том, что сайт лежал ночью, должен узнавать разработчик утром, а не SEO-специалист через месяц по падению трафика.

Как проверять реальные коды

Браузер не показывает код ответа и проходит перенаправления молча. Поэтому «я открыл страницу, всё работает» — не проверка. Проверка — запрос адреса инструментом, который показывает код ответа и всю цепочку перенаправлений, обход сайта краулером — программой, которая обходит сайт по ссылкам так же, как поисковый робот, и собирает адреса, коды ответа и заголовки, — и логи сервера, где видно, что сервер отвечал именно роботу. Последнее важно: бывают серверы, которые людям отвечают одно, а роботам — другое, из-за защиты от ботов, ошибок кэширования или настроек хостинга. Справочник кодов — в техническом справочнике (П1) и в уроке «Коды ответа сервера, 404 и битые ссылки».

Пример: страницы отвечали 200 вместо 404

Сервис сантехников с двенадцатью бригадами сменил движок сайта. Старые страницы услуг перенаправили на новые, всё проверили по списку — сто сорок адресов, все в порядке. Чего не проверили: что отвечает новый движок на адрес, которого нет. Он отвечал кодом 200 и шаблоном с текстом «страница не найдена» и блоком популярных услуг.

Сам по себе это была бы мелкая ошибка. Но в шаблоне новой версии оказалась относительная ссылка, которая на любой странице, кроме главной, превращалась в адрес на уровень глубже — и тоже отвечала 200. Робот получил бесконечную лестницу: «услуги», «услуги/услуги», «услуги/услуги/услуги». За два месяца в базе Яндекса набралось около сорока тысяч таких адресов при четырёхстах настоящих страницах. Новые страницы районов индексировались по месяцу. Позиции основных страниц за это время просели на три-пять мест — достоверно отделить это от сезона нельзя, но совпадение по времени было точным.

Исправление заняло один день разработчика: несуществующие адреса стали отвечать 404, ссылку в шаблоне исправили. Мусорные адреса уходили из индекса около двух месяцев. Новые страницы стали индексироваться за несколько дней, позиции вернулись. Владелец задал правильный вопрос: «Почему этого не было в проверке после переезда?» Ответ — потому что проверяли то, что было, а не то, чего нет. С тех пор в моём чек-листе выкладки есть пункт: запросить три выдуманных адреса и посмотреть код ответа.

Зеркала, склейка, домены

Зеркало сайта — тот же сайт по другому адресу: с www и без, по http и https, на втором домене. Поисковик выбирает главное зеркало и показывает его; остальные склеивают с главным 301-редиректом, иначе сайт делит позиции сам с собой.

У любого сайта минимум четыре адреса главной: с защищённым соединением и без, с www и без. Если все четыре отвечают кодом 200 и показывают одно и то же, поисковая система видит четыре сайта-копии и выбирает главный сама. Обычно выбирает правильно, но не всегда, и не всегда быстро. Решение одно для обеих систем: один адрес — основной, остальные постоянным перенаправлением ведут на него, и на тот же основной адрес указывают канонические ссылки, карта сайта и внутренние ссылки.

Механика склейки в двух системах

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

Технические поддомены и тестовые копии

Самые дорогие зеркала — те, о которых никто не знает. Тестовая копия сайта на поддомене, открытая для всех. Старый домен, который продолжает отвечать копией сайта. Поддомен, через который хостинг отдаёт тот же сайт по техническому адресу. Адрес сервера по IP. Каждый из них — полная копия сайта, которая может попасть в индекс и спорить с основным за место в выдаче.

Тестовые копии закрывают паролем, а не запретом в robots.txt и не noindex. Запрет обхода не убережёт: адреса копии попадут в поиск по ссылкам — из таск-трекера, из писем, из чата подрядчика. Noindex опасен по-другому: при выкладке его переносят на боевой сайт, и это та же история, что с правилом в начале главы. Пароль не переедет на боевой сервер незаметно, потому что сайт перестанет открываться у всех.

Что делать, если склеилось не то

Бывает, что поисковая система выбрала основным не тот адрес: старый домен вместо нового, технический поддомен вместо основного, версию без защищённого соединения. Порядок действий: убедиться, что все сигналы указывают на нужный адрес — перенаправления, канонические ссылки, карта, внутренние ссылки, адрес в панелях вебмастеров; убрать противоречия — например, канонические ссылки на старый домен, которые забыли в шаблоне; сообщить о переезде: в Яндексе — в Вебмастере с главного адреса, в Google при смене домена — инструментом смены адреса в Search Console; и ждать — склейка и расклейка занимают недели. Делать что-то сверх этого, пока сигналы не приведены к одному, бессмысленно: система выбирает по сигналам, и пока они противоречат друг другу, она продолжит выбирать сама.

И о самом решении сменить главный адрес. Позиция книги о переездах — только с расчётом потерь — действует и здесь. У перехода на защищённое соединение расчёт короткий: потери небольшие и временные, а без него браузер предупреждает посетителей, что сайт не защищён. У смены домена ради нового названия расчёт длинный, и чаще всего он не сходится; это разговор главы о миграциях.

Управление краулинговым бюджетом

Главное о бюджете введено в главе 1: он считается по адресам, а не по страницам, и маленький сайт с фильтрами и метками ведёт себя как большой. Остаётся практический вопрос — как понять, что бюджет расходуется впустую, и чем это лечить.

Когда это реальная проблема

Признаки, по которым бюджет становится проблемой, а не модным термином: новые страницы индексируются неделями, хотя на них есть ссылки; изменения на старых страницах доходят до выдачи с опозданием в месяц и больше; в панелях вебмастеров число известных системе адресов в десятки раз больше, чем страниц на сайте; в логах сервера большая часть запросов робота — к адресам с параметрами, к сортировкам, к страницам, которых нет в меню. Рабочий порог из главы 1: если на страницы, которые должны быть в поиске, приходится меньше половины запросов робота, обход расходуется впустую. Если признаков нет, бюджета как проблемы у сайта нет, и работа над ним — расход.

Инструменты влияния по убыванию эффективности

1. Не создавать мусорные адреса. Самый эффективный и самый недооценённый способ: фильтры, которые не создают новый адрес для каждого сочетания, внутренние ссылки без меток и параметров, отказ от сессий в адресе, исправленные шаблоны, которые не порождают бесконечных адресов. Адрес, которого нет, не нужно ни закрывать, ни склеивать.
2. Правильные коды ответа. Несуществующее отвечает «страницы нет», переехавшее — постоянным перенаправлением без цепочек. Робот перестаёт тратить время на то, чего нет.
3. Запрет обхода для того, что не должно быть в поиске и там не стоит. Внутренний поиск, корзина, сочетания фильтров без спроса, сортировки.
4. Склейка параметров. В Яндексе — правилом о параметрах в robots.txt, в обеих системах — каноническим адресом. Работает медленнее и слабее, чем первые три способа, потому что робот всё равно узнаёт об этих адресах.
5. Ускорение сервера. Быстрый ответ позволяет роботу брать больше страниц за то же время. Эффект реальный, но заметен только на больших сайтах.
6. Карта сайта и перелинковка на важные страницы. Не экономят бюджет, но направляют его: робот чаще приходит туда, куда ведут ссылки и где карта сообщает об изменениях.

Чего в этом списке нет. Noindex бюджет не экономит: чтобы увидеть noindex, робот должен страницу скачать, и он продолжает её скачивать, хотя со временем реже. Nofollow на внутренних ссылках — тоже: адрес остаётся известным. И «отправить на переобход» — не управление бюджетом, а разовая просьба, которая не меняет причины.

Диагностика: почему страница не в индексе

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

Несколько правил, без которых алгоритм не работает.

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

Одна страница — это симптом, раздел — диагноз. Если не в индексе одна страница, причина может быть в ней. Если не в индексе треть раздела, причина почти всегда в шаблоне, движке или процессе — и искать её надо там, а не править страницы по одной.

Статусы читать в динамике, как сказано в главе 1: диагноз — статус, который держится несколько недель, а не один снимок.

Останавливаться на шаге 6, если до него дошли. Шаги 1–5 — техника: они чинятся разработкой по постановке SEO, и за них можно отвечать сроками. Шаг 6 — содержание и спрос, это зона бизнеса и SEO вместе. Если страница прошла первые пять шагов и упёрлась в шестой, дальнейшие технические действия — переобход, правка карты, ссылки — не помогут. Это тот случай, когда техническая ошибка ≠ проблема, а проблема — в том, что страница не даёт человеку ничего, чего нет в выдаче.

Индексация ≠ рост. Алгоритм заканчивается, когда страница в индексе. Дальше начинается ранжирование — граница влияния, о которой говорит глава 1, — и разговор о том, почему страница в индексе, но не в топе, — это разговор о факторах ранжирования, а не об индексации.

Мифы

• «robots.txt убирает из индекса». Он запрещает обход. Обе системы в справке пишут, что закрытые страницы могут участвовать в поиске. Чтобы убрать страницу, роботу нужно её скачать и увидеть noindex или код «страницы нет».
• «sitemap ускоряет индексацию». Для небольшого сайта с нормальными ссылками — почти не ускоряет: робот и так всё находит. Для большого каталога и часто меняющихся страниц — помогает, но только если карта честная: без мусора, дублей и фальшивых дат.
• «noindex экономит краулинговый бюджет». Не экономит: чтобы увидеть noindex, робот должен скачать страницу. Бюджет экономят адреса, которых нет, правильные коды ответа и запрет обхода для того, что не стоит в индексе.
• «302 не передаёт вес совсем». Вопрос поставлен неверно. Временное перенаправление говорит, что основной адрес — старый, и в выдаче обычно остаётся он. Ошибка в выборе между 301 и 302 стоит времени, а не «обнуления»; если адрес не вернётся — нужен 301.
• «Тестовый домен можно не закрывать — на него никто не ссылается». Ссылаются: таск-трекер, письма, чаты, сервисы проверки. Копия попадает в индекс и спорит с основным сайтом. Закрывать паролем.
• «Удалённые страницы надо перенаправлять на главную». Массовое перенаправление на главную поисковые системы распознают как мягкую ошибку. Страницам с трафиком и ссылками — перенаправление на ближайшую по смыслу, остальным — код «страницы нет».

Что запомнить

Обход и индекс управляются разными рычагами. Ошибка в выборе рычага — главная причина того, что «всё сделали, а страница всё ещё в поиске» или «всё сделали, а её всё ещё нет».

Страница не в индексе → восемь шагов от «точно ли нет» до санкции, остановка на первом подтверждённом обрыве. После каждого релиза — проверка запретов и кодов ответа на боевом сервере, раз в квартал — контроль по логам и панелям; на малом сайте больше не нужно.

Базовый уровень этой главы — уроки «Индексация», «robots.txt, sitemap.xml и метатег robots» и «Коды ответа сервера, 404 и битые ссылки». Синтаксис директив, коды ответа и форматы карт — в техническом справочнике (П1), проверки — в чек-листе аудита (П2).