使用这个 Python 工具对网站 SEO 问题进行自动化测试

SEODeploy 能够帮助咱们在网站部署以前识别出 SEO 问题。python

做为一个技术性搜索引擎优化开发者,我常常被请来协助作网站迁移、新网站发布、分析实施和其余一些影响网站在线可见性和测量等领域,以控制风险。许多公司每个月常常性收入的很大一部分来自用户经过搜索引擎找到他们的产品和服务。虽然搜索引擎已经能妥善地处理没有被良好格式化的代码,但在开发过程当中仍是会出问题,对搜索引擎如何索引和为用户显示页面产生不利影响。linux

我曾经也尝试经过评审各阶段会破坏 SEO(搜索引擎优化search engine optimization)的问题来手动下降这种风险。个人团队最终审查到的结果,决定了该项目是否能够上线。但这个过程一般很低效,只能用于有限的页面,并且颇有可能出现人为错误。git

长期以来,这个行业一直在寻找可用且值得信赖的方式来自动化这一过程,同时还能让开发人员和搜索引擎优化人员在必须测试的内容上得到有意义的发言权。这是很是重要的,由于这些团队在开发冲刺中优先级一般会发生冲突,搜索引擎优化者须要推进变化,而开发人员须要控制退化和预期以外的状况。github

常见的破坏 SEO 的问题

我合做过的不少网站有成千上万的页面,甚至上百万。实在使人费解,为何一个开发过程当中的改动能影响这么多页面。在 SEO 的世界中,Google 或其余搜索引擎展现你的页面时,一个很是微小和看起来可有可无的修改也可能致使全网站范围的变化。在部署到生产环境以前,必需要处理这类错误。web

下面是我去年见过的几个例子。数据库

偶发的 noindex

在部署到生产环境以后,咱们用的一个专用的第三方 SEO 监控工具 ContentKing 立刻发现了这个问题。这个错误很隐蔽,由于它在 HTML 中是不可见的,确切地说,它隐藏在服务器响应头里,但它能很快致使搜索不可见。数组

HTTP/1.1 200 OK
Date: Tue May 25 2010 21:12:42 GMT
[...]
X-Robots-Tag: noindex
[...]

canonical 小写

上线时错误地把整个网站的 canonical 连接元素全改为小写了。这个改动影响了接近 30000 个 URL。在修改以前,全部的 URL 大小写都正常(例如 URL-Path 这样)。这之因此是个问题是由于 canonical 连接元素是用来给 Google 提示一个网页真实的规范 URL 版本的。这个改动致使不少 URL 被从 Google 的索引中移除并用小写的版本(/url-path)从新创建索引。影响范围是流量损失了 10% 到 15%,也污染了将来几个星期的网页监控数据。服务器

源站退化

有个网站的 React 实现复杂而奇特,它有个神奇的问题,origin.domain.com URL 退化显示为 CDN 服务器的源站。它会在网站元数据(如 canonical 连接元素、URL 和 Open Graph 连接)中间歇性地显示原始的主机而不是 CDN 边缘主机。这个问题在原始的 HTML 和渲染后的 HTML 中都存在。这个问题影响搜索的可见性和在社交媒体上的分享质量。网络

SEODeploy 介绍

SEO 一般使用差别测试工具来检测渲染后和原始的 HTML 的差别。差别测试是很理想的,由于它避免了肉眼测试的不肯定性。你但愿检查 Google 对你的页面的渲染过程的差别,而不是检查用户对你页面的渲染。你但愿查看下原始的 HTML 是什么样的,而不是渲染后的 HTML,由于 Google 的渲染过程是有独立的两个阶段的。app

这促使我和个人同事创造了 SEODeploy 这个“在部署流水线中用于自动化 SEO 测试的 Python 库。”咱们的使命是:

开发一个工具,让开发者能提供若干 URL 路径,并容许这些 URL 在生产环境和预演环境的主机上进行差别测试,尤为是对 SEO 相关数据的非预期的退化。

SEODeploy 的机制很简单:提供一个每行内容都是 URL 路径的文本文件,SEODeploy 对那些路径运行一系列模块,对比生产环境production和预演环境staging的 URL,把检测到的全部的错误和改动信息报告出来。

SEODeploy overview

这个工具及其模块能够用一个 YAML 文件来配置,能够根据预期的变化进行定制。

SEODeploy output

最初的发布版本包含下面的的核心功能和概念:

  1. 开源:咱们坚信分享代码能够被你们批评、改进、扩展、分享和复用。
  2. 模块化:Web 开发中有许多不一样的堆栈和边缘案例。SEODeploy 工具在概念上很简单,所以采用模块化用来控制复杂性。咱们提供了两个建好的模块和一个实例模块来简述基本结构。
  3. URL 抽样:因为它不是对全部 URL 都是可行和有效的,所以咱们引入了一种随机抽取 XML 网站地图 URL 或被 ContentKing 监控的 URL 做为样本的方法。
  4. 灵活的差别检测:Web 数据是凌乱的。不管被检测的数据是什么类型(如 ext、数组或列表、JSON 对象或字典、整数、浮点数等等),差别检测功能都会尝试将这些数据转换为差别信息。
  5. 自动化: 你能够在命令行来调用抽样和运行方法,将 SEODeploy 融合到已有的流水线也很简单。

模块

虽然核心功能很简单,但在设计上,SEODeploy 的强大功能和复杂度体如今模块上。模块用来处理更难的任务:获取、清理和组织预演服务器和生产服务器上的数据来做对比。

Headless 模块

Headless 模块 是为那些从库里获取数据时不想为第三方服务付费的开发者准备的。它能够运行任意版本的 Chrome,会从每组用来比较的 URL 中提取渲染的数据。

Headless 模块会提取下面的核心数据用来比较:

  1. SEO 内容,如标题、H1-H六、连接等等。
  2. 从 Chrome 计时器Timings和 CDP(Chrome 开发工具协议Chrome DevTools Protocol)性能 API 中提取性能数据
  3. 计算出的性能指标,包括 CLS(累积布局偏移Cumulative Layout Shift),这是 Google 最近发布的一个很受欢迎的 Web 核心数据
  4. 从上述 CDP 的覆盖率 API 获取的 CSS 和 JavaScript 的覆盖率数据

这个模块引入了处理预演环境、网络速度预设(为了让对比更规范化)等功能,也引入了一个处理在预演对比数据中替换预演主机的方法。开发者也能很容易地扩展这个模块,以收集他们想要在每一个页面上进行比较的任何其余数据。

其余模块

咱们为开发者建立了一个示例模块,开发者能够参照它来使用框架建立一个自定义的提取模块。另外一个示例模块是与 ContentKing 结合的。ContentKing 模块须要有 ContentKing 订阅,而 Headless 能够在全部能运行 Chrome 的机器上运行。

须要解决的问题

咱们有扩展和强化工具库的计划,但正在寻求开发人员的反馈,了解哪些是可行的,哪些是不符合他们的需求。咱们正在解决的问题和条目有:

  1. 对于某些对比元素(尤为是 schema),动态时间戳会产生误报。
  2. 把测试数据保存到数据库,以便查看部署历史以及与上次的预演推送进行差别测试。
  3. 经过云基础设施的渲染,强化提取的规模和速度。
  4. 把测试覆盖率从如今的 46% 提升到 99% 以上。
  5. 目前,咱们依赖 Poetry 进行部署管理,但咱们但愿发布一个 PyPl 库,这样就能够用 pip install 轻松安装。
  6. 咱们还在关注更多使用时的问题和相关数据。

开始使用

这个项目在 GitHub 上,咱们对大部分功能都提供了 文档

咱们但愿你能克隆 SEODeploy 并试试它。咱们的目标是经过这个由技术性搜索引擎优化开发者开发的、通过开发者和工程师们验证的工具来支持开源社区。咱们都见过验证复杂的预演问题须要多长时间,也都见过大量 URL 的微小改动能有什么样的业务影响。咱们认为这个库能够为开发团队节省时间、下降部署过程当中的风险。

若是你有问题或者想提交代码,请查看项目的关于页面。


via: https://opensource.com/article/20/7/seodeploy

做者:JR Oakes 选题:lujun9972 译者:lxbwolf 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

相关文章
相关标签/搜索