最终的重新爬网分析：实施大规模SEO更改后的强大而重要的最后一步

当帮助公司应对由于主要算法更新，网站重新设计，CMS迁移以及SEO力量受到的其他干扰而导致的性能下降时，我发现自己爬了很多URL。 在客户参与期间，这通常包括许多爬网。 对于大型站点，在分析爬网数据时出现很多问题的情况并不少见，从技术SEO问题到内容质量问题再到用户参与障碍。

在解决了这些问题之后，制定补救计划以解决这些问题，纠正问题并提高网站的整体质量非常重要。 如果不是这样，则站点可能无法从算法更新命中中恢复，它可能处于质量的灰**域，技术问题可能会恶化。

正如Google的John Mueller多次解释如何从质量更新中进行恢复一样，Google希望看到质量的长期改善。 因此，基本上，请解决所有问题-然后您可能会看到积极的进展。

爬行：企业与手术

深入研究站点时，通常通常首先要了解该站点的整体情况，其中包括企业爬网（较大的爬网，该爬网覆盖了足够多的站点，可让您获得大量的SEO智能）。 这并不意味着爬行整个站点。 例如，如果一个站点索引了100万个页面，则可能从抓取200-300K页面开始。

这是我执行的一些初始企业爬网，范围从250K到440K URL。

根据初始爬网，然后可以启动针对站点特定区域的多个外科爬网。 例如，注意到网站的X部分中有很多瘦内容吗？ 然后将下一个爬网集中在该部分上。 您可能仅在该区域中爬网25-50K URL或更多，以更好地了解那里发生的事情。

说完一切之后，您可能会在参与过程中启动许多外科手术，以将注意力集中在这些特定领域的问题上。 例如，这是一个较小的，仅用10K URL进行的外科手术爬网（针对网站的特定区域）。

所有爬网都可以帮助您在站点上尽可能多地发现问题。 然后由您和您的客户团队（营销人员，项目经理，设计师和开发人员的组合）实施需要完成的更改。

下一步：审核阶段-很棒，但不是最后一英里

在帮助客户时，我通常可以访问暂存环境，因此我可以在更改到达生产现场之前对其进行检查。 这是解决棘手问题的好方法。 不幸的是，有时错误地实施更改可能导致更多问题。 例如，如果开发人员误解了某个主题并实施了错误的更改，那么最终可能会遇到比开始时更多的问题。

您绝对希望确保所有实施的更改都是正确的，否则最终状态可能会比审核之前更糟。 爬网暂不公开时，爬网的一种方法是拥有VPN访问权限。 我在上一篇文章中介绍了有关如何在将更改推送到生产环境之前对过渡服务器进行爬网的内容。

但是，这是摩擦。 我们现在谈论的是暂存环境，而不是生产环境。 有时候，变更会从阶段转移到生产中，并且出现问题。 可能是指令被破坏，代码故障破坏了元数据，网站设计也受到影响，这也影响了可用性，移动URL受到了负面影响，依此类推。

因此，您绝对希望检查登台中的更改，但是绝对要在生产中将这些更改再次检查。 在更改上线并发现问题之后，我无法告诉您检查生产现场多少次。 有时它们很小，但有时却不那么小。 但是，如果您在它们首次推出时就抓住了它们，则可以在这些问题造成长期损害之前对其进行消除。

之所以提出所有这些要求，是因为检查整个生产过程中的变更至关重要，然后一旦变更影响生产，就必须检查变更。 这包括对更改生效的站点（或部分）进行重新爬网。 让我们更多地讨论爬网。

抓取分析并比较更改

现在，您可能会说Glenn在这里谈论很多工作……恩，是，不是。 幸运的是，一些顶级的爬网工具使您可以比较爬网。 这样可以帮助您节省大量时间进行抓取分析。

我之前多次提到我最喜欢的两种爬网工具，它们是DeepCrawl和Screaming Frog。 （免责声明：我在DeepCrawl的客户顾问委员会中工作了很多年。）两者都是出色的爬网工具，可提供大量功能和报告。 我经常说，当同时使用DeepCrawl和Screaming Frog来审核站点时，为1 + 1 = 3。 DeepCrawl在企业爬网方面功能强大，而Screaming Frog在外科爬网方面非常出色。

图片来源：GIPHY

DeepCrawl和Screaming Frog很棒，但是街上有个新孩子，他的名字叫Sitebulb。 我刚刚开始使用Sitebulb，正在研究中。 我一定会看看Sitebulb并尝试一下。 它只是可以补充DeepCrawl和Screaming Frog的另一个工具。

比较每种工具的变化

当您通过DeepCrawl重新抓取网站时，它会自动跟踪上次抓取和当前抓取之间的更改（同时提供所有抓取的趋势）。 这对于比较以前爬网中出现的问题有很大帮助。 您还将看到随着时间推移每个问题的趋势（如果您执行的爬网次数不止两次）。

Screaming Frog本身不提供比较功能，但是您可以将问题从工具导出到Excel。 然后，您可以比较报告以检查更改。 例如，404是否从15K降为3K？ 标题过长是否从45K下降到10K？ 没有索引的页面是否从0准确地增加到125K？ （依此类推。）您可以轻松地在Excel中创建自己的图表。

现在来了一个叫Sitebulb的年轻朋克。 您会很高兴地知道Sitebulb提供了本机比较爬网的功能。 您可以单击任何报告，并检查一段时间内的变化。 Sitebulb跟踪项目的所有爬网，并报告每个类别随时间的变化。 太棒了

如您所见，正确的工具可以在爬网和重新爬网时提高效率。 在问题浮出水面，创建补救计划，实施更改，在阶段检查更改，然后将更新推送到生产中之后，最终的重新爬网至关重要。

能够在爬网之间比较更改的能力可以帮助您识别未正确完成的更改或需要进一步完善的更改。 对于Screaming Frog，您可以导出到Excel并进行手动比较。

现在，我们来谈谈在重新爬网分析中可以找到的内容。

从生产中撤出：在重新爬网分析中可以找到的真实示例

将变更推入生产后，您将完全了解SEO。 毫无疑问，Googlebot很快就会开始抓取这些更改（无论好坏）。

引用阿甘（Forrest Gump）的话：“生活就像一盒巧克力，你永远都不知道会得到什么。” 好吧，完全爬网是相同的方法。 当更改生效时，有很多潜在的问题可以注入到站点中（尤其是在复杂的大型站点上）。 您可能会惊讶于发现的东西。

下面，我列出了多年来在为客户提供帮助的同时对各种生产进行重新爬坡时遇到的实际问题。 这些子弹不是虚构的。 实际上，它们确实发生了，并且被意外推入了生产环境（CMS导致了问题，开发团队偶然地推了些东西，出现了代码故障等等）。

墨菲定律-任何可能出错的想法都会出错-在SEO中是真实存在的，这就是为什么在所有更改生效后检查至关重要的原因。

请记住，目标是解决问题，而不是添加新问题。 幸运的是，我迅速发现了问题，将其发送给每个开发团队，并将其从方程式中删除。

• 实时发布更改后，规范人员被完全从站点中剥离（该站点已索引150万页）。
• CMS在网站的多个部分中错误地发布了使用noindex的meta robots标签。 这些额外的部分吸引了大量的自然搜索流量。
• 另一方面，为了改善网站上的移动URL，数千空白或几乎空白的页面被发布到该站点（但只能由移动设备访问）。 因此，注入了少量的内容，这是肉眼看不到的。
• 发布了错误的robots.txt文件，并且正在爬网数千个不应爬网的URL。
• 站点地图已损坏，无**确更新。 其中包括Google新闻站点地图。 Google新闻吸引了该网站的大量访问量。
• Hreflang标签被意外剥离。 并且有65,000个URL，其中包含hreflang标签，每个群集针对多个国家/地区。
• 代码故障将广告数量增加了一倍。 因此，如果您有一个烦人的广告占用了大量空间，则该站点现在有两个。 用户必须进行大量滚动才能获得主要内容（从算法角度，可用性角度或从Chrome操作角度来看，效果不佳）。
• 多年来一直未关注的链接再次突然被关注。
• 导航更改实际上是冻结站点上的菜单。 在解决问题之前，用户无法访问网站上的任何下拉菜单。
• 代码处理分页中断，并且rel next / prev和rel规范无**确设置。 该站点包含数千页的页面，这些页面涉及许多类别和子类别。
• AMP设置已损坏，并且每个带有AMP替代选项的页面均未包含正确的amphtml代码。 rel规范已从AMP页面中删除，这是同一错误的一部分。
• 标题标记在关键区域得到了改进，但是html代码被偶然添加到了这些标题中。 html代码开始破坏标题标签，导致标题长度超过800个字符。
• 代码故障在页面上的每个链接上添加了其他子目录，所有子目录均导致页面空白。 在这些页面上，更多目录被添加到导航中的每个链接。 这引发了无限风暴被稀薄内容（无限空间）爬网的完美风暴。

我想你明白了。 这就是为什么仅检查登台还不够好的原因。 更改上线时，您需要重新爬网生产站点，以确保正确实施这些更改。 同样，上面列出的问题很快得到了解决。 但是，如果在更改生效后没有再次爬网该站点，那么它们可能会引起大问题。

克服针对SEO的墨菲定律

我们没有生活在一个完美的世界中。 实时发布更改时，没有人试图破坏网站。 只是在大型和复杂的站点上工作才打开了可能导致大问题的小错误的大门。 重新引导您进行的更改可以解决这些问题。 这样可以节省当天的SEO。

对于已经进行了最终爬网分析的您来说，这真是棒极了。 对于那些相信您建议的更改可以正确投入生产的人，请再次阅读我在重新爬网分析期间发现的实际问题的列表。 然后确保在您的下一个项目中包括重新爬网分析。 那就是“最后一英里”。

我以前写过关于墨菲定律的文章。 这是真实的，而且对于SEO来说很可怕。 进行重新爬网可以帮助阻止Murphy-当Googlebot敲门时，这总是一件好事。

本文中表达的观点是来宾作者的观点，不一定是Search Engine Land。 工作人员作者在此处列出。