Два сайта с одинаковыми текстами и одинаковым ссылочным профилем могут стоять в выдаче на разных страницах — только из-за того, как они собраны. Стек, способ рендеринга, вес JavaScript и чистота HTML — это не «внутренняя кухня разработчиков», а полноценные факторы, которые определяют, как поисковик краулит, индексирует и оценивает ваш сайт. Разбираем, где именно технологии встречаются с SEO и что проверить на своём проекте.
В этой статье 6
- Почему качество сборки — ранжирующий фактор
- Скорость и Core Web Vitals: цифры, которые видит алгоритм
- Рендеринг JavaScript: почему часть сайтов индексируется наполовину
- Чистота HTML и разметка: что бот понимает без догадок
- Статика против тяжёлых CMS: честное сравнение
- Что проверить на своём сайте: короткий аудит за вечер
Почему качество сборки — ранжирующий фактор
Поисковая система взаимодействует с сайтом на трёх уровнях: краулинг (бот скачивает страницы), рендеринг и индексация (страница разбирается и попадает в базу), оценка (алгоритм сопоставляет её с запросами и поведением пользователей). Технологии влияют на все три. Медленный сервер урезает краулинговый бюджет — бот успевает обойти меньше страниц. Тяжёлый JavaScript откладывает рендеринг — контент попадает в индекс с задержкой или не полностью. Плохие Core Web Vitals ухудшают пользовательский опыт — а поведенческие сигналы считывают и Яндекс, и Google.
Поэтому «сделаем сайт, а SEO прикрутим потом» — стратегия с встроенной ошибкой. Часть SEO-потенциала закладывается или теряется в момент выбора технологий: до первого текста и до первой ссылки. Исправлять фундамент постфактум всегда дороже, чем заложить его правильно, — это одна из причин, почему мы в АОСА делаем сайты той же командой, которая потом их продвигает.
Скорость и Core Web Vitals: цифры, которые видит алгоритм
Google оценивает страницы по трём метрикам Core Web Vitals: LCP (скорость появления основного контента), INP (отзывчивость на действия пользователя) и CLS (стабильность вёрстки). Яндекс отдельного публичного стандарта не имеет, но скорость и поведенческие факторы учитывает не менее жёстко: медленная страница собирает отказы, а отказы — это прямой сигнал о качестве.
Ключевой момент: CWV — это в первую очередь следствие архитектуры, а не «оптимизации после». Если сайт грузит мегабайт JavaScript до отрисовки контента, никакое сжатие картинок не спасёт LCP. Если баннеры и виджеты вставляются скриптами после загрузки — CLS будет прыгать. Быстрым сайт делают решения уровня сборки: критический CSS, ленивые изображения с заданными размерами, шрифты с preload, минимум блокирующих скриптов.
Рендеринг JavaScript: почему часть сайтов индексируется наполовину
Самая недооценённая техническая проблема — клиентский рендеринг (CSR), когда сервер отдаёт почти пустой HTML, а контент дорисовывает JavaScript в браузере. Google умеет исполнять JS, но делает это во вторую очередь, отдельной волной, и с ограничениями по ресурсам. Яндекс исторически работает с JavaScript ещё осторожнее. На практике это означает: страницы попадают в индекс с задержкой, часть контента бот не видит вовсе, а внутренние ссылки, дорисованные скриптом, могут не участвовать в перелинковке.
Решение известно: отдавать боту готовый HTML. Это делают серверный рендеринг (SSR) и статическая генерация (SSG), когда страницы собираются в HTML заранее, на этапе сборки. Бот получает полный контент первым же запросом — без исполнения скриптов, без второй волны, без сюрпризов. Для большинства коммерческих сайтов — услуги, корпоративные сайты, каталоги — статическая генерация закрывает вопрос индексации полностью.
Сайт нашего агентства aosa.ru собран статически: 9 676 страниц отдаются как готовый HTML, суммарный JavaScript — около 140 КБ в gzip (у типичного сайта на конструкторе — в разы больше), PageSpeed на десктопе — 95+. Каждая страница попадает в индекс без этапа рендеринга JS: боту просто нечего дорисовывать. Это не подвиг оптимизации, а следствие выбора архитектуры на старте.
Собирательный пример на основе типовых проектов — не реальный клиент.
Чистота HTML и разметка: что бот понимает без догадок
Поисковик разбирает страницу как документ. Семантический HTML — правильная иерархия заголовков, списки списками, таблицы таблицами — помогает алгоритму понять структуру без эвристик. Свалка из вложенных div с классами-абракадаброй, которую генерируют многие конструкторы, — наоборот. Отдельный уровень — структурированные данные: Schema.org-разметка в формате JSON-LD прямо сообщает поиску, что перед ним организация, услуга, статья, хлебные крошки или FAQ. Это влияет на сниппеты в выдаче и на попадание в нейроответы: генеративные системы охотнее цитируют страницы, из которых легко извлечь факты.
Хороший ориентир — разметка на каждой странице, а не только на главной. На aosa.ru JSON-LD присутствует на 100% страниц, потому что она генерируется автоматически из тех же данных, из которых собирается страница. Когда разметку добавляют вручную «по мере сил», покрытие быстро расползается: новые страницы выходят без неё, старые устаревают.
Статика против тяжёлых CMS: честное сравнение
Тяжёлая CMS с десятком плагинов — это цепочка «запрос → PHP → база данных → сборка страницы» на каждый визит, плюс чужой код в каждом плагине. Статический сайт — это заранее собранные HTML-файлы, которые сервер отдаёт из кэша мгновенно. Разница проявляется во всём: скорость ответа, стабильность CWV, поверхность для взлома, стоимость хостинга.
Как решения уровня стека транслируются в SEO-эффекты
- Технологическое решение: Статическая генерация (SSG/SSR)
- Что видит поисковик: Полный HTML первым запросом
- SEO-эффект: Быстрая и полная индексация
- Технологическое решение: Клиентский рендеринг (CSR)
- Что видит поисковик: Пустой каркас + JS
- SEO-эффект: Задержки и пробелы в индексе
- Технологическое решение: Лёгкий бандл JS (~100–200 КБ)
- Что видит поисковик: Быстрые LCP и INP
- SEO-эффект: Плюс к CWV и поведенческим
- Технологическое решение: Конструктор с виджетами
- Что видит поисковик: Мегабайты скриптов
- SEO-эффект: Просадка CWV, отказы
- Технологическое решение: JSON-LD на всех страницах
- Что видит поисковик: Явные сущности и факты
- SEO-эффект: Расширенные сниппеты, нейроответы
- Технологическое решение: HTML-свалка без семантики
- Что видит поисковик: Структуру надо угадывать
- SEO-эффект: Хуже понимание контента
Текст схемы и все данные
Как решения уровня стека транслируются в SEO-эффекты
- Технологическое решение: Статическая генерация (SSG/SSR)
- Что видит поисковик: Полный HTML первым запросом
- SEO-эффект: Быстрая и полная индексация
- Технологическое решение: Клиентский рендеринг (CSR)
- Что видит поисковик: Пустой каркас + JS
- SEO-эффект: Задержки и пробелы в индексе
- Технологическое решение: Лёгкий бандл JS (~100–200 КБ)
- Что видит поисковик: Быстрые LCP и INP
- SEO-эффект: Плюс к CWV и поведенческим
- Технологическое решение: Конструктор с виджетами
- Что видит поисковик: Мегабайты скриптов
- SEO-эффект: Просадка CWV, отказы
- Технологическое решение: JSON-LD на всех страницах
- Что видит поисковик: Явные сущности и факты
- SEO-эффект: Расширенные сниппеты, нейроответы
- Технологическое решение: HTML-свалка без семантики
- Что видит поисковик: Структуру надо угадывать
- SEO-эффект: Хуже понимание контента
| Технологическое решение | Что видит поисковик | SEO-эффект |
|---|---|---|
| Статическая генерация (SSG/SSR) | Полный HTML первым запросом | Быстрая и полная индексация |
| Клиентский рендеринг (CSR) | Пустой каркас + JS | Задержки и пробелы в индексе |
| Лёгкий бандл JS (~100–200 КБ) | Быстрые LCP и INP | Плюс к CWV и поведенческим |
| Конструктор с виджетами | Мегабайты скриптов | Просадка CWV, отказы |
| JSON-LD на всех страницах | Явные сущности и факты | Расширенные сниппеты, нейроответы |
| HTML-свалка без семантики | Структуру надо угадывать | Хуже понимание контента |
Означает ли это, что тяжёлая CMS — всегда ошибка? Нет. Крупному магазину с личным кабинетом, остатками и фильтрами динамическая платформа нужна по делу. Ошибка — когда визитка на 20 страниц тащит на себе движок с 40 плагинами, а бизнес потом годами оплачивает его медлительность позициями.
Что проверить на своём сайте: короткий аудит за вечер
- Прогоните ключевые страницы через PageSpeed Insights: смотрите не общий балл, а LCP, INP, CLS по полевым данным.
- Откройте исходный код страницы (Ctrl+U): если текстов и ссылок в HTML нет — у вас клиентский рендеринг, и индексация под вопросом.
- Проверьте разметку валидатором Schema.org: есть ли JSON-LD, на скольких типах страниц, без ошибок ли.
- Оцените вес JavaScript во вкладке «Сеть» браузера: мегабайт и больше на простой странице — повод для разговора с разработчиком.
- Сравните мобильную и десктопную версии: поиск оценивает прежде всего мобильную.
- Посмотрите в Вебмастере и Search Console долю страниц «обнаружено, но не проиндексировано» — это часто симптом медленного сервера или JS-рендеринга.
Что проверить на своём сайте: короткий аудит за вечер
- Прогоните ключевые страницы через PageSpeed Insights: смотрите не общий балл, а LCP, INP, CLS по полевым данным.
- Да
- Откройте исходный код страницы (Ctrl+U): если текстов и ссылок в HTML нет — у вас клиентский рендеринг, и индексация под вопросом.
- Да
- Проверьте разметку валидатором Schema.org: есть ли JSON-LD, на скольких типах страниц, без ошибок ли.
- Да
- Оцените вес JavaScript во вкладке «Сеть» браузера: мегабайт и больше на простой странице — повод для разговора с разработчиком.
- Да
- Сравните мобильную и десктопную версии: поиск оценивает прежде всего мобильную.
- Да
- Посмотрите в Вебмастере и Search Console долю страниц «обнаружено, но не проиндексировано» — это часто симптом медленного сервера или JS-рендеринга.
- Да
Текст схемы и все данные
Что проверить на своём сайте: короткий аудит за вечер
- Прогоните ключевые страницы через PageSpeed Insights: смотрите не общий балл, а LCP, INP, CLS по полевым данным.
- Да
- Откройте исходный код страницы (Ctrl+U): если текстов и ссылок в HTML нет — у вас клиентский рендеринг, и индексация под вопросом.
- Да
- Проверьте разметку валидатором Schema.org: есть ли JSON-LD, на скольких типах страниц, без ошибок ли.
- Да
- Оцените вес JavaScript во вкладке «Сеть» браузера: мегабайт и больше на простой странице — повод для разговора с разработчиком.
- Да
- Сравните мобильную и десктопную версии: поиск оценивает прежде всего мобильную.
- Да
- Посмотрите в Вебмастере и Search Console долю страниц «обнаружено, но не проиндексировано» — это часто симптом медленного сервера или JS-рендеринга.
- Да
Если по итогам самопроверки картина тревожная, дальше есть два пути: точечно лечить текущую платформу (иногда достаточно) или пересобрать сайт на быстром стеке — этот путь разумно совместить с редизайном, чтобы не платить за миграцию дважды. Выбор между ними — задача технического аудита, а не интуиции.
Типичная ситуация на аудитах: бизнес год платит за продвижение, а сайт отдаёт первый контент на четвёртой секунде и держит треть страниц вне индекса из-за JS-рендеринга. Контент и ссылки в таких условиях работают вполсилы — как хороший двигатель на спущенных колёсах. Правильный порядок обратный: сначала техническая база, на которой сигналы качества вообще могут проявиться, потом наращивание контента. Именно поэтому сайт и его продвижение стоит проектировать как одну систему, а не как два подряда.
Владимир БогдановОснователь и руководитель AOSA · эксперт по SEO и AEO, 12+ лет в поисковой оптимизации