用 Workbubby 執行 JavaScript SEO：以功能優先的安全網頁調查工作流程

AI 代理可以協助 JavaScript SEO，但前提是你先弄清楚它實際能做什麼。Workbubby 能讀取本機檔案嗎？能瀏覽公開網頁嗎？能檢查原始 HTML，或使用已完成轉譯的瀏覽器嗎？能執行指令嗎？能存取已連接的檢索匯出資料嗎？能建立票證、傳送訊息或排程工作嗎？這些答案會改變安全的工作流程。

光看代理產品的名稱，無法得知它擁有哪些權限。相似的代理產品可能採用截然不同的部署模式、工具、核准關卡、資料存取範圍與紀錄方式。這對 SEO 工作尤其重要，因為看似微小的操作也可能改動 CMS、robots 指示、網站地圖、部署內容或公開網頁。

完成本指南後，你會得到： 一張符合你實際 Workbubby 環境的功能卡、一份針對重要網頁的唯讀證據矩陣，以及一份經負責人核准的交接文件。本文不會假設 Workbubby 擁有終端機、瀏覽器自動化、Git checkout、連接器、排程器或發布功能。

第一部分：不靠猜測理解 JavaScript SEO

為什麼網頁看起來完整，仍可能留下 SEO 疑問

在 JavaScript 網站上，伺服器回傳初始回應後，還可能繼續執行指令碼、資料請求、用戶端路由與 UI 更新。瀏覽器會把這些部分組合成看似完整的網頁。搜尋系統仍必須找到 URL、提出請求、處理可存取的資源、理解連結與內容，最後決定要將什麼納入索引。

JavaScript 本身不是問題。真正的風險是：決定網頁用途的內容、穩定目的地或網頁訊號，仰賴了尚未驗證的步驟。商品網格可能依賴某些狀態下會失敗的請求；卡片可能只透過事件處理常式進行導覽；無限清單較深處的頁面可能沒有穩定 URL；缺貨項目也可能在用戶端顯示錯誤，但伺服器仍回傳成功狀態。

工作的重點是找出實際狀況，而不是責怪所使用的技術。

四個證據層次

「未知」是不可或缺的答案。如果 Workbubby 只能讀取附加的螢幕截圖，就無法檢查原始 HTML。如果它能瀏覽公開網頁，卻不能使用轉譯後的瀏覽器，就無法驗證動態內容。如果它能讀取程式碼庫檔案，卻沒有正式環境的證據，也不能聲稱今天線上 URL 實際回傳了什麼。

初次檢查的七個 JavaScript SEO 項目

URL 與回應行為

URL 是否抵達預期的最終網頁？是否回傳適當的狀態？重新導向是否直接且合理？用戶端重新導向或許對訪客有效，但不應掩蓋回應層的問題。

主要內容是否可用

先確認網頁上最重要的內容。商品分類頁可能是標題、商品、價格與目的地；文章頁可能是標題與內文。記錄這些內容是否已存在於提供的回應中、只在轉譯後出現、只在互動後出現，或根本不在現有證據中。

可檢索的目的地

重要目的地通常應以具有穩定 URL 的一般連結呈現。可以點擊的卡片不一定是可檢索連結。這不代表代理應該改寫標記，而是代表負責人應該檢查目前的實作方式。

Canonical 與 robots 是否一致

Canonical 與 robots 訊號應符合網頁預期的 URL 與可用狀態。Canonical 只是一項提示，不能修復重複或損壞的路由。Robots 指示與 robots.txt 都可能造成大範圍影響，因此不要自動修改其中任何一項。

片段導覽與用戶端路由

當目的地需要被個別探索時，#details 之類只有片段的路徑不能取代網頁 URL。History API 路由可以正常運作，但必須具備穩定、可路由的 URL，以及能正確處理直接請求的伺服器。

延遲載入與無限捲動

延遲載入不一定有害。要問的是：重要內容是否能在不依賴任意捲動或點擊的情況下被找到。對長清單而言，穩定的分頁或其他可檢索路徑，通常比假設捲動事件就足夠更安全。

中繼資料與結構化資料

Title、meta description、canonical、robots 與結構化資料應準確描述使用者看到的網頁。結構化資料只是輔助脈絡，並不保證 Google 會顯示複合式搜尋結果或提升網頁排名。

用網頁故事設定範圍

請代理展開調查前，先用幾句話說明網頁原本要完成的工作。

這能讓初學者得到比「檢查 SEO」更明確的起點，也會告訴代理哪些事情絕對不能做。

第二部分：先建立 Workbubby 功能卡

以正確產品名稱進行公開搜尋後，我們仍未找到能夠說明你所用環境中已啟用 Workbubby 功能的權威文件。因此，安全做法是功能優先：在交付任務前，先請 Workbubby 說明目前實際存在的工具、來源與核准界線。

只要求功能卡，不讓它採取行動

針對這項 JavaScript SEO 工作，只回報你目前可使用的功能。

請為每個項目標示：允許、不可用，或需要我的核准。
- 讀取本機專案檔案
- 瀏覽公開 URL
- 檢查原始 HTML
- 檢查轉譯後網頁
- 執行指令
- 存取已連接的工具或資料
- 建立或編輯檔案
- 建立票證或傳送訊息
- 發布、部署、提交 URL 或變更設定
- 排程重複工作

對每項允許的功能，以一句話說明來源或工具界線。
不要採取任何行動。不要根據產品名稱推斷功能。不要要求憑證，
也不要開啟未列出的連接器。

把回答和案例一起保存。功能卡不是官僚程序；它能避免把終端機代理用的提示詞套在只能處理附件的助理上，也能防止具備瀏覽能力的代理悄悄跨入可寫入的操作。

指派工作前，請先記錄你的 Workbubby 環境中哪些功能獲准、不可用或必須通過核准。

選擇與功能卡相符的調查路線

如果某項功能不存在，就修改工作流程，不要叫代理想辦法繞過限制。例如，不能瀏覽時附上回應擷取；沒有連接器時，向資料負責人要求匯出檔案。

在任務本身標示存取界線

功能卡只是某個時間點的快照。每個提示詞都要重複重要界線，以免舊任務或記憶擴大存取範圍。

核准的來源：[清單]
這項工作允許的功能：[清單]
不可用的功能：[清單]
禁止的行動：編輯、傳送、發布、排程、部署、提交 URL、變更設定，
或存取未列出的連接器。

如果答案取決於不可用的來源，請標示「未知」，並指出負責人可核准的
最小下一步檢查。不要試圖繞過界線。

第三部分：執行唯讀 JavaScript SEO 調查

一個網頁、一項訪客任務、一份證據清單

從小處開始。選一個具代表性的分類頁、商品頁、文章頁或地點頁，就足以測試範本機制。

只使用核准的來源，執行唯讀 JavaScript SEO 調查。

網頁：[URL 或網頁檔案]
訪客任務：[一句話]
必要內容與目的地：[清單]
核准的來源：[清單]
不可用的來源：[清單]

有證據時，檢查以下項目：
- 最終 URL、狀態、重新導向、canonical 與 robots 是否一致；
- 主要內容與網頁 title；
- 前往重要目的地的一般連結；
- 片段導覽與用戶端重新導向；
- 延遲載入與無限捲動；
- 中繼資料與結構化資料是否一致。

針對每個項目，回傳證據、狀態（已觀察／可能風險／未知）、
它對訪客任務的重要性，以及最小下一步檢查。

不要編輯、傳送、發布、排程、部署、提交 URL，或存取未列出的連接器。
不要捏造索引、排名、檢索資料或成效資料。

預期輸出： 一份觀察矩陣。品質檢查： 每一列都要列出來源，不能把無法進行的檢查寫成結論。復原方式： 刪除沒有依據的列；如果獲准，附上缺少的來源，只重新執行受影響的檢查。

以初學者角度閱讀矩陣

即使讀者不熟悉任何框架，也應該看得懂代理的說明。比較以下範例：

較好的報告會告訴負責人目前已知什麼、哪些部分仍不確定，以及下一步該問什麼。

將確認的觀察轉成負責人摘要

不要讓第一次檢查直接造成無人監督的變更。當觀察結果重要到需要升級處理時，準備一份精簡的交接文件：

「Workbubby 可能可以建立票證」並不代表已獲授權。負責人必須決定是否建立、建立在哪裡，以及可以包含哪些內容。

第四部分：讓自動化先通知，而不是直接修復

如果你的環境確認 Workbubby 可以排程工作，請從唯讀提醒或審查佇列開始。不要從 robots 編輯、部署、網站地圖變更、發布或 URL 提交開始。

安全的每週工作設計

按照核准的時程，只審查提供的高價值 URL 清單與核准的證據匯出資料。
為每個 URL 記錄執行日期、來源清單、觀察狀態與負責人。只有在這項工作
明確取得寫入權限時，才能在核准的目的地建立審查佇列。

不要編輯程式碼、變更設定、發布、部署、提交 URL、傳送外部訊息，
也不要推斷索引狀態。將缺漏或過期的證據標示為「未知」。

理想輸出是一個問題，而不是一次修復：

兩個分類 URL 的轉譯證據中看不到商品目的地。請確認 DOM 擷取內容，並指派前端負責人。

第一次自動化應產生可供審查的問題，絕不能直接在無人監督下變更網站。

加入升級核准關卡

代理工作遇到以下情況時，應停止並向指定的人要求核准：

• 要求編輯程式碼、CMS 內容、robots、網站地圖或設定；
• 在核准目的地以外建立票證、訊息或分享內容；
• 需要憑證、客戶資料或新的連接器；
• 發現與原始網頁故事不同的機制；
• 發現會影響樣本網頁以外的範本；
• 測試失敗或缺少復原路徑。

升級內容應包含證據與選項，而不是把建議包裝成已完成的行動。

維持小型審查佇列

這種佇列能讓責任與不確定性清楚可見，因此比塞滿未排序警告的儀表板更有用。

第五部分：驗證經人工核准的變更

如果負責人核准程式碼或設定變更，請使用符合實際環境的獨立實作流程。Workbubby 只能在功能卡與明確核准所確認的範圍內提供協助。

依順序驗證

1. 必要的訪客行為： 使用者能否完成網頁故事中的任務？
2. 回應行為： 最終 URL、狀態、重新導向、canonical 與 robots 訊號是否符合核准的目標？
3. 轉譯輸出： 必要內容與目的地是否出現在相關狀態？
4. 保留的行為： 鍵盤導覽、視覺狀態、分析與錯誤狀態是否仍正常運作？
5. 核准的搜尋證據： 稍後的檢查、檢索、紀錄或 Search Console 來源顯示了什麼？

任何單一測試都不能取代全部五項。瀏覽器測試不是索引證據，而乾淨的原始回應也不能證明轉譯資料一定成功。

在外部行動前定義復原方式

對經核准的變更，記錄確切的撤回條件。條件可能是功能測試失敗、分析事件中斷、無法存取的導覽路徑、錯誤的狀態，或超出預期的範本影響範圍。如果無法說明復原方法與負責人，這項行動還不適合無人監督的自動化。

記錄決策

保存證據清單、負責人的決定、變更紀錄、測試結果、日期與仍未知的項目。未來的代理應從這份紀錄開始，而不是重新產生沒有依據的診斷。

絕對不要假設 Workbubby 能做的事

由於研究期間未能確認這個特定產品設定的權威文件，因此不要假設 Workbubby 能夠：

• 執行終端機指令；
• 瀏覽或轉譯公開網站；
• 讀取 Git 程式碼庫；
• 存取 Search Console、分析資料或檢索資料；
• 建立工作、票證或訊息；
• 排程重複工作；
• 部署或發布；
• 以特定方式保護你的資料。

請在自己的環境中提出功能問題。這不是批評產品，而是安全操作任何可能因團隊而有不同設定的代理所必須採取的方法。

常見錯誤

把終端機代理提示詞複製到未知環境

代理可能沒有提示詞預設的工具，也可能擁有你不打算使用的寫入工具。請先從功能卡開始。

讓代理自行決定權限

代理可以回報可用工具，但特定工作中哪些工具與資料獲得核准，必須由人類負責人決定。

把瀏覽器螢幕截圖當成完整技術稽核

螢幕截圖是有用的證據，但無法確認回應狀態、原始 HTML、程式碼原因或索引狀態。請明確說明它能顯示與不能顯示的內容。

把排程變成安靜運作的自動修復系統

先從觀察與審查佇列開始。只有在存取範圍、核准行為、測試、負責人與復原方式都清楚後，才加入寫入行動。

把 Workbubby 稱為與 OpenClaw 相同的產品

除非你自己的文件證實兩者的關係，否則應視為不同產品。模式相似並不能證明工具、資料處理或權限相同。

常見問題

Workbubby 與 OpenClaw 是相同產品嗎？

除非你的部署文件另有說明，否則請視為不同產品。代理模式相似，不代表功能或安全行為相同。

我可以在 Workbubby 重複使用 Codex 或 Claude Code 的 skill 嗎？

應重複使用的是決策邏輯，而不是安裝前提。先確認你的環境能存取與核准什麼，再將流程轉換成 Workbubby 文件所描述的設定。

最安全的第一項 Workbubby 工作是什麼？

先要求功能卡，再讓它只使用你提供的來源，針對一個重要網頁建立唯讀證據矩陣。

Workbubby 能判斷 Google 是否已將網頁編入索引嗎？

只有當你的環境中經授權的搜尋來源提供這項資訊時才可以。單憑瀏覽器畫面、HTML 檔案或程式碼庫 checkout 無法確定。

最安全的第一次自動化是什麼？

使用核准輸入建立負責人審查佇列的唯讀提醒。第一次不要自動執行部署、發布、robots 變更或 URL 提交。

作者：Martin Hayes，Auspia 的 GEO Playbook Builder，已製作超過 200 份執行檢查清單。Martin 專注撰寫逐步工作流程、實戰指南與營運檢查清單。