使用這個 Python 工具對網站 SEO 問題進行自動化測試

作為一個技術性搜索引擎優化開發者，我經常被請來協助做網站遷移、新網站發布、分析實施和其他一些影響網站在線可見性和測量等領域，以控制風險。許多公司每月經常性收入的很大一部分來自用戶通過搜索引擎找到他們的產品和服務。雖然搜索引擎已經能妥善地處理沒有被良好格式化的代碼，但在開發過程中還是會出問題，對搜索引擎如何索引和為用戶顯示頁面產生不利影響。

我曾經也嘗試通過評審各階段會破壞 SEO（ 搜索引擎優化 search engine optimization ）的問題來手動降低這種風險。我的團隊最終審查到的結果，決定了該項目是否可以上線。但這個過程通常很低效，只能用於有限的頁面，而且很有可能出現人為錯誤。

長期以來，這個行業一直在尋找可用且值得信賴的方式來自動化這一過程，同時還能讓開發人員和搜索引擎優化人員在必須測試的內容上獲得有意義的發言權。這是非常重要的，因為這些團隊在開發衝刺中優先順序通常會發生衝突，搜索引擎優化者需要推動變化，而開發人員需要控制退化和預期之外的情況。

常見的破壞 SEO 的問題

我合作過的很多網站有成千上萬的頁面，甚至上百萬。實在令人費解，為什麼一個開發過程中的改動能影響這麼多頁面。在 SEO 的世界中，Google 或其他搜索引擎展示你的頁面時，一個非常微小和看起來無關緊要的修改也可能導致全網站範圍的變化。在部署到生產環境之前，必須要處理這類錯誤。

下面是我去年見過的幾個例子。

偶發的 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 的渲染過程是有獨立的兩個階段的。

這促使我和我的同事創造了 SEODeploy 這個「在部署流水線中用於自動化 SEO 測試的 Python 庫。」我們的使命是：

開發一個工具，讓開發者能提供若干 URL 路徑，並允許這些 URL 在生產環境和預演環境的主機上進行差異測試，尤其是對 SEO 相關數據的非預期的退化。

SEODeploy 的機制很簡單：提供一個每行內容都是 URL 路徑的文本文件，SEODeploy 對那些路徑運行一系列模塊，對比 生產環境 production 和 預演環境 staging 的 URL，把檢測到的所有的錯誤和改動信息報告出來。


這個工具及其模塊可以用一個 YAML 文件來配置，可以根據預期的變化進行定製。


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

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-H6、鏈接等等。
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中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive