Вебмастер не работает: как проверить сайт и SEO

Если Яндекс Вебмастер не работает, начните с доступности своего сайта, содержимого страниц и серверных логов. Недоступный кабинет лишает вас отчёта, но не доказывает остановку индексации. Менять robots.txt, переносить домен или переписывать всю семантику на основании одной заглушки рано.

Срез события: 12 октября 2026 года, около 21:54 МСК. Официальная страница Вебмастера показывала сообщение о временной недоступности. Яндекс сообщил о повреждении своих дата-центров и не назвал срок восстановления оборудования в заявлении компании. Это разные наблюдения: заявление об инфраструктуре и состояние интерфейса конкретного сервиса.

Я бы начал проверку с вопроса, на который можно получить ответ без кабинета: открываются ли страницы, которые приводят заявки? Затем проверил бы обращения роботов. Общие риски для бизнеса разобраны в статье про последствия атак на ЦОДы Яндекса. Здесь задача уже: собрать доказательства по собственному сайту.

1. Отчёт, обход, индексация и позиция: четыре разных состояния

Робот запросил страницу, поисковая система обработала её, документ попал в индекс, пользователь увидел его по запросу. Между этими событиями нет знака равенства. Вебмастер помогает наблюдать часть процесса, но доступ к отчёту и сам процесс тоже нужно различать.

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

Таблица нужна и для общения с руководителем. Вместо «Яндекс нас выкинул» запишите конкретный симптом, URL, время и способ проверки. Такой журнал позволит сравнить состояние до восстановления и после.

2. Проверьте HTTP и содержание ключевых страниц

Возьмите небольшой контрольный набор: главную, продающую посадочную, несколько страниц с органическими заявками и свежую публикацию. Размер набора зависит от сайта; для первого прохода можно начать с 5–10 URL. Это рабочая рекомендация, не норматив Яндекса.

Откройте страницы с компьютера и телефона. Проверьте итоговый адрес после редиректов, код HTTP и видимый текст. Ответ 200 с пустым шаблоном, сообщением об ошибке или заглушкой вместо статьи не подтверждает нормальную работу страницы. Осмотрите исходный HTML: есть ли заголовок и основной материал, загрузились ли нужные ресурсы.

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

Для каждого URL сохраните результат: время, HTTP-код, конечный адрес, скриншот и обнаруженную проблему. При нестабильности повторите проверку из другой сети. Одного успешного открытия мало, чтобы закрыть расследование периодических ошибок.

3. Осмотрите robots.txt, canonical и sitemap

Проверьте, что важный раздел случайно не закрыт в robots.txt, а на страницах нет незапланированного запрета индексации в метатеге robots или заголовке X-Robots-Tag. Посмотрите canonical: он должен вести на выбранную основную версию документа, а не на тестовый домен, соседнюю статью или страницу ошибки.

Откройте sitemap по публичному адресу. Новая статья должна иметь корректный URL и доступную страницу, без цепочки ненужных редиректов. Для сайта с несколькими картами проверьте индекс карт и файл, содержащий именно нужную публикацию. Менять дату всех документов на сегодняшнюю ради «ускорения» обхода не стоит.

Я рекомендую сохранять исходные настройки перед правкой и менять только подтверждённую ошибку. Массовое снятие ограничений может открыть для обхода фильтры, технические разделы и дубли. Рабочие настройки полезнее панического переезда. Как читать отчёты в обычном режиме, объясняет руководство по Вебмастеру для маркетолога.

Сценарий А: обнаружена ошибка на самом сайте

Условный пример: Вебмастер недоступен, а посадочная отдаёт 503 и с мобильной сети, и при серверной проверке. В журнале приложения есть ошибки за тот же интервал. Это основание восстанавливать сайт: кабинет не нужен, чтобы подтвердить проблему доступности. После исправления проверяют HTTP, содержимое и форму, сохраняют время возврата страницы в работу. Последствия для индекса пока остаются отдельным вопросом.

Другой технический симптом: HTTP 200, но после собственного релиза нужный раздел попал под запрет в robots.txt. Сравните версию файла до релиза и после, проверьте правило для нужного робота и исправьте конкретный запрет. Запись об исправлении объяснит дальнейшие изменения обхода лучше предположения «всё случилось из-за атаки».

Сценарий Б: недоступен только кабинет

В другом условном примере контрольные страницы отдают полноценный HTML с кодом 200, настройки обхода сохранены, форма принимает тестовую заявку. В логах есть проверенное обращение основного робота после начала сбоя. Эти наблюдения подтверждают доступность сайта и конкретный обход. Они не гарантируют индексацию новой статьи и прежние позиции. Запишите результат и продолжайте наблюдение; оснований менять canonical или адреса страниц здесь пока нет.

4. Найдите YandexBot в логах и проверьте его подлинность

Попросите администратора выгрузить обращения к контрольным URL за период сбоя. Нужны время с часовым поясом, IP, User-Agent, запрошенный адрес и код ответа. Если перед сервером стоит CDN, учитывайте его журналы: часть ответов из кеша может вообще не попадать в лог основного сервера.

Строку YandexBot способен написать в User-Agent любой клиент. По инструкции Яндекса нужно определить имя хоста обратным DNS-запросом, проверить окончание yandex.ru, yandex.net или yandex.com, затем выполнить прямой DNS-запрос. Полученный IP должен совпасть с исходным. Передайте эту проверку тому, кто администрирует сайт.

Подтверждённый запрос основного индексирующего робота к статье с ответом 200 показывает, что обращение состоялось. Он не сообщает, принят ли материал в индекс. Другие роботы Яндекса могут заходить для собственных задач: проверка доступности не равна поисковой индексации.

Отсутствие YandexBot тоже требует аккуратности. Проверьте полноту журналов, ротацию файлов и временной диапазон. Без старого периода сравнения нельзя объявить редкий обход аварией: робот не обязан посещать каждый документ ежедневно.

5. Используйте IndexNow как уведомление об изменениях

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

Сохраните отправленные URL, время и HTTP-ответ. В справочнике API Яндекса код 202 означает ожидание проверки нового ключа. Код 200 подтверждает успешную передачу адресов. Ни один из этих кодов не означает «страница уже в поиске».

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

6. Отделите падение органики от сбоя измерения

Если одновременно недоступны Вебмастер и Метрика, сравнивайте независимые наблюдения. Есть ли запросы к страницам с поисковым реферером? Продолжают ли поступать заявки с ранее сохранённым источником? Открывается ли сайт по нескольким основным запросам? Разбор счётчика находится в статье «Яндекс Метрика не работает: что проверить».

Реферер бывает пустым, обращения ботов попадают в логи, повторные запросы не равны новым посетителям. Поэтому серверный журнал не заменяет отчёт поисковых кликов. Ручная проверка выдачи тоже ограничена регионом, устройством и формулировкой запроса. Зафиксируйте одинаковые условия, чтобы сравнение хотя бы отвечало на один вопрос.

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

Журнал наблюдений, который можно передать коллеге

Достаточно одной таблицы: время МСК, URL, способ проверки, HTTP-код, наблюдение, ссылка на сохранённый результат, действие и ответственный. В строке об обходе укажите IP, результат проверки подлинности и вид робота. В строке о выдаче сохраните запрос, регион и устройство. Для IndexNow запишите ответ API, а не статус «проиндексировано» по собственной догадке.

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

7. Частые вопросы о сбое Вебмастера

Нужен разбор конкретного сайта и его точек отказа? Оставьте заявку или напишите в Telegram @dipustovalov. Приложите проблемные URL, время сбоя и результаты проверки: с ними разговор начнётся с фактов.