Как проверить, не остался ли запрет на индексацию после запуска сайта
Пошаговая проверка robots.txt, запрета noindex, заголовков сервера и доступа к страницам. Как отличить случайные ограничения после запуска от нужных запретов и проверить результат исправления.
Чтобы проверить, не остался ли запрет на индексацию после запуска сайта, изучите файл robots.txt, инструкции robots в коде страниц и заголовок ответа сервера X-Robots-Tag. Затем убедитесь, что страницы открываются без авторизации и сервер отдаёт нужный контент. Снимать ограничения следует с тех страниц, которые должны появляться в поиске: служебные разделы и закрытые данные требуют отдельного решения.
Проверяйте именно опубликованный сайт. Настройка в панели управления может выглядеть правильно, а посетители и поисковые роботы продолжат получать старый запрет из шаблона, серверной конфигурации или кеша.
Какие ограничения искать
Индексация — это включение страницы в базу поисковой системы. Перед этим поисковый робот должен получить страницу и прочитать её содержимое. Поэтому важно различать запрет на обход и запрет на индексацию.
Запрет на обход ограничивает загрузку адресов роботом. Обычно его задают в robots.txt. Запрет на индексацию сообщает, что полученную страницу не следует включать в поиск. Для этого используют инструкцию noindex в коде страницы или в заголовке ответа сервера.
Эти механизмы нельзя считать взаимозаменяемыми. Адрес, закрытый в robots.txt, иногда может быть известен поисковой системе по ссылкам. При этом робот не сможет прочитать noindex внутри страницы, если ему запрещено её загружать.
| Где находится ограничение | Что искать | Как оценить находку |
|---|---|---|
| robots.txt | Disallow для всего сайта или нужного раздела | Проверить, запрещён ли обход важных адресов |
| Код страницы | noindex в инструкции robots или инструкции для отдельного робота | Выяснить, должна ли эта страница появляться в поиске |
| Заголовки сервера | X-Robots-Tag со значением noindex | Проверить правило сервера, приложения или внешнего сервиса |
| Доступ к странице | Пароль, отказ в доступе, проверка посетителя | Убедиться, что робот может получить содержимое |
| Ответ сервера | Ошибка, перенаправление, страница-заглушка | Проверить, что адрес отдаёт именно опубликованную страницу |
Отсутствие запретов ещё не означает, что страница обязательно появится в выдаче. Эта проверка решает более узкую задачу: найти технические ограничения, которые могли остаться после разработки.
Подготовьте список страниц для проверки
Начните с адресов, через которые люди должны находить бизнес. Обычно это главная страница, страницы услуг, категории каталога, карточки товаров и полезные статьи. Добавьте по представителю каждого шаблона: запрет может действовать только на один тип страниц.
Включите в список недавно опубликованную страницу и страницу, которая существовала ещё на тестовом сайте. Так проще заметить разницу между новыми настройками и ограничениями, перенесёнными вместе со старым контентом.
Отдельно запишите страницы, которым поиск не нужен: личный кабинет, корзину, внутренние результаты поиска, тестовые разделы. Это поможет не удалить все ограничения одним действием.
Для проверки понадобятся браузер, инструменты разработчика и доступ к настройкам сайта либо помощь разработчика. Если сайт подключён к Яндекс.Вебмастеру или Google Search Console, используйте проверку конкретного адреса как дополнительный источник информации. Названия и расположение инструментов могут различаться.
Заведите таблицу с полями: адрес, назначение страницы, найденное ограничение, решение и результат повторной проверки. Она станет списком задач, а не просто перечнем подозрительных настроек.
Шаг 1. Проверьте robots.txt на рабочем домене
Откройте путь /robots.txt на том домене, где опубликован сайт. Убедитесь, что видите текст правил, а не главную страницу, форму входа или сообщение об ошибке.
В robots.txt правила объединяются в группы. Строка User-agent определяет, к какому роботу относится группа. Значение * обозначает общее правило для роботов, которые его применяют. Disallow указывает пути, обход которых запрещён.
Типичный запрет, который используют во время разработки:
User-agent: *
Disallow: /
Здесь закрыт обход всего сайта. Если рабочий сайт должен быть доступен поисковым роботам, такое правило требует пересмотра. Но сначала прочитайте файл целиком: отдельные группы и разрешающие правила могут менять результат для конкретного адреса и робота.
Другой пример:
User-agent: *
Disallow: /catalog/
Такое правило касается путей внутри /catalog/. Если там находятся категории и товары, которые должны привлекать покупателей из поиска, выясните причину ограничения. Возможно, его добавили до наполнения каталога и забыли изменить при запуске.
Не удаляйте весь файл автоматически. В нём могут быть нужные правила для служебных адресов. Если сочетание Allow и Disallow выглядит сложным, проверьте конкретные URL инструментом анализа robots.txt, который учитывает правила нужной поисковой системы.
Проверяйте фактический рабочий домен и используемые поддомены отдельно. Ограничения тестового поддомена не описывают доступность основного сайта, а исправление файла на тестовой площадке не меняет рабочую версию.
Шаг 2. Найдите noindex в коде опубликованных страниц
Откройте страницу из списка и выберите просмотр исходного кода в браузере. Найдите слово noindex, затем изучите его окружение. Само совпадение ещё не доказывает наличие запрета: слово может встречаться в тексте статьи или примере.
Ищите метатег, у которого имя — robots, а содержимое включает noindex. Также проверьте инструкции для отдельных роботов, например с именем googlebot. Такой запрет может относиться только к определённой поисковой системе.
Возможные значения удобно понимать так:
noindex— инструкция не включать страницу в поисковый индекс.nofollow— инструкция, касающаяся перехода по ссылкам; сама по себе не запрещает индексацию страницы.none— сочетание noindex и nofollow в контексте инструкции robots.index, follow— разрешающие значения, которые не отменяют запрет, заданный в другом месте.
Для обычной открытой страницы услуг noindex часто оказывается следом режима разработки. Для внутренней страницы с результатами поиска это может быть осознанное решение. Оценивать нужно назначение страницы, а не только найденное слово.
Проверьте, нет ли нескольких инструкций robots. Плагин может добавлять разрешающее значение, а шаблон — запрещающее. Добавление ещё одного метатега с index не устраняет причину: нужно убрать ошибочный запрет в месте, где он формируется.
Если сайт меняет содержимое страницы с помощью JavaScript, дополнительно изучите вкладку Elements в инструментах разработчика. Она показывает текущую структуру страницы после работы скриптов. Разница между исходным кодом и этой структурой — повод попросить разработчика проверить, какие инструкции получает и видит поисковый робот.
Шаг 3. Проверьте X-Robots-Tag в ответе сервера
Запрет может отсутствовать в исходном коде и всё равно передаваться сервером. Для этого существует X-Robots-Tag — заголовок ответа, то есть служебная информация, которую сервер отправляет вместе с документом.
Проверить его можно в браузере:
- Откройте инструменты разработчика.
- Перейдите на вкладку Network, или «Сеть».
- Перезагрузите страницу, чтобы появились запросы.
- Выберите запрос основного документа, а не картинки, стиля или скрипта.
- Откройте Headers и найдите раздел Response Headers — заголовки ответа.
- Проверьте наличие X-Robots-Tag и его значение.
Например, ответ может содержать:
X-Robots-Tag: noindex
Такой запрет не получится устранить только настройкой метатега в редакторе страницы. Его источник может находиться в приложении, серверной конфигурации, настройках хостинга или сервиса, через который проходит ответ.
Просмотрите все строки X-Robots-Tag, если их несколько, и обратите внимание на указание отдельного робота. Передайте разработчику точный адрес и найденные значения: фраза «в коде всё открыто» не описывает проблему в заголовках.
Заголовок особенно полезно проверять у PDF и других файлов, которые должны находиться через поиск. У них нет обычного HTML-кода страницы, но инструкция noindex может передаваться в ответе сервера.
Шаг 4. Проверьте доступ без входа в систему
Откройте важные страницы в приватном окне браузера, где вы не авторизованы в панели сайта. Владелец может видеть полноценную страницу благодаря своему входу, тогда как остальные посетители получают пароль, заглушку или сообщение о технических работах.
На вкладке Network посмотрите статус ответа основного документа. Это короткий код, которым сервер обозначает результат запроса:
| Статус | Что означает | Что проверить |
|---|---|---|
| 200 | Запрос обработан успешно | Есть ли нужный контент вместо заглушки |
| 301 или 302 | Адрес перенаправляет на другой | Куда ведёт переход и доступна ли конечная страница |
| 401 | Требуется авторизация | Не осталась ли защита тестового сайта |
| 403 | Доступ запрещён | Почему сервер или система защиты блокирует запрос |
| 404 | Страница не найдена | Правильно ли опубликован адрес |
| 5xx | Ошибка на стороне сервера | Может ли сервер стабильно отдавать страницу |
Статус 200 сам по себе не подтверждает готовность страницы к индексации. Сервер может с этим статусом отдавать пустой шаблон или текст «Сайт скоро откроется». Проверяйте одновременно статус и содержимое.
Если есть перенаправление, изучите конечный адрес. Именно там могут находиться noindex, ошибка доступа или старый тестовый домен. Проверка только первого ответа оставит эту проблему незамеченной.
Приватное окно помогает выявить зависимость от авторизации, но не воспроизводит запрос поискового робота полностью. Если браузер получает страницу, а инструмент поисковой системы сообщает о блокировке, разработчику нужно проверить настройки защиты и ответы на запросы робота.
Шаг 5. Определите, какие ограничения нужно снять
Главный вопрос: должна ли конкретная страница быть доступна людям через поиск? Для главной, услуг, категорий и содержательных карточек товаров ответ обычно положительный. Случайный noindex или запрет обхода таких страниц следует устранить.
Служебные адреса требуют другого подхода. Корзина, внутренний поиск, технические копии и страницы с параметрами могут иметь ограничения по обоснованной причине. Не открывайте их массово только потому, что сайт запущен.
Закрытые данные должны защищаться авторизацией и правами доступа. Robots.txt и noindex не обеспечивают конфиденциальность: они сообщают правила поисковым роботам, но не мешают человеку открыть известный адрес.
Предположим, у магазина каталог закрыт правилом Disallow, а карточки товаров дополнительно содержат noindex. Чтобы разрешить их индексацию, нужно исправить оба ограничения. Удаление одного запрета оставит второй действующим.
Другая ситуация: публичная страница услуги содержит noindex, а личный кабинет требует входа. Здесь задача — убрать запрет со страницы услуги и сохранить защиту кабинета. Общая команда «открыть весь сайт» слишком неточна.
Шаг 6. Найдите источник запрета и исправьте его
Проверяйте не только отдельную страницу, но и настройку, которая создала ограничение. Иначе запрет может вернуться после обновления шаблона или повторной публикации.
В системе управления сайтом изучите общий режим видимости для поисковых систем, SEO-настройки раздела, параметры страницы и настройки плагинов. У конструктора также может быть отдельная настройка индексации для проекта и для каждого документа.
Если noindex обнаружен на страницах одного типа, вероятный источник — их общий шаблон или правило раздела. Если X-Robots-Tag приходит даже у разных документов, проверьте общие настройки сервера и сервисов доставки контента.
Передайте исполнителю конкретную задачу: «На опубликованных страницах услуг найден noindex в инструкции robots. Эти страницы должны быть доступны поиску. Удалить запрет из источника и проверить опубликованные ответы». Добавьте адреса, место находки и ожидаемый результат.
После изменения очистите соответствующий кеш, если он используется. Кеш — сохранённая копия ответа; из-за неё посетители могут продолжать получать старую версию после исправления настройки.
Шаг 7. Повторите проверку после исправлений
Заново откройте robots.txt, исходный код и заголовки ответа для тех же адресов. Проверку проводите без авторизации. Убедитесь, что запрет действительно исчез из опубликованной версии, а нужные служебные ограничения сохранились.
Затем используйте проверку URL в кабинете поисковой системы, если она доступна. Различайте сведения о последнем обходе и результат проверки текущей страницы: старый отчёт может описывать состояние до исправления.
Если инструмент позволяет запросить повторный обход, это можно сделать для исправленных адресов. Такой запрос не гарантирует включение страницы в индекс и не задаёт точный срок появления в поиске.
Результат технической проверки формулируйте конкретно: «Обход разрешён, noindex в коде и заголовках не обнаружен, страница доступна без входа и отдаёт нужное содержимое». Это подтверждает снятие найденных ограничений, но не обещает позиции или трафик.
Частые вопросы
Нужно ли добавить index, чтобы открыть страницу?
Обычно достаточно удалить ошибочный noindex. Добавление разрешающего значения не исправит запрет в X-Robots-Tag, закрытый обход или недоступность страницы. Проверьте все места, где могут задаваться ограничения.
Поможет ли добавление страницы в sitemap?
Sitemap — файл со списком адресов, который помогает сообщить поисковой системе о страницах. Он не отменяет noindex, правила robots.txt и ограничения доступа. Сначала устраните случайные запреты на нужных страницах.
Можно ли проверить запрет только поиском по домену?
Нет. Отсутствие страницы в результатах поиска не объясняет причину, а её наличие не подтверждает текущие настройки сервера. Для диагностики нужны опубликованный код, заголовки ответа и проверка доступа.
Почему после снятия запрета страница ещё не появилась?
Поисковая система могла ещё не обработать новую версию. Кроме того, решение об индексации зависит не только от технических разрешений. Проверьте текущий ответ страницы и дату сведений в инструменте поисковой системы, прежде чем повторно менять настройки.