Сайт не появляется в Google: как проверить индексацию и составить план исправлений
Если сайт не находится в Google, начните с проверки конкретных адресов в Search Console. Нужно выяснить, какую версию страницы видел Google, что доступно сейчас и должна ли эта страница вообще попадать в поиск. Ниже — порядок проверки для владельца бизнеса, таблица статусов и пример задания разработчику.
Уточните, что именно не появляется в поиске
Фраза «нас нет в Google» может описывать разные задачи: главная страница отсутствует в индексе, услуга не показывается по нужному запросу или компания не находится на карте. Этот разбор посвящён индексации страниц сайта. Показ рекламных объявлений и карточка компании на Google Maps требуют отдельной проверки.
Запишите полный адрес проблемной страницы и запрос, по которому вы её искали. Например, «страница уборки офисов не находится по запросу о клининге во Франкфурте» точнее, чем «сайт пропал». Затем отделите два вопроса: знает ли Google эту страницу как индексируемый документ и получает ли она видимость по интересующему запросу.
Поиск с оператором site: можно использовать для быстрой ориентировки, но он не показывает исчерпывающий список проиндексированных адресов. Отсутствие страницы в таком результате само по себе не доказывает проблему с индексацией. Не стройте задание подрядчику только на скриншоте поисковой выдачи.
Если проверка конкретного URL подтверждает, что он находится в Google, перенесите вопрос о его позициях в отдельную задачу: соответствие запросу, содержание страницы, конкурирующие результаты. Повторная отправка того же адреса на индексацию не заменяет этот анализ.
Соберите небольшой список важных страниц
Для первого прохода достаточно выбрать несколько адресов с разными задачами: главную, основную услугу, ещё одну услугу из другого шаблона, полезную статью и старый адрес после переезда. Это предлагаемая рабочая выборка, а не ограничение Google. Если найдётся повторяющаяся ошибка, проверку нужно расширить на затронутую группу.
Рядом с каждым URL напишите, зачем он нужен в поиске. Например: «объясняет услугу уборки офисов и принимает запросы», «отвечает на вопрос о подготовке помещения», «старый адрес услуги, теперь перенаправляет на новый». Так одинаковый статус не приведёт к одинаковому решению для совершенно разных страниц.
Ведите один журнал, доступный вам и исполнителю. Минимальные поля: полный URL, ожидаемое поведение, статус и дата последнего обхода Google, результат текущей проверки, задача, ответственный и дата следующего просмотра. Сохраняйте ссылки на доказательства или скриншоты рядом с записью.
Начните с страницы, отсутствие которой мешает основной услуге или всему сайту. Затем проверьте связанные шаблоны. Число красных строк в отчёте не отражает важность проблемы: один ошибочный запрет для раздела услуг может требовать внимания раньше десятков старых адресов.
Уточните у команды дату последнего запуска, смены домена, настройки перенаправлений или SEO-плагина. Эти сведения понадобятся для сравнения с последним обходом. Запись «исправили недавно» замените датой и описанием конкретного изменения.
Сравните сохранённую проверку с текущей версией
В Search Console выберите нужный ресурс и вставьте полный URL в верхнюю строку проверки. Сначала запишите результат обычной проверки, причину исключения и дату последнего сканирования. Затем запустите «Проверить опубликованную страницу» — TEST LIVE URL в английском интерфейсе.
Обычная проверка показывает данные о версии, обработанной Google ранее. Проверка опубликованной страницы исследует её текущее состояние. Надпись «URL доступен Google» подтверждает результат этой проверки, но не означает, что адрес уже включён в индекс. Выбранный Google канонический адрес в текущем тесте не определяется.
Предположим, перенаправление убрали 10 сентября, а в обычном отчёте указан обход 8 сентября. Старый статус ещё не доказывает, что исправление не сработало. Сопоставьте его с текущей проверкой и датой изменения; зафиксируйте отдельно технический результат и ожидание новой обработки.
В обратной ситуации ожидание мало помогает: если текущая проверка по-прежнему показывает действующий запрет, он требует разбора. Не закрывайте задачу только потому, что разработчик изменил настройку в панели управления. Нужен результат проверки опубликованного адреса.
При перенаправлении отдельно проверьте конечный URL и ответ исходного адреса. Сохраните оба адреса: зелёная карточка без этой информации не объясняет, что происходит со старой страницей. Для спорного случая полезно приложить доступные в инструменте HTML и снимок проверенной страницы.
Прочитайте статус и выберите следующий шаг
Ниже — краткая расшифровка распространённых статусов. Решение зависит от назначения страницы. Перенаправленный адрес или корректный дубль может не индексироваться намеренно; добиваться индексации каждой строки отчёта не нужно.
| Статус | Что он сообщает | Следующая проверка |
|---|---|---|
| Crawled — currently not indexed | Google обошёл страницу, но не включил её в индекс. | Сопоставить дату, текущую доступность, дубли и содержание. |
| Discovered — currently not indexed | Адрес известен, но ещё не просканирован. | Проверить доступность и пути обнаружения. Сам статус не устанавливает причину задержки. |
| Page with redirect | Этот адрес перенаправляет на другой. | Проверить назначение редиректа и конечную страницу. |
| Alternate page with proper canonical tag | Страница рассматривается как альтернативная версия. | Убедиться, что выбран нужный основной адрес. |
| Duplicate, Google chose different canonical | Google выбрал другой основной URL. | Сравнить его с заявленным canonical и содержанием обеих страниц. |
| Blocked by robots.txt | Правило robots.txt запрещает обход. | Выяснить, намеренно ли закрыт именно этот адрес. |
| Excluded by ‘noindex’ tag | Для страницы обнаружено указание не индексировать её. | Проверить, соответствует ли запрет назначению страницы. |
| Not found (404) | Сервер сообщил об отсутствии страницы. | Выяснить, удалена ли она намеренно и есть ли подходящая замена. |
Записывайте в журнал действие, которое проверит гипотезу. Например, для страницы услуги со статусом Crawled — currently not indexed поставьте задачу сравнить её с похожей услугой, а не утверждение «Google считает текст плохим». Статус не даёт такого диагноза.
Если несколько важных страниц имеют одну причину и общий шаблон, сгруппируйте их для исполнителя. Для старого адреса после переноса оставьте самостоятельное ожидаемое поведение: он может исправно перенаправлять и при этом оставаться в списке неиндексируемых страниц.
Проверьте препятствия на опубликованной странице
Для технической возможности индексации Google должен получать доступ к странице, успешный ответ HTTP 200 и пригодное для индексации содержание. Выполнение этих минимальных условий не гарантирует включение в индекс. Проверять их стоит на публичном адресе, который должен видеть посетитель.
Попросите разработчика проверить HTTP-ответ и фактическое содержание. Страница может выглядеть нормально в браузере владельца, но зависеть от авторизации или отличаться для другого посетителя. Ответ 200 тоже не доказывает исправность содержания: вместо услуги сервер способен вернуть пустую страницу или сообщение об ошибке. Такие случаи могут определяться как soft 404.
Отдельно проверьте noindex в HTML и HTTP-заголовке X-Robots-Tag. Если это случайный запрет на основной услуге, нужно убрать его и проверить результат. Если он нужен служебной странице, менять правило ради улучшения общей статистики не следует.
robots.txt и noindex выполняют разные задачи. Когда обход закрыт в robots.txt, Google может не прочитать указание noindex на странице. Поэтому комбинация двух запретов не является универсальным способом управлять исключением. Сначала определите желаемое поведение адреса, затем согласуйте механизм.
Не ограничивайте проверку одной настройкой CMS. Запрет мог появиться в шаблоне, плагине или заголовке ответа. В задании попросите назвать место исправления и перечислить другие страницы, на которые распространяется то же правило.
При ошибках загрузки запросите у исполнителя проверку серверных ответов и журналов за соответствующее время. Для воспроизводимого сбоя полезны URL, дата, часовой пояс и результат повторной проверки. Формулировка «Google иногда не видит сайт» без этих данных затрудняет поиск причины.
Разберитесь, какой адрес должен быть основным
Canonical — указание предпочтительного адреса для одинаковых или очень похожих страниц. Если Google выбрал другой URL, откройте оба и сравните назначение и содержание. Сначала нужно понять, перед вами ожидаемый дубль или две самостоятельные страницы, которые ошибочно связали как копии.
Например, новая страница услуги и её старая версия могут описывать одно предложение. Если старую заменили, согласуйте перенаправление на соответствующий новый адрес. Если страницы обслуживают разные задачи, разберите, почему они выглядят одинаково и почему одна указывает на другую.
Редиректы и rel="canonical" относятся к сильным сигналам канонизации; включение в sitemap — к более слабым. Эти сигналы желательно согласовать: основной адрес должен соответствовать содержанию, внутренним ссылкам и карте сайта. Google может выбрать канонический URL иначе, чем указано владельцем.
Не назначайте главную страницу основным адресом для всех услуг. Аналогично, общее название компании на двух доменах ещё не делает все их страницы дублями. Для языковых версий и самостоятельных сайтов сначала составьте карту соответствий.
Попросите исполнителя приложить фактический canonical из опубликованной страницы и результат проверки предполагаемого основного адреса. Скриншот настройки без URL не позволяет убедиться, что правило относится к нужной версии.
Проверьте карту сайта и ссылки на важные страницы
Откройте раздел Sitemaps в Search Console. Статус Success означает, что Google получил и прочитал карту без ошибок. Число обнаруженных страниц не равно числу проиндексированных: успешная отправка sitemap сама по себе не подтверждает обработку каждого URL.
Сравните содержимое XML-карты со своим списком важных страниц. В sitemap следует указывать полные канонические адреса, которые вы хотите видеть в поиске. Если там остались старые версии, попросите обновить генерацию карты и проверить конкретные строки после публикации.
Затем найдите путь к проблемной странице с сайта: из раздела услуг, категории блога или другого тематического материала. Google обычно извлекает ссылки из элементов a с атрибутом href. Переход, который визуально выглядит как ссылка, стоит проверить в разметке, если страницу трудно обнаружить.
Для владельца удобен простой вопрос: откуда заинтересованный посетитель должен попасть на эту услугу или статью? Если ответа нет, добавление одного URL в карту не решает задачу навигации. Попросите редактора выбрать осмысленное место для ссылки и понятную подпись.
Зафиксируйте два самостоятельных результата: адрес присутствует в актуальной карте и на него можно перейти по подходящей внутренней ссылке. Эти действия помогают организовать обнаружение страниц; срок и результат индексации они не задают.
Пример: четыре адреса — четыре разных решения
Условный пример: компания по уборке офисов обновила сайт 10 сентября 2026 года. Владелец проверяет его 14 сентября. Названия, даты и результаты ниже придуманы для объяснения процедуры и не описывают клиентский проект. Для краткости показаны пути; в рабочем журнале следует сохранять полный URL с доменом.
| Адрес и задача | Данные Google | Проверка 14 сентября | Действие и ответственный |
|---|---|---|---|
| / — главная, должна индексироваться | Обход 8 сентября: перенаправление. | 200, содержание главной; canonical указывает на этот же адрес. Редирект убран 10 сентября. | Зафиксировать текущий результат, запросить обработку и наблюдать. Владелец. |
| /uslugi/uborka-ofisov/ — основная услуга | Обход 12 сентября: исключена по noindex. | Запрет сохраняется в HTML. | Убрать случайный запрет в шаблоне, проверить остальные услуги. Разработчик. |
| /pages/office-cleaning — старый адрес услуги | Перенаправление, обход 12 сентября. | 301 на новую услугу; у цели пока есть noindex из предыдущей строки. | Сохранить корректный редирект. Разблокировать целевую услугу; обновить старые внутренние ссылки. Разработчик и редактор. |
| /blog/podgotovka-ofisa/ — инструкция клиенту | Обход 11 сентября: просканирована, пока не индексируется. | 200, запрета нет; содержание почти повторяет страницу услуги. | Проверить, нужна ли отдельная инструкция. Подготовить самостоятельные шаги и примеры либо обоснование объединения. Редактор. |
В этом примере ждать обновления отчёта достаточно только для уже проверенного исправления главной. У основной услуги остаётся действующий запрет. Старый адрес выполняет свою функцию, но его целевая страница ещё требует исправления. Для статьи пока сформулирована гипотеза о содержании, а не доказанная причина исключения.
После изменения шаблона разработчик повторяет проверку услуги и выборки других страниц с этим шаблоном. Владелец записывает дату публикации исправления. Когда Google обойдёт адрес заново, его результат сравнивают именно с этой датой.
Журнал помогает избежать лишних задач: никто не пытается сделать старый URL самостоятельной страницей, не переписывает главную из-за старого снимка и не считает отправку sitemap завершением всех работ.
Если технического запрета нет, оцените содержание
Для доступной, но неиндексируемой страницы полезен отдельный редакторский разбор. Нельзя установить качество материала по одному статусу Search Console. Сравните задачу страницы с соседними материалами и определите, есть ли у неё самостоятельная польза для посетителя.
Для услуги проверьте, понятны ли результат, границы работ, условия обращения и следующий шаг. Для инструкции — может ли читатель выполнить действие после прочтения: какие данные подготовить, что сделать и как оценить результат. Перечень общих советов без объяснения их применения трудно отличить от других страниц на ту же тему.
В условном примере статья о подготовке офиса может стать самостоятельной инструкцией: что согласовать до приезда команды, как обеспечить доступ и какие помещения требуют отдельных указаний. Если таких сведений у бизнеса нет, сначала получите их от ответственного сотрудника. Не добавляйте выдуманные процедуры ради объёма.
Выберите конкретное решение: сохранить страницу, доработать её или рассмотреть объединение с подходящим материалом. Зафиксируйте основания и исполнителя. Удаление страницы только из-за отсутствия индексации или увеличение числа слов без новой пользы не заменяет такого решения.
Если проблема относится к накопившимся статьям, следующий материал на Salestudia.de поможет организовать именно работу с содержанием: решить, какие страницы обновлять, объединять или удалять. Это отдельный этап после первичной проверки доступности.
Отправьте исправленные адреса и определите, чего ждёте
После проверки изменений можно запросить индексацию отдельных важных URL через инструмент проверки. Для большого набора адресов используется sitemap. Повторные запросы одного URL не ускоряют обработку; у инструмента есть квоты. Google не гарантирует включение страницы в индекс после запроса.
Google указывает, что повторное сканирование может занять от нескольких дней до нескольких недель. Это ориентир для обхода, а не обещанный срок индексации. В журнале поставьте дату следующего просмотра как организационное решение команды, без обещания клиенту определённой даты появления в поиске.
Кнопку «Проверить исправление» в отчёте используйте для действительно исправленной причины. Она не предназначена для превращения всех исключений в индексируемые страницы. Если старый адрес должен перенаправлять, его отсутствие в индексе не требует отмены редиректа.
Закрывайте техническую задачу по согласованному результату: нужная страница доступна, случайное ограничение устранено, изменения проверены. Наблюдение за обработкой Google оставьте отдельной записью. Так ожидание не маскирует незавершённую работу.
Если новый обход уже произошёл после исправления, но важная страница остаётся исключённой, вернитесь к её актуальной причине и собранным доказательствам. Расширяйте диагностику по обнаруженному несоответствию. Новая кнопка запроса без нового основания редко добавляет полезную информацию команде.
Передайте разработчику задачу с проверяемым результатом
Вместо просьбы «исправьте индексацию всего сайта» отправьте список конкретных адресов и ожидаемое поведение. Ниже — заготовка сообщения; замените поля в квадратных скобках своими данными.
«Страница [полный URL] должна [индексироваться самостоятельно / перенаправлять на конкретный URL / оставаться служебной]. В Search Console статус [название], последний обход [дата]. Последнее изменение сайта: [дата и описание]. Текущая проверка от [дата, время, часовой пояс] показывает [результат]. Скриншоты и сведения об ответе страницы: [ссылки].
Просьба проверить причину [наблюдаемое несоответствие], указать место исправления и затронутые шаблоны. После публикации приложите результат повторной проверки этого адреса и связанных страниц. Критерий приёмки: [конкретное ожидаемое поведение]. Обработку изменения Google будем отслеживать отдельно».
- Назначьте одного ответственного за исправление и одного за последующее наблюдение, если это разные люди.
- Укажите точные целевые адреса для редиректов и canonical: формулировка «на правильную страницу» оставляет решение непроверяемым.
- Сохраняйте даты до и после изменения. Они позволяют отличить повторный дефект от ещё не обновившегося отчёта.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- Google Search Console: проверка URL Источник проверен: 14.09.2026
- Google Search Console: индексирование страниц Источник проверен: 14.09.2026
- Google: технические требования Источник проверен: 14.09.2026
- Google: HTTP-ответы Источник проверен: 14.09.2026
- Google: noindex Источник проверен: 14.09.2026
- Google: канонические URL Источник проверен: 14.09.2026
- Google: карты сайта Источник проверен: 14.09.2026
- Google Search Console: отчёт Sitemaps Источник проверен: 14.09.2026
- Google: ссылки Источник проверен: 14.09.2026
- Google: запрос повторного сканирования Источник проверен: 14.09.2026
- Google: оператор site: Источник проверен: 14.09.2026
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.