域迁移 SEO:Web 专业人士的清单
已发表: 2019-05-22迁移网站有很多很好的理由:
- 对于一些企业来说,这是一个安全问题。 一个很好的例子是需要迁移到 https 的 http 域。
- 对于其他人来说,这是在更改内容管理系统等内容的同时进行清理的问题。 如果您要从 Joomla 迁移到 Drupal,这也可能是迁移仍然重要的内容并为此做好计划的好时机。
- 对于某些组织来说,这是一个收购问题。 被收购的公司有时需要融入“母”域。
- 对于一些公司来说,是时候进行品牌重塑了,而域名是要改变的事情之一。
无论您迁移的原因是什么,您都需要了解所有域迁移都会带来一些风险,其中一些是良性的,另一些会破坏网站流量。
精心计划的迁移可以减轻这些风险。 它还使网站所有者可以更好地保留现有的搜索引擎推荐,或实际改善整体网站流量。
搬家前的基准测试
在规划迁移的更多技术方面之前,您需要挖掘许多东西以使用不同的工具。 这类似于在长途驾驶之前踢你的轮胎。 最好进入准备好的迁移项目。
每个网站都不同,但您可能需要以下项目的一些变化:
- 从Google Search Console导出一年的 Google 展示次数、点击次数和排名。 这将为您在移动后需要满足的搜索引擎存在建立基线。
- 从网站分析工具(如 WebTrends 或 Google Analytics)导出自然流量、总访问量、平均 404 错误数、跳出率和转换的月度统计数据。 得到这个至少一年为好。 如果您的工具具有实时功能,请感受一下工作日的并发流量,这样您还可以在启动后将其与新域进行比较。
- 如果您有调查工具(如 ForeSee 或 Qualaroo),请导出满意度,以及可以找到所需内容的人的百分比。
- 如果您的转化是表单提交而不是购买,请从您的营销自动化工具和/或客户关系管理 (CRM)中导出。
这些统计数据将为您提供定性和定量统计数据的混合对比。 为迁移收集一系列统计数据的优点之一是,如果出现问题,您将能够进行三角测量,并很快找出问题所在。
一些迁移可能有大量移动部件,大多数团队在迁移过程中可能会非常忙碌。 您需要优化识别和隔离问题所需的时间,这样就不会给已经很忙的团队增加太多压力。 这样,数据紧缩是在准备阶段,而不是在发布当天,所有团队都可能会被拉伸。
收集基线统计数据以隔离问题是所有营销人员在计划进行网站迁移时都应该做的事情。
规划不同类型的网站迁移
根据您要进行的迁移类型,您需要计划不同的任务。 您需要确定以下几点:
- 仅域更改与 URL 路径更改
- 相同内容或不同内容
- 新的内容管理系统 (CMS) 或相同的 CMS
- 新工具或相同工具
考虑到差异,让我们来看看您需要计划什么。
仅域更改与 URL 路径更改
仅域移动不会更改顶级域之后的任何字符串。 (这些是“路径”或“URL 路径”。)
例如,如果您的所有字符串(如/products/product1或/about/company )都不会更改,但您的域将从 domain.com 更改为 new-domain.com,那么您只有一个域更改。
域更改
- www.domain.com/ path1到www.new-domain.com/ path1
- www.domain.com/ path2到www.new-domain.com/ path2
- www.domain.com/ path3到www.new-domain.com/ path3
http 到 https 重定向也将被视为仅域移动。
相比之下,具有 URL 路径更改的迁移将意味着更改域之后的字符串。
域和 URL 路径更改
- www.domain.com/ path1到www.new-domain.com/ new-path1
- www.domain.com/ path2到www.new-domain.com/ new-path2
- www.domain.com/ path3到www.new-domain.com/newfolder/ newstringsfornewpath3
对于 URL 路径不变的迁移,通常有一些技术方法可以自动更改重定向的域字符串,而无需为网站上的每个页面编写一个重定向。
对于 URL 路径实际更改的迁移,将需要编写一些页面级别 301 重定向。 这肯定更麻烦。
如果对一个拥有成千上万个页面的站点进行信息架构更改,那么为所有内容编写页面级重定向可能是不可行的。 您可能需要确定流量阈值。 例如,您可能希望根据搜索引擎和总流量排名仅重定向前 5,000 个页面,而不是全部 175,000 个页面。
相同内容或不同内容
如果您在新域上有效地拥有与旧域上相同的内容,那么就内部链接而言,无需考虑太多事情,确保内容组仍然有意义等。
但是,如果您要添加或删除大量内容,则需要仔细映射。
- 您是否会更改任何类别,并且您会在此过程中“孤立”页面吗? 这些页面可能需要找到新家或折叠到其他页面中。 这需要成为你计划的一部分。
- 考虑到您的新内容,主菜单仍然有意义吗? 如果有重要页面的部分在移动后将更难到达,请考虑在内容更改后为它们提供额外的路径。
新的 CMS 或相同的 CMS
如果您要从www.example.com迁移到www.new-example.com并且您没有更改 CMS,那么内容的实际迁移应该非常简单。
如果您要从一个 CMS 切换到另一个 CMS,那么同样的移动可能不是一项简单的任务。 你需要……
- 确保旧站点上的布局和模板将得到新系统的合理支持。
- 确定是否有办法将您的 CMS 内容导出到新的内容管理系统将接受的内容中(即使这不是 100%,内容迁移的部分自动化也会有所帮助)。
- 为因 CMS 更改而手动进行的内容迁移部分留出时间。
新工具或相同工具
您的实际工具和部署工具的方式可能在旧域和新域之间有所不同。
你需要考虑几件事:
- 在新系统上,是否有一个母版页或类似于插件脚本的工具,无论是独立的还是作为标签管理工具的一部分? 或者您是否需要在整个站点中多次插入脚本? 如果是后者,请确保您有足够的时间。
- 如果您要从逐个工具的实施切换到像 Google 跟踪代码管理器这样的代码管理工具,请确保您有足够的时间来测试这种情况。 标签管理工具很有用,但它们可能需要时间来适应,这应该考虑到您的域切换时间表中。
- 如果您要添加工具,请确保您有时间进行回归测试。 您的新工具可能无法立即与旧工具很好地配合使用,您需要时间进行调试。
完成网站迁移计划
一旦您掌握了不同类型的站点迁移,就该设置站点迁移计划了。
让我们为一个相当复杂的场景构建一个示例,这样您就可以去掉不需要的部分。
假设您要从旧 CMS 迁移到新 CMS。 而且您在新站点上的信息架构会略有不同——一些 URL 路径将被移动到新位置。
从重定向的角度来看,您需要尽早做以下几件事:
1. 确保您有办法处理页面级 301 重定向
有多种方法可以设置“手动”页面级重定向。 其中一些涉及编辑配置文件,其他涉及将 XML 放入模块中,还有一些仍然具有处理此问题的基本 CMS 功能(假设您仍然可以访问旧 CMS)。 尽早确定你要走哪条路,这样你就可以避免头疼了。
2.检查您是否可以处理通配符或条件重定向
如果您能够调整 .htaccess 文件或类似的配置文件,则可以通过条件管理一些重定向,而不是单独设置每个重定向。 这将为您节省一些时间。
3. 导出旧网站首页
在总流量和自然流量之间进行选择,作为排名的决定因素。 (自然流量对此非常有用,因此您知道您将在迁移之前重定向实际驱动搜索引擎推荐的页面。)
- 考虑到网站的大小,选择一个有意义的阈值。 对于拥有 500 个左右 URL 的网站来说,前 100 个页面可能是最佳选择,因为其中大部分流量都来自前 80 个页面。 但是,对于具有数万个 URL 的站点,您可能需要前 5,000 个页面。
4. 将首页映射到新位置
这是一个手动步骤,您可以执行此操作以节省时间。 在电子表格上排列首页列表并将它们标记为旧 URL,然后在它们旁边添加新 URL。 当您知道要构建什么(如 XML 文件)时,您将拥有可以开始使用的文件。
301 重定向的好处
当您移至新域时,将 301(或“永久”)页面级重定向添加到您最有价值的页面可以完成两件事:
- 它将用户发送到正确的页面,以获得用户体验 (UX) 的好处
- 它告诉搜索引擎蜘蛛这一举动,以获得SEO 的好处
当您的网站只有一部分发生了信息架构更改时,您通常可以对仍然具有相同 URL 路径的网站部分进行条件或通配符重定向,并且只对较小的部分使用逐一页面级重定向绝对必要的用例数量。
例如,可能/product/下的所有内容在新站点上都更改为/products/ 。 您可以使用通配符替换来处理移动的那部分。 但是我们也假设/about/下的所有内容都有一个新的“路径”,所以/about/之后的实际字符串会改变。 对于/about/下的所有内容,您需要将旧 URL 映射到新 URL,并添加 301 页面级重定向。
这样,您就可以从旧域中获得链接权益转移的好处,而不会压倒管理重定向的团队。
避免常见的陷阱
域迁移失败的方式有很多种。
以下是您需要注意的一些常见问题:
1. 您可以使用的重定向工具对于切换来说不够健壮。
- 一些重定向工具只管理 http 的 URL,而不能处理 https 的。 因此,您需要找到其他方法来处理您的 https URL。
- 一些重定向工具是 CMS 的本机部分,需要大量时间来设置。 当您拥有数百或数千个 URL 时,这最终会出现问题。
- 一些重定向工具无法处理通配符,因此您需要计划手动重定向。 而且您需要考虑所需的额外时间。
成功的网站迁移依赖于营销人员充分了解他们可以使用的重定向工具,并且只为可能的事情进行规划。
使用上面列出的说明,尽早开始向您的开发人员说明可用的内容。
请注意在发布日之前您会遇到的限制。 如果有很多手动步骤,请预留足够的时间来处理这些步骤。
这确保了当切换之日到来时,该区域不会出现意外。
2.团队无法正确评估成功或失败。
如果团队没有建立要满足的基准——网站排名的搜索词、总有机流量、总访问量、网站上的满意度和成功率等——很难判断迁移是否顺利。
也许整体流量大致相同,但成功率开始下降。 也许满意度分数是相同的,但网站排名的搜索词更少,自然流量下降。
如果您没有查看一系列数据,则在网站实际受到打击时,域切换可能看起来很顺利。 表现不佳并认识到它比表现不佳并认为自己做得很好更可取。
确保您对网站的多个方面都有基准,以避免此问题。
3. 团队错过了重要的页面迁移。
对于信息架构发生变化的域,很容易丢失在搜索引擎上排名或从多个来源获得大量流量的页面。
如果没有人导出首页以确保所有这些都被迁移,那么团队通常会在迁移后看到流量下降。
如果发生这种情况,团队需要一起整理一份报告,并检查旧内容是否仍在某个文件中,以便将其转移到新域中,或者忍受流量损失。 这种类型的计划失败确实会损害整体流量。
您需要确保您已经查看了您的分析工具并导出了首页,并且在您拉动重定向触发器之前内容计划处于良好状态。
4. 任务量变得太多,团队无法处理
有许多事情可以改变域迁移所需的任务量。
该站点可能具有绝对链接而不是相对链接,并且您需要进行比您最初预期的更多的内部链接调整。
重定向工具可能无法支持通配符,您需要管理比计划更多的手动重定向。
您可能需要将非页面内容项目转移到新的 CMS,例如现场搜索的特色结果,并且您需要在发布后花时间处理它。
通常最好在切换发生时为站点分配一些额外的资源,这样当事情没有完全按计划进行时,您就有回旋余地。
管理切换当天的任务
假设所有重定向都按预期工作。
您想要移动的所有内容都已被移动。 您不会收到 404 错误峰值,您的所有工具都像以前一样触发,所有非页面内容配置都正确移动。
这是一个很好的开始,但它仍然在发布日为 SEO 任务留下了一些任务:
1. 在 robots.txt 上设置您的禁止条件
robots.txt 文件告诉搜索引擎蜘蛛他们应该和不应该在网站上抓取什么。
请与您的开发人员和 SEO 确认您已配置 robots.txt 文件,然后将其移过来。 如果你没有,至少要确保你的 robots.txt 文件不会是这样的:
- 用户代理: *
- 不允许: /
这种组合将告诉谷歌和其他搜索引擎不要索引您网站上的任何内容。 这是您应该尽量避免的情况。
2. 创建和验证新的 Google Search Console 帐户
建立新域后,您需要将其注册到 Google Search Console,并证明您拥有该域。 您可以使用多种方法来执行此操作,从删除 Google 将在根目录识别的文件到使用 Google 跟踪代码管理器。
- 为文件夹设置 Google Search Console 帐户。 验证域后,您可以将站点的部分添加为附加属性。 这将允许您执行一些操作,例如查看指向“产品”部分或“关于我们”部分的搜索(如果有的话)。 这将为您提供一个额外的层来检查您的自然流量是否在域迁移中幸存下来。
3.提交站点地图
根据您的内容管理系统,您可以从 CMS、爬网工具或通过记事本手动生成带有 URL 列表的站点地图。
您可以在这里做的一件事是为您网站的每个部分生成一个单独的站点地图(一个站点地图用于您的“产品”部分,一个站点地图用于“关于我们”等)如果 Google 索引您 90% 的产品页面但只有 5% 的关于页面,您会知道只修复索引不佳的部分。 只有在网站的每个部分都有单独的站点地图时,您才会看到该问题。
为不同的网站部分生成站点地图后,您应该通过 Search Console 将它们提交给 Google。
4. 告诉谷歌域名切换
即使是一些经验丰富的营销人员也错过了这一步骤。 Google Search Console 有一个工具可让您声明“地址更改”。 要使用它,您需要验证旧域和新域的 Google Search Console 属性,然后按照 Google Search Console 列出的步骤操作。
启动后监控统计信息
如果到目前为止您已经遵循了这篇文章中的建议,那么您将有定量和定性的基准进行比较。
- 调查工具数据。 满意度和人们找到所需内容的能力显着下降可能意味着网站的新结构可能会让访问者感到困惑。 您需要重新考虑新架构。
- 谷歌搜索控制台和分析工具数据。 404 错误的激增加上一些排名损失和自然流量下降通常意味着至少有一些重定向失败。 您需要调查重定向方法。
- 分析工具数据。 总流量和推荐流量显着下降而搜索引擎流量没有大幅下降可能意味着您没有移动其他网站链接到的内容。 您需要重新访问该内容。
交通的实时监控在这里也有帮助。 如果您网站上的同时访问者数量大大低于发布前的数据(例如,不到原来的一半),那么您就会知道有些事情不对劲,您需要深入挖掘。
在域迁移中没有过度准备
移动域可能是一个痛苦的过程。
对于您的网站,该过程有很多方法可能会很糟糕。 并且很少有通往成功的途径。
综上所述,如果您需要更改域,最好做好充分准备。 如果你 …
- 尽早了解您的重定向工具可以为您做什么,
- 痴迷于内容计划,直到你看不到任何漏洞,并且
- 使用数据管理过渡
…您有更好的机会无缝迁移到新域。
对于某些类型的搬家,如果你执着于计划,你甚至可能在切换后增加流量和转化。