Почему страница есть на сайте, но её нет в Яндексе и Google

Страница опубликована.

Она нормально открывается в браузере:

https://example.ru/expert/new-article

На ней есть:

TITLE;
description;
H1;
текст;
изображения;
canonical.

Страница даже добавлена в:

sitemap.xml

Но проходит несколько дней.

Потом неделя.

В Яндексе страницы нет.

В Google тоже.

Возникает естественный вопрос:

Если страница существует и доступна пользователю, почему поисковая система её не показывает?

Потому что фраза:

«страница есть на сайте»

и:

«страница находится в поисковом индексе»

описывают совершенно разные состояния.

Между публикацией страницы и её появлением в поиске находится целая цепочка:

Страница создана
      ↓
Поисковая система узнала URL
      ↓
Робот решил его обойти
      ↓
Получил HTTP-ответ
      ↓
Проверил robots/noindex
      ↓
Получил или отрендерил контент
      ↓
Определил canonical
      ↓
Сравнил страницу с другими
      ↓
Принял решение об индексировании
      ↓
Страница получила возможность
участвовать в поисковой выдаче

Сбой или неоднозначность практически на любом этапе способны привести к ситуации:

страница существует

но:

в поиске её нет.

Разберём весь путь последовательно.

Индексирование — не то же самое, что публикация

Когда разработчик нажимает:

Опубликовать

происходит событие внутри сайта.

Например в базе появляется статья:

status = published

и сервер начинает отдавать:

GET /expert/article

Пользователь может открыть URL.

Но Google и Яндекс не получают автоматическое уведомление:

На сайте появилась новая страница — немедленно добавьте её в поиск.

Поисковой системе сначала необходимо хотя бы узнать о существовании URL.

У страницы есть несколько разных состояний

Удобно разделять их.

1. URL существует

https://example.ru/expert/article

работает.

2. Поисковая система знает URL

Она обнаружила его через:

внутреннюю ссылку;
sitemap;
внешнюю ссылку;
ранее известный URL.

3. Робот скачал страницу

То есть был выполнен HTTP-request.

4. Страница технически пригодна для индексации

Например:

HTTP 200;
нет noindex;
нет запрета;
контент доступен.

5. Поисковая система решила включить страницу в индекс

Именно здесь находится принципиальный момент:

техническая доступность не гарантирует индексирование.

Google прямо указывает, что даже просканированная страница может не показываться в поиске, если система не считает её достаточно полезной или востребованной. Отправка URL на повторный обход также не гарантирует его включение в индекс.

Yandex аналогично подчёркивает, что даже наличие URL в Sitemap не гарантирует его появления в поисковых результатах.

Причина №1. Поисковая система просто не знает о странице

Представим статью:

/expert/postgresql-queue

Она опубликована.

Но:

на неё нет ссылки с /expert;
нет ссылки с главной;
нет ссылки из других статей;
в sitemap она не попала.

Для пользователя, которому отправили прямой URL:

страница существует.

Для робота:

URL может вообще не существовать.

Внутренние ссылки — это не только SEO-вес

Это ещё и механизм обнаружения страниц.

Yandex прямо рекомендует строить понятную структуру сайта и отмечает, что робот переходит с одной страницы на другую по обычным HTML-ссылкам. Чем глубже документ находится в структуре, тем больше времени может потребоваться на его обнаружение и индексирование.

Google также использует ссылки для обнаружения новых URL и рекомендует делать их обычными crawlable-ссылками:

<a href="/expert/article">
  Статья
</a>

а не только JavaScript-обработчиками без реального href.

Типичная ошибка SPA

На экране есть карточка:

Новая статья

Пользователь нажимает её.

JavaScript выполняет:

openArticle(article.id);

Но в HTML нет:

<a href="/expert/new-article">

Для человека навигация существует.

Для crawler discovery может быть значительно хуже.

Практический вывод

У важной SEO-страницы желательно иметь хотя бы один нормальный путь:

Главная
↓
Экспертный центр
↓
Рубрика
↓
Статья

А не существовать только как:

URL, который знает база данных.

Причина №2. Страница отсутствует в sitemap.xml

Sitemap не является командой:

Проиндексировать.

Но это очень полезный механизм обнаружения.

Например:

<url>
  <loc>
    https://example.ru/expert/postgresql-queue
  </loc>
</url>

сообщает поисковой системе:

Мы считаем этот URL значимой страницей сайта.

Google рекомендует включать в Sitemap URL, которые вы хотите видеть в поиске, прежде всего canonical-версии страниц.

Яндекс тоже использует Sitemap как источник информации о структуре сайта, хотя прямо предупреждает: попадание URL в файл само по себе не гарантирует его появления в результатах.

Поэтому ситуация

URL есть в sitemap

но:

URL не индексируется

не является противоречием.

Sitemap решает вопрос:

Как помочь роботу узнать URL?

Но не:

Обязан ли поисковик сохранить страницу в индексе?

Более серьёзная ошибка — sitemap содержит неправильный URL

Например реальная страница:

https://example.ru/expert/article

А Sitemap:

http://example.ru/expert/article

Или:

https://www.example.ru/expert/article

при canonical:

https://example.ru/expert/article

Получаются конфликтующие сигналы.

Хорошая схема

Для индексируемой страницы желательно согласовать:

URL в sitemap
=
canonical
=
внутренняя ссылка
=
финальный URL после redirects

Это не абсолютное требование поискового алгоритма.

Это просто хорошая инженерная дисциплина:

не заставлять поисковую систему самостоятельно угадывать, какой URL мы считаем главным.

Причина №3. robots.txt запрещает обход

Например:

User-agent: *
Disallow: /expert/

Теперь новый Экспертный центр можно прекрасно открыть браузером.

Но crawler получает инструкцию не обходить этот раздел.

Особенно опасен staging robots после deployment

На тестовом сервере совершенно разумно иметь:

User-agent: *
Disallow: /

Чтобы тестовая версия не попала в поиск.

Потом configuration случайно переносится в production.

Получаем:

сайт работает;
пользователи ходят;
поисковый робот закрыт.

Именно поэтому robots.txt нужно тестировать после релиза

Не только смотреть файл в repository.

А выполнить настоящий:

GET /robots.txt

на production-домене.

Yandex предупреждает, что ошибки в robots.txt способны привести как к исчезновению важных страниц из поиска, так и к индексированию нежелательных страниц.

Но robots.txt и noindex — разные инструменты

Это важно.

robots.txt прежде всего регулирует обход.

noindex сообщает:

Эту страницу не нужно включать в индекс.

Например:

<meta
  name="robots"
  content="noindex"
>

или HTTP:

X-Robots-Tag: noindex

Причина №4. На странице случайно остался noindex

Очень распространённый production-дефект.

На staging:

<meta
  name="robots"
  content="noindex,nofollow"
>

правилен.

Но после публикации template остаётся тем же.

В браузере страница выглядит идеально.

TITLE есть.

H1 есть.

Контент есть.

HTTP:

200 OK.

Но HTML говорит:

не индексировать.

Yandex прямо указывает, что страницы с noindex в robots meta или X-Robots-Tag исключаются из поиска.

Поэтому одной визуальной проверки недостаточно

Нужно проверять:

HTML <head>

и:

HTTP headers.

Потому что:

X-Robots-Tag: noindex

вообще не виден на странице.

Особенно часто X-Robots-Tag появляется на уровне Nginx

Приложение может ничего о нём не знать.

Например configuration:

location /expert/ {
    add_header X-Robots-Tag "noindex";
}

Frontend-тесты зелёные.

Backend-тесты зелёные.

Страницы из поиска исчезают.

Именно поэтому SEO нужно тестировать на уровне реального HTTP.

Причина №5. Страница возвращает не тот HTTP status

Для браузера визуально всё может работать.

Для робота HTTP-код имеет принципиальное значение.

Например вместо статьи приходит redirect

HTTP/1.1 301 Moved Permanently
Location: /expert

Пользователь автоматически попадает в раздел и может даже не заметить проблему.

Но индексироваться как самостоятельная статья такой URL уже не должен.

Или сервер возвращает 500

Например статья зависит от базы.

Пользователь открыл её позже, когда база восстановилась.

А Googlebot пришёл ровно во время сбоя:

500 Internal Server Error.

Для поисковой системы документ в этот момент недоступен.

Или появляется 403

Например WAF, CDN или антибот-система решает:

Необычный User-Agent.

Пользователь из обычного Chrome получает:

200

а crawler:

403.

Владелец сайта открывает страницу:

Всё работает.

Но для поискового робота сайт работает совершенно иначе.

Поэтому полезно задавать вопрос

Не:

Открывается ли страница у меня?

А:

Какой HTTP-ответ получает crawler?

Для нормальной индексируемой HTML-страницы обычно ожидаем

200 OK
Content-Type: text/html

и реальный контент.

Причина №6. «404» существует только визуально

Это одна из самых коварных ошибок SPA.

Пользователь открывает:

/expert/does-not-exist

и видит:

Страница не найдена

Кажется:

404 настроен.

Но HTTP-response:

200 OK

Для сервера это успешная страница

Получается:

200
+
текст «страница не найдена».

Поисковая система вынуждена самостоятельно определять, не является ли такой документ soft 404.

Ещё хуже обратный сценарий

Реальная статья:

/expert/real-article

почему-то получает пустой shell:

<div id="app"></div>

и HTTP:

200.

JavaScript не смог загрузить данные.

Для пользователя после ошибки API:

белый экран.

Для crawler — практически пустая страница.

Формально URL существует.

Но индексировать там почти нечего.

Причина №7. Неправильный canonical

Статья:

https://example.ru/expert/api-timeout

содержит:

<link
  rel="canonical"
  href="https://example.ru/expert/"
>

То есть сама страница говорит поисковой системе:

Главная версия моего содержимого — не я, а страница /expert/.

После этого удивляться отсутствию конкретной статьи в индексе уже странно.

Canonical — это очень сильный сигнал

Yandex указывает, что страница с canonical на другой URL рассматривается как неканоническая, а в поиске используется canonical-версия.

Google также группирует одинаковые или очень похожие URL и выбирает представительный canonical; при этом поисковик может выбрать другой canonical, чем указал владелец сайта, если остальные сигналы или содержимое говорят об обратном.

Самая безопасная схема для обычной уникальной статьи

Страница:

https://example.ru/expert/api-timeout

canonical:

https://example.ru/expert/api-timeout

То есть self-canonical.

Ошибка может появиться в общем шаблоне

Например разработчик пишет:

canonical = `${BASE_URL}/expert`;

вместо:

canonical =
  `${BASE_URL}${articlePath}`;

Теперь:

100 статей

сообщают:

Все мы — одна страница.

Это уже массовая SEO-регрессия.

Поэтому canonical особенно важно тестировать автоматически

Например:

page URL
===
canonical

для всех стандартных индексируемых статей.

Причина №8. Поисковая система считает страницу дублем

Canonical может быть правильным.

Но сами страницы почти одинаковы.

Например генератор создал:

Разработка CRM в Москве

Разработка CRM в Казани

Разработка CRM в Омске

А содержание отличается только названием города:

Мы разрабатываем CRM в Москве...

и:

Мы разрабатываем CRM в Казани...

Остальные 95% текста одинаковы.

Технически это три URL

С точки зрения пользователя и поисковой системы ценность может быть практически одной.

Поэтому поисковик может:

объединить;
не выбрать часть URL;
выбрать один canonical;
не считать каждый документ достойным отдельного индекса.

Google прямо описывает canonicalization как выбор одной представительной страницы из набора дублей или очень похожего содержимого.

Yandex тоже объединяет одинаковые или похожие страницы в группы дублей и выбирает canonical-документ.

Поэтому «уникальный URL» не означает «уникальная страница»

Пример:

/product/red
/product/blue

если обе страницы показывают практически одно и то же, сам другой slug ничего не решает.

Причина №9. Контент технически доступен, но поисковик не считает его достаточно ценным

Это принципиально другой класс проблем.

Здесь всё может быть идеально:

HTTP 200 ✓

robots открыт ✓

noindex отсутствует ✓

canonical правильный ✓

sitemap ✓

Но страницы в индексе всё равно нет.

Почему?

Потому что поисковая система не обязана хранить в индексе каждый доступный документ Интернета.

Google прямо отмечает, что страницы могут не показываться в поиске даже после crawling, если система не видит достаточной ценности или пользовательского спроса.

В Google Search Console эта логика проявляется, в частности, в ситуациях, когда URL уже известен, но ещё не crawled, либо crawled, но на данный момент не включён в индекс. Сам факт успешного обхода страницы не равен решению её индексировать.

Представим статью

Заголовок:

Что такое CRM

Текст:

CRM — это система управления
взаимоотношениями с клиентами.

Она помогает бизнесу работать
с клиентами.

CRM бывают разные.

Технически:

идеальная HTML-страница.

Информационно:

почти ничего нового.

В Интернете существуют тысячи более подробных материалов на ту же тему.

Просто увеличить количество слов — не решение

Можно превратить текст в:

10 000 символов

из повторяющихся объяснений.

Ценность от этого автоматически не появляется.

Полезнее добавить:

реальный сценарий;
архитектурную схему;
сравнение решений;
цифры;
ошибки;
практический опыт;
пример реализации;
неочевидный вывод.

Именно поэтому технические статьи на реальном инженерном опыте часто имеют больший смысл, чем массово созданные страницы под ключевые фразы.

Причина №10. Контент существует только после JavaScript

Современный сайт может работать так:

GET /expert/article
↓
index.html
↓
JavaScript
↓
GET /api/article/123
↓
render article

В первоначальном HTML:

<div id="app"></div>

Самого текста статьи нет.

Google умеет выполнять JavaScript

Но его процесс включает отдельные этапы:

crawl
↓
render
↓
index

Google прямо описывает, что JavaScript-приложение сначала crawled, а затем может попасть в очередь на rendering, где Chromium выполняет JavaScript и поисковик анализирует уже полученный DOM. Время между crawl и rendering не обязано быть мгновенным.

Кроме того, сама Google Search Central рекомендует SSR, static rendering или hydration вместо попытки полагаться на специальные обходные схемы динамического рендеринга.

Проблема не обязательно в JavaScript как таковом

Проблема появляется, если контент зависит от условий, которые crawler не выполняет.

Например:

нужен localStorage;
нужна cookie предыдущей сессии;
нужно нажать кнопку;
нужно прокрутить страницу;
нужен WebSocket;
API блокирует Googlebot.

Google отдельно предупреждает

При rendering:

Local Storage;
Session Storage;
cookies

не следует рассматривать как постоянное состояние между загрузками страниц.

Контент, который существует только после пользовательского действия, тоже может быть проблемой.

Например

Статья появляется только после:

button.onclick = () => {
  loadArticle();
};

Пользователь нажмёт.

Googlebot — нет.

Или lazy loading требует scroll

Google подчёркивает, что crawler не взаимодействует со страницей как пользователь и не будет прокручивать или нажимать элементы только ради появления контента. Индексируемое lazy-loaded содержимое должно становиться доступным без таких действий.

Почему SSR полезен для SEO-страниц

Для публичной статьи лучше получить:

<h1>
Почему timeout API
не означает отказ операции
</h1>

<p>
...
</p>

уже в HTTP-response.

Вместо:

<div id="app"></div>
<script src="/app.js"></script>

с надеждой, что весь дальнейший runtime отработает одинаково у каждого crawler.

Это не означает, что CSR запрещён

Google умеет индексировать JavaScript.

Но для публичного контента SSR/SSG часто делают путь короче:

HTTP
↓
готовый содержательный HTML

вместо:

HTTP
↓
JavaScript download
↓
execution
↓
API
↓
render
↓
content.

Чем меньше обязательных звеньев, тем меньше точек отказа.

Причина №11. Server-side HTML представляет собой shell

Это особенно характерно для SPA.

Проверяем страницу:

curl https://example.ru/expert/article

и получаем:

<!doctype html>
<html>
  <head>
    <title>Example</title>
  </head>

  <body>
    <div id="root"></div>
  </body>
</html>

В браузере после JavaScript всё прекрасно.

Но HTML-response практически ничего не рассказывает о самой статье.

Для приватного кабинета это может быть нормально

Например:

/login
/account
/admin

вообще не обязаны быть SEO-страницами.

Для Экспертного центра ситуация другая

Если цель страницы:

получать поисковый трафик;
передавать TITLE;
показывать текст;
участвовать во внутренней перелинковке,

серверный или статически сгенерированный HTML значительно предсказуемее.

Причина №12. Заголовок есть, а основного текста почти нет

Иногда SEO-генератор очень хорошо создаёт:

TITLE;
description;
keywords;
JSON-LD.

Но основной документ:

300 символов.

С технической точки зрения метаданные идеальны.

Однако поисковая система индексирует не набор SEO-полей отдельно от страницы.

Она оценивает сам документ.

Metadata не способна заменить содержимое

Очень хороший:

<title>

не превращает пустую страницу в полезный материал.

Так же как:

Article JSON-LD

не создаёт статью, которой фактически нет.

Причина №13. Сайт создал тысячи страниц слишком быстро

Представим SEO-generator за один день создаёт:

50 000 URL.

Из них:

5 000 реально полезных;
45 000 — комбинации фильтров,
городов, тегов и параметров.

Теперь crawler должен решить, куда расходовать ресурсы.

Поисковой системе не обязательно обходить всё немедленно

Google прямо рекомендует следить за crawl efficiency и отмечает, что большое количество малополезных URL способно отвлекать crawling resources от действительно важных страниц.

Yandex аналогично рекомендует закрывать технические, дублирующие и малоценные URL, чтобы робот не тратил ресурсы на них вместо основных документов.

Типичные источники URL-мусора

?sort=
?filter=
?page=
?session=
?utm_source=

а также:

бесконечные календари;
комбинации фильтров;
поиск по сайту;
служебные endpoints.

Чем чище индексируемый URL-space, тем понятнее сайт

Это похоже на склад.

Если на складе:

500 важных товаров

и:

500 000 пустых коробок,

поиск важных вещей становится сложнее.

Причина №14. URL слишком глубоко спрятан

Например:

Главная
↓
Экспертный центр
↓
Категория
↓
Подкатегория
↓
Архив
↓
2026
↓
Октябрь
↓
Статья

Для пользователя статья существует.

Но внутренний граф сайта сообщает:

Это очень глубоко спрятанный материал.

Yandex прямо отмечает связь скорости обнаружения с глубиной вложенности и рекомендует ясную структуру внутренних ссылок.

Важные страницы не обязательно ставить прямо на главную

Но они должны быть встроены в нормальную архитектуру сайта.

Например:

/expert

содержит ссылку на статью.

Статья связана с рубрикой.

Родственные статьи ссылаются друг на друга.

Получается осмысленный тематический кластер.

Причина №15. Страница недавно опубликована

Иногда проблемы вообще нет.

Страница появилась:

сегодня утром.

А вечером владелец уже спрашивает:

Почему Google меня не индексирует?

Обход и индексирование работают асинхронно.

Google предупреждает, что повторный crawl может занять от нескольких дней до нескольких недель и что запрос на индексирование не гарантирует немедленного включения страницы.

Яндекс также рекомендует проверить доступность страницы, Sitemap и внутренние ссылки, а затем использовать инструменты переобхода; если доступная и отправленная на переиндексацию страница долго не появляется, уже имеет смысл расследовать причину глубже.

Поэтому кнопка «Запросить индексирование» не является кнопкой «Добавить в Google»

Это запрос:

Посмотрите страницу ещё раз.

Не:

Обязаны включить её в индекс.

И отправлять один URL двадцать раз бесполезно

Google прямо отмечает, что повторная отправка одного и того же URL не ускоряет его crawl.

Гораздо полезнее исправить причину:

discovery;
content;
canonical;
rendering;
internal links.

Причина №16. Поисковая система выбрала другой URL

Представим статья доступна:

/expert/article

а также:

/expert/article/
/expert/article?utm_source=yandex
/expert/article?ref=telegram

Все возвращают одинаковый текст.

Поисковая система должна выбрать, какой URL считать основным.

Если сигналы противоречат друг другу

Например:

canonical → /expert/article

но:

sitemap → /expert/article/

а большинство ссылок ведут:

/expert/article?ref=...

мы сами создаём неопределённость.

Лучше нормализовать URL

Например:

/expert/article

— единственная основная версия.

Остальные:

redirect;
canonical;
параметры не создают отдельные документы.

Причина №17. Страница была в индексе, а потом исчезла

Это тоже возможно.

Индексирование не является пожизненным сертификатом.

Страница могла:

стать дублем;
получить noindex;
сменить canonical;
начать отдавать ошибку;
потерять содержимое;

или поисковик переоценил её необходимость в индексе.

Поэтому полезно различать

«никогда не индексировалась»

и:

«раньше индексировалась,
потом была исключена».

У второго сценария часто есть конкретное изменение во времени.

Очень полезен release history

Например:

10 сентября
→ canonical refactor

12 сентября
→ статьи начали выпадать

Это намного информативнее:

Google почему-то передумал.

Причина №18. Проблема массовая, а вы проверяете одну страницу

Если из индекса исчезла одна статья:

ищем проблему статьи.

Если:

300 статей

одновременно перестали нормально индексироваться:

ищем общий слой.

Например:

layout;
robots;
canonical generator;
SSR;
Nginx;
sitemap;

Массовая SEO-ошибка почти всегда интереснее одиночной

Одна опечатка:

1 URL.

Ошибка общего шаблона:

весь раздел.

Поэтому смотреть нужно не только страницу.

Но и паттерн проблемы.

Как диагностировать страницу последовательно

Вместо случайных действий:

переписать TITLE;
добавить keywords;
отправить на переобход;
ещё раз отправить на переобход;

лучше идти по цепочке.

Шаг 1. Проверяем реальный URL

Убедиться, что:

URL постоянный;
не требует login;
не является временным preview.

Шаг 2. Проверяем HTTP

Ожидаем:

200 OK

для индексируемой страницы.

Проверяем:

redirects;
403;
404;
500;
Content-Type.

Шаг 3. Проверяем robots.txt

Убедиться, что раздел не заблокирован.

Шаг 4. Проверяем meta robots и X-Robots-Tag

Ищем:

noindex;
none.

Шаг 5. Проверяем canonical

Для обычной уникальной статьи ожидаем self-canonical.

Например:

URL:
https://example.ru/expert/article

Canonical:
https://example.ru/expert/article

Шаг 6. Смотрим исходный HTML

Не только DevTools после полного выполнения приложения.

А именно то, что сервер отправляет первоначально.

Есть ли там:

TITLE;
H1;
основной текст;
canonical;
ссылки.

Шаг 7. Проверяем rendered HTML

Если сайт использует JavaScript, нужно понять:

Получает ли crawler тот же содержательный документ?

Google рекомендует для таких проверок URL Inspection и инструменты рендеринга, позволяющие увидеть итоговый DOM и JavaScript-проблемы.

Шаг 8. Проверяем sitemap

URL должен быть:

правильный;
canonical;
200;

и действительно присутствовать в актуальном Sitemap.

Шаг 9. Проверяем внутренние ссылки

Можно ли попасть на страницу:

с /expert;
из рубрики;
из связанных статей?

Или это orphan page?

Шаг 10. Проверяем уникальность и пользу

Если техника идеальна, вопрос меняется.

Не:

Что сломано?

А:

Почему поисковой системе нужен именно этот документ?

Например сравниваем две статьи

Первая:

Что такое API

API — это интерфейс взаимодействия
между программами...

На этом практически всё.

Вторая:

Почему timeout API
не означает отказ операции

и внутри:

сценарий потери response;
state machine;
idempotency;
reconciliation;
webhook race;
пример SQL constraint;
failure test.

Обе страницы технически индексируемы.

Но информационная ценность совершенно разная.

Именно поэтому SEO нельзя отделять от качества материала

Техническое SEO делает страницу:

доступной для поисковой системы.

Но не делает её:

обязательной для индекса.

Это разные задачи.

«У меня зелёные SEO-тесты, почему страницы всё равно нет?»

Потому что тесты проверяют:

корректно ли мы передаём сигналы.

Они не способны приказать поисковой системе:

сохранить этот документ.

Например SEO test подтверждает

HTTP 200 ✓

canonical ✓

noindex отсутствует ✓

sitemap ✓

H1 ✓

JSON-LD ✓

Это означает:

С нашей технической стороны не видно препятствия.

Но финальное решение об индексировании всё равно принимает поисковая система.

Это очень важное различие

SEO as Code предотвращает технические regression.

Но не заменяет:

содержательность;
оригинальность;
структуру сайта;
авторитетность;
реальную полезность.

Что означает «Discovered, но не индексируется»

Упрощённо:

Google знает URL

но ещё не дошёл до его полноценного crawl/indexing.

Причиной могут быть:

приоритет обхода;
огромное число URL;
нагрузка сервера;
слабая внутренняя связность;
общая оценка необходимости crawl.

Google отдельно отмечает, что при проблемах с crawl нужно проверять Sitemap, robots, crawl efficiency и способность сервера нормально обслуживать запросы Googlebot.

А «Crawled, но не индексируется» — уже другая ситуация

Это означает концептуально:

страницу получили
↓
посмотрели
↓
пока не выбрали для индекса.

Здесь бессмысленно бесконечно нажимать:

Request indexing.

Нужно исследовать:

дубли;
контент;
canonical;
ценность страницы;
качество раздела.

Что может происходить с новым сайтом

У нового домена ещё мало:

истории;
внешних ссылок;
понятных тематических связей;
накопленных crawl signals.

Поэтому ожидать:

опубликовал 100 статей
↓
завтра 100 в индексе

не стоит.

Поисковым системам нужно время, чтобы:

обнаружить структуру;
обойти страницы;
переоценить их;
понять связи сайта.

В такой ситуации особенно важнее качество, чем количество

Плохо:

1000 коротких SEO-страниц

созданных ради наполнения sitemap.

Лучше:

30–50 сильных взаимосвязанных материалов,

которые действительно раскрывают разные вопросы.

Внутренняя перелинковка должна быть смысловой

Не нужно механически ставить:

20 ссылок

на каждую статью.

Лучше:

В материале про background jobs естественно дать ссылку на SKIP LOCKED.

В статье про timeout — на idempotency.

В статье про API versioning — на мобильные клиенты и webhooks.

Так образуется настоящий тематический граф.

Поисковику проще понимать структуру

Например:

API и интеграции
│
├── Timeout внешнего API
├── Idempotency
├── Webhooks
├── Versioning
└── Background jobs

Это намного осмысленнее сотни несвязанных URL.

Не нужно путать индексирование и позиции

Допустим страница уже индексируется.

Но пользователь вводит:

разработка CRM

и не видит её в первых:

100 результатах.

Это не означает:

страницы нет в Google.

Она может быть в индексе, но не иметь достаточной релевантности или конкурентоспособности для данного запроса.

Индексирование отвечает на вопрос

Может ли страница участвовать в выдаче?

Ранжирование:

На какой позиции показать её по конкретному запросу?

Это принципиально разные этапы.

Поэтому сначала диагностируем индекс

И только потом:

семантику;
ссылки;
авторитетность;
CTR;
конкурентов;
позиции.

Особый случай: страница есть в Яндексе, но нет в Google

Это нормально.

У поисковых систем:

разные роботы;
разные очереди обхода;
разные системы рендеринга;
разные алгоритмы canonicalization;
разные критерии выбора документов.

Поэтому результат не обязан быть синхронным.

И обратная ситуация тоже нормальна

Google ✓
Yandex ✗

не обязательно указывает на техническую ошибку.

Сначала проверяем именно инструменты соответствующей поисковой системы.

Для Яндекса полезно смотреть статус URL

Yandex Webmaster показывает причины исключения вроде:

HTTP error;
noindex;
non-canonical;
alternate site address.

Это значительно полезнее, чем просто искать страницу вручную.

Для Google — URL Inspection

Он позволяет проверить:

известен ли URL;

какой canonical выбран;

что получил crawler;

как была отрендерена страница.

Особенно важен этот инструмент для JavaScript-сайтов.

Чего не стоит делать при проблеме индексирования

Не переписывать статью сразу без диагностики

Возможно проблема вообще:

noindex.

Не отправлять URL на индексирование десять раз

Google прямо говорит, что это не заставит crawler прийти быстрее.

Не добавлять ключевые слова в каждый абзац

Если проблема:

canonical → другая страница,

keyword density здесь ни при чём.

Не покупать случайные ссылки только ради «разбудить Google»

Сначала нужно убедиться, что сама страница технически здорова и действительно заслуживает отдельного документа.

Не создавать ещё десять почти одинаковых страниц

Если первая не индексируется из-за низкой самостоятельной ценности, масштабирование того же шаблона только увеличит проблему.

Не считать sitemap гарантией

И Google, и Yandex рассматривают Sitemap как важный способ обнаружения и указания предпочтительных URL, а не как приказ обязательно включить их в выдачу.

Как мы бы построили автоматическую проверку

Для каждого нового материала:

/article

автотест проверяет:

HTTP 200;
Content-Type text/html;
TITLE;
description;
один основной H1 по правилам шаблона;
self-canonical;
нет noindex;
JSON-LD валиден;
URL присутствует в sitemap;
URL не redirect;

После deployment:

real HTTP smoke test.

Но дальше нужен уже не тест, а наблюдение

Через Search Console и Яндекс Вебмастер смотрим:

обнаружен ли URL;
обошёл ли его робот;
какой canonical выбран;
есть ли исключение;

Получается два уровня

Автоматическая техническая проверка

Мы правильно построили страницу?

Search monitoring

Как поисковая система её обработала?

Один инструмент не заменяет другой

CI не знает решения Google.

Google Search Console не заменяет ваши production tests.

Вместе они дают значительно более точную картину.

Практический чек-лист: страница не попала в индекс

Проверяем по порядку:

1. URL действительно публичный и постоянный?
2. Есть ли на него нормальная внутренняя ссылка?
3. Присутствует ли URL в актуальном sitemap?
4. Возвращает ли он 200 OK?
5. Нет ли redirect?
6. Нет ли 403, 404, 5xx для crawler?
7. Правильный ли Content-Type?
8. Не закрыт ли URL в robots.txt?
9. Нет ли <meta name="robots" content="noindex">?
10. Нет ли X-Robots-Tag: noindex?
11. Куда указывает canonical?
12. Не выбрала ли поисковая система другой canonical?
13. Есть ли основной контент уже в server response?
14. Если используется JavaScript — появляется ли контент в rendered HTML?
15. Не требуется ли click, scroll, login или localStorage?
16. Не является ли страница почти полным дублем другой?
17. Есть ли у неё самостоятельная информационная ценность?
18. Не создал ли сайт тысячи малозначимых URL вокруг неё?
19. Не слишком ли глубоко она находится во внутренней структуре?
20. Не опубликована ли она совсем недавно?

И только после этого имеет смысл говорить:

Поисковая система почему-то не индексирует страницу.

Очень часто к этому моменту причина уже находится.

Самая полезная схема диагностики

                 URL существует?
                       │
                    нет│
                       ▼
                     FIX
                       │
                      да
                       ▼
              Робот знает URL?
                  /         \
                нет          да
                 │            │
      links + sitemap         ▼
                        HTTP доступен?
                         /         \
                       нет          да
                        │            │
                       FIX           ▼
                              robots/noindex?
                                /       \
                              да         нет
                               │          │
                              FIX         ▼
                                   canonical?
                                        │
                                        ▼
                                  content/render
                                        │
                                        ▼
                               duplicate/value?
                                        │
                                        ▼
                                  indexing decision

Эта последовательность помогает не лечить:

контент

когда проблема в:

HTTP,

и не переписывать:

Nginx

когда страница просто не имеет самостоятельной ценности.

Что особенно важно для динамической редакционной системы

Если статьи публикуются через CMS или собственный редакционный модуль, каждый материал должен автоматически проходить один и тот же pipeline:

Publish
↓
Public URL
↓
SSR/HTML
↓
Metadata
↓
Canonical
↓
JSON-LD
↓
Sitemap
↓
Internal listing
↓
Search notification/reindex mechanisms

Нельзя полагаться на:

Редактор после публикации вручную всё проверит.

На десятках и сотнях материалов это перестаёт масштабироваться.

В идеале публикация сама должна создавать все SEO-артефакты

Например новая статья:

Почему страница есть на сайте,
но её нет в Яндексе и Google

после публикации автоматически:

получает URL;

появляется в /expert;

получает canonical;

попадает в sitemap;

формирует Article JSON-LD;

становится доступной по HTTP 200.

А тесты подтверждают, что это действительно произошло.

Тогда человеческая проверка занимается содержанием

Не:

Не забыли ли canonical?

А:

Действительно ли статья полезна читателю?

Это намного правильнее использовать человеческое внимание.

Важный вывод о генераторах SEO-страниц

Сам факт возможности автоматически создать:

10 000 страниц

не означает, что нужно это делать.

Правильный генератор должен уметь отвечать не только:

Можем ли мы создать URL?

Но и:

Есть ли у этой страницы самостоятельный смысл?

Иначе технически идеальная система начинает производить индексный шум

canonical ✓
title ✓
H1 ✓
sitemap ✓
JSON-LD ✓

но:

содержательная ценность ≈ 0.

Поисковая система совершенно не обязана хранить такой документ.

Вместо вывода

Если страница открывается в браузере, это подтверждает только одну вещь:

пользователь с известным URL сейчас может её получить.

Это ещё не означает, что поисковая система:

знает URL;

обошла его;

смогла получить контент;

разрешила индексирование;

выбрала именно этот canonical;

посчитала страницу самостоятельной и полезной;

решила сохранить её в индексе.

Поэтому путь в поиск правильнее представлять не так:

Опубликовал
↓
Google

а так:

Опубликовал
       ↓
Discovery
       ↓
Crawling
       ↓
HTTP
       ↓
Rendering
       ↓
Indexability
       ↓
Canonicalization
       ↓
Content evaluation
       ↓
Index
       ↓
Ranking

Именно поэтому фраза:

«Страница есть, но её нет в Яндексе и Google»

сама по себе ещё почти ничего не говорит о причине.

Она только сообщает, на каком-то участке этой цепочки результат не дошёл до стадии поискового индекса.

Правильная работа начинается не с хаотичного изменения TITLE или повторной отправки Sitemap.

Она начинается с последовательной диагностики:

знает ли робот URL?
↓
может ли получить?
↓
что отвечает сервер?
↓
разрешена ли индексация?
↓
что указано canonical?
↓
виден ли основной контент?
↓
чем эта страница отличается от других?
↓
зачем поисковой системе хранить её отдельно?

И если техническая часть сайта построена качественно, большая часть первых вопросов должна проверяться автоматически.

Тогда SEO перестаёт быть мистикой:

«Почему поисковик меня не любит?»

и превращается в нормальную инженерную задачу:

на каком этапе обработки URL возникла проблема и какой сигнал мы передаём поисковой системе неправильно?