如何避免来自平台的SEO灾难

重新设计您的电子商务网站或更改平台会令人不寒而栗。 很容易错过重要的一步，并失去宝贵的自然搜索流量和收入。

我曾协助许多电子商务网站进行重新设计和重新平台设计。 大多数进展顺利。 许多实际上增加了SEO流量。 但是有些痛苦。 我努力向他们学习。

当我回顾成功与失败时，谷歌文档或SEO博客中存在一些明显的极端案例和情况，这些都不属于一般建议的一部分。

在本文中，我将分享我的战斗伤痕-这些案件需要采取额外的步骤来防止灾难或事后迅速恢复。

首先，我将总结来自Google和SEO从业人员的标准建议。

标准建议

全面的301重定向地图。 当新设计或平台需要更改URL时，这是最关键的步骤。 您必须将每个旧URL映射到等效的新URL。 不要只映射首页。 映射每个页面。

一致的SEO元数据。 如果您在现有站点中拥有高质量的元数据（标题，元描述，H1标签），请确保至少将它们导入新平台。 当旧站点中的页面没有元描述时，没有任何借口。

降低DNS TTL。 在平台更改期间，任何事情都可能出错。 还原DNS更改可能会非常缓慢。 通过将站点的主DNS记录设置为最短的TTL（生存时间）时间，可以降低这种风险。

如果在重新平台期间需要还原到旧站点，则将域的DNS记录设置为较短的生存时间（即TTL）将迫使ISP更快地将更改识别回旧站点。

检查DNS传播。 除了确保DNS切换快速发生，并且可以快速返回到以前的站点之外，还要跟踪在网络上更新新IP的速度。 DNS Checker是一个方便，免费的工具，可以帮助您执行此操作。

DNS***是跟踪网络上新IP更新速度的好工具

更新XML网站地图和robots.txt。 您的XML网站地图和robots.txt文件需要更新，以反映新的设计或平台URL约定。

消除重定向链。 如果您具有先前重新设计或迁移的重定向映射，将这些重定向链接到新的重定向不是一个好主意。 最好将旧地图中的源URL连接到新平台中的最终目标。

监视爬网统计信息和爬网错误。 启动后，您可能仍会在Google Search Console中看到新的404错误。 也有可能在抓取活动中看到较大的峰值。 正常情况下，最初几天会看到这种情况，但是如果一周后仍然可以看到它们，则可能有无限的爬网空间，应将其固定。

分别移动各节。 同时保留新旧网站的运行的风险要小得多，因为新网站不可见且搜索机器人无法访问。 然后，您一次重定向和打开部分，从风险最低的部分开始。 这种做法对大型零售商尤其重要。

非学校推荐

我已经通过困难的方式学到了一些下一个建议：我首先遵循了最佳实践，然后发现了引发各种问题的极端案例。

许多站点所有者试图在新站点迁移或重新设计期间改善表面上的所有内容，例如精美的导航，无限滚动以及改进的标题和元描述。

但以我的经验来看，在重新设计或迁移期间所做的更改越少越好。 相中最大的变化。 例如，首先完成重新设计或重新平台，然后更改标题标签，然后进行导航更改。

这种方法的主要好处是，如果出现性能下降，则更容易找出原因并恢复原状。

以下是我从经验中学到的其他建议。

启动前请勿更改标题标签。 更改标题标签的问题在于它们会影响排名。 如果您在整个网站上更改标题标签，则可能会看到广泛的排名变化。 在某些情况下，您可以提高排名。 但是在其他情况下，您可能会浪费大量时间。 不值得冒险。

重新设计或迁移后几周，如果没有问题，是更好的时间来更新标题标签。 但是即使如此，也要分批更改标题。 保持标题更改的效果更好，然后回退那些效果不佳的标题。

映射来自Google Analytics（分析）的所有URL。 我经常看到重定向地图仅包含效果最好的页面，或者在最佳情况下仅包含XML站点地图中的URL的情况。 但是Googlebot的记忆力很长。 它对不再从站点中任何位置链接但已从第三方站点链接的页面进行爬网和排名。 如果您忘记映射这些页面，则将失去宝贵的流量。

确保所有页面都重定向的一种简单方法是从Google Analytics（分析）中检索它们。

确保重定向映射保留冗余参数。 开发人员经常寻找捷径，以在更短的时间内完成更多工作。

但是，您不希望开发人员在重定向映射中使用快捷方式。 重定向规则必须足够通用，以便它们考虑源URL的任何可能变体。 特别是，他们需要考虑到您尚未看到的冗余参数。

以下重写是错误的，因为它删除了URL参数（包括付费搜索跟踪）。

在RewriteEngine上
RewriteRule ^ p / 1002 /(.*）http://www.newstore.com/product/1002/？ [L，R = 301]

—

此重写是正确的，因为它保留了URL参数。

在RewriteEngine上
RewriteRule ^ p / 1002 /(.*）http://www.newstore.com/product/1002/ [L，R = 301]

不要合并大组页面。 在重新设计或重新设计平台时，电子商务商人通常希望消除商店的某些部分，或合并部分，以使访问者更轻松地完成购买。

假设删除或合并301重定向部分或页面会提高流量和排名是错误的。 尽管合并后的页面通常可以提高页面声誉，并且性能比以前更好，但是它们通常缺少合并后的页面的内容，并且不能以相同的术语进行排名。

如果您需要合并页面，请在重新设计或迁移之后进行，并考虑打开可以弥补合并页面的多面导航页面。

不要删除过多的内容。 我学到的另一个重要经验教训是，在重新构建平台后，您的电子商务网站上的唯一内容总量应保持不变。

下图显示了我进行的迁移后分析，以了解为什么网站的访问量和收入下降，并查找有问题的页面。

进行了迁移后分析，以了解流量和收入下降的原因。

请注意，在上面的图表中，产品，内容和主页的性能相似，但是类别页面的性能仅为以前的一半。 我们比较了页面的总数和前后的字数，发现内容量大大减少了。

等待移至https。 我通常建议您利用重新设计或重新设计平台的机会转到https。 但是，由于这一变化，最近的迁移变得更加复杂。 因此，我现在建议迁移后作为一个单独的步骤移至https。

转向https不仅需要进行重新设计和重新平台，还需要进行周密的计划。 我将在下一篇文章中详细介绍它。

不要忘记URL参数设置。 您的新平台可能需要Google Search Console中全新的URL参数设置。 这些参数可确保流畅的Googlebot抓取体验。 明智的做法是在迁移之前（或迁移时）预先配置新的URL参数，同时保持旧参数不变。

等待启动无限滚动。 SEO友好的无限滚动需要复杂的实现，并且还需要支持标准分页。 如果启动时没有SEO友好的无限滚动，则最终将出现未爬网或未编入索引的分页类别页面。

考虑在没有无限滚动的情况下完成重新平台，然后在以后以SEO友好的方式添加功能。

注意JavaScript呈现的页面。 复杂的电子商务系统有时会使用JavaScript来渲染商品列表页面，而Google不会对其编制索引。 最具挑战性的部分是，您需要使用Search Console的“获取和呈现”来检查您的页面，但是Search Console仅适用于公共站点，并且重新设计或重新平台化将在临时环境中进行。

一个简单的快捷方式是让您的电子商务平台提供其他正在运行该系统的公共站点的示例，然后使用Google的cache命令来查看是否存在问题。

要求您的电子商务平台提供运行该系统的其他站点的示例，然后使用Google的cache命令查看是否存在问题。 在这种情况下，缺少页面网格。

—

另一个解决方案是设置一个示例测试页以公开打开，并使用Search Console的“获取和呈现”功能进行检查。

—

设置示例测试页，您可以公开打开该页面，并使用Search Console的“获取和呈现”功能进行检查。

迁移旧的重定向和重定向配置。 我在零售商处的一些开发团队在迁移后会丢弃旧的重定向映射文件。 但是问题在于重定向是永久的。 Google永远不会忘记他们。 它会继续重新搜寻旧的404或410 URL，以防它们再次出现。

我去年在一个重新平台上遇到了这个问题。 Google在重新平台后产生了20,000多个404错误，几乎无法识别实际的迁移后404。 问题变得更加复杂，因为Search Console一次仅允许您提取1,000个404 URL，而新的平台供应商仅将Web服务器日志保留了30天。

请注意，Search Console过去曾允许您使用其API提取所有错误，但Google对其进行了更改，并提供了该功能的有限版本。

保留90天的Web服务器日志。 Search Console是一款出色的免费SEO工具。 但是，在缩小关键SEO问题的范围内，Web服务器日志是您的朋友。 您可以找到Google和其他搜索引擎抓取或未抓取的所有URL，还可以确定任何主要问题。

如果您在迁移后遇到许多意外的404错误，则迁移前后Google所访问的URL的全面列表对于更快地完成重定向映射至关重要。

地图图像和视频URL。 我经常在重定向映射中仅看到网页URL。 但是，如果您在Search Console中签入Search Analytics，则可能会发现大量来自图片的流量。 图片和视频网址也经常获得链接。 因此，最好在重新平台中创建301重定向到新的图像和视频URL。

避免花哨的分析实施。 这可能是我在重新平台后看到的最模糊的问题。 Google将该网站标记为被黑客入侵，并注入了垃圾内容。 但是，当我们仔细观察时，这不是黑客，而是高级Google Analytics（分析）实现。 开发人员将隐藏的div元素用于某些自定义属性，而不是更标准地使用JavaScript变量。 隐藏的div元素很可能为Googlebot提供了与隐藏的垃圾邮件文本类似的模式。

在一个实例中，开发人员将隐藏的div元素用于某些自定义属性，而不是更标准地使用JavaScript变量。

仔细检查分析设置。 有时由于跟踪问题，迁移后的性能似乎比预期的要差或更好。 某些页面可能缺少Google Analytics（分析）标签，或者标签重复，或者缺少用于整合第三方购物车指标的设置，因此流量被标记为引荐。

我遇到的其他问题是，付费搜索流量被错误地标记为自然搜索，因为重定向映射将用于标记AdWords广告系列的gclid去除了。

明智的做法是使用Screaming Frog之类的工具来爬网新站点，以确保所有分析标记都正确并正确无误。

启动后监视日志。 我要求客户的开发团队每天将Web服务器日志发布到SFTP站点或Amazon S3存储桶，以便与Google Search Console相比，可以拉动它们并以更好的分辨率监视Googlebot的活动。

例如，我们启动了一个新站点，当请求具有ACCEPT-LANGUAGE标头时，页面仅显示其他语言版本，而Googlebot应该支持该标头。 但是，许多星期之后，我们还没有看到Googlebot使用其他语言来获取页面。

结论

重新设计或重新平台后，我在管理自然搜索流量方面的课程不会在这里停止。 该列表将随着其他迁移战而增长。 如果您有我没有涉及的经验，请在评论中分享。