Идеальная структура урла

Особо не пишу про технические штуки, но вот проняло. Во всех своих проектах, которые планирую модифицировать, стараюсь юзать урлы вида:

/тип-страницы/айди/херня для человека

Или

/<айди>/<херня для человека>

Например:

/article/1034/how-to-cook-potato/
/03/рахат-лукум.html

Чё тут такого? А вот чё: в CMS все урлы /<тип-страницы>/<айди>/* равны, и делают 301 редирект на текущий урл вида /<тип-страницы>/<айди>/<херня для человека>. То бишь:

/article/1034/ ->301-> /article/1034/how-to-cook-potato/
/article/1034/как_готовить_картоху.html ->301-> /article/1034/how-to-cook-potato/

Таким образом, над частью «херня для человека» мы можем извращаться как угодно. Для всяких там САП это не проканает, а вот для людей и поисковиков схема идеальная. Других вариантов обычно два: либо наплевать на то, что урл может измениться (превед, Вордпресс!), либо хранить все старые урлы в базе и редиректить с них (дарова, Друпал!). И оба эти варианта — порочны.

33 комментария к “Идеальная структура урла”

  1. а в коде этой самой страницы с каким угодно окончанием — указываешь канонический урл? если нет — надо бы, чтобы гугл знал, какая страница на самом деле основная и дубли не плодил.

    1. Плохо прочитал, везде 301 редирект на основной урл. Никаких дублей и быть не может. Как только мы переделываем это окончание (допустим, переименовываем) — редирект пойдёт на новое.

  2. Э, а зачем? Может просто сразу делать url для человека, а тип и id уже по базе или роутингом определять? /news-by-atlantic-city.html?id=18

    1. Невозможно ничего изменить без затрат. Точка!

      Допустим, узнал ты, что такой-то символ не канает, как пробел (для многих это неприятный сюрпрайз, но «_» до сих пор не пробел для Гугла). И чо будешь делать? :)

      Или, как в Викимапии: пользователи иногда переименовывают тайтл, по которому строится slug. Что тут прикажешь делать? Оставить старый? А если там опечатка, а стало лучше? По-другому делать — я описал варианты.

      И быть уверенным, что такого не будет — практически невозможно.

      Ваще почему я написал: щас вот хрен переделаешь на блоге все трансличеные урлы в кириллические. Это тоже пример.

  3. Ну переименовал, со старого просто поставил 301 редирект на новый адрес и всё. Получается связь одного уникального ID ко многим алиасам, среди которых 1 текущий, а остальные прошлые варианты с редиректом.

    Ну и если придерживать твоей схемы, то тип излишним тоже будет, пусть только ID будет, он уникальный на всё и по нему же можно узнать тип к примеру.

    1. Я написал про твой вариант в конце поста :) Читай внимательно. Надо будет хранить старый адрес. Если глобально тебе взбредёт поменять принцип именования слагов — то слегка многовато будет хранить чего. Если часто переименовывают (пример: Викимапия) — то на каждый пост десятки будут записей в базе. Зачем это всё? :) Тут ты ваще ничего не хранишь. Думать ваще не надо. Хоть /id/ только пиши в урле — это будет работать на все 100%.

      А тип нужен, если сложный проект. Ты, похоже, фреймворк юзаешь какой-то? В джанге это зовётся аппы. В остальных — как-нить ещё. Для основного аппа, конечно, урл можно вынести без префикса.

      ЗЫ: кстати — единственное, когда схема сильно будет сосать — это в случае тегов. Я, и какие-нить ещё гики, наверное, привыкли вбивать tag/.

  4. Схема сама по себе избыточная, раз достаточно только ID, да и мелочи хронить uri строки в сравнении например с файлами и текстами контента расхода больше будет, экономить на этом я бы не стал.

    App в Django как я понимаю, это собранные в один application набор контроллеров, библиотек, моделей и вьюшек. Если так, то видимо обычно их два бывает в рабочем приложении, frontend и backend, думаю в последнем нам такие url бесполезные и не заботит, то для frontend’а роутинг вполне мог бы и определять, что это цифровой id и значит это наш такой-то app и т.п.

    Схема конечно имеет право на жизнь. Например в одном из моих новых проектов я использовал схожий принцип.
    Только у меня uri строится по дереву
    /news/about/id.12.title.16.html
    /news/about — это дерево
    id.12.title.hello-world — это параметры id=>12, title=>hello-world

    Вот например
    http://sampostroyu.ru/catalogue/product.426.sayding-d4-5d-karamel.html
    здесь например sayding-d4… нафиг не нужный параметр, лишь для сео и делает автоматом транслитерацией (ибо позиций много и грузятся из 1С), то его можно стереть или написать что угодно
    http://sampostroyu.ru/catalogue/product.426.html будет работать, это основа

    Так же есть разумеется бэкэнд и фронтэнд, но и то и другое всё завязано на дереве адресов, потому на самом деле роутинга от фреймворка и каких-либо ушей application не видно

    С тэгами да, есть неувязка, но я привык считать тэги параметром, а не как ресурсом uri, потому /bog/posts?tag=траляля саме то имхо

    1. MpaK, ты SE не занимаешься, чтоль? :) Эти слаги ваще нах не нужны, кроме как для поисковиков щас.

    2. Ага, не дочитал, вижу — занимаешься :)

      Не, не бекенд-фронтенд. Апп в Жанго — это логически собранный кусок приложения. Например, «статьи», «блог», «форум».

  5. Ну СЕО это так, по просьбе заказчика, как говориться за деньги клиента любой его каприз, хоть шрифты в 42em :)

    С app понял, а-ля пакеты где собраны контроллеры с его моделями, библиотеками и вьюшками. У меня в CMS это HMVC модули.

  6. А мне нравится схема /год/месяц/число/херня-для-человека. Тогда можно стирать до слеша и получать записи за число, месяц, год соответственно. В этом хоть смысл есть, а кому нафиг нужен числовой ID?

  7. /год/месяц/число/ мне кажется избыточным (если только речь не о новостном сайте/разделе сайта), поскольку это тоже по сути «херня для человека». Тогда лучше /ид/херня-для-человека-вместе-с-датой-если-надо

  8. Тормоз, ну это для новостей логично и удобно. Для например каталога товаров ну совсем не в тему или например в разделе История — О компании, Сотрудники и т.п. года жеж не нужны :)

    Потому и все нормальные фреймворки дают в руки правила роутинга

  9. Ну да, согласен, конечно. Смотря где. Но для блога точно отлично подходит структура с датами, как я выше показал. А вот реплику Samlowry про необходимость ID компьютеру не понял. Нафиг он ему? ID внутри машины и так существует, зачем это показывать наружу?

  10. Тормоз, ну это не то чтобы компьютеру, скрипт блога, сайта, cms должен как-то однозначно реагировать на адресную строку. Потому желательно иметь уникальный URI, таким может выступать уникальный ID например, чтобы точно знать, что на
    100 — надо показать пост в блоге с номером 100 и шаблоном красный
    а например на 200 показать контактные данные в шаблоне зеленого цвета :)

    ID не всегда просто может быть числовой, это может быть например уникальное название или уникальное название из вложенных в друг-друга папочек и т.д.

  11. @Тормоз:
    Что непонятного-то?
    Что будет со входящими ссылками, если ты решишь у записи сменить URL? 404 будет.
    Поэтому URL логически делится на две части: числовой ID, необходимый CMS для распознавания URL, и человекочитаемая-хрень, необходимая только для SEO и повышения юзабилити. Вторую часть можно хоть как менять, при этом все прежние ссылки на запись будут оставаться валидными (редиректиться на канонический вариант).

    1. Тормоз просто слишком опирается на юзабилити. Не, когда-то, когда компьютеры станут очень большими, а сохранение всех старых урлов будет стандартной частью любого фреймворка — это будет пох. Может быть, тогда и id страницы будет не цифрой, а текстовым полем, в котором будет лежать урл — так будет нагляднее при программировании :)

  12. Тормоз, на примерах всё проще
    вот адресная строка
    /about/
    /contacts/

    они должны однозначно показывать, первый текст о компании, второй схему проезда

    не желательно, чтобы при заходе на about у тебя то текст показался, то не показался или хуже еще что-то иное покажет :) /about/ можно считать тем же уникальным ID (соблюдать уникальность надо нам) по которому мы точно можем сказать какая страница будет показана.

    вложенные это например /about/russia/ можно считать это тоже уникальным ID, можно считать это иерархией уникальных ID и т.п.

  13. Clr, про смену URLа не подумал. По идее, их менять нафиг не надо, но это иногда случается, да :)

  14. Благородный дон Тормоз, я, может, плохо объяснил, но идея крутилась вокруг возможности смены урлов и только неё.

  15. Да наверно просто я непонятливый. Однако, всё равно решение с запоминанием старых URL было бы красивей, человекоприятней. Машина с памятью, вот пусть она и запоминает.

  16. Тормоз, ну с идей, которую предлагает samlowry даже запонимать старые URI не надо, но у неё другой момент — излишество параметров и не совсем ясно с построением иерархии объектов

  17. Бесценные данные? :))) Ну не, я отказываюсь, сохранять постоянный навоз из кучи спама, розовощеких блондинок и смачно пердящих юнцов с прыщами на всяких форумах школоты

  18. «Ты вообще сути не понял.» такие фразы без продолжения мысли принято записывать в «губошлество» еще это называют «бла-бла-бла» :)))

  19. А куда принято записывать за выдранные из контекста пару слов и развитие их до пердящих юнцов?

Комментарии закрыты.