Когда страница выпадает из поиска или внезапно перестаёт расти, первая реакция обычно предсказуемая: переписать текст, добавить ключи, покрутить внутренние ссылки. Иногда это помогает. Но иногда мы начинаем лечить контент, который поисковый робот вообще видит не так, как пользователь.
В Яндекс Вебмастере для этого есть довольно приземлённый инструмент — «Проверка страницы». Он показывает код ответа, доступный роботу контент, поисковый статус страницы и результат мобильной проверки. Вроде ничего экзотического. Но именно с него логично начинать разбор странного URL, прежде чем уходить в теории про качество текста и алгоритмы.
Особенно это актуально сейчас, когда сайты всё чаще собирают заметную часть интерфейса и контента через JavaScript. В браузере всё красиво, карточки загрузились, фильтр работает, описание на месте. А вопрос для SEO другой: что из этого получил и обработал робот?
Почему смотреть страницу в обычном браузере недостаточно
Обычный просмотр отвечает на вопрос, что видит человек после загрузки страницы. Для диагностики индексирования этого мало. Между запросом робота и готовой страницей есть сервер, редиректы, заголовки, правила индексирования, JavaScript, иногда защита от ботов и ещё несколько мест, где всё может пойти не по плану.
Типичный пример: URL открывается у владельца сайта без проблем, потому что браузер уже получил cookie, прошёл защиту или загрузил данные дополнительным запросом. Робот при этом может получать другой ответ. Поэтому фраза «у меня же страница открывается» в SEO почти ничего не доказывает.
Официальная справка Яндекса прямо предлагает использовать «Проверку страницы», чтобы узнать HTTP-код, который получает робот, посмотреть доступный ему контент, проверить статус URL в поиске и мобильную адаптацию.
Первое, что смотрим: ответ сервера
Начинать лучше с самого скучного — HTTP-кода. Для нормальной индексируемой страницы ожидаем 200 OK. Если робот получает редирект, ошибку сервера, 404 или другой неожиданный ответ, спорить о плотности ключевых слов пока рано.
Причём важен именно ответ для робота. Плавающие ошибки сервера особенно неприятны: сегодня URL отдаёт 200, завтра 500, потом снова работает. Владелец сайта может ни разу не попасть в момент сбоя, а поисковый робот попадёт.
Если проблема повторяется на группе страниц, я бы уже смотрел не отдельные тексты, а общий шаблон: сервер, CDN, правила перенаправлений, плагины, защиту, генерацию страниц.
Второе: какой контент получил робот
Вот здесь начинается самое интересное. Страница может отвечать кодом 200 и при этом быть практически пустой с точки зрения поискового робота.
На современных сайтах это бывает, когда значимая информация появляется только после выполнения клиентского JavaScript. Например, заголовок товара есть в исходном HTML, а характеристики, описание и часть навигации подгружаются позже. Для пользователя разницы почти нет. Для индексирования разница может оказаться принципиальной.
Поэтому полезно сравнивать не просто внешний вид страницы, а фактическое содержимое, доступное роботу. Есть ли основной текст? Заголовок? Ссылки на соседние разделы? Цена или характеристики, если они важны для страницы? Не заменился ли полезный блок сообщением об ошибке?
Отдельная история — cookie-баннеры, региональные окна, проверки возраста, авторизация и антибот-защита. Если такой слой закрывает или подменяет основной документ для робота, SEO-правки самого текста будут бессмысленны.
JavaScript не надо объявлять врагом SEO
Из наличия JavaScript не следует, что сайт плохо индексируется. Это слишком грубое правило. Проблема появляется не тогда, когда на странице есть скрипты, а когда без их успешной работы поисковая система не получает важный контент или ссылки.
Я бы разделял две вещи. Интерактивные элементы вполне могут жить на JavaScript. А критически важная для поиска информация должна быть доступна максимально надёжно.
Чем важнее элемент для понимания страницы и обхода сайта, тем меньше мне нравится зависимость этого элемента от сложной цепочки клиентских событий. Особенно если речь о заголовках, основном описании, навигации и ссылках на индексируемые разделы.
Третье: участвует ли URL в поиске
Следующий слой — поисковый статус. Если страница исключена, важно не останавливаться на самом факте исключения, а понять причину.
Здесь часто всплывают вещи, которые появились случайно: noindex после переноса с тестового сервера, canonical на другой URL, запрет в robots.txt, цепочка редиректов или технический дубль. Бывает и наоборот: владелец пытается вернуть в индекс страницу, которую поисковик считает дублем, хотя на сайте действительно существуют две почти одинаковые версии.
В такой ситуации задача не «заставить Яндекс взять URL», а сначала решить, должен ли этот URL вообще быть самостоятельной поисковой страницей.
Canonical: проверяем не по привычке, а по смыслу
Canonical часто воспринимают как техническую галочку. На деле ошибочный канонический адрес способен аккуратно сообщить поисковику, что продвигаемая страница вторична.
Особенно внимательно я бы проверял шаблоны интернет-магазинов, фильтры, сортировки, пагинацию и страницы, созданные на базе параметров URL. После массовых изменений шаблона одна ошибка легко размножается на тысячи адресов.
Если канонический URL отличается от проверяемого, сначала надо понять, это осознанная логика или наследство от шаблона. Автоматически менять canonical только потому, что конкретная страница не в поиске, тоже не стоит.
Мобильная версия всё ещё часть технической проверки
Вебмастер отдельно показывает, насколько страница адаптирована для мобильных устройств. Здесь я бы не ограничивался формальной отметкой.
Даже технически адаптивная страница может быть неудобной: элементы прыгают при загрузке, фильтр перекрывает каталог, кнопки стоят вплотную, таблица уезжает за экран. Это уже не только вопрос робота. Поисковый трафик должен куда-то приземляться, и бессмысленно радоваться индексации страницы, с которой пользователь сразу уходит.
Когда отправлять страницу на переобход
После исправления важного URL его можно отправить на переобход через Вебмастер. Яндекс описывает этот инструмент как способ сообщить роботу о новых и обновлённых страницах и поставить их в приоритетный обход.
Но переобход — не кнопка «починить SEO». Если сервер продолжает отдавать ошибку, canonical всё ещё ведёт не туда или робот не получает основной контент, повторная отправка URL просто ускорит следующую встречу робота с той же проблемой.
Поэтому порядок лучше не переворачивать: исправили причину, перепроверили страницу, убедились, что робот получает ожидаемую версию, и уже потом отправили URL на переобход.
Как я бы диагностировал проблемную страницу
Без сложных чек-листов последовательность выглядит примерно так:
- Проверить HTTP-код именно для робота.
- Посмотреть содержимое страницы, которое ему доступно.
- Сверить основной контент с тем, что видит пользователь.
- Проверить статус в поиске и причину исключения, если она есть.
- Проверить robots.txt, noindex и canonical.
- Посмотреть мобильную адаптацию.
- Если были изменения — после исправления отправить URL на переобход.
И только когда этот технический слой выглядит нормально, имеет смысл глубже разбирать соответствие запросу, качество текста, коммерческие факторы, внутреннюю перелинковку и конкурентов.
Почему это особенно важно после редизайна и переезда
Самый полезный момент для такой проверки — не когда трафик уже упал, а сразу после изменений сайта. Новый дизайн, смена CMS, переделка URL, перенос на другой сервер, внедрение клиентского рендеринга — всё это может изменить страницу для робота, даже если визуально она почти не поменялась.
Яндекс отдельно предупреждает, что при изменении структуры старый и новый адрес могут восприниматься как разные страницы. Поэтому после крупных работ я бы проверял не одну главную, а выборку разных типов URL: категорию, карточку, информационную страницу, фильтр, пагинацию.
Одна идеально работающая главная ничего не говорит о шаблоне каталога.
Главная мысль
SEO иногда слишком быстро превращается в обсуждение текстов и алгоритмов. А причина может лежать на этаж ниже: поисковый робот получил не тот документ, не тот код или не тот канонический адрес.
Поэтому при странном поведении отдельной страницы я бы сначала выяснял, что именно видит Яндекс. Это не самая эффектная часть работы, зато она хорошо отделяет реальные проблемы от догадок. И уже после этого можно спорить о качестве контента — хотя бы зная, что поисковик этот контент действительно получил.