包含数字的搜索引擎友好 URL...好还是坏?

发布于 2024-08-21 18:02:48 字数 1038 浏览 1 评论 0原文

我制作了一个具有分层结构的网站,并具有搜索引擎友好 (SEF) URL,例如:

/seeds-1/
/seeds-1/fruits-2/
/seeds-1/fruits-2/black-berries-5/
/seeds-1/fruits-2/blue-berries-6/
/seeds-1/fruits-2/strawberries-7/
/seeds-1/vegetables-3/
/seeds-1/vegetables-3/potato-8/
/seeds-1/vegetables-3/onion-9/
/seeds-1/vegetables-3/cabbage-10/
/seeds-1/flowers-4/
/seeds-1/flowers-4/red-rose-11/
/seeds-1/flowers-4/tulips-12/

等等。您会注意到末尾的数字是 ID。现在我已经完成了网站和所有事情,一位“顾问”介入并告诉我的客户“...网址对搜索引擎不100%友好,以使它们100%< /strong> 搜索引擎友好,必须删除这些数字......”。我显然无法与“顾问”交谈,因为他们已经完成了他们的工作并消失了。

如果有人能指出这两种类型的 URL 的优点和缺点,我将不胜感激。我需要一些可靠的论据来说服客户,而且我真的需要知道为我的网站选择这种 URL 方案是否犯了错误。

编辑----

可能是我太懒了。重写规则如下所示:

RewriteRule ^[^/]+-([0-9]+)/$ object.php?ObjectID=$1
RewriteRule ^[^/]+-([0-9]+)/[^/]+-([0-9]+)/$ object.php?ObjectID=$2
.
.
.

从查询字符串中提取 ObjectID、将其转换为整数并在 SQL 查询中使用它相当容易。我认为在查询中使用文本比较(WHERE Name = '%s')比使用整数比较(WHERE ObjectID = %d)慢,因此我在犹豫。问题更像是是否值得以降低编码/性能友好性为代价,使 URL 更加人性化。

I made a website that has a hierarchical structure and has search engine friendly (SEF) URLs like:

/seeds-1/
/seeds-1/fruits-2/
/seeds-1/fruits-2/black-berries-5/
/seeds-1/fruits-2/blue-berries-6/
/seeds-1/fruits-2/strawberries-7/
/seeds-1/vegetables-3/
/seeds-1/vegetables-3/potato-8/
/seeds-1/vegetables-3/onion-9/
/seeds-1/vegetables-3/cabbage-10/
/seeds-1/flowers-4/
/seeds-1/flowers-4/red-rose-11/
/seeds-1/flowers-4/tulips-12/

and so on. You'll notice that the numbers at the end are IDs. Now that I am done with the website and everything, a "consultant" intervenes and tells my client that "... urls are not 100% search engine friendly, to make them 100% search engine friendly, the numbers must be removed...". I obviously cannot talk to the "consultant" as they have done their job and disappeared.

I'll now appreciate if someone can point out the PROs and CONs for both types of URLs. I need some solid arguments to convince the client plus I really need to know if I've made a mistake choosing this kind of URL scheme for my website.

Edit ----

May be I am being lazy. The rewrite rules look like:

RewriteRule ^[^/]+-([0-9]+)/$ object.php?ObjectID=$1
RewriteRule ^[^/]+-([0-9]+)/[^/]+-([0-9]+)/$ object.php?ObjectID=$2
.
.
.

Its fairly easy to extract the ObjectID from query-string, cast it as an integer and use it in SQL query. I think using text comparison in queries (WHERE Name = '%s') is slower compared to using integer comparison (WHERE ObjectID = %d), therefore I am hesitating. The question is more like is it worth making the URLs more human-friendly at the cost of making them less coding/performance friendly.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

木森分化 2024-08-28 18:02:48

同意 cherouvim 并将扩展。

这里需要考虑两件事 -

人类友好是一点......如果您的用户想要输入蔬菜/洋葱/vidalia 而不是蔬菜/洋葱-10,那么它显然对最终用户更有意义。

此外,搜索引擎还可以获取更多详细信息...因此,搜索 vidalia onion 可能会为您的网站带来更好的排名。

最后,顾问正在推广可读性这个流行词。是的,从长远来看,它可能总体上更好(并且应该像编写一个漂亮的小 .htaccess 文件来修复一样简单),但您的设置确实没有任何问题。

编辑

老实说,这实际上取决于您的客户想要什么。正如其他用户也指出的那样,呈现链接的方式实际上并没有太大的性能差异......

现在真正重要的是您的客户是否希望呈现它。他们关心这类信息是否可以被人类读取吗?如果他们只是接受顾问的建议,那么您不妨实施您的重写规则。

Agree with cherouvim and will expand.

Two things to consider here -

Human friendly is one point...if your user wants to type in vegetables/onions/vidalia instead of vegatables/onions-10, then it obviously makes more sense to the end user.

Also, the search engine could also pick up on a little more detail as well...so a search for vidalia onion may yield a better ranking for your website.

In the end, the consultant is promoting the buzzword of readability. Yes its probably overall better in the long run (and should be as simple as writing a nice little .htaccess file to fix), but there's really nothing wrong with your setup.

Edit

Honestly, it really boils down to what your customer wants. As other users have also specified, there really isn't much of a performance difference in how you present the links...

What really matters now is if your client wants it presented. Do they care if this sort of information is readable by humans? If they're just going to take the consultant's advice then you might as well just implement your rewrite rules.

南巷近海 2024-08-28 18:02:48

搜索“种子”、“花”、“蔬菜”等将在 URL 上匹配,因此 URL 很好,引擎会很好地处理它们。

是否想让它们变得更加人类友好是另一个问题。

Searches for "seeds", "flowers", "vegetables" etc will match on the URL, so the URLs are good and engines will handle them nicely.

Whether you want to make them more human friendly is another issue.

枕花眠 2024-08-28 18:02:48

从技术角度来看,如果关键字在其上下文中不唯一,则只需要数字 ID。

例如,如果第一级中可以有多个种子,就会出现这种情况。然后,您需要数字 ID(或另一个唯一值)来区分不同的种子

/seeds-1/…
/seeds-2/…
 ⋮

但是,如果所有关键字在其上下文中都是唯一的(路径是唯一的),那么您可以删除数字 ID不会丢失任何信息。

From the technical point of view, you would only need the numerical IDs if the keywords are not unique in their contexts.

That is the case if, for example, there can be more than one seeds in the first level. Then you would need the numerical ID (or another unique value) to distinguish between the different seeds:

/seeds-1/…
/seeds-2/…
 ⋮

But if all keywords are unique in their contexts (the paths are unique), then you can remove the numerical ID without any loss of information.

冰葑 2024-08-28 18:02:48

URL 中包含 ID 没有任何问题。到处都是这样做的。例如:

  1. 这里在 Stack Overflow (/questions/2264708/search-...) 或
  2. Amazon (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/ 0735619670/)

这只是两个例子,还有更多。将 ID 嵌入到 URL 中几乎是普遍现象,特别是对于大型站点或大型数据集,在这些站点或大型数据集上对 slugs 进行字符串比较的成本很高。

它根本不会损害SEO。它可能对用户不太友好,因为用户无法“猜测”URL,但这完全是一个不同的问题。

There's nothing wrong having ID's in the URL. It's done all over the place. For example:

  1. Here on Stack Overflow (/questions/2264708/search-...) or
  2. Amazon (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/)

Are just two examples and there are more. Embedding ID's into the URL is almost ubiquitous, especially for large sites or large datasets where doing string comparisons on slugs are costly.

It will not hurt SEO at all. It might be a little less user friendly because users can't "guess" URL's, but that is a different problem altogether.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文