arunacharya1603/seo-engineering

SEO 工程技能

使命

協助專案透過讓有用頁面變得可被發現、可理解、符合搜尋資格、對使用者可信賴、技術上可靠且與商業成果連結，來獲得相關且永續的有機能見度與合格流量。

此技能是與專案無關的。請根據實際的業務、受眾、市場、CMS/框架、代管環境、搜尋引擎以及使用者的請求來調整。在檢視之前，請勿假設專案是 Next.js、部落格、電子商務、在地商家或特定領域。

沒有任何技術可以保證索引、豐富結果、AI 引用、流量、潛在客戶或排名位置。 搜尋引擎會自行選擇是否以及如何爬取、索引和排名頁面。請精確說明哪些是已測試的，哪些是推斷的。

不可協商的運作原則

1. 先稽核再編輯。 檢查儲存庫，並在允許存取的情況下檢查已部署的網站。找出已運作良好的部分。保留正確的配置和現有的 SEO 權益。
2. 以人為本，以證據為導向。 針對訪客的任務和業務相關性進行最佳化，而不是關鍵字密度、任意內容數量或核對清單完成度。
3. 最新文件為準。 針對因搜尋功能、結構化資料資格、垃圾政策、API、爬蟲或工具變更而受影響的主張，請查閱官方、最新的搜尋引擎文件。偏好使用 Google 搜尋中心、Bing 網站管理員文件以及官方框架/平台文件。社群文章可能提供假設，但不得凌駕於官方指引之上。
4. 最小化、可逆的變更。 做出能解決已驗證問題的最小實作。請勿重構不相關的程式碼、變更網域/DNS/名稱伺服器、輪換憑證、移除驗證權杖、變更代管環境，或未經明確授權就部署到正式環境。
5. 絕不偽造證據。 請勿憑空捏造關鍵字搜尋量、排名難度、反向連結、流量、競爭對手、索引狀態、效能衡量、作者資歷、評論、結構化資料事實或成功的測試結果。
6. 無排名保證或垃圾行為。 請勿推薦偽裝、隱藏關鍵字文字、關鍵字堆疊、入口網頁、大規模低價值內容、連結方案、虛假評論、誤導性的結構化資料，或其主要目的是操控排名的自動化內容。
7. 區分不同層面的問題。 可爬取性、可索引性、排名、搜尋結果中的呈現方式以及轉換是截然不同的。請修復相關的層面，而不是聲稱一個技術變更就能解決所有問題。
8. 保護敏感資料安全。 請勿在報告、提交記錄、日誌或產生的範例中暴露機密、API 金鑰、客戶資訊、分析識別碼或私人頁面。
9. 尊重現有架構。 在選擇實作方式之前，先了解技術堆疊、命名慣例、路由模型和部署流程。偏好使用既有的專案模式，而非引入新的依賴項。
10. 清楚說明不確定性。 如果無法進行外部存取、取得憑證、網路存取或正式環境測試，請說明哪些部分仍未驗證，並提供安全的手動檢查方式。

工作流程概述

對於重要的 SEO 任務，請遵循以下順序：

1. 了解網站和業務。
2. 建立基準並檢查實作。
3. 在必要時研究當前的搜尋引擎需求。
4. 產出優先順序清單的診斷和建議計畫。
5. 僅實作經過授權的必要變更。
6. 執行相關測試並檢查實際的渲染/部署行為。
7. 報告變更、證據、剩餘風險以及監控步驟。

對於一個集中的請求（例如，改善一個標題標籤），僅使用此工作流程中相關的部分，但仍需檢查副作用並避免提出未經證實的主張。

1. 探索專案及其目標

在建議程式碼之前，檢查儲存庫和部署線索。適用的情況下找出：

• 業務/網站目的、目標受眾、提供的服務、獲利模式、主要轉換目標以及地理/語言目標。
• 網站類型：資訊型、內容發布者、SaaS、市集、電子商務、在地商家、作品集、文件、論壇、出版商或混合型。
• 框架/CMS 及其版本、路由器、渲染策略、內容來源、套件管理器、建置/ lint /測試指令以及現有的 SEO 函式庫。
• 代管/CDN/邊緣運算設定、網域變體、重新導向、環境配置以及暫存環境 vs 正式環境。
• 路由類型：首頁、服務/類別、詳細頁面、部落格/文章、作者、搜尋結果、標籤/分類、分頁、篩選/分面 URL、產品變體、在地化路由以及錯誤頁面。
• 現有的分析和搜尋工具：Google Search Console、GA4 或其他分析工具、Bing 網站管理員工具、日誌存取、排名追蹤、爬取報告、轉換追蹤以及同意管理平台。
• 現有的技術決策：標準主機、Sitemap 策略、爬蟲規則、重新導向、結構化資料、hreflang、索引政策、中繼資料範本以及內部連結。

請勿要求儲存庫或已提供的上下文已能回答的資訊。如果無法確定關鍵事實，請帶著明確的假設繼續進行，或者當決策確實取決於該資訊時，提出一個簡潔的問題。

2. 基準化與爬取網站

使用適合環境的可用工具。偏好進行代表性的爬取和針對性的程式碼檢查，而不是僅根據檔案名稱做出假設。

儲存庫檢查

檢查相關檔案和原始碼路徑，包括但不限於：

• 套件/配置檔案、框架配置、代管/部署配置、中介軟體/代理和重新導向規則。
• 根層級和巢狀佈局、路由/頁面模組、中繼資料輔助函式、內容結構描述、CMS 配置、範本以及共享的導航/頁尾元件。
• sitemap.xml 或 Sitemap 產生程式碼、robots.txt、標準邏輯、重新導向以及 URL 建置輔助函式。
• 結構化資料產生器、圖片/影片元件、分析/同意設定以及 404/410 處理。
• 現有的測試和 CI 檢查。

請勿傾印 .env 值或其他機密。檢查所需變數是否存在，但不要列印其值。

即時網站檢查（在允許的情況下）

測試代表性的 URL 類別，並檢查回應和渲染後的 HTML。擷取：

• 狀態碼、重新導向鏈和最終 URL。
• Canonical 標籤、標題、Meta Description、爬蟲指令和爬蟲標頭。
• 原始 HTML 和（涉及 JavaScript 時的）渲染後 HTML 中的主要內容。
• 內部連結、Sitemap 包含情況、結構化資料以及明顯的重複版本。
• 行動版渲染、明顯的渲染失敗以及可取得的效能資料。

至少取樣首頁、關鍵轉換/服務頁面、主要列表頁面、代表性的詳細頁面、一篇部落格文章、一個類別/標籤/篩選頁面（如果適用）、一個有效的查詢字串 URL 以及一個不存在的 URL。對於大型網站，建立一個爬取樣本並按範本分組。如果您並未爬取每個 URL，請勿聲稱已爬取所有 URL。

基準證據

在進行變更之前，記錄可用的基準：按範本區分的 URL 數量、回應狀態分佈、可索引性、Canonical 一致性、Sitemap 錯誤、有機點擊/曝光/點擊率/排名位置、轉換、Core Web Vitals 以及相關的業務成果。請勿憑空捏造缺少的衡量指標。

3. 理性地確定問題優先順序

使用嚴重性和信心度，而不是模糊的 SEO 分數。一個實用的優先順序等級：

• P0 — 關鍵： 全站 noindex、意外的爬蟲阻擋、主要路由上的錯誤 Canonical、重新導向迴圈、正式環境中斷、大規模 5xx、遺失網域/URL 遷移、安全漏洞，或其他阻止重要頁面被存取/索引的問題。
• P1 — 高： 重要的金錢/內容頁面被封鎖、被錯誤 Canonical 化、從導航/Sitemap 中遺漏、未渲染出實質內容、回傳錯誤狀態碼，或存在系統性的範本缺陷。
• P2 — 中： 重要的中繼資料/結構化資料/內部連結/效能問題、孤立區段、重複頁面、內容覆蓋率不佳，或顯著的轉換障礙。
• P3 — 低/機會： 次要的文案改善、低影響的潤飾、可選的結構化資料、孤立的替代文字缺口，或投機性的內容機會。

對於每個發現，說明：證據、受影響的 URL/範本、可能的使用者/搜尋影響、信心度、實作工作量、風險、建議以及驗證方法。請勿將嚴重性等同於確定的排名變化。

4. 技術 SEO：爬取、索引、URL 和狀態碼

可爬取性和可索引性

• 區分爬取存取（robots.txt、伺服器回應、可達連結）、索引指令（noindex、Canonical 訊號、狀態）、Canonical 選擇以及排名。
• 確保重要的公開內容可透過正常的可爬取連結存取，並成功回應。
• 僅在有意的情況下使用 noindex。請記住，robots.txt 會阻止爬取；它不是從搜尋結果中移除 URL 的可靠方法，而且爬蟲通常需要先擷取頁面才能看到其頁面層級的 noindex 指令。
• 除非是經過驗證的有意封鎖，否則請勿禁止爬取渲染或理解重要內容所需的資源。
• 適當保護登入、帳戶、管理、結帳、內部搜尋、預覽、暫存和私人區域，使其不被搜尋引擎索引。使用授權機制保護私人內容；robots.txt 不是存取控制。
• 確保不存在的頁面回傳真正的 404 或 410 狀態碼，而不是 200 的軟 404。請勿將不相關的已刪除 URL 重新導向到首頁。
• 不要強制索引每個 URL。某些篩選器、內部搜尋結果、內容薄弱的標籤頁面、重複變體和工具頁面可能不值得索引。
• 將爬取預算最佳化視為對非常大或頻繁更新網站的特殊考量，而不是小型網站的例行公事。

Canonical 化和 URL 正規化

• 選擇一個與實際業務決策、網域配置和現有 SEO 權益相符的偏好協定/主機/路徑格式。請勿假設 www 或非 www 在本質上較優越。
• 對於真正的重複 URL，在適當的情況下，讓永久重新導向、Canonical 連結元素、內部連結、Sitemap URL 和結構化資料 URL 保持一致。
• 為每個可索引的頁面使用正確的絕對 Canonical URL。避免將不相關的內容或所有頁面都 Canonical 化到首頁。
• 將重新導向視為強烈的 Canonical 化訊號，將 rel="canonical" 視為強烈的訊號，並將 Sitemap 包含視為較弱的訊號。這些是訊號，而非絕對的指令。
• 保持 Canonical 目標可索引、可爬取、成功且相關。避免重新導向鏈和迴圈；使用直接重新導向到最終目的地。
• 不要盲目地移除合法的查詢參數。在正規化 URL 之前，請了解活動追蹤、篩選器、分頁、排序、產品變體和應用程式功能。
• 除非有明確的理由，否則保留現有的有價值 URL。

重新導向和錯誤

• 當 URL 已永久移動且平台正確支援時，使用永久重新導向（301 或 308）；對臨時狀況使用暫時重新導向。
• 僅根據預期的網站架構來測試 HTTP/HTTPS、www/non-www 以及結尾斜線的行為。
• 在主機名稱或協定正規化期間，保留路徑和有意義的查詢參數。
• 避免制定會攔截 API 端點、資產、子網域或不相關路徑的廣泛規則。
• 對於 URL 變更，在存在真正對應關係的地方，建立一對一的舊 URL 到新 URL 對應。將過時的 URL 重新導向到最接近的相關替代頁面，而不是一律導向到首頁。
• 在部署環境中驗證狀態碼和重新導向跳躍次數；僅靠本地配置並不能證明正式環境的行為。

JavaScript 和渲染

• 確認主要內容、頁面標題、中繼資料、Canonical 提示、連結和結構化資料都存在於可爬取/渲染的輸出中。
• 在適合技術堆疊和網站的情況下，使用伺服器端渲染、靜態生成或預渲染，但不要僅因為 SEO 的迷思而遷移框架。
• 使用正常的 <a href="..."> 連結使重要的導航可爬取。不要僅依賴點擊處理器或無法存取的應用程式殼層互動來進行發現。
• 不要依賴使用者互動、身分驗證或延遲的用戶端專屬效果來揭示必要的可索引內容。
• 避免初始 HTML 和 JavaScript 渲染後的 HTML 之間，在 Canonical 或爬蟲指令值上產生衝突。如果 JavaScript 變更了中繼資料，請檢查渲染後的輸出。
• 使用框架原生的中繼資料和路由系統，而不是透過衝突的機制複製中繼資料。

Sitemap XML

• 盡可能從真實的路由/內容來源產生 Sitemap。
• 僅包含應有資格被索引的偏好的 Canonical URL；排除重新導向、noindex URL、錯誤、私人頁面以及不相關的 URL 變體。
• 始終如一地使用絕對 URL 和偏好的主機/協定。
• 當符合資格的內容發布、更新或移除時，自動更新 Sitemap。
• 僅在實際有實質修改日期的時候才使用有意義的 lastmod 值；不要在每次部署時都更新每個日期。
• 遵守 Sitemap 協定限制；當規模或可維護性需要時，使用 Sitemap 索引和分段 Sitemap。多個 Sitemap 本身並不會改善排名。
• 驗證 XML 語法、回應狀態、內容類型、URL 數量以及樣本 URL。如果獲得授權，請檢查 Search Console 的 Sitemap 報告。
• 不要聲明提交 Sitemap 能保證爬取、索引或排名。

robots.txt 和指令

• 在編輯之前檢查現有的指令。除非它們是錯誤的或有明確記載的目的，否則保留規則。
• 在適當時加入 Sitemap 位置，並確保它是 Canonical 的 Sitemap URL。
• 區分 robots.txt 的爬取指令與 meta robots 和 X-Robots-Tag 的索引指令。

...（技術 SEO 下一個區段繼續）

（注意：由於原始內容被截斷，此處的翻譯也止於原始內容提供的相同位置。完整的技能文件應包含原始 SKILL.md 的其餘部分。）