技術 SEO 審計 playbook
店舖的 SEO 問題更多是結構性而非編輯性的：爬取浪費、facet 混亂、孤兒商品、無效標記。審計的價值不在發現——在修復順序。
通用審計工具產出四百個問題和零個計劃。值得跑的店舖審計問的是更鋒利的一組問題——爬取預算是否花在能轉化的頁面上、收錄是否與目錄一致、標記是否通過校驗、店在用戶真實所在處是否夠快——並按流量風險排修復順序。這份 playbook 跑這場審計，以及更重要的，之後的分診。
階段一：爬取與收錄的現實
像搜索引擎那樣爬你的店，然後對比三個集合：存在的頁面、被爬的頁面、被收錄的頁面。缺口就是發現。吞噬爬取預算的 facet URL、沒有任何內鏈指向的孤兒商品頁、軟 404 的分類、多年換平台留下的重定向鏈——過了一定店齡的店四樣全有。
可爬 URL 清單對預期目錄——兩者的背離超出所有人預期
篩選導航：哪些組合可爬、可收錄、真正配得上
孤兒商品、重定向鏈與軟 404 逐一枚舉
按模板類型的收錄覆蓋——商品、分類、內容
階段二：卡住表現的那幾層
結構化數據按模板校驗——不是抽查，是校驗，因為一個模板錯誤會在使用它的每個頁面上倍增。渲染檢查：爬蟲收到的對你想提供的——腳本重的主題和 headless 架構上經典的無聲失敗。速度從按模板的實測數據讀。多語言店還有 hreflang 完整性。每層檢查起來機械，放著不修則昂貴。
階段三：按流量風險分診，然後按計劃複審
四百個問題按流量風險加權後，塌縮成一張短的有序清單：模板級修復最先（修一處、全目錄生效），然後是高價值頁面修復，然後是長尾。按此順序上線、在 Search Console 驗證、排上覆審——因為主題更新、應用安裝與目錄增長在持續再生技術債。審計是快照；計劃才是資產。
運作方式
爬取並對比
以引擎視角爬店；存在、爬取、收錄三集合做 diff，得出真發現。
校驗卡口層
結構化數據、渲染、實測速度與 hreflang，逐模板檢查。
按槓桿修復、按計劃複審
模板級先行、高價值頁面跟上、Search Console 驗證、按節奏重複。
你會得到甚麼
從 facet 噪音改道到收入頁面的爬取預算
與你實際售賣目錄一致的收錄
每個模板（而非大多數模板）都通過校驗的標記
被計劃抓住的技術債，而不是被流量損失抓住
由這些 Agent 負責
常見問題
店舖多久該複審一次？
全量審計每季度；易壞的層——結構化數據有效性、收錄覆蓋、速度迴歸——持續監控，因為它們在審計之間無聲地壞。任何換平台或重大主題變更之後：立即。
店舖最常見的單一發現是甚麼？
失控的篩選導航——成千上萬可爬的篩選排列稀釋爬取預算、複製內容。修它是模板級工作、全目錄生效，所以它通常排在分診首位。
流量看著不錯還需要審計嗎？
上漲的流量掩蓋結構浪費；審計告訴你沒認領的還有甚麼。而值得抓的失敗模式——一次錯誤 robots 改動導致的除名、主題更新導致的標記失效——要幾週傷害之後才通過流量顯形。
哪些 Agent 跑這個？
Visibility 負責爬取、校驗與分診；Ops 供實測速度數據；Builder 上線模板修復。複審節奏與最近的已知良好狀態存在共享記憶裏，迴歸是 diff，不是懸案。