少走弯路！科学构建URL，事半功倍！

显然，很多网站都会看到这个建议，因为只需少量的假设，你在一家电子商务公司工作。

能够知道所有产品每周的自然搜索会话数和转化数是不是会大有裨益？

如果你有权访问任何一家电商公司的相关数据，请马上尝试在5分钟内生成一份这样的报告。

…

好了吗？

还是你发现这个简单的问题开始变得复杂起来？你是否陷入了一种无法自拔的情况？

要回答这个问题并没那么简单，这是一个每年要花费数千美元的问题。

每一个线上业务，无论是实体店还是电商网站，都可能会费尽心思来作出网站应该如何被看待、被感受和该如何构建的决策。

最大的决策通常是这样的：我们该如何构建我们的网站？而在这里面，会有数以百计的决定，例如我们的博客上应该包含哪些类别？

而每一个决策都将会影响着未来的成本和机会，以及塑造业务的运作方式。

包括URL结构也在这个过程中被敲定。我们希望它是合乎逻辑的，但创建的环境与它最终被使用的环境总是会不尽相同。

随着业务的增长，我们对信息量和优质分析的需求也在增长。我们花数千美元聘请数据分析师和支付代理去帮忙收集这些数据，并将其转换成有用的格式，以便做出明智的商业决策。

可惜太晚了。在一年里你已经浪费了1000英镑。

已经太晚了。截止目前，你已经为你的数据分析师创建了无数个小时的额外工作，数千美元将被浪费。

所有这些都是因为在构建URL时，没有人想到要收集数据。

让我们回到刚开始讨论的问题，但这次我会讲完整个故事。一家电子商务公司去了一个代理机构，要求他们收集在所有产品页面上的总自然搜索会话数。这家公司想要衡量过去一段时间的效果。

现在这家公司在做网站的时候非常用功。当他们设计网站时，他们会阅读Moz博客并聘请一家SEO机构，因此相信他们也会阅读到这条建议：产品需要构建在根目录上。（例如mysite.com/white-t-shirt。）

搜索，你就可以找到很多网站的产品页面是在根目录上的，例如英国一些出名的网站：Appleyard Flowers、Game和Tesco Direct。

在某个层面上它是有其意义的，那就是当一个产品可能会出现在多个类别的情况下（例如液晶显示器和42”电视），你可以以此避免重复的内容。此外，即使你更改了类别，也不需要重定向所有产品。

但从数据收集的角度来看，这是很可怕的。为什么？因为这样的话，谷歌分析就无法分辨出所有产品，除非我们有先见之明，譬如运用自定义维度或内容分组。没有任何东西能把产品URL与在根目录中的任何其他URL区分开来。

那么，数据分析师又是如何在这种情况下获得数据呢？

他们可能需要抓取网站上的所有页面，以便他们可以用HTML脚本（标识模板页面上的一段特定的HTML）来选出它们，或者从机构中拥有数据的人员获取内部列表。获得所有产品URL后，他们必须在Excel中将这些数据与谷歌分析的数据进行匹配，可能会用到VLOOKUP，或者如果数据集过大的话，还会用到数据库。

哎呀妈呀，这听起来就感觉花费不菲。

当然了，如果你想定期做这个分析，这个列表还会不断地变化。产品的销售范围也会改变。所以需要为此制定一个自动抓取的报告。如果选择自动抓取这个办法，我们是可以做到的，但要定期抓取的话，利用Screaming Frog也实现不了。现在要么我们定期花时间在Screaming Frog上，要么花钱购买一个可以自定安排时间的云抓取工具。另一种办法则是让开发人员创建一个自动化的内部报告，这样我们就能在内部实现所有页面的收集。

哇，这样算下来，真的很贵。要不花费几天的开发时间，要不就是你的SEO顾问或数据分析师需要每周重复地工作。

这本可以是只需几个点击就能在默认报告上获取到的信息。

如果我们有先见之明，把所有的产品都放在一个名为“/ products /”的文件夹中，这个漫长的过程就会被缩减为一个步骤：

在谷歌分析中加载着陆页报告，并筛选以“/ product /”开头的URL。

恭喜啊，你因此减少了几天的代理费用、节省了宝贵的开发时间，或者获得了解雇你的第二位数据分析师的理由，因为你的第一个数据分析师现在非常地高效！（Sorry啊，第二位数据分析师）。

而对于数据分析师或SEO顾问来说，如果不断地遇到这样的问题，不仅要额外花费大量时间，还让原本快速的任务变成了无穷无尽的琐事。

对于大多数数据分析服务来说，它是可以用来识别页面的主要信息。谷歌分析、谷歌站长工具、日志文件，大部分情况只能访问URL，在某些情况下，这些也是你所能访问到的，这一点你永远无法改变。

绝大多数的网站分析都需要使用模板，并在类似网页的分组之间进行归纳，且需要通过URL来使用模版。

这是至关重要的。

在此引用一段Jeff Bezos（亚马逊集团董事会主席兼CEO）的话：

“一般决策有两种类型。第一类是不可逆的，你必须非常小心地做出决定。第二类就像是走过一扇门，如果你不喜欢，你总是可以走回去。”

URL设置属于第一类的决策。正如SEO中的任何人都知道，你真的不希望经常更改URL; 这样会造成很多问题，所以当它们建立时，我们需要花时间思量。

你该如何选择一个好的URL模式？

首先，让我们定义一下好的模式。能够轻松选择一个URL模式，理想情况下是可以使用选取器，则可视为好的模式，而不是使用一些复杂的正则表达式。

这通常也意味着添加文件夹，因为最简单的方法是使用选取过滤器，即“/ products /”、“/ blogs /”等。

我们需要尽可能保持可读性，因此在选择文件夹时需要牢记这一点。

那么我们应该在URL哪里添加文件夹呢？

这里是两个我常会提出的问题：

• 我需要将这个模板中的页面一起分组吗？

Ø 如果一组页面需要分组，我需要把它们放在同一个文件夹中，这样我们就可以通过URL来识别。

• 这组页面是否存在重要的子分组？如果存在，它们是否相互独立的？它们会被改变的机会有多大？

Ø 如果存在我想要做的常见分组，那么我应该考虑把它放在URL中，除非那些分组数据是可以改变的。

我们来看几个例子。

让我们先回到产品示例：假设我们正在为一家时尚网店设置产品URL。

我需要把产品一起分组吗？是的，几乎可以肯定。显然我们需要在URL中进行分组，且应该把它们放在一个“/product/” 的文件夹中。

在这个模板中，我该如何给这些URL分组？最合理的产品分组是产品类别。让我们以“black midi dress”（黑色中长裙）为例。

如果把“little black dress”（小黑裙）或“midi”（中长裙）作为一个类别，这样是否合适呢？那我们首先需要思考下，它们是否相互独立？我们的服装既适合“小黑裙”类别也适合“中长裙”的类别，因此上述分类我们不应该添加到URL的文件夹。

如何更高级地使用“dress”（裙子）来作为一个类别？实际上可以更合理地把我们所有的产品分为：

• Dresses（连衣裙）
• Tops （上衣）
• Skirts （半身裙）
• Trousers （长裤）
• Jeans （牛仔裤）

如果我们觉得把牛仔裤和长裤分开分类是没问题的话，那么衡量每个顶级类别的效果就会变得轻松起来。这种分组似乎也不太可能改变，只要我们认为把这种类型的层次结构置于顶部（例如，非“按季节分类”这种类型）是没问题的话，就是合理的。

我们对此已有所了解，并列举了上面的例子。把你的产品粘贴在“/ products /”文件夹中。

用前面讨论过的相同规则应用到文章上，就会发现两件事情。首先是顶级的分类。

例如，添加以下文件夹可以让你轻松衡量到顶级文章的效果：

•  旅行
•  体育
•  新闻

当然，既然不按类别分组，你就应该把它们放在“/ blog /”或“/ guides /” 之类的文件夹里。

以下是所有三种情况的示例：

•  糟糕的博客文章URL：example.com/this-is-an-article-name/
•  普通的博客文章URL：example.com/blog/this-is-an-article-name/
•  优秀的博客文章URL：example.com/blog/sports/this-is-an-article-name

第二种，符合来我们所有的规则，属于按作者的分组，这种情况非常适合于有大量作者的编辑性站点，他们更倾向于这样的数据统计。

许多类型的网站通常在每个地理位置都有类别页面。例如：

•  Cars for sale in Manchester（在曼彻斯特出售的汽车）——“ /for-sale/vehicles/manchester/”
•  Cars for sale in Birmingham （在伯明翰出售的汽车）——“ /for-sale/vehicles/birmingham”

但是，不同级别的地理位置粒度有很多。例如，这里有4个不同的URL，每个URL都是比上面例子更具体的位置（非英国的读者非常抱歉，暂且跟着我思路走）。

•  Cars for sale in Suffolk（在萨福克出售的汽车）—— “/for-sale/vehicles/suffolk/”
•  Cars for sale in Ipswich（在伊普斯维奇出售的汽车）—— “/for-sale/vehicles/ipswich”
•  Cars for sale in Ipswich center（在伊普斯维奇中心出售的汽车）——“/for-sale/vehicles/ipswich-center”
•  Cars for sale on Lancaster road（在兰开斯特路上出售的汽车）——“/for-sale/vehicles/lancaster-road”

很显然，每个网站都会有不同级别的地理位置粒度，但是这里经常会丢失的一个分组，就是在URL中提供位置粒度的级别。例如：

•  Cars for sale in Suffolk（在萨福克出售的汽车）——“/for-sale/cars/county/suffolk”
•  Cars for sale in Ipswich （在伊普斯维奇出售的汽车）——“/for-sale/vehicles/town/ipswich”
•  Cars for sale in Ipswich center（在伊普斯维奇中心出售的汽车）——“for-sale/vehicles/area/ipswich-center”
•  Cars for sale on Lancaster road（在兰开斯特路出售的汽车）—— “/for-sale/vehicles/street/lancaster-road”

这甚至可能只是数字（尽管这不太理想，因为它违反了我们的第二条规则）：

•  Cars for sale in Suffolk（在萨福克出售的汽车）——“/for-sale/vehicles/04/suffolk”
•  Cars for sale in Ipswich（在伊普斯维奇出售的汽车）——“/for-sale/vehicles/03/ipswich”
•  Cars for sale in Ipswich center（在伊普斯维奇中心出售的汽车）——“/for-sale/vehicles/02/ipswich-center”
•  Cars for sale on Lancaster road（在兰开斯特路出售的汽车）——“/for-sale/vehicles/01/lancaster-road”

这种类型会使得评估和衡量每个层级的效果变得非常容易，因此你可以以此来决定是否有必要这样做，又或者先衡量你是否已经拥有太多的汇总数据。

最后，大家还遇到过什么优秀或反面的例子吗？欢迎留言讨论一下！