Редакция Romanov Lab · Обновлено
Если важная страница не появляется в поиске, начните с конкретного адреса и ожидаемого результата. Формулировка «сайт плохо индексируется» слишком широкая: каталог может работать нормально, а новые карточки оказаться закрытыми настройкой одного шаблона. Ниже приведён порядок диагностики для Google. У других поисковых систем есть собственные инструменты и особенности обработки правил.
Сначала составьте небольшой набор проверяемых URL
Выберите несколько отсутствующих страниц одного типа и одну похожую страницу, которая уже находится в индексе. Зафиксируйте полный адрес, дату публикации, назначение и путь из меню. Отдельно укажите, должна ли страница вообще участвовать в поиске. Результаты внутреннего поиска, личные кабинеты и технические копии не обязаны индексироваться.
Условный пример: у магазина появились новые модели оборудования. Старые карточки видны в поиске, новые нет. Проверка одной новой и одной старой карточки помогает найти различие в шаблоне быстрее, чем редактирование общего файла robots.txt наугад. Сохраните исходные настройки перед изменением: это позволит объяснить результат и вернуть прежнее поведение при ошибке.
Проверьте доступность до поисковых настроек
Откройте URL без авторизации и посмотрите фактический HTTP-ответ. Важна вся последовательность переходов: адрес может сначала перенаправлять на мобильную версию, затем на страницу входа. Ответ 200 тоже требует проверки содержимого: иногда сервер возвращает его для пустой страницы, заглушки или сообщения об отсутствии товара.
- Доступен ли основной текст без входа и специальных cookies?
- Не подменяет ли защитный сервис страницу проверкой посетителя?
- Загружаются ли название, описание и ссылки в отрисованной версии?
- Одинаково ли ведут себя адреса с параметрами и без них?
Используйте проверку опубликованного URL в Search Console и сопоставьте её с данными об уже обработанной версии. Это разные наблюдения. Текущая доступность не означает, что робот уже повторно посетил страницу и обновил индекс.
Разделите обход и включение в индекс
В документации Google robots.txt описан как инструмент управления обходом. Запрет Disallow сам по себе не гарантирует исчезновения URL из выдачи: адрес может быть известен по ссылкам. Для исключения доступной роботу страницы применяют noindex в HTML или HTTP-заголовке X-Robots-Tag. Если одновременно закрыть обход, Google может не увидеть noindex.
Поэтому проверяйте правила в двух местах. Сначала robots.txt именно нужного домена и протокола, включая подходящую группу User-agent. Затем исходный HTML и заголовки ответа. На сайте может отсутствовать meta robots, но сервер или CDN добавляет запрет заголовком. Бывает и обратная ситуация: настройка CMS разрешает индексирование, однако старый шаблон продолжает выводить noindex.
Не используйте поисковые запреты для защиты документов с персональными данными. Для таких материалов нужен контроль доступа. Если тестовая площадка должна быть закрытой, её нельзя считать защищённой только потому, что в robots.txt указан общий запрет.
Согласуйте sitemap с желаемым состоянием
Sitemap помогает сообщить о страницах, но отправка файла не гарантирует их индексирование. Для рабочего списка кандидатов выбирайте предпочтительные адреса, которые хотите видеть в поиске. Проверьте, что файл доступен, читается инструментом вебмастера и не содержит случайных тестовых доменов. Значение lastmod должно отражать существенное обновление страницы, если его удаётся определять достоверно.
Практически удобно разделять карту по типам содержимого: карточки, категории, статьи. Это упрощает поиск шаблонной ошибки. Сравните три списка: опубликованные страницы из CMS, адреса в sitemap и страницы, доступные по внутренним ссылкам. Если новая статья есть только в sitemap, проверьте, почему её не добавили в журнал или тематический раздел.
Практический разбор: новые услуги не появляются в поиске
Представим учебную ситуацию: после обновления сайта опубликованы страницы ремонта насосов и компрессоров. Главная открывается в поиске, а услуги не находятся. Это ещё не основание менять robots.txt целиком. Возьмите по одному новому адресу, старую работающую услугу и главную. Такая выборка разделяет общесайтовую проблему и дефект конкретного шаблона.
Сначала откройте новые услуги в приватном окне. Затем посмотрите вкладку Network в инструментах разработчика и выберите запрос основного HTML-документа, а не изображения. Запишите итоговый URL, статус ответа, заголовки и видимый текст. Если вместо услуги показывается экран авторизации, дальнейшая работа с метатегами преждевременна: сначала нужно восстановить публичную версию. При нормальном ответе переходите к поисковым ограничениям.
Допустим, в исходном HTML запрета нет, но в ответе присутствует X-Robots-Tag: noindex. Теперь есть проверяемая гипотеза: ограничение добавляется вне шаблона страницы. Разработчик сравнивает настройки сервера и CDN для старого и нового маршрута. В учебном сценарии новые услуги попали под правило, оставшееся от предпросмотра. Исправление должно ограничить область действия этого правила, сохранив защиту действительно закрытых материалов.
После изменения недостаточно увидеть отсутствие заголовка у себя. Повторите запрос без авторизации, проверьте новый URL и соседнюю услугу, обновите проверку опубликованной страницы в Search Console. Сохраните дату исправления и дату последнего обхода из отчёта. Если обход был раньше изменения, старое сообщение о noindex пока не опровергает результат работы. Не добавляйте новые исправления только ради мгновенного исчезновения предупреждения.
- Нужен в поиске? Если нет, проверьте ожидаемое исключение и завершите эту ветку.
- Доступен роботу? Разберите ответ сервера, авторизацию и правила обхода.
- Разрешено индексирование? Сопоставьте HTML и HTTP-заголовки.
- Это основной адрес? Проверьте canonical и содержимое альтернатив.
- Обновление уже увидели? Сравните дату обхода с датой исправления.
Как читать три похожих, но разных ситуации
URL неизвестен инструменту. Начните с обнаружения: существует ли обычная ссылка из раздела, включён ли адрес в актуальную карту, совпадает ли проверяемый домен с опубликованным. Проверьте опечатки, завершающий слеш и параметры. Не создавайте дополнительную копию страницы в надежде, что второй адрес обнаружат быстрее.
Адрес обнаружен, но ещё не обработан. Здесь полезно проверить стабильность доступности, связь с остальным сайтом и масштаб новых публикаций. Одна исправная страница не доказывает исправность всего раздела: возьмите несколько URL разных дат. Если одновременно появляются тысячи почти одинаковых комбинаций фильтров, отдельно разберите генерацию адресов. Простая повторная отправка карты не отвечает на вопрос, зачем нужны эти страницы.
Страница обработана, но не включена в индекс. Проверьте, что фактически получил робот: полноценный материал или пустой шаблон. Сравните содержание с другими URL. Есть ли здесь самостоятельный ответ, характеристика или предложение? Если технических препятствий не обнаружено, задачу стоит передать редактору вместе с конкретными примерами пересечений, а не формулировкой «добавить побольше текста».
Что передать разработчику, чтобы задачу можно было проверить
Хорошая заявка содержит наблюдение и ожидаемое поведение. Например: «У трёх опубликованных услуг сервер возвращает noindex в заголовке. У старой услуги его нет. Новые услуги должны быть публичными и доступными для индексирования; страницы предпросмотра должны оставаться закрытыми». Добавьте точные адреса, время проверки, снимок заголовков и ссылку на соответствующее правило конфигурации, если оно уже найдено.
- Область изменения: конкретный шаблон или группа маршрутов, а не весь сайт по умолчанию.
- Положительный тест: важная страница отдаёт ожидаемый документ без нежелательного запрета.
- Отрицательный тест: закрытая служебная страница не стала случайно публичной.
- Проверка кэша: одинаковый результат для свежего ответа и повторного открытия.
- Наблюдение после выпуска: дата нового обхода и состояние контрольных адресов.
Разделяйте срочность и масштаб. Ошибка на всех услугах после релиза важнее единичного старого URL, который уже перенаправляется на замену. При этом временное отсутствие совершенно новой страницы в поиске не требует аварийного изменения конфигурации. Рабочая диагностика заканчивается объяснением каждого симптома и следующим проверяемым шагом, а не обещанием индексации к определённой дате.
Исправляйте причину, затем наблюдайте
Посмотрите canonical и выбранный Google канонический адрес. Отсутствие конкретного URL в индексе может объясняться тем, что поисковая система объединила его с другой версией. Это отдельная задача: снятие noindex не исправит противоречивую канонизацию. Аналогично статус «Просканирована, но пока не проиндексирована» не доказывает наличие технического запрета.
- Запишите выявленную причину и все затронутые шаблоны.
- Проверьте исправление на тестовой странице и сохраните пример ответа.
- Внедрите изменение, очистите необходимый кэш и повторите проверку.
- При необходимости запросите индексирование важного URL через Search Console.
- Вернитесь к группе страниц после нового обхода и сопоставьте статусы.
Критерий завершения задачи состоит из двух частей: техническая причина устранена, а поисковая система получила возможность увидеть исправление. Момент фактического включения в индекс не задаётся настройкой CMS и не гарантируется запросом на переобход. Для общей очереди исправлений используйте чек-лист SEO-аудита, а если проблема повторяется после каждого выпуска, добавьте проверку в регламент поддержки сайта.
Официальные источники
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
