все разделы
Индексация сайта – это не простое появление страницы в поисковой выдаче. Сначала поисковая система должна узнать URL, получить его содержимое, при необходимости выполнить JavaScript, сопоставить страницу с другими документами и решить, стоит ли включать её в поисковую базу. Разберём проверку в Яндекс Вебмастере и Google Search Console, причины исключения URL, Sitemap, IndexNow, ссылки и способы закрытия страниц. Отдельно покажем настройки Tilda, 1С-Битрикс и WordPress, чтобы владелец сайта мог отличить проблему обхода от проблемы индексации и не пытался исправить её одной кнопкой переобхода.
Представьте библиотеку: поисковик узнаёт о книге, получает её, описывает, сравнивает с копиями и решает, помещать ли её в каталог. Поэтому опубликованная страница не обязательно проиндексирована: нужны доступный ответ, обрабатываемое содержимое и самостоятельная ценность. Для бизнеса важны нужные товары, услуги, категории и статьи, а не поиск, корзины, аккаунты и тестовые копии.
Discovery – обнаружение URL, crawling – получение ресурса, processing/rendering – обработка и выполнение JavaScript, indexing – решение о включении в индекс, ranking/serving – выбор результата по запросу.
Discovery может произойти по внутренней ссылке, Sitemap, внешней ссылке, истории обхода или специальному уведомлению. Crawling означает, что бот действительно запросил адрес. Если сервер вернул HTML, это ещё не доказывает, что робот увидел контент, который появляется после выполнения JavaScript. Rendering может проходить отдельно и попасть в очередь.
Indexing – самостоятельное решение о сохранении документа. Ranking начинается позже: уже проиндексированные страницы сопоставляются с запросом, конкурируют друг с другом и получают место в выдаче. Поэтому URL «есть в индексе» и URL «находится на первой странице по нужной фразе» – разные утверждения.
URL находят по ссылкам, Sitemap, истории обхода, API-уведомлениям и посещениям. Яндекс дополнительно использует IndexNow и Метрику, но это не гарантирует индексирование.
Orphan page не имеет внутренних ссылок. Её найдут через Sitemap или внешнюю ссылку, но важность останется неочевидной. Важным страницам нужны ссылки из категорий и релевантных материалов.
Контроль индексации помогает поисковику расходовать ресурсы на полезные документы. Если сайт создаёт тысячи URL фильтров, сортировок, календарей и результатов внутреннего поиска, бот тратит часть обхода на дубли и технические варианты. Это не означает, что каждая лишняя страница обязательно «крадёт» обход у каждой важной, но URL-пространство становится сложнее и менее управляемым.
Контроль нужен и для качества выдачи: дубли конкурируют с основной страницей, soft 404 создают пустые документы, а случайный noindex после staging закрывает production-сайт. Цель аудита – связать назначение URL с состоянием: существовать, обходиться, индексироваться или быть закрытым.
Crawl budget важен прежде всего для крупных и часто меняющихся сайтов. Для небольшого корпоративного сайта полезнее исправить HTTP, canonical, Sitemap и ссылки, чем искать универсальный лимит.
Первичные источники диагностики – Яндекс Вебмастер и Google Search Console. Поисковые операторы подходят для быстрой проверки отдельных примеров, но не являются точным счётчиком индекса. Для аудита составьте URL inventory из CMS, Sitemap, внутренних ссылок, логов и crawler-сканирования.
В Яндекс Вебмастере откройте «Индексирование → Страницы в поиске», а для URL – «Индексирование → Проверка страницы». Смотрите статус, HTTP, directives, canonical, редиректы и содержание робота.
Для нового или изменённого URL есть «Индексирование → Переобход страниц». Это запрос на приоритетное посещение, а не команда включить документ в поиск. Доступное число запросов динамическое и отображается в интерфейсе, поэтому не переносите в инструкцию старое фиксированное правило о тридцати страницах.
Полезен раздел «Индексирование → Мониторинг важных страниц», где можно следить за критичными адресами. В отчётах могут встречаться причины LOW_DEMAND, DUPLICATE, META_NO_INDEX, NOT_CANONICAL, HTTP_ERROR, HOST_ERROR и ошибки парсинга. Каждая причина требует своего исправления: повторный переобход не заменяет работу с canonical, качеством или сервером.
Для отдельного адреса используйте URL Inspection в Google Search Console. Смотрите Last crawl, Crawled as, Page fetch, User-declared canonical и Google-selected canonical. Если пользовательский canonical отличается от выбранного Google, сопоставьте редиректы, Sitemap, внутренние ссылки и содержимое всех связанных версий.
Статус Discovered – currently not indexed означает, что Google уже знает URL, но ещё не просканировал его. Проверяйте внутреннюю значимость адреса, Sitemap, стабильность сервера и количество технических URL. Crawled – currently not indexed означает, что документ уже скачан, но пока не выбран для индекса. В этом случае ищите дублирование, canonical, рендеринг и самостоятельную ценность страницы.
Request indexing подходит для небольшого числа важных страниц после реального изменения. У инструмента есть динамическая квота, повторная отправка одного и того же URL не ускоряет обход. Для массовых публикаций нужны архитектура, Sitemap, достоверный lastmod и стабильная работа сервера. Google не обещает фиксированный срок: повторный обход может занять от нескольких дней до нескольких недель.
В Google для быстрой выборки используйте:
``text site:example.com site:example.com/catalog/ ``
site: помогает найти примеры URL, но число результатов в выдаче не равно точному размеру индекса. Даже известный поисковику адрес может не показываться по такому запросу. Для отдельной страницы надёжнее URL Inspection.
В Яндексе можно проверить конкретный адрес оператором:
``text url:https://example.com/page/ ``
Оператор url: не следует выдавать за универсальный инструмент Google. Операторы показывают выдачу, а не внутреннее состояние URL. Важные выводы подтверждайте данными консоли.
Screaming Frog и Netpeak Spider помогают построить технический inventory: найти ссылки, коды ответа, canonical, robots directives, редиректы, глубину и дубли. Они показывают, что сайт отдаёт, но не заменяют данные поисковых систем о выбранной canonical-версии и индексе. Сервисы массовой проверки SERP используйте только как дополнительный мониторинг: на результат влияют задержки, CAPTCHA, регион и ограничения запросов. Статусы отдельных URL сверяйте в Яндекс Вебмастере и Search Console. Для server-side части проверяйте логи, curl и фактические заголовки production-ответа, поскольку CDN и кэш могут отдавать роботу другую версию.
Разделите адреса на три множества. A, Should be indexed – canonical-страницы с 200, которые предназначены для органического поиска. B, Actually indexed – адреса, участвующие в поиске по данным консолей, с выборочной проверкой URL Inspection. C, Should not be indexed – поиск, корзина, аккаунт, staging, приватные материалы, технические параметры, мусорные фасеты и устаревшие URL.
Затем посмотрите на разности. A − B показывает важные страницы, которые должны индексироваться, но пока потеряны. B ∩ C выявляет index bloat, то есть лишние документы в поисковой базе. Адреса вне всех трёх множеств ищите по логам, Sitemap, внутренним ссылкам и данным crawler.
Зафиксируйте назначение URL, HTTP, robots, noindex, canonical, Sitemap и статус. Так вопрос превращается в список задач.
Диагностируйте URL по последовательности: доступность → HTTP → directives → rendering → canonical → внутренние ссылки → содержание и выбор индекса. Если начать с кнопки переобхода, можно пропустить запрет, ошибку сервера или конфликт версий.
robots.txt управляет crawling, то есть разрешает или запрещает загрузку адреса конкретным роботом. Он не является механизмом конфиденциальности и не гарантирует удаление URL из индекса. Если на закрытый адрес ведут ссылки, поисковик может узнать его и показать без полноценного сниппета.
noindex работает иначе: робот должен получить HTML и прочитать директиву. Для HTML это может быть <meta name="robots" content="noindex">, а для PDF, изображений и других ресурсов – заголовок X-Robots-Tag: noindex. Если одновременно поставить Disallow и спрятать noindex внутри страницы, робот может не скачать документ и не увидеть директиву.
Для приватных данных нужны авторизация, пароль или ограничение доступа на сервере. SEO-директивы не должны заменять security-control. После снятия запрета проверяйте исходный и rendered HTML, response headers и фактический robots.txt на production-домене.
Ответ 200 означает, что ресурс успешно получен, но не гарантирует индексацию. Настоящая удалённая страница должна возвращать 404 или 410. Временная авария должна сообщаться корректным серверным статусом, например 503 в подходящем сценарии, а не страницей «сервис недоступен» с кодом 200.
Постоянные 5xx и 429 ухудшают возможность обхода. Soft 404 возникает, когда пользователь видит сообщение о том, что страницы нет, а сервер отдаёт 200. Проверьте случайный несуществующий URL, варианты со слешем и адреса после удаления товара.
Следите за цепочками редиректов. 301 и 308 подходят для постоянного переезда, 302 и 307 – для временного. Цепочка A → B → C → D сложнее и дороже для обхода, чем прямой A → D. Операционный триггер «исправить после двух-трёх переходов» не является универсальным лимитом поисковой системы. Цикл A → B → A нужно устранять обязательно.
rel="canonical" – сильный сигнал, но не приказ. Поисковик сопоставляет его с редиректами, Sitemap, внутренними ссылками и содержанием. Если Sitemap содержит параметрическую версию, ссылки ведут на неё, а canonical указывает на чистый URL, сайт передаёт противоречивые сигналы.
Canonical должен вести на доступную эквивалентную страницу, а не на 404, noindex, редирект или нерелевантную категорию. Для удалённого товара не подходит автоматический canonical на раздел: нужен 404/410 либо релевантный permanent redirect.
В Google сравнивайте User-declared и Google-selected canonical. В Яндексе смотрите DUPLICATE, NOT_CANONICAL и NOT_MAIN_MIRROR. Выберите одну версию и приведите к ней Sitemap и ссылки.
Orphan page не имеет crawlable внутренних ссылок из обычного графа сайта. Она всё равно может быть найдена через Sitemap или внешнюю ссылку, но поисковику труднее понять её роль и важность. Добавьте ссылки из релевантных категорий, навигации, хлебных крошек и материалов блога.
Глубина в кликах – полезная эвристика для аудита, а не универсальный порог Google или Яндекса. Важнее не конкретное число, а отсутствие ценных URL в изолированном сегменте. Проверяйте также, не создаёт ли меню на JavaScript ссылки, которые появляются только после пользовательского действия.
Для обнаруженного, но не просканированного URL проверяйте доступность, значимость, сервер и лишнее URL-пространство. Для просканированного, но не включённого – содержание, дубли, canonical и rendered HTML.
Формально уникальный текст не гарантирует включение. У Google нет нормы плотности ключей или фиксированного процента уникальности, а автоматизация сама по себе не запрещена. Риск возникает, когда сайт массово создаёт однотипные страницы ради поискового трафика без фактической пользы. В Яндексе похожая проблема может отображаться как «малоценная или маловостребованная страница».
Отправка сообщает поисковой системе о существовании или изменении URL. Она не отменяет проверку доступности, canonical, содержимого и качества. Перед отправкой убедитесь, что адрес действительно должен индексироваться и не закрыт случайным noindex.
Добавьте сайт в Яндекс Вебмастер и Google Search Console, подтвердите права и передайте Sitemap. Проверьте, что карта доступна по правильному протоколу и host, содержит только нужные canonical 200 URL и не противоречит robots.txt.
Новый сайт должен иметь понятную внутреннюю структуру. Создайте ссылки на ключевые разделы с главной страницы и других уже доступных материалов. Внешнее уведомление, Sitemap или IndexNow могут ускорить discovery, но не являются обещанием индексации.
В Яндекс Вебмастере используйте «Индексирование → Переобход страниц». В Google откройте URL Inspection и выберите Request indexing. Делайте это после публикации или исправления, а не вместо исправления. Статус принятой заявки означает обработку запроса или попытку посещения, но не гарантирует включение страницы в поиск.
Если причина исключения – canonical, noindex, 404, недоступный API или низкая самостоятельная ценность, повторная отправка без изменений результата не даст. После исправления проверьте фактический ответ, отправьте URL один раз и отслеживайте состояние.
Для большого массива используйте Sitemap, автоматическое обновление <lastmod> при значимом изменении и внутренние ссылки. Для поддерживаемых реализаций подключите IndexNow и отправляйте события publish, update и delete конкретных URL.
Не отправляйте весь сайт по расписанию. Свяжите уведомления с публикацией и сначала проверьте небольшую группу URL, ответы API и key-файл.
Безопасное ускорение – это устранение препятствий и улучшение обнаружения, а не попытка заставить робота нажимать на кнопку чаще. Сначала проверьте 200, доступ crawling, отсутствие noindex, рендеринг, canonical, Sitemap и внутренние ссылки.
Один Sitemap содержит до 50 000 URL и имеет размер до 50 МБ в несжатом виде. При превышении лимита используйте несколько файлов и sitemap index. Кодировка должна быть UTF-8, URL абсолютными и соответствующими нужному host.
В production-карту включайте только canonical, indexable URL с 200, которые действительно хотите видеть в поиске. <lastmod> меняйте при реальном значимом обновлении документа. changefreq и priority не являются рычагами, заставляющими Googlebot или YandexBot приходить чаще. Sitemap помогает обнаружению, но не гарантирует crawling или indexing.
Размещайте новые страницы в релевантных категориях, навигации, хлебных крошках и старых материалах. Используйте canonical URL, проверяйте статус ссылок и не создавайте искусственную сетку только для робота. Ссылка должна иметь смысл и для пользователя.
После миграции обновите внутренние ссылки одновременно с редиректами и Sitemap. Уберите ссылки на 404, цепочки, параметры-дубли и страницы, закрытые noindex, если они не нужны для навигации. Особенно внимательно проверяйте JavaScript-меню и ссылки, доступные только после события в интерфейсе.
Для небольшого числа критичных URL используйте ручные инструменты Яндекса и Google после фактического изменения. У Яндекса доступная квота динамическая и видна в интерфейсе. В Google действует quota, а повторная отправка того же адреса не ускоряет процесс.
Кнопка не исправляет архитектуру и не превращает некачественную страницу в индексируемую. После отправки наблюдайте дату последнего обхода, Page fetch, canonical и итоговый статус. Не обещайте мгновенный результат или обязательное появление в выдаче.
IndexNow уведомляет участвующую поисковую систему о добавлении, изменении или удалении URL. Уведомление может быть доставлено быстро, но решение о посещении и индексации принимает поисковик. Для Яндекса в соответствующей документации встречается отправка до 10 000 URL в одном запросе, однако это параметр реализации, а не гарантия результата.
Проверьте key-файл, его host и область действия для домена, поддомена или каталога. Не публикуйте секреты в статье. Связывание сайта с Метрикой и «Индексирование → Обход по счётчикам» помогает Яндексу обнаруживать посещаемые URL, но может привести к обнаружению корзин, параметров и приватных адресов. Контролируйте, какие страницы реально доступны.
Проверьте DNS, TLS, стабильность сервера, время ответа, частоту 5xx и 429, доступность CSS, JavaScript и API. Для Google важна mobile-first обработка: мобильная версия должна содержать основной контент, canonical и нужные ресурсы. Не закрывайте robots.txt файлы, необходимые для rendering, без проверки.
Crawl budget складывается из capacity и demand. Capacity ограничивается возможностями сервера, demand зависит от размера сайта, обновляемости, популярности и качества URL. Для обычного сайта не превращайте TTFB или глубину кликов в формальные требования: это инженерные сигналы и эвристики, а не универсальные условия индексации.
Каждая индексируемая страница должна отвечать на самостоятельный вопрос или решать задачу пользователя. Уберите шаблонные дубли, пустые варианты, фасеты без поискового назначения и страницы, созданные только ради числа URL. Проверяйте, что основной текст доступен в HTML или rendered HTML и не появляется исключительно после клика.
Не путайте индексацию с Core Web Vitals. Показатели пользовательского опыта важны для качества взаимодействия и ранжирования, но не являются простым условием «страница будет или не будет в индексе». Техническая скорость важна для способности сервера обслуживать обход, но фиксированного TTFB-порога для индексации нет.
Яндекс использует собственные статусы, инструменты и классификацию причин исключения. Их нельзя механически переводить в статусы Google. Общие принципы одинаковы: обнаружение, обход, обработка и отдельное решение о включении, но названия разделов и механизмы уведомления различаются.
Источниками discovery служат внутренние и внешние ссылки, Sitemap, ранее известные URL, IndexNow и обход по связанным счётчикам Метрики. Ссылка из уже известной страницы помогает не только обнаружить адрес, но и понять его место в архитектуре.
Если через Метрику обнаруживаются пользовательские URL, проверьте корзины, аккаунты, параметры и другие адреса, которые не должны попадать в поиск. Для регулярных обновлений лучше связывать уведомление с публикацией и изменением документа, а не надеяться на случайное обнаружение.
Используйте «Индексирование → Страницы в поиске» для массового отчёта и «Индексирование → Проверка страницы» для отдельного URL. Для срочного сообщения об изменении предусмотрен «Индексирование → Переобход страниц», а для контроля важных адресов – соответствующий раздел мониторинга.
Причина LOW_DEMAND означает, что повторная отправка не решает вопрос сама по себе. При DUPLICATE и NOT_CANONICAL сопоставляйте версии, canonical, Sitemap, редиректы и ссылки. При HTTP_ERROR, HOST_ERROR и PARSER_ERROR начинайте с сервера, DNS, TLS, логов и фактического HTML.
После реального изменения страницы исправьте источник проблемы, обновите Sitemap и внутренние ссылки, затем запросите переобход важного URL. Доступный дневной лимит не фиксирован и показывается в интерфейсе. «Заявка обработана» означает, что запрос принят или URL посещён, но не является гарантией включения в поисковую базу.
Для массовых изменений используйте Sitemap и IndexNow. Не называйте эти механизмы мгновенной индексацией. Яндекс сам выбирает документы и сроки обновления.
Google отдельно показывает discovery, crawling, rendering и index selection. Для Google особенно важно проверять mobile-first версию, выбранный canonical и различие между «обнаружен, но не просканирован» и «просканирован, но не включён».
Откройте URL Inspection и изучите Page fetch, Last crawl, Crawled as, User-declared canonical и Google-selected canonical. Проверьте live URL после исправления, но учитывайте, что результат проверки не обещает показ по конкретному запросу.
Если Google выбрал другую canonical-версию, сравните редиректы, Sitemap, внутренние ссылки, содержание и доступность всех вариантов. Если URL Discovered – currently not indexed, исследуйте обход и URL-пространство. Если Crawled – currently not indexed, ищите проблему выбора индекса, а не запрет на загрузку.
Для небольшого числа важных адресов используйте Request indexing. Для больших массивов передайте Sitemap и обеспечьте нормальную внутреннюю связанность. Отправляйте URL после устранения причины: повторная кнопка без изменений не ускоряет обход.
Google может вернуться к странице через несколько дней или недель, а само посещение не гарантирует индексирование. Для JavaScript проверяйте rendered HTML, доступность ресурсов и соответствие мобильной версии. Контент, появляющийся только после пользовательского клика или свайпа, нельзя считать гарантированно доступным роботу.
Сначала определите задачу: ограничить сканирование, запретить индексирование, закрыть содержимое от людей или удалить URL. Механизмы не взаимозаменяемы:
| Метод | Что делает | Когда применять | Ограничение |
robots.txt Disallow | ограничивает сканирование | технические пространства и ловушки для роботов | не гарантирует удаления URL из индекса |
meta robots noindex | запрещает индексирование HTML | публичная страница не нужна в поиске | робот должен получить HTML |
X-Robots-Tag | передаёт noindex в HTTP-заголовке | PDF и другие не-HTML ресурсы | робот должен получить ответ сервера |
| авторизация или IP allowlist | закрывает само содержимое | staging и конфиденциальные данные | требует корректной настройки доступа |
404/410 | сообщает об отсутствии документа | URL удалён без замены | состояние должно быть постоянным |
301/308 | переносит сигналы на другой URL | документ переехал на эквивалентный адрес | нельзя вести на нерелевантную страницу |
Файл robots.txt управляет обходом, а не гарантированным удалением из индекса. Базовый пример для служебных разделов выглядит так:
``text User-agent: * Disallow: /search/ Disallow: /cart/ Disallow: /checkout/ Disallow: /account/ Sitemap: https://www.example.com/sitemap.xml ``
Для полного технического запрета используется User-agent: * и Disallow: /, но это не защита данных. URL может стать известен по ссылкам, а робот не увидит расположенный в HTML noindex. Пути зависят от проекта: не копируйте шаблон без проверки.
Для доступной пользователю HTML-страницы используйте:
``html <meta name="robots" content="noindex"> ``
При необходимости следовать по ссылкам оставляют noindex, follow. Чтобы директива сработала, робот должен получить HTML. Поэтому не закрывайте тот же адрес robots.txt, если рассчитываете на чтение meta. После публикации проверьте исходный и rendered HTML, а также кэш CDN.
X-Robots-Tag передаёт директиву через HTTP-заголовок и подходит для PDF, изображений и других ресурсов без обычного <head>:
``text X-Robots-Tag: noindex ``
Пример для Nginx:
``nginx location ~ ^/documents/.\.pdf$ { add_header X-Robots-Tag "noindex, nofollow" always; } ``
Проверяйте фактический response, включая заголовок и Content-Type. Если ресурс закрыт robots.txt, поисковик может не получить header и не применить директиву.
Staging лучше закрывать Basic Auth, VPN, IP allowlist или другим настоящим контролем доступа. Disallow: / можно оставить как дополнительное правило, но оно не заменяет пароль. Личные кабинеты, заказы и внутренние документы должны быть недоступны без авторизации.
Перед переносом production проверьте, что не остались noindex, закрытый robots.txt, тестовый canonical и ограничение IP. После релиза откройте главную, типовые шаблоны, Sitemap и несколько страниц из каждой группы.
Выберите постоянное состояние. Удалённый документ отдаёт 404 или 410. Публичный, но непоисковый – доступен роботу и получает noindex или X-Robots-Tag. Приватный – закрыт авторизацией. Переехавший – получает 301 или 308 на эквивалентную страницу.
Временный инструмент удаления в Search Console или Яндекс Вебмастере ускоряет скрытие, но не исправляет сайт. Не закрывайте уже известный URL robots.txt в надежде на deindexing: после запрета робот может не увидеть noindex или обновлённое состояние.
Открытие – это не только удаление одной директивы. Проверьте, что сервер, шаблон, CDN, Sitemap, canonical и внутренние ссылки одновременно сообщают поисковику одну и ту же версию URL.
Откройте production robots.txt и убедитесь, что нужный путь не попадает под Disallow. Проверьте HTML на отсутствие noindex, response headers на отсутствие X-Robots-Tag noindex, а также код ответа 200. Убедитесь, что canonical ведёт на саму страницу или на согласованную эквивалентную версию.
Проверьте rendered HTML, доступность CSS, JS и API, мобильную версию, Sitemap и внутренние ссылки. Если страницу закрывали на staging, очистите кэш и повторно опубликуйте шаблоны. Административная галочка считается изменённой только после проверки фактического ответа.
После снятия запрета обновите Sitemap и при необходимости отправьте отдельный URL на переобход в Яндекс Вебмастере или Request indexing в Google Search Console. Для большого числа изменений используйте Sitemap и IndexNow, если он поддерживается.
Сообщение ускоряет обнаружение или приоритет посещения, но не гарантирует индексирование. Следите за Last crawl, Page fetch, canonical и причиной исключения. Если статус не меняется, продолжайте диагностику содержания, дублирования, рендеринга и качества, а не повторяйте запрос бесконечно.
CMS упрощает настройку, но интерфейс не заменяет проверку исходного HTML и HTTP-заголовков. Названия пунктов зависят от версии и конфигурации. После изменения публикуйте страницу и проверяйте её на домене.
Глобальный запрет находится в настройках сайта в SEO-разделе, а для отдельной страницы – в её SEO-настройках отображения в поиске. Canonical задаётся в специальных метаданных страницы. После изменения обязательно заново опубликуйте сайт или страницу и проверьте source HTML.
Для незапущенного проекта используйте ограничение доступа, пароль или IP-фильтрацию. Один SEO-флажок не защищает тестовые материалы. Проверьте, что домены не создают противоречивые canonical-сигналы.
Robots.txt настраивается через SEO-раздел, но итоговый файл зависит от версии и архитектуры. Свойства роботов могут задаваться для страниц и элементов инфоблоков. После сохранения проверяйте финальный HTML, headers, canonical и Sitemap.
Не используйте универсальный Disallow: /bitrix/: внутри prefix могут находиться ресурсы, необходимые для отображения и JavaScript-rendering. Разделяйте административные endpoints, персональные области, внутренний поиск и CSS/JS. Директивы Host и Crawl-delay из административного шаблона не следует считать обязательными без сверки с текущей документацией поисковика.
В «Настройки → Чтение» есть флажок «Попросить поисковые системы не индексировать сайт» или аналогичная настройка Search Engine Visibility. В современных версиях WordPress она формирует robots meta, поэтому проверяйте исходный HTML, а не только наличие Disallow: /.
После переноса staging флажок часто остаётся включённым. Для отдельных страниц и типов контента настройки обычно задаются SEO-плагином или темой. Изменение глобального значения может затронуть записи, рубрики, товары и архивы, поэтому проверьте каждую важную группу URL.
Большинство ошибок появляется, когда один механизм используют для другой задачи. Ниже приведены типовые сценарии и правильное направление проверки.
Фильтры, сортировки, внутренний поиск, календарь и параметры могут создать бесконечное URL-пространство. Найдите варианты в логах, crawler-отчёте и Search Console, определите SEO-фасеты и технические комбинации, затем согласуйте canonical, noindex, robots и внутренние ссылки.
Sitemap не должна содержать такие адреса. Но одного удаления из Sitemap недостаточно, если URL уже связан ссылками или известен поисковику. Для уже существующих лишних страниц выберите правильный результат: noindex, 404/410, redirect или ограничение crawling после решения вопроса с индексом.
Причиной может быть оставшийся Disallow: /, meta noindex после staging, X-Robots-Tag на уровне сервера, неверный шаблон или закрытые ресурсы rendering. Проверяйте страницу как пользователь и как робот: robots.txt, HTTP, headers, исходный HTML, rendered HTML и URL Inspection.
После исправления обновите кэш, Sitemap и внутренние ссылки, затем запросите переобход. Не считайте принятую заявку доказательством индексации: дождитесь обновления статуса и проверьте фактический canonical.
Disallow ограничивает загрузку, но не является гарантированным deindexing и не защищает конфиденциальные данные. Для публичной страницы, которая не должна быть в поиске, обычно подходит доступный роботу noindex. Для удалённой – 404/410, для переехавшей – 301/308, для приватной – авторизация.
Особенно опасно сочетание Disallow и meta noindex: поисковик не сможет прочитать meta. После изменения проверяйте, что желаемый механизм действительно виден crawler и соответствует назначению URL.
Sitemap, IndexNow, «Переобход страниц» и Request indexing сообщают об изменении, но не управляют алгоритмическим решением. Повторный обход может занять дни или недели.
Сначала проверяйте исправление, затем обход и индексирование. Если URL просканирован, но не включён, исследуйте canonical, дубли, рендеринг и ценность страницы. Здоровая индексация – это соответствие назначения URL его фактическому состоянию, а не добавление в базу всего, что создаёт CMS.
11.09.2026
59
32 мин
00000
Главная блога
Интернет-маркетинг
Отдел продаж
ТОП сервисы.svg)
Новости
