Return to site

从Web迁移中恢复有机搜索流量错误

我知道如果没有确定301重定向的位置并确保链接,XML站点地图和/或规范标签也会更新,您将永远不会更改URL。但是,如果你已经做了一段时间的搜索引擎优化,我打赌你也有一些客户 - 甚至是大客户 - 他们试图进行结构性网络更改或任何类型的迁移之后,而不采取SEO最佳实践考虑到。

每当发生这种情况时,您的新客户会在“紧急”类型的情况下向您寻求帮助,其中在执行所需的SEO分析时有两个特征:

  1. 您需要优先考虑: 
    您的客户可能对此情况非常紧张。您没有足够的时间在一开始就投资,立即进行全面审核。您需要专注于识别迁移过程中未完成的操作,以确保修复流量丢失的根本原因 - 然后您可以继续进行其他操作。
     
  2. 您可能没有所有数据: 
    您可能只有基本信息(如Google Analytics和Google Search Console)以及客户与您分享的有关执行更改时所采取的步骤的信息。通常没有以前的排名,抓取或访问日志。您需要充分利用这两个相当容易获得的数据源,您可以自己进行的新爬网以及第三方“历史”排名数据。在这个分析中,我们将从现有的情况中作为“最坏情况”工作,因此您可以获得的额外收益将是额外的好处。
如何充分利用您的时间和基本数据访问来识别出现问题并进行修复 - 尽快?

让我们完成“最低可行”Web迁移验证的步骤,以确定要修复的关键问题:

1.验证Web迁移是导致流量丢失的原因。

首先,它是关键:

  • 从客户端获取已完成的特定更改以及迁移期间采取的操作,以便您可以识别可能遗漏的那些并在进行分析时确定其验证的优先级。
  • 检查流量丢失的时间是否与迁移的时间一致,以验证它实际上是原因,或者是否有可能同时受影响的不同或重合因素,以后您可以在完成时考虑审计和分析。

要识别此情况,请将之前和之后的其他流量来源,每台设备和您网站的迁移区域(如果不是全部更改)进行比较,等等。

使用“ 为什么我的网络流量丢失”核对清单快速验证丢失与此无关,例如,迁移后的Google Analytics设置不正确或同时发生Google更新。

我遇到的情况是,有机搜索流量丢失不仅与网络迁移同时发生,而且与幻影更新的日期一致(并且它们具有针对性的特征类型)。

如果是这种情况,在修复与迁移相关的问题后,您不能期望重新获得所有流量。将需要进一步的分析和实施来解决流量损失的其他原因。

2.确定在流量,转化次数和排名中下降最多的网页。

一旦您确认流量丢失(完全或部分)到达网络迁移,那么下一步就是集中精力分析和识别那些在流量,转化次数和排名方面受到最大影响的问题透视。您可以通过在Google Analytics中迁移之前和之后比较每页的自然搜索流量来执行此操作:

选择以前拥有最高流量和转化次数且丢失最高流量百分比的那些。

您还可以执行与Google Search Console“搜索分析”报告中具有最大负面更改的展示次数,点击次数和排名最高的网页类似的内容:

收集此数据后,在Excel电子表格中合并所有这些页面(和相关指标)。在这里,您将拥有从迁移中丢失最多的最关键页面。

3.确定这些页面排名的关键字并开始监控它们。

在大多数情况下,问题将是技术问题(尽管有时可能是由于结构内容问题)。但是,重要的是要确定过去这些页面已经过排名的关键字,这些关键字在迁移后失去了可见性,开始跟踪它们,并且能够在问题得到修复后验证其改进。

这可以通过从具有历史关键字排名功能的工具(如SEMrush,Sistrix或SearchMetrics)收集数据来完成,这些功能还可以显示哪些页面在特定时间段内丢失了排名。

这可能有点耗时,因此您也可以使用URLProfiler来发现过去排名的关键字。它可以通过API轻松连接您的Google Search Console“搜索分析”数据,以获取过去3个月的查询。

因此,您可以在一个电子表格中评估关键字数据和选定的关键页面:

现在,您可以使用自己喜欢的关键字监控工具开始跟踪这些关键 您甚至可以使用SERPwoo等工具跟踪关键字的整个SERP 。

4.抓取带有流量下降的网页列表和完整网站,以确定问题和差距。

现在,您可以使用Screaming Frog等SEO爬虫的“列表模式”抓取您已识别的页面列表,然后使用“爬虫模式”抓取您的网站,比较丢失流量的网页与新网页中的问题,目前相关的。

您还可以将网站抓取与Google Analytics集成,以确定差距(ScreamingFrog和Deepcrawl具有此功能),并验证可能由迁移引起的抓取,索引,甚至结构内容相关问题。以下是我建议您看一下的一些基本原理,回答以下问题:

A.)哪些页面不在网络爬行中(因为它们不再链接)但是正在接收有机搜索流量?

这些与丢失流量,排名和转换的页面是否一致?这些页面已被替换?如果是这样,为什么他们没有被301重定向到他们的新版本?做吧

B.)协议中的协议是否不一致?

特别是如果迁移是从一个版本到另一个版本(例如HTTP到HTTPS),请验证是否仍有页面仍在使用其HTTP版本进行爬网,因为链接或XML站点地图未更新...请确保修复它。

C.)规范化页面是否指向不相关的URL?

检查已迁移页面的规范标签是否仍指向旧URL,或者规范标签是否已更改并突然指向不相关的URL(例如主页,如下例所示)。如果是这种情况,请务必更新它们以指向其相关的原始URL。

D.)现在通过robots.txt阻止了有流量丢失的网页,还是不可索引的?

如果是这样,为什么?取消阻止应该被抓取,编入索引和排名的所有页面以及之前的页面。

E.)验证重定向逻辑是否正确。

仅仅因为页面被重定向并不意味着那些重定向是正确的。通过询问以下问题来确定这些类型的问题:

  • 重定向是否会转到旧版本的相关新页面版本?
    验证重定向是否转到具有类似内容且与重定向目标具有相同目的的正确页面目标。如果不是,请确保更新重定向。
  • 是否有任何302重定向应该成为301s(因为它们是永久性的而不是临时的)
    更新它们。
  • 是否存在可能干扰搜索爬虫到达最终页面目的地的重定向循环
    也更新这些。
特别是如果您有一个独立的移动网站版本(例如,在“m”子域下),您将需要专门验证其重定向逻辑与桌面版本。
  • 重定向是否会转向不可索引,规范化,重定向或错误页面?
    优先考虑修复。 

为了便于此分析,您可以使用OnPage.org的“按状态代码重定向”报告。

    • 为什么这些重定向的页面仍在被抓取?
更新仍指向现在重定向到其他页面的页面的链接和XML站点地图,以便它们直接进入最终页面进行爬网,索引和排名。
  • 丢失的流量页面中是否存在重复的内容问题?
    重定向,规范,无索引或分页的配置可能已更改,因此这些页面现在可能包含已标识为重复且应修复的内容。
  • 5.是时候对已识别的问题实施修复。

    一旦您提出这些问题并更新丢失的流量页面的配置,如上所述,重要的是:

    1. 更新所有内部链接以直接转到最终的URL目标。
    2. 更新所有XML站点地图,以消除旧网址的包含,仅保留新网址并将其重新提交到Google Search Console
    3. 验证是否有任何外部链接仍然存在现在应该重定向的不存在的页面。这样,在将来和更多时间,您可以与链接到它们的最权威的站点进行外展,以便可以更新它们。
    4. 使用Google Search Console“抓取为Google”部分提交要重新抓取的丢失的流量页面。

    重新提交后,通过您的网络日志开始监控搜索爬虫的行为(您可以使用尖叫青蛙日志分析器),以及您的网页的索引,排名和流量趋势。几天后你应该开始看到一个积极的举动:

    请记住,如果迁移需要进行大幅度的更改(例如,如果您已经迁移到其他域名),那么很快就会看到短期排名和流量丢失。即使现在已正确实施并且新域具有更高权限,也可以这样。你应该考虑到这一点; 但是,如果改变改善了以前的优化状态,那么中长期结果应该是积极的。

    正如您在上面所看到的,如果您确保优先处理并解决负面影响问题,则可以从此类情况中恢复,然后再继续更改与其无关的任何其他内容。完成此操作并看到积极趋势后,您就可以开始完整的SEO审核和流程,以改进您迁移的内容,最大化新Web结构的优化和结果。

    All Posts
    ×

    Almost done…

    We just sent you an email. Please click the link in the email to confirm your subscription!

    OKSubscriptions powered by Strikingly