Как настроить H1, H2 и H3 на сайте для SEO в 2026 году

Я обычно начинаю с простого правила: H1, H2 и H3 — это не «для красоты», а нормальная архитектура страницы. Если заголовки на сайте размечены криво, SEO в 2026 году тоже начинает хромать: поисковику сложнее понять тему, пользователю — быстрее уставать, а вам — получать нормальные поведенческие сигналы.

Зачем вообще нужны H1, H2 и H3

На моей практике часто встречается одна и та же история: владелец сайта просит «сделать SEO», а на странице товара или услуги вообще нет H1, зато три H2 и восемь жирных абзацев. Честно говоря, это плохая идея. Заголовки — это не просто визуальные элементы. Они задают иерархию контента, помогают Google и Яндексу понять смысл страницы, а пользователю — быстро пробежать глазами текст и найти нужный блок.

Если говорить грубо, H1 — это главная тема страницы. H2 — крупные смысловые разделы внутри темы. H3 — уточняющие подпункты, детали, примеры, ответы на частные вопросы. И когда эта структура выстроена логично, страница становится понятнее и для людей, и для роботов. На длинных коммерческих страницах, особенно в Bitrix и WordPress, это прямо влияет на качество индексации и на то, как контент «схватывается» в выдаче.

И да, если у вас уже есть проблемы с индексацией, я бы сначала посмотрел не только на заголовки, но и на техническую часть: robots.txt, sitemap, canonical, скорость, мобильную версию. У меня был клиент на WordPress 6.4 с PHP 8.2, где после правки H1 трафик не вырос, потому что страница просто загружалась по 5,8 секунды. Сначала починили Core Web Vitals, потом структуру заголовков — и только тогда получили вменяемый результат.

Современные правила для SEO в 2026 году

Сразу скажу: старые советы уровня «впихните ключ в H1 и будет счастье» уже не работают так прямолинейно. Да, ключевая фраза в H1 по-прежнему полезна. Но поисковые системы оценивают страницу шире: семантику, интент, полезность текста, структуру, скорость, поведение пользователя и соответствие запросу.

В 2026 году я бы держал в голове такой подход: заголовок должен помогать человеку понять, что будет внутри блока, а не обслуживать робота. Если H2 выглядит как набор ключей через запятую, это сразу чувствуется. И пользователи, и поисковики такое не любят. Особенно это видно на контентных проектах, где статьи делаются пачками, а редактор просто копирует шаблон.

На деле работает комбинация из нескольких вещей: нормальный H1, логичная сетка H2, уместные H3, грамотная микроразметка, удобная мобильная верстка. Если тема у вас сложная, советую посмотреть ещё статьи про Schema.org и про FAQ, HowTo и Breadcrumbs. Они отлично дополняют хорошую заголовочную структуру.

Как правильно использовать H1

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

Например, для услуги это может быть: «Продвижение сайтов на WordPress в Москве». Для статьи: «Как настроить H1, H2 и H3 на сайте для SEO в 2026 году». Для категории интернет-магазина: «Ноутбуки ASUS для работы и учёбы». В H1 не нужно пихать всё подряд. Не надо лепить и регион, и коммерческое УТП, и три модификатора. Это плохая идея, особенно если дальше идёт хороший title и нормальный текст.

На моей практике H1 иногда дублируется в шапке сайта, в логотипе, в хлебных крошках или в виджете темы. Это уже проблема шаблона. В Bitrix и WordPress такое встречается регулярно. Если у вас тема или компонент автоматически выводит H1 в нескольких местах, я бы это исправлял сразу. А если нужна доработка шаблона, можно посмотреть услугу по доработке сайта или поддержку WordPress.

Ещё один важный момент: H1 не должен быть длинной портянкой. Оптимально — 3–8 слов, иногда до 10–12, если тема сложная. Но если вы видите H1 на 18 слов, это уже перебор. По опыту, такие заголовки читаются хуже и выглядят как попытка переспорить алгоритм. Не надо так.

Как выстраивать H2: логика разделов

H2 — это каркас страницы. Если H1 говорит «о чём всё это», то H2 раскладывают тему по полочкам. Я обычно делаю так: сначала определяю основные смысловые блоки, а потом уже заполняю их текстом. Для статьи про заголовки H2 могут быть такие: «Зачем вообще нужны H1, H2 и H3», «Как правильно использовать H1», «Частые ошибки», «Как проверить структуру».

Хороший H2 должен быть самостоятельным и понятным. Человек, который бегло просматривает страницу, должен по H2 сразу понять, где находится нужная часть. Иначе текст превращается в кашу. На длинных лендингах, особенно с несколькими услугами, я часто вижу H2 в стиле «Наши преимущества» десять раз подряд. Это слабая структура. Лучше писать конкретнее: «Сроки работ», «Что входит в поддержку», «Как мы принимаем задачи», «Какие CMS берём в работу».

Если вы ведёте блог, H2 ещё и помогают разбить статью на смысловые куски. В этом смысле связка заголовков и внутренней перелинковки работает особенно хорошо. Например, если вы пишете про структуру сайта, уместно сослаться на SEO-аудит сайта или XML sitemap. Это усиливает тематический кластер и помогает пользователю глубже уйти в тему.

И ещё момент. H2 не обязаны содержать точное вхождение ключа. Иногда лучше писать естественно. По опыту, когда заголовок звучит как нормальная фраза, его и читать приятнее, и CTR в сниппете иногда выше, если этот блок попадает в расширенный ответ.

Когда нужен H3 и как его не испортить

H3 нужен тогда, когда внутри H2 у вас есть несколько частных подпунктов. То есть если H2 — это большой раздел, H3 — его мелкая детализация. У меня был случай на сайте услуг на Laravel 10 и PHP 8.3: заказчик хотел всё разложить H2, потому что «так проще для SEO». На деле получилось 14 громоздких разделов на одной странице. После пересборки структуры часть пунктов ушла в H3, текст стал читабельнее, а страница — заметно аккуратнее.

H3 не надо использовать ради количества. Если в блоке всего один абзац, H3 там не нужен. Но если внутри раздела есть несколько часто задаваемых вопросов, шагов, причин или сценариев — это как раз его место. Например, под H2 «Типичные ошибки» можно сделать H3: «Два H1 на странице», «Заголовки ради ключей», «Смешивание структуры и дизайна», «Отсутствие логики между блоками».

Отдельно скажу про каталоги и интернет-магазины. Там H3 часто выручает в фильтрах, описаниях категорий и информационных блоках. Но если у вас уже есть фасетная навигация, карточки, рейтинги и Schema.org, заголовочная структура должна быть особенно аккуратной. Советую потом сверить это с материалом про SEO-фильтры и Faceted Navigation и Structured Data для интернет-магазина.

Частые ошибки при настройке заголовков

Ошибка номер один — несколько H1 на одной странице без понятной причины. Иногда это результат шаблона темы, иногда — следствие кривой верстки. На WordPress это особенно часто всплывает после установки «красивых» тем с ThemeForest. Дизайн вроде бы симпатичный, а внутри — семантический хаос.

Ошибка номер два — заголовки используются для визуального оформления. Например, разработчик делает H2 только потому, что ему нравится размер шрифта. Это неправильный подход. Для стилей есть CSS. Для структуры — HTML. Смешивать эти задачи не стоит, особенно если потом сайт будет жить не один год и переживёт ещё и редизайн, и миграцию на другую CMS.

Ошибка номер три — заголовок не соответствует содержимому блока. Пользователь видит H2 «Сроки выполнения», а внутри написано про цены и гарантии. Это раздражает. И если у вас много таких расхождений, страдает не только удобство, но и SEO-сигналы. Поисковики хорошо видят, когда структура «пообещала одно, а дала другое».

Ошибка номер четыре — переспам ключами. Я видел H2 в стиле «Настройка H1, H2 и H3 для SEO, H1 H2 H3 SEO заголовки». Это уже перебор. Лучше один нормальный заголовок, чем набор словаря. Если вам нужно повысить видимость страницы, разумнее доработать весь текст, добавить примеры, FAQ, внутренние ссылки и, если нужно, техническую часть. И да, если сайт уже давно не обновлялся, иногда лучше начать с технического долга сайта.

Как проверить структуру заголовков на сайте

Проверять заголовки можно руками и инструментами. Я обычно открываю страницу, смотрю исходный код и сразу вижу, где бардак. Для быстрой диагностики подходят браузерные расширения, DevTools и краулер типа Screaming Frog. Если сайт большой, без краулинга вообще тяжело. На проекте с 50 000 URL руками это не проверить нормально, тут уже нужна системная выгрузка.

Если у вас WordPress, можно посмотреть DOM прямо в браузере и проверить, не дублирует ли тема H1 в шапке, а H2 — в блоках, не относящихся к контенту. В Bitrix часто проблема в компонентах: список новостей, каталог, хлебные крошки, блоки «похожие товары» — всё это может тащить свои заголовки. В таких случаях я сначала смотрю шаблон, потом уже лезу в контент. Иногда проблема не в тексте, а в верстке.

Вот простой способ быстро увидеть все заголовки на странице через консоль браузера:

[...document.querySelectorAll('h1, h2, h3')].map((el, i) => ({
  level: el.tagName,
  text: el.textContent.trim(),
  index: i + 1
}));

Если нужен более «серверный» подход, я иногда делаю проверку через PHP на staging-среде, особенно если правки вносятся массово. Например, когда нужно убедиться, что шаблон корректно выводит один H1 и нужную вложенность:

<?php
$html = file_get_contents('https://example.com/page/');
libxml_use_internal_errors(true);

$დომ = new DOMDocument();
$dom->loadHTML(mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8'));

$xpath = new DOMXPath($dom);
$headings = $xpath->query('//h1 | //h2 | //h3');

foreach ($headings as $heading) {
    echo $heading->nodeName . ': ' . trim($heading->textContent) . PHP_EOL;
}

Если у вас уже настроено staging-окружение, такие проверки вообще лучше делать там. На боевом сайте любые эксперименты с заголовками я бы не трогал без копии. Иначе можно случайно сломать важный блок на странице, а потом ещё и ловить это в проде.

Настройка H1, H2 и H3 в WordPress, Bitrix и Laravel

В WordPress обычно всё упирается в тему и редактор. У хорошей темы H1 уже выведен в заголовке записи или страницы, а в контенте вы спокойно ставите H2 и H3 через Gutenberg. Если тема кривая, приходится править шаблон, иначе заголовки дублируются или наоборот исчезают. У меня был кейс на WordPress 6.5 + PHP 8.2, где H1 выводился и в title блока, и в контенте. После правки шаблона и небольшого SEO-аудита структура стала нормальной.

В Bitrix чаще всего работаю через шаблоны компонентов и свойства элементов. Там надо смотреть, что именно подставляется в заголовок страницы, в title, в хлебные крошки и в описание. Иногда H1 стоит в компоненте news.detail, а потом ещё и в статическом блоке выше по странице. В таких случаях я правлю логику вывода, а не только текст. Если нужна системная помощь, уместно смотреть поддержку Битрикс или материал про обновление Битрикс.

В Laravel чаще всего всё аккуратнее, потому что разработка изначально более контролируемая. Но и там встречаются ошибки — особенно если проект собирался быстро, а потом его начали «допиливать» на ходу. Я обычно сразу закладываю семантику в Blade-шаблоны. Вот очень простой пример:

<h1>{{ $page->h1 ?? $page->title }}</h1>

<section>
    <h2>О компании</h2>
    <p>...</p>

    <h2>Почему выбирают нас</h2>
    <h3>Опыт</h3>
    <p>...</p>
</section>

Кстати, если у вас после правок заголовков сайт начал вести себя странно, я бы проверил ещё кэш, CDN и серверный слой. Иногда проблема вообще не в HTML, а в том, что старый шаблон отдается через кэш. Тут полезны материалы про кеширование в Битрикс и кэширование статики и заголовки Cache-Control.

Связь заголовков с другими SEO-элементами

Заголовки нельзя рассматривать отдельно от остального SEO. H1, H2 и H3 работают в связке с title, description, URL, внутренними ссылками и микроразметкой. Если у страницы отличный H1, но кривой title, слабый текст и пустая структура, результат будет средний. И наоборот: иногда даже неидеальный H1 спасается сильным контентом и хорошей технической базой.

Например, на информационной статье H1 может быть «Как настроить H1, H2 и H3 на сайте для SEO в 2026 году», title — чуть более кликабельный, а description — с обещанием конкретики и примеров. Внутри текста обязательно стоит сделать ссылки на тематически близкие статьи. Я бы, кроме уже упомянутых материалов, ещё посмотрел почему сайт не индексируется и SEO-аудит сайта. Это помогает выстроить понятный контентный кластер.

Если у вас коммерческий сайт, заголовки стоит согласовывать с карточками услуг, FAQ-блоками, отзывами и хлебными крошками. Особенно это заметно на локальных услугах и на сайтах с несколькими направлениями. Тогда структура страницы становится не просто «читабельной», а реально полезной для конверсии. А если страница сложная, я бы ещё проверил мобильную версию — на смартфоне плохие заголовки чувствуют себя особенно плохо. Тут в тему будет статья про адаптивный дизайн и мобильную версию.

Чек-лист перед публикацией

Перед публикацией я всегда прохожусь по короткому, но жёсткому чек-листу. Один H1 на страницу. H1 отражает тему страницы и не дублирует title дословно. H2 разбивают контент на крупные смысловые блоки. H3 используются только там, где внутри H2 реально есть вложенная структура. Заголовки читаются человеком, а не только поисковиком. Нет переспама ключами.

Потом я смотрю визуальную часть: не съехала ли верстка, не провалился ли заголовок на мобильной версии, не конфликтует ли он с sticky-header, баннерами, плашками cookies и прочими радостями. На сайтах с плотной шапкой это частая проблема. Плюс я проверяю, не дублируются ли заголовки через шаблон, если используется сложная CMS-логика или подключены дополнительные блоки.

Если проект новый, лучше сразу заложить нормальную семантику в разработку, чем потом перепиливать всё руками. Если старый — править постепенно, начиная с ключевых страниц: главная, услуги, категории, топовые статьи. И да, в 2026 году я бы не откладывал это на потом. Исправление структуры заголовков — одна из самых дешёвых и полезных доработок. Иногда именно она даёт быстрый порядок на странице без лишнего ребрендинга и сложных переработок.

Если нужна помощь с технической правкой, семантикой шаблонов или SEO-структурой страницы, я бы смотрел в сторону поддержки сайта, поддержки WordPress или поддержки Битрикс. На деле это часто быстрее и дешевле, чем пытаться объяснить дизайнеру, почему H2 не должен быть кнопкой.