On-page структура в RU-SEO: H1, иерархия заголовков, анкоры и alt-text

On-page оптимизация — это не про «сколько раз упомянуть ключ в H1». Это про три сигнала, которые поисковик собирает из HTML: topical relevance из иерархии заголовков, граф ссылок из анкоров внутренних ссылок, контекст изображений из alt-text. И RU-Яндекс обрабатывает каждый из этих сигналов иначе, чем Google — потому что у него морфология по падежам, другие SERP-блоки для картинок и явный приоритет hub-spoke топологии.

H1 — единственный заголовок страницы, который имеет значение

Каноническая рекомендация для обоих движков простая: один H1 на страницу. Не три в -обёртках, не визуально спрятанный «декоративный» H1. Один — и он отражает тему страницы.

Яндекс это правило формализует жёстче: один H1, в нём должно быть отражение ключа из title (но не дословный дубль). Кириллица предпочтительна на RU-странице — латиница в H1 не помогает ни релевантности, ни CTR.

Google допускает кратные H1 внутри HTML5-семантики , но визуально всё равно ожидает одну. Если у вас два 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