Return to site

SEO|网站搜索引擎优化-策略、流程和检查列表

网站搜索引擎优化

· seo优化
什么是站点迁移?

网站迁移是搜索引擎优化专业人员广泛使用的一个术语,用于描述网站在哪些领域发生重大变化,这些变化可能会对搜索引擎的可见度产生重大影响-通常是网站结构、内容、编码、网站性能或用户体验的重大变化。

谷歌优化关于网站迁移的文档并没有很深入地报道这些信息,并淡化了这样一个事实:它们往往会导致流量和收入的重大损失-这可能会持续几周至几个月-这取决于搜索引擎推广排名信号受到影响的程度,以及受影响的业务推出成功的复苏计划可能需要多长时间。

站点迁移实例

下一节将讨论成功和不成功的站点迁移,并解释为什么在不遭受重大损失的情况下100%地完成站点迁移。

揭穿“预期流量下降”的神话

任何参与过网站迁移的人都可能听说过这样一种普遍的理论,即这将导致事实上的流量和收入损失。尽管这一论断对某些非常具体的案例(即从一个已建立的领域转移到一个全新的领域)有一定的真实性,但它不应被视为福音。这是完全可能的迁移,而不失去任何流量或收入,你甚至可以享受显著增长后,推出一个改进的网站。然而,只有在每一步都经过了周密的规划和执行之后,才能实现这一目标.

不成功地点迁移的例子

下图展示了英国一家大型零售商的网站迁移,从HTTP到HTTPS两周后,该网站失去了35%的可见性。他们花了大约6个月的时间才完全恢复,这肯定对有机搜索的收入产生了重大影响。这是糟糕的站点迁移的一个典型例子,可能是由于规划或执行不善造成的。

一个糟糕的地点迁移的例子-恢复花了6个月!

但复苏并非总是可能的。下面的可见性图来自另一家英国大型零售商,在那里,HTTP到HTTPS的切换导致了20%的可见性永久丢失。

另一个例子,一个糟糕的网站迁移-没有迹象恢复6个月后!

事实上,从HTTP迁移到HTTPS是完全可能的,而不会丢失如此多的流量,在如此长的一段时间内,除了前几周,谷歌发现新的URL和更新搜索结果时,关键词排名优化会出现很大的波动。

成功迁移网站的例子

成功的站点迁移是什么样子?这在很大程度上取决于站点迁移类型、目标和KPI、网页优化seo。但在大多数情况下,成功的站点迁移至少显示了以下特征之一:

  1. 头几周能见度损失最小(短期目标)
  2. 此后的能见度增长-取决于移徙类型(长期目标)

下面的可见性报告是从HTTP迁移到HTTPS站点的,该迁移还伴随着对站点页面加载时间的显著改进。

下面的可见性报告来自一次完整的现场大修,我有幸提前几个月参与其中,并在战略、规划和测试阶段得到了支持,所有这些都同样重要。

由于通常发生在工地迁移项目上,由于过早启动新网站的风险,以及在充分解决重大技术障碍之前,启动日期不得不推迟几次。但是,正如您在下面的可见性图上所看到的,等待是非常值得的。有机能见度不仅没有下降(正如大多数人通常预期的那样),而且实际上从第一周就开始增长。

迁移后一个月的能见度增长达到60%,而有机交通在发射两个月后的增长超过80%。

一个非常成功的网站迁移的例子-在新站点发布后立即增长!

这是一个相当复杂的迁移,因为这个新网站是在一个新的平台上重新设计和构建的,它改进了网站分类,包括新的登陆页面、更新的URL结构、大量的重定向以保持链接公平性,以及从HTTP到HTTPS的转换。

通常,同时引入太多的更改是很棘手的,因为如果出了问题,您将很难找出究竟是什么错了。但同时,将重大变化留待以后进行也不理想,因为这将需要更多的资源。如果你知道自己在做什么,那么一次做出多个积极的改变是非常划算的。

在深入了解如何将复杂的站点迁移项目转化为成功之前,重要的是运行主要站点迁移类型,并解释许多站点迁移失败的主要原因。

站点迁移类型

站点迁移类型很多。这都取决于传统网站所发生的变化的性质。

Google优化的文档主要涉及站点位置更改的迁移,这些更改分类如下:

  • 场地移动带着URL更改
  • 场地移动URL更改

场地迁移

这些情况通常发生在网站移动到另一个URL时,原因如下所示:

协议变更

一个典型的例子是当从HTTP迁移到HTTPS时。

子域或子文件夹更改

在国际SEO中非常常见,企业决定将一个或多个ccTLD移动到子域或子文件夹中。另一个常见的例子是,位于单独的子域或子文件夹上的移动站点变得响应,桌面和移动URL都是统一的。

域名变更

通常发生在企业重新命名并且必须从一个域转移到另一个域时。

顶层域更改

当企业决定启动国际网站并需要从ccTLD(国家代码顶级域)转移到gTLD(通用顶级域),或者反过来,例如从.co.uk迁移到.co.uk,或者从.com移动到.co.uk等,这种情况很常见。

场地结构变化

这些是对站点架构的更改,通常会影响站点的内部链接和URL结构。

其他类型的移徙

还有其他类型的迁移,这些迁移是通过更改站点的内容、结构、设计或平台来触发的。

再版

当一个网站从一个平台/CMS移动到另一个平台/CMS时,情况就是这样,例如从WordPress迁移到Magento,或者只是升级到最新的平台版本。在某些情况下,由于技术上的限制,在某些情况下,重构还会导致设计和URL更改。这就是为什么重新定位迁移很少会导致一个与前一个网站完全相同的网站。

内容迁移

主要的内容更改,如内容重写、内容整合或内容修剪,可能会对站点的有机搜索可见性产生很大影响,这取决于规模。这些更改通常会影响站点的分类、导航和内部链接。

移动设置更改

有这么多选项可供网站的移动设置使用,启用应用程序索引、构建AMP站点或构建PWA网站也可被视为部分站点迁移,特别是当现有移动站点被应用程序AMP或PWA所取代时。

结构变化

这通常是由于站点的分类法发生了重大变化,对站点导航、内部链接和用户行程产生了影响。

场地重新设计

这些可以从外观和感觉上的重大设计变化,到一个完整的网站改造,其中也可能包括重要的媒体,代码和复制的变化。

混合迁移

除了以上所述之外,还有几种混合迁移类型可以任何可能的方式组合在一起。同时引入的变化越多,复杂性和风险就越高。尽管同时进行太多的更改会增加出错的风险,但从资源的角度来看,如果迁移计划和执行得很好的话,成本效益可能会更高。

常见的站点迁移陷阱

尽管每个站点迁移都不同,但最典型的站点迁移灾难背后也有一些共同的主题,其中最大的主题如下:

不良战略

在新站点启动之前,一些站点迁移注定要失败。建立在不明确和不现实目标的基础上的战略不太可能带来成功。

为了衡量发射后移徙的影响,必须制定可衡量的目标。对于大多数网站迁移,主要目标应该是保持网站目前的流量和收入水平。在某些情况下,标准可以提高,但一般而言,预测或预测增长应是次要目标。这将有助于避免产生不切实际的期望。

规划不善

尽早制定一个详细网站建设及推广的项目计划将有助于避免沿途的延误。考虑到额外的时间和资源,以应付任何可能出现的意外情况。不管你的计划有多周密,也不太可能一切如愿。灵活处理你的计划,并接受这样一个事实,那就是几乎肯定会有延误。规划所有依赖关系,并使所有涉众都了解它们。

避免计划在你的季节性高峰附近发布网站,因为如果出了什么问题,你将没有足够的时间来纠正这些问题。例如,零售商应避免在接近9月/10月的时候推出一个网站,以避免将繁忙的圣诞节前时期置于危险之中。在这种情况下,在较为安静的夏季,它的推出将更加明智。

缺乏资源

在承诺一个站点迁移项目之前,要估计成功所需的时间和精力。如果你的预算是有限的,打一个电话,它是否值得继续进行迁移,很可能无法实现其既定目标,并造成收入损失。

根据经验,尝试在额外资源中包含至少20%的缓冲区,这比您最初认为的项目所需的资源要多。这个额外的缓冲区稍后将允许您在任何问题出现时迅速解决,而不会危及成功。如果您的资源太紧,或者在这个早期阶段就开始偷工减料,站点迁移将面临风险。

缺乏SEO/UX咨询

当改变发生在一个网站上,每个决策都需要从UX和SEO的角度进行加权。例如,删除大量内容或链接以改进UX可能会损害站点针对业务关键字的能力,或者导致爬行和索引问题。在这两种情况下,这种变化都可能损害网站的有机搜索能见度。另一方面,过多的文本拷贝和很少的图片可能会对用户的参与产生负面影响,并破坏网站的转换。

为了避免风险,任命有经验的SEO关键词优化和UX顾问,这样他们就可以与比其他人更了解业务复杂性的关键业务涉众讨论每一个变化的潜在后果。在作出任何决定之前,需要权衡每种选择的利弊。

后期参与

站点迁移可以跨越几个月,需要很好的计划和足够的时间进行测试。晚些时候寻求专业支持是非常危险的,因为关键的步骤可能已经错过。

缺乏测试

除了一个伟大的战略和深思熟虑的计划,投入一些时间和努力彻底测试,然后推出网站。如果测试确定了关键问题,而不是匆忙地将粗略的实现投入生产,那么延迟发布要好得多。不用说,如果一个网站没有经过专家SEO和UX团队的测试,你就不应该发布它。

注意细节也很重要。确保开发人员充分意识到与实现不力相关的风险。教育开发人员了解他们的工作对网站流量的直接影响(以及收入)可以产生很大的影响。

对错误修复的缓慢响应

一旦新站点启用,总会有bug需要修复。但是,有些bug比其他bug更重要,可能需要立即注意。例如,启动一个新站点只是为了发现搜索引擎蜘蛛在爬行和索引站点内容方面有困难,这需要立即修复。对重大技术障碍的缓慢反应有时可能是灾难性的,需要很长时间才能从其中恢复过来。

低估尺度

业务涉众通常不会预期站点迁移会耗费时间和资源。对于高级利益相关者来说,要求新网站在计划好的一天内推出并不少见,不管它是否已经100%准备好了。格言“让我们尽快启动,然后修复”是一个典型的错误。大多数利益相关者不知道的是,有机搜索的能见度可能只需几天,但恢复可能需要几个月的时间。

顾问和项目经理有责任对客户进行教育,在所有不同的阶段和场景中对他们进行操作,并解释每一个阶段和场景所包含的内容。然后,业务涉众能够做出更知情的决策,他们的期望应该更容易管理。

场地迁移过程

场地迁移过程可分为六个主要阶段。它们都同样重要,跳过以下任何任务都会在不同程度上阻碍迁移的成功。

第一阶段:范围和规划
制定项目范围

不管站点迁移项目背后的原因是什么,您需要从一开始就对目标非常清楚,因为这些目标将有助于设置和管理期望。将站点从HTTP迁移到HTTPS与进行彻底的站点大修是非常不同的,因此这两个站点应该有不同的目标。在第一种情况下,目标应该是保持站点的流量水平,而在第二种情况下,您可能会以增长为目标。

站点迁移是解决遗留问题的好机会。在项目范围中包括尽可能多的这些应该是非常具有成本效益的,因为在启动后解决这些问题将需要更多的资源。

然而,在每一种情况下,确定项目成功的最关键的方面。确定所有可能对网站可见性产生负面影响的风险,并考虑采取哪些预防措施。理想情况下,根据不同的风险和增长机会,准备一些预测方案。不用说,预测方案应由经验丰富的工地迁移顾问编写。

在这个早期阶段,包括尽可能多的利益相关者,将有助于您更深入地了解跨部门的最大挑战和机遇。询问你的内容,SEO,UX,和分析团队的反馈,并列出一个最大的问题和机会的清单。然后,您需要计算出解决这些问题的潜在ROI是什么。最后,根据您的目标和可用资源选择一个可用的选项,这将构成您的站点迁移策略。

现在,您应该有一个优先的活动列表,这些活动如果实现,预期将有一个积极的ROI。然后与所有涉众进行沟通和讨论,以便您从一开始就设定现实的目标、商定项目的范围和设定正确的期望。

准备项目计划

规划同样重要,因为站点迁移通常是非常复杂的项目,可以轻松跨越几个月。在计划阶段,每个任务都需要一个所有者(即SEO顾问、UX顾问、内容编辑器、web开发人员)和一个预期的交付日期。任何依赖项都应该识别并包含在项目计划中,这样每个人都知道由于依赖他人而无法完成的任何活动。例如,除非重定向映射已经完成,并且重定向已在暂存时实现,否则无法测试重定向。

项目计划应尽早与大家分享,以便有足够的时间进行讨论和澄清。每项活动都需要详细说明,以便利害关系方了解每项任务将涉及的内容。不用说,要按照时间表组织和开展所需的活动,就必须进行完美无缺的项目管理。

项目计划的一个关键部分是确定预期的启动日期。理想情况下,新网站应该在流量低的时候推出。同样,避免提前或在高峰时期启动,因为如果事情不像预期的那样,后果可能是毁灭性的。要记住的一点是,由于站点迁移永远不会完全按照计划进行,因此需要一定程度的灵活性。

第二阶段:发射前准备

这些活动包括在新地点仍在开发中时需要开展的任何活动。到这一点,新网站的SEO要求应该已经捕获。您应该与设计人员和信息架构师保持联系,在新站点可以在分阶段环境中使用之前,提供有关原型和线框的反馈。

线框审查

在开发开始之前,检查新站点的原型或线框。审查新网站的主要模板可以帮助识别SEO和UX在早期阶段的问题。例如,您可能会发现,大部分内容已经从类别页中删除,这些内容应该立即被标记。或者您可能会发现一些高流量驱动页面不再出现在主导航中。任何根本的改变,在设计或复制的网页,应彻底审查潜在的SEO问题。

编制技术SEO规范

一旦原型和线框已经被审查,准备一个详细的技术搜索引擎优化SEO规范。这一重要文件的目标是捕捉所有必要的SEO需求开发人员需要知道,然后才能计算出项目的工作范围和成本。这是在这个阶段,预算是签署的;如果SEO的要求不包括在内,这可能是不可能包括他们以后的路线。

技术SEO规范需要非常详细,但编写的方式使开发人员可以轻松地将需求转化为行动。这不是要解释的文件为什么一些事情需要实施,但是多么,怎样它应该得到执行。

确保包括至少涵盖以下领域的具体要求:

  • URL结构
  • 元数据(包括动态生成的默认值)
  • 结构化数据
  • 规范和元机器人指令
  • 复制和标题
  • 主次航行
  • 内部链接(以任何形式)
  • 分页
  • XML站点地图
  • HTML站点地图
  • Hcorang(如果有国际网站)
  • 移动设置(包括应用程序、AMP或PWA站点)
  • 重定向
  • 自定义404页
  • JavaScript、CSS和图像文件
  • 页面加载时间(用于桌面和移动)

规范还应包括CMS功能领域,允许用户:

  • 指定自定义URL并覆盖默认URL
  • 更新页面标题
  • 更新元描述
  • 更新h1-h6标题
  • 添加或修改默认规范标记
  • 将元机器人属性设置为index/noindex/追随者/no追随者
  • 添加或编辑每个图像的ALT文本
  • 包括用于描述、URL、图像、类型、站点名的开放图形字段
  • 包括TwitterOpen图字段,用于卡片、URL、标题、描述、图像
  • 批量上载或修改重定向
  • 更新robots.txt文件

还必须确保在更新特定属性(例如h1)时,其他元素不受影响(即页面标题或任何导航菜单)。

识别优先级页

站点迁移的最大挑战之一是,google优化成功与否在很大程度上取决于已迁移的页面的数量和质量。因此,确保您专注于真正重要的页面是非常重要的。这些页面一直在驱动旧站点的流量,有累积链接的页面,以及转换良好的页面等等。

为了做到这一点,您需要:

  1. 爬行遗留站点
  2. 标识所有可索引页
  3. 识别性能最好的页面

如何爬行遗留站点

抓取旧网站,以便你有一个所有的网址,网页标题,元数据,标题,重定向,断链接等的副本。不管选择的爬虫应用程序,确保爬行不太严格。在爬行遗留站点之前,请密切注意爬虫的设置,并考虑是否应该:

  • 忽略robots.txt(以防任何重要部件意外阻塞)
  • 遵循内部的“no追随者”链接(因此爬虫到达更多的页面)
  • 爬行所有子域(取决于范围)
  • 爬行外部开始文件夹(取决于范围)
  • 将用户代理更改为Googlebot(桌面)
  • 将用户代理更改为Googlebot(智能手机)

贴士:在迁移完成几个月后,将旧站点的爬行数据(文件或云中)的副本保存几个月,以防在新站点运行后需要旧站点的任何数据。

如何识别可索引页

一旦爬行完成,就可以识别遗留站点的索引页。这些是具有以下特征的任何HTML页面:

  • 返回200服务器响应
  • 要么没有规范标记,要么具有自引用规范URL。
  • 没有元机器人
  • 不排除在robots.txt文件中。
  • 内部链接到其他页面(非孤立页)。

可索引页面是唯一有可能将流量驱动到站点的页面,因此在站点迁移中需要对其进行优先排序。这些页面值得优化(如果它们将存在于新站点上)或重定向(如果它们不存在于新站点上)。

如何识别性能最好的页面

一旦确定了所有可索引的页面,您可能需要执行更多的工作,特别是如果遗留站点包含大量页面,并且由于时间、资源或技术限制,不可能对所有这些页面进行优化或重定向。

如果是这样的话,您应该识别遗留站点的最佳执行页面。这将有助于在后期阶段对要重点关注的页面进行优先排序。

建议编写包含以下字段的电子表格:

  • 遗留URL(仅包括来自CRW数据的可索引URL)
  • 过去12个月的有机访问(分析)
  • 过去12个月的收入、换算率和换算率(分析)
  • 过去12个月的网页浏览量(分析)
  • 过去90天的点击次数(搜索控制台)
  • 顶级链接页面(Majestic SEO/Ahfers)

有了上面的信息在一个地方,它现在更容易确定您最重要的网页:那些产生有机访问,转换良好,贡献收入,有大量的参考领域链接到他们,等等。为了成功地迁移站点,您必须关注这些页面。

理想情况下,新站点上也应该存在性能最好的页面。如果由于任何原因他们没有,他们应该被重定向到最相关的页面,这样用户要求他们不会登陆404页,他们以前的链接公平仍然在网站上。如果这些页面中的任何一个不再存在,并且没有被正确地重定向,那么您的站点的排名和流量将受到负面影响。

标杆

一旦新网站的推出接近尾声,你就应该对遗留网站的性能进行基准测试。基准测试是非常重要的,它不仅可以比较新站点的性能,而且还可以帮助诊断哪些领域在新站点上表现不佳,并迅速解决这些问题。

秩跟踪

如果你不经常跟踪该网站的排名,你应该在新网站上线之前就这样做。否则,您稍后将很难弄清楚迁移是否进展顺利,或者到底哪里出了问题。不要把这件事留到最后一分钟,以免出问题-提前一周才是理想的时间。

花一些时间找出哪些关键词最能代表网站的有机搜索能见度,并在桌面和移动平台上跟踪它们。因为监控成千上万的头、中、长尾关键字组合通常是不现实的,所以你应该监控的最起码的关键词是那些驱动流量到站点的关键词(在第一页上排名),并且有很好的搜索量(头/中尾焦点)。

如果您确实从品牌和非品牌关键字获得流量,您还应该决定哪种类型的关键字要关注更多的跟踪POV。一般来说,非品牌关键词往往更具竞争性和波动性.对于大多数网站来说,主要关注这些网站是有意义的。

别忘了跟踪桌面和移动的排名。如果在一种设备类型上存在性能问题,这将使在启动后诊断问题变得更加容易。如果您收到来自多个国家的大量流量,请考虑其他市场中的排名跟踪关键字,因为不同国家的能见度和排名可能有很大差异。

场地性能

新网站的页面加载时间对流量和销售都有很大的影响。几项研究表明,页面加载时间越长,弹出率就越高。除非旧网站的页面加载时间和网站性能评分已经记录下来,否则很难将任何流量或收入损失归因于网站性能相关的问题。

建议您使用谷歌的PageSpeedInsight和灯塔工具检查所有主要页面类型。您可以使用像下面这样的汇总表来对一些最重要的性能指标进行基准测试,这对于在新站点运行后进行比较非常有用。

老站点爬行数据

在新站点替换旧站点的前几天,运行旧站点的最后爬行。如果在新站点上存在优化问题,那么这样做可能是非常有价值的。最后的抓取将允许您保存有关旧站点的页面标题、元描述、h1-h6标题、服务器状态、规范标记、noindex/no追随者页面、inlink/outlink、level等重要信息。如果新站点没有得到很好的优化,或者遇到技术错误的问题,那么拥有所有这些信息可以为您节省很多麻烦。还尝试保存旧站点robots.txt和XML站点地图的副本,以防稍后需要这些副本。

搜索控制台数据

还可以考虑尽可能多地导出旧站点的搜索控制台数据。这些数据只提供90天,一旦新站点启用,旧站点的搜索控制台数据迟早会消失。值得导出的数据包括:

  • 搜索分析查询和页面
  • 爬行错误
  • 阻塞资源
  • 移动可用性问题
  • URL参数
  • 结构化数据错误
  • 链接到您的网站
  • 内部链接
  • 索引状态

重定向准备

重定向实现是站点迁移过程中最关键的活动之一。如果遗留站点的URL不再存在,并且没有正确的重定向,那么该网站的排名和可见性就会下降。

为什么重定向在站点迁移中很重要?

重定向非常重要,因为它们帮助搜索引擎和用户查找可能不再存在、已被重命名或移到另一个位置的页面。从优化网站排名的角度来看,重定向帮助搜索引擎更快地发现和索引站点的新URL,但也了解旧站点的页面是如何与新站点的页面相关联的。这种关联将允许排名信号从旧页面传递到新页面,因此排名保持不变而不会受到负面影响。

当重定向没有正确实现时会发生什么?

当重定向实现不力时,后果可能是灾难性的。用户将登陆未找到的页面(404 S)或不符合用户意图的无关页面。无论是哪种情况,网站的反弹和转换速度都将受到负面影响。搜索引擎的后果也可能是灾难性的:如果URL不相同,它们将无法将旧站点的页面与新站点上的页面联系起来。排名信号不会从旧的传递到新的网站,这将导致排名下降和有机搜索能见度损失。此外,搜索引擎将需要更长的时间来发现和索引新网站的网页。

301,302,JavaScript重定向,还是元刷新?

当站点新旧版本之间的URL不同时,请使用301(永久)重定向。这将告诉搜索引擎索引新的网址,以及转发任何排名信号从旧的网址到新的。因此,如果您的站点移动到/从另一个域/子域移动,如果您从HTTP切换到HTTPS,或者站点的一个或多个部分已被重组,则必须使用301重定向。尽管谷歌声称302次重定向PageRank,但是索引新URL的速度会更慢,排名信号可能需要更长时间才能从旧页面传递到新页面。

302(临时)重定向只能在重定向不需要永久存在的情况下使用,因此索引新URL不是优先事项。对于302重定向,搜索引擎最初将不愿意索引重定向目标URL的内容,并将任何排名信号传递给它。但是,如果临时重定向保持很长一段时间而不被移除或更新,则它们最终可能以类似于永久重定向(301)的方式结束。当重定向可能需要在不久的将来更新或删除时,以及对任何特定于国家、语言或设备的重定向时,请使用302重定向。

应该避免元刷新和JavaScript重定向。尽管Google在爬行JavaScript方面做得越来越好,但并不能保证它们会被发现,或者将排名信号传递给新页面。

如果您想了解更多关于google如何处理不同类型重定向的信息,请请参阅约翰·米勒的帖子。

重定向映射过程

如果您足够幸运地处理不涉及URL更改的迁移,则可以跳过本节。否则,请继续阅读,以了解为什么迁移后无法在同一个URL上使用的任何遗留页面都应该被重定向。

重定向映射文件是包含以下两列的电子表格:

  • 旧站点URL->旧站点上的页面URL。
  • 新站点URL->新站点上的页面URL。

当将页面从旧站点映射(重定向)到新站点时,始终尝试将其映射到最相关的对应页面。在不存在相关页面的情况下,避免将页面重定向到主页。首先,将用户重定向到不相关的页面会导致用户体验非常差。谷歌已经声明,将页面重定向到不相关的页面将被视为软404,因此不会传递任何SEO值。如果无法在新站点上找到等效页面,请尝试将其映射到其父类别页。

映射完成后,需要将文件发送给开发团队以创建重定向,以便在启动新站点之前对这些重定向进行测试。重定向的实现是站点迁移周期中经常出错的另一个部分。

提高重定向映射过程中的效率

重定向绘图需要非常关注细节,需要由经验丰富的SEO执行。理论上,在小站点上的URL映射可以通过手动将遗留站点的每个URL映射到新站点上的URL来完成。但是在包含数千甚至几十万页的大型站点上,手动映射每个URL实际上是不可能的,需要引入自动化。依靠遗产和新站点之间的某些共同属性可以节省大量时间。这些属性可以包括页面标题、h1标题或其他唯一的页面标识符,如产品代码、SKU等。确保重定向映射所依赖的属性是唯一的,并且不会在多个页面中重复;否则,您将得到不正确的映射。

小贴士:在开始重定向映射之前,确保新站点的URL结构是100%完成的。没有什么比在新站点运行之前更新的URL更危险的了。当URL在重定向映射完成后被更新时,您可能必须在启动时处理不想要的情况,例如中断的重定向、重定向链和重定向循环。内容冻结应该早在迁移日期之前放置在旧站点上,因此在旧站点上发布新内容有一个断点。这将确保在重定向映射中不会遗漏任何页面,并保证旧站点上的所有页面都被重定向。

不要忘记遗留的重定向!

您应该掌握旧站点的现有重定向,以确保在为新站点准备重定向映射时考虑到它们。除非您这样做,否则站点当前的重定向文件很可能会在发布日期被新的重定向文件覆盖。如果发生这种情况,以前已经存在的所有遗留重定向都将不复存在,该站点可能会失去相当数量的链接公平性,其程度将在很大程度上取决于该站点遗留重定向的数量。例如,过去经历过几次迁移的站点应该有大量的遗留重定向,您不希望丢失这些重定向。

理想情况下,保存尽可能多的遗留重定向,确保与新站点的重定向结合时不会引起任何问题。强烈建议在此早期消除任何潜在的重定向链,这可以通过检查重定向映射电子表格中相同的URL是否同时显示为“Legacy URL”和“New Site URL”来实现。如果是这样的话,您将需要相应地更新“NewSiteURL”。

例子:

URL A重定向到URL B(遗留重定向)

URL B重定向到URL C(新的重定向)

这将导致以下重定向链:

URL A->URLB->URLC

要消除这种情况,请修改现有的遗留文件重定向,并创建一个新的版本,以便:

URL A重定向到URL C(修改后的遗留重定向)

URL B重定向到URL C(新的重定向)

专业提示:检查重定向映射电子表格中的重定向循环。当“Legacy URL”与“NewSiteURL”相同时,就会出现这种情况。需要删除重定向循环,因为它们会导致无限加载用户和搜索引擎无法访问的页面。必须消除重定向循环,因为它们是即时通信、转换和排名杀手!

实施总括重定向规则以避免重复内容

强烈建议尝试制定覆盖尽可能多URL请求的重定向规则。在Web服务器上实现重定向规则比依赖大量一对一的重定向要有效得多。如果您的重定向映射文档包含大量需要作为一对一重定向规则实现的重定向,则站点性能可能受到负面影响。无论如何,与开发团队反复检查Web服务器可以处理的最大重定向数,而不会出现问题。

无论如何,应该制定一些标准的重定向规则,以避免产生重复的内容问题:

  • URL大小写:所有包含大写字符的URL都应该被301重定向到所有小写URL。https://www.website.com/Page/应该自动重定向到https://www.website.com/page/
  • 主机:例如,所有的非www网址应该被301重定向到他们的www等值。https://website.com/page/应该重定向到https://www.website.com/page/
  • 协议:在安全的网站上,对HTTPURL的请求应该重定向到等效的HTTPS URL。http://www.website.com/page/应该自动重定向到https://www.website.com/page/
  • 尾随斜杠:例如,任何不包含尾随斜杠的URL都应该重定向到带有尾随斜杠的版本。http://www.website.com/page应该重定向到http://www.website.com/page/

即使一些标准的重定向规则存在于遗留网站上,除非明确请求,否则不要认为它们必然存在于新站点上。

避免内部重定向

尝试更新站点的内部链接,这样它们就不会触发内部重定向。尽管搜索引擎可以跟踪内部重定向,但不建议使用这些方法,因为它们会给页面加载时间增加额外的延迟,并可能对搜索引擎的爬行时间产生负面影响。

别忘了你的图像文件

如果网站的图片移到了一个新的位置,Google建议将旧的图像URL重定向到新的图像URL。帮助谷歌更快地发现和索引新图像。如果不容易重定向所有图像,目标是重定向至少那些有累积反向链接的图像URL。

第三阶段:发射前测试

越早开始测试,越好。有些事情需要完全实现才能被测试,但其他的则不需要。例如,用户旅程问题可以在原型或线框设计时就被识别出来。旧站点和新站点之间的内容相关问题或内容不一致(例如桌面和移动站点之间的内容不一致)也可以在早期阶段确定。但是,技术含量更高的组件只有在完全实现之后才能进行测试-比如重定向、规范标记或XML站点地图。越早发现问题,就越有可能在发布新站点之前解决这些问题。在稍后阶段确定某些类型的问题是不符合成本效益的,需要更多的资源,并造成严重的延迟。糟糕的测试和不允许所需的时间彻底测试所有可能影响SEO和UX性能的构建块,可能会在新站点运行后不久产生灾难性的后果。

确保搜索引擎无法访问暂存/测试站点

在使新站点在分阶段/测试环境中可用之前,请注意搜索引擎不对其进行索引。有几种不同的方法可以做到这一点,每一种都有不同的利弊。

可供特定IP使用的站点(大多数建议)

将测试站点仅供特定IP地址使用是防止搜索引擎爬行的一种非常有效的方法。任何试图访问测试站点的URL的人都将无法看到任何内容,除非他们的IP已被白化。主要的优点是白名单的用户可以很容易地访问和抓取网站,没有任何问题。唯一的缺点是,由于ip的限制,第三方网络工具(比如google的工具)不能被使用。

密码保护

密码保护的阶段/测试站点是另一种方式,以防止搜索引擎爬虫,但这个解决方案有两个主要的缺点。根据实现的不同,如果爬虫应用程序无法通过登录屏幕,就不可能爬行和测试受密码保护的网站。另一个缺点是:使用表单进行身份验证的受密码保护的网站可以使用第三方应用程序进行爬行,但也存在导致严重和意外问题的风险。这是因为爬虫点击页面上的每个链接(当你登录时),并且很容易地点击创建或删除页面、安装/卸载插件等的链接。

robots.txt阻塞

将以下代码行添加到测试站点的robots.txt文件将防止搜索引擎爬行测试站点的页面。

User-agent: * Disallow: /

这种方法的一个缺点是,即使出现在测试服务器上的内容不会被索引,但不允许的URL可能会出现在Google的搜索结果上。另一个缺点是,如果上面的robots.txt文件进入活动站点,将导致严重的去索引问题。这是我多次遇到的事情,出于这个原因,我不建议使用这种方法来阻止搜索引擎。

用户旅程回顾

如果网站已经重新设计或重组,很可能会在一定程度上影响用户的行程。由于缺乏用户数据,在新站点发布之前尽早检查用户行程是困难的。然而,经验丰富的用户体验专业人员将能够指出任何可能对网站转化率产生负面影响的担忧。由于现阶段的A/B测试几乎是不可能的,因此可能值得进行一些用户测试,并试图从实际用户那里获得一些反馈。不幸的是,用户体验问题可能是一些更难解决的问题,因为它们可能需要在站点范围内进行更改,这需要花费大量的时间和精力。

在全面的站点大修中,并非所有的UX决定都可以得到数据的支持,许多决策必须基于最佳实践、过去的经验和“直觉”,因此尽早让UX/CRO专家参与进来可能会在稍后产生红利。

站点架构评审

站点迁移通常是改进站点体系结构的一个好机会。换句话说,你有一个很好的机会重新组织你的关键字目标内容,并最大限度地发挥其搜索流量潜力。进行广泛的关键词研究将有助于确定最好的类别和子类别页面,这样用户和搜索引擎就可以在点击几下就到达网站上的任何页面-越少越好,所以你最终不会得到一个非常深入的分类。

识别具有良好交通潜力的新关键字并将它们映射到新的登陆页面可以对站点的有机流量水平产生很大的影响。另一方面,加强站点架构需要深思熟虑。如果重要的页面深入到新的站点架构中,或者有太多类似的页面为相同的关键字进行优化,那么ITT可能会导致问题。一些最成功的站点迁移是分配大量资源以增强站点体系结构的迁移。

元数据和副本审查

确保站点的页面标题、元描述、标题和副本已经从旧的转移到新的站点,没有问题。如果您已经创建了任何新页面,请确保这些页面是经过优化的,并且不要针对已经被其他页面锁定的关键字。如果您正在重新创建平台,请注意,外贸网站优化在创建新页面时,新平台可能具有不同的默认值。在没有适当优化页面标题或任何类型的缺失副本的情况下启动新站点将立即对您网站的排名和流量产生负面影响。不要忘记检查是否有任何用户生成的内容(即用户评论、评论)也已上载。

内部链接审查

内部链接是网站的骨干。无论网站的拷贝有多好的优化和结构,成功都是不够的,除非它得到了完美的内部链接方案的支持。必须审查整个网站的内部链接,包括以下链接:

  • 主次航行
  • 页眉和页脚链接
  • 正文内容链接
  • 分页链接
  • 横向链接(相关物品、类似产品等)
  • 垂直链接(例如,面包屑导航)
  • 跨网站链接(例如跨国际网站的链接)

技术检查

必须进行一系列的技术检查,以确保新站点的技术设置是健全的,并避免在新站点运行后遇到重大技术故障。

robots.txt文件审查

在暂存环境上准备新站点的robots.txt文件。这样,您可以测试它的错误或遗漏,并避免遇到搜索引擎爬行问题时,新的网站运行。站点迁移中的一个典型错误是robots.txt文件使用以下指令阻止搜索引擎访问:

Disallow: /

如果这被意外地转移到活动站点(而且经常是这样),它将阻止搜索引擎爬行该站点。当搜索引擎无法爬行索引页面时,与页面关联的关键字将在搜索结果中降级,最终页面将被取消索引。

但是,如果使用新站点的robots.txt指令填充暂存的robots.txt文件,则可以避免这种故障。

在准备新站点的robots.txt文件时,请确保:

  • 它不会阻止搜索引擎访问打算被索引的页面。
  • 它不阻止任何JavaScript或CSS资源,搜索引擎需要呈现页面内容。
  • 如果需要,对遗留站点的robots.txt文件内容进行了检查和结转。
  • 它引用新的XML站点地图,而不是任何不再存在的遗留站点地图。

规范标签评审

检查网站的规范标签。查找没有规范标记或具有指向另一个URL的规范标记的页面,并询问这是否有意。不要忘记爬行规范标记,以确定它们是否返回200个服务器响应。如果没有,则需要更新它们以消除任何3xx、4xx或5xx服务器响应。您还应该查找具有指向另一个URL的规范标记和noindex指令的页面,因为这两个是相互冲突的信号,您需要消除其中的一个。

元机器人评论

一旦您爬行了暂存站点,请查找将元机器人属性设置为“noindex”或“no追随者”的页面。如果是这样的话,请检查其中的每一个,以确保这是有意的,如果不是,则删除“noindex”或“no追随者”指令。

XML站点地图审查

准备两种不同类型的站点地图:一个包含所有新站点的可索引页面,另一个包含所有旧站点的可索引页面。前者将有助于谷歌了解新网站的可索引网址。后者将帮助Google意识到已经存在的重定向,以及一些索引URL已经转移到新位置的事实,这样Google就可以更快地发现它们并更新搜索结果。

您应该检查每个XML站点地图,以确保:

  • 它没有问题地验证。
  • 它被编码为utf-8。
  • 它不包含超过50,000行。
  • 其大小在未压缩时不超过50 mbs。

如果有超过50K行或文件大小超过50 MB,则必须将站点地图分解为较小的行。如果Google请求站点地图太频繁,这将防止服务器超载。

此外,您必须抓取每个XML站点地图,以确保它只包含可索引的URL。任何不可索引的URL都应排除在XML站点地图中,例如:

  • 3xx、4xx和5xx页(例如重定向、未找到页面、错误请求等)
  • 软404。这些页面没有返回200个服务器响应的内容,而不是404。
  • 规范化页面(除了自引用规范URL)
  • 具有元机器人noindex指令的页面

<!DOCTYPE html> <html><head> <meta name="robots" content="noindex" /> (…) </head> <body>(…)</body> </html>

  • HTTP头中带有noindex X-Robots-标记的页面

HTTP/1.1 200 OK Date: Tue, 10 Nov 2017 17:12:43 GMT (…) X-Robots-Tag: noindex (…)

  • 从robots.txt文件中阻塞的页面

构建干净的XML站点地图可以帮助监视新站点的真正索引级别。如果不这样做,就很难发现任何索引问题。

专业提示:下载并打开Excel中的每个XML站点地图,以获得任何附加属性的详细概述,如hcorang或图像属性。

HTML站点地图审查

根据正在迁移的站点的大小和类型,拥有HTML站点地图在某些情况下是有益的。HTML站点地图由未从站点主导航链接的URL组成,可以极大地促进页面发现和索引。但是,避免生成包含太多URL的HTML站点地图。如果您确实需要包含数千个URL,请考虑构建一个分段HTML站点地图。

嵌套站点地图的数量以及每个站点地图中应该包含的URL的最大数量取决于站点的权限。网站越权威,嵌套的站点地图和URL的数量就越多。

例如,NYTimes.com HTML站点地图由三个级别组成,其中每个站点地图包含超过1,000个URL。这些嵌套的HTML站点地图有助于搜索引擎爬虫发现自1851年以来发表的文章,否则将很难发现和索引,因为并不是所有的文章都是内部链接的。

纽约时报HTML站点地图(1级)

纽约时报HTML站点地图(2级)

结构化数据审查

结构化数据标记中的错误需要及早识别,因此在新站点启用之前有时间修复它们。理想情况下,您应该使用Google seo的结构化数据测试工具.

一定要检查桌面和移动页面上的标记,特别是当移动网站没有响应时。

该工具只报告任何现有错误,而不报告遗漏。例如,如果您的产品页面模板不包括ProductStructedDataSchema,则该工具不会报告任何错误。因此,除了检查错误之外,还应该确保每个页面模板都包含适合其内容类型的结构化数据标记。

请参阅google的文档,以获得最新的结构化数据实现和支持的内容类型.

JavaScript爬行审查

您必须测试新站点的每个页面模板,以确保Google能够抓取需要JavaScript解析的内容。如果你能够使用谷歌的抓取和渲染工具在你的分期网站,你一定要这样做。否则,进行一些手工测试,听从贾斯汀·布里格的建议.

如[医]巴托兹·戈拉勒维奇氏试验事实证明,即使Google能够爬行和索引JavaScript生成的内容,也并不意味着它能够在所有主要JavaScript框架中爬行JavaScript内容。下表总结了Bartosz的发现,表明一些JavaScript框架并不是SEO友好的,AngularJS目前是所有框架中问题最严重的。

Bartosz还发现其他搜索引擎(如Bing、Yandex和Baidu)确实存在。为JavaScript生成的内容建立索引,这是很重要的知道你的网站的流量是否依赖于任何这些搜索引擎。

希望随着时间的推移,这将有所改善,但随着JavaScript框架在Web开发中的日益普及,这必须在您的清单中占据很高的位置。

最后,您应该检查是否有任何外部资源被阻塞。不幸的是,这不是你能百分之百控制的事情,因为很多资源(比如JavaScript和css文件)都是由第三方网站托管的,这些网站可能会通过他们自己的robots.txt文件来阻止他们!

同样,提取和呈现工具可以帮助诊断这类问题,如果这些问题得不到解决,可能会产生严重的负面影响。

流动网站SEO检讨 资产阻塞审查

首先,确保robots.txt文件不会意外阻塞对移动站点内容呈现必不可少的任何JavaScript、CSS或图像文件。这可能会对搜索引擎如何呈现和索引移动站点的页面内容产生负面影响,而这反过来又会对移动站点的搜索可见性和性能产生负面影响。

移动第一索引审查

为了避免与谷歌的移动第一索引相关的任何问题,彻底检查移动网站,使桌面和移动站点在以下领域没有任何不一致之处:

  • 页面标题
  • 元描述
  • 标题
  • 复制
  • 规范标签
  • 元机器人属性(即noindex、no追随者)
  • 内部链接
  • 结构化数据

响应性网站应该在设备之间提供相同的内容、链接和标记,上面的SEO优化关键词属性在桌面和移动网站之间应该是相同的。

除此之外,您还必须根据移动站点的设置进行一些进一步的技术检查。

响应性现场审查

响应性网站必须为所有设备提供相同的HTML代码,根据屏幕大小(通过使用CSS)进行调整。

Googlebot能够自动检测这个移动设置,只要允许它爬行页面和它的资产。因此,确保Googlebot能够访问所有重要资产(如图像、JavaScript和CSS文件)是非常重要的。

为了向浏览器发出页面响应的信号,应该在每个HTML页面的中放置meta=“viewport”标记。

<meta name="viewport" content="width=device-width, initial-scale=1.0">

如果Metaviewport标签丢失,字体大小可能会以不一致的方式出现,这可能会导致google将页面视为不适合移动的。

单独的移动URL审查

如果移动网站使用与桌面不同的URL,请确保:

  1. 每个桌面页面都有一个指向相应的移动URL的标记。
  2. 每个移动页面都有一个rel=“规范化”标记,指向相应的桌面URL。
  3. 当移动设备上请求桌面URL时,它们被重定向到相应的移动URL。
  4. 将工作重定向到所有移动设备,包括Android、iPhone和Windows手机。
  5. 桌面和移动页面之间没有任何不相关的交叉链接。这意味着桌面页面上的内部链接只应该链接到桌面页面,而在移动页面上找到的链接应该只链接到其他移动页面。
  6. 移动URL返回一个200服务器响应。
动态服务评审

动态服务网站为每个设备提供不同的代码,但在相同的URL上。

在动态服务网站上,检查是否正确设置了不同的HTTP报头。这是必要的,因为动态服务网站为移动用户代理更改HTML和不同的HTTP头帮助Googlebot发现移动内容。

移动友好性审查

不管移动站点的设置(响应性的、单独的URL或动态服务),使用移动用户代理检查页面,并确保:

  1. 视图已正确设置。跨设备使用固定宽度的视图将导致移动可用性问题。
  2. 字体大小不太小。
  3. 触摸元素(即按钮、链接)并不太接近。
  4. 没有侵入间隙,如广告、邮件列表注册表格、应用程序下载弹出等.为了避免任何问题,您应该使用使用小型HTML或图像横幅.
  5. 移动页面加载速度并不太慢(参见下一节)。

谷歌的移动友好测试工具可以帮助诊断上述大多数问题:

谷歌的移动友好测试工具投入使用

安培地盘检讨

如果有AMP网站和桌面版本的网站,请确保:

  • 每个非AMP页面(即桌面,移动)都有一个指向相应的AMP URL的标记。
  • 每个AMP页面都有一个REL=“规范化”标记,指向相应的桌面页面。
  • 任何没有相应桌面URL的AMP页面都有一个自引用规范标记.

您还应该确保AMP是有效的。这可以使用Google的AMP测试工具.

混合内容误差

随着谷歌大力推动网站完全安全,Chrome成为第一个浏览器将HTTP页标记为不安全,目的是在HTTPS上启动新站点,确保通过安全的HTTPS连接请求所有资源,如图像、CSS和JavaScript文件。混合内容问题.

当通过安全HTTPS连接加载的页面通过不安全的HTTP连接请求资产时,就会出现混合内容。大多数浏览器要么阻止危险的HTTP请求,要么只显示阻碍用户体验的警告。

Chrome JavaScript控制台中的混合内容错误

识别混合内容错误的方法有很多,包括使用爬虫应用程序、Google的灯塔等等。

形象资产审查

Google抓取图像的频率低于HTML页面。如果将站点的图像从一个位置迁移到另一个位置(例如从您的域迁移到CDN),有一些方法可以帮助Google更快地发现迁移的图像。建一个图像XML站点地图会有所帮助,但你也需要确保Googlebot在爬行网站时能够到达该网站的图像。图像索引的棘手之处在于,出现图像的网页和图像文件本身都必须进行索引。

现场业绩审查

最后但并非最不重要的是,测量旧网站的页面加载时间,看看这些与新网站的比较,当这成为可用的中转。在这一阶段,重点关注与网络无关的性能方面,例如外部资源的使用(图像、JavaScript和CSS)、HTML代码和Web服务器的配置。有关如何进行此操作的更多信息可进一步了解。

分析跟踪审查

确保正确设置分析跟踪。这一审查最好由专家分析顾问进行,他们将超越跟踪代码的实施范围。确保正确设置目标和事件,实现电子商务跟踪,启用增强的电子商务跟踪等。没有什么比在你的新网站推出后没有分析数据更令人沮丧的了。

重定向测试

在新站点启用之前对重定向进行测试是非常关键的,以后可以为您节省很多麻烦。在暂存/测试服务器上检查重定向有许多方法,但底线是在没有测试重定向之前,您不应该启动新的网站。.

一旦重定向在暂存/测试环境中可用,请抓取重定向的整个列表,并检查以下问题:

  • 重定向循环(一个无限重定向到自身的URL)
  • 使用4xx或5xx服务器响应重定向。
  • 重定向链(重定向到另一个URL的URL,后者反过来重定向到另一个URL,等等)。
  • 返回4xx或5xx服务器响应的规范URL。
  • 标准循环(A页有一个规范指向页B,而正则指向页A)。
  • 规范链(指向另一个具有规范指向另一个页面的规范,等等)。
  • 协议/主机不一致,例如URL被重定向到HTTP和HTTPS URL或www和非www URL。
  • 前导/尾随空格字符。在Excel中使用TRIM()消除它们。
  • URL中的无效字符。

提示:确保旧站点的一个URL重定向到新站点上的正确URL。在这个阶段,因为新站点还不存在,所以您只能测试重定向目标URL是否是预期的URL,但这绝对值得。URL重定向并不意味着它重定向到正确的页面。

第四阶段:启动日活动
When the site is down...

而新的网站正在取代旧的,很可能是现场将暂时关闭。停机时间应保持在最低限度,但当这种情况发生时,Web服务器应该用503(服务不可用)服务器响应来响应任何URL请求。这将告诉搜索引擎爬虫该网站暂时关闭,以维护,所以他们回来,以爬行网站稍后。

如果网站在没有服务503服务器响应和搜索引擎爬行网站太长时间,有机搜索可见性将受到负面影响,一旦网站恢复不会立即恢复。此外,在网站暂时关闭的同时,它还应提供一个信息保存页面,通知用户该网站暂时关闭以进行维护。

技术抽查

一旦新网站投入使用,请快速查看:

  1. robots.txt文件,以确保搜索引擎不会被禁止爬行
  2. 顶部页面重定向(例如,对旧站点顶部页面的请求是否正确地重定向?)
  3. 顶部页面规范标记
  4. 顶级页面服务器响应
  5. noindex/no追随者指令,如果它们是无意的

需要在移动站点和桌面站点进行现场检查,除非站点完全响应。

搜索控制台操作

新网站一旦启用,应立即开展下列活动:

  1. 测试和上传XML站点地图
  2. 设置域的首选位置(www或non-www)
  3. 设定国际目标(如适用)
  4. 配置URL参数,以尽早解决任何可能重复的内容问题。
  5. 上传拒绝文件(如果适用)
  6. 使用地址更改工具(如果切换域)

贴士:对于每种不同类型的页面(例如主页、类别、子类别、产品页面),请使用“获取作为Google”的功能来确保Googlebot能够在没有任何问题的情况下呈现页面。检查任何报告的阻塞资源,并不要忘记使用抓取和渲染桌面和移动,特别是如果移动网站没有响应。

阻塞的资源阻止Googlebot呈现页面内容。

第五阶段:发射后审查

一旦新的网站投入使用,就应该进行新一轮的深入检查.这些基本上与“第三阶段:发射前测试”部分中提到的相同。

但是,这个阶段的主要区别是您现在可以访问更多的数据和工具。不要低估您在这个阶段需要付出的努力,因为您现在遇到的任何问题都会直接影响站点在SERP中的性能。另一方面,一个问题越早被发现,它就会越快得到解决。

除了重复第三阶段中概述的相同的测试任务之外,在某些领域,可以更彻底、更准确和更详细地进行测试。现在,您可以充分利用搜索控制台的功能。

检查爬行状态和服务器日志

注意搜索控制台中可用的爬行统计数据,以确保Google正在搜索新站点的页面。一般来说,当Googlebot遇到新页面时,它往往会加速它每天爬行的平均页数。但是,如果你在发布日期前后找不到一个尖峰,可能会对Googlebot爬行网站的能力产生负面影响。

在Google的搜索控制台上爬行统计数据

到目前为止,查看服务器日志文件是发现任何爬行问题或效率低下的最有效方法。像这样的工具Botify和论爬行可能非常有用,因为它们结合了爬行和服务器日志数据,并且可以突出显示页面,搜索引擎不爬行,没有链接到内部的页面(孤儿页面),低值的页面,严重的内部链接,等等。

定期检查爬行错误

注意报告的爬行错误,最好是每天在头几周。每天下载这些错误,爬行报告的URL,并采取必要的操作(即实现额外的301重定向,修复软404错误)将有助于更快的恢复。您不太可能需要重定向所报告的每一个404,但是您应该为最重要的404添加重定向。

专业提示:在GoogleAnalytics中,您可以很容易地找到最常见的404 URL请求,并首先修复这些URL!

其他有用的搜索控制台功能

值得检查的其他搜索控制台特性包括:阻塞的参考资料、结构化数据错误、移动可用性错误、HTML改进和国际定位(检查hcorang报告的错误)。

贴士:密切关注URL参数,以防它们导致重复的内容问题。如果是这样的话,考虑采取一些紧急补救行动。

现场测速

一旦新站点启用,请测量站点速度,以确保该站点的页面在桌面和移动设备上加载足够快。站点速度是跨设备的排名信号,并且因为缓慢的页面失去用户和客户比较新站点和旧站点的速度是非常重要的。如果新网站的页面加载时间似乎较高,您应该立即采取一些行动,否则您的网站的流量和转换几乎肯定会受到打击。

使用Google的工具评估速度

两个工具可以帮助这一点是谷歌的灯塔和佩格斯皮德洞察。

这,这个,那,那个Pagspeed Insight工具测量移动设备和桌面设备的页面性能,并根据Google从Chrome收集的用户数据显示真实的页面速度数据。它还检查页面是否已应用。共同绩效最佳做法并提供了一个优化分数。该工具包括以下主要类别:

  • 速度评分:使用两个指标将页面分类为“快速”、“平均”或“慢速”:第一个内容油漆(FCP)和DOM内容加载(DCL)。如果两个指标都位于其类别的前三分之一,则页面被认为是快速的。
  • 优化分数:根据性能净空将页面划分为好的、中等的或低的。
  • 页面加载分布:通过与Chrome用户体验报告中的所有FCP和DCL事件进行比较,将页面划分为快速(最快的第三个)、平均(第三个)或慢(第三个)。
  • 页面统计:可以指示如果开发人员修改页面的外观和功能,页面是否会更快。
  • 优化建议:可应用于页面的最佳实践列表。

谷歌的网页速度洞察行动

谷歌的灯塔非常方便移动性能、可访问性和渐进Web应用程序审核。它提供了各种有用的度量标准,可用于测量移动设备上的页面性能,例如:

  • 第一个有意义的绘图,它测量页面的主要内容何时可见。
  • “交互式时间”是指页面为用户交互做好准备的时刻。
  • 速度指数测量显示页面被明显填充的速度

这两个工具都提供建议,以帮助改进任何报告的站点性能问题。

谷歌灯塔行动

您也可以使用这个Google工具要粗略估计用户的百分比,您可能会失去您的移动网站的网页,因为缓慢的页面加载时间。

同样的工具还提供了一个行业比较,这样你就可以知道你离你所在行业中表现最好的网站有多远了。

从实际用户测量速度

一旦该网站已经运行,您可以开始评估网站的速度,根据用户访问您的网站。如果你有谷歌分析,你可以很容易地比较新网站的平均加载时间与前一个。

此外,如果您可以访问真正的用户监视工具,如,您可以根据访问您的网站的用户来评估站点速度。下面的地图显示了不同的访问者如何体验不同的加载时间取决于他们的地理位置。在下面的示例中,页面加载时间对于来自英国、美国和德国的访问者来说似乎是令人满意的,但是对于居住在其他国家的用户来说,他们要高得多。

第六阶段:测量站点迁移性能

何时测量

网站迁移是否成功?这是每个人都想知道的百万美元的问题,一旦新网站投入使用。在现实中,你等待的时间越长,答案就越清晰,因为最初几周甚至几个月的能见度可能会很不稳定,这取决于站点的大小和权威。对于较小的站点,在将新站点的可见度与旧站点的可见性进行比较之前,4-6周的时间应该足够了。对于大型网站,您可能需要等待至少2-3个月后才能进行测量。

此外,如果新站点与前一个站点有很大的不同,用户将需要一些时间来适应新的外观和感觉,并适应新的分类法、用户行程等等。这种变化最初会对网站的转化率产生重大的负面影响,几个星期后,随着返回的访问者越来越习惯于新网站,转化率应该会有所提高。无论如何,对新站点的用户体验做出数据驱动的结论是有风险的。

但这些只是一般的经验法则,需要与其他因素一起加以考虑。例如,如果在新网站启动后几天或几周进行了重大的额外修改(例如为了解决技术问题),则应进一步推迟对迁移的评估。

如何测量

性能度量是非常重要的,尽管业务涉众只想了解收入和流量的影响,但是还有很多其他的度量标准需要注意。例如,网站迁移后收入下降可能有几个原因,包括季节性趋势、品牌兴趣降低、UX问题,这些问题大大降低了网站的转化率、移动性能差、页面加载时间差等。因此,除了有机交通和收入数字外,还要注意以下几点:

  • 桌面和移动可见性(来自Searchics,SEMrush,Sistrix)
  • 桌面和移动排名(来自任何可靠的排名跟踪工具)
  • 用户参与(反弹率,页面平均时间)
  • 每一页类型的会话(即类别页是否驱动的会话与以前一样多?)
  • 每一页类型的转换率(即产品页是否与以前一样转换?)
  • 按设备划分的转换速率(即自新站点启动以来桌面/移动转换速率是否有所增加/下降?)

审查以下内容也非常方便,网站搜索引擎优化特别是从技术故障排除的角度来看:

  • 索引页数(搜索控制台)
  • 在XML站点地图中提交与索引页(搜索控制台)
  • 至少接受一次访问的页面(分析)
  • 网站速度(网页速度洞察,灯塔,谷歌分析)

只有在您了解了上述所有方面之后,您才能安全地得出您的迁移是否成功的结论。

站点迁移检查表

最新的站点迁移检查表可以从我们的网站下载。请注意,该清单定期更新,以包括所有成功的地点迁移的关键领域。

附录:有用的工具
爬行器
  • 尖叫青蛙:SEO瑞士军刀,理想的爬行中小型网站。
  • 硅球:非常直观的爬虫应用程序,具有整洁的用户界面、组织良好的报告和许多有用的数据可视化。
  • 深履带基于云的抓取器具有抓取暂存站点和进行爬行比较的能力。允许比较不同的抓取和处理与大型网站良好。
  • Botify:另一个强大的基于云的爬虫,由特殊的服务器日志文件分析功能支持,在理解搜索引擎如何爬行站点方面非常有洞察力。
  • 爬上:用于企业SEO审核的爬虫和服务器日志分析器具有许多方便的特性,以确定爬行预算、内容质量和性能问题。
手巧的Chrome附加组件
  • Web开发人员开发工具的集合,包括启用/禁用JavaScript、CSS、图像等的简单方法。
  • 用户代理交换机在不同的用户代理之间切换,包括Googlebot、Mobile和其他代理。
  • Ayima重定向路径一个伟大的标题和重定向检查。
  • 点击1次SEO Meta:页面上的元属性、标题和链接检查器.
  • 刮刀一种将网站数据抓取到电子表格中的简单方法。
现场监测工具
  • 正常运行时间机器人*免费网站正常运行时间监测。
  • 罗博托免费robots.txt监控工具。
  • 平模工具:监视站点的正常运行时间和实际用户的页面速度(朗姆酒服务)
  • SEO雷达*监视所有关键的SEO元素,并在这些更改时触发警报。
现场性能工具
  • 速度洞察*测量移动设备和桌面设备的页面性能。它检查页面是否已应用。共同绩效最佳做法并提供一个分数,从0到100分不等。
  • 灯塔方便的Chrome扩展功能,可访问性,渐进的Web应用程序审核。也可以从命令行运行,也可以作为节点模块运行。
  • Webpagetest.org来自不同位置、连接和设备的非常详细的页面测试,包括详细的瀑布图。
结构化数据测试工具
  • 谷歌的结构化数据测试工具 & Google的结构化数据测试工具Chrome扩展
  • Bing标记验证器
  • Yandex结构化数据测试工具
  • Google丰富的结果测试工具
移动测试工具
  • Google的移动性测试工具
  • Google的AMP测试工具
  • 放大器验证器工具
反向链接数据源
  • 阿赫菲
  • 雄伟的SEO

有需要seo报价的请咨询我们,本地的杭州seo嘉兴seo我们可直接上门服务

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