使用這個 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，把檢測到的全部的錯誤和改動信息報告出來。

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

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

開源：咱們堅信分享代碼能夠被你們批評、改進、擴展、分享和複用。
模塊化：Web 開發中有許多不一樣的堆棧和邊緣案例。SEODeploy 工具在概念上很簡單，所以採用模塊化用來控制複雜性。咱們提供了兩個建好的模塊和一個實例模塊來簡述基本結構。
URL 抽樣：因爲它不是對全部 URL 都是可行和有效的，所以咱們引入了一種隨機抽取 XML 網站地圖 URL 或被 ContentKing 監控的 URL 做爲樣本的方法。
靈活的差別檢測：Web 數據是凌亂的。不管被檢測的數據是什麼類型（如 ext、數組或列表、JSON 對象或字典、整數、浮點數等等），差別檢測功能都會嘗試將這些數據轉換爲差別信息。
自動化: 你能夠在命令行來調用抽樣和運行方法，將 SEODeploy 融合到已有的流水線也很簡單。

模塊

雖然核心功能很簡單，但在設計上，SEODeploy 的強大功能和複雜度體如今模塊上。模塊用來處理更難的任務：獲取、清理和組織預演服務器和生產服務器上的數據來做對比。

Headless 模塊

Headless 模塊是爲那些從庫裏獲取數據時不想爲第三方服務付費的開發者準備的。它能夠運行任意版本的 Chrome，會從每組用來比較的 URL 中提取渲染的數據。

Headless 模塊會提取下面的核心數據用來比較：

SEO 內容，如標題、H1-H六、連接等等。
從 Chrome 計時器Timings和 CDP（Chrome 開發工具協議Chrome DevTools Protocol）性能 API 中提取性能數據
計算出的性能指標，包括 CLS（累積佈局偏移Cumulative Layout Shift），這是 Google 最近發佈的一個很受歡迎的 Web 核心數據
從上述 CDP 的覆蓋率 API 獲取的 CSS 和 JavaScript 的覆蓋率數據

這個模塊引入了處理預演環境、網絡速度預設（爲了讓對比更規範化）等功能，也引入了一個處理在預演對比數據中替換預演主機的方法。開發者也能很容易地擴展這個模塊，以收集他們想要在每一個頁面上進行比較的任何其餘數據。

其餘模塊

咱們爲開發者建立了一個示例模塊，開發者能夠參照它來使用框架建立一個自定義的提取模塊。另外一個示例模塊是與 ContentKing 結合的。ContentKing 模塊須要有 ContentKing 訂閱，而 Headless 能夠在全部能運行 Chrome 的機器上運行。

須要解決的問題

咱們有擴展和強化工具庫的計劃，但正在尋求開發人員的反饋，瞭解哪些是可行的，哪些是不符合他們的需求。咱們正在解決的問題和條目有：

對於某些對比元素（尤爲是 schema），動態時間戳會產生誤報。
把測試數據保存到數據庫，以便查看部署歷史以及與上次的預演推送進行差別測試。
經過雲基礎設施的渲染，強化提取的規模和速度。
把測試覆蓋率從如今的 46% 提升到 99% 以上。
目前，咱們依賴 Poetry 進行部署管理，但咱們但願發佈一個 PyPl 庫，這樣就能夠用 pip install 輕鬆安裝。
咱們還在關注更多使用時的問題和相關數據。

開始使用

這個項目在 GitHub 上，咱們對大部分功能都提供了文檔。

咱們但願你能克隆 SEODeploy 並試試它。咱們的目標是經過這個由技術性搜索引擎優化開發者開發的、通過開發者和工程師們驗證的工具來支持開源社區。咱們都見過驗證複雜的預演問題須要多長時間，也都見過大量 URL 的微小改動能有什麼樣的業務影響。咱們認爲這個庫能夠爲開發團隊節省時間、下降部署過程當中的風險。

若是你有問題或者想提交代碼，請查看項目的關於頁面。

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

做者：JR Oakes 選題：lujun9972 譯者：lxbwolf 校對：wxy

本文由 LCTT 原創編譯，Linux中國榮譽推出