slug是描述或标题页面的URL的一部分,并且通常是关键字丰富的页面改进SEO.例如,在这个URL中PHP/JS - 动态创建缩略图或存储为最后一节"php-js-create-thumbnails-on-the-fly-or-store-as-files"的文件是slug.
目前,我正在为每个页面存储slug,并在DB中记录页面的记录.当页面生成并与页面一起存储时,从标题字段生成slug.但是,我正在考虑动态生成slug,以防我想要改变它.我正在努力找出哪个更好,哪些更好.
到目前为止,我已经为每个人提出了这些专业要点:
Store slug: - "Faster"处理器每次都不需要生成它(生成一次)
生成即时: - 灵活(可以调整slug算法,不需要为整个表重新生成). - 在数据库中占用更少的空间 - 从数据库传输到应用程序的数据更少
还有什么我错过了,你会怎么做？
编辑:
我想澄清一下在答案中看起来像是一种误解.slu to对登陆正确页面没有影响.要理解这一点,只需切断或破坏本网站上任何部分的slu .. 例如:
都将带你到同一页.slu from永远不会被编入索引.
你不需要保存旧的slu .. 如果你登陆了一个有"旧slu"的页面,那么你可以检测到这一点,然后只需301重定向到正确的"slu"".在上面的例子中,如果Stack Overflow实现了它,那么当你登陆任何带有截断slug的链接时,它会将url中的slug与当前slug算法生成的slug进行比较,如果不同,它会执行301重定向到同一页面,但使用新的slug.
请记住,所有内部生成的链接将立即使用新算法,并且只有来自外部指向的链接才会使用旧的slug.
不会改变现有页面的slu is是一个非常糟糕的主意吗？它会打破你所有的inlinks开始.
编辑,跟随盖伊在问题中的澄清:你仍然需要考虑旧的slu .. 例如:如果您更改了slug算法,Google可能会开始看到每个页面的多个版本,并且您可能会遭受重复的内容损失,或者最多在同一页面的多个版本之间共享PR和SERP.为了避免这种情况,你需要一个规范版本的页面,任何非规范的slug重定向到 - 因此你无论如何都需要数据库中的规范slug.
对于 slug 生成，我认为生成时间不应该是一个问题，除非你的 slug 算法非常复杂！同样，存储空间也不会成为问题。
我会将 slug 存储在数据库中，原因很简单，slug 通常构成永久链接的一部分，一旦永久链接出现在野外，它应该被认为是不可变的。能够更改已发布数据的数据块似乎是一个坏主意。
您可能需要考虑另一件事，如果您希望用户/自己能够定义自己的子弹，该怎么办。也许算法并不总是足够的。
如果是这样，您或多或少需要将其存储在数据库中。
如果不是，我认为这没什么大不了的，您可以即时生成它们，但是如果不确定是否要更改它们，或者不让它们进入数据库。在我看来，这两种方法都没有真正的性能问题（除非实时生成非常缓慢或类似的情况）。
选择最灵活的一种。
| 归档时间： |
|
| 查看次数： |
3839 次 |
| 最近记录： |