Структура URL: принципы построения под SEO

Что такое структура URL

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

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

URL в цифрах

Анатомия URL: семь частей

Прежде чем строить структуру, разберём из чего состоит URL. RFC 3986 описывает семь компонентов; в SEO-контексте важны все, кроме user-info и fragment:

https://www.example.com:443/blog/seo/url-structure/?utm=email#summary
│  │   │            │   │                          │            │
│  │   │            │   │                          │            └─ fragment (якорь)
│  │   │            │   │                          └────────────── query (GET-параметры)
│  │   │            │   └─────────────────────────────────────── path (путь)
│  │   │            └─────────────────────────────────────────── port (обычно скрыт)
│  │   └──────────────────────────────────────────────────────── host (домен)
│  └──────────────────────────────────────────────────────────── subdomain
└─────────────────────────────────────────────────────────────── scheme (протокол)

Почему URL важен для SEO

URL влияет на ранжирование напрямую и косвенно. Прямой вклад невелик — Google неоднократно подтверждал, что ключевое слово в URL даёт «крошечный» буст. Косвенное влияние гораздо сильнее: URL формирует кликабельность сниппета, доверие пользователя и предсказуемость для краулера.

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

Девять правил хорошего URL

За последние пятнадцать лет рекомендации Google по URL почти не менялись. Девять правил ниже — компиляция официальной документации и эмпирических исследований Backlinko, Ahrefs и Moz. Они применимы к любому стеку — от WordPress до Next.js.

• Используйте латиницу (если основная аудитория не локальная). Кириллица технически работает через punycode, но плохо копируется в мессенджерах, ломается при печати и снижает CTR в международной выдаче. /blog/struktura-url/ лучше, чем /блог/структура-url/.
• Слова разделяйте дефисом, не подчёркиванием. Google прямо рекомендует hyphens. Подчёркивания _ слипаются со словами при парсинге: url_structure для бота — это один токен url_structure, не два слова.
• Только строчные буквы. URL технически чувствителен к регистру (на UNIX-серверах). /Page/ и /page/ — два разных адреса, создающие дубли. Принудительно приводите к lowercase на уровне сервера.
• Длина — короче, чем кажется нужным. Оптимум 50–75 символов. Если URL длиннее — обычно лишние слова в слаге или избыточные категории.
• Глубина вложенности — максимум три уровня. /category/subcategory/page/ — потолок для большинства сайтов. Глубже краулер реже доходит, и пользователю сложнее ориентироваться.
• Без стоп-слов. Убирайте и, или, the, a из слага: /how-to-fix-error/ лучше, чем /how-to-fix-an-error-in-the-code/. Стоп-слова не помогают ни ранжированию, ни читаемости.
• Ключевое слово — раз и в начале слага. Не повторяйте ключ дважды (/seo/seo-guide/). Размещайте его как можно ближе к домену: чем ближе к корню, тем выше вес.
• Никаких ID и хешей в слаге. /article-12384/ или /post-a3f9b2c8/ непонятны человеку и не дают семантики. Используйте говорящие слаги с переводом темы.
• URL не должен меняться. Опубликованный адрес — обязательство. Любое изменение требует 301-редиректа и приводит к потере части веса. Думайте о структуре заранее.

Глубина и иерархия каталога

Структура папок в URL — это не просто эстетика, а карта сайта для краулера и пользователя. Глубина вложенности (click depth) — количество кликов от главной до страницы — связана с тем, как часто Google переобходит страницу и как быстро её обнаруживает.

Глубина URL не равна click depth. Страница может находиться на /shop/laptops/macbook-pro-14/ физически и при этом быть в одном клике с главной через хорошую перелинковку. Поисковик учитывает оба сигнала: путь в URL и реальное расстояние в графе ссылок.

www, HTTPS, trailing slash и регистр

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

http://example.com/page
http://example.com/page/
https://example.com/page
https://example.com/page/
http://www.example.com/page
http://www.example.com/page/
https://www.example.com/page
https://www.example.com/page/

HTTPS

Обязателен с 2018 года: Chrome помечает HTTP-сайты как «не защищённые», Google использует HTTPS как слабый ранжирующий фактор. Настройка — один редирект в nginx или apache:

# nginx — 301 с HTTP на HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

www или без www

Технически — равноценно. На уровне DNS www — это поддомен, но Google и Яндекс трактуют его как алиас, если настроен 301. Без www чуть короче и современнее; с www удобнее на уровне cookies (можно разделять между поддоменами). Главное правило: выберите один вариант и 301-редиректом сводите весь трафик на него.

# nginx — 301 c www на без www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Trailing slash

Слеш в конце URL (/page/ vs /page) — два разных адреса для сервера. Конвенция: каталоги заканчиваются на /, файлы — нет. На современных сайтах все страницы — каталоги, поэтому единая стратегия — всегда с трейлинг-слешем (или всегда без). Next.js и WordPress по умолчанию используют trailing slash.

// next.config.ts — принудительный trailing slash
const nextConfig = {
  trailingSlash: true,  // /blog/page/  вместо  /blog/page
};
export default nextConfig;

Регистр

URL чувствителен к регистру на большинстве серверов (Linux/UNIX). /Page/ и /page/ — два URL, два дубля. Приводите весь путь к нижнему регистру на уровне reverse proxy или приложения:

# nginx — редирект URL в нижний регистр (Lua-модуль)
location ~ [A-Z] {
    rewrite ^/(.*)$ /$1 last;
    set_by_lua_block $lower_uri {
        return ngx.var.uri:lower()
    }
    return 301 $lower_uri;
}

Шаблоны URL по типам страниц

Разные типы контента требуют разных шаблонов URL. Ниже — проверенные паттерны для шести типов страниц, которые встречаются на 90% сайтов.

Для e-commerce — отдельная тема. Карточка товара может жить по двум схемам: /shop/category/product/ (с категорией) или /shop/product/ (плоская). Первая лучше для SEO категории (URL сигнализирует о принадлежности), вторая — для миграции товаров между категориями без редиректов. Выбор зависит от того, как часто товары меняют категорию.

Локализация и мультиязычные URL

Для мультиязычного сайта URL — это первая часть стратегии. Google рекомендует три подхода, каждый со своими компромиссами:

Подпапки выигрывают в 80% случаев. Они проще в управлении, дешевле в SSL и хостинге, и весь ссылочный вес работает на единый домен. Именно этот подход использует seohead.tech: основной язык на корне, второй — в /en/.

Слаги в локализованных URL — спорная тема. Перевод слага (/en/url-structure/ ↔ /struktura-url/) даёт лучший CTR для каждого языка и точнее сигнализирует о релевантности. Минус — сложнее поддерживать, нужно следить за hreflang и редиректами при переводах. Для большинства проектов компромисс — переводить только slug блога и оставлять единый slug для технических страниц.

Типичные ошибки и как их исправить

Восемь самых частых ошибок URL, которые встречаются в SEO-аудитах. Каждую можно исправить за один спринт; цена бездействия — постепенная потеря позиций и краулингового бюджета.

• Дублирование через GET-параметры. UTM-метки, сортировки, фильтры создают сотни вариантов одной страницы. Решение: rel="[canonical](/glossary/canonical)" на основной URL + параметр URL Parameters в GSC.
• Смешение trailing slash. Часть страниц с /, часть без. Поисковик видит дубли. Решение: единая конвенция + 301 со всех несоответствующих вариантов.
• Кириллица в URL для глобального проекта. /услуги/ превращается в /%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B8/. Решение: транслитерация (/uslugi/).
• Слишком глубокая иерархия. /shop/electronics/computers/laptops/apple/macbook-pro/ — 6 уровней. Решение: плоская структура с категориями как фасеты.
• ID в URL вместо слага. /article?id=12384 или /post/12384/. Решение: переход на семантические URL + 301 со старых ID.
• Изменение URL без 301. Любая смена адреса без редиректа = потеря веса и трафика. Решение: всегда настраивайте 301 при переименовании.
• Регистр в URL. /Catalog/ и /catalog/ — два дубля. Решение: принудительный lowercase на сервере.
• Бесконечные цепочки редиректов. A → B → C → D. Каждое звено теряет вес. Решение: всегда 301 напрямую на финальный URL.

# Проверка цепочек редиректов через curl:
curl -sILo /dev/null -w "%{http_code} %{url_effective}\n" \
     -L https://example.com/old-page/

# Поиск URL с заглавными буквами в логах nginx:
grep -E 'GET /[a-z]*[A-Z]' /var/log/nginx/access.log | head

# Аудит URL через [Screaming Frog](/glossary/screaming-frog):
# 1. Запустить полный краулинг сайта
# 2. Открыть вкладку URL → Underscores / Uppercase / Non ASCII Characters
# 3. Экспортировать список проблемных URL и составить план редиректов

FAQ

Ответы на самые частые вопросы о структуре URL, которые возникают при аудитах и редизайнах.

Итог

Структура URL — это решение, которое принимается один раз и работает годами. Хороший URL короткий, читаемый человеком, отражает иерархию контента и стабилен во времени. Три ключевых принципа — латиница в нижнем регистре, дефисы вместо подчёркиваний, максимум три уровня вложенности — закрывают 80% типичных ошибок.

Начните с аудита текущих URL: Screaming Frog → отчёты «Underscores», «Uppercase», «Non ASCII Characters». Это даст карту проблем за час. После — составьте таблицу old → new, настройте 301 и обновите внутренние ссылки. Не торопитесь делать массовую миграцию перед сезоном продаж: на переоценку Google уходит 4–8 недель.