Структура сайта — как составить, чтобы не переделывать через год

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

Nielsen Norman Group разобрала это правило прямо: оно не подтверждено ни одним опубликованным исследованием. След ведёт к книге Джеффри Зельдмана 2001 года, где это просто утверждение в тексте — мол, если человек не найдёт нужное за три клика, он уйдёт к кому-то другому. В 2003 году UIE решила проверить. 44 пользователя, 620 задач, больше 8000 кликов. Вывод: после трёх кликов задачу бросают не чаще, чем после двенадцати. Удовлетворённость тоже не зависела от длины пути — доля недовольных держалась в пределах 46–61% независимо от того, сколько кликов заняла задача.

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

Что такое структура сайта и из чего она состоит

Структура сайта — это не меню и не карта сайта в Figma. Это ответ на три вопроса: какие страницы существуют, в каких они отношениях между собой и как пользователь и робот поисковой системы эти отношения видят.

Составляющих ровно четыре, и путают их постоянно:

1. Логическая иерархия — какие разделы есть, что чему подчинено. Живёт в голове и на схеме.
2. URL-адреса — как эта иерархия записана в адресной строке. Не обязаны повторять логику один в один, но обычно повторяют.
3. Навигация — меню, хлебные крошки, блоки перелинковки, фильтры. То, чем человек реально пользуется.
4. Внутренние ссылки — сеть переходов между страницами, включая те, которых в меню нет.

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

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

Виды структур сайта — и как выбрать свою

На практике встречаются четыре типа. Выбирают не по красоте схемы, а по тому, как человек ищет информацию.

Линейная. Страницы идут последовательно, одна за другой, без ответвлений. Онбординг, пошаговый гайд, конфигуратор, длинная форма заявки. Работает там, где порядок шагов важнее свободы выбора. Для целого сайта это редкость, для отдельного сценария внутри сайта — норма.

Древовидная (иерархическая). Главная → разделы → подразделы → конечные страницы. Самый распространённый тип, и на нём построено большинство корпоративных сайтов, каталогов услуг и интернет-магазинов. Классика, с которой редко ошибаются.

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

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

Nielsen Norman Group описывает выбор внутри дерева через два полюса. Плоская иерархия — широкая и короткая, три уровня, много пунктов на каждом. Глубокая — пять уровней, мало категорий на каждом шаге. Оба полюса рабочие: вопрос не в количестве уровней, а в том, есть ли с верхнего уровня короткие переходы вниз.

Тип структуры определяется типом сайта: для сайта-визитки хватит одного уровня, для корпоративного сайта работает дерево на два-три уровня, для интернет-магазина — дерево с фильтрами и сетевыми связями между категориями.

Что Google действительно документирует о структуре

Всё, что ниже, есть в документации Google Search Central дословно.

Читаемые слова вместо идентификаторов. Google просит использовать в URL понятные слова, а не длинные числовые ID, и слова на языке вашей аудитории — включая транслитерацию, если она уместна. Для товарных страниц есть прямой пример: /product/black-t-shirt-with-a-white-collar рекомендовано, /product/3243 — нет.

Дефисы, а не подчёркивания. Формулировка дословная: рекомендуем использовать дефисы (-) вместо подчёркиваний (_) для разделения слов в URL. Одна из немногих вещей в структуре URL, о которых Google говорит прямо, без «зависит».

Регистр имеет значение. /APPLE и /apple для Google — две разные страницы с собственным содержимым. Классическая проблема сайтов, где часть ссылок сгенерирована с заглавной буквы.

Фрагменты не строят структуру. Google не поддерживает смену содержимого страницы через #-фрагмент. Раздел, который существует только как якорь, для поиска не существует как страница.

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

Ссылки — только <a href>. Google сканирует ссылки лишь тогда, когда это HTML-элемент <a> с атрибутом href. В документации перечислены как раз те случаи, на которых современные сайты и ломаются: маршруты фреймворков вроде routerLink, <span> с атрибутом href, переходы через onclick. Красивая SPA-навигация без настоящих ссылок — это структура, которую видит только человек. Такие вещи вылавливает SEO-аудит, и вылавливает регулярно.

Мультиязычность. Для сайтов на нескольких языках или на несколько стран Google называет две приемлемые схемы: отдельный домен страны (example.de) или подпапка на общем домене (example.com/de/). Мы на своём сайте используем вторую — именно поэтому русская версия живёт в /ru/.

Сколько уровней вложенности делать на самом деле

У правила трёх уровней URL ровно та же природа, что и у правила трёх кликов: его пересказывают, но первоисточника у него нет. В документации Google порога вложенности не существует.

Что там существует — это порог объёма. Google пишет: если на сайте больше нескольких тысяч URL, способ организации контента может повлиять на то, как Google сканирует и индексирует сайт; в частности, группировка похожих тем по папкам помогает Google понять, как часто обновляются URL внутри каждой папки. Это честная граница, и её стоит проговорить прямо: сайту на 40 страниц структура папок не даёт никакого выигрыша в сканировании. Делайте её для людей.

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

Практический вывод вместо цифры «три». Глубина сама по себе не наказывается — наказывается неочевидность пути. Вместо того чтобы резать уровни, делайте другое: давайте прямые ссылки на важные страницы с главной и из разделов, держите смежные категории доступными друг из друга, показывайте в контенте ссылки на конечные страницы. Nielsen Norman Group формулирует это так: важнее сырого количества кликов то, чтобы навигация была хорошо организована и имела понятные пути. Как это влияет на позиции в целом — в материале о поисковой оптимизации сайта.

Хлебные крошки — не зеркало URL

С хлебными крошками делают две типичные ошибки, и обе хорошо видны на любом каталоге.

Первая: крошки делают копией URL-адреса. Google говорит обратное — предоставляйте хлебные крошки, которые отражают типичный путь пользователя к странице, а не копируют структуру URL. Разница становится видимой на товаре, к которому ведут три разные дороги: из категории, из подборки и из раздела бренда. Для таких случаев Google разрешает разметить на одной странице несколько цепочек крошек.

Вторая: крошки лепят везде. NN/g определяет их как список ссылок на текущую страницу и её «предков» вплоть до главной. И прямо называет, кому они не нужны: плоским иерархиям на один-два уровня и линейным сайтам. На сайте-визитке крошки — просто шум.

И третье, о чём вспоминают реже первых двух, — разметка. Google описывает крошки как обозначение позиции страницы в иерархии сайта, и для поиска они существуют не как визуальный элемент, а как структурированные данные BreadcrumbList. В спецификации schema.org это цепочка связанных веб-страниц, которая обычно заканчивается текущей страницей. Поле position там не имеет отдельного смысла: просто целые числа, начиная с единицы. Части URL и без разметки могут показываться в выдаче как крошки, поэтому адрес — элемент интерфейса, а не техническая строка. Но управляемая разметка даёт управляемый результат, а ставят её за полчаса.

Фасетная навигация — где структура размножается сама

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

Механизм Google описывает так: URL, созданные фасетной навигацией, выглядят новыми, и краулер не может определить их полезность, не просканировав; поэтому он обычно обходит очень большое количество фасетных URL, прежде чем его процессы поймут, что эти адреса на самом деле бесполезны. То есть платит за фильтры не сервер, а скорость сканирования полезных страниц.

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

Выбор между двумя подходами простой. Если комбинация фильтров имеет собственный поисковый спрос — «женские кроссовки Nike» люди ищут, — она заслуживает отдельной индексируемой страницы с текстом и метаданными. Если спроса нет — «сортировать по цене, показать по 48» — этой комбинации отдельный URL не нужен. Google отдельно просит не класть в адреса временные параметры: идентификаторы сессий, трекинговые коды, относительные значения вроде location=nearby или time=last-week и текущее время.

Есть ещё одна сторона каталога, которую тоже решает структура. Baymard измерял, сколько крупных ecommerce-сайтов дают перейти между соседними категориями, не поднимаясь вверх по иерархии: поддерживают такое поведение 53%, а 47% показывают только список товаров и фильтры плюс путь наверх. Рекомендация по итогам тестирований — показывать соседние категории на всех страницах категорий. Так глубина перестаёт мешать: из любой точки каталога видно соседей. Вместе с категориями планируют и наполнение каталога — категория без товаров в структуре выглядит как ошибка.

Карта сайта и поддомены — два технических ограничения

Карта сайта — это не структура, а её перечень для поисковой системы. Два ограничения из документации стоит знать заранее.

Один файл карты ограничен 50 МБ в распакованном виде или 50 000 URL. Дальше — индексный файл и несколько карт. Для большинства бизнес-сайтов цифра недостижима, для каталога с вариантами товаров — вполне реальна.

Второе: карта действует только на потомков папки, в которой она лежит. Именно поэтому её кладут в корень домена, а не рядом с разделом.

Отдельно о поддоменах. Это структурное решение с последствиями, а принимают его обычно легкомысленно. Краулинговая инфраструктура Google определяет сайт как уникальный хост: www.example.com и code.example.com — это разные сайты с разными бюджетами сканирования. Вынести блог или магазин на поддомен — значит начать накапливать сигналы для него отдельно. Подпапка остаётся частью основного сайта. При прочих равных мы всегда делаем подпапку, и на собственном сайте тоже.

Как перестроить структуру и не потерять трафик

Переделывать структуру приходится почти каждому сайту, который прожил несколько лет. Вопрос лишь в том, по какому плану.

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

301 не сжигает вес. В документации о переезде со сменой URL сказано прямо: постоянные редиректы, в том числе 301, не приводят к потере PageRank. Цена перестройки не в потере веса — она во времени и в тщательности.

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

Редиректы живут минимум год. Рекомендация дословная: держите редиректы как можно дольше, в общем случае минимум год. То есть старые адреса не «выключаются после переезда» — они обслуживаются ещё двенадцать месяцев минимум.

Порядок работ, по которому мы это делаем:

1. Выгрузка всех имеющихся URL. Сканирование сайта плюс данные Search Console плюс карта сайта. На выходе — полный список адресов с трафиком и позициями, а не только тех, что есть в меню.
2. Проектирование новой структуры. Категории, вложенность, схема адресов, точки входа. На выходе — схема на один лист, которую понимает и разработчик, и владелец.
3. Карта соответствий старое → новое. Для каждого старого адреса — конкретный новый, а не главная страница. На выходе — CSV, в котором у каждой строки есть пара.
4. Внедрение 301 и проверка. Цепочки редиректов раскручиваются до одного перехода, внутренние ссылки переписываются на новые адреса. На выходе — ни одной ссылки на старый URL внутри сайта.
5. Наблюдение в Search Console. Индексация новых адресов, покрытие, ошибки сканирования. На выходе — подтверждение, что новые URL зашли в индекс, а старые отдают 301.

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

Если структура уже болит, а перестраивать страшно, это нормальная работа в рамках SEO-продвижения — с картой соответствий, планом релиза и контролем после него.

Как составить структуру сайта с нуля — порядок действий

Для нового проекта порядок такой, и он редко меняется.

1. Собрать спрос. Семантика показывает, что люди ищут и какими словами. Категория без спроса — это категория, которую вы придумали для себя.
2. Сгруппировать запросы в страницы. Одна группа — одна страница. Две страницы под одно намерение будут конкурировать между собой в выдаче.
3. Разложить страницы по уровням. Главная, разделы, конечные страницы. Не по правилу трёх кликов, а по тому, очевиден ли путь.
4. Назначить адреса. Читаемые слова, дефисы, нижний регистр, без параметров и дат.
5. Спроектировать навигацию. Меню, крошки там, где уровней больше двух, перелинковка между смежными страницами.
6. Проверить доступность каждой страницы. У каждой важной страницы должна быть минимум одна входящая ссылка обычным <a href>.

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

FAQ