[url]大量重复的内容问题-更明显

因此，上个月，我在这里发表了一篇文章，标题为“您认为您有重复的内容问题吗？”在这里，我描述了史诗般的内容重复的噩梦。本质上，我找到了一个站点，该站点具有该站点上每个页面的数百个副本，并概述了我需要委托开发人员修复的步骤。

好吧，自那时以来，我做了一些进一步的挖掘，以提供实施的完整任务计划。并发现问题比我最初的评估还要严重。愚蠢的更糟。看来解决所有问题将是一场艰巨的战斗……

回到我第一次发现问题时，我估计应该只有大约15,000页，但发现站群正在显示86,000页。从那里，我发现站群正在索引一百万页，但是在他们内部自动显示“正确设置”的努力中，最终并没有做得那么出色。

当时，这意味着那15,000页并没有全部用完诱使他们真的当之无愧。

更多挖掘

我最初发现并发现的所有信息纯粹是基于中级审核工作。但是，当我需要用清晰，简洁，简明的英文文档来实际记录调查结果以提供给网站的开发人员时，我需要走得更远。我需要真正检查一下，并显示存在问题的链接的示例。

而且我需要制定解决方案-详细介绍SEO和信息体系结构最佳实践。因为当您告诉开发人员“您花费大量时间来构建该网站时，现在需要解决大量的问题”，因此最好做到周密。并且为情绪或心理上可能不愿意承认或认可自己在问题上的努力的人的退缩做好准备。

更多细节

您还记得这是一个房地产网站。在几个县设有几个办事处。遍布各地的代理商超过400个。事实证明，实际上有超过25,000座房屋在他们的系统中出售。该站点提供深入的导航-从县到城市，到邻域，最后到单个物业。

如果加上所有这些县，市和街区页面，再加上数百个特工页面，事实证明实际页面只有26,000多个。

哦，看！几个**问题

好的，在我的上一篇文章中，我解释了如何转到代理的个人主页，然后从那里单击该站点上的任何其他页面，所有URL都将附加该代理的ID。那就是大多数重复的来源。成千上万的属性页，每个属性页都被**，每个代理的唯一ID都附加在URL后面。

可是等等！还有更多！

在最后的撰写过程中，我扫描了在站群上被索引的重复页面。你猜怎么着？事实证明，每个县都有两个不同的URL，您可以使用它们访问该县页面。显然，该代码允许使用多个URL –一种是网站最初的构建方式。另一个是我他们上线后被修改为可以工作。

除非没有人意识到您必须执行301重定向。

觉得不好吗？每个县的每个城市都存在类似的问题。是的，每个城市的每个街区。

超过130个页面都具有两个可以使用的URL（并且两个版本中的许多都在站群中建立了索引，非常感谢）。

可是等等！还有更多！

你猜怎么着？当我进入站群网站站长工具时，是否有任何可以揭示此问题的信息？是的，从五月份开始，我发现列出了100,000个404错误！

现在，我通常不必过多担心404错误。大多数大型网站一定会有一些。当然，最好的方法是在它们长大后解决所有问题。但是，在大多数情况下，如果数量很少，那么有时这是一项低优先级的任务。

除非它如此庞大。

尤其是当其中大多数链接指向它们时。

如何以100,000 404错误结束。在一个月内。

变成你所有这404个错误都有三个主要原因。首先，当该网站于去年首次重新设计和重建时，最初存在URL结构问题。回想一下我之前提到的县/镇/街区系统中重复内容问题是如何产生的？

在县/镇系统中，这些第1版URL仍然有效。

但是，它们无法在网站的其他部分工作。这些部分采用了一种新的URL结构，从而使它们的第一代URL陷入了僵局。 404.找不到

除非这仅适用于其中的少数几个。

再有一个事实是，旧站点（在此重建之前已存在的站点）具有某种站点级别的****链接方案。不要问我如何或为什么。我所知道的是，有数百个URL有时以某种方式进入了站群索引，这些URL指向该站点上的****文件夹。在该****文件夹中，存在指向属性页的各种链接。怪异的至少可以说。

但是，真正大量的404计数来自于现已停用的网站上的旧属性URL结构。无论出于何种原因，在构建新站点时，没有人想到–“嘿–我们正在废弃这个旧站点。因此，也许我们应该301重定向所有这些属性页”。

甚至在重建该站点之前，没有人回想起旧站点“嘿-随着物业被出售，也许我们应该为每个站点设置一个自动301”。

在通道3上清理

因此，您可以冒险猜到，这个特定站点上的问题比我上个月第一次写这篇文章时最初想到的更加混乱，纠结和痛苦。

本质上，整个网站的URL结构都需要清理。这对我来说很棒。因为在我的任务文件中，我不仅传达了所有需要消除/重复的城镇/城市/街区页面，还包括了301'。我走得更远。并说“扔掉两个版本”。并用THIS替换它们语法。

没错-我追求了-真正精致，用户友好和SEO友好的URL结构。

因为我是一个好人。