SEO и контент

Как поисковая система видит современный веб-сайт: путь страницы от HTTP-ответа до индекса

В браузере всё выглядит просто. Пользователь вводит адрес сайта, через доли секунды появляется интерфейс: заголовок, текст, изображения, меню, карточки, кнопки. Если страница визуально работает, возникает естественный вывод: поисковая система должна видеть примерно то же самое.

WebRuta · 05.10.2026 · 13 мин чтения

Но у поискового робота совсем другой путь.

Для него страница начинается не с дизайна и даже не с HTML. Сначала существует только URL. Затем идут проверка доступности, HTTP-запрос, ответ сервера, правила robots.txt, редиректы, HTML, метатеги, JavaScript, дополнительные сетевые запросы, рендеринг, извлечение ссылок, поиск дублей и только после этого — решение о том, достоин ли документ попадания в индекс.

Поэтому фразы:

«Страница открывается»

«Страница индексируется»

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

Более того, даже:

«Поисковый робот успешно загрузил страницу»

ещё не означает:

«Эта страница появится в поиске».

Google официально разделяет работу поиска на crawling, indexing и serving: сначала URL необходимо обнаружить и загрузить, затем содержимое анализируется и попадает — или не попадает — в индекс, и только после этого документ потенциально может участвовать в формировании поисковой выдачи. При этом Google отдельно предупреждает: корректная техническая реализация страницы сама по себе не гарантирует ни обход, ни индексирование, ни показ в результатах поиска.

Разберём весь путь современной страницы — от первого HTTP-запроса до поискового индекса.

Поисковая система сначала должна узнать, что URL вообще существует

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

Предположим, мы опубликовали новую статью:

https://example.ru/expert/http-indexing

Никакого универсального реестра новых страниц интернета не существует. Поисковой системе необходимо каким-то образом обнаружить этот URL.

Обычно это происходит через несколько каналов:

внутренняя ссылка
        │
        ├────► новый URL
        │
внешняя ссылка
        │
        ├────► новый URL
        │
Sitemap.xml
        │
        └────► новый URL

Поисковый робот может перейти на страницу с другой страницы сайта, обнаружить адрес во внешней ссылке или узнать о нём из Sitemap.

Это важное архитектурное различие:

Sitemap сообщает о существовании URL, но не помещает страницу в индекс.

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

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

страница есть в sitemap.xml
+
страницы нет в поиске

сама по себе не является ошибкой Sitemap.

Это только означает, что один из этапов discovery выполнен.

Дальше поисковой системе ещё предстоит решить, что делать с этим URL.

Следующий вопрос — разрешено ли роботу вообще заходить на страницу

Перед обходом сайта поисковая система учитывает robots.txt.

Например:

User-agent: *
Disallow: /admin/
Disallow: /private/

Это инструкция роботам не обходить указанные URL.

Здесь часто возникает одна из самых опасных путаниц в техническом SEO.

robots.txt и noindex решают разные задачи.

Упрощённо:

robots.txt
    ↓
можно ли роботу запрашивать URL?

noindex
    ↓
можно ли включать полученный документ в поиск?

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

/private/report

И одновременно две настройки:

robots.txt:
Disallow: /private/

и:

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

На первый взгляд защита двойная.

Но возникает противоречие.

Чтобы увидеть noindex, роботу сначала необходимо получить HTML страницы. А robots.txt как раз запрещает этот запрос.

Google прямо предупреждает: если URL закрыт в robots.txt, поисковый робот может не увидеть находящийся внутри страницы noindex. Более того, сам URL при определённых обстоятельствах всё ещё может появиться в результатах поиска, например если на него ведут ссылки с других ресурсов.

Яндекс описывает аналогичный принцип: для удаления страницы через noindex робот должен иметь возможность получить страницу и обнаружить это указание.

Поэтому robots.txt нельзя воспринимать как универсальную кнопку:

«Удалить страницу из поисковиков».

Это прежде всего инструмент управления обходом.

Поисковый робот делает обычный HTTP-запрос — и здесь уже многое может пойти не так

Предположим, URL разрешён.

Робот обращается к серверу:

GET /expert/http-indexing HTTP/1.1
Host: example.ru
User-Agent: ...

И получает ответ.

Например:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Для веб-разработчика это привычный уровень протокола.

Для поисковой системы HTTP-код является одним из фундаментальных сигналов о том, что произошло с ресурсом.

Очень упрощённо:

Ответ	Что он означает
`200 OK`	документ доступен
`301` / `308`	ресурс перенесён
`302` / `307`	временное перенаправление
`404 Not Found`	документ не найден
`410 Gone`	ресурс удалён
`403 Forbidden`	доступ запрещён
`429 Too Many Requests`	слишком много запросов
`5xx`	проблема на стороне сервера

Из-за этого красивой HTML-страницы недостаточно.

Можно создать страницу:

<h1>Статья не найдена</h1>
<p>Такого материала больше нет.</p>

но вернуть:

HTTP/1.1 200 OK

Для пользователя всё выглядит логично.

На уровне протокола сервер сообщает другое:

Всё хорошо. Здесь находится нормальный документ.

Так появляются так называемые soft 404.

Google отдельно рекомендует для действительно отсутствующих страниц возвращать корректный 404, а не только показывать визуальное сообщение об ошибке внутри документа с 200 OK.

Это хороший пример более общего принципа:

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

Первое представление страницы — HTML, который вернул сервер

Теперь предположим, что сервер корректно ответил:

200 OK

Он может вернуть практически готовый документ:

<html>
<head>
  <title>Как работает индексирование сайта</title>
  <meta
    name="description"
    content="Разбираем путь страницы от HTTP-ответа до поискового индекса."
  >
  <link
    rel="canonical"
    href="https://example.ru/expert/http-indexing"
  >
</head>

<body>
  <main>
    <h1>Как поисковая система видит современный веб-сайт</h1>
    <p>В браузере всё выглядит просто...</p>
  </main>
</body>
</html>

Но современное веб-приложение может вернуть совсем другое:

<html>
<head>
  <title>Example</title>
</head>

<body>
  <div id="root"></div>
  <script src="/assets/app.js"></script>
</body>
</html>

Второй вариант — типичный app shell.

В исходном HTML практически нет содержимого страницы.

Заголовок статьи, текст, навигация, ссылки и метаданные появятся только после выполнения JavaScript.

Для обычного браузера это может быть совершенно нормально.

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

Нужно:

получить HTML
       ↓
получить JavaScript
       ↓
выполнить JavaScript
       ↓
возможно вызвать API
       ↓
дождаться ответа API
       ↓
создать DOM
       ↓
только теперь увидеть статью

Именно поэтому вопрос:

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

слишком упрощён.

Да, Google выполняет JavaScript. Но правильный вопрос звучит иначе:

«Насколько надёжно поисковый робот сможет пройти весь путь от первоначального HTML до критически важного содержимого конкретного приложения?»

Crawling и rendering — не одно и то же

Для классической серверной страницы основное содержимое уже приходит в HTTP-ответе.

Схема короткая:

GET /article
      ↓
HTML
      ↓
текст уже существует

При client-side rendering:

GET /article
      ↓
HTML shell
      ↓
JavaScript
      ↓
API
      ↓
DOM

Google описывает обработку JavaScript-приложения тремя основными фазами:

Crawling
   ↓
Rendering
   ↓
Indexing

При этом HTML сначала анализируется как обычный документ. Для JavaScript-зависимых страниц Google затем использует Web Rendering Service на базе Chromium, выполняет JavaScript и повторно анализирует уже отрендеренный HTML.

Яндекс также умеет обрабатывать JavaScript-страницы и предоставляет в Вебмастере отдельные средства управления и проверки JavaScript rendering. При этом Яндекс прямо отмечает, что SSR или пререндеринг могут избавить робота от необходимости выполнять JavaScript для получения основного содержимого.

Из этого не следует:

CSR нельзя использовать для SEO.

Такое утверждение давно слишком категорично.

Правильный вывод другой:

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

Почему SSR часто проще для поискового робота

Представим две реализации одной статьи.

CSR

Первичный ответ:

<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>

После выполнения приложения:

<body>
  <div id="root">
    <article>
      <h1>Как работает индексирование</h1>
      <p>...</p>
    </article>
  </div>
</body>

SSR

Первичный ответ:

<body>
  <article>
    <h1>Как работает индексирование</h1>
    <p>...</p>
  </article>

  <script src="/bundle.js"></script>
</body>

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

Но во втором случае критическое содержимое доступно сразу после HTTP-запроса.

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

Именно в этом заключается одно из главных SEO-преимуществ SSR.

Не:

SSR каким-то образом автоматически повышает позиции.

А:

SSR уменьшает количество технических зависимостей между HTTP-запросом и доступностью основного содержимого страницы.

Это совершенно разные утверждения.

JavaScript может загрузиться, но контент всё равно останется невидимым

Представим React-приложение:

useEffect(() => {
  fetch("/api/article/127")
    .then(response => response.json())
    .then(article => setArticle(article));
}, []);

Чтобы робот увидел статью, необходима цепочка:

HTML доступен
   ↓
JS-файл доступен
   ↓
JS успешно выполняется
   ↓
API доступно
   ↓
API отвечает достаточно быстро
   ↓
ответ корректен
   ↓
компонент успешно рендерится

Теперь достаточно одной ошибки:

/api/article/127 → 500

И поисковой робот может получить:

<div id="root">
  <div class="loading">Загрузка...</div>
</div>

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

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

Это одна из причин, почему SEO современной веб-системы нельзя проверять только так:

Открыл Chrome — всё отображается.

Даже успешный render ещё не означает индексирование

Допустим, робот:

нашёл URL;
получил 200 OK;
скачал JavaScript;
выполнил приложение;
получил всю статью.

Кажется, задача закончена.

На самом деле именно теперь начинается один из наиболее важных этапов — indexing.

Поисковая система пытается понять документ.

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

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

отрендерированный документ
        ↓
основной контент
        ↓
title / headings
        ↓
ссылки
        ↓
изображения и alt
        ↓
структурированные данные
        ↓
язык и тематика
        ↓
дублирование
        ↓
canonicalization
        ↓
решение об индексировании

Поэтому между состояниями:

Crawled

и:

Indexed

существует принципиальная разница.

Canonical: ещё одна стадия, о которой часто забывают

Современная страница редко существует только по одному URL.

Например:

/product/notebook
/product/notebook?utm_source=ads
/product/notebook?sort=price
/product/notebook?ref=homepage

Иногда разные адреса возвращают одинаковое или почти одинаковое содержимое.

Поисковой системе нет смысла хранить все эти версии как независимые документы.

Поэтому применяется canonicalization — выбор представительной версии страницы.

В HTML сайт может сообщить предпочитаемый URL:

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

Но важно понимать природу этого механизма.

canonical — это не безусловная команда:

Индексируй именно этот URL и никакой другой.

Google рассматривает rel="canonical" как сильный сигнал, но в конечном счёте может выбрать другую каноническую версию. Среди других сигналов учитываются, например, редиректы и Sitemap.

Яндекс также прямо указывает, что rel="canonical" является рекомендацией и в некоторых ситуациях может быть проигнорирован.

Это объясняет ситуацию, которая иногда удивляет владельца сайта:

мой canonical:
URL A

canonical, выбранный поисковой системой:
URL B

Это не обязательно баг поисковика.

Иногда сам сайт передаёт противоречивые сигналы.

Например:

canonical → A
Sitemap → B
внутренние ссылки → B
301 → B

А затем разработчик пытается выяснить, почему поисковик не выбрал A.

Согласованность сигналов важнее количества SEO-тегов

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

Например:

URL:
https://example.ru/expert/http-indexing

self canonical:
https://example.ru/expert/http-indexing

Sitemap:
https://example.ru/expert/http-indexing

внутренние ссылки:
https://example.ru/expert/http-indexing

Сигналы согласованы.

Проблемная архитектура:

страница открывается:
 /article?id=127

canonical:
 /expert/http-indexing

Sitemap:
 /blog/http-indexing/

меню:
 /articles/http-indexing

Все варианты могут вести к одному содержимому.

Но поисковой системе сначала приходится разбираться, что именно разработчики считают настоящим документом.

SEO здесь становится не задачей написания meta description, а задачей согласованного проектирования URL.

`noindex` проверяется уже внутри доступного документа

Если сервер возвращает:

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

страница сообщает:

Не включать этот документ в индекс.

Google поддерживает такую инструкцию как в HTML, так и в HTTP-заголовке X-Robots-Tag. Но чтобы инструкция сработала, поисковый робот должен иметь возможность получить ресурс.

Например:

HTTP/1.1 200 OK
X-Robots-Tag: noindex
Content-Type: application/pdf

Так можно управлять индексированием даже ресурсов, у которых вообще нет HTML <head>.

Это полезный пример того, почему SEO нельзя ограничивать frontend-разметкой.

Часть поисковых инструкций живёт непосредственно на HTTP-уровне.

Как робот обнаруживает следующие страницы

После обработки страницы поисковой системе нужны новые URL.

Один из основных источников — ссылки.

Надёжная обычная ссылка выглядит так:

<a href="/expert/next-article">
  Следующая статья
</a>

URL явно присутствует в документе.

Но современный frontend иногда делает:

<div onclick="navigate('/expert/next-article')">
  Следующая статья
</div>

Для пользователя визуальный результат похож.

Семантически это уже не обычная ссылка.

Особенно опасна архитектура, когда адрес вообще генерируется только после пользовательского действия:

клик
 ↓
JavaScript
 ↓
запрос
 ↓
получение ID
 ↓
формирование URL

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

Именно поэтому хорошая внутренняя перелинковка — это не только «передача SEO-веса».

Это ещё и механизм обнаружения документов.

Sitemap и ссылки решают разные задачи

Рассмотрим статью, которая:

есть в Sitemap

но:

ни одна страница сайта на неё не ссылается

Поисковик может узнать URL из Sitemap.

Но с архитектурной точки зрения возникает вопрос:

Если сама структура сайта никак не связывает эту страницу с другими материалами, насколько важна она для сайта?

Теперь обратный вариант:

статья имеет ссылки
из рубрики
из других статей
из страницы услуги
из блока рекомендаций

Сайт уже описывает её место в собственной информационной архитектуре.

Поэтому Sitemap не является заменой внутренней навигации.

Это дополнительный канал discovery.

Поисковый робот видит не дизайн, а структуру документа

Для человека:

большой шрифт
градиент
анимация
карточка
иконка
отступ

имеют огромное значение для восприятия интерфейса.

Для поисковой системы особенно важна семантическая структура.

Например:

<main>
  <article>
    <h1>Как работает индексирование сайта</h1>

    <p>...</p>

    <h2>Как робот получает страницу</h2>
    <p>...</p>

    <h2>Что происходит после рендеринга</h2>
    <p>...</p>
  </article>
</main>

Здесь довольно понятно:

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

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

Это не означает, что наличие правильного <h1> автоматически повышает страницу в топ.

Смысл другой:

семантический HTML уменьшает неоднозначность документа.

Структурированные данные — дополнительное описание, а не замена контента

Для статьи можно добавить JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Как поисковая система видит современный веб-сайт",
  "datePublished": "2026-10-04",
  "author": {
    "@type": "Organization",
    "name": "Example"
  }
}

Это помогает машине интерпретировать сущности и свойства документа.

Но Structured Data не превращает пустую страницу в качественную статью.

Если основной HTML содержит:

три абзаца шаблонного текста

то большой JSON-LD не создаёт вместо него хороший документ.

Разметка описывает содержимое.

Она не должна подменять его.

Что происходит с дубликатами

Представим интернет-магазин:

/catalog/notebook
/catalog/notebook?page=1
/catalog/notebook?sort=asc
/catalog/notebook?sort=desc
/catalog/notebook?utm_source=yandex

Поисковая система может решить, что несколько URL представляют один и тот же основной документ.

Google описывает этот процесс как clustering: похожие страницы объединяются, после чего выбирается наиболее подходящая canonical-версия.

Это важно потому, что разработчик часто думает категориями URL:

у меня пять адресов
=
у меня пять страниц

Поисковая система думает категориями содержания:

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

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

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

Допустим, технически две страницы реализованы одинаково.

Обе:

200 OK
разрешены robots.txt
без noindex
имеют canonical
есть в Sitemap
SSR

Но одна индексируется, другая — нет.

Это не противоречие.

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

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

Поэтому существует важное различие:

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

и:

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

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

Второе — уже качеством, уникальностью и полезностью документа в контексте поискового индекса.

Пример полного пути одной статьи

Теперь соберём всё вместе.

Редактор публикует:

https://example.ru/expert/http-indexing

CMS сохраняет материал.

1. Формируется URL

/expert/http-indexing

2. На статью появляется ссылка

Например, на странице:

/expert

3. URL добавляется в Sitemap

<url>
  <loc>https://example.ru/expert/http-indexing</loc>
</url>

4. Робот узнаёт URL

Через ссылку, Sitemap или другой источник.

5. Проверяется возможность обхода

В robots.txt нет запрета:

Disallow: /expert/

6. Выполняется HTTP-запрос

Сервер возвращает:

HTTP/1.1 200 OK

7. Приходит серверный HTML

В нём уже есть:

<title>...</title>

<meta name="description" content="...">

<link rel="canonical" href="...">

<h1>...</h1>

<article>...</article>

8. Загружаются необходимые ресурсы

CSS, JavaScript, изображения.

Если страница использует hydration, интерактивность подключается после первоначального HTML.

9. Поисковик анализирует документ

Определяются:

основное содержание
заголовок
ссылки
изображения
метаданные
структурированные данные
язык
тематика

10. Выполняется canonicalization

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

11. Принимается решение об индексации

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

Получается:

URL создан
     ↓
URL обнаружен
     ↓
разрешён обход
     ↓
HTTP-запрос
     ↓
HTTP-ответ
     ↓
HTML
     ↓
JavaScript / Rendering
     ↓
содержимое
     ↓
метаданные
     ↓
canonicalization
     ↓
indexing decision
     ↓
INDEX

Любая проблема на промежуточном этапе способна изменить результат.

Почему «у меня всё работает» ничего не говорит об индексировании

Рассмотрим четыре страницы.

Страница A

Browser: работает
HTTP: 200
robots: allow
HTML: полный
Index: да

Нормальное состояние.

Страница B

Browser: работает
HTTP: 200
robots: allow
HTML: meta noindex
Index: нет

Для пользователя всё прекрасно.

Поисковая инструкция запрещает индексирование.

Страница C

Browser: работает
HTTP: 200
robots: allow
HTML: пустой app shell
JS API: ошибка для bot
Index: проблема

Разработчик вручную может вообще не увидеть дефект.

Страница D

Browser: показывает «Страница не найдена»
HTTP: 200
Index: soft 404

Визуально всё корректно.

Протокольно — нет.

Поэтому качественный SEO-аудит веб-продукта должен проходить несколько уровней.

Первый уровень проверки — HTTP

Не нужно начинать с огромного SEO-сервиса.

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

curl -I https://example.ru/expert/http-indexing

Например:

HTTP/2 200
content-type: text/html; charset=utf-8

Следующий вопрос:

curl -L https://example.ru/expert/http-indexing

Что действительно находится в HTML?

Есть ли:

H1?
основной текст?
canonical?
robots?
title?
description?

Если curl получает почти пустой shell:

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

а весь контент появляется только после JavaScript, это уже важная характеристика архитектуры страницы.

Не обязательно ошибка.

Но это нужно знать.

Второй уровень — rendered DOM

Далее необходимо сравнить:

server HTML

и:

rendered HTML

Если они radically различаются:

Server:
2 КБ shell

Rendered:
180 КБ контента

значит, поисковая доступность страницы существенно зависит от rendering pipeline.

Тогда особенно важно проверять:

доступность JS;
доступность API;
ошибки runtime;
скорость загрузки;
контент после render;
canonical после render;
title после render.

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

Третий уровень — глазами самого поискового робота

Это значительно важнее проверки обычным Chrome.

Google Search Console предоставляет URL Inspection.

Яндекс Вебмастер — проверку страницы и средства анализа JavaScript rendering.

Яндекс прямо позволяет сравнивать доступное роботу содержимое и проверять, попадает ли необходимый JavaScript-контент в обрабатываемую версию страницы.

Это уже ответ не на вопрос:

Что вижу я?

А на гораздо более полезный:

Что получила поисковая система?

Четвёртый уровень — что реально находится в индексе

Даже после успешной технической проверки работа не заканчивается.

Необходимо посмотреть:

страница проиндексирована?

Если нет:

почему?

Возможные причины находятся на разных уровнях:

URL не обнаружен;
robots.txt;
noindex;
HTTP-ошибка;
редирект;
soft 404;
проблема rendering;
дубликат;
другой canonical;
недостаточная ценность страницы;
страница ещё не обработана.

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

«SEO не работает»

практически бесполезна для диагностики.

Нужно установить, на каком этапе pipeline находится URL.

Архитектурная ошибка: SEO добавляют после разработки

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

сначала разрабатываем приложение
        ↓
запускаем production
        ↓
потом зовём SEO-специалиста
        ↓
«добавьте SEO»

Но что означает «добавить SEO», если уже принято решение, что:

все публичные страницы работают только через CSR;
URL генерируются динамически;
часть страниц невозможно открыть прямой ссылкой;
ошибочные маршруты возвращают 200;
title одинаковый на всём приложении;
canonical формируется после API-запроса;
контент существует только после авторизации;
нет серверного Sitemap;
удалённые страницы продолжают отдавать 200?

Это уже не настройка метатегов.

Это архитектура.

И её исправление может потребовать изменений маршрутизации, backend, frontend, CMS и deployment pipeline.

Хорошая SEO-архитектура делает публичную страницу предсказуемой

Для индексируемого документа полезна простая модель:

GET URL
   ↓
предсказуемый HTTP status
   ↓
понятный HTML
   ↓
основное содержимое доступно
   ↓
однозначный canonical
   ↓
корректная индексационная политика

Например:

GET /expert/http-indexing

возвращает сразу:

<title>
  Как поисковая система видит современный веб-сайт
</title>

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

<meta name="robots" content="index,follow">

<main>
  <article>
    <h1>
      Как поисковая система видит современный веб-сайт
    </h1>

    ...
  </article>
</main>

JavaScript при этом никто не запрещает.

Он может обеспечивать:

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

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

Что поисковик видит первым: сервер или красивый интерфейс?

Сервер.

Это, пожалуй, главное изменение мышления, необходимое при разработке индексируемого веб-продукта.

Разработчик frontend обычно думает:

Component
→ DOM
→ pixels

Backend-разработчик:

request
→ business logic
→ response

А поисковая система проходит практически через всю цепочку:

URL
↓
robots
↓
network
↓
HTTP
↓
HTML
↓
resources
↓
JavaScript
↓
DOM
↓
content
↓
links
↓
canonicalization
↓
index

SEO современного веб-приложения поэтому находится не только в <head>.

Оно проходит через всю архитектуру публичной части продукта.

Несколько распространённых мифов

«Если страница есть в Sitemap — она будет проиндексирована»

Нет.

Sitemap помогает обнаружить URL.

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

«Если страница отдаёт 200 — всё хорошо»

Нет.

Она может содержать:

noindex;
ошибку приложения;
пустой контент;
soft 404;
дублирующий материал;
неправильный canonical.

200 означает только успешный HTTP-ответ.

«Если Google выполняет JavaScript, SSR больше не нужен»

Тоже нет.

Google действительно выполняет JavaScript, но SSR и pre-rendering уменьшают количество промежуточных условий, необходимых для получения основного документа. Google сам отмечает, что server-side и pre-rendering остаются полезными, в том числе потому, что не каждый бот выполняет JavaScript.

«robots.txt удаляет страницу из Google»

Не обязательно.

Robots.txt прежде всего управляет crawling. Заблокированный URL всё ещё может быть известен поисковой системе.

«canonical гарантирует, какой URL будет в поиске»

Нет.

Это сильный сигнал, но окончательное решение о canonical-версии принимает поисковая система.

«Если поисковик страницу скачал, она уже проиндексирована»

Нет.

Crawling и indexing — разные этапы.

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

Почему робот заходил вчера, а страницы всё ещё нет в поиске?

Индексацию полезно воспринимать как pipeline

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

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

DISCOVERY
   │
   ▼
CRAWLING
   │
   ▼
HTTP
   │
   ▼
PARSING
   │
   ▼
RENDERING
   │
   ▼
CONTENT EXTRACTION
   │
   ▼
CANONICALIZATION
   │
   ▼
INDEXING
   │
   ▼
SERVING

Тогда для любой проблемы можно поставить конкретный вопрос.

Не:

Почему SEO плохое?

А:

URL обнаружен?

Если да:

Робот может его обходить?

Если да:

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

Если корректный:

Что находится в server HTML?

Дальше:

Что появляется после rendering?

Потом:

Нет ли noindex?

Затем:

Какой canonical выбран?

И только после этого:

Почему документ не включён в индекс?

Так SEO превращается из набора мистических рекомендаций в обычную инженерную диагностику.

Вместо заключения

Современный сайт для пользователя и современный сайт для поисковой системы — это не два разных продукта.

Но способы их восприятия различаются.

Человек начинает с экрана.

Поисковый робот начинает с URL.

Дальше он проходит последовательность технических состояний:

нашёл адрес
→ получил разрешение на обход
→ обратился к серверу
→ получил HTTP-ответ
→ разобрал HTML
→ при необходимости выполнил JavaScript
→ получил итоговое содержимое
→ обнаружил ссылки
→ проанализировал документ
→ сопоставил его с похожими страницами
→ определил canonical
→ принял решение об индексировании

Именно поэтому SEO сложного веб-продукта нельзя свести к заполнению title, description и Sitemap.

Если сервер отдаёт неправильный HTTP-код, метатеги не спасут страницу.

Если важный контент недоступен при rendering, хороший текст может остаться невидимым.

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

Если робот не может открыть страницу, он не увидит находящийся в ней noindex.

А присутствие URL в Sitemap говорит лишь о том, что поисковой системе сообщили о его существовании.

Поэтому техническое SEO начинается гораздо раньше поисковых запросов и ключевых слов.

Оно начинается в тот момент, когда разработчик решает:

какой URL будет у страницы;
какой HTTP-код она вернёт;
что окажется в первоначальном HTML;
потребуется ли JavaScript для основного контента;
как будут устроены ссылки;
что произойдёт при удалении документа;
какая версия URL станет канонической.

Если эти решения приняты правильно, поисковая система получает понятную и предсказуемую структуру.

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

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

Красиво ли она выглядит?

и даже не:

Есть ли на ней SEO-теги?

А:

Что именно получит поисковый робот, если прямо сейчас запросит этот URL с нуля?

Ответ на этот вопрос часто говорит о техническом состоянии SEO больше, чем десятки автоматических аудитов.

Есть похожая задача?

Опишите продукт, интеграции и ограничения. До разработки зафиксируем объём, риски и критерии приёмки.

Обсудить проект →

Как поисковая система видит современный веб-сайт: путь страницы от HTTP-ответа до индекса

Поисковая система сначала должна узнать, что URL вообще существует

Следующий вопрос — разрешено ли роботу вообще заходить на страницу

Поисковый робот делает обычный HTTP-запрос — и здесь уже многое может пойти не так

Первое представление страницы — HTML, который вернул сервер

Crawling и rendering — не одно и то же

Почему SSR часто проще для поискового робота

CSR

SSR

JavaScript может загрузиться, но контент всё равно останется невидимым

Даже успешный render ещё не означает индексирование

Canonical: ещё одна стадия, о которой часто забывают

Согласованность сигналов важнее количества SEO-тегов

noindex проверяется уже внутри доступного документа

Как робот обнаруживает следующие страницы

Sitemap и ссылки решают разные задачи

Поисковый робот видит не дизайн, а структуру документа

Структурированные данные — дополнительное описание, а не замена контента

Что происходит с дубликатами

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

Пример полного пути одной статьи

1. Формируется URL

2. На статью появляется ссылка

3. URL добавляется в Sitemap

4. Робот узнаёт URL

5. Проверяется возможность обхода

6. Выполняется HTTP-запрос

7. Приходит серверный HTML

8. Загружаются необходимые ресурсы

9. Поисковик анализирует документ

10. Выполняется canonicalization

11. Принимается решение об индексации

Почему «у меня всё работает» ничего не говорит об индексировании

Страница A

Страница B

Страница C

Страница D

Первый уровень проверки — HTTP

Второй уровень — rendered DOM

Третий уровень — глазами самого поискового робота

Четвёртый уровень — что реально находится в индексе

Архитектурная ошибка: SEO добавляют после разработки

Хорошая SEO-архитектура делает публичную страницу предсказуемой

Что поисковик видит первым: сервер или красивый интерфейс?

Несколько распространённых мифов

«Если страница есть в Sitemap — она будет проиндексирована»

«Если страница отдаёт 200 — всё хорошо»

«Если Google выполняет JavaScript, SSR больше не нужен»

«robots.txt удаляет страницу из Google»

«canonical гарантирует, какой URL будет в поиске»

«Если поисковик страницу скачал, она уже проиндексирована»

Индексацию полезно воспринимать как pipeline

Вместо заключения

Есть похожая задача?

`noindex` проверяется уже внутри доступного документа