Как обеспечить несколько функций поиска на сайте? - PullRequest
1 голос
/ 26 февраля 2009

Я занимаюсь разработкой веб-приложения, в котором у меня есть следующий тип поиска:

  • Обычный поиск : где пользователь вводит ключевое слово для поиска в записях.
  • Popular: это не вид поиска, он будет отображать популярные записи на сайте, как это делают digg и другие сайты социальных закладок.
  • Последние: В этом я показываю Недавно добавленные записи на моем сайте.
  • Поиск города: Здесь я представляю названия городов пользователю, например, "Дели", "Мумбаи" и т. Д., И когда пользователь щелкает эту ссылку, отображаются все записи из этого города.
  • Поиск по тегу: То же, что и при поиске по городу. У меня есть ссылки на теги, когда пользователь нажимает на тег, тогда все записи, отмеченные этим тегом, будут отображаться для пользователя.
  • Поиск по алфавиту: То же, что и город, и тег для этой функции также есть ссылки из букв типа "A", "B", .... и т. Д., И когда пользователь щелкает ссылку на любую букву, начинаются все записи с этим конкретным письмом будет отображаться пользователю

Теперь, моя проблема в том, что я должен предоставить пользователю перечисленные выше поисковые запросы, но я не могу решить, что у меня будет одна страница (result.aspx), которая будет отображать все записи поиска, и я ' Используя строку запроса, я выясню, какой запрос использует пользователь, и какие данные я должен показать пользователю. Например, допустим, я ищу город, Дели и Tag Delhi-Hotels, тогда URL-адреса для обоих будут такими:

Для города: www.example.com/result.aspx?search_type=city&city_name=delhi

Для тегов: www.example.com/result.aspx?search_type=tag&tag_name=delhi-hotels

Для обычного поиска: www.example.com/result.aspx?search_type=normal&q=delhi+hotels+and+bar&filter=hotlsOnly

Теперь я чувствую себя выше. Идея использовать одну страницу для всех поисков - грязная. Поэтому я подумал о еще более чистой идее, которая использует отдельные страницы для всех типов поиска как

Для города: www.example.com/city.aspx?name=delhi

Для тегов: www.example.com/tag.aspx?name=delhi-hotels

Для обычного поиска: www.example.com/result.aspx?q=delhi+hotels+and+bar&filter=hotlsOnly

Для недавних: www.example.com/recent.aspx

Для популярных: www.example.com/popular.aspx

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

С новой Идеей все в порядке, Но я все еще не могу решить, с чем мне, пожалуй, нужно идти, Может ли кто-нибудь высказать мне ваши мысли по этой проблеме.

Я хочу реализовать идею, которую будет легко поддерживать, оптимизировать для SEO (дать хороший рейтинг моему веб-сайту), удобно для пользователя (легко использовать и понять для пользователей)

Спасибо.

Ответы [ 4 ]

2 голосов
/ 26 февраля 2009

Одна вещь, которую стоит упомянуть на фронте SEO:

Поскольку многие страницы "результатов" будут ссылаться на один и тот же контент, есть несколько преимуществ появления *, чтобы иметь разные URL для этих страниц:

  1. Некоторые поисковые системы оказываются перекрестными, если у вас есть дублированный контент на сайте или существует возможность создания почти бесконечных списков.
  2. Анализ транспортных потоков.

Так, например, для пункта 1 вы заметите, что SO имеет множество способов поиска вопросов, включая:

  1. На домашней странице
  2. Через / вопросы
  3. Сквозь / теги
  4. Через / без ответа
  5. Сквозная / подача
  6. Через / поиск

Если вы посмотрите robots.txt для SO, вы увидите, что паукам не разрешено посещать (среди прочего):

Disallow: /tags
Disallow: /unanswered
Disallow: /search
Disallow: /feeds
Disallow: /questions/tagged

Таким образом, поисковая система должна найти только один маршрут к контенту, а не три или четыре.

Если все они пройдут через одну и ту же страницу, вы не сможете фильтровать таким образом. В идеале вы хотите, чтобы поисковая система индексировала список городов и тегов, но вам нужно только один раз проиндексировать фактические данные - скажем, из списка от A до Z.

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

Наконец, как я уже упоминал в комментариях к другим ответам, пользователи вполне могут захотеть добавить в закладки конкретный поиск - запрос, вставленный в URL тем или иным способом (строки запроса или переписанный URL-адрес), является способом сравнения, позволяющим это .

* Я говорю «появляясь», потому что, как уже отмечали другие, перезапись URL позволила бы это, фактически не имея разных страниц на сервере.

1 голос
/ 26 февраля 2009

Есть несколько вопросов, которые необходимо решить, чтобы правильно ответить на ваш вопрос:

  1. Вы не обязательно должны перенаправлять на страницу результатов, прежде чем сможете обрабатывать данные. Страница или элемент управления, содержащий интерфейс поиска при отправке, может обрабатывать отправленные параметры поиска (и тип поиска) и инициировать вызов к базе данных или промежуточному веб-сервису, который предоставляет результат поиска. Затем вы можете использовать одну страницу результатов для отображения полученных данных.

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

  3. Большинство пользователей не используют информацию url / querystring в адресной строке браузера для определения своего текущего местоположения на веб-сайте. У вас должно быть что-то более наглядное (например, элемент управления Breadcrumbs или заголовки), чтобы указать текущее местоположение. Кроме того, как вы упомянули, проблема с ремонтопригодностью здесь весьма существенна.

Я бы определенно не рекомендовал второй вариант (используя отдельные страницы результатов для каждого вида поиска). Если вы беспокоитесь о SEO, используйте переписывание URL для создания «слагов» URL для создания более интуитивных путей.

0 голосов
/ 26 февраля 2009

Отбросьте строки запросов и используйте переписывание URL для обработки ваших "разделов" .. намного лучше, SEO и понятнее с точки зрения удобства чтения закладок / пользователей.

Город: www.example.com/city/delhi/

Метка: www.example.com/tag/delhi-hotels/

Последние: www.example.com/recent/

Популярные: www.example.com/popular/

Обычный поиск можно просто перейти на www.example.com/search.aspx или что-то еще.

0 голосов
/ 26 февраля 2009

Я бы придерживался оригинальной страницы результатов result.aspx. С моей точки зрения, это объясняется тем, что сам фактический URL-адрес сообщает мало информации. Вам было бы лучше создать визуальные подсказки на странице, в которой говорится что-то вроде «Поиск X в категории Y с тегами Z».

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

...