On-page структура в RU-SEO: H1, иерархия заголовков, анкоры и alt-text
On-page оптимизация — это не про «сколько раз упомянуть ключ в H1». Это про три сигнала, которые поисковик собирает из HTML: topical relevance из иерархии заголовков, граф ссылок из анкоров внутренних ссылок, контекст изображений из alt-text. И RU-Яндекс обрабатывает каждый из этих сигналов иначе, чем Google — потому что у него морфология по падежам, другие SERP-блоки для картинок и явный приоритет hub-spoke топологии.
H1 — единственный заголовок страницы, который имеет значение
Каноническая рекомендация для обоих движков простая: один H1 на страницу. Не три в <section>-обёртках, не визуально спрятанный «декоративный» H1. Один — и он отражает тему страницы.
Яндекс это правило формализует жёстче: один H1, в нём должно быть отражение ключа из title (но не дословный дубль). Кириллица предпочтительна на RU-странице — латиница в H1 не помогает ни релевантности, ни CTR.
Google допускает кратные H1 внутри HTML5-семантики <section>, но визуально всё равно ожидает одну. Если у вас два H1 «логически», значит, страница пытается быть двумя страницами — разнесите.
Главная ошибка, которая встречается в RU-проектах: H1 пишется для SEO, а не для пользователя — в духе «купить окна ПВХ в Москве недорого с установкой». Такой H1 не работает ни для одного движка. И Яндекс, и Google берут heading-текст как сигнал topical relevance, и переспамленный H1 просто размывает сигнал.
Иерархия H2-H6: не перескакивайте уровни
И Яндекс, и Google парсят структуру заголовков как outline, а не как плоский список. Это значит: после H2 идёт H3, после H3 — H4. H2 → H4 без H3 — это разрыв outline, и поисковик его не «починит» магически.
Структурно outline читается так:
H1: Тема страницы
├─ H2: Подтема 1
│ ├─ H3: Аспект подтемы 1.1
│ └─ H3: Аспект подтемы 1.2
└─ H2: Подтема 2
└─ H3: Аспект подтемы 2.1
Текст заголовка ведёт релевантность, не плотность ключей. Если H3 называется «Стоимость», а в нём три абзаца про сроки доставки — сигнал topical relevance уезжает в раздел «Сроки доставки», а не «Стоимость». Это не баг поисковика, это баг структуры страницы.
Практический масштаб для среднего материала: H1 плюс 4-7 H2, под каждым H2 — 1-3 H3. Этот диапазон читается и пользователем, и outline-парсером.
Анкоры: Яндекс склеивает падежи, Google — нет
Это самое интересное место, где RU отличается от EN.
Яндекс нормализует анкоры по морфологии. Анкоры «купить окна», «купить окон», «покупка окон», «купить окно» — это один и тот же анкор-бакет для Яндекса. Все они будут учтены в графе ссылок как ссылки на одну и ту же сущность.
Google такой морфологии не делает. Для Google «купить окна» и «купить окон» — это разные строки.
Следствие для RU-сайтов: якорный профиль, который для Google выглядит разнообразным, для Яндекса может выглядеть однообразным. Если у вас 40% ссылок морфологически сходятся в один бакет «купить окна», Яндекс увидит переоптимизацию именно там, где Google ещё терпит.
Яндекс также сигналит, что каждый уникальный анкор не должен превышать ~30% от профиля для одного коммерческого кластера. Это не точная константа — это порог, после которого Яндекс.Вебмастер начинает помечать профиль как «переоптимизированный». Брендовый анкор — естественный разбавитель.
Граф внутренних ссылок: hub-spoke без осиротевших страниц
Структура «hub + spokes» — это не просто рекомендация, это единственный способ удержать топологию управляемой на сайте с десятками и сотнями страниц.
hub (обзорная страница)
├─ spoke 1 (детальная)
├─ spoke 2 (детальная)
├─ spoke 3 (детальная)
└─ spoke 4 (детальная)
Hub получает входящие внешние ссылки и распределяет вес по spokes. Каждый spoke ссылается обратно на hub и на 1-2 соседних spokes. Связь «hub → spoke в первых 200 словах страницы» — не догма, но рабочий шаблон, который держит ссылочный вес там, где он нужен.
Что ломает hub-spoke:
- Осиротевшие страницы — нет ни одной внутренней ссылки ниоткуда. Поисковик их найдёт только через sitemap, но вес по ним не потечёт.
- Дублирование URL —
/page/и/pageбез canonical. Поисковик не знает, какую версию считать основной, вес размазывается. - Trailing slash без 301-редиректа на одном хосте — то же самое.
- Несколько hubs на одну тему — два конкурирующих hub-узла делят вес, и вместо одного сильного кластера получается два слабых.
Яндекс даёт инструмент, которого у Google нет: директива Clean-param в robots.txt. Она говорит роботу, что определённые GET-параметры не меняют контент (?utm_source=, ?ref=, ?sort=), и робот не должен индексировать их как отдельные URL. Это часть on-page hygiene: если робот видит 50 URL на одну страницу, граф ссылок дробится на 50 частей вместо одной.
Alt-text: описание для пользователя, разметка для ImageObject
Alt-text существует по двум причинам: доступность (скринридеры читают alt) и поиск картинок. Это не SEO-текст ради ключей.
Google требует ImageObject-разметку для попадания в Google Images. Яндекс читает ту же разметку, плюс требует alt-text, плюс поддерживает caption, title, license в image-sitemap.
Хороший alt-text описывает, что на картинке, в одном-двух предложениях:
- ❌
image1.jpg - ❌
купить окна ПВХ - ✅
Белые пластиковые окна в квартире-студии, вид изнутри
Третий вариант описывает содержание. Первые два — не описывают. Поисковик может извлечь текст из контекста страницы, но без alt вы теряете Image Pack / Картинки SERP-блок, а это в RU-сегменте ощутимый канал трафика на информационных запросах.
В image-sitemap для Яндекса дополнительно можно указать caption, title, license — поля не обязательные, но Яндекс их учитывает.
Когда это не работает
- Single-page-app с клиентским рендерингом — если H1 рисуется JS-ом после гидратации, оба движка его видят (Яндекс через opt-in JS-rendering в Вебмастере, Google — всегда), но видимость задерживается на второй wave индексации. Если для вас H1 = «критический сигнал релевантности», держите его в SSR-HTML.
- Длинные лендинги с десятками H2 — outline становится нечитаемым, и поисковик начинает «усреднять» релевантность по всему документу. Если у вас 15 H2, возможно, у вас 5 страниц.
- E-commerce с автогенерированными alt — alt вида
фото-123.jpgилиimageиз шаблонизатора не дают сигнала ни скринридерам, ни поиску картинок. Это либо технический долг, либо сигнал, что шаблон не настроен.
Откуда это
Эта статья — продолжение Title и Meta Description в RU и EN, вместе они закрывают on-page rubric из RU-SEO-разведки 2026 года. Цифры и пороги взяты из документации Яндекс.Вебмастера (yandex/en/recommendations/presentation, yandex/en/recommendations/links), Google Search Central (search/docs/appearance, spam-policies) и открытых наблюдений RU-агентств.
Дальше в цикле — Технический SEO для RU-сайтов: robots, sitemap, hreflang, Core Web Vitals и Schema.org, и завершает аналитика Яндекс vs Google в RU: 18 деталей, которые реально отличаются, которая объясняет, почему эти пороги у Яндекса и Google расходятся структурно.
Дисклеймер
Это сводный разбор on-page структуры для RU-сайтов, не «объективное сравнение всех SEO-подходов». Нет академического разбора функций ранжирования, нет обещания конкретного прироста позиций после применения. Все цифры — рабочие диапазоны и пороги из первоисточников; поведение поисковиков меняется от апдейта к апдейту, поэтому проверяйте даты рядом с каждой ссылкой.
Первоисточники
- Яндекс.Вебмастер — Recommendations: https://yandex.com/support/webmaster/en/recommendations/presentation
- Яндекс.Вебмастер — Links: https://yandex.com/support/webmaster/en/recommendations/links
- Яндекс.Вебмастер — Sitemap (incl. images): https://yandex.com/support/webmaster/en/controlling-robot/sitemap
- Google Search Central — Structured Data / Article: https://developers.google.com/search/docs/appearance/structured-data/article?hl=ru
- Google Search Central — Google Images best practices: https://developers.google.com/search/docs/appearance/google-images?hl=ru
- Google Search Central — Spam policies (link spam): https://developers.google.com/search/docs/essentials/spam-policies?hl=ru