Почему страница не индексируется
В предыдущем уроке мы разделили сведения из индекса и проверку опубликованной страницы. Теперь используем это различие для выбора исправления. Рассмотрим новую статью C: она нужна в поиске, но содержит noindex. Рядом находится служебная страница E, которую включать в поиск не нужно. У неё такой же метатег, однако робот не может его прочитать из-за запрета в robots.txt.
Адреса и ответы example.com остаются условным учебным сценарием. Мы не располагаем полученными сейчас отчётами индексации ProfessorWeb и не выдаём данные стенда за такие отчёты. При выполнении на собственном сайте сохраняйте фактическое состояние в seo-audit/observations-template.csv, а замысел изменения — в changes-template.csv.
Разрешение обхода и разрешение индексации
Обход — получение документа роботом. Индексация — дальнейшая обработка документа для поиска. Правило, мешающее первому действию, не становится автоматически инструкцией для второго. Представьте письмо с указанием внутри: если получателю запретили вскрывать конверт, он не узнает, что написано на листе. Подобная зависимость возникает между блокировкой URL в robots.txt и директивой noindex в его ответе.
В начале нашего примера есть следующие условия:
| ID | Назначение | Учебный ответ | Обход по условиям стенда | noindex |
Чего хочет владелец |
|---|---|---|---|---|---|
| B | Старый урок | 200 | Разрешён | Нет | Сохранить возможность участия в поиске |
| C | Новая статья | 200 | Разрешён | Есть | Разрешить участие в поиске |
| E | Публичный поиск /search/?q=xml |
200 | Закрыт для /search/ |
Есть | Оставить доступ посетителям, исключить из поиска |
Таблица показывает намерение и технические условия, а не фактические поисковые статусы. Для B и C успешная загрузка не решает вопрос о включении в индекс. Для E блокировка обхода объясняет, почему директива документа может оставаться непрочитанной. Google прямо указывает эту зависимость и не поддерживает noindex как правило файла robots.txt. Блокировка индексирования в Google.
Рабочая последовательность диагностики начинается с доступности документа: удаётся ли получить нужный материал, разрешён ли обход, отсутствует ли запрет индексации? Если один из этих вопросов имеет отрицательный ответ вопреки назначению страницы, у нас есть конкретная техническая причина. Если ответы положительные, исследование продолжается: они ещё не объясняют решение поисковой системы.
Удаление ошибочного запрета у C
Статья C находится по адресу /articles/markdown-guide.html. По сценарию она возвращает свой текст и canonical на себя, но её <head> содержит такой фрагмент:
<meta name="robots" content="noindex">
<link rel="canonical" href="https://example.com/articles/markdown-guide.html">Предназначение этих строк различается. Первая запрещает индексацию, вторая объявляет предпочитаемый адрес документа. Самоссылка canonical не отменяет запрет первой строки. Поэтому добавление ещё одного canonical или включение C в Sitemap не исправляет указанную проблему.
Изменение для нашего стенда состоит в удалении ошибочного метатега noindex. Приведённый ниже фрагмент показывает ожидаемую часть <head> после изменения; остальные элементы документа остаются на месте:
<link rel="canonical" href="https://example.com/articles/markdown-guide.html">При этом нужно найти источник запрета, а не только отредактировать готовый HTML. В статическом проекте он может появляться из настройки статьи или общего шаблона. Если изменить лишь файл в папке результата, следующая сборка вернёт прежнюю строку. Этот механизм знаком нам по переносу ProfessorWeb: исходники материалов и общая оболочка существуют отдельно от публикуемого результата.
Проверьте также HTTP-заголовки и правила для отдельных роботов. Например, отсутствие общего метатега не помогает, если сервер продолжает отдавать X-Robots-Tag: noindex, либо документ содержит отдельное запрещающее указание для нужной системы. Чтобы убрать запрет, необходимо устранить его действующий источник. Дополнительное разрешающее правило не является надёжным способом перекрыть все запрещающие правила. Как Google объединяет правила robots, метатеги и заголовки в Яндексе.
Здесь особенно полезна проверка области действия. Если запрет установлен в общем шаблоне, изучите, какие страницы используют этот шаблон, и почему правило появилось. Возможно, это оболочка публичных черновиков или тестового раздела, где запрет нужен. Нельзя удалять его у всего сайта только потому, что одной статье пора участвовать в поиске. Настройка должна выражать назначение материала и воспроизводиться при следующей публикации.
Ожидаемый результат изменения C — в её опубликованном ответе больше нет запрета, обход разрешён, текст статьи сохранён. В таблице это касается index_allowed, а не автоматически index_state. До получения новых поисковых сведений состояние в индексе остаётся неизвестным. Кроме того, C всё ещё не имеет обычных внутренних ссылок: добавление пути из каталога мы выполняем позднее, чтобы различать эффект разных изменений.
Почему запрет E нужно сделать читаемым
Для служебного поиска задача противоположная. Посетитель должен уметь открыть /search/?q=xml и пользоваться результатами. Но владелец не хочет публиковать в поиске каждую комбинацию запросов. По нашим начальным условиям документ содержит noindex, а фрагмент robots.txt запрещает роботу обращаться к нему:
User-agent: *
Disallow: /search/Это учебный фрагмент, а не полный файл реального сайта. У живого проекта может быть несколько групп User-agent, разрешающие исключения и другие правила. Прежде чем что-либо менять, нужно определить применимую к конкретному роботу группу и проверить полный адрес E. Для Яндекса это можно сделать инструментом «Анализ robots.txt», сопоставляя результат с самой страницей. Проверка доступности страницы для робота.
В нашем небольшом сценарии мы убираем правило, блокирующее /search/, и сохраняем у публичной страницы noindex. В результате робот может получить ответ и прочитать запрет индексации. Яндекс также предупреждает, что URL, ограниченный в robots.txt, может участвовать в поиске; для удаления средствами noindex доступ к документу должен быть открыт. Использование robots.txt в Яндексе.
Открытие обхода здесь не означает разрешение индексации. В журнале E появляются два самостоятельных ожидаемых наблюдения: crawl_allowed=true и index_allowed=false. Страница по-прежнему не входит в Sitemap. Не подменяйте такой результат словом «открыта», которое без уточнения может обозначать оба противоположных решения.
Мы обсуждаем публичный служебный документ. Если по адресу находятся персональные сведения, закрытые документы или административные действия, безопасность обеспечивается проверкой прав доступа и авторизацией. Файл robots.txt публичен, а его правила адресованы роботам; они не мешают любому посетителю открыть URL. noindex тоже не закрывает сетевой доступ. Ограничения robots.txt в Google.
Для большого поиска может появиться другая задача — ограничить огромное пространство комбинаций, чтобы робот не тратил ресурсы на бесконечные результаты. Она требует отдельной политики адресов и обхода. Наше изменение E решает узкий конфликт читаемости noindex; переносить его на миллион сочетаний фильтров без оценки устройства сайта нельзя.
Когда технического запрета уже нет
После исправления C владелец иногда ожидает немедленного появления статьи. Если этого не произошло, он начинает менять описание, добавлять index и повторно отправлять страницу каждый день. Такой набор действий не связан с доказанной причиной. Лучше посмотреть, на каком этапе появились доступные сведения, и сопоставить их с датой исправления.
В отчёте Google встречаются разные ситуации: адрес обнаружен, но ещё не проиндексирован; адрес просканирован, но ещё не проиндексирован; выбрана другая каноническая страница. Они требуют разного следующего вопроса, а некоторые исключения ожидаемы. Например, отсутствие дубля в индексе может быть правильным результатом. Описание причин содержится в справке отчёта об индексировании страниц.
Если источник сообщает только об обнаружении, нужно разобраться с доступностью и путями обнаружения, не предполагая, что робот уже прочитал новую статью. Если сообщается об обходе, исследуются полученный контент и его отличие от других материалов. Если указан другой canonical, сравниваются оба документа. Один лишь HTTP 200 оставляет эти вопросы открытыми: технические требования дают странице возможность индексирования, но не обещают его. Технические требования Google Поиска.
Для нашего C есть известная следующая задача: нормальный путь из каталога пока отсутствует. Sitemap даёт дополнительный источник адреса, однако посетитель не может дойти до статьи по обычным ссылкам. Позднее мы добавим такую связь. Пока запишите её как самостоятельную гипотезу в next_action, не утверждая, что именно она уже стала причиной конкретного решения Google или Яндекса.
Содержание тоже оценивается отдельно. Проверьте, отвечает ли новая статья на свою задачу, содержит ли полноценный текст, не повторяет ли соседний материал под новым заголовком. Здесь полезно сравнение с B, но не механическое выравнивание длины. Два самостоятельных урока могут иметь разный объём; добавление пустых абзацев ради числа слов не устраняет диагностированную техническую ошибку. В Яндекс Вебмастере основания исключения также следует читать по конкретному статусу, а не сводить все случаи к запрету робота. Причины исключения страниц в Яндексе.
Две разные записи об исправлении
В changes-template.csv заведите по одной записи для C и E. Для C гипотеза связана с ошибочным запретом нужной статьи, ожидаемое наблюдение — доступный ответ без noindex. Для E гипотеза связана с невозможностью прочитать нужный запрет; ожидаемый результат — разрешённый обход при сохранённом noindex. Даты изменения заполняются после фактического действия, а не при планировании.
В колонке rollback опишите возврат к прежней настройке статьи или прежнему фрагменту правил. Это не предложение отменять исправление при задержке поискового отчёта. Запись нужна, чтобы понимать, какой именно источник изменён и как вернуть его при обнаружении нежелательного влияния на другие страницы.
В конце урока C технически может участвовать в поиске, но остаётся без ссылки из каталога; E доступна роботу, чтобы тот увидел запрет. Получены два разных результата для двух разных назначений страниц. Следующий пример добавит ещё одну причину неверного состояния: ответ «успешно» для удалённого материала и лишние переходы по старому адресу.