Комментарии 19
Чем https://example.com/ochen-krutoi-razdel/ochen-krutaya-statya-kotoryu-nuzhno-obyazatelino-prochitat лучше https://example.com/201701/11 для юзера?
Посмотрите хотя бы на выдачу Гугла по какому-нибудь запросу. Красиво и понятно составленные ссылки могут иметь решающее значение при выборе ссылки для перехода. Это не значит что нужно делать по вот такому примеру как вы написали. Оба эти варианта оставляют желать лучшего.
могут иметь решающее значение при выборе ссылки для перехода
а могут и не быть. Это утверждение нуждается в проверке а не в голословных утверждениях. Ибо больше похоже на культ карго.
С учетом того что в выборке отображается заголовок в нормальном человеческом виде, дескрипшен и т.д. я не вижу ни одной причины загоняться по формату ссылок.
Как вы верно замечаете что ЧПУ сейчас не в тренде, но это не значит что можно на них забить и полностью игнорировать. Нужно найти баланс между "загоняться" и совсем забросить. Ведь это ещё одна строка в поисковой выдаче, на которую вы влияете! Разве это разумно вот так просто отказываться от возможностей, которые дают поисковики?
Нужно найти баланс между "загоняться" и совсем забросить.
Давайте составим требования к URL:
- уникальный идентификатор ресурсов, желательно постоянный.
- чем короче тем лучше
- по нему должно быть легко понятно "что внутри" с точки зрения чтения эксес логов.
Хорошие примеры урлов:
/posts/2017/06/23/123323
/products/123134
/products/123134-kakoyto-product
/users/DQ4ADQsCCwACDgsLBAUGDgПлохие примеры урлов:
/raznoie/samoy-krutoy-product-v-catalogeПоследний пример плох тем что он:
- не гарантирует нам постоянство — если поменялся слаг — поменяется и урл, надо хэндлить редиректы (чего обычно не происходит), излишняя сложность
- может быть длинным и сложным
- по логам ничего не понятно
Вот это уже похоже на взвешенный подход. Вам бы статью про ЧПУ написать.
Последний пример плох тем что он:
не гарантирует нам постоянство — если поменялся слаг — поменяется и урл, надо хэндлить редиректы (чего обычно не происходит), излишняя сложность
Если поменялся slug на ту страницу, для которой требовался ЧПУ, то это уже другая страница, которую нужно индексировать по новому в подавляющем большинстве случаев. Вы сами подумайте — вы поменяли название продукта/статьи/еще чего-то. Так что о редиректах тут речь идет только в том случае, когда ЧПУ применяется неуместно.
может быть длинным и сложным
Если полный адрес страницы укладывается в 128 символов, то кого это волнует? Да зачастую и более длинные ссылки мало кого раздражают. Длинный адрес — не является сложным. Плохо составленный адрес даже будучи коротким может вынести мозг почище 256-ти символьного.
по логам ничего не понятно
Логи нужно заполнять так, чтобы было понятно. А главное заполнять их исходя из понимания того как вы их будете потом читать и какая вам понадобится информация для понимания и в каком виде. И уж точно тут мало что зависит от длины адреса строки.
Если говорить про стандартные Apache логи, то чем вам облегчит чтение при урле типа
/products/123134
?
123134 — это такой же ID как и slug. В случае если в урле есть еще и slug категории, то у вас есть два ID для выборки интересующей статьи, которые, кстати, еще из логов уже могут указать на тематику страницы с данным урлом. В итоге, на сколько я понимаю, вы недовольны тем, что вам придется делать на одно действие больше при выборки из базы данных статьи, вызвавшей сбой в программе? На месте вашего работодателя (если таковой имеется) я бы подумал — повышать вам ЗП или нет.
Пока все из того, что я прочитал в ваших комментариях, относиться к тому, что вам проще работать с числовыми идентификаторами сущностей. Программистов/сисадминов в этом винить трудно, но речь идет не о нашем удобстве, а о том, что можно продукт сделать лучше.
Если поменялся slug на ту страницу, для которой требовался ЧПУ, то это уже другая страница, которую нужно индексировать по новому в подавляющем большинстве случаев. Вы сами подумайте — вы поменяли название продукта/статьи/еще чего-то.
а теперь подумайте. Я скопировал ссылку и скинул ее кому-то. Этот кто-то спустя какое-то время (месяц) кликает по ней и получает 404. Да, редиректы определенно не нужны.
Причин для изменения "урла" тут множество. Это может быть не только изменение продукта. К примеру продукт относился к какой-то общей категории, и у нас появилась необходимость разделить эту общую категорию на две более специализированные. В этом случае продукт переносится в новую категорию и соответственно меняется ссылка.
Если полный адрес страницы укладывается в 128 символов, то кого это волнует?
а если не укладывается? Если вот было хорошо, укладывалось, но это не покрывает все 100% кейсов.
Плохо составленный адрес даже будучи коротким может вынести мозг почище 256-ти символьного.
Проведите исследование, приведите статистику, какой процент пользователей "читает" урлы.
И уж точно тут мало что зависит от длины адреса строки.
вопрос не в длине, а в отсутствии необходимости учитывать контекст. Все должно быть максимально явно.
В случае если в урле есть еще и slug категории, то у вас есть два ID для выборки интересующей статьи
Какой толк мне от второго идентификатора если для нахождения статьи мне достаточно одного?
которые, кстати, еще из логов уже могут указать на тематику страницы с данным урлом.
Те задачи где надо учитывать тематику больше подходят под описание задач аналитики. И по сути имея идентификаторы можно легко выгрести самую разнообразную статистику.
В логах же интересует что делал человек. Скажем у нас есть ошибка при добавлении товара в корзину. И каждому пользователю присваивается некий идентификатор. Видя ошибку мы можем просто грепнуть по идентификатору и глянуть какие именно продукты он пытался купить и тд.
Конечно пример надуманный, но от этого толка явно больше.
На месте вашего работодателя (если таковой имеется) я бы подумал — повышать вам ЗП или нет.
когда речь идет о изменении оплаты труда, всегда стоит думать.
Программистов/сисадминов в этом винить трудно, но речь идет не о нашем удобстве, а о том, что можно продукт сделать лучше.
Ответьте на вопрос, КАК такая вещи как ЧПУ поможет сделать продукт лучше. Польза для пользователей весьма сомнительна, количество потенциальных проблем зависящих от контекста задачи может сильно повлиять на стоимость этой фичи для бизнеса. Причем бизнесу как таковому профита от этого может и не быть вовсе.
Пока все из того, что я прочитал в ваших комментариях, относиться к тому, что вам проще работать с числовыми идентификаторами сущностей.
Из того что я прочитал все относится к тому что ЧПУ нужны, но зачем — ответа я так и не получил. Урлы читают? нет. Урлы учитываются при ранжировании поисковиками?
Есть огромная разница между "урлами с семантикой" и то о чем вы говорите. Семантика урлов нужна, но для того что бы у них была эта самая семантика совершенно не нужно пихать название продукта в урл.
- ID сущности постоянен
- Slug сущности может меняется
Поэтому, делать ссылки только со slug неправильно. Это может привести к следующим проблемам:
- Slug поменялся и ссылка отдает 404.
Это плохо для пользователя и для поисковиков. При частой смене slug можно и бан словить. - Slug сущности А сменился, а slug сущности Б сменился на slug сущности А.
Теперь по старой ссылке отдается другой контент. Это плохо для пользователя и для SEO. - Смена slug затрудняет идентификацию сущности в логах.
Ещё Google рекомендует в ссылках указывать числовой идентификатор (лень искать ссылку).
Решение описанных проблем это использование в URL, и ID и slug. И выглядеть это будет так:
/article/{id}-{slug}Что это на даёт:
- Мы гарантируем уникальность ссылок даже при смене slug.
- Ссылки соответствуют рекомендациям Google.
- В логах мы увидим ID сущности.
- ЧПУ у нас сохраняется.
- Мы можем избавится от 404 из-за смены slug.
Вы наверное уже догадались как избавится от 404, но я всё же поясню.
В контроллер выбираем сущность по ID из запроса. Проверяем текущий slug в сущности и slug из запроса. Если не совпадают, делаем 301 редирект на правильный slug.
Лёгким мановением руки решили все проблемы)))
Оба эти варианта оставляют желать лучшего.
Из моей статьи:
URL на вашем сайте должны содержать релевантную для поисковика информацию о страничках, на которые они ведут и иметь продуманную вложенность
Ваш длинный URL содержит вредную избыточность. В примере моей статьи приведен лишь базовый пример работы со slug-ами. В действительности нужно давать возможность их «причесывать» под SEO контентменеджеру сайта, и/или самому автору статьи.
Ну а на счет того, что для пользователя большой разницы нет, ЧПУ-не ЧПУ, — об этом я и сам написал в статье. И с вами согласен. Однако есть большое НО: Если пользователь продвинутый (умеет печатать не только указательными пальцами), то на ссылки внимание он обращает и получает из них много информации. Например я обращаю внимание. Особенно когда хожу по ссылкам в поисковике.
https://example.com/ochen-krutoi-razdel/ochen-krutaya-statya-kotoryu-nuzhno-obyazatelino-prochitat — в этой ссылке я могу удалить ochen-krutaya-statya-kotoryu-nuzhno-obyazatelino-prochitat и попасть в раздел. К тому же я примерно понимаю где я нахожусь. )
Здесь https://example.com/201701/11 удаляя "11" я не могу даже западозрить куда попаду.
Если фильтрация и сортировка подразумевает сотню параметров, то в общем-то и нет смысла сувать это все в ЧПУ, так как такой URL уже приобретает характер служебного URL. То есть такого URL, который индексировать поисковик не должен, да и пользователю лишний раз его показывать не стоит.
Но если параметров фильтрации не больше 20-ти и одновременно из них не может быть выбрано больше 5-ти, то это можно оформить в виде ЧПУ ссылок.
Сами подумайте, ведь ЧПУ типа:
http(s)://Домен/slug-категории/slug-подкатегории/
уже является ЧПУ с фильтрацией. Здесь фильтрация по категории.
Значит здесь думать нужно так: если в результате фильтрации получаются URL-ы, которые вы в гипотетической смтуации могли бы вставить в гипотетическую менюшку и такая менюшка была бы удобна для пользователя, то подобная фильтрация заслуживает быть ЧПУ. А вот как это реализовать — это другой вопрос. Один экшин в симфони может сопоставляться с большим количеством маршрутов:
/**
* @Route("/search/category/{category_slug}/", name="search_by_category")
* @Route("/search/date-from/{date-from}/date-to/{date-to}", name="search_by_date")
* @Method({"GET"})
* @return \Symfony\Component\HttpFoundation\RedirectResponse|\Symfony\Component\HttpFoundation\Response
*/
public function searchAction(Request $request, string $category_slug = null, $date-from = null, $date-to = null )
{
...
}
Либо еще как-то эксперементировать с маршрутами
параметры фильтрации передаются на сервер банальными GET параметрами
Всегда считал, что так правильнее если эту ссылку нужно кому-то скинуть. Иначе будет примерно так: вот ссылка на раздел, там выбери такие-то параметры фильтра и где-то там на третьем экране нужное что-то…
Еще есть вопрос по поводу уникальности slug: если есть товар с одинаковым наименованием, то как быть?
Или один товар в разных категориях, или две подкатегориями с одинаковым названием в разных категориях?
В общем проблема имеет место быть и простым уникальным индексом не решается.
Но, как я говорил в статье, Doctrine Sluggable behavior extension берет на себя ответственность по построению уникальных slug-ов.
Я сейчас создал три раза подряд продукт с одним и тем же именем: «Что-то осмысленное». Автоматически сгенерированные slug-и получились такими:
- chto-to-osmyslennoe
- chto-to-osmyslennoe-1
- chto-to-osmyslennoe-2
Если этот вариант не нравится, то можно для поля slug указать генерацию на основе не одного поля, а на основе двух. Например:
@Gedmo\Slug(fields={"name", "publishDate"})Но это громоздкие slug-и получатся, так что надо под конкретный случай разбирать.
Возможность иметь продукты с одинаковым наименованием и slug-ом в двух разных категориях я не рассматривал.
уже является ЧПУ с фильтрацией. Здесь фильтрация по категории.
а теперь сделайте мне так что бы можно было выводить продукты из 5-ти различных категорий. И скажите что удобнее. сделать /products?category=1,2,5,12 или /products/category1-category2-category3... и потом еще хэндлить редиректы (названия то могут поменяться, но ссылки должны сохраняться, а тут могут быть коллизии).
Я это к чему. Основная характеристика ссылок — они должны быть постоянными. Или хотя бы по максимуму постоянными. Не должно быть такого что я поделился ссылкой, контент менеджер переименовал категорию и ссылка стала невалидной. А это уже влечет за собой огромное количество технических проблем и неимоверное усложенение. Причем профит от этого действа мягко скажем сомнительный.
В целом же любая фильтрация и тд. это уже служебная ссылка. Как правило индексируется все же детали по продукту, есть возможность подсказывать краулерам что является основным контентом и т.д. ЧПУ было в тренде лет 10 назад, сейчас в этом нет никакого смысла.
На самом деле урл не является предметом семантического, то есть смыслового анализа. Смотрите факт 3 на скриншоте выше. Если рассмотреть всю ссылку страницы первого места, там вообще использован ни о чём не говорящий числовой хеш.
Однако никто не отменяет того, что заказчик сайта может решить, что важно внимание мелочам. И тут лучше знать как делать ЧПУ, чем не знать.
Ну что же, это грустно. Я помню, что 12 лет назад команда, в которой я работал, много сил и времени потратила, чтобы создать коробочный продукт под Joomla. Этот продукт позволял управлять ссылками на сайте, и тем какой вид будет у ЧПУ. Помню это было интересной работой для тех дремучих лет. Да и продукт раскупался как пирожки.
Впрочем технологий не становится меньше. Скорее наоборот и в геометрической прогрессии. Скучать не приходится, даже если что-то устарело.
ЧПУ (SEF URLs) в Symfony 3 — автогенерация slug, настройка и маршрутизация