Почему я должен использовать URL-адреса в стиле “Web 2.0”?[закрыто]

Question

Короче говоря, зачем использовать что-то вроде http://stackoverflow.com/badges/6/supporter вместо чего-то "более простого" (и притом субъективно) вроде http://stackoverflow.com/badges/6/.

Даже на моем собственном сайте я только что использовал /post / 6 / для ссылки на записи (по идентификаторам, хотя я все еще храню slug.) Вместо /post/6/small-rant-on-urls, и в некоторых случаях они могут получить даже еще более абсурдно, гораздо больше, чем это действительно необходимо.

Answer 1

Потому что у вас потенциально могут получиться дубликаты, если вы не будете осторожны.Я предполагаю, что stack overflow добавил идентификатор, потому что существовал высокий потенциал для дубликатов, учитывая объем созданных записей.

Другие системы могут предпочесть не использовать идентификатор в URL-адресе - например, системе ведения блога, вероятно, это не понадобилось бы.

Будет лучше, если у вас есть пользовательский контент, результатом которого является новый URL, созданный для включения идентификатора записи.Если единственный способ создания новых URL-адресов - это доступ к типу администратора, вы, вероятно, можете обойтись без этого, пока проверяете наличие дубликатов.

Answer 2

Оптимизация в поисковых системах было бы одним из них, а также сделало бы URL-адрес более читаемым для людей.Поисковым системам обычно нравится, чтобы ваш URL-адрес, заголовок и H2 содержали "тему" страницы.

Если у вас есть и то, и другое, то вы можете вручную ввести / ID и автоматически перейти к "цветистому" URL-адресу с перезаписью..немного экономит ваши пальцы :)

Answer 3

Добавление slug во все ссылки Для контент помогает поисковым системам, потому что поисковые системы обычно используют слова в самом URL-адресе, чтобы помочь индексировать контент.

Answer 4

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

Причина включения полного названия статьи заключается в том, что Google начисляет кучу бонусных баллов за поисковые запросы, совпадающие по имени файла.

Answer 5

@Грег Хьюгилл

Добавление slug во все ссылки на контент помогает поисковым системам, поскольку поисковые системы обычно используют слова в самом URL-адресе, чтобы помочь индексировать контент.

Мне следовало бы немного уточнить:Я имел в виду URL-адреса, которые имеют оба идентификатора и пуля в них.Я просто не вижу смысла в том, чтобы иметь что-то вроде /post/1/la-la-la-la-text-hahahaha против /post/1/ или /post/la-la-la-la-text-hahahaha, поскольку первый вариант работал бы без дополнительного текста в конце.

Answer 6

URL-адрес является частью веб-интерфейса пользователя.

Существует отслеживание использования поисковой системы который обнаружил, что люди тратят 24% своего пристального времени они проводят, просматривая URL-адреса в результатах поиска.

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

Answer 7

Возможно, быстрее получить публикацию в блоге по идентификатору, чем по слагу, поэтому укажите идентификатор для SQL-запроса и слаг для поисковых систем (SEO).

https://stackoverflow.com/users/58163/movaxes65675

Мне нравится тип /post /la-la-la-la-text-хахахаха, я могу запомнить URL, узнать название поста (до фактической загрузки сайта).Не очень нравится /post / 1 / для меня это ничего не значит, кроме поста № 1 (плохо для маркетинга?)

Редактировать:идентификатор также помогает избежать дубликатов, как указал andybaird

Answer 8

Ну, во-первых, следует отметить, что "URL-адреса в стиле Web 2.0" на самом деле являются частью чего-то, называемого ОТДЫХ.Эти URL-адреса иногда называют URL-адресами RESTful.В заявленные преимущества являются:

• Обеспечивает улучшенное время отклика и уменьшенную нагрузку на сервер благодаря своей поддержке для кэширования представлений;
• Улучшает масштабируемость сервера за счет уменьшения необходимости поддерживать сеанс состояние.Это означает, что разные серверы могут использоваться для обработки разных запросов в сеансе;
• Требует написания меньшего количества клиентского программного обеспечения, чем при других подходах, поскольку один браузер может получить доступ к любому приложению и любому ресурсу;
• Меньше зависит от программного обеспечения поставщика и механизмов, которые накладывают дополнительный слой платформы обмена сообщениями поверх HTTP;
• Обеспечивает эквивалентную функциональность по сравнению с альтернативными подходы к коммуникации;
• Не требует отдельного механизма обнаружения ресурсов, благодаря использованию гиперссылок в представлениях;
• Обеспечивает лучшую долгосрочную совместимость и эволюционируемость характеристики, чем у RPC.Это связано Для:
  • Способность типов документов, таких как HTML, развиваться без нарушения обратной- или прямой-совместимости;и
  • Способность ресурсов добавлять поддержку для новых типов контента по мере их определения без удаления или уменьшения поддержки для старых типов контента .