1. Проверьте HTTP-ответ
Нужная индексируемая страница обычно должна отвечать 200. Старый URL при переносе - 301, удаленный без замены - 404 или 410. Сначала исключите редиректы, циклы и серверные ошибки.
2. Проверьте robots и meta robots
Убедитесь, что URL отдельно проверить Disallow в robots.txt и отсутствие noindex в HTML. Для Tilda отдельно проверьте настройки индексации страницы и проекта.
3. Посмотрите canonical
Canonical должен указывать на фактическую предпочтительную версию документа. Ошибка в шаблоне способна канонизировать десятки страниц на один URL.
4. Сравните исходный и отрисованный HTML
Если критичный текст появляется JavaScript, проверьте, существует ли он после рендеринга. Google описывает отдельную фазу выполнения JavaScript, поэтому ошибки скриптов способны менять содержимое, которое робот видит после загрузки.
5. Используйте Search Console
Проверка URL показывает статус индексирования и позволяет запросить актуальный обход. Для JavaScript-страниц полезно смотреть отрисованную версию и доступность ресурсов.
6. Используйте Яндекс Вебмастер
Инструменты Вебмастера показывают страницу глазами робота, код ответа и причины исключения. Если URL пропал из поиска, сначала определите его статус, а затем исправляйте причину.
7. Проверьте мобильную версию
Убедитесь, что важный проверьте видимость текста, доступность меню, обычные кликабельные ссылки и загрузку отложенных ресурсов без обязательного действия пользователя.
Как проверить реализацию
- зафиксируйте конечный URL после всех редиректов;
- сверьте исходный код и отрисованный DOM;
- проверьте canonical и meta robots;
- посмотрите, доступны ли CSS, JavaScript и изображения;
- сравните данные Яндекса и Google с текущей версией страницы;
Для проблемного URL удобно сохранять короткий протокол: код ответа, индексирование, canonical, robots, дата обхода и найденная причина. Это экономит время при повторной проверке.
Что чаще упускают
Частая ошибка аудита - делать вывод только по оператору site: или по визуальному открытию страницы. Эти проверки не показывают, какой canonical выбрал поисковик, когда был последний обход и что именно попало в отрисованный документ.
Четыре слоя проверки вместо одного сервиса
Мы не ограничиваемся командой site: или зеленой отметкой в панели. Сначала проверяем HTTP-ответ: код, редиректы, заголовки. Затем исходный HTML: Title, robots, canonical, H1, ключевой текст и ссылки. Третий слой - отрендеренный DOM после JavaScript. Четвертый - данные самой поисковой системы в Яндекс Вебмастере и Google Search Console.
Такой порядок позволяет понять, где именно возникла проблема. Если ключевого текста нет уже в ответе сервера, причина одна. Если HTML полный, но поисковик выбрал другой canonical - другая. Если все технически доступно, но страница не попадает в индекс, нужно переходить к качеству и спросу.
Минимальный набор для диагностики
Для Яндекса используйте Проверку страницы и статус индексирования, для Google - проверку URL и отрендеренную версию. Яндекс отдельно рекомендует проверять, не выводится ли важный контент только JavaScript. Связанные сценарии разобраны в материалах про JavaScript-контент, про проверку индексации и про просканированные, но не проиндексированные URL.
Не смешивайте четыре разных состояния страницы
Исходный ответ сервера, DOM в браузере, версия поискового робота и документ в поисковом индексе могут отличаться. Поэтому проверка только через просмотр страницы в браузере дает неполную картину.
В Яндекс Вебмастере инструмент Проверка страницы показывает код ответа, доступный роботу контент и результат рендеринга JavaScript. См. официальную справку. Для Google аналогичную роль выполняет проверка URL в Search Console.
Что должно совпасть в четырех проверках
Проверка глазами робота - это цепочка: HTTP, robots, canonical, HTML, рендеринг и поисковые панели. Такой подход быстрее находит причину, чем перебор SEO-настроек наугад.
