У меня проблема с принятием решения о включении категории / пути в URL-маршрутизацию. Предположим, в моем образце веб-приложения есть продукты, относящиеся к некоторым категориям. Например:
Book1 Attached to -> Category1 | Category2
Book2 Attached to -> Category1 | Category2 | Category3
Book3 Attached to -> Category2 | Category3
И определенная карта маршрутизации для продуктов:
url: "{controller}/{action}/{languageCode}/{category}/{product}"
defaults: new { controller = "Home", action = "ViewItem" }
Итак, возможная маршрутизация для Book1:
[Domain Name]/Home/ViewItem/en-US/Category1/Book1
[Domain Name]/Home/ViewItem/en-US/Category2/Book1
Возможная маршрутизация для Book2:
[Domain Name]/Home/ViewItem/en-US/Category1/Book2
[Domain Name]/Home/ViewItem/en-US/Category2/Book2
[Domain Name]/Home/ViewItem/en-US/Category3/Book2
Я хочу сохранить и узнать текущую категорию, но у меня есть один уникальный URL-адрес для каждого продукта (для отслеживания и обмена URL-адресами поисковой системы). Думаю использовать Переменная сеанса или ViewBag, даже Cookie-файлы, но у каждого из них есть свои ограничения и минусы. Например, использование файлов cookie может вызвать некоторые проблемы: если установить слишком малое время истечения срока действия, он может потерять текущий путь, когда пользователь приостанавливает работу на некоторых страницах, а если он установлен слишком долго, может привести пользователя к старому пути просмотра, даже если пользователь запросил домашнюю страницу в новом открывающемся браузере из-за существующего файла cookie (за исключением того, что у меня был некоторый опыт работы с файлами cookie, и я считаю, что это не работает точно всегда), О Сессия и ViewBag Я не знаю, лучше ли их использовать, Так может ли кто-нибудь поделиться проверенным решением или хорошей идеей? Я буду признателен за это.
У вас должна быть страница mywebsite.com/product1 (каноническая версия URL). Включение всех версий URL не поможет. Скорее всего, это просто запутает Google и может привести к тому, что Google проигнорирует определенные URL-адреса.
Даже если вы укажете каноническую версию и на ваших страницах будет тег rel canonical, Google может по-прежнему рассматривать другую версию URL как каноническую.
Тогда в идеале я бы решил настоящую проблему здесь и имел бы только одну версию URL-адреса продукта на вашем сайте (чтобы версии с категорией в URL-адресе перенаправляли на версию URL-адреса без категории в URL-адресе). Таким образом, вам даже не придется беспокоиться обо всех проблемах, которые может вызвать дублирование контента.
Спасибо за ответ, но самое главное - как хранить и отслеживать выбранную категорию? После перенаправления URL-адреса на версию без категории я потеряю его, я ошибаюсь?
Поскольку вы единственный ответчик на этот вопрос, я дам вам награду, если нет ничего лучше, чтобы ответить на этот вопрос до истечения срока действия, но не помечен как ответ, потому что я еще не уверен в этом ответе.
Я думаю, что @Mikaal заслуживает награды, но я ценю вас за внимание, я укажу на ваш ответ +1, еще раз спасибо.
Я подозреваю, что это не проблема маршрутизации, а проблема архитектуры. Я думаю, что «языковой код» и «категория» должны быть атрибутом объекта Book, а не быть частью маршрута.
Тогда у вас будут такие URL-адреса:
{домен} / {контроллер} / книга / идентификатор
А для представлений, связанных с «категорией» или «языковым кодом», у вас могут быть URL-адреса, например:
{домен} / {контроллер} / search? languageCode = enUS & category = 1
Это все равно будет идеально RESTful и, на мой взгляд, намного проще.
Я не хочу, чтобы URL-адрес имел форму «? Param = value & ...», вы можете просмотреть отличные веб-сайты и увидеть, что языковые коды являются частью URL-адреса, например «/ en / ...», потому что некоторый контент может существуют на одном языке и не существуют на другом, поэтому наличие кода языка в URL-адресе логично, но по категориям вы можете перейти к специальному продукту из разных категорий. Продукт уникален, но категория! Мне нужно знать категорию без URL-адреса.
Если вы хотите избежать чего-либо в URL-адресе, вы можете выполнить запрос POST вместо GET, чтобы они не отображались в URL-адресе.
Если вы хотите отслеживать категорию, не сохраняя ее в URL-адресе, вы можете: 1) Передать ее как параметр запроса (в запросе POST или GET, в зависимости от того, хотите ли вы, чтобы он отображался в URL). 2) Передайте его с помощью ViewBag. Если вы хотите сохранить это в течение более длительного периода, вы можете добавить его в сеанс, но вам также нужно будет обновлять это каждый раз при смене категории. И, читая ваш вопрос выше, я бы посоветовал вам хранить только «categoryName / categoryId» в «Session» / «ViewBag» / «Request Parameter» вместо «Path».
Пожалуйста, прочтите вопрос еще раз, я знаю об этих способах, но я не знаю, какой из них наиболее логичен и удобен для поисковых систем! Я описал в вопросе, какие проблемы и опасения существуют при использовании любого из них.
На основании моих знаний «Как вы сохраняете категорию на своем сервере?» не повлияет на SEO / удобство поиска ваших веб-страниц, потому что поисковые системы не зависят от внутреннего устройства вашего сервера. А с технической точки зрения, какие подходы использовать полностью зависит от вас, если вам не нужно сохранять «категорию» в течение более длительного периода, то «ViewBag» может быть хорошим и простым решением. В противном случае сеанс тоже был бы хорош.
Однако небольшое влияние на SEO окажет сам URL-адрес, который вы в конечном итоге создаете, потому что в конечном итоге веб-страницы, которые представляют эти URL-адреса, в конечном итоге будут где-то проиндексированы против какого-либо поискового запроса.
Хорошее практическое правило согласно руководящим принципам REST - иметь один уникальный URI для каждого ресурса. Если у вас есть несколько URI, представляющих один и тот же ресурс, вы, вероятно, в конечном итоге уменьшите SEO, поскольку вместо одной часто посещаемой страницы у вас будут две чуть менее посещаемые страницы. И я думаю, что первое лучше. Кроме того, я не знаю, как это может повлиять на SEO.
Представьте, что вы поделились URL-адресом для специального продукта, например, в Facebook, и у вас есть категория в этом URL-адресе. Через некоторое время вы удаляете эту категорию, но продукт. Теперь этот URL-адрес не будет работать, потому что категория не существует. Это простой пример, чтобы понять мой взгляд.
Ааа, понятно. Это довольно интересная перспектива. Возможно, stackoverflow.com/questions/9546635/… может пролить на это немного больше света.
"вместо одной часто посещаемой страницы у вас будут две чуть менее посещаемые страницы" <- я не хочу этого, целевой продукт уникален, поэтому URL-адрес для него тоже должен быть уникальным.
Позвольте нам продолжить обсуждение в чате.
Конечно ... Дайте этому чтение moz.com/blog/15-seo-best-practices-for-structuring-urls Пункт № 4 очень важен для вашего запроса.
Я переместил это обсуждение в чат.
Чат здесь: chat.stackoverflow.com/rooms/170809/…
Хотя вы не рекомендовали точное решение, я вижу, что вы потратили время, чтобы ответить на вопрос, и обратили внимание на этот вопрос, я буду рад услышать от вас о правильном решении этой проблемы, но пока я думаю, что вы заслужили получить награду Большое спасибо.
Большой! Спасибо. Я надеюсь, что наша дискуссия была полезна для того, чтобы, по крайней мере, приблизиться к точному решению, если не прийти к нему. Я дам вам знать, если дам более точный ответ.
Безусловно, мы закроем решение после обсуждения. Цените это, пожалуйста :)
Меня поразило голосование "против" без каких-либо комментариев, описания или причины для этого. Я назначил свои 50 ценных очков наградой, потому что ваш ответ очень важен для меня. Если вы понимаете мой вопрос и знаете о решении, пожалуйста, ответьте, в противном случае оставьте его. Если вы думаете, что это глупый вопрос, и решаете проголосовать против, по крайней мере, напишите комментарий и скажите, в чем ваша причина. Спасибо всем.