Управление перенаправлениями URL-адресов при изменении красивых URL-адресов - Рекомендации - PullRequest
Новая
       5

Управление перенаправлениями URL-адресов при изменении красивых URL-адресов - Рекомендации

1 голос
/ 16 декабря 2009

Каковы стандарты для управления URL-перенаправлениями, если вы основываете на своем URL-адресах свойства данных, которые могут изменяться несколько раз, например, «заголовок»?

У меня есть веб-сайт с большим количеством изображений, и я хочу, чтобы URL выглядели так:

<a href="http://www.mySite.com/images/132123/my-cool-image-title" rel="nofollow noreferrer">http://www.mySite.com/images/132123/my-cool-image-title</a>

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

<a href="http://www.mySite.com/images/132123/renamed-image-title" rel="nofollow noreferrer">http://www.mySite.com/images/132123/renamed-image-title</a>

Так что теперь нужно сделать переадресацию для людей, которые добавили в закладки старый ... Теперь допустим, что это происходит в среднем 3 раза на изображение. Это означает, что у меня будет много перенаправлений на карту. Кажется, у меня была бы база данных перенаправлений.

Какова лучшая практика в этом случае, если я хочу использовать красивые URL-адреса, а не основывать их на каком-то универсально уникальном идентификаторе, и что я хотел бы получить как можно больше преимуществ SEO?

Ответы [ 2 ]

1 голос
/ 17 декабря 2009

проголосуй за меня, если ты считаешь мой ответ глупым. Мне все равно.

Не уверен, что вы используете тот же подход, что и StacOverflow, если вы это сделаете, то слаг, в вашем случае my-cool-image-title и renamed-image-title не будет иметь большого значения, если вы сохраните идентификатор 132123 одинаковым , Так что вам нужно беспокоиться о перенаправлении вещей. Тем не менее, с точки зрения пользователей социальных закладок, я думаю, что изменение слаг может привести к путанице, но это не проблема перенаправления.

Я не прав?

1 голос
/ 16 декабря 2009

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

Я бы порекомендовал, чтобы, если вы заранее знали, что будет изменять данные, их, вероятно, не должно быть в URL-адресе. Если это требование (возможно, это важно для SEO, или вы создаете блог или что-то еще, у вас есть несколько вариантов:

  1. Забудьте старый URL и используйте только новый. Наверное, не очень хороший способ подружиться;)
  2. Сохраните старый URL и примите тот факт, что заголовок и URL не совпадают. Это может быть достигнуто с помощью каждого сообщения, имеющего поле slug, в котором хранится текст URL, отдельно от фактического заголовка сообщения.
  3. Сохраните старый URL и добавьте новые. Способ сделать это может состоять в том, чтобы иметь отдельную таблицу, которая отображает слагов на посты, каждый пост имеет один или несколько слагов. Таким образом, выполняется любое количество изменений.

Если требуются возможные изменения и обратная совместимость, я бы выбрал что-то вроде варианта 3. Конечно, лучше встроить его в ваше приложение, чем управлять растущими файлами .htaccess или правилами перезаписи URL или чем-то еще.

...