Стоит ли использовать «красивые URL», если вы не заботитесь о SEO / SEM - PullRequest
Новая
       17

Стоит ли использовать «красивые URL», если вы не заботитесь о SEO / SEM

4 голосов
/ 26 октября 2009

Я разрабатываю размещенное приложение «программное обеспечение как услуга», которое похоже на узкоспециализированную версию продукта Highrise от 37Signal. В этом контексте, где SEO не является проблемой, стоит ли реализовывать «красивые URL» вместо того, чтобы идти с числовыми идентификаторами (например, customers/john-smith вместо customers/1234)? Я заметил, что многие веб-приложения не беспокоятся о них, если они не предоставляют реальную ценность (например, приложения для электронной коммерции, блоги - вещи, которые нуждаются в поиске SEO с помощью поисковых систем)

Ответы [ 7 ]

20 голосов
/ 26 октября 2009

Зависит от того, как часто URL передаются пользователями в устной форме. Людям, как правило, трудно произносить что-то вроде 

http://www.domain.com/?id=4535&f=234&r=s%39fu__

и т.п. 

http://www.domain.com/john-doe

намного лучше;)

8 голосов
/ 26 октября 2009

В дополнение к удобочитаемости следует помнить, что, предоставляя автоматически увеличивающийся цифровой ключ, вы также позволяете кому-то угадывать URL-адреса для других ресурсов и можете выдавать определенные сведения о ваших данных. Например, если кто-то зарегистрирует ваше приложение и увидит, что его учетная запись имеет номер /customer/12, это может повлиять на его уверенность в вашем приложении, зная, что у вас есть только 11 других клиентов. Это не было бы проблемой, если бы у них был URL /customer/some-company.

7 голосов
/ 26 октября 2009

Это всегда стоит, если у вас просто есть время, чтобы сделать это правильно.

  • Дружественные URL выглядят намного лучше, и они дают лучшее представление о том, куда приведет ссылка. Это полезно, если ссылка является общей, например. через мгновенное сообщение.
  • Если вы ищете определенную страницу из истории браузера, вам поможет читабельный URL.
  • Дружественный URL намного легче запомнить (полезно в некоторых случаях).
  • Как уже говорилось ранее, устно общаться намного проще (нужно чаще, чем вы думаете).
  • Скрывает ненужные технические детали от пользователя. В одном случае, когда идентификатор пользователя был виден в URL, несколько пользователей спросили, почему их идентификатор превышает общее количество пользователей. Ущерб не причинен, но зачем путать пользователя, если вы можете избежать этого.
2 голосов
/ 26 октября 2009

Я уверен, что при наведении мыши на нее гораздо больше шансов щелкнуть ссылку, и она имеет http://www.example.com/something-i-am-interested-in.html.

Вместо того, чтобы видеть http://www.example.com/23847ozjo8uflidsa.asp.

Довольно раздражает переход по ссылкам на MSDN, потому что я никогда не знаю, чего ожидать.

1 голос
/ 26 октября 2009

Когда я создаю приложения, я стараюсь изо всех сил скрывать его структуру от посторонних глаз - хотя она субъективна в отношении того, сколько «SEO» вы получаете от этого - красивые URL-адреса, как правило, помогают людям ориентироваться и понимать, где они находятся, защищая ваш код от возможных уколов.

Я заметил, что вы используете приложение Rails - поэтому у вас, вероятно, не будет огромной строки запроса, как в ASP, PHP или других языках, - но, на мой взгляд, дополнительная чистота и общий внешний вид являются плюсом для взаимодействия с клиентами , Когда пользователи делятся ссылками, лучше копировать URL: customer / john_doe, чем искать «link me» или случайного / customer /

.

Marco

0 голосов
/ 27 октября 2009

Если ваше приложение успокаивается, то URL-адреса, которые выдает rails, по умолчанию оптимизированы для SEO.

В вашем примере customers/1234, вероятно, вернет что-то вроде 

<h1>Customer</h1>
<p><strong>Name:</strong> John Smith</p>
etc etc

Любой текущий SEO-паук будет достаточно умен, чтобы разобрать целевую страницу и все равно извлечь из нее «Джона Смита».

Таким образом, в этом смысле, customers/1234 уже является «хорошим» URL-адресом (в отличие от других систем, в которых у вас будет что-то вроде resource/123123/1234 для клиента 1234 resource/23232/321 для клиента 321).

Теперь, если вы хотите, чтобы ваши пользователи регулярно использовали URL-адреса (как, например, в восхитительных и т. Д.), Вы можете начать использовать логины и читаемые поля вместо идентификаторов.

Но для SEO, идентификаторы просто отлично.

0 голосов
/ 26 октября 2009

Обычно я использую комбинацию - сохраняя простоту использования RESTful-маршрутизации Rails, при этом предоставляя некоторую расширенную информацию в URL-адресах.

URL моего приложения выглядят примерно так: http://example.com/discussions/123-is-it-worth-using-pretty-urls/ http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments/34567

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

def to_param
  [ id, permalink ].join("-")
end

И убедитесь, что любые параметры вызова find [: id] в вашем контроллере преобразуются в целое число путем установки параметров [: id] .to_i.

Просто заметка, вам нужно установить постоянный атрибут при сохранении вашей записи ...

...