Структура URL гранітної навігації

1. Унікальність
2. Кілька вибору
3. Нестандартне кодування URL-адрес
4. Чи є ієрархічні аспекти?
5. Незмінні значення
6. Порядок фацета
7. Досвід користувача
8. Логічні доповнення

Фасетна навігація - це набір елементів інтерфейсу та функціональності, які надають можливість фільтрувати та уточнювати види категорій. Існує певна дискусія в SEO, UX і спільнотах веб-розробників про найкращий спосіб представити гранітну навігацію в URL.

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

- Найкраще (і 5 з найгірших) практик

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

Параметри запиту https://example.com/category?option=true Віртуальні підкаталоги https://example.com/category/filter/option/true

Порада: Параметри запитів і віртуальні підкаталоги (сегменти шляху) піддаються дублюванню проблем із вмістом, якщо вони не керовані належним чином; Кананізація URL-адрес може допомогти уникнути дублювання покарання за вмістом.

Щоб визначити, яка структура URL найкраще підходить для SEO, давайте розглянемо переваги та недоліки кожного варіанту відповідно до “найкращих і найгірших” практик фасетованої навігації, визначених Google.

Унікальність

У ідеальному стані, унікальний контент - будь-який окремий продукт / стаття або категорія товарів / статей - міг би мати лише одну доступну URL-адресу.

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

Google розглядає кожну окрему URL-адресу (включно з параметрами запиту) як унікальну URL-адресу з унікальним вмістом. Це пояснюється тим, що технічно можливо, що веб-сайт надає різний вміст для кожної окремої URL-адреси, а для URL-адрес, які містять параметри запиту, ймовірно, зміст може змінюватися на основі цих значень.

Порада. Це також стосується URL-адрес і URL-адрес http і https, які можна відвідати за допомогою субдомену та без нього (наприклад, www); канонізація або перенаправлення цих URL-адрес допоможе уникнути дублювання покарання за змістом.

Кілька вибору

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

1. Параметри запиту
   • https://example.com/category?color=black,white
   • https://example.com/category?color=black,white&size=8,10
2. Віртуальні підкаталоги
   • https://example.com/category/filter/color/black,white/
   • https://example.com/category/filter/color/black,white/size/8,10/

Ці підходи викликають занепокоєння щодо дійсного кодування URL-адрес.

… [Небезпека ієрархічної класифікації як загального рішення лежить] у філософії сенсу. … Тому що відносини між суб'єктами є веб-подібними, а не деревоподібними, навіть для людей, які погоджуються на веб, можуть вибрати інше деревоподібне представлення.

- Прохолодні URI не змінюються Тім Бернерс-Лі

Нестандартне кодування URL-адрес

Google радить не використовувати «нестандартне кодування URL-адрес для параметрів… замість ключів = значення & пар».

Google надає два приклади "найгіршої практики", де пари ключ-значення позначені неправильно: а, а не =, і де кілька параметрів додаються з [] і, а не &.

Якщо пари ключ-значення позначені правильно, існують допустимі спеціальні символи, які можуть використовуватися в URL-адресі.

Кома, наприклад, є дозволеним символом шляху (тобто "pchar") як частину розділювачів (тобто "підрозділів"), визначених у RFC 3986 § 2.2 як для параметрів запиту, так і для сегментів шляху. Як RFC 3986 § 3.3 держави:

крапка з комою (“;”) і рівними (“=”) зарезервовані символи часто використовуються для розмежування параметрів і значень параметрів, що застосовуються до цього сегмента. Зарезервований символ коми (“,”) часто використовується для подібних цілей.

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

Чи є ієрархічні аспекти?

Суть питання полягає в тому, чи є фасети ієрархічними даними.

Відповідно до Запис у Вікіпедії на тему "Фасетована класифікація" , аспекти не є ієрархічними:

Ієрархічна класифікація відноситься до класифікації об'єктів з використанням єдиної ієрархічної таксономії . Фасетна класифікація насправді може використовувати ієрархію в одному або декількох її аспектах, але дозволяє використовувати більш ніж одну таксономію для класифікації об'єктів.

Як ми бачили в наведених вище прикладах, "множинні таксономії", представлені гранями, не дуже добре підходять для включення до сегмента шляху URL. Повертаючись до точки використання нестандартного кодування URL, відповідно до RFC 3986 § 3.3 :

Компонент шляху містить дані, зазвичай організовані в ієрархічній формі, що разом з даними в неієрархічному компоненті запиту ( Розділ 3.4 ), служить для ідентифікації ресурсу ...

RFC 3986 § 3.4 продовжується:

Компонент запиту містить неієрархічні дані

Це дає зрозуміти, що аспекти не повинні з'являтися в сегментах шляху, але повинні відображатися як параметри запиту. Насправді, Google доручає:

Використовуйте параметри (коли це можливо) зі стандартним кодуванням і парами ключ = значення.

Використання віртуальних підкаталогів для позначення фасетів є нестандартним, і Google здатний робити кращі припущення щодо вмісту сторінки, коли фасети передаються через параметри запиту. Google навіть надає Інструмент параметрів URL в Пошуковій консолі Google, яка дозволяє адміністраторам сайтів надавати Google інструкції щодо інтерпретації параметрів запитів; не існує такого інструменту для віртуальних підкаталогів.

Незмінні значення

Ще однією «найгіршою практикою», визначеною Google, є «використання каталогів або шляхів до файлів, а не параметрів для переліку значень, які не змінюють вміст сторінки».

У структурі URL-адрес із гранітною URL-адресою всі наступні URL-адреси будуть містити однаковий вміст:

• https://example.com/category/filter/option/
• https://example.com/category/filter/
• https://example.com/category/

Ця проблема менш очевидна при використанні параметрів запиту, оскільки існує чітке розмежування між ієрархією і гранями за допомогою пар ключ-значення. Це питання може бути вирішено шляхом канонізації, але не вважається найкращою практикою, як зазначено від Google ; Найкраща практика полягає у використанні параметрів запиту, оскільки "параметри URL-адрес дозволяють пошуковим системам більш гнучко визначати, як ефективно сканувати".

Порядок фацета

Незалежно від того, яка URL-адреса використовується, фасети завжди повинні бути представлені уніфіковано (наприклад, за алфавітом), тому кілька URL-адрес не індексуються для одного і того ж вмісту. Приклад:

• https://example.com/category?test=0,1
• https://example.com/category?test=1,0

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

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

Досвід користувача

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

Примітка: Я написав обширна публікація про важливість розробки URL-адрес як частини інтерфейсу сайту .

Логічні доповнення

Google радить не додавати параметри URL без логіки. Необхідні параметри повинні бути позбавлені, щоб підтримувати людську структуру можливих URL, коли це можливо. Google рекомендує видаляти інформацію про сеанс користувача з URL-адреси та зберігати ці дані у файлі cookie. Зберігання URL-адреси без зайвих даних не тільки допомагає користувачам зрозуміти вміст, присутній у поточному перегляді, але й допомагає SEO, як відзначає Google:

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