Структура сайту — як скласти, щоб не переробляти через рік

Найпоширеніша порада про структуру сайту звучить так: будь-яка сторінка має бути не далі трьох кліків від головної. Її переказують агентські блоги, її пишуть у технічних завданнях, під неї ламають логічні каталоги. Джерела в неї немає.

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