修改漂亮 URL 时管理 URL 重定向 - 最佳实践
如果您的 URL 的属性基于可能会更改几次的数据（例如“标题”），那么管理 URL 重定向的标准是什么？
我有一个包含大量图像的网站，我想让网址看起来像这样：
http://www.mySite.com/images/132123/my-cool-image-title
现在假设一群人为该图像添加了书签，一周后我将其更改为：
http://www.mySite.com/images /132123/renamed-image-title
所以现在必须为那些为旧书签添加书签的人进行重定向...现在假设每个图像平均发生 3 次。这意味着我会有很多很多的地图重定向。我似乎有一个重定向数据库。
在这种情况下，假设我想使用漂亮的网址而不是将其基于某些普遍唯一的 ID，并且我希望获得尽可能多的 SEO 好处，那么最佳实践是什么？
What are the standards for managing URL redirects if you base your URL's off properties of the data that might change a few times, like the "title"?
I have a website with lots of images and I want to make the urls look like this:
http://www.mySite.com/images/132123/my-cool-image-title
Now say a bunch of people bookmark the image, and a week later I change it to:
http://www.mySite.com/images/132123/renamed-image-title
So now there has to be a redirect for the people that bookmarked the old one... Now lets say that happens on average 3 times per image. That means I'd have lots and lots of redirects to map. I'd have a database of redirects it seems.
What is best practice in this case, assuming I want to use pretty urls and not base it on some universally unique id, and that I'd like to reap as many benefits of SEO as possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我不知道反对票是关于什么的，这对我来说似乎是一个完全有效的问题。
我的建议是，如果您事先知道您将要更改数据，那么它可能一开始就不应该出现在 URL 中。如果这是一个要求（也许它对 SEO 很重要，或者您正在创建博客或其他东西，您有一些选择：
slug字段来实现，其中存储 URL 文本，与帖子的实际标题分开。如果需要可能的更改和向后兼容性，我会选择类似选项 3 的选项。将其内置到您的应用程序中肯定比必须管理不断增长的 .htaccess 文件或 URL 重写规则或其他内容更好。
Well I don't know what the downvote was about, this seems like a perfectly valid question to me.
My recommendation would be that if you know in advance you will be changing the data, it probably shouldn't be in the URL in the first place. If this is a requirement (perhaps its important for SEO or you are creating a blog or something, you have some choices:
slugfield where the URL text is stored, separate to the post's actual title.If possible changes and backwards compatibility are a requirement, I'd go with something like option 3. Its certainly better to have it built in to your app than have to manage growing .htaccess files full or URL rewrite rules or something.
如果您认为我的回答很愚蠢，请投票给我。我不太关心它。
不确定您是否使用与 StacOverflow 相同的方法，如果您这样做，那么 slug，在您的情况下
my-cool-image-title和renamed-image-title会这样做只要保持 ID132123相同，就不会产生太大差异。所以你需要担心你的重定向问题。话虽如此，从社交书签用户的角度来看，我认为更改 slug 可能会造成混乱，但这不是重定向问题。我错了吗？
vote me down if you think my answer is stupid. I do not care it so much.
Not sure if your are using the same approach as StacOverflow, if you do then the slug, in your case
my-cool-image-titleandrenamed-image-titledo not make a big difference as long as you keep the ID132123the same. So you need to to worry about your redirect stuff. That being said, in the perspective of social Bookmark users, I think changing slug may cause confusing, but it is not a redirect issue.Am I wrong?