Почему сайт не индексируется в Google и Яндексе: как найти причину
Если сайт не индексируется, потенциальный клиент может не увидеть нужную услугу, товар или статью в органическом поиске. Но одинаковая жалоба «нас нет в Google и Яндексе» скрывает разные ситуации: поисковик ещё не обнаружил адрес, робот не смог загрузить страницу, система выбрала другой URL или страница уже есть в поиске, но не показывается по выбранному запросу.
Начинать стоит с установления причины, а не с массовой отправки адресов на переобход. Ниже — порядок диагностики для владельца сайта, вебмастера и SEO-специалиста: какие доказательства собрать, как отличить техническую ошибку от нормального исключения и что проверить после исправления. Цель — вернуть возможность участия в поиске важным страницам, а не добиться индексации каждого служебного URL.
Почему «сайт не виден в поиске» ещё не означает проблему индексации
Путь страницы к посетителю состоит из нескольких этапов. Поисковая система узнаёт адрес, запрашивает его, обрабатывает содержимое и определяет, можно ли использовать страницу в поиске. Затем для конкретного запроса выбираются подходящие результаты и порядок их показа. В описании работы поиска Яндекса отдельно выделены обход, обработка данных, формирование базы участвующих в поиске страниц и выдача.
Из этого следуют разные задачи. Если адрес неизвестен, нужно разобраться с обнаружением. Если запрос завершается ошибкой — с доступностью. Если поисковик выбрал дубль — с адресами и содержимым. Если нужная страница уже участвует в поиске, но отсутствует среди заметных результатов по коммерческому запросу, дальнейшее исследование относится к релевантности, качеству и ранжированию.
Оператор site: пригоден для предварительного наблюдения, но не заменяет проверку конкретного URL в панели поисковика. Отсутствие страницы в отдельной выдаче само по себе не доказывает, что она не проиндексирована. Сравнивайте один и тот же адрес: протокол, поддомен, путь, параметры и конечный URL после перенаправления могут различаться.
В инструменте проверки URL Google сведения об индексировании и проверка опубликованной страницы отвечают на разные вопросы. Первый результат относится к известной Google версии, второй показывает доступность текущей страницы для обработки. Успешный живой тест не подтверждает включение в индекс и не гарантирует будущий показ.
Шаг 1. Определите масштаб и время появления проблемы
Запишите, какие страницы должны участвовать в поиске и почему. Отдельно отметьте главную, основные категории, востребованные товары, услуги и полезные материалы. Не включайте в целевой список личные кабинеты, результаты внутренних операций, случайные параметры и другие адреса, которым не нужна самостоятельная поисковая выдача.
Сравните пропавшие и сохранившиеся страницы одного типа. Если не индексируется только новый раздел, ищите различия в его шаблоне, навигации и правилах. Если одновременно исчезают разные разделы, сначала проверяйте общие изменения: перенос, настройки сервера, запреты, CDN, защиту от ботов. Эта группировка помогает найти одну системную причину вместо десятков отдельных «плохих страниц».
| Ситуация | Что проверить первым | Какие данные собрать |
|---|---|---|
| Новый сайт ещё не представлен в поиске | Обнаружение адресов и доступность публичной версии | Дата запуска, ссылки, выбранный основной адрес, сведения об обходе |
| Главная есть, внутренние страницы отсутствуют | Навигацию, общий шаблон и самостоятельность содержимого | Примеры разных разделов, HTML, правила индексирования |
| Проблема появилась после обновления | Изменённые настройки и компонент, общий для затронутых страниц | Время выпуска, список правок, старый и новый ответ |
| Потеряны страницы одного типа | Шаблон, canonical, содержимое и загрузку данных | Затронутый URL и рабочий пример того же типа |
| Google и Яндекс показывают разные результаты | Историю обхода и решение каждой системы отдельно | Статусы, даты последнего посещения и выбранные адреса |
Зафиксируйте исходное состояние до правок: точный статус, дату проверки, время последнего обхода, код ответа и ожидаемый результат. Если одновременно поменять текст, URL, canonical и правила сервера, последующее улучшение будет трудно связать с конкретным исправлением. Для групповых проблем сначала подтвердите гипотезу на нескольких характерных страницах.
Шаг 2. Выясните, может ли поисковик обнаружить нужные URL
Страница может открываться по прямому адресу, но оставаться изолированной от структуры сайта. Проверьте, можно ли добраться до неё по обычным ссылкам из доступного раздела. Бывает, что новые товары существуют только в выгрузке, статьи убраны из рубрики, а следующая часть каталога появляется исключительно после сложного действия пользователя.
В рекомендациях Google по ссылкам базовым вариантом служит элемент <a> с атрибутом href. Кнопка, которая меняет экран только через обработчик события, не обязательно даёт роботу адрес для обхода. Передайте разработчику конкретный пример: откуда посетитель приходит, какой URL должен обнаруживаться и что находится в разметке перехода.
Сопоставьте внутренние ссылки и Sitemap с фактическими адресами. В карте не должны случайно оставаться только старые URL, страницы тестового домена или варианты, которые перенаправляют в другой раздел. Наличие карты помогает сообщить об адресах, но не исправляет отсутствие контента, запрет индексирования или недоступность сервера.
Если поисковик уже знает URL, бесконечное повторение отправки не решает задачу обнаружения. Переходите к истории обхода: был ли успешный запрос, когда он состоялся и что робот получил. Не покупайте массовые внешние ссылки только ради «разгона индексации»: сначала убедитесь, что важная страница включена в логичную структуру собственного сайта.
Шаг 3. Проверьте ответ сервера и доступность для робота
Открытие страницы в вашем браузере не доказывает, что такой же ответ доступен поисковой системе. У вас могут быть сохранённая сессия, разрешённый IP или локальная копия. Сопоставьте проверку URL в панели поисковика, текущий HTTP-ответ и журналы сервера за время обращения робота. Для повторяющихся сбоев полезно сравнение нескольких моментов, а не одного удачного запроса.
HTTP-коды, соединение и ложные страницы успеха
Ошибки DNS, TLS и соединения мешают получить документ ещё до анализа его содержимого. Далее важны код ответа, цепочка перенаправлений и фактическое тело страницы. Документация Google по HTTP-кодам прямо указывает: успешный ответ 2xx не гарантирует индексирование. Длительные ошибки сервера могут сокращать обход и приводить к выпадению ранее известных адресов.
| Наблюдение | Что оно может означать | Направление исправления |
|---|---|---|
| 401 или 403 на публичной странице | Требуется вход либо запрос блокируется | Проверить права и защитные правила именно для публичного содержимого |
| 404 или 410 у нужного URL | Страница удалена, неправильно маршрутизируется или имеет другой адрес | Восстановить нужную страницу либо настроить релевантный переход |
| 5xx, тайм-ауты, разрывы соединения | Сбой приложения, хостинга или промежуточного узла | Найти причину по журналам и проверить устойчивость после ремонта |
| 200, но вместо материала заглушка | Формальный успех скрывает отсутствие нужного содержимого | Исправить выдачу контента и вернуть соответствующий состоянию код |
| Повторяющиеся перенаправления | Конфликт адресов, HTTPS или правил приложения | Устранить цикл и проверить конечную страницу |
Важный частный случай — soft 404: URL отвечает успешно, но показывает отсутствие страницы, пустой шаблон или сообщение об ошибке. Для существующей страницы восстанавливают полезное содержимое и его загрузку. Если материал окончательно удалён без подходящей замены, корректный 404 или 410 может быть ожидаемым результатом. Перенаправлять все исчезнувшие адреса на главную без учёта смысла не следует.
Авторизация, CDN и защита от ботов
Проверьте, не получает ли робот форму входа, страницу проверки браузера или блокировку вместо материала. Согласуйте исправление с администратором: публичная страница должна быть доступна, а закрытые данные должны оставаться защищёнными. Не отключайте защиту всего сайта ради одного теста и не открывайте административные разделы.
По строке User-Agent нельзя надёжно установить, кто обращался к серверу. Для Google есть официальные способы проверки запросов. Сопоставляйте подлинные обращения, журналы CDN и исходного сервера. Так можно выяснить, доходит ли запрос до приложения и на каком участке меняется ответ, вместо предположения «поисковик почему-то не заходит».
Шаг 4. Найдите непреднамеренный запрет индексирования
После разработки или переноса на рабочий домен иногда остаются ограничения тестовой версии. Проверяйте не только файл robots.txt, но и HTML страницы, HTTP-заголовки, настройки CMS и SEO-модуля. Общий шаблон способен добавить запрет сразу всем новым публикациям, а правило сервера — только определённому разделу или типу файла.
Robots.txt и noindex решают разные задачи
Для Google запрет обхода в robots.txt не равен гарантированному удалению URL из поиска. Директива noindex в метатеге или HTTP-заголовке запрещает индексирование, но робот должен получить страницу, чтобы прочитать правило. Эта зависимость подчёркнута в документации Google по noindex.
У Яндекса также нужно проверять метатеги и заголовок X-Robots-Tag: его справка указывает, что правило метатега или заголовка не действует, если страница запрещена в robots.txt. Однако особенности обработки директив у поисковых систем различаются. Не переносите рецепт одной системы на другую без проверки.
Для нужной публичной страницы выясните, откуда пришло ограничение, устраните случайный запрет и проверьте окончательный ответ после применения настроек. Если сайт использует несколько слоёв кэша, убедитесь, что посетителю и роботу уже выдаётся новая версия. Изменённый переключатель в административной панели ещё не доказывает изменения HTML и заголовков.
Когда исключение нужно сохранить
Закрытые документы, личные кабинеты и внутренние результаты операций не следует открывать ради красивой доли проиндексированных страниц. Яндекс описывает авторизацию как один из способов ограничить доступ к содержимому. Для конфиденциальных данных нужны реальные ограничения доступа; поисковые директивы не заменяют их.
Составьте два списка: «должно участвовать в поиске» и «исключено намеренно». Это особенно полезно в магазине с фильтрами и параметрами. Исправление должно возвращать доступ к выбранным посадочным страницам, не превращая каждую сортировку, сессию или служебный экран в самостоятельную страницу для поиска.
Шаг 5. Проверьте дубли, canonical и конечный адрес
Иногда страница не индексируется отдельно, потому что её содержимое уже представлено по другому адресу. Уточните, какой вариант нужен посетителю и какой выбрала поисковая система. Сравнивайте основной контент, а не только разные заголовки: переименование почти одинаковых страниц не делает их самостоятельными ответами на разные задачи.
В Google canonical и перенаправления служат сигналами выбора предпочтительного URL. Они должны согласовываться с внутренними ссылками и Sitemap. Проверьте, не ссылается ли шаблон каждой услуги на главную, не остался ли адрес тестового домена и доступна ли сама каноническая страница.
Яндекс воспринимает указание canonical как рекомендацию и перечисляет ситуации, в которых оно может не учитываться. Поэтому недостаточно обнаружить тег в исходном коде. Нужен ответ на вопрос: какой адрес фактически выбран и соответствует ли это логике сайта? Дубли, исключённые в пользу правильной основной страницы, не требуют принудительного возвращения в поиск.
Что проверить после смены адресов
При переезде сопоставьте старые и новые URL по смыслу. Старый адрес должен вести к соответствующему материалу, а целевой — открываться, содержать нужные данные и допускать индексирование. Обновите внутренние переходы и карту сайта в согласованной схеме. Не оставляйте посетителю длинную цепочку, которая заканчивается ошибкой или общим разделом вместо нужной услуги.
Пример для диагностики: адрес товара https://example.com/product-a/ исключён как дубль варианта с параметром. Сначала сравните содержимое и правила выбора адреса. Если это одна карточка, задача — согласовать сигналы в пользу основного URL. Если это разные товары, нужно искать ошибку шаблона или загрузки данных, из-за которой робот получает одинаковые страницы. Это пример рассуждения, а не результат проверки конкретного сайта.
Шаг 6. Убедитесь, что робот получает важный контент
Работающий интерфейс не всегда означает доступный для индексирования документ. Сравните HTML ответа сервера и результат рендеринга в инструментах поисковой системы: присутствуют ли название, основной текст, товарные данные и ссылки? Обратите внимание на пустой контейнер, бесконечный индикатор загрузки, ошибку API и ресурсы, которые не удалось получить.
Google умеет выполнять JavaScript, но обход и рендеринг являются разными этапами. Заблокированные ресурсы и ошибки выполнения могут изменить увиденное содержимое. Если исходный ответ уже содержит noindex, рассчитывать на последующее удаление запрета скриптом нельзя. Для разработчика важны конкретный отсутствующий блок и условия его загрузки.
В Яндекс Вебмастере предусмотрено управление рендерингом JavaScript. Сверяйте настройки и полученный результат в этой системе отдельно. Не объявляйте любой JavaScript причиной проблем, но и не считайте правильное отображение в своём браузере достаточным доказательством.
Для Google существенна мобильная версия содержимого. Проверьте, не исчезают ли на ней основные сведения, не меняются ли запреты и доступность ресурсов. Контент, который загружается только после ввода, клика или другого действия посетителя, требует особого внимания. Удобные раскрывающиеся блоки допустимы, если нужные данные доступны для обработки; удалять информацию из мобильной версии ради компактности не стоит.
Шаг 7. Оцените, есть ли у страницы самостоятельная ценность
Если доступ и технические настройки в порядке, изучите саму страницу. Полезно спросить: какую задачу она решает лучше, чем соседние страницы сайта? Есть ли на ней конкретные условия, характеристики, объяснение выбора, оригинальные материалы или сведения, необходимые пользователю? Список ключевых фраз и перефразированный общий абзац не заменяют содержательный ответ.
Рекомендации Google по полезному контенту предлагают оценивать полноту, достоверность и дополнительную пользу материала. Предпочтительного для всех страниц количества слов нет. Увеличение текста само по себе не устраняет дублирование, ошибки фактов и несоответствие задаче посетителя.
Для карточки товара проверьте различимые характеристики и доступную информацию о выборе. Для услуги — содержание работ, применимость, условия и понятный следующий шаг. Для статьи — прямой ответ, проверяемые пояснения и необходимые примеры. Если несколько страниц фактически отвечают на один вопрос одинаково, оцените объединение или переработку; не создавайте новые URL только ради повторного шанса на индексирование.
Яндекс отдельно объясняет статус «Малоценная или маловостребованная страница». Он может быть связан с дублями, отсутствием видимого роботу содержимого или слабым соответствием интересам пользователей. Сам по себе этот статус не означает наличие нарушений и ограничений в ранжировании. Сначала проверьте техническую доступность содержимого, затем его назначение и пользу.
Как читать статусы Google и Яндекса без поспешных выводов
Статус — отправная точка расследования, а не всегда полное описание корневой причины. Сопоставляйте его с датой обхода и текущим ответом. Если исправление выполнено позже последнего посещения роботом, старые сведения могут ещё описывать предыдущую версию страницы.
В отчёте Google об индексировании «Обнаружена, не проиндексирована» относится к известному адресу, который ещё не был просканирован в описанной ситуации. «Страница просканирована, но пока не проиндексирована» означает, что обход состоялся, однако включение не произошло. Второй статус не доказывает конкретную ошибку текста или сервера: нужно исследовать доступный контент, дубли и остальные сигналы.
В Яндексе ориентируйтесь на причину исключения в отчёте «Страницы в поиске». Например, «Дубль», «Неканоническая» и «Неглавный адрес сайта» требуют проверки адресов, а ошибки соединения и HTTP — доступности. Не переводите каждый статус Яндекса в похожее название Google: системы принимают решения отдельно и могут иметь разную историю обхода.
Если есть признаки взлома, чужие перенаправления или уведомления поисковика, проверьте разделы безопасности и нарушений. Для Google существует отдельный отчёт о мерах, принятых вручную. Следуйте указанной в нём причине и процедуре исправления. Отсутствие трафика само по себе не подтверждает санкции, а отсутствие ручных мер не объясняет все возможные причины потери видимости.
Как проверить результат после исправления
Разделите техническую приёмку и наблюдение за поиском. Сразу после выпуска можно подтвердить код ответа, доступность контента, снятие случайного запрета и правильность адресов. Появление новой версии в данных поисковой системы зависит от последующего обхода и обработки, поэтому это отдельный этап.
- Повторите исходную проверку. Используйте те же URL и условия, при которых была обнаружена проблема.
- Проверьте весь затронутый шаблон. Убедитесь, что исправлена причина, а не один показательный адрес.
- Сопоставьте конечный ответ. Проверьте заголовки, содержимое и выбранные адреса после применения настроек и обновления кэша.
- Сообщите об изменениях подходящим способом. Для важных исправленных страниц используйте инструменты поисковика; для набора URL поддерживайте корректную карту сайта.
- Отследите новое посещение. Сравните дату обхода с датой выпуска, затем повторно оцените статус страницы.
Google предупреждает, что запрос обхода не гарантирует включение в поиск, а повторные отправки одного URL не ускоряют его обработку. Для Яндекса также важно наблюдать фактическое посещение и итоговое решение, а не считать принятую заявку подтверждением индексации.
Если причина не исчезла, возвращайтесь к доказательствам: тот ли адрес проверяется, дошло ли исправление до рабочей среды, видит ли робот новую версию? Не меняйте URL заново только из-за отсутствия мгновенного результата. Это создаёт дополнительные переходы и усложняет сравнение истории.
Как расставить приоритеты и передать задачу исполнителю
Сначала исправляют общие препятствия для важных публичных страниц: недоступность, ошибочные запреты, сломанные шаблоны и перенаправления. Затем разбирают отдельные дубли, неполное содержимое и адреса с неясным назначением. Приоритет определяется ценностью страницы и масштабом ошибки, а не количеством предупреждений в панели.
| Что передать | Пример содержания задачи |
|---|---|
| Объект и охват | Точный URL, шаблон, список похожих страниц и рабочий пример |
| Доказательство | Статус поисковика, дата обхода, код ответа, заголовок или отсутствующий блок |
| Ожидаемое поведение | Публичный материал доступен, выбран правильный адрес, случайный запрет отсутствует |
| Граница исправления | Какие разделы меняются и какие исключения нужны по назначению |
| Приёмка | Повторная техническая проверка, дата выпуска и последующее наблюдение за обходом |
Хорошая задача формулируется конкретно: «на страницах указанного шаблона сервер отдаёт noindex, хотя они предназначены для поиска». Формулировка «сделайте индексацию» не объясняет, что менять и как принимать результат.
После устранения причин неиндексации продолжайте контролировать доступность важных страниц: новые сбои могут снова помешать роботам получить содержимое. Познакомьтесь с SiteGuard и оцените возможности мониторинга для регулярного контроля важных URL. Сохраняйте время обнаруженных ошибок и сопоставляйте его с датами обхода в панелях Google и Яндекса.
Частые вопросы о страницах, которые не индексируются
Почему новый сайт не появляется в Google сразу после запуска?
Публикация не равна обнаружению, обходу и включению в поиск. Проверьте публичную доступность, навигацию, основной адрес и отсутствие ограничений тестовой версии. После этого следите за данными поисковика. Универсального срока, после которого любой новый сайт обязан появиться в выдаче, нет.
Почему сайт индексируется в Яндексе, но не в Google?
У систем различаются история обхода, обработка и решения об участии страниц в поиске. Успех в одной не доказывает отсутствие проблемы для другой. Сравните конкретные URL, ответы, запреты для роботов, доступность содержимого и выбор канонического адреса в каждой панели.
Может ли мешать отсутствие Sitemap?
Карта помогает поисковику узнать об адресах, особенно если сайт новый или имеет много страниц. Но она не является единственным способом обнаружения и не заменяет доступные ссылки. Если URL уже известен, ищите причину дальше: в обходе, запретах, содержимом и выборе основной версии.
Нужно ли добиваться индексации всех страниц?
Нет. Приоритет — нужные пользователю основные страницы. Дубли, личные кабинеты и технические состояния могут быть исключены намеренно. Полезный результат аудита — понятное решение по каждой группе URL и отсутствие случайных препятствий у тех страниц, которые должны приводить посетителей.
Что делать, если технических ошибок не найдено?
Проверьте самостоятельную пользу страницы, её отличие от соседних материалов и фактически доступный роботу контент. Сопоставьте текущую версию с последним обходом. Если данных недостаточно, сформулируйте следующую проверяемую гипотезу; увеличение объёма текста и повторная отправка адреса без причины не заменяют диагностику.