- -
- 100%
- +
Не только Google
Отдельная тема, которую легко упустить из виду, если думать только о позициях в Google, — остальные потребители контента сайта. Bing также развивал возможности обработки JavaScript, но эти возможности не полностью совпадают с возможностями Google. Нет оснований считать, что если сайт хорошо индексируется в одной системе, то так же будет в другой без отдельной проверки. А у других поисковых и AI-систем архитектура обхода может отличаться от Google ещё сильнее. Поэтому корректно индексируемый Google JavaScript-сайт не стоит автоматически считать одинаково доступным для всех остальных краулеров — особенно осторожно стоит относиться к системам, для которых приоритетны быстрый массовый сбор и предварительная обработка контента. Подробно развивать здесь эту тему я не буду — она уже выходит за рамки классического поиска и связана в том числе с генеративным поиском, и заслуживает отдельного, доказательного разговора в другой книге. Но для полноты картины важно проговорить: техническая база, о которой эта книга, не заканчивается на одном Googlebot, даже если именно на нём чаще всего сосредоточено внимание.
Что из этого следует
Разрыв, о котором шла речь в прошлой главе, действительно сузился — Google в 2026 году заметно лучше справляется с современным вебом, чем в начале 2010-х, и это видно не только из официальной документации, но и из практики. Но он не закрылся и, судя по тому, как устроена сама архитектура — с очередью, зависимостью от доступных ресурсов, статус-кодов и управляющих директив, — вряд ли закроется полностью: слишком много условий должно выполняться одновременно, чтобы можно было гарантировать одинаково полный результат рендеринга для каждой страницы.
Это совсем не значит, что JavaScript нужно избегать. Современный веб уже устроен иначе, и клиентский код стал нормальной частью большинства сложных сайтов. Вопрос в другом: насколько критичен для сайта результат выполнения этого кода поисковой системой.
Если поисковая система должна выполнить несколько скриптов, загрузить дополнительные ресурсы, дождаться запросов к API и только после этого получить основной контент страницы, SEO начинает зависеть от всей этой цепочки. Чем она сложнее, тем больше в ней точек, в которых результат может отличаться от того, что увидел пользователь.
Поэтому выбор архитектуры рендеринга имеет прямое отношение к SEO. Не потому, что одна модель сама по себе «хороша для SEO», а другая «плоха», а потому, что разные модели по-разному распределяют работу между сервером, браузером и поисковой системой. И это уже нужно учитывать при проектировании сайта, а не пытаться исправить после его запуска. Какие архитектурные модели рендеринга возникли в ответ на эту проблему и что каждая из них меняет в отношениях сайта с поисковой системой, разберём в следующей главе.
Глава 4. Рендеринг как часть SEO-архитектуры
Один и тот же интернет-магазин можно устроить по-разному. В одном случае сервер сразу отдаёт готовый HTML. В другом браузер получает минимальную оболочку и формирует страницу сам. Можно заранее подготовить HTML для всех нужных страниц во время сборки сайта, а можно сочетать эти подходы и обновлять отдельные страницы по мере изменения данных.
Для пользователя разница между этими вариантами часто почти незаметна. Он открывает карточку товара, видит название, цену и фотографии, нажимает «В корзину» и продолжает работу с сайтом. Для поисковой системы разница принципиальная: в зависимости от архитектуры она может получить готовый документ сразу или сначала получить только его основу, а затем потратить дополнительные ресурсы на то, чтобы сформировать итоговое содержимое.
Поэтому вопрос рендеринга для SEO заключается не в выборе «правильного» фреймворка и даже не в том, нужно ли использовать JavaScript. Гораздо важнее другое: на каком этапе обработки страницы поисковая система получает тот HTML и то содержимое, которые мы хотим видеть в поиске.
От ответа на этот вопрос зависит, насколько сайт будет зависеть от выполнения JavaScript, доступности дополнительных ресурсов, времени обработки и других условий, которые находятся уже не на стороне самого HTML-документа. Поэтому рендеринг стоит рассматривать как часть SEO-архитектуры сайта. Причём решение может быть разным для разных типов страниц и даже для разных частей одной страницы.
Начнём с самого зависимого от браузера варианта.
SSR: документ появляется на сервере
Рендеринг на стороне сервера (server-side rendering, SSR) переносит формирование HTML на сервер: при обращении к странице сервер получает необходимые данные, собирает HTML и отдаёт его уже с основным содержимым. Для поисковой системы это принципиальная разница: уже на первом этапе обработки она получает содержательный HTML, а не минимальную оболочку, которую ещё предстоит собрать с помощью JavaScript.
У этой модели есть и обратная сторона, о которой при разговоре об SEO говорят заметно реже. HTML приходится формировать при обращении к странице. Серверу нужно получить данные, собрать разметку и отправить результат пользователю или поисковому роботу. Если таких запросов много, нагрузка быстро становится существенной: поисковые роботы могут последовательно запрашивать тысячи и десятки тысяч страниц. Поэтому на практике SSR часто требует продуманного кэширования на сервере или CDN, иначе одни и те же страницы приходится заново формировать при каждом обращении.
Есть и вопрос скорости ответа. Само по себе наличие готового HTML ещё не означает, что страница будет быстро получена: если сервер долго формирует документ или ждёт данные из нескольких источников, преимущество SSR частично теряется. Для SEO это важно не потому, что поисковая система ставит отдельный «балл за SSR», а потому, что скорость ответа влияет и на пользовательский опыт, и на эффективность обхода сайта.
При этом SSR не превращает сайт автоматически в хорошо оптимизированный. Он решает одну конкретную задачу: позволяет отдать основное содержимое уже в первоначальном HTML. Но остаются дублирующиеся URL, ошибки в canonical, проблемы с перелинковкой, слабый или нерелевантный контент и множество других факторов.
Поэтому было бы ошибкой противопоставлять хорошо реализованный SSR любому варианту клиентского рендеринга. Сайт на SSR с плохо устроенной архитектурой может работать хуже для поиска, чем аккуратно спроектированный сайт на CSR с предварительным рендерингом. Модель рендеринга задаёт условия, в которых работает SEO, но сама по себе его не определяет.
SSG: документ появляется до запроса
Статическая генерация страниц (static site generation, SSG) формирует HTML заранее, во время сборки сайта, а не в момент обращения к странице. В результате получается набор готовых файлов, которые можно отдавать пользователям напрямую, в том числе через CDN, без обращения к серверу приложения при каждом запросе. Это позволяет добиться высокой скорости ответа и существенно снизить нагрузку на серверную инфраструктуру.
SSG особенно хорошо подходит для сайтов, где содержимое страниц меняется относительно редко: блогов, документации, справочных разделов, каталогов со стабильными данными. Все необходимые данные известны на момент сборки, поэтому основной контент, метаданные, canonical и структурированные данные уже присутствуют в готовом HTML. Поисковой системе не нужно ждать отдельного этапа рендеринга, чтобы получить это содержимое.
Главное ограничение SSG становится заметно там, где данные меняются часто. Например, каталог из ста тысяч товаров с ценами и остатками, которые обновляются несколько раз в день, трудно поддерживать в актуальном состоянии при чистом SSG. Если запускать полную пересборку после каждого изменения, это быстро становится слишком затратным. Если же собирать сайт реже, часть страниц какое-то время будет содержать устаревшие данные.
Та же проблема возникает с содержимым, которое зависит от конкретного пользователя. Персональные рекомендации, данные авторизованного пользователя или другие индивидуальные элементы нельзя заранее собрать в одной общей версии страницы. SSG хорошо работает там, где страницу можно подготовить заранее и отдавать одинаковой или почти одинаковой для всех посетителей.
ISR: документ появляется заранее, но может обновляться
Именно из этого ограничения выросла модель, которую Next. js представил в 2020 году под названием инкрементальная регенерация статических страниц (incremental static regeneration, ISR). Её идея проста: страница по-прежнему формируется как статическая, но уже не обязательно один раз при полной сборке сайта. Отдельную страницу можно заново сформировать после истечения заданного времени или по внешнему событию, не пересобирая при этом весь сайт. Для большого каталога это существенно меняет экономику обновлений: изменение данных одной страницы не требует заново формировать тысячи остальных.
При этом пользователь обычно получает уже подготовленную версию страницы. Обновление может происходить отдельно от его запроса, поэтому актуализация данных не обязательно должна увеличивать время ответа.
Для SEO эта модель важна прежде всего тем, что позволяет сочетать два свойства. Как и при SSG, поисковая система получает готовый HTML без необходимости сначала выполнять JavaScript. Но содержимое страницы при этом можно регулярно обновлять без полной пересборки сайта.
Именно такие модели постепенно разрушили простое противопоставление «SSR против CSR», которое долго использовалось для описания архитектуры веб-приложений. На практике один сайт может использовать разные способы формирования страниц в зависимости от того, насколько часто меняются данные, насколько важна скорость ответа и требуется ли персонализация.
Поэтому вопрос уже не в том, какую модель выбрать для сайта целиком. Гораздо важнее определить, какая модель подходит каждому типу страниц и какие части страницы действительно должны формироваться на сервере, заранее или в браузере.
Гибридная архитектура: рендеринг как свойство страницы, а не сайта
Один и тот же сайт сегодня может использовать несколько моделей рендеринга одновременно. Например, статьи блога удобно заранее формировать при сборке сайта с помощью SSG, карточки товаров обновлять через ISR, а персонализированные разделы отдавать с сервера. Для отдельных интерактивных элементов, содержание которых не имеет значения для поиска, вполне достаточно CSR.
Причём разные модели могут использоваться не только для разных типов страниц, но и внутри одной страницы. Основной текст карточки товара может быть сформирован на сервере и попасть в HTML сразу, а блок рекомендаций загрузиться в браузере после открытия страницы. Для пользователя это одна страница, но с точки зрения её формирования в ней участвуют разные механизмы.
Поэтому сегодня уже не совсем правильно говорить, что сайт работает на CSR, SSR или SSG. Правильнее смотреть на конкретную страницу и на отдельные части её содержимого. Для SEO это особенно важно: далеко не весь JavaScript на странице представляет одинаковую ценность. Одно дело, когда в браузере появляется дополнительная кнопка или интерактивный фильтр, и совсем другое, когда только после выполнения JavaScript становится доступен основной текст, цена товара или список категорий.
Именно поэтому выбор модели рендеринга стоит рассматривать как часть архитектуры конкретного контента. Чем важнее элемент для поискового трафика, тем меньше оснований оставлять его появление исключительно на усмотрение браузера и последующего рендеринга поисковой системой.
Что SEO действительно должно знать о рендеринге
Из всего сказанного следует практический вывод. Он не сводится к совету «используйте SSR»: такой совет перестал быть универсальным, как только выбор модели рендеринга стал зависеть от конкретной страницы и её содержимого.
Вместо этого SEO-специалисту нужна другая привычка: для каждого важного элемента задавать конкретный вопрос — где и на каком этапе он появляется в документе, который в итоге получает поисковая система. Если элемент появляется только после выполнения JavaScript, это уже отдельное условие, которое нужно учитывать при оценке страницы.
Именно такой взгляд позволяет связать техническую архитектуру с реальным SEO: важно не название модели рендеринга само по себе, а то, какое содержимое поисковая система получает и на каком этапе обработки страницы.
Это не чек-лист для одноразовой проверки, а модель, к которой SEO-специалист возвращается при обсуждении новой функциональности или редизайна. Вопрос здесь в том, в какой момент и где появляется именно этот элемент. Разные ответы для разных элементов одной и той же страницы совершенно нормальны в 2026 году и сами по себе не означают, что архитектура устроена неправильно.
Итог
У рендеринга нет одной универсально правильной модели. Для одних страниц разумно заранее формировать готовый HTML, для других — собирать его на сервере при запросе, для третьих — сочетать разные подходы. Выбор зависит от того, какие данные содержит страница, как часто они меняются, нужна ли персонализация и насколько важно получить содержимое уже на первом этапе обработки.
Поэтому сам по себе выбор CSR, SSR, SSG или ISR ещё ничего не говорит о качестве SEO-архитектуры. Важно другое: понимает ли команда, где формируется содержимое страницы, когда оно становится доступным и что именно в этот момент получает поисковая система.
Проблема возникает тогда, когда эти вопросы вообще не входят в техническое проектирование. Например, команда может выбрать архитектуру, удобную для разработки и поддержки, а влияние этого решения на поисковую видимость обнаружить только после запуска. На этом этапе исправление может потребовать уже не настройки отдельных метатегов, а изменения способа формирования страниц и взаимодействия между сервером, браузером и данными.
Поэтому рендеринг стоит рассматривать как часть SEO-архитектуры с самого начала. SEO-специалисту важно участвовать в обсуждении таких решений не для того, чтобы навязывать конкретную технологию, а для того, чтобы заранее определить, какое содержимое должно быть доступно поисковой системе и на каком этапе оно должно появляться.
На этом мы заканчиваем разговор о том, где и когда формируется документ. В следующей части разберём, что происходит с ним после этого: как поисковая система обнаруживает URL, получает страницу, обрабатывает её, принимает решение об индексации и в итоге определяет, какое место документ займёт в поиске.
Часть II. Что поисковик видит на самом деле
Глава 5. Жизненный цикл URL в поисковой системе
Владелец сайта обычно говорит: «страница проиндексирована» или «страница не индексируется», как будто индексация — это простое состояние, которое можно представить переключателем: включено или выключено. Для поисковой системы всё сложнее. URL не попадает в индекс одним действием. Сначала поисковой системе нужно узнать о его существовании, затем решить, когда его обходить, получить ответ от сервера, при необходимости обработать JavaScript, разобрать полученное содержимое и только после этого принять решение об индексации.
На любом из этих этапов обработка может быть отложена или завершиться без перехода к следующему. Причина не обязательно заключается в технической ошибке. Поисковая система может не считать дальнейшую обработку URL достаточно приоритетной, не получить нужные данные, обнаружить дублирующее содержимое или принять другое решение на основании доступных ей сигналов.
Эту последовательность полезно разложить на отдельные этапы. Не потому, что каждый из них требует самостоятельного технического разбора прямо сейчас: краулинговому бюджету, дублям, canonical и другим отдельным вопросам будут посвящены следующие главы. Такая карта нужна прежде всего для диагностики. Когда страница не появляется в поиске, важно понимать, на каком этапе возникло ограничение, иначе разные причины легко принять за одну и ту же проблему.
Здесь важно сделать ещё одну оговорку. В общих материалах Google описывает работу поисковой системы через несколько крупных процессов, среди которых обход, рендеринг и индексация. Более подробное деление, которое я буду использовать дальше, — обнаружение URL, планирование обхода, получение ответа, рендеринг, разбор содержимого и индексация — это упрощённая авторская модель для практической диагностики, а не официальное описание внутреннего процесса Google.
Реальный процесс не выглядит как строго последовательная конвейерная цепочка. Отдельные действия могут повторяться, откладываться или выполняться в рамках разных этапов обработки. Уже принятое решение также может быть пересмотрено при следующем обходе. Поэтому дальше эту схему стоит воспринимать именно как карту: она помогает определить, где искать причину проблемы, но не описывает внутреннюю реализацию поисковой системы до каждого технического шага.
Discovery: URL ещё не известен поисковой системе
Первый этап начинается раньше, чем можно подумать: прежде чем поисковая система сможет обработать страницу, ей нужно обнаружить её URL. Источников для этого несколько: ссылки с уже известных страниц, как внутренних, так и внешних, файлы sitemap, перенаправления со старых адресов и другие сигналы. В Search Console также можно отправить URL на проверку и запросить его индексацию, но это именно запрос на обработку, а не гарантия немедленного обхода или индексации.
Если URL ещё не обнаружен поисковой системой, она не может начать его обычную обработку. Не имеет значения, насколько качественным является размещённый на нём контент: сначала поисковой системе нужно узнать сам адрес.
Здесь появляется первая важная развилка, которую Google показывает в Search Console статусом «Discovered — currently not indexed». Это не сообщение о технической ошибке и не окончательный отказ от индексации. Оно означает, что Google уже знает о URL, но пока не выполнил его обход. Среди возможных причин Google указывает откладывание обхода, в том числе для того, чтобы не создавать чрезмерную нагрузку на сервер сайта.
Таким образом, даже обнаруженный URL не обязательно сразу переходит к следующему этапу. Между тем, что поисковая система уже знает об адресе, и фактическим обращением к нему может пройти некоторое время.
Crawl scheduling: когда выполнять обход
Когда URL уже известен, поисковая система принимает отдельное решение о том, когда имеет смысл обратиться к нему и сколько ресурсов выделить на обход.
В документации Google для описания этой задачи используются два понятия: crawl capacity и crawl demand. Crawl capacity показывает, насколько интенсивно Google может обращаться к сайту с учётом возможностей его серверной инфраструктуры. Если сервер отвечает медленно или начинает возвращать ошибки, допустимая частота запросов может снижаться. Crawl demand, в свою очередь, описывает потребность Google возвращаться к сайту и его URL. На неё влияют, в частности, важность и популярность содержимого, а также то, насколько оно изменилось с момента предыдущего обхода.
Из этого следует важный практический вывод: размер сайта сам по себе не определяет частоту его обхода. Небольшой сайт не обязан обходиться реже большого только потому, что на нём меньше страниц. Важны сочетание возможностей сервера и потребности поисковой системы получать или обновлять содержимое.
С новыми или малоизвестными сайтами я бы тоже не вводил отдельное правило вроде «Google специально занижает им приоритет». Такого универсального принципа Google не заявляет. У нового сайта просто может быть меньше накопленных сигналов, на основании которых поисковая система определяет потребность в его регулярном обходе. Поэтому обнаруженные URL такого сайта могут некоторое время оставаться необработанными.
Именно здесь находится одна из возможных причин длительного статуса «Discovered — currently not indexed». URL уже известен Google, но поисковый робот ещё не приступил к его обходу. Сам по себе этот статус не говорит о технической ошибке страницы.
Fetch: получение HTTP-ответа
Если URL выбран для обхода, Googlebot сначала должен определить, разрешено ли ему обращаться к нему с учётом правил robots. txt. Эти правила управляют доступом поисковых роботов к URL и ресурсам сайта. При этом robots. txt не является инструкцией «индексировать или не индексировать»: URL, закрытый от обхода, в некоторых случаях всё равно может появиться в результатах поиска без содержимого страницы.
Если обращение разрешено, Google получает HTTP-ответ. И здесь обработка ещё может остановиться. Сервер может вернуть ошибку, перенаправление или успешный ответ с кодом 200, в котором при этом практически нет нужного содержимого.
Статус ответа имеет значение и для дальнейшей обработки. В частности, Google отдельно уточняет, что страницы с кодом 200 передаются на рендеринг, тогда как для ответов с другими кодами HTTP такое поведение не гарантируется. Поэтому на этом этапе важно смотреть не только на сам URL, но и на то, что именно сервер вернул поисковому роботу.
Render: если необходимо
Если сервер уже отдал содержательный HTML, отдельный рендеринг для получения основного содержимого может быть не нужен. Для страниц, зависящих от JavaScript, ситуация другая: Google должен обработать скрипты и получить представление страницы, которое затем можно анализировать дальше.
Это именно тот этап, который мы подробно разбирали в предыдущих главах: выполнение JavaScript, необходимые сетевые запросы и формирование итогового DOM. При этом не стоит представлять рендеринг как обязательную вторую стадию для каждой страницы. Для обычного серверного HTML значительная часть информации уже доступна до него.
И ещё одна важная оговорка: результат рендеринга не следует считать раз и навсегда установленной версией документа. При следующем обходе Google может получить другое содержимое, увидеть изменения и заново оценить страницу. Поэтому здесь нас интересует не «финальный документ Google», а то представление страницы, которое поисковая система получила в рамках конкретной обработки.
Parse: что поисковая система извлекает из документа
После получения HTML, с выполнением рендеринга или без него, поисковая система должна разобрать содержимое документа. Она извлекает текст, ссылки, метаданные, структурированные данные и другие доступные элементы страницы.
Именно здесь становится особенно заметна разница между тем, что разработчик или редактор считает содержимым страницы, и тем, что поисковая система действительно получила в результате обработки. Текст может появляться только после выполнения JavaScript, ссылки могут отсутствовать в HTML, метаданные могут отличаться от ожидаемых, а часть данных может вообще не попасть в полученное представление страницы.
Это напрямую связано с проблемой, которую мы разбирали в первой главе: разные источники информации о сайте могут показывать разные картины. Сервер может отдавать одно содержимое, после рендеринга формируется другое, sitemap заявляет третье, а внутренняя структура сайта указывает на четвёртую версию.
На этом же уровне возникает вопрос о дублях и канонизации. Если поисковая система обнаруживает несколько URL с одинаковым или очень похожим основным содержимым, она может объединить их в одну группу и выбрать каноническую версию. Указанный сайтом canonical является одним из сигналов для этого решения, но не гарантирует, что Google выберет именно его.