Предложить лучший стиль URL - PullRequest
Новая
       22

Предложить лучший стиль URL

0 голосов
/ 10 июля 2010

Наша система

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

  • ключевое слово для поиска
  • экзаменационный фильтр
  • предметный фильтр
  • фильтр диапазона дат
  • фильтр названий курсов ... ... и т.д.

и есть параметры разбивки на страницы и сортировки, такие как

  • Номер страницы
  • Количество результатов на странице
  • поле сортировки
  • порядок сортировки

У нас были такие URL, как: - 

www.projectname/module/search/<search keyword>/<examination filter>/<subject filter>/
www.projectname/module/search/<search keyword>/<examination filter>/<subject filter>/<Page number>,<Number of results in a page>,<sort field>,<sort order>

.... ... ...

И у нас было одно правило перезаписи в htaccess для каждого варианта.

Текущая проблема

Из-за проблем с несколькими URL-адресами, вызывающих проблемы в обслуживании кода, я теперь прибегаю к функциям PHP для выполнения задачи вместо htaccess, что-то похожее на библиотеки URL-адресов каркасов, таких как Zend, Codeignitor.

Мой вопрос

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

  1. Наличие всех параметров URL, присутствующих во всех URL, независимо от того, нужны они или нет, например: -

    www.projectname / module / search / hello // 110 / ... все остальные параметры присутствуют ...

    Здесь нам не нужно упоминать, какой параметр является поисковым ключевым словом, а какой - тематическим фильтром. Простые функции парсера URL всегда принимают 2-й параметр из www.projectname / module / в качестве ключевого слова поиска (в данном случае, привет) и аналогично для других параметров. В этом примере фильтр экзамена неприменим, поэтому он остается пустым и не нарушает URL, но это хорошо. Если было много пустых параметров, то появилось бы много косых черт

  2. Предоставление свободы передачи параметров URL в любом порядке, например: -

    www.projectname / module / search / search_keyword / hello / subject_filter / 110 / ... присутствуют только другие необходимые параметры ... www.projectname / module / search / subject_filter / 110 / search_keyword / hello / ... присутствуют только другие необходимые параметры ...

    Оба эти URL-адреса означают одно и то же В этом соглашении функция парсера URL анализирует каждую пару имя-значение и принимает значение рядом с именем «search_keyword» в качестве ключевого слова для поиска и аналогичным образом для других (в этом примере name = search_keyword, value = hello). Функция будет анализировать каждую пару имен и значений, поэтому термин search_keyword, отображаемый в качестве значения для другой пары, не будет мешать.

Пожалуйста, примите во внимание следующие факторы: - - SEO дружелюбие - простота обслуживания (учитывая, что в будущем могут быть добавлены новые фильтры)

Пожалуйста, дайте несколько советов по улучшению SEO. Я мало что знаю об этом

Спасибо

Ответы [ 2 ]

0 голосов
/ 12 июля 2010

Я сам выбрал лучшее решение. Я чувствую, что 2-е соглашение, т.е. Allowing freedom to pass URL params in any order лучше, только потому, что 1-е соглашение может привести к обратным слешам, если в некоторых случаях один или несколько параметров не будут переданы. Чтобы узнать больше о том, почему мы должны избегать лишних косых черт, проверьте Почему мы не используем такие форматы URL?

0 голосов
/ 10 июля 2010

В Zend Framework объект Request позволяет передавать данные в любом порядке и, в конечном итоге, использовать помощник Router или Url View для создания URL страницы так, как вы хотите в данный момент.

Это лучший шаблон, который я знаю. Нет правил .htaccess вообще.

...