⌘ K
← Энциклопедия

ЧПУ (человекопонятный URL)

SEF URL (search-engine-friendly URL), human-readable URL, clean URL

Также: человекопонятный УРЛ, красивые ссылки, понятные адреса, семантический URL, slug (часть адреса)

ЧПУ (человекопонятный URL) — адрес веб-страницы, путь которого составлен из читаемых слов, отражающих содержание страницы или её место на сайте, а не из служебных параметров и числовых идентификаторов. «ЧПУ» — русскоязычный термин; в английском ему соответствуют SEF URL, clean URL и human-readable URL.

Факты проверены 14 октября 2026 г., версия 2.0. Как готовилась статья

Не путать: в станкостроении «ЧПУ» означает числовое программное управление. Это другой термин, к веб-адресам он отношения не имеет.

Кратко

  • ЧПУ — способ записи адреса: /catalog/kofe/arabika/ вместо /index.php?id=4821&cat=7. Читаемый адрес помогает людям понять, куда ведёт ссылка, а его части Google может показывать в выдаче как хлебные крошки [2].
  • И Google, и Яндекс в официальной документации рекомендуют понятный вид адреса. Google — «readable words rather than long ID numbers» [1]; Яндекс — чтобы «вид URL давал представление о том, что содержится на соответствующей странице» [11].
  • О ранжировании Google говорит узко: ключевые слова в имени домена или в пути URL сами по себе почти не влияют на него, кроме показа в хлебных крошках [2]. Яндекс на странице о структуре сайта о ранжировании не пишет; там речь о том, чтобы робот понял, о чём страница [11].
  • Менять адрес работающей страницы следует с постоянным редиректом со старого адреса на новый: Google советует серверные 301 или 308, если это технически возможно [3], Яндекс — 301 [12]. В деталях переезда (цепочки редиректов, редирект на раздел) подходы платформ различаются.
  • Транслит, перевод или кириллица — решение с компромиссами. Google допускает слова на языке аудитории и транслит [1], Яндекс отмечает пользу транслитерации для робота и даёт отдельный совет по кодировке кириллических адресов [11].

Происхождение и история термина

Динамические адреса. Ранние веб-приложения получали данные от пользователя через строку запроса. В спецификации Common Gateway Interface (RFC 3875, октябрь 2004, описывает CGI 1.1) переменная QUERY_STRING определена так: «The QUERY_STRING variable contains a URL-encoded search or parameter string» [7]. Там же есть переменная PATH_INFO — путь, который интерпретирует сам скрипт [7]. Отсюда типичный вид динамического адреса: имя программы и параметры после ?.

Переписывание адресов и роутинг. Чтобы скрыть устройство приложения за читаемым путём, используют переписывание URL на веб-сервере и маршрутизацию в CMS. Документация Apache HTTP Server 2.4 описывает модуль mod_rewrite как средство, которое «provides a way to do URL manipulations» [9]. В документации CMS Joomla поддержка таких адресов называется SEF: «Search engine friendly (SEF), human-readable or clean URLs are URLs that make sense to both humans and search engines» [10]. Там же приведён исходный вид адреса index.php?option=com_content&view=article&id=42 и сказано, что с версии 1.5 Joomla умеет создавать и разбирать URL в любом формате [10]. Подтверждённой истории появления самого английского термина «search-engine-friendly URL» (кто и когда его ввёл) в источниках уровней 1–2 найти не удалось.

Стабильность против описательности. В документе W3C «Cool URIs don't change» (1998) Тим Бернерс-Ли сформулировал принцип: «URIs don't change: people change them» [8]. Он предлагает не включать в адрес то, что со временем меняется: имя автора, тему, статус документа, уровень доступа, расширение файла, детали программного обеспечения, имя диска [8]. Пути вида cgi-bin и расширения вроде .pl он относит к приметам того, «как мы делаем это сейчас»: при смене технологии такие адреса ломаются [8]. Этот текст часто связывают с идеей «понятного адреса», но его позиция отличается от практики ЧПУ: Бернерс-Ли советует начинать адрес с даты создания документа (пример http://www.w3.org/1998/12/01/chairs), а классификацию по темам называет «a great medium term solution but has serious drawbacks in the long term» [8]. Подробнее — в разделе о спорных вопросах.

Аббревиатура «ЧПУ». Термин употребляется в официальной справке Яндекса: среди причин смены адресов страниц названо «внедрение человеко-понятных URL (ЧПУ-адресов)» [12]. Автор аббревиатуры и год её появления в рунете в источниках уровней 1–2 не установлены; материалы агентств и сервисов (уровень 3) историю термина не доказывают, поэтому ни автора, ни год мы не указываем.

Суть и механизм

Анатомия URL

Общий синтаксис идентификатора ресурса задан стандартом IETF RFC 3986 (STD 66, январь 2005): URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] [5]. Адрес состоит из схемы (https), указания на хост, иерархического пути, необязательного запроса после ? и необязательного фрагмента после #. Путь содержит данные, «usually organized in hierarchical form» [5]. ЧПУ — это прежде всего вопрос о том, как устроен путь.

Стандарт выделяет «незарезервированные» символы, которые можно использовать без кодирования: латинские буквы, цифры и знаки -, ., _, ~ [5]. Остальные данные передаются через процентное кодирование: октет записывается тройкой символов — знак % и две шестнадцатеричные цифры [5]. Подчёркивание, таким образом, синтаксически допустимо; совет Google разделять слова дефисами — вопрос практики, а не синтаксиса [1].

Как получается ЧПУ

Пользователь и робот запрашивают читаемый адрес, а сайт внутри сопоставляет его с нужным содержимым. Обычно это делается одним из двух способов:

  1. правила переписывания адресов на веб-сервере — например, mod_rewrite в Apache [9];
  2. маршрутизация в приложении или CMS: у записи (статьи, товара, раздела) есть поле с «человеческой» частью адреса — slug, а CMS умеет строить и разбирать такие адреса [10].

Пример

Технический адрес Адрес ЧПУ Что изменилось
/index.php?id=4821&cat=7 /catalog/kofe/arabika/ вместо ID и параметров — слова, отражающие раздел и товар
/news/p?n=93812 /news/chpu-chto-eto/ адрес описывает содержание, а не номер записи

Примеры в таблице — редакционные. Google показывает похожее сравнение в своей документации: адрес /wiki/Aviation удобнее, чем адрес с длинной служебной строкой [1]. По формулировке Starter Guide, URL, который содержит только случайные идентификаторы, «is less helpful for users» [2].

Виды и классификации

Единой общепринятой классификации ЧПУ в изученных источниках уровней 1–2 нет. Ниже — практическая классификация, не приписываемая какому-либо автору.

По способу формирования:

  • ручной slug — редактор вводит его сам;
  • автоматический — генерируется из заголовка, часто с транслитерацией;
  • иерархический — повторяет разделы сайта (/catalog/kofe/arabika/);
  • плоский — без вложенности (/arabika/).

По алфавиту:

Вариант Как выглядит Что говорят источники Ограничения
Транслит /kofe-v-zernakh/ Google допускает «transliterated words» [1]; Яндекс: транслитерация «позволит роботу понять, о чем может быть страница» [11] систем транслитерации несколько, возможны разночтения
Перевод на английский /coffee-beans/ только ASCII, кодирование не нужно [5] Google советует слова на языке аудитории [1]; для русскоязычной аудитории перевод — не её язык
Кириллица /кофе-в-зёрнах/ Google приводит пример адреса на японском (/ペパーミント) для японоязычной аудитории [1]; Яндекс советует одинаковую кодировку страниц и кириллических адресов [11] при передаче по протоколу кодируется: символ → UTF-8 → %HH [6]; в закодированном виде путь /корзина выглядит как /%D0%BA%D0%BE%D1%80%D0%B7%D0%B8%D0%BD%D0%B0 [11]

Google формулирует совет так: «Use words in your audience's language in the URL (and, if applicable, transliterated words)» [1]. То есть речь о языке аудитории, а не о «ключевых словах». Для адресов с символами не из ASCII Google рекомендует процентное кодирование в ссылках (пример gem%C3%BCse вместо gemüse) [1]. Решения «кириллица лучше» или «транслит лучше» нет ни у Google, ни на изученных страницах Яндекса.

Яндекс на странице «Структура сайта» пишет: «Желательно, чтобы вид URL давал представление о том, что содержится на соответствующей странице», и добавляет: «Использование транслитерации в адресах страниц также позволит роботу понять, о чем может быть страница» [11]. Для кириллицы там же дан совет: «Используйте одинаковую кодировку для страниц сайта и кириллических адресов в его структуре» — страница должна открываться и по процентно-кодированному адресу [11].

Технически кириллический адрес описывается стандартом IRI (RFC 3987, январь 2005): «An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646)» [6]. Для передачи через протоколы, рассчитанные на URI, каждый такой символ переводится в UTF-8, а каждый октет — в %HH [6].

Как применяется на практике

Правила Google

Из документации «URL structure best practices for Google Search» (обновлена 10.12.2025) [1]:

  • использовать читаемые слова вместо длинных числовых идентификаторов;
  • разделять слова дефисами: Google рекомендует «using hyphens (-) instead of underscores (_)»;
  • сокращать адреса, убирая ненужные параметры;
  • учитывать регистр: «Google Search's URL handling is case sensitive», то есть /APPLE и /apple — разные URL;
  • не использовать фрагмент (#) для смены содержимого страницы;
  • по возможности не включать в адрес идентификаторы сессии, а использовать cookie;
  • следить, чтобы комбинируемые фильтры не размножали адреса: при добавочных фильтрах число URL «explodes».

Что даёт читаемый адрес в выдаче: по Starter Guide, части URL могут показываться как хлебные крошки, и Google «learns breadcrumbs automatically based on the words in the URL» [2]. Там же сказано, что группировка похожих страниц по каталогам помогает Google понять, как часто меняется содержимое разных разделов [2]. Подробнее об отображении в выдаче — в статье о сниппете.

Рекомендации Яндекса

Официальная справка Вебмастера («Структура сайта») связывает вид адреса не с ранжированием, а с пониманием страницы роботом и индексацией [11]:

  • каждая страница должна иметь уникальный адрес; желательно, чтобы вид URL давал представление о содержании страницы; транслитерация помогает роботу понять, о чём страница;
  • для кириллических адресов нужна одинаковая кодировка со страницами сайта;
  • глубина вложенности влияет на скорость индексации: «чем глубже страница, тем больше времени может пройти до включения ее в индекс»;
  • надо проверять symlink-и, чтобы не возникал «бесконечно растущий URL»; страницы, путь которых содержит много повторений одного токена, могут не индексироваться.

Справка о дублях добавляет правила для параметров и слеша [13]: незначащие параметры можно исключить директивой Clean-param в robots.txt, а «большинство UTM-меток, удаляются поисковой системой автоматически». Для адресов, различающихся только слешем в конце, Яндекс рекомендует 301 с одного варианта на другой и не рекомендует canonical, «так как он может игнорироваться» [13].

Позиции Google и Яндекса

Вопрос Google Яндекс
Вид адреса Читаемые слова вместо длинных ID [1] Вид URL должен давать представление о содержании страницы [11]
Язык слов Язык аудитории, при необходимости транслит; пример адреса на японском [1] Транслитерация помогает роботу понять страницу; кириллица — с одинаковой кодировкой [11]
Связь с ранжированием Ключевые слова в домене или пути «hardly any effect beyond appearing in breadcrumbs» [2] На страницах [11][13] о ранжировании не сказано; говорится о понимании страницы роботом и об индексации
Глубина вложенности В документах [1][2] о глубине не сказано; группировка по каталогам помогает понять частоту обновления [2] Чем глубже страница, тем дольше она может попадать в индекс [11]
Параметры Убирать ненужные параметры, не использовать session ID [1] Clean-param; большинство UTM-меток удаляется автоматически [13]
Регистр букв Обработка URL чувствительна к регистру [1] В справке о дублях о регистре не сказано [13]
Слеш в конце адреса В документе [1] не рассматривается 301 с одного варианта на другой; canonical не рекомендуется [13]
Канонический адрес В этой статье не рассматривается В пределах одного домена, абсолютным адресом; при ряде условий робот указание игнорирует [14]

Переход на ЧПУ без потери трафика

Яндекс прямо называет «внедрение человеко-понятных URL (ЧПУ-адресов)» одной из причин смены адресов и предупреждает: без редиректа робот может «воспринимать страницу по старому и новому адресу как две отдельных страницы» [12]. Порядок переезда у платформ в основном совпадает, но различается в деталях.

Шаг Google [3] Яндекс [12]
1. Список старых адресов Составить карту «старый → новый»; источники — sitemap, логи сервера или аналитика, CMS —
2. Редирект Серверные постоянные 301 или 308, «if technically possible»; клиентские — «as a last resort» 301 со старого адреса на новый
3. Цепочки Перенаправлять сразу на конечный адрес; Googlebot проходит до 10 переходов, цепочку держать «ideally no more than 3 and fewer than 5» «При необходимости можно использовать цепочку редиректов»; в индекс попадает конечная страница
4. Исчезнувшие страницы Не перенаправлять много старых адресов на один нерелевантный, например на главную Если тематика сохранилась — 301 на главную страницу соответствующего раздела или похожий раздел; если сменилась — код 404
5. Ссылки и sitemap Обновить внутренние ссылки, sitemap, указать самоссылающийся canonical Добавить новые адреса в Sitemap, обновить меню; найти внешние ссылки на старые адреса
6. Ускорение и проверка Проверить редиректы и следить за трафиком пользователей и робота на старом и новом сайте «Проверка ответа сервера» (код 200), «Переобход страниц»: отправленные страницы «смогут попасть в поиск в течение двух недель»
7. Срок хранения редиректов Как можно дольше, как правило не менее года; для пользователей — можно бессрочно Срок в [12] не указан

Google отдельно отмечает, что редиректы «don't cause a loss in PageRank» [3], то есть позволяют передать сигналы новому адресу.

Как измерить или проверить

Формулы для оценки ЧПУ нет; проверка — это чек-лист. Рабочий список редакции, собранный по правилам [1][3][11][13][14]:

  1. адрес читается как слова и отражает содержание или раздел [1][11];
  2. в нём нет идентификатора сессии и лишних параметров [1][13];
  3. регистр единый: для Google /APPLE и /apple — разные адреса [1];
  4. варианты со слешем и без него сведены редиректом 301 [13];
  5. страница отвечает кодом 200, после переезда — без длинных цепочек редиректов [3][12];
  6. canonical указан абсолютным адресом в пределах домена [14];
  7. нет бесконечно растущих путей с повторяющимися фрагментами [11].

Инструменты:

  • Google Search Console, инструмент «Проверка URL» (URL Inspection): показывает сведения об индексированной версии страницы и позволяет проверить, может ли URL быть проиндексирован [4];
  • Яндекс Вебмастер: «Проверка ответа сервера», «Переобход страниц», «Статистика обхода», «Файлы Sitemap», «Внешние ссылки» [12].

Подробности о кодах ответа — в статье «Коды ответа сервера».

Ошибки, ограничения и спорные вопросы

  • Смена адреса без редиректа. Робот может считать старую и новую страницы разными [12]; Google советует постоянный редирект с каждого старого адреса [3].
  • Цепочки редиректов. Здесь платформы расходятся: Google советует перенаправлять сразу на конечный адрес [3], Яндекс допускает цепочку «при необходимости» [12]. Безопаснее ориентироваться на более строгое требование.
  • Массовый редирект на главную. Google не советует перенаправлять много старых адресов на один нерелевантный [3]; Яндекс допускает 301 на главную страницу соответствующего раздела, если тематика сохранилась [12]. Общее у обоих — релевантность цели.
  • Описательность против стабильности. Google и Яндекс рекомендуют, чтобы адрес отражал содержание [1][11]. Бернерс-Ли, наоборот, предлагает не включать в адрес тему и всё, что может измениться, а включать дату создания: она не меняется [8]. Иерархический ЧПУ вида /catalog/kofe/arabika/ удобен сегодня, но при перестройке разделов адреса придётся менять — ровно то, от чего предостерегает W3C [8]. Документы поисковиков и W3C решают разные задачи: первые — понятность для пользователей и роботов, второй — долговечность ссылок.
  • Дата в адресе. Единой позиции нет: W3C рекомендует дату создания как стабильную часть адреса [8]; в изученной документации Google и Яндекса [1][2][11] о дате в URL ничего не сказано. Мы не даём рекомендации «за» или «против».
  • Влияют ли ключевые слова в адресе. Позиция Google узкая и прямая: слова в домене или пути сами по себе «hardly any effect beyond appearing in breadcrumbs» [2]. Яндекс говорит о понимании страницы роботом [11], но не о ранжировании. Распространённое на SEO-рынке мнение о сильном влиянии ключей в URL проверяемыми данными уровней 1–2 в изученных материалах не подкреплено.
  • Длина и глубина. О длине URL в документации Google по структуре адресов не сказано [1]. Связь глубины вложенности со скоростью индексации заявлена Яндексом [11]; источника о связи длины или глубины с позициями в выдаче нет, поэтому «идеальных» чисел мы не приводим.
  • Фильтры и параметры в каталогах. Комбинируемые фильтры размножают адреса [1]. Что делать с дублями — в статье «Дубли страниц».
  • Слово и ID вместе. В крупных каталогах, где названия повторяются, встречается схема «слово + идентификатор» (/arabika-4821/). Это пример; документация её не предписывает.

Правовой аспект

Специальных правовых норм для формата адреса страницы нет; раздел не применяется.

Частые вопросы

Влияет ли ЧПУ на ранжирование в Яндексе и Google?

Google пишет, что ключевые слова в имени домена или в пути URL сами по себе почти не влияют на ранжирование, кроме показа в хлебных крошках [2]. Яндекс рекомендует понятный вид URL и транслитерацию, чтобы робот понял, о чём страница, но о ранжировании на этой странице не говорит [11].

Что выбрать: транслит или кириллицу?

Однозначного ответа в документации нет. Google советует слова на языке аудитории, при необходимости транслит, и приводит пример адреса на японском [1]. Яндекс отмечает, что транслитерация помогает роботу, а для кириллических адресов требует одинаковой кодировки со страницами [11]. Кириллический адрес при передаче кодируется в %HH [6].

Дефис или нижнее подчёркивание?

Google рекомендует дефисы [1]. Подчёркивание допустимо по синтаксису RFC 3986 [5].

Можно ли менять адрес проиндексированной страницы?

Можно, с постоянным редиректом 301 (у Google также 308) со старого адреса на новый [3][12]. Затем стоит обновить внутренние ссылки и sitemap [3][12]. Бернерс-Ли советует проектировать адреса так, чтобы их не приходилось менять [8].

Сколько хранить редиректы?

Google советует как можно дольше, как правило не менее года, а с точки зрения пользователей — можно бессрочно [3]. В справке Яндекса о смене структуры срок хранения не указан [12].

Нужен ли ЧПУ интернет-магазину с тысячами товаров?

Обязательным его не называет ни одна из платформ, но обе рекомендуют понятный вид адреса [1][11]. Google предупреждает о размножении адресов фильтрами [1], Яндекс — о связи глубины вложенности со скоростью индексации [11].

Обязательно ли делать ЧПУ латиницей?

Нет. Google рекомендует язык аудитории и допускает необходимые формы кодирования. Яндекс упоминает транслитерацию как понятный вариант. Выбор должен учитывать пользователей и работу системы. [15] [17]

Можно ли оставлять числовой идентификатор?

Да, если он помогает устойчиво различать страницы. Понятность оценивается по адресу в целом, а не по отсутствию цифр.

Надо ли менять адрес вместе с заголовком?

Не обязательно. Сначала определяют, осталась ли это та же сущность, и оценивают последствия изменения ссылок. Принцип долговечности адресов поддерживает осторожный подход. [16]

Удалит ли ЧПУ все проблемы индексации?

Нет. Параметры, дубли, доступность, содержимое и навигация требуют самостоятельной проверки. Понятная строка адреса — только один элемент устройства сайта. [15] [17]

Связанные термины

Источники

  1. Google. (2025, December 10). URL structure best practices for Google Search. Google Search Central. Retrieved October 14, 2026, from https://developers.google.com/search/docs/crawling-indexing/url-structure ↑ а б в г д е ж з и к л м н о п р с т у ф х ц ч ш э ю я 28
  2. Google. (2025, December 10). Search Engine Optimization (SEO) Starter Guide. Google Search Central. Retrieved October 14, 2026, from https://developers.google.com/search/docs/fundamentals/seo-starter-guide ↑ а б в г д е ж з и к л
  3. Google. (2026, August 20). How to move a site [Site move with URL changes]. Google Search Central. Retrieved October 14, 2026, from https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↑ а б в г д е ж з и к л
  4. Google. (n.d.). URL Inspection tool. Search Console Help. Retrieved October 14, 2026, from https://support.google.com/webmasters/answer/9012289 ↑
  5. Berners-Lee, T., Fielding, R., & Masinter, L. (2005). Uniform Resource Identifier (URI): Generic syntax (RFC 3986, STD 66). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc3986 ↑ а б в г д е
  6. Duerst, M., & Suignard, M. (2005). Internationalized Resource Identifiers (IRIs) (RFC 3987). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc3987 ↑ а б в г
  7. Robinson, D., & Coar, K. (2004). The Common Gateway Interface (CGI) Version 1.1 (RFC 3875). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc3875 ↑ а б
  8. Berners-Lee, T. (1998). Cool URIs don't change. World Wide Web Consortium. Retrieved October 14, 2026, from https://www.w3.org/Provider/Style/URI.html ↑ а б в г д е ж з
  9. The Apache Software Foundation. (n.d.). Apache mod_rewrite introduction (Apache HTTP Server Version 2.4). Retrieved October 14, 2026, from https://httpd.apache.org/docs/2.4/rewrite/intro.html ↑ а б
  10. Joomla! Documentation. (n.d.). Search Engine Friendly URLs. Open Source Matters. Retrieved October 14, 2026, from https://docs.joomla.org/Search_Engine_Friendly_URLs ↑ а б в
  11. Яндекс. Структура сайта // Справка Яндекс Вебмастера. — URL: https://yandex.ru/support/webmaster/ru/recommendations/site-structure (дата обращения: 14.10.2026). ↑ а б в г д е ж з и к л м н о п р с т у ф х ц ч ш
  12. Яндекс. Смена структуры и дизайна сайта // Справка Яндекс Вебмастера. — URL: https://yandex.ru/support/webmaster/ru/recommendations/changing-site-structure (дата обращения: 14.10.2026). ↑ а б в г д е ж з и к л м н
  13. Яндекс. Дублирование страниц // Справка Яндекс Вебмастера. — URL: https://yandex.ru/support/webmaster/ru/robot-workings/double.html (дата обращения: 14.10.2026). ↑ а б в г д е ж з и
  14. Яндекс. Канонический адрес страницы // Справка Яндекс Вебмастера. — URL: https://yandex.ru/support/webmaster/ru/robot-workings/canonical (дата обращения: 14.10.2026). ↑ а б в
  15. Google. (n.d.). URL structure best practices for Google Search. Google Search Central. URL: https://developers.google.com/search/docs/crawling-indexing/url-structure (дата обращения: 21.10.2026). ↑ а б
  16. Berners-Lee, T. (1998). Cool URIs don't change. W3C Style. URL: https://www.w3.org/Provider/Style/URI (дата обращения: 21.10.2026). ↑
  17. Яндекс. Структура сайта // Справка Вебмастера. Б.г. URL: https://yandex.ru/support/webmaster/ru/recommendations/site-structure (дата обращения: 21.10.2026). ↑ а б

Служебный блок

Версия
2.0
Факты проверены
Подготовка
Редакция Медиатрона
Публикация
утверждена главным редактором
Дополнено
4 ноября 2026 г.: вопросы и ответы (4) из новой редакции

Редакция Медиатрона. Факты сверены с первоисточниками, публикация утверждена главным редактором.

Нашли ошибку? info@mediatrone.ru