有许多不同类型的迁移,但规划和故障排除的基本步骤是相似的。迁移可能非常复杂,因为它们通常涉及许多人和移动部件,如果一切没有完全按计划进行,请不要担心,你几乎可以修复任何出错的地方。
在本指南中,我们将介绍:
你需要知道会发生了什么变化以及需要谁参与才能使网站顺利搬迁,换句话说,需要一个人来计划和跟踪所有活动部件,需要了解所有相关人员、他们的角色、截止日期,并制定一个流程来跟踪所有事情。项目经理和项目管理系统对此会有所帮助,只试图在电子邮件和 Slack 中完成这一切可能会很快失控。
你会想知道迁移的影响,因此请确保可以访问旧站点和新站点上的 GSC 和 Analytics(如果需要查看两者,请创建组合的可视图)。有些变化可能需要几周甚至几个月的时间,你可能会看到变化,也可能根本看不到任何变化。举例来说,如果要将一个中型站点迁移到一个新域,我预计需要几周的时间。但是,如果要合并到现有的站点中,则可能根本看不到任何流量中断。
你还想做一些准备工作,我建议以下几个步骤:
- 抓取你的网站。你将使用它作为基线来检查之后的更改,你可以为此使用网站诊断。
- 创建一组测试页面。例如网站分析(Site Explorer)中热门页面(Top Pages)报告中的那些页面,之后你将使用这些来检查错误。你可能希望在单独的 Site Audit 项目中继续抓取这些内容,以便您以后可以轻松地比较它们。
- 限制对临时站或开发站点(如果有)的访问。以防止其被编入索引。
- 备份你的网站,以防万一需要还原它。
确切来说,网站迁移所涉及的内容取决于 URL 是否保持不变,下面我们将讨论这两种情况。
当网址相同时…
这通常是一个更直接的迁移(至少在 SEO 方面),因为只有少数事情正在改变,这可能仍然是一个复杂的迁移,但与这些举措相关的许多任务通常更多的是基础架构/DevOps 或开发人员的工作而不是 SEO。
这些迁移可能包括:
- 托管:CDN、服务器
- 平台:CMS、语言、JS框架
- 设计:模板、内部链接、标签
如果你使用的是临时站点或开发站点,最好在实时启动前访问以检查问题。
要找什么
为此,你实际上是在寻找所有更改,包括以下内容:
- Canonical 标签。这些必须相同。
- 标题标签。确保这些与你的相同或相似,新系统可能有自动生成标记或某些可能与你的有不同的默认值。
- Meta 描述
- Heading 标签
- Hreflang
- Schema
- Meta robots。确保页面没有被编入索引。
- 内容。这对于 JavaScript 系统至关重要,默认情况下,新系统可能不会将所有内容都加载到 DOM 中,因此在某些情况下搜索引擎可能看不到特定内容。
- 内部链接。面包屑、相关帖子、页脚链接,甚至主导航等内容都可能发生了变化。
- 速度差异
使用网站诊断(Site Audit)的比较功能查看自上次抓取以来的变化:
还有几个情况可能会造成更严重的问题。
- 如果不小心留下了禁止爬取的相关指令,搜索引擎将无法抓取你的页面。
- 有时旧的重定向不会从 .htaccess 文件或服务器配置文件中复制过来,你会遗失一些指向你网站的链接,这很棘手,因为它更难被注意到,而且经常在更换主机时发生。密切关注网站分析(Site Explorer)中的按反链数量排序(Best by Links)报告并过滤 404 页面以查看链接已损坏的页面。
当 URL 不同时…
这些迁移通常会更复杂,例外从 HTTP 迁移到 HTTPS — 如今这变的非常容易。
而这些迁移可能包括:
特定于 HTTP > HTTPS
- 使用升级不安全请求的内容安全策略来修复所有混合内容问题。除了内部链接相关的内容之外,它可以快速实施并适用于所有资源,不过仍然需要自行更新。
- 安装安全证书
- 301 重定向 HTTP > HTTPS
- 添加 HSTS 标头
我不会担心根路径上的重定向链或更新站点链接之类的事情,修复链和更新链接不会有任何好处,因为信号会因重定向而合并。
特定域改变
这里有一个给网站诊断(Site Audit)用户的快速提示:如果将项目设置中的爬网范围更改为不同的域,你的新爬网将在新域上,你能够将其与旧域上的爬网进行比较。
全部
- 更新内部链接和各种标签(如规范、hreflang 等)中的链接,可以使用查找和替换插件快速为内部链接执行此操作。
- 设置 GSC。这可能包括 disavow 的文件、设置地理定位、URL 参数设置和上传 sitemap 等内容。需要在短时间内保留带有旧 URL 的 sitemap。这将有助于监控 GSC 中 URL 的索引编制。
- 删除旧站点和新站点上页面的所有爬行禁止。一切都需要爬行才能正确整合信号。
- 确保要编入索引的页面未标记为 noindex。 您可以为此使用网站诊断(Site Audit)。
- 重定向页面。希望确保使用 301 重定向将旧页面重定向到新版本的页面,重定向图像和 PDF 之类的内容也是一个好主意,但不要担心 JS、CSS 或字体文件之类的内容。专注于重定向搜索引擎索引的内容,不要担心其他文件类型。
你希望有一个开发站点或临时站点,如果有开发站点或临时站点,则应更改到在线站点,以便进行网络访问以确保一切正常。请记住,如果旧站点使用 HTTPS 并且 证书日期,机器人会通过,但用户会收到错误消息并且不会被发现,有多个站点的多域证书可以防止此问题。
如果出现下降,则可能与用户、无法抓取索引的内容、未编入的内容、内容更改或删除内容、内部链接更改或与技术 SEO 相关的更改有关。
有多种方法可以查看迁移进度并确保一切都按预期进行。
透过 Ahrefs
有几种不同的方法来寻找变化,正如我之前提到的,可以在网站诊断(Site Audit)中更改爬网范围,并进行比较以显示更改的内容,需要注意以下方面的变化:
- Canonicals
- Hreflang。如果更改域,这将中断一段时间,因为重新抓取页面和建立连接需要一些时间。
- Schema
- Meta robots
还记得我们之前是如何创建热门页面列表的吗?这些是你的优先页面,很值得在网站诊断(Site Audit)中抓取该列表,以确保重定向等内容到位并且没有任何重大改变。如果提前为该列表设置了单独的项目,你甚至可以进行比较爬网以快速查看这些页面上的更改。
可以使用网站分析 2.0(Site Explorer 2.0)中的热门页面(Top Pages)和自然搜索关键词(Organic Keywords)报告获取页面流量、关键字流量和更改历史记录。对同一个域进行比较很容易,但如果更改了域,可能希望将此数据导出到 Excel 或 Google 表格,以便对不同时期进行组合视图,并查看可能发生的任何损失。
还可以使用我们的爬虫来确保您的重定向工作正常,并且链接正确重定向。
这是最简单的方法:
- 在网站分析(Site Explorer)中输入你的域
- 转到按反链数量排序(Best by Links report)
- 添加“404 not found”过滤器
- 按引用域排序
这将向你显示带有指向它们的链接的页面,这些我们的爬虫将其视为 404 的链接页面,你可能想要重定向这些。
透过 GSC
Google Search Console 有大量数据可帮助你进行迁移,例如,可以使用 URL 检查工具检查规范化问题,只需输入 URL,Google 就会告诉你他们选择的规范网址。
除此之外,可以导出 GSC 数据并在 Excel 或 Google Data Studio 中组合查看你的流量,以更好地观察迁移状况,你可能还想使用页面或关键字数据的组合视图来解决损失问题。
索引覆盖率报告可帮助了解你的页面是如何编入索引的,如果同时上传了旧的 sitemap 文件和新的 sitemap 文件,则可以在此处查看索引的变化并检查是否存在任何问题。通过拥有 sitemap 文件,可以获得仅针对这些 sitemap 中页面的特定覆盖率报告。
如果想查看 Google 抓取活动和任何已识别问题的概览,最好查看 Google Search Console 中的抓取统计报告,此处提供了各种报告,可帮助识别抓取行为的变化、抓取问题,并提供有关 Google 如何抓取你网站的更多信息。
你肯定想查看任何标记的抓取状态,例如此处显示的状态:
还有上次抓取页面的时间戳记。
其它
如果没有获得站点的基线抓取并且需要检查新旧之间的差异,请查看 archive.org 来寻找他们是否有任何页面的副本。他们通常还拥有来自站点的 robots.txt 文件副本,这些副本可用于查看是否出现问题并在此过程中被意外阻止。
如果无权访问某个网站的 Google Search Console,仍然可以通过在 Google 中粘贴 URL 来检查规范化,通常显示的第一页将是规范的。
同样,如果无权访问 GSC,则可以在日志文件中检查与抓取相关的许多其他问题。
只是一个小警告,『site:』的搜索运算符有时容易造成混淆,如果使用『site:』,是在询问 Google 对特定网站的了解程度。仅仅因为在那里看到页面并不意味着它们的索引方式或迁移存在问题。我已经看到这会导致人们做一些事情,像是阻止旧站点就为了将页面排除索引,而这会导致问题。
持续监测
有些问题可能会在迁移结束后很久才会出现。
- 监控旧域以确保它顺利更新,并对重定向到该站点的其他域执行相同操作。如果域过期,则任何通过旧站点重定向传递的信号都可能丢失。
- 如果还保有旧主机并保持重定向,请注意如果它关闭了重定向都会中断,你还将丢失一些链接,可以通过 DNS 重定向并将重定向存储在新站点上来解决此问题。
- 确保更新安全证书或切换到多域证书,正如我们之前讨论那样。
最后的想法
迁移网站并不容易,因此如果一切顺利,是时候庆祝一下了。但是由于这可能不是你最后一次进行网站迁移,因此我建议你再与相关人员相聚,讨论哪些地方做得好、哪些地方出了问题,以及如果重来一遍必须更改哪些地方。
还有任何问题吗?到 Twitter 上找我。
译者,李元魁,SEO 分解茶博客创始人