Навигация в длинной статье: оглавление, якорные ссылки и переходы между разделами

20 августа 2026 • Визуальная культура

Длинная статья не обязательно читается сверху вниз от первого абзаца до последнего. Один человек приходит за определением, другой уже знает вводную часть и ищет сравнение, третий возвращается к конкретному ограничению. Если документ допускает только последовательную прокрутку, вся его структура существует, но пользоваться ею неудобно.

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

Навигация начинается со структуры разделов

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

Поэтому навигация опирается на уже построенную информационную архитектуру длинной страницы.

У каждого навигационного пункта должен существовать реальный объект назначения:

самостоятельный раздел;
важный подраздел;
результат;
таблица или иной крупный блок, если к нему действительно возвращаются;
отдельный служебный раздел вроде источников.

Навигация не должна создавать больше уровней, чем есть у самого материала.

Оглавление нужно не каждой длинной статье

Сам объём текста ещё не является достаточной причиной добавлять содержание в начало страницы.

Оглавление особенно полезно, когда:

материал разделён на несколько самостоятельных секций;
пользователь часто приходит только за одной частью ответа;
разделы имеют понятные названия;
документ используется как справочный и к нему возвращаются;
в статье есть методика, данные, результаты или другие крупные блоки, которые имеет смысл открывать напрямую.

Office for National Statistics в своей дизайн-системе рекомендует table of contents для страниц с большим объёмом материала, разделённого на ясные секции. Такой компонент помогает увидеть структуру страницы и перейти к нужной части.

Но короткий материал из трёх последовательных разделов может читаться быстрее без дополнительного блока ссылок. Оглавление в таком случае создаёт ещё один элемент интерфейса, который пользователь должен сначала просмотреть.

Хорошее оглавление — это не копия всех заголовков

Автоматически вывести в содержание каждый H2 и H3 технически просто. Пользовательская ценность зависит от результата.

Представим страницу с шестью крупными разделами и двадцатью подразделами. Полное оглавление из двадцати шести ссылок уже само становится большим документом перед документом.

Есть несколько вариантов:

Ситуация	Подход к оглавлению
Небольшое число самостоятельных H2	Показать основные разделы
Несколько крупных групп с важными подразделами	Использовать двухуровневое содержание только там, где второй уровень действительно помогает
Очень много мелких H3	Не выводить их все автоматически, сначала проверить саму структуру
Документ состоит из последовательных шагов	Содержание может повторять этапы процесса
Разделы почти нельзя читать независимо	Компактное оглавление или его отсутствие может быть понятнее

Оглавление должно сокращать время поиска, а не демонстрировать глубину HTML-структуры.

Название ссылки должно объяснять, куда она ведёт

Пункт «Подробнее» мало помогает в содержании. Пользователю приходится сначала читать соседний контекст, чтобы понять назначение ссылки.

Гораздо полезнее:

«Когда нужно оглавление»;
«Как работают якорные ссылки»;
«Sticky-навигация на мобильном»;
«Проверка навигации с клавиатуры».

Для оглавления обычно удобно сохранять формулировку близкой к заголовку целевого раздела. Тогда обещание ссылки и место после перехода совпадают.

Полное буквальное совпадение не является обязательным. Но если пункт называется «Результаты исследования», а после клика пользователь попадает к заголовку «Что произошло дальше», приходится заново определять, туда ли он пришёл.

Якорная ссылка переводит к конкретной части того же документа

В обычном HTML для этого используется fragment identifier — часть URL после символа #.

Пример:

<a href="#mobile-navigation">Мобильная навигация</a>

...

<h2 id="mobile-navigation">Мобильная навигация</h2>

MDN описывает URI fragment как указатель на отдельную часть ресурса. В HTML браузер может использовать значение id и прокрутить документ к соответствующему элементу.

У такого подхода есть дополнительное преимущество: раздел получает адрес, которым можно поделиться напрямую.

https://example.com/article/#mobile-navigation

Человек открывает не просто статью, а конкретное место внутри неё.

ID разделов лучше считать постоянными адресами

Название H2 может меняться во время редакторской работы. Если вместе с ним каждый раз автоматически меняется id, старые внешние и внутренние ссылки на раздел перестают попадать в прежнюю точку.

Поэтому для материалов, на которые могут ссылаться напрямую, полезно отделять:

видимый заголовок и стабильный fragment ID.

Например:

<h2 id="toc-mobile">
  Как адаптировать оглавление для мобильного экрана
</h2>

Через месяц редактор может слегка изменить формулировку H2, не меняя toc-mobile.

MDN также описывает text fragments, которые позволяют вести к конкретному тексту без заранее заданного ID. Для временного обмена ссылкой это удобно. Но текст меняется легче, чем структурный идентификатор. Поэтому для постоянной навигации, которую контролирует автор страницы, обычные document fragments остаются более предсказуемой основой.

Навигационный блок лучше размечать как навигацию

Оглавление — не просто набор случайных ссылок. Это отдельная область страницы, предназначенная для перемещения по документу.

WAI-ARIA Authoring Practices рекомендует использовать HTML-элемент <nav> для navigation landmark. Если на странице несколько областей навигации, их нужно различать доступными названиями.

Например:

<nav aria-labelledby="page-toc">
  <h2 id="page-toc">Содержание статьи</h2>
  <ul>
    <li><a href="#toc">Когда нужно оглавление</a></li>
    <li><a href="#anchors">Якорные ссылки</a></li>
    <li><a href="#mobile">Навигация на мобильном</a></li>
  </ul>
</nav>

Это помогает отличить, например, основное меню сайта от содержания конкретной статьи.

Заголовки сами являются способом навигации

Оглавление — не единственный механизм перемещения по длинному документу.

W3C отмечает, что корректно размеченные headings позволяют пользователям вспомогательных технологий переходить между секциями и пропускать части страницы. Поэтому хороший outline полезен даже тогда, когда видимого содержания нет.

Из этого следует две вещи.

Первая: нельзя считать оглавление заменой нормальной иерархии H1–H3.

Вторая: слишком много навигационных механизмов тоже не всегда полезно. W3C в учебных материалах по navigation design отдельно советует оценивать количество таких компонентов, поскольку их избыток может создавать лишний шум.

Навигация должна давать новый способ доступа, а не пять раз повторять одну и ту же структуру разными компонентами.

Sticky-оглавление полезно, когда к содержанию действительно возвращаются

На широком экране содержание можно оставить рядом с основным текстом и удерживать в viewport во время прокрутки. Пользователь видит текущий раздел и может быстро перейти к соседнему.

Такой вариант особенно уместен у:

длинных справочных материалов;
руководств с независимыми секциями;
документов, где человек регулярно переключается между частями;
страниц, на которых текущая позиция внутри структуры имеет значение.

Но sticky не является улучшением по умолчанию.

Если оглавление высокое, оно может не помещаться в viewport. Office for National Statistics прямо не рекомендует свой in-page table of contents, когда блок становится выше экрана. Независимая прокрутка внутри длинного бокового содержания способна сделать взаимодействие сложнее.

Перед sticky-вариантом поэтому стоит проверить не только ширину колонки, но и реальную высоту списка.

Sticky-элемент не должен закрывать место назначения

Есть и техническая проблема. Если сверху закреплён header или navigation bar, переход по #fragment может визуально привести к разделу, но его заголовок окажется под фиксированным элементом.

То же касается клавиатурного фокуса. WCAG 2.2 содержит критерий Focus Not Obscured: элемент, получивший клавиатурный focus, не должен быть полностью скрыт авторским sticky-контентом.

Для интерфейса это означает, что нужно проверить:

куда попадает viewport после перехода по якорю;
виден ли сам заголовок;
не перекрывает ли его fixed header;
видны ли ссылки при перемещении с клавиатуры;
учтён ли необходимый scroll offset или scroll-padding.

Sticky-навигация полезна только пока она не мешает читать то, к чему сама же переводит.

Подсветка текущего раздела должна соответствовать реальному положению

В боковом оглавлении часто отмечают пункт текущей секции.

Это помогает ответить на вопрос:

«Где я сейчас нахожусь внутри документа?»

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

Поэтому active state нужно проверять на границах секций, при коротких разделах и при переходе по якорю.

MDN описывает CSS :target как способ стилизовать элемент, соответствующий fragment identifier текущего URL. Для более сложной подсветки положения во время обычной прокрутки может понадобиться дополнительная логика. Но независимо от реализации активное состояние должно помогать понимать позицию, а не превращаться в декоративную анимацию.

На мобильном оглавление обычно требует другого интерфейса

Десктопная боковая колонка редко переносится на смартфон без изменений. Она занимает ширину, конкурирует с текстом и при sticky-поведении может перекрывать заметную часть viewport.

На маленьком экране возможны другие варианты:

обычное содержание перед статьёй;
сворачиваемый блок «Содержание»;
короткая навигация только по главным H2;
компактный элемент, который открывает список разделов по запросу пользователя.

Выбор зависит от числа пунктов и сценария чтения. Если содержание состоит из пяти ссылок, отдельная сложная панель может быть лишней. Если документ огромный и постоянно используется как справочник, доступ к разделам должен оставаться удобным и после длинной прокрутки.

Полную адаптацию длинных материалов для небольшого экрана разберём отдельно в статье о мобильной версии длинной статьи.

Ссылкам на мобильном нужно достаточно места для нажатия

Компактное содержание легко превратить в плотный список мелких строк.

WCAG 2.2 для Target Size (Minimum) устанавливает базовое требование: цель для pointer input должна быть не меньше 24 × 24 CSS px, если не действует одно из перечисленных исключений. Для обычных inline-ссылок внутри текста есть отдельное исключение, но меню содержания обычно можно спроектировать просторнее.

Поэтому мобильное оглавление лучше проверять как набор интерактивных целей:

не расположены ли соседние ссылки слишком близко;
можно ли попасть в нужный пункт пальцем;
достаточна ли высота строки;
не приходится ли нажимать точно на маленькие буквы;
не закрывает ли открытый список основной контент без понятного способа закрытия.

Нужна ли кнопка «Наверх»

У длинных страниц такой элемент кажется очевидным. Но он не обязателен для каждого материала.

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

Если sticky-оглавление постоянно доступно, отдельная кнопка может просто дублировать навигацию.

Поэтому вопрос лучше формулировать не «длинная ли статья», а:

«Какую пользовательскую задачу решает возврат к началу?»

Если ответа нет, ещё один floating control добавлять необязательно.

Ссылки между разделами полезны, когда зависимость нелинейная

Не все отношения в длинном материале можно выразить порядком сверху вниз.

Например, раздел о графике может требовать подробности из более раннего блока про ограничения. Повторять весь текст не нужно. Можно дать локальную ссылку:

<a href="#limitations">
  ограничения интерпретации
</a>

Такие ссылки особенно полезны, когда:

понятие объясняется в одном основном месте;
к нему нужно обратиться из нескольких разделов;
повторение увеличило бы объём;
пользователь может читать документ выборочно.

Но если каждый второй абзац отправляет пользователя в другое место статьи, последовательное чтение распадается. Локальные переходы должны поддерживать архитектуру, а не превращать её в сеть обязательных прыжков.

Прямые ссылки на раздел полезны и за пределами оглавления

Стабильный fragment позволяет ссылаться на конкретную часть статьи:

из другого материала;
из письма или сообщения;
из документации;
из списка источников;
из собственной внутренней перелинковки сайта.

Это особенно полезно у длинных справочных страниц, где ссылка на верх документа заставила бы человека заново искать нужный фрагмент.

Поэтому наличие понятных и стабильных ID можно рассматривать не только как функцию оглавления, но и как часть общей адресуемости материала.

Что происходит при изменении структуры статьи

Живой материал со временем может получить новые разделы, а старые — поменять порядок.

При обновлении стоит проверить:

соответствует ли оглавление новой структуре;
не исчезли ли старые ID, на которые могли вести ссылки;
не появились ли два одинаковых идентификатора;
актуальны ли ссылки между разделами;
правильно ли подсвечивается текущая секция;
не стало ли sticky-оглавление выше viewport.

Если заголовок больше не нужен, но на его fragment уже могли ссылаться, удаление ID требует отдельного решения. Иногда проще сохранить прежнюю точку назначения или перенаправить пользователя к ближайшему актуальному блоку средствами приложения.

Как проверить навигацию до публикации

Открыть каждый пункт содержания

Переход должен попадать именно к тому разделу, который обещает ссылка. Не на соседний H2 и не на заголовок, скрытый под sticky-header.

Проверить адрес с fragment напрямую

Скопируйте URL конкретного раздела и откройте его в новой вкладке. Нужная часть страницы должна оставаться понятной без предварительной прокрутки от начала.

Пройти страницу только с клавиатуры

Focus должен оставаться видимым, а навигационные ссылки — доступными в предсказуемом порядке.

Проверить headings отдельно от оглавления

Если удалить содержание, структура всё ещё должна позволять навигацию по заголовкам.

Проверить мобильную ширину

Список не должен занимать большую часть первого экрана без достаточной причины. Интерактивные пункты должны оставаться удобными для нажатия.

Проверить статью после добавления нового раздела

Навигационная система должна выдерживать развитие материала без ручного ремонта в нескольких несвязанных местах.

Типичные ошибки навигации в длинной статье

Ошибка	Почему мешает	Что сделать
Оглавление содержит каждый H2 и H3 без отбора	Список становится почти таким же сложным, как статья	Оставить пункты, которые реально помогают выбирать часть документа
Пункт содержания заметно отличается от H2 по смыслу	После перехода приходится заново искать обещанный ответ	Сблизить названия
ID автоматически меняется вместе с заголовком	Старые deep links перестают вести в нужное место	Использовать стабильные идентификаторы
Sticky-блок выше viewport	Навигация сама требует сложной прокрутки	Сократить список или изменить мобильный и десктопный сценарий
Fixed header закрывает heading после перехода	Пользователь не видит точку назначения	Настроить отступ прокрутки и проверить focus
Цвет — единственное обозначение текущего раздела	Статус может быть плохо различим	Добавить другой визуальный признак
Слишком много способов перемещения	Интерфейс перегружен одинаковыми функциями	Оставить те механизмы, которые решают разные задачи

Практическая схема навигации для длинной статьи

Проверить архитектуру. У документа должны быть самостоятельные и правильно названные разделы.
Определить сценарии выборочного чтения. Какие части пользователь действительно будет искать отдельно.
Решить, нужно ли оглавление. Длина сама по себе не является достаточным основанием.
Выбрать глубину содержания. Не копировать все уровни автоматически.
Задать стабильные fragment ID. Важные секции получают постоянные адреса.
Разметить навигационный блок семантически. При нескольких nav-областях дать им различимые названия.
Решить вопрос со sticky. Проверить высоту, viewport и перекрытие контента.
Спроектировать мобильный вариант отдельно. Боковая колонка не должна механически уменьшаться до ширины телефона.
Проверить pointer и keyboard interaction. Ссылки должны быть доступны и не скрываться под фиксированными элементами.
Проверять навигацию при каждом крупном обновлении структуры.

Что должна дать внутридокументная навигация

Хорошая навигация не заставляет человека использовать оглавление. Она просто даёт выбор.

Можно читать статью последовательно. Можно посмотреть структуру и открыть один раздел. Можно получить прямую ссылку на конкретную часть. Можно перейти к связанному объяснению и продолжить работу с документом.

Для длинной страницы полезна простая последовательность:

структура → точки перехода → понятные названия → стабильные адреса → доступное взаимодействие.

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

Источники

Источники проверены 20 августа 2026 года. Использованы материалы W3C Web Accessibility Initiative, MDN Web Docs и Office for National Statistics Design System.