Оптимальна структура URL
Оптимальна структура URL — тема, де в Google є власний посібник, і він коротший та суворіший за сім правил із типових чек-листів. У ньому два блоки: вимоги, без яких сайт обходиться погано або не обходиться взагалі, і рекомендації для зрозумілості. Багато чого зі звичного — «не більше пʼяти слів», «без стоп-слів», «не глибше чотирьох рівнів» — у ньому відсутнє. У цьому уроці — що підтверджено, що ні і як не зламати сайт під час зміни адрес.
Спиратися будемо на посібник зі структури URL і на опис канонізації.
Вимоги: без них обхід іде погано
Посібник попереджає: якщо адреси не відповідають цим критеріям, Google найімовірніше обходитиме сайт неефективно — аж до надмірно високої частоти запитів чи відмови від обходу. Критеріїв три:
- Стандарт. Google підтримує URL за IETF STD 66; зарезервовані символи мають бути закодовані відсотковим кодуванням.
- Фрагменти. Не використовуйте фрагменти, щоб змінювати вміст сторінки: Google загалом їх не підтримує; для JavaScript потрібен History API. Докладно — в уроці про навігацію.
- Параметри. Пари «ключ — значення» розділяються знаком рівності, параметри — амперсандом; кілька значень одного ключа можна перелічити через кому. Нестандартні схеми з дужками й двокрапками чи подвійними комами не рекомендуються.
Рекомендації: щоб адреса була зрозумілою
Про дефіс і підкреслення — точно
Питання в цьому посібнику розвʼязано рекомендацією, а не забороною, і причину названо іншу, ніж у переказах. Підкреслення не радять з історичних причин: воно вже часто позначає поняття, які потрібно тримати разом, наприклад в іменах функцій на кшталт format_date. Злите написання виду greendress теж не рекомендується. Твердження «Google читає technical_seo як одне невідоме слово» в документації не зустрічається.
Кирилиця та інші алфавіти
Для сайтів не латиницею це найпрактичніше місце посібника: слова потрібно писати мовою аудиторії, а в посиланнях — кодувати. Приклад звідти ж: адреса зі словом gemüse в атрибуті href має виглядати як gem%C3%BCse. Отже, російська чи українська адреса припустима, але в розмітці посилання вона кодується. Які адреси зрештою отримує обхід, показує сканер сайту.
Чого в документації немає
Ці поширені твердження в документації не зустрічаються, тому як правила їх подавати не можна:
- «у шляху не більше пʼяти слів» і «прибирайте стоп-слова»;
- «ключове слово в адресі — слабкий, але реальний сигнал релевантності»;
- «кожен слеш коштує PageRank, не глибше чотирьох рівнів»;
- «в консолі пошуку потрібно обрати бажаний домен».
Це не означає, що коротка читабельна адреса погана: посібник прямо радить читабельність. Але числа на кшталт «пʼять слів» і «чотири рівні» — звичка, а не норма.
Дублі через адреси
Посібник називає головне джерело проблем: надто складні адреси, особливо з кількома параметрами, створюють зайву кількість URL з тим самим вмістом, через що Googlebot може витрачати значно більше трафіку, а Google Search — не зуміти проіндексувати весь вміст сайту. Типові причини там само: фільтри, що комбінуються адитивно, і зайві параметри — реферальні, сортування, сесійні. Як із цим працювати, розібрано в уроці про навігацію і в посібнику з фасетної навігації.
Єдина форма адреси: протокол, www, слеш
Той самий матеріал може бути доступний як http і https, з www і без, зі слешем і без. Для Google це різні рядки, що обробляються за IETF STD 66, тому на практиці обирають одну форму й закріплюють її двома способами: постійним редиректом і rel=canonical. Для слеша і www окремих правил у документації немає; це наслідок загального принципу. А от про протокол сказано точно: Google віддає перевагу HTTPS-сторінкам над еквівалентними HTTP-сторінками як канонічним, окрім випадків із проблемами: недійсний SSL-сертифікат, небезпечні залежності (крім зображень), редирект на HTTP чи через нього, rel=canonical на HTTP-версію.
Який редирект
Різницю описано прямо. Постійний редирект — сигнал для індексації, що цільова адреса має стати канонічною; застосовуйте його, коли впевнені, що його не буде скасовано. Тимчасовий редирект Google виконує, але не використовує як сигнал про канонічну адресу і показує в результатах вихідну сторінку. Серверні редиректи 301 і 308 — найнадійніший варіант для інтерпретації. Тому перехід з HTTP на HTTPS і з другорядної форми на основну роблять постійним. Ланцюги перевіряє перевірка редиректів.
Canonical: навіщо й як
Важливе застереження з посібника про дублі: зазвичай не критично вказувати перевагу щодо канонічної адреси, але є причини робити це явно — обрати адресу для видачі, консолідувати сигнали й не витрачати обхід на дублі. У самому елементі використовуйте абсолютні шляхи, а не відносні: відносні підтримуються, але можуть створити проблеми згодом. Подробиці — в уроці про canonical-теги.
Пагінація й адреси
Тут часто ускладнюють. Посібник із пагінації: дайте кожній сторінці унікальну адресу, наприклад із параметром ?page=n, бо адреси в послідовності сприймаються як окремі сторінки. Переписувати ?page=2 на /page/2/ не потрібно. Решту правил — свій canonical у кожної сторінки й жодних фрагментів у номерах сторінок — розібрано в уроці про навігацію.
Коли змінювати адресу
Перейменування адрес — це переїзд у малому масштабі. В описі переїзду сказано: постійні редиректи 301 та інші не призводять до втрати PageRank, тож редирект працює — але очікуйте тимчасових коливань позицій: для сайтів середнього розміру потрібно кілька тижнів і більше, поки Google поступово замінить старі адреси новими. Висновки:
| Ситуація | Змінювати? | Умова |
|---|---|---|
| Нова сторінка, на неї ще немає посилань | Так | — |
| Адреса породжує дублі або містить ідентифікатор сесії | Так | Постійний редирект і canonical |
| Зміна платформи чи структури | Обережно | Повна відповідність старих і нових адрес — див. урок про переїзд сайту |
| Сторінка, що приносить трафік, лише заради «краси» | Зазвичай ні | Відома ціна — тижні коливань, а виграш у документації не описано |
Останній рядок — висновок зі сказаного, а не правило Google. Стан адрес після змін видно в аудиті URL, а розбіжність карти сайту і нових адрес відстежує моніторинг sitemap.
Чек-лист
- Читабельні слова замість ідентифікаторів, мовою аудиторії.
- Дефіси, а не підкреслення; один регістр.
- Лише параметри, що змінюють вміст; формат «ключ=значення&».
- Жодних фрагментів для зміни вмісту.
- Одна форма адреси: HTTPS, один варіант www, одна конвенція слеша — закріплена постійним редиректом і canonical з абсолютною адресою.
- Кожна сторінка списку — своя адреса.
- Під час зміни адреси — постійний редирект і перевірка результату.
Помилки
- Видавати за вимоги Google правила про пʼять слів і чотири рівні.
- Використовувати тимчасовий редирект там, де адреса змінюється назавжди.
- Залишати доступними http і https, з www і без, не закріпивши один варіант.
- Не кодувати символи поза ASCII в посиланнях.
- Змінювати адреси сторінок із трафіком заради косметики.
- Вважати, що підкреслення робить слово «невідомим», а 301 передає «99% ваги».
Що далі
Наступний модуль курсу — технічна оптимізація сторінок: заголовок, опис, зображення та вміст.