Управление описательными URL

Question

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

http://www.hanselman.com/blog/VirtualCamaraderieAPersistentVideoPortalForTheRemoteWorker.aspx

Я предполагаю, что это сделано для поисковой оптимизации.

Как эточитать из базовой модели данных? Вы действительно ищете

VirtualCamaraderieAPersistentVideoPortalForTheRemoteWorker

в базе данных?

Если да, то как управляется описание? Если это ключ, является ли правило, что его нельзя изменить после создания, не нарушая веб-ссылки?

Answer 1

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

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

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

Если вы хотите быть сверхнадежным в своем приложении, вы можете автоматически сохранять историю слагов и генерировать заголовки «301 Moveed Permanently» всякий раз, когда слаг будет изменен.

Answer 2

Обычно при создании статьи эта строка сохраняется в базе данных в качестве ключа, да. Некоторые движки блогов, такие как Wordpress, позволяют вам (автору) вручную изменять, что это за строка, и после того, как вы это сделаете, ссылки на старую строку больше не будут работать.

В Wordpress они называют это «постоянная ссылка»", хотя разные движки имеют свои собственные названия для этого. Я не думаю, что есть универсальный термин для этого.

Answer 3

Нет причин, по которым VirtualCamaraderieAPersistentVideoPortalForTheRemoteWorker не может быть ключом в таблице «записей», учитывая, что даже у действительно большого блога не будет больше, чем, скажем, паратысяч строк в таблице записей.

Если вы решили переписать его, то можете создать редирект 301 для этого URL без большого ущерба для SEO.

Но, какВ комментариях к вашему вопросу я обсуждал, что отношение статических URL, подобных этому, к SEO больше не имеет значения . Реальное преимущество для пользователя заключается в том, что у него есть структура, с которой визуально легче ориентироваться («взломанные» ссылки).

Google не будет заботиться, если в URL будет указано:

hanselman.com/blog/index.aspx?id=123

или

hanselman.com/blog/foobar.aspx

Рейтинг будет одинаковым, независимо от того.

Answer 4

Существуют различные стратегии для дружественных поисковых систем URL. Учитывая ваш пример URL, вы можете, например, выполнить поиск по всей строке или использовать хеш-значение C # в качестве (возможно, неуникального) ключа. В любом случае ссылки на эту страницу будут прерываться, если заголовок будет изменен. Одним из решений является встраивание дополнительного уникального ключа в URL (примеры см. На amazon.com).

Если вам интересно, как dasBlog обрабатывает URL-адреса, вы можете получить полный исходный код по адресу http://www.dasblog.info/.

Answer 5

Ознакомьтесь с динамическими URL-адресами и Apache mod_rewrite.

Также проверьте этот mod_rewrite генератор правил .

В качестве примера того, что mod_rewrite может сделать для вас, насколько это возможнов качестве описательных URL-адресов постоянную ссылку можно рассматривать как URL:

 http://www.somesite.com/catalog.php?cat=widgets&product_id=1234

, а модуль перезаписи создаст гораздо более описательный и более простой:

 http://www.somesite.com/catalog/widgets-1234.html 

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

 RewriteEngine On
 RewriteBase /
 RewriteCond %{QUERY_STRING} ^cat\=([^&]+)\&product_id\=([^&]+)$
 RewriteRule ^$ /catalog/%1-%2.html [R=301,

Этот пример был найден здесь .

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

Похоже, что SEO-энтузиастам настоятельно рекомендуется создать google sitemap.xml, чтобы помочь Google проиндексировать их (возможно бесконечный, или до верхней границы длины URL, которая не определена, но> 2000 символов URL не будет работать во многих браузерах) статически сгенерированные страницы. Пока правила являются детерминированными, они также могут быть постоянными.