用Hermes Agent執行JavaScript SEO：證據、分流與審查的團隊手冊

JavaScript SEO 聽起來像是只有工程師才需要理解的主題，但一開始要問的問題其實很生活化：這個頁面應該幫助訪客完成什麼？哪些內容和連結必須能被取得？伺服器回傳了什麼？頁面執行之後出現了什麼？還有哪些事實是我們不知道的？

Hermes Agent 適合用在這裡，因為 JavaScript SEO 調查包含多項不該混在一起的工作。一個角色可以記錄初始回應，另一個角色檢查已提供的渲染證據，第三個角色再把兩份報告整理成決策卡。至於是否要修改程式碼，仍然必須由人類負責人決定。

完成這套流程後，你會得到： 一份針對單一重要 URL 的一頁式個案檔案。每項發現都有具名證據，未知事項清楚標示，下一步則被限制在一個明確範圍內。這套流程不會證明 Google 已把頁面收錄、不承諾排名，也不授權 Agent 修改正式環境。

第一部分：給不寫JavaScript的人的JavaScript SEO入門

網頁是分階段交付的

開啟傳統 HTML 頁面時，許多有用內容可能已經存在於伺服器回應中。但對高度依賴 JavaScript 的網站來說，第一次回應可能只是起點。瀏覽器還會下載指令碼、請求額外資料、建立商品卡與導覽，並在初始 HTML 抵達後更新中繼資料。

這不代表頁面的 SEO 一定有問題。Google 能處理 JavaScript，許多現代網站也成功使用它。實務上的風險在於「不一致」：訪客最後可能看到完整頁面，但重要內容、URL 或頁面訊號在初始回應中不存在、被延後到互動之後、卡在失敗的請求後面，或以不容易被發現的形式呈現。

可以把頁面想成四個可觀察的層次：

這些層次回答不同問題。螢幕截圖顯示的是某個瀏覽器呈現的畫面，不是伺服器回傳內容。200 回應只表示成功交付，不代表已被收錄。渲染後 DOM 中出現穩定連結，也無法證明搜尋引擎已選擇該 URL 進入索引。

優先檢查六項訊號

初學者不必先學完整套前端框架，才能檢查頁面。從與發現及理解直接相關的六項訊號開始即可。

1. 狀態碼與重新導向。 有效頁面應回傳符合用途的狀態。不存在的商品不該偽裝成成功的空白頁面，重新導向則應避免混亂鏈條，並在正確目的地結束。
2. 主要內容。 頁面標題、核心說明、商品或文章資訊，以及其他定義頁面目的的內容，都應在相關頁面狀態中可用。若必須點擊或依賴不穩定請求才會出現，請記錄這項依賴。
3. 可爬取連結。 重要目的地通常應使用具有穩定 URL 的真正連結，例如帶有 href 的 a 元素。只靠事件處理器運作的可點擊卡片，對訪客可能有用，但發現路徑比較脆弱。
4. canonical 與 robots 指示。 canonical URL、robots meta、回應狀態、網站地圖與內部連結應講述一致的故事。canonical 是提示，不是命令，也不該用來掩蓋網站本來能防止的 URL 重複。
5. 漸進式載入。 延遲載入圖片、無限捲動、前端分頁不應讓有價值項目只能靠捲動、點擊，或沒有穩定 URL 的瀏覽器狀態才能取得。
6. 中繼資料與結構化資料。 由 JavaScript 產生的 title、description、canonical 與結構化資料，必須準確反映可見頁面。結構化資料能幫助理解，但不保證產生複合式搜尋結果。

渲染不等於收錄

釐清這個差異可以避免許多錯誤工單。渲染問的是系統能否處理頁面並取得預期內容。收錄問的是搜尋引擎是否選擇儲存該 URL，讓它有機會出現在搜尋結果。排名則關心它在何時、針對哪個查詢、出現在什麼位置。

一次瀏覽器操作不能證明三件事。如果唯一證據是一張截圖，誠實的結論可能是：「內容在這個瀏覽器狀態中出現；伺服器回應、搜尋引擎渲染及索引選擇仍未知。」這比「Google 看不到頁面」更有用，因為它直接指出團隊還缺少哪些證據。

檢查前先寫頁面故事

Agent 可以產生很長的檢查清單，卻仍錯過頁面的商業目的。因此要先寫一則簡短的頁面故事：

這則頁面故事會成為所有 Hermes 角色共用的簡報。人類負責人也能用一個簡單標準判斷：若某項發現不影響訪客任務或頁面訊號，它可能不該放入這個個案。

第二部分：把調查變成Hermes Agent團隊執行手冊

Hermes Agent 的公開文件介紹 agents、tools、skills、memory、automation 與 subagents 等概念，但實際工具與權限仍取決於部署環境。因此，這份手冊只定義輸出與邊界，不假設每個 Hermes 環境都能瀏覽 URL、執行指令、讀取程式庫或建立工單。

讓三個角色負責不同的證據工作

不要建立一個名為「修好 JavaScript SEO」的大型任務。把蒐集與解讀分開，再把解讀與行動分開。

你可以使用三個 subagent、三個依序執行的任務，或讓同一個 Agent 進行明確分隔的三個階段。重點不是增加 Agent 數量，而是讓每一次交接都能被檢查。

個案檔案會在技術決策前，持續分開顯示證據來源與不確定狀態。

建立共用的證據契約

偵察員開始前，先定義可使用的資料來源。若缺少輸入，必須標示為不可用，而不是用看似合理的答案填補。

你正在處理一個 JavaScript SEO 個案。

目標頁面：[URL 或已提供的頁面證據]
訪客任務：[一句話]
必要頁面元素：[清單]
允許的證據：[回應 HTML、渲染後 DOM、HAR、螢幕截圖、爬取匯出，
或程式庫檔案]
不可用證據：[清單]

保持唯讀。不得編輯檔案、發布內容、提交 URL、修改 CMS、傳送訊息、
建立工單，或存取未經明確授權的帳號。

每項觀察都要記錄證據來源，並使用其中一種狀態：
CONFIRMED、PLAUSIBLE RISK、UNKNOWN、OWNER DECISION。

沒有來自經授權來源的特定證據時，不得宣稱搜尋引擎已經收錄、渲染
或讓頁面取得排名。

預期輸出： 簡短的證據帳本。品質檢查： 每項觀察都有來源。復原方式： 若報告出現無來源結論，刪除那些列，並只用核准的證據清單重新執行該角色。

執行回應偵察員

回應偵察員描述頁面應用程式執行前收到的內容。依核准工具不同，它可以檢查儲存回應、爬取匯出或公開 URL。它應記錄以下事實：

• 已知重新導向後的最終 URL
• 可取得時的 HTTP 狀態
• 回應中的 title、canonical、robots 指示與語言訊號
• 定義頁面目的之內容是否存在
• 前往必要目的地的一般連結
• 從已提供原始碼看得到的指令碼與資料依賴
• 例如可收錄頁面 canonical 到其他 URL 的衝突

使用簡單表格輸出：

偵察員不能因內容不在回應裡，就直接建議伺服器端渲染。它找到的是一個條件，還不是原因或必要解法。

執行渲染偵察員

渲染偵察員檢查團隊實際能提供的完成頁面狀態，並與頁面故事和回應帳本比較。請它確認：

• 主要內容是否不需任意使用者操作就會出現
• 重要目的地是否以穩定連結表示
• 渲染後中繼資料或 canonical 是否改變
• 延遲載入項目是否需要捲動或互動
• 無限捲動是否提供穩定且可到達的頁面路徑
• 錯誤、空白或不可用狀態是否仍具意義
• 必要資料請求失敗時，內容如何變化

如果團隊只有截圖，偵察員不能檢查連結標記或中繼資料。有渲染後 DOM 卻沒有網路擷取，也無法解釋請求為何失敗。輸出必須註明這些限制。

讓分流編輯員保留不確定性

分流編輯員會合併兩份報告，但它的工作不是讓報告聽起來更確定，而是保留觀察、可能機制與缺少來源之間的差異。

優先順序應根據頁面影響與證據強度，而不是一項發現聽起來多技術。營收模板缺少主要商品連結，可能需要立即審查；沒有證據支持的框架偏好則不需要。

把一項發現做成核准卡

分流後，只選擇一項已確認或有充分支持的發現。不要把整份稽核直接送去實作。

發現 ID：JS-01
頁面與訪客任務：[URL 與一句話]
證據：[具體的回應、DOM 或程式碼觀察]
狀態：[CONFIRMED / PLAUSIBLE RISK]
訪客影響：[哪些內容可能難以到達或理解]
建議的最小行動：[一項範圍明確的變更或調查]
受影響模板或系統：[KNOWN / UNKNOWN]
驗收檢查：[本機行為、回應、渲染後 DOM、功能連結]
復原：[如何還原先前行為]
決策負責人：[姓名或職務]
實作狀態：WAITING FOR APPROVAL

範圍明確的核准卡，能把 Agent 發現轉成由指定負責人檢查的決策。

Hermes 能準備卡片，但不能擁有商業或工程決策。memory 與 automation 功能本身，也不會讓重大變更自動變得安全。

核准後使用獨立實作任務

負責人核准行動，而且 Hermes 環境有適當工具時，建立只包含核准範圍的新任務。不要默默把稽核任務變成寫入任務。

只實作個案 JS-01 中已核准的行動。

變更前，重新說明：
1. 受影響檔案或系統
2. 驗收檢查
3. 仍禁止的操作
4. 復原條件

變更後顯示精確 diff 或變更紀錄，並只執行核准測試。
不得部署、發布、提交 URL、修改無關檔案或擴大範圍。
若實際檔案或機制與核准簡報不同，請停止並把新證據交還負責人。

預期輸出： 一份可審查的變更紀錄。品質檢查： 不含無關檔案與操作。復原方式： 測試失敗或機制不同時，依核准方式還原並重新開啟個案。

分層驗證結果

Agent 說任務成功，不代表實作已完成。按照頁面交付順序驗證：

1. 本機行為： 頁面或元件可建置、訪客流程正常，而且無障礙與分析行為沒有被破壞。
2. 回應層： 狀態、重新導向、title、canonical、robots 指示與重要原始內容符合核准目標。
3. 渲染層： 必要內容與連結在相關頁面狀態中出現，且不依賴隱藏互動。
4. 搜尋證據： 經授權資料可用時，記錄 URL 檢查、爬取、日誌或 Search Console 實際回報內容。不要用本機渲染替代。
5. 決策紀錄： 儲存日期、證據、核准行動、測試結果、負責人與復原參照。

任何一層失敗時，不要用自信的摘要掩蓋。把失敗檢查與最小的下一項調查交回負責人。

可持續執行的Hermes每週流程

每週挑選一個具代表性且高價值的模板，而不是把大量 Agent 投入整個網站。

當多個頁面出現同一個已確認機制，再為受影響模板建立新的範圍個案。不要因一個 URL 就宣告全站缺陷。

常見失敗與復原方法

Agent產出重複報告

它們的任務重疊了。為每個角色提供不同來源清單與輸出契約。回應偵察員不解讀渲染行為，渲染偵察員也不重寫回應事實。

缺少資料時分流報告仍過度肯定

強制使用四種狀態標籤，拒絕沒有證據來源的列。Unknown 是有用結果，因為它告訴負責人下一步要索取什麼。

還沒找出錯誤就開始爭論SSR

回到頁面故事與已確認症狀。SSR、prerendering、hydration 調整與 client-only rendering 都是架構選項，不是通用解答。

排程任務開始製造雜訊

把範圍縮小到單一模板或已提供的 URL 清單。排程應產生包含日期、失敗與負責人的審查佇列；除非另行核准，否則不應修改內容或傳送外部訊息。

回應與渲染報告彼此不一致

這種差異常常正是調查重點。保留兩項觀察，不要挑比較好看的版本。例如原始碼沒有商品資訊，渲染 DOM 卻有；下一個問題就是渲染路徑是否可靠，以及結果是否仍提供穩定目的地。請索取最小的額外來源，例如已知回應擷取或核准爬取結果，不要把不一致直接當成失敗證明。

審查者想從一頁推論全站

單一 URL 可以提出模板假設，卻不能證明適用範圍。第一個個案找出可能共用的機制後，再增加第二個代表頁面。若第二頁不同，就拆成不同個案。這比宣告全面缺陷慢，但能避免為單一邊界情況啟動昂貴專案。

第一個完整個案範例

假設某分類頁有自然搜尋流量，但 SEO 同事發現商品卡很難稽核。頁面故事說訪客必須能比較商品並前往詳情頁。回應偵察員在已提供擷取中找到 200 回應與自我參照 canonical，但初始原始碼沒有商品名稱。渲染偵察員看到渲染後的名稱與價格，卻因擷取不完整而無法確認主要卡片操作是否是標準連結。

分流編輯員不該寫「Google 無法收錄商品」。可辯護的個案更小：

第一個決策可能只是核准檢查程式庫。若程式碼負責人之後確認卡片只使用點擊處理器，沒有穩定主要目的地，第二個決策再核准小型且可測試的元件變更。即使排名資料尚未改變，團隊已從焦慮式說法前進到可驗證的機制，這就是成功的 Hermes 流程。

常見問題

多個Hermes Agent可以平行檢查同一頁嗎？

可以，前提是它們有不同的唯讀角色、不重疊的證據來源與共用個案格式。不要讓多個 Agent 編輯同一個實作區域。

Hermes可以判斷Google是否收錄我的JavaScript頁面嗎？

不能只靠原始碼或瀏覽器畫面判斷。請提供經授權的 URL 檢查、爬取、日誌或 Search Console 證據，否則把收錄問題標示為 Unknown。

回應偵察員一定要瀏覽正式URL嗎？

不一定。只使用可用且已核准的工具與來源。在受限環境中，儲存回應或爬取匯出可能才是正確輸入。

原始碼缺少元素就一定需要伺服器端渲染嗎？

不一定。真正解法可能是穩定連結、正確狀態、可用資料路徑、一致中繼資料，或其他小型模板變更。先診斷機制。

初學者最適合的第一個Hermes任務是什麼？

對一個重要 URL 執行一個回應偵察員，要求提供含來源的事實表，再判斷是否需要渲染頁面證據。

作者：Julian Mercer，Auspia 的技術 SEO 實務工作者，擁有 14 年經驗。他專注於可爬取性、渲染、網站架構，以及讓 AI 容易讀取內容的技術基礎。