Структура URL: повний посібник з адрес сторінок, які не можна міняти після запуску

Коротка відповідь: URL — це первинний ключ сторінки в пошуку. Позиції, назбирані посилання, історія в Search Console, цитування в AI-відповідях — усе прив'язане до конкретної адреси. Змінюєте адресу — починаєте стосунки з Google спочатку, навіть із бездоганно налаштованими редиректами. Тому рішення з цього матеріалу треба ухвалити до релізу, а не після.

За останні роки через наші аудити пройшли сотні сайтів із падінням трафіку. І приблизно в кожному п'ятому випадку корінь був не в контенті й не в посиланнях, а в тому, що хтось одного разу вирішив навести лад в адресах. Лад навели. Трафік поїхав.

Цей матеріал — повний посібник з адрес: від анатомії URL до карти редиректів під час переїзду. З розбором того, як ці задачі вирішують Rozetka, Comfy, Prom і Makeup — не за підручником, а за їхніми фактичними адресами та robots.txt. І з нашими власними граблями, на які ми наступили в серпні на власному ж сайті.

З чого складається URL: анатомія адреси

Перш ніж сперечатися про дефіси й транслітерацію, варто домовитися про слова. Візьмімо реальну адресу й розберімо її на частини:

https://rozetka.com.ua/ua/maska-dlya-litsa/c4657310/producer=face-boom/?sort=cheap#reviews

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

Що Google вимагає формально, а що просто радить

Вимог у Google небагато, і вони нудні. Усе інше — практика, яка допомагає людям і роботам, але формальним правилом не є. Розділяти ці речі корисно: у суперечках із розробником ви точно знатимете, де стандарт, а де ваші вподобання.

Що обов'язково

Відповідність стандарту. Google Search підтримує URL за стандартом IETF STD 66. Зарезервовані символи мають бути відсотково закодовані. Якщо розробник запхав в адресу пробіл, лапку чи квадратну дужку в сирому вигляді — ви за межами стандарту, і далі поведінка непередбачувана.

Фрагменти не змінюють контент. Адреси на кшталт example.com/#/catalog — типова хвороба односторінкових застосунків на старих фреймворках. Google такі маршрути окремими сторінками не бачить. Розв'язання — History API, тобто справжні шляхи замість решітки.

Регістр має значення. У документації сказано прямо: URL чутливі до регістру, /APPLE і /apple — різні сторінки. Рекомендацією це не є — так влаштований веб.

Що рекомендується

Тут Google дає пари «добре / погано», і процитувати їх краще точно:

Пояснення про дефіс і підкреслення суто технічне: для пошуковика color_profile — одне слово, color-profile — два. Різниця впливає на те, як система розбирає адресу на токени.

Google окремо перелічує параметри, які найчастіше плодять дублі: мітки реферера (ref=foo%2Cbar), ідентифікатори сесій (sessionid=6EE2BF1AF6A3D705D5561B7C3564D9C2), сортування (search_sort=relevance). Рекомендація — закривати такі адреси в robots.txt.

Як це вирішують великі українські магазини: розбір реальних адрес

Теорія — теорією, але цікавіше подивитися, що роблять сайти, які в цій видачі живуть роками. Я вивантажив по 120 найтрафіковіших адрес у чотирьох великих українських проєктів і подивився, які рішення там ухвалені. Плюс прочитав їхні robots.txt, бо без нього картина неповна.

Rozetka: фільтри винесені в шлях, усе з параметрами закрито

Найцікавіше рішення з чотирьох. Дивіться на реальні адреси з топу:

https://rozetka.com.ua/kalkulyatory/c2560887/
https://rozetka.com.ua/ua/hammer-tel000844/p458511719/
https://rozetka.com.ua/maska-dlya-litsa/c4657310/producer=face-boom/
https://auto.rozetka.com.ua/ua/mini-azs/c4630082/razreshennie-gidkosti=benzin/
https://rozetka.com.ua/ua/producer/jysk/

Що тут закладено:

• Слово плюс ідентифікатор. Категорія — це /kalkulyatory/c2560887/: людиночитаний слаг і технічний ID з префіксом c (category). Товар — /hammer-tel000844/p458511719/, де p означає product. Така схема дозволяє змінювати назву категорії, не ламаючи маршрутизацію: система знаходить сторінку за ID, а слаг працює на людей і на сніпет.
• Фільтр — це сегмент шляху, а не параметр. producer=face-boom/ стоїть у шляху й закінчується скісною рискою. Формально це виглядає як параметр, але синтаксично — частина шляху.
• Скісна риска в кінці завжди. Зі 120 адрес — 120 зі скісною. Нуль винятків, тобто правило прошите на рівні платформи.
• Параметрів у топі немає взагалі. Жодної адреси зі знаком ? серед найтрафіковіших.

Останні два пункти пояснює їхній robots.txt, і ось тут стає по-справжньому цікаво. Там стоїть правило Disallow: /*?* — тобто закрито взагалі все, де є знак питання. Плюс окремо закриті */search/, */comparison/, */cabinet/*, */section/*/*/, мітки gclid, utm_medium=rooms, yclid, tab=.

А тепер ключове: при цьому стоїть Allow: */section/*/producer=*/. Тобто фільтр за виробником — єдиний, який вони цілеспрямовано відкрили для обходу. Але відкритий він лише в одиничному вигляді — одразу під дозвільним правилом ідуть два заборонні:

Allow:    */section/*/producer=*/
Disallow: */section/*/producer=*;*/
Disallow: */section/*/producer=*,*/

Крапка з комою й кома — це роздільники, якими платформа склеює кілька значень фільтра в одному сегменті. Отже, «бренд» відкритий, а «бренд + ціна», «бренд + колір», «бренд + будь-що ще» — закриті. Застереження щодо формулювань: robots.txt керує обходом, а не індексацією; закрита в ньому адреса теоретично може потрапити в індекс за зовнішніми посиланнями, але без вмісту. На практиці для комбінацій фільтрів цього досить.

Складаємо два спостереження — і отримуємо усвідомлену стратегію, а не випадковість. Усе, що потрапляє в параметри, у Rozetka за визначенням не індексується. Усе, що має індексуватися, живе в шляху. А з десятків можливих фільтрів для індексу обрано один — за брендом, бо «маска для обличчя Face Boom» люди справді шукають, а «маска для обличчя від 200 до 300 гривень, сортування за ціною» — ні.

Є в них і слабке місце, яке видно в тих самих вивантаженнях:

https://rozetka.com.ua/ua/1162060/c1162060/razmer-131496=copy_xxxs_59ee2f126acdc/
https://rozetka.com.ua/ua/2577232/c2577232/producer=beking/

Тут слаг загубився, лишився голий ID, а значення фільтра виглядає як внутрішній технічний ключ: copy_xxxs_59ee2f126acdc. Так виглядає адреса, згенерована системою без людської участі — рівно те, від чого застерігає документація Google. Навіть у лідера ринку такі місця є, і це корисно знати: ідеальних структур не буває, бувають продумані в головному.

Comfy: фільтри в шляху через подвійне підкреслення

https://comfy.ua/ua/smartfon/brand__apple__seriya_smartphone__apple-iphone-17/
https://comfy.ua/smartfon/brand__apple__seriya_smartphone__apple-iphone-17-pro-max/
https://comfy.ua/ua/podstavka-antivibracionnaja-savitel-m-jaki-lapki-otzyvy.html

Comfy пішла тим самим шляхом — фільтри в URL як сегмент, а не параметр, — але реалізувала це через подвійне підкреслення як роздільник полів: brand__apple__seriya_smartphone__apple-iphone-17.

Формально це рівно те, чого Google радить уникати: підкреслення замість дефіса. Усередині значень при цьому використовується дефіс (apple-iphone-17-pro-max), а між полями — подвійне підкреслення. Логіка читається: підкреслення як службовий роздільник рівнів, дефіс як роздільник слів.

Чи працює це? Судячи з того, що саме ці адреси збирають трафік — так, працює. Але повторювати я б не радив: Comfy може дозволити собі йти проти рекомендації за рахунок авторитету домену, у нового сайту такого запасу немає.

Друге, що впадає в око, — .html в адресах товарів і суфікс -otzyvy для сторінок відгуків. Розширення .html — спадок старих CMS. Саме собою воно не шкодить, але додає символів і натякає на технологію, яка може змінитися. Якщо сьогодні починаєте новий проєкт — розширення в адресі не потрібне.

Третя деталь — транслітерація. kak-udalit-pyatna-na-ehkrane-noutbuka: «экране» перетворилося на ehkrane. Це машинна транслітерація за стандартом, де «э» передається як eh. Читається важко. Нижче окремо розберу, чому вибір таблиці транслітерації — не формальність.

Prom: великі літери в адресах

https://prom.ua/ua/Avtozapravochnye-stantsii.html
https://prom.ua/Rozetki.html
https://prom.ua/ua/p2012211303-podarochnyj-nabor-noskov.html
https://prom.ua/m-6437202537981145948-smartfon-hammer-energy.html

Тут два спостереження. Перше: структура пласка. Зі 120 адрес 48 мають глибину в один сегмент, 66 — два. Для маркетплейсу з мільйонами товарів це усвідомлене рішення: не вибудовувати глибоку ієрархію, а тримати все близько до кореня.

Друге: великі літери в адресах — Avtozapravochnye-stantsii, Rozetki, Gorillas-market. З огляду на те, що URL чутливі до регістру, це зайвий ризик: будь-яке посилання, де хтось напише адресу малими, веде на неіснуючу сторінку або на дубль. Prom із цим живе, але для нового проєкту правило просте — тільки нижній регістр, а варіант в іншому регістрі редиректити на канонічний.

Ідентифікатори на кшталт m-6437202537981145948 — дев'ятнадцять цифр — це вже за межею розумного. Таку адресу неможливо ні прочитати, ні продиктувати.

Makeup: адреси без слів

https://makeup.com.ua/ua/brand/2321515/
https://makeup.com.ua/ua/brand/232525/
https://makeup.com.ua/brand/29143/

Зі 120 трафікових адрес 90 містять числовий ідентифікатор, а в сторінок брендів адреса складається буквально зі слова brand і номера. Ні назви бренду, ні категорії.

Це рівно той антиприклад, який Google наводить у документації. Чи працює сайт? Працює, трафік є. Але уявіть: ви копіюєте таке посилання в месенджер, і людина на тому боці бачить makeup.com.ua/ua/brand/232525/. Жодного сигналу про те, що всередині. Клікабельність такого посилання в листі, у сніпеті, у чаті свідомо нижча, ніж у /ua/brand/estee-lauder/.

Зведена таблиця рішень

Спільне в усіх чотирьох: мовна версія винесена в сегмент шляху, а не в піддомен і не в параметр. Для українського ринку це де-факто стандарт, і сперечатися з ним на новому проєкті сенсу немає.

Транслітерація чи кирилиця: що обрати українському сайту

Це перша суперечка, яка трапляється майже на кожному проєкті. Розробнику простіше віддати кирилицю — CMS так уміє з коробки. Клієнту кирилиця здається зрозумілішою. Формально Google працює і з тим, і з тим.

Але в документації Google радить саме закодований варіант замість нелатиниці у відкритому вигляді. Причина в тому, що кирилична адреса живе гарно рівно до першого копіювання. В адресному рядку браузера ви бачите /маска-для-обличчя/. Варто скопіювати посилання й вставити в лист, у месенджер, у рекламний кабінет, у звіт — і там опиниться /%D0%BC%D0%B0%D1%81%D0%BA%D0%B0-%D0%B4%D0%BB%D1%8F-%D0%BE%D0%B1%D0%BB%D0%B8%D1%87%D1%87%D1%8F/. З тридцяти символів виходить сто з гаком.

Практична різниця виглядає так:

Для українського проєкту є окремий чинник, про який згадують пізно. Якщо сайт багатомовний, кирилиця змушує тримати різні набори правил для української та російської версій, і будь-яка похибка в передачі «і», «ї», «є» народжує нову адресу. Ми на своєму сайті тримаємо латинські слаги всіма трьома мовами: /razrabotka-sajtov/, /rozrobka-saytiv/, /website-development/. Кожна адреса мовою своєї аудиторії, і при цьому будь-яку з них можна продиктувати телефоном.

Яку таблицю транслітерації брати

Якщо обрали транслітерацію, наступне питання — за якою системою. Варіантів багато, і вони дають різний результат для одного й того самого слова. В Україні є офіційний стандарт — постанова Кабміну №55 від 27 січня 2010 року, за якою оформлюють закордонні паспорти й географічні назви. Проблемні літери там передаються так:

Практичний висновок не в тому, щоб сліпо взяти цей стандарт для всіх слагів. Він оптимізований під паспорти, а не під читання в пошуку: Koriukivka людині читати складніше, ніж koryukivka. Висновок в іншому: таблиця має бути одна на весь сайт і має бути зафіксована в коді. Найгірше, що може статися, — половина адрес згенерована одним транслітератором, половина іншим, і в структурі одночасно живуть /kharkiv/ і /harkov/.

І окремо: не змішуйте українську та російську транслітерацію в одній версії сайту. Помилка на кшталт ehkrane для «экране», яку видно в Comfy, народжується саме з машинної таблиці, застосованої без розбору.

Довжина URL: скільки символів і чому це знову стало важливо

Раніше на довжину дивилися як на справу смаку. У 2026-му з'явилися дані, через які варто дивитися уважніше.

Semrush у січні 2026-го розібрав 5 мільйонів URL, процитованих ChatGPT Search і Google AI Mode, — 378 тисяч цитувань в аналізі — і подивився, що в цих сторінок спільного. За довжиною слага картина така: найбільше цитувань (близько 87 тисяч) зібрали адреси зі слагом у 21–25 символів, далі йдуть короткі, 6–10 символів. Робочий діапазон — приблизно 17–40 символів.

Застережуся чесно: це кореляція, а не причина. Ніхто не довів, що модель віддає перевагу коротким адресам. Радше короткий осмислений слаг — побічна ознака сторінки, яку робили руками, а не вивантажували генератором. Але як орієнтир під час проєктування — цілком годиться.

Є й технічна стеля, про яку згадують лише тоді, коли щось падає. Практичний ліміт визначає не стандарт, а найслабша ланка в ланцюжку:

Для звичайних сторінок це неактуально. Але для магазину, де користувач може накрутити вісім фільтрів поспіль, а система складе їх в одну адресу, — цілком реальний сценарій відмови. Причому відвалиться не найтерпиміший компонент, а найсуворіший: якщо у вас NGINX перед застосунком, стеля буде 4 096 незалежно від того, що вміє браузер.

Практичний орієнтир для сторінки, яку ви просуваєте: слаг 20–40 символів, уся адреса в межах 75–100. Не тому що далі штраф, а тому що далі вона перестає вміщатися в сніпет, у лист і в голову.

Вісім адрес однієї сторінки: як дублі народжуються на рівному місці

Найдорожчі проблеми виникають не там, де сеошник сперечається з копірайтером про ключове слово в слазі. Вони виникають у місцях, про які на старті не думає ніхто.

Візьміть будь-яку сторінку свого сайту. Найімовірніше, вона доступна щонайменше за вісьмома адресами:

Кожен варіант, який віддає код 200 без канонічного посилання на основний, — окрема сторінка в очах пошуковика. Вага розмазується, у звітах з'являються дублі, а в AI-відповідь потрапляє не та адреса, яку ви просували.

Перевіряється це за п'ять хвилин із термінала:

curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" http://site.com/catalog
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://www.site.com/catalog
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://site.com/Catalog/

Усі три мають показати 301 і одну й ту саму цільову адресу. Якщо хоч одна віддає 200 — у вас дубль. Якщо показує 302 — ви повідомляєте пошуковику, що переїзд тимчасовий, і сигнали переносяться гірше.

Окрема пастка — ланцюжки. Коли http://www.site.com/Catalog редиректить на https://www.site.com/Catalog, той на https://site.com/Catalog, а той уже на https://site.com/catalog/ — це три стрибки замість одного. Google прямо попереджає, що довгі ланцюжки редиректів негативно впливають на кравлінг: кожен стрибок — окремий запит. Правильно — один редирект одразу на фінальну адресу.

Глибина вкладеності: скільки рівнів припустимо

Друге питання після «які слова в адресі» — «скільки сегментів». Тут є два обмеження: технічне й поведінкове.

Технічне пов'язане з кравлінгом. Google вважає бюджет обходу критичним для сайтів від мільйона унікальних сторінок за оновлення раз на тиждень або приблизно від 10 тисяч сторінок за щоденних змін. Якщо ваш сайт менший — про бюджет можна не думати. Якщо більший — кожна зайва сходинка ієрархії, кожен зайвий дубль і кожен ланцюжок редиректів з'їдають обхід, який міг би дістатися товарам.

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

При цьому глибина шляху в адресі й глибина кліків — різні речі, які часто плутають. У Rozetka розподіл адрес за глибиною шляху такий: 3 сегменти — 18 адрес зі 120, 4 сегменти — 56, 5 сегментів — 38. Тобто більшість трафікових сторінок лежать на четвертому-п'ятому рівні шляху. Але кліками вони досяжні значно швидше, бо на них ведуть посилання з головної, з меню, з блоків перелінковки.

Висновок: довжина шляху в адресі — питання зрозумілості, а не ранжування. Не варто вибудовувати /catalog/electronics/computers/laptops/gaming/asus/rog-strix/ заради ієрархії. Але й розплющувати все в один рівень, як Prom, варто лише якщо у вас маркетплейс із мільйонами позицій і власна логіка навігації.

Фільтри й фасетна навігація: де магазини втрачають найбільше

Фасетна навігація вміє створювати десятки тисяч адрес із нічого. Рахується легко: 10 брендів × 6 розмірів × 8 кольорів × 4 сортування × 20 сторінок пагінації — це 38 400 адрес на одну категорію. Усі вони віддають код 200, усі містять майже однаковий контент, і всі конкурують між собою.

У рекомендаціях Google для e-commerce є кілька конкретних правил:

• Формат /t-shirt?color=green замість /t-shirt?green — значення завжди з іменем параметра.
• Не дублювати один і той самий параметр в адресі.
• Не пускати в URL тимчасові параметри: сесії, мітки часу, фільтри на кшталт «поруч зі мною».
• Варіанти товару — або сегментом шляху /t-shirt/green, або параметром /t-shirt?color=green; для необов'язкових параметрів канонічною вважається версія без параметра.
• Порожні категорії закривати noindex або віддавати 404.
• Кожна сторінка пагінації має мати свою унікальну адресу. Google окремо зазначає, що найбільше помилок у структурі URL припадає саме на пагінацію.

Але технічна частина тут вторинна. Первинне питання — чи потрібна така сторінка взагалі. Микола на розборі структури каталогу формулює це жорстко:

«Ви створюєте фільтр — насамперед у вас мають бути товари під цей фільтр. Тобто під створений фільтр має бути створений унікальний контент».

І далі він пояснює, звідки береться унікальність у різних типів бізнесу:

«В інтернет-магазину унікальним контентом є картки товарів — це їхній унікальний контент. Якщо ж ви сайт послуг, то вашим унікальним контентом є чітко прописана послуга під обрані запити».

Це робочий критерій, який економить місяці. Перш ніж відкривати комбінацію фільтрів для індексації, дайте відповідь на три питання: чи є під неї товари, чи є під неї попит у семантиці, чи відрізнятиметься видача за нею від батьківської категорії. Якщо хоча б одна відповідь «ні» — адресу створювати не треба.

Три способи поводитися з фільтрами

Схема Rozetka — це перший і другий підхід одночасно: усе зі знаком питання закрито в robots.txt, а з фільтрів у шлях винесено й відкрито для індексу рівно один — за виробником. Така жорсткість виглядає грубо, але саме вона пояснює, чому в топі їхніх адрес немає жодної сміттєвої.

Пагінація: де найчастіше ламається структура

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

Що має бути: у кожної сторінки списку — своя унікальна адреса (/catalog/page/2/ або /catalog/?page=2), власний rel="canonical" на саму себе, а не на першу сторінку, і осмислений title, що відрізняється від першої сторінки.

Що часто трапляється замість цього:

• Canonical з усіх сторінок на першу. Логіка «перша сторінка головна» здається розумною, але так ви повідомляєте пошуковику, що товари з другої й далі йому не потрібні. На великих каталогах це прямий шлях до того, що половина асортименту не потрапляє в індекс.
• Нескінченне прокручування без адрес. Товари підвантажуються скриптом, адреса не змінюється, у сторінки 40 ніколи не буде свого URL. Розв'язання — підвантаження з паралельним оновленням адреси через History API і робочі посилання пагінації в розмітці.
• Дублювальний текст категорії на всіх сторінках. Опис категорії на 2000 знаків, повторений на всіх 30 сторінках пагінації, — це 30 майже однакових документів. Текст лишають тільки на першій.
• Комбінація пагінації з фільтрами й сортуваннями. /catalog/?page=7&sort=price&color=red — найплодючіший генератор сміття з усіх.

UTM, gclid та інші мітки: як аналітика плодить дублі

Окремий клас адрес, про які під час проєктування структури не думають узагалі, бо їх створює не розробник, а маркетолог.

Будь-яке посилання з міткою — ?utm_source=facebook&utm_medium=cpc&utm_campaign=autumn — технічно нова адреса. Поки такі посилання живуть тільки в рекламі, біди немає. Проблема починається, коли їх хтось опублікував: партнер поставив посилання з міткою на своєму сайті, блогер вставив у пост, менеджер надіслав клієнту, а той запостив у спільноту. Тепер у сторінки з'явився зовнішній дубль, який пошуковик обійшов і проіндексував.

Як із цим живуть великі магазини — видно з їхніх robots.txt. Rozetka закриває /*gclid=*, /*utm_medium=rooms*, yclid, і на додачу все поспіль через Disallow: /*?*. Comfy закриває *utm_*, *?gclid=*, *?yclid=*, а також store_id і city_id — параметри вибору магазину й міста, які інакше помножили б каталог на кількість міст.

Мінімальний набір для будь-якого комерційного сайту:

• rel="canonical" на чисту адресу з усіх сторінок із мітками — це основний механізм.
• Закриття міток у robots.txt — як страховка від зайвої витрати обходу.
• Перевірка в Search Console: звіт «Сторінки» покаже, чи потрапили адреси з мітками в індекс.

Важливий нюанс: robots.txt забороняє обхід, але не гарантує відсутності в індексі. Якщо на закриту адресу ведуть зовнішні посилання, вона може потрапити у видачу без опису. Тому canonical первинний, robots.txt вторинний.

Сторінки під міста: найдорожча помилка в структурі

Історія, яка повторюється в клієнтів із завидною регулярністю. Бізнес працює в кількох містах, хтось радить зробити сторінку під кожне місто, і в структурі з'являються десятки адрес, що відрізняються одним словом.

«Коли до мене приходить клієнт і каже: я займаюся документацією, і в мене там для Барнаула одна сторінка, для Абакана інша, а за фактом вони нічим одна від одної не відрізняються, крім назви міста — це дублі та сміття».

Механіка тут така. Проблема не в тому, що в адресі є місто. Проблема в тому, що за адресою немає нічого свого. У магазину унікальність забезпечують картки товарів — на різних фільтрах виводяться різні товари. У сайту послуг такого джерела немає, його треба створювати руками.

Микола про цю стратегію висловлюється недвозначно:

«Я є противником стратегії, коли на одну сторінку послуг створюється от скільки міст, стільки копій. Ця стратегія дозволяє інколи обманювати індекс, інколи за низькою частотою вдається пролізти, але Google уже це все склеює».

При цьому в тому самому розборі він показує клієнта, у якого вийшло: сервіс із ремонту пральних машин, де сторінки розведені не за містами, а за марками. У кожної марки свої коди помилок, свої типові поломки, свій блок запитань і відповідей. /remont-indesit/ і /remont-bosch/ справді різні сторінки, бо в машин різні кнопки й різні несправності:

«У різних пральних машин найчастіше реально різні поломки, і для кожної сторінки зібрані різні запитання і під них дібрані різні відповіді. Навіть коди помилок».

Робочий варіант, який ми бачили в проєктах: розводити сторінки не за географією, а за товаром чи послугою, а регіональність закривати окремим шаром. У магазині дитячих товарів у Молдові, наприклад, зростання дало не нарізання за містами, а нові підкатегорії — візочки, ліжечка, манежі, — кожна зі своїм асортиментом і своїм попитом.

Якщо регіональні сторінки все-таки потрібні — а для сервісного бізнесу вони часто справді потрібні, — мінімальний набір відмінностей виглядає так: своя адреса й телефон, свої ціни або терміни виїзду, свої відгуки клієнтів із цього міста, своя карта, свій список виконаних робіт. Якщо нічого з цього немає, сторінка не виживе, хоч би якою правильною була її адреса.

URL і AI-пошук: що змінилося у 2026

Раніше адреса була питанням гігієни. Тепер у неї з'явилася друга функція — бути цитованою.

Коли ChatGPT, Perplexity або Google AI Mode формують відповідь, вони показують джерела. Користувач бачить вашу адресу, і рішення клікати чи ні ухвалюється за частку секунди за тим, що в цій адресі написано. Адреса на кшталт makeup.com.ua/ua/brand/232525/ не повідомляє нічого. Адреса /struktura-url/ повідомляє все.

Дані з уже згаданого дослідження Semrush по 5 мільйонах процитованих URL дають ще кілька орієнтирів окрім довжини слага. На процитованих сторінках систематично трапляється структурована розмітка: Organization — у 25% сторінок, процитованих ChatGPT, і 34% у Google AI Mode; Article — 20% і 26%; Breadcrumb — 15% і 20%. Open Graph присутній у 40–60% процитованих сторінок.

Розмітка Breadcrumb тут важлива саме в контексті адрес: вона описує пошуковику ту саму ієрархію, що закладена в шлях URL. Якщо шлях каже одне (/blog/razrabotka/struktura-url/), а хлібні крихти інше, ви самі створюєте собі різночитання. Узгодженість шляху, крихт і розмітки — це одна робота, а не три.

Ще раз чесно: кореляція не дорівнює причині. Жодна правка адреси не змусить модель вас процитувати. Але набір ознак «коротка осмислена адреса + узгоджені крихти + розмітка» описує сторінку, яку робили усвідомлено, і такі сторінки цитують частіше.

Багатомовність в адресах

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

Google називає прийнятними два підходи — окремий домен на країну (example.de) і підпапку (example.com/de/). Третій варіант, піддомен (de.example.com), формально працює, але означає, що авторитет ви будуєте майже з нуля для кожної версії.

Усі чотири розібрані вище магазини використовують підпапку. Це не збіг: для ринку, де одна компанія працює з двома мовами в одній країні, підпапка — єдиний варіант, за якого посилальна вага не розмазується.

Далі починається місце, де помиляються майже всі. Слаги всередині мовних версій мають бути локалізовані, а не скопійовані. Якщо у вас українська версія лежить за адресою /ua/razrabotka-sajtov/, тобто з російським слагом в українській папці, ви отримуєте адресу, яку не читає жодна аудиторія. Правильно — /ua/rozrobka-saytiv/.

І кожна версія має посилатися на решту через hreflang, включно із собою, плюс x-default для версії за замовчуванням. Без цього пошуковик може показати українцю англійську версію, а іноземцю — українську.

Наскільки це масштабується, видно з нашого проєкту фінансової платформи: 44 мовні локалі, 10 681 перевірена адреса в кеші карти сайту й 57 070 hreflang-альтернатів без жодного некоректного значення. За такої кількості зв'язок адреси перестають бути питанням смаку — будь-яка нестабільність у правилах генерації слага множиться на сорок чотири версії.

Кейс: що дає перенесення фільтрів із параметрів у шлях

Щоб попередні розділи не виглядали теорією — приклад із нашої практики.

Ювелірний інтернет-магазин. Початковий стан: фільтри віддавали динамічні адреси з параметрами, а мета-теги під час застосування фільтра не змінювалися взагалі — хоч би який фільтр людина обрала, title і description лишалися від батьківської категорії. Плюс загальний технічний фон: понад 9 700 помилок і 3 128 сторінок без H1.

Що зробили з адресами: перенесли фільтри з параметрів у людиночитаний вигляд і задали унікальні мета-теги для сторінок фільтрів. Це дозволило повернути трафік за запитами на кшталт «золоті сережки 585 проби» — тими самими комбінаціями «метал + проба + тип виробу», які люди справді шукають.

Результат за рік, з грудня 2024 до грудня 2025: покази в пошуку зросли зі 169 526 до 960 936 — у 5,6 раза, кліки за товарними сніпетами з 1 400 до 7 800, органічний трафік із 45 000 до 51 900 візитів, ROAS з 2,8 до 5,1.

Зверніть увагу на пропорцію: покази зросли в рази, трафік — на 16%. Так і виглядає відкриття довгого хвоста через адреси: багато запитів, у кожного невелика частотність і висока точність наміру.

Коли URL таки треба міняти: карта редиректів

Іноді переробляти адреси справді потрібно: переїзд із конструктора, зміна CMS, злиття двох сайтів, локалізація слагів під мовні версії. Тоді працює один принцип — карта.

Джон Мюллер із Google на питання про ключі успішної міграції відповідає буквально: найважливіше — відстежувати окремі URL, щоб мати чітку карту старих і нових адрес. Друге за важливістю — внутрішня перелінковка: забуті посилання в меню й підвалі, що ведуть на старі адреси, уповільнюють переіндексацію дужче, ніж будь-що інше. Там же він нагадує про rel canonical, про який під час переїзду забувають систематично.

І правило, яке порушують найчастіше: редиректити сторінку можна тільки на суттєво схожий контент. Якщо відповідної сторінки немає — чесний 404 кращий за редирект на головну. Масовий редирект усього поспіль на головну Google розцінює як soft 404: ви втрачаєте і стару сторінку, і час на з'ясування, чому нічого не переноситься.

Порядок робіт під час зміни адрес

1. Зібрати повний список старих адрес. Чотири джерела, і всі потрібні: вивантаження з Search Console (що реально в індексі), sitemap.xml (що ви вважаєте своїми сторінками), логи сервера за 3–6 місяців (що реально запитують, включно зі сторінками, про які ви забули), кравлер на кшталт Screaming Frog (що пов'язано внутрішніми посиланнями). Перетин цих чотирьох списків завжди ширший, ніж очікуєш.
2. Побудувати таблицю «стара → нова». Три колонки: стара адреса, нова адреса, тип відповідності (точна / близька / немає аналога).
3. Окремо вирішити, що робити зі сторінками без аналога. Якщо в сторінки був трафік і посилання — варто створити заміну. Якщо ні — 410 або 404, але не редирект на головну.
4. Налаштувати 301 — одразу на фінальну адресу. Без проміжних стрибків, навіть якщо так простіше написати правило.
5. Оновити внутрішні посилання. У меню, підвалі, текстах статей, у розмітці хлібних крихт, у sitemap. Внутрішні посилання мають вести на нові адреси напряму, а не через редирект.
6. Надіслати новий sitemap і лишити старий доступним кілька тижнів — так Google швидше побачить відповідності.
7. Перевірити фактичні відповіді сервера за всією таблицею. Не конфіг — саме відповіді.
8. Спостерігати 4–8 тижнів за звітами Search Console: помилки 404, сторінки з редиректами, покриття.

Про терміни. За коректного 301 сторінка зазвичай повертається на попередні позиції, але не миттєво: Google має переобійти стару адресу, побачити редирект і перенести сигнали. На невеликому сайті це дні, на великому — тижні, і що більший сайт, то важливіше не витрачати бюджет обходу на ланцюжки й сміття.

Наш випадок: як два шари редиректів завели п'ять мовних адрес не туди

Приклад із власної практики, щоб це не виглядало теорією. Ми пройшли рівно таку міграцію на seoquick.com.ua і наступили на граблі, які варто описати докладно.

Що ми міняли й навіщо

Дістався нам цей сюжет у спадок: українська та англійська версії сайту багато років жили за російськими слагами. Українець, що потрапив на /ua/zakazat-zvonok/, бачив в адресі російське слово; англомовний на /en/raskrutka-v-youtube/ — теж. Мова контенту одна, мова адреси інша — рівно та помилка локалізації, про яку йшлося вище.

У червні 2026-го ми це виправили: згенерували карту редиректів зі старих російськослагових адрес на локалізовані. Російська версія слаги не міняла, тому для неї редиректів немає. Блог, подкасти, вебінари й інструменти не чіпали взагалі — там слаги не змінювалися, а отже, і ризикувати не було навіщо.

Файл правил виглядає так (формат Cloudflare Pages: звідки, куди, код):

# ===== UA — послуги =====
/ua/kontekstnaya-reklama/            /ua/kontekstna-reklama/         301
/ua/poiskovoe-prodvizhenie/          /ua/poshukove-prosuvannya/      301
/ua/texnicheskij-audit/              /ua/tekhnichnyy-audyt/          301
/ua/website-audit/                   /ua/audyt-saytu/                301
/ua/schedule-event/                  /ua/zabronyuvaty-zustrich/      301

# ===== EN — послуги =====
/en/poiskovoe-prodvizhenie/          /en/seo-services/               301
/en/razrabotka-sajtov/               /en/website-development/        301

Зверніть увагу на дві речі, які ми заклали свідомо. Перша: англійські слаги — це не транслітерація, а переклад. /en/razrabotka-sajtov/ стало /en/website-development/, а не /en/razrabotka-sajtov/. Друга: /en/kontekstnaya-reklama/ стало /en/performance-marketing/ — тобто на англійському ринку послуга називається інакше, і адреса це відображає. Механічний переклад слага дав би /en/contextual-advertising/, чого ніхто не шукає.

Де зламалося

Наприкінці серпня ми виявили, що п'ять українських та англійських адрес відкривають російські версії сторінок. Не 404, не помилка сервера — користувач з української версії просто потрапляв на російську сторінку і, судячи з поведінки, ішов.

Причина виявилася в тому, що на нашій інфраструктурі редиректи живуть у двох місцях одночасно. Є файл правил, який ви бачили вище, і є обробник запитів на рівні функцій Cloudflare Pages, де прописані точні відповідності. І обробник спрацьовує раніше за файл: якщо точне правило знайшлося там, до файлу з масками запит уже не доходить.

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

Що я забрав із цієї історії

Перше й головне: карта редиректів має включати не тільки пари «стара → нова», а й те, яким механізмом кожна пара обробляється. Якщо шарів більше одного — а на будь-якому сучасному хостингу з CDN, edge-функціями й правилами на рівні платформи їх зазвичай більше одного, — то перевіряти треба не конфіг, а фактичну відповідь за кожною адресою.

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

while read -r from to; do
  real=$(curl -sI -o /dev/null -w "%{redirect_url}" "https://site.com$from")
  [ "$real" = "https://site.com$to" ] || echo "MISMATCH: $from -> $real (очікували $to)"
done < redirects.tsv

Третє, менш очевидне: мовні редиректи небезпечніші за звичайні, бо ламаються тихо. Побите посилання дає 404, і його видно в Search Console наступного дня. А редирект на сторінку іншої мови віддає чесний код 200 — з погляду будь-якого технічного моніторингу все гаразд. Помітити це можна лише двома способами: очима або за поведінковими метриками конкретних сторінок.

Як перевірити свій сайт: інструменти й команди

Аудит адрес не потребує дорогих інструментів. Ось набір перевірок, який закриває 90% проблем.

Перевірка канонізації хоста і скісної риски

for u in "http://site.com/catalog" "http://www.site.com/catalog" \
         "https://www.site.com/catalog" "https://site.com/catalog" \
         "https://site.com/Catalog/"; do
  printf "%-45s %s\n" "$u" "$(curl -sI -o /dev/null -w '%{http_code} -> %{redirect_url}' "$u")"
done

Очікуваний результат: скрізь 301 і одна й та сама фінальна адреса.

Пошук ланцюжків редиректів

curl -sIL -w "%{url_effective} %{http_code} (стрибків: %{num_redirects})\n" \
  -o /dev/null https://site.com/staraya-stranica

Якщо стрибків більше одного — правило треба переписати так, щоб вело одразу на фінальну адресу.

Що дивитися в Search Console

• Звіт «Сторінки» → «Не проіндексовані». Категорії «Сторінка з переадресацією», «Копія: Google обрав іншу канонічну сторінку», «Виявлено, не проіндексовано» — усі три вказують на проблеми з адресами.
• Інструмент перевірки URL. Показує, яку адресу Google вважає канонічною — і це далеко не завжди та, яку вказали ви.
• Звіт зі статистики сканування. Якщо велика частка запитів припадає на редиректи й 404 — обхід витрачається не туди.

Кравлер

Screaming Frog у безкоштовній версії обходить до 500 адрес — цього вистачає для сайту послуг. Що дивитися насамперед: коди відповідей (вкладка Response Codes), ланцюжки (звіт Redirect Chains), розбіжності canonical, дублі title як непряму ознаку дублів сторінок, адреси з параметрами.

Швидка альтернатива без встановлення — наш онлайн-аудит сторінок: він показує коди відповідей, редиректи, канонічні посилання й дублі за конкретними адресами.

Симптом → причина → як лагодити

Чек-лист перед релізом

Усе, що вище, зводиться до списку рішень, які ухвалюють один раз — до того, як перша сторінка потрапила в індекс.

Канонізація:

• Обрано один варіант хоста (з www чи без) — решта віддає 301.
• Увесь сайт на https, http редиректить одним стрибком.
• Обрано варіант зі скісною рискою в кінці або без — однаково по всьому сайту.
• Адреси в іншому регістрі редиректять на нижній.
• На кожній сторінці є rel="canonical" на саму себе.

Слаги:

• Латиниця, нижній регістр, слова через дефіс.
• Одна таблиця транслітерації, зафіксована в коді.
• Довжина слага в межах 20–40 символів.
• Слаг мовою своєї версії сайту, а не транслітерація з російської.
• Службових ідентифікаторів в адресі немає — або є, але поруч зі словом.

Каталог і фільтри:

• Фільтри віддають ?ключ=значення, а не ?значення.
• Сесії, мітки часу й службові фільтри в адресу не потрапляють.
• Для комбінацій без товарів і без попиту адреси не створюються.
• Відкриті для індексу тільки фільтри, під які є попит у семантиці.
• Порожні категорії віддають 404 або закриті noindex.
• У кожної сторінки пагінації своя адреса й свій canonical на себе.

Мови:

• Мовні версії в підпапках, слаги локалізовані.
• hreflang проставлений в усі боки, включно із самою сторінкою і x-default.
• Перевірено, що мовна версія не редиректить на іншу мову.

Якщо це переїзд:

• Є таблиця «стара → нова», зібрана з чотирьох джерел.
• Усі редиректи — 301 і без проміжних стрибків.
• Внутрішні посилання оновлені на нові адреси.
• Карта перевірена за фактичними відповідями сервера, а не за конфігом.
• Враховані всі шари обробки редиректів, якщо їх більше одного.

Якщо сайт уже запущений і ви не впевнені, що з адресами все гаразд, почніть з онлайн-аудиту або замовте технічний аудит — ми якраз шукаємо такі речі. А якщо новий сайт тільки планується, ці рішення дешевше ухвалити на етапі розробки, поки жодна сторінка ще не проіндексована.

Часті запитання

Чи впливає ключове слово в URL на позиції?

Слабко. Як самостійний фактор ранжування це давно майже нічого не важить. Але ключ в адресі допомагає користувачеві зрозуміти, куди він потрапить, іноді підсвічується у сніпеті й краще виглядає у списку джерел AI-відповіді. Тобто працює на клікабельність, а не на позицію.

Що краще — зі скісною рискою в кінці чи без?

Google ставиться до обох варіантів однаково, важливо лише обрати один і триматися його. Rozetka й Makeup ставлять скісну завжди, Prom майже ніколи — обидві стратегії робочі. Єдине, чого робити не можна, — віддавати код 200 за обома варіантами одночасно.

Чи треба прибирати дати з адрес блогу?

Якщо статті регулярно оновлюються — так, дата в адресі працює проти вас: матеріал 2023 року виглядає застарілим навіть після переписування. Але міняти адреси заради самого лише цього варто тільки разом з іншою запланованою переробкою, а не окремою операцією: ризик переїзду завжди вищий за вигоду від косметики.

Що буде з позиціями, якщо змінити адресу однієї сторінки?

За коректного 301 сторінка зазвичай повертається на попередні позиції, але не миттєво: Google має переобійти стару адресу, побачити редирект і перенести сигнали. На невеликому сайті це дні, на великому — тижні. Проблеми починаються, коли редирект налаштований ланцюжком через дві-три проміжні адреси, коли внутрішні посилання й далі ведуть на старий URL або коли нова сторінка за змістом помітно відрізняється від старої.

Чи можна використовувати кирилицю в домені, а не лише у шляху?

Технічно так, кириличні домени працюють через punycode. Практично — ті самі проблеми, що й із кирилицею у шляху, тільки серйозніші: домен фігурує в пошті, на візитках, у договорах. Для бізнесу, який планує рости за межі однієї мовної аудиторії, латинський домен безпечніший.

Скільки рівнів вкладеності припустимо?

Жорсткого ліміту немає. У Rozetka більшість трафікових адрес лежать на четвертому-п'ятому рівні шляху, і це не заважає. Важливіша не довжина шляху, а кількість кліків від головної до сторінки: ключові комерційні сторінки мають бути досяжні приблизно за три переходи. Якщо для цього потрібна перелінковка в обхід ієрархії — значить, потрібна перелінковка.

Що робити зі старими адресами, для яких немає нового аналога?

Якщо в сторінки був трафік і зовнішні посилання — краще створити заміну за змістом і редиректити на неї. Якщо сторінка була службовою чи тимчасовою — віддавайте 404 або 410. Редирект усього поспіль на головну Google вважає м'якою помилкою, і це найгірший із варіантів: ви і сторінку втрачаєте, і сигнал про переїзд не передаєте.