TL;DR

  • 抓取層：先確認重要 URL 能被目標 crawler 發現並取得 200 回應，robots、權限、WAF 與 redirect 任何一關失敗，後面的內容優化都無法補救。
  • 索引層：被抓取不等於被索引，noindex、canonical、重複頁、參數頁與 sitemap 訊號必須共同核對，不能只看 sitemap 是否提交成功。
  • 渲染層：主要標題、正文、連結、FAQ 與商品資訊應在可取得的 HTML 中穩定出現，不能假設每個搜尋或 AI 系統都會完整執行 JavaScript。
  • 理解層：可見文字、實體名稱、內容類型與結構化資料必須一致，語法通過不代表系統就能正確理解頁面。
  • 引用層：技術基礎只能讓內容取得被理解與引用的資格，不能保證排名、AI citation 或商業成效。

一張 AI Search visibility 報表裡，最容易誤導團隊的欄位是「沒有被引用」。它描述的是結果，卻沒有說明問題發生在哪一層。頁面可能根本沒有被 crawler 取得，也可能被抓取後因 canonical 指向別處而沒有進入索引；還可能索引了空殼 HTML，真正的商品規格要等瀏覽器執行 API 才出現。

在參與客戶網站盤點時，會先把「看不到」改寫成可驗證的技術問題。AI Search 沒有讓 Technical SEO 消失；更務實的起點，是把抓取、索引、渲染、canonical、結構化資料與內容可存取性整理成有證據、owner 與驗收標準的診斷流程。

五個層次必須照相依關係檢查

技術盤點要按「可抓取、可索引、可渲染、可理解、可引用」前後排查，因為後一層建立在前一層之上。若 URL 回傳 403，先討論 FAQ schema 幾乎沒有意義；若 Google 選到另一個 canonical，改寫當前頁面的標題也未必能解決可見性問題。

層次 要回答的問題 最小驗收證據
可抓取 目標 crawler 能否發現 URL 並取得內容？ crawler 可存取、最終回應為預期狀態碼、沒有權限或 WAF 阻擋
可索引 平台是否允許並選擇這個 URL 進入索引？ 無意外 noindex、canonical 訊號一致、平台檢查結果指向預期 URL
可渲染 crawler 取得的頁面是否包含完整主要內容與連結？ 原始 HTML 與渲染結果的關鍵欄位可比對，JavaScript 錯誤有紀錄
可理解 系統能否辨識頁面主題、實體、關係與內容類型？ 標題、正文、連結與 markup 對同一事實表達一致
可引用 內容是否有資格與價值支持特定問題的答案？ 針對固定 query set 保存結果與引用位置，不把單次未引用當技術故障

這五層不是五個保證。Google 官方說明，搜尋與 AI features 沿用既有技術要求，符合要求仍不保證抓取、索引或顯示；OpenAI 也把 OAI-SearchBot 的搜尋發現用途與 GPTBot 的模型訓練用途分開。團隊要針對實際平台與 user agent 核對規則，不能把「允許一個 bot」寫成所有 AI 系統都會引用的承諾。

抓取先查入口、回應與阻擋層

抓取檢查的重點不是 robots.txt 有沒有檔案，而是重要 URL 從發現到回應的整條路徑是否暢通。我通常先選商品頁、分類頁、活動頁與知識文章各一組代表 URL，再用相同順序留下證據。

  • 檢查 robots.txt 對 Googlebot、Bingbot、OAI-SearchBot、PerplexityBot 等目標 crawler 的實際規則，避免只看 User-agent: * 就下結論。
  • 檢查 robots meta 與 HTTP X-Robots-Tag。robots.txt 管的是抓取；noindex 管的是索引，而且 crawler 必須能取得頁面才看得到 noindex。
  • 保存 HTTP status 與 redirect chain。重要頁應回到預期的 200 URL；連續轉址、loop、soft 404、5xx 與不同裝置結果不一致都要單獨記錄。
  • 用未登入狀態確認內容不受會員、地區、Cookie consent 或權限限制。若內容只有登入後可見，就不應假設公開 crawler 能取得。
  • 對照 CDN、WAF、rate limit 與 bot mitigation log。瀏覽器開得起來，不代表 crawler 沒有收到 403、429 或 challenge page。
  • 從首頁、分類頁或 topic hub 實際走到重要 URL，確認存在可爬的 HTML 連結。只在 sitemap 或前端搜尋框出現的孤兒頁，發現與重要性訊號都較弱。

OpenAI 最新 publisher 文件特別提醒，robots.txt 之外，WAF、CDN、authentication 與 rate limiting 都可能阻擋 crawler。這也是為什麼驗收不能只附一張 robots tester 截圖；工程 ticket 至少要包含測試 URL、user agent、時間、回應碼、response headers、redirect chain，以及相關 edge log。

索引要查平台選了哪個 URL

索引問題最常見的誤判，是把「已提交 sitemap」當成「已被索引」。Sitemap 是發現與偏好訊號，不是收錄保證；Google 也明確說明，sitemap 中的 canonical 偏好屬於較弱訊號，平台仍會根據內容與其他訊號選擇 canonical。

索引檢查應同時核對頁面的 robots meta、HTTP header、HTML canonical、redirect、站內連結、sitemap 與實際平台結果。電商網站尤其要注意排序、篩選、追蹤參數、分頁、相似商品與活動複製頁；若不同訊號各自指向不同 URL，平台選錯 canonical 並不意外。

我會要求索引 ticket 回答三件事：品牌想保留哪個 URL、目前各項訊號指向哪裡、平台實際選了哪一個 URL。修正後的 acceptance criteria 也不是「canonical tag 已上線」，而是原始碼、redirect、sitemap 與主要站內連結都一致指向預期版本，並在平台重新處理後保存檢查結果。

JavaScript 檢查要比較原始 HTML 與渲染結果

JavaScript 網站的風險不是「用了 JavaScript」，而是主要內容是否依賴不穩定的執行條件。Google 能渲染 JavaScript，但官方流程仍把 crawling、rendering 與 indexing 分成階段，也提醒 blocked resources、API 錯誤與不相容程式碼可能影響內容取得。其他搜尋或 AI crawler 的渲染能力與時程不應被假設成完全相同。

檢查時至少保存三份證據：初始 HTTP 回應的 HTML、一般瀏覽器完成渲染後的 DOM、平台 URL inspection 或 crawler 測試所看到的結果。接著逐項比對 H1、title、主要正文、商品名稱、價格或規格、FAQ、canonical 與內部連結。若初始 HTML 只有 root element，內容需等待 API、同意 Cookie 或 client-side route 才出現，就應把 API 回應失敗、console error、network waterfall 與缺少欄位的畫面一起放進 ticket。

管理上最穩健的做法，是讓關鍵事實與可爬連結在伺服器回傳或預渲染 HTML 中就存在，再用 JavaScript 增強互動。這不是要求所有網站改成純靜態頁，而是避免把搜尋可見性綁在使用者端執行成功這一個條件上。

內容可存取性比「畫面看得到」更嚴格

內容可存取性要檢查的是系統能否穩定取得完整文字與連結關係，不是人類操作幾次後是否看得到。重要資訊若藏在收合元件、頁籤、圖片、影片、登入牆、canvas，或點擊後才呼叫的 API，團隊要逐一確認未互動狀態下是否仍有可取得的文字替代與 HTML 關係。

例如，商品尺寸只印在圖片上，搜尋系統就難以把尺寸與商品實體穩定連結；FAQ 問題出現在 HTML，答案卻要點擊後才從 API 載入，也可能只留下半套內容。影片可以保留，但關鍵說明應有可讀文字；互動比較器可以保留，但核心規格不應只存在於 client-side state。

技術可存取與內容品質仍要分開。若系統已能取得完整內容，但頁面沒有回答使用者問題、事實過期或缺乏證據，owner 應從工程轉到內容或產品團隊。技術 SEO 的責任是確保內容有機會被取得與理解，不是替內容價值做保證。

結構化資料要和使用者看到的事實一致

結構化資料檢查不能停在「語法有效」。有效只表示格式可解析；是否符合平台支援規則、是否與頁面可見內容一致，以及是否正確描述實體與內容類型，才會影響辨識品質與風險。

商品價格、庫存、評分、作者、發布日期與 FAQ 若出現在 markup，就必須和頁面可見內容及後端事實一致。把已下架商品標成有庫存、把品牌自評寫成使用者評分，或在 JSON-LD 填入頁面不存在的 FAQ，都會建立錯誤訊號。Google 官方也明確表示，正確標記不保證顯示 rich result。

驗收時應把 schema validator、平台 rich result 測試、頁面可見內容與資料來源放在同一張檢查表。內容團隊負責確認事實，產品或資料 owner 確認來源，工程負責輸出與更新邏輯；不能把所有 schema 問題都丟給 SEO owner。

Sitemap、feed、lastmod 與站內連結是更新訊號

發現與更新要使用多個一致訊號，而不是尋找一個 AI 專用捷徑。XML sitemap 應只列可索引的 canonical URL，lastmod 應反映有意義的內容變更；RSS 或 Atom feed 可以協助支援它的平台發現近期更新，Bing 官方也接受 XML、RSS 與 Atom 等 sitemap 格式。IndexNow 能通知支援的搜尋引擎 URL 已新增、更新或刪除，但通知仍不等於保證收錄。

站內連結同樣重要。新文章若只出現在 feed，網站本身沒有任何分類頁、導覽或相關內容連到它，團隊失去的不只是 crawl path，也失去內容在網站架構中的關係。較好的驗收是：canonical URL 已進入 sitemap、更新時間可信、相關 feed 能讀取、站內有可爬連結，且平台後續能看到更新；不是「檔案已產生」就結案。

把工具結果改寫成可處理的故障票

有效的技術 SEO 專案，最小工作單位應是「症狀 → 證據 → 可能原因 → owner → 修正 → 驗收」。工具只是取得證據的方法，分數本身不能告訴團隊誰要改什麼。

欄位 應記錄的內容 範例
症狀 使用者或監測看到的結果 重要商品頁未被索引，AI Search query set 也未出現
證據 可重現的技術資料 URL、時間、user agent、403 response、edge log、HTML 差異
可能原因 尚待驗證的假設 WAF 將 crawler 判成自動化流量
Owner 有權修正的角色 Infrastructure／Security owner
修正 明確的設定或程式變更 調整規則並保留 rate limit 與安全邊界
驗收 可觀察的完成條件 指定 crawler 取得 200、主要 HTML 完整、log 無阻擋，平台重新處理

這個格式有兩個管理價值。第一，團隊不會因為「AI 看不到」就直接要求內容部門重寫文章；第二，工程也不會只交付「設定已修改」，卻沒有外部可觀察的結果。可能原因必須標成假設，驗收則必須是另一個人可以重現的證據。

一個電商盤點如何逐層排除問題

以下是一個依常見實務合成的匿名情境，不代表特定品牌成果。行銷團隊發現新品頁在多組 AI Search 問題中沒有出現，初步要求內容團隊增加 FAQ。SEO owner 沒有先改文案，而是從五層模型開始。

抓取層發現，一部分 crawler 對新品頁取得 403，但一般瀏覽器是 200；edge log 顯示 bot mitigation 規則誤判。修正後，crawler 能取得頁面。索引層再發現新品頁的 canonical 指向上一季活動模板，sitemap 與站內連結卻指向新品 URL；團隊統一訊號後提交重新處理。

渲染層接著發現，商品名稱已在初始 HTML，完整規格與 FAQ 卻要等 API 回應。工程改為讓核心規格在伺服器輸出，互動比較功能仍由 JavaScript 增強。理解層最後查到 JSON-LD 的庫存狀態來自舊 cache，和頁面可見狀態不一致，由產品資料 owner 修正更新邏輯。

完成這些工作後，團隊能證明頁面可抓取、canonical 一致、主要內容可取得、markup 與畫面相符。至於頁面是否被特定 AI Search 引用，仍要回到固定 query set 持續觀測；若技術條件都通過而內容仍未被採用，下一張 ticket 才應轉向問題對應、證據品質與內容治理。這個順序讓模糊的 visibility 問題，變成跨部門可以各自負責並共同驗收的工作。

Owner 分工要跟著證據走

跨部門協作的關鍵不是每個人都懂全部技術，而是每一層都有明確決策權。行銷與內容團隊定義重要頁面、目標 query 與預期事實；SEO owner 整合 crawl、index、render 與 citation 證據，安排優先級；產品與工程負責模板、資料、canonical 與渲染修正；Infrastructure 或 Security owner 處理 CDN、WAF 與 bot policy。

共同驗收時，不用「搜尋分數提高」作為唯一結論。應逐張關閉有可重現證據的 ticket，再分開觀察索引、自然搜尋、AI citation、referral 與商業轉換。只有這樣，技術修正、內容改善與平台波動才不會混成同一個 KPI。

AI Search 時代的技術 SEO，核心仍是讓正確內容能被正確系統穩定取得。把五個層次、六段故障票與跨部門 owner 建立起來，團隊就能知道下一步要修 robots、canonical、JavaScript、資料來源，還是內容本身，而不是對著一個「沒有被引用」的結果猜原因。

FAQ

AI Search 技術 SEO 應該先檢查什麼？

先確認重要 URL 對目標 crawler 可抓取，再依序檢查可索引、可渲染、可理解與可引用。最先保存 robots 規則、HTTP status、redirect chain、WAF log 與初始 HTML；抓取不通時，schema 或內容改寫都不是優先事項。

robots.txt 允許 crawler，就代表頁面會被 AI Search 引用嗎？

不代表。robots.txt 只處理特定 crawler 的抓取許可，頁面還要通過權限、WAF、索引、渲染、內容理解與答案選擇等環節。允許 OAI-SearchBot 或 PerplexityBot 有助於相應服務取得內容，但不能保證收錄、排名或引用。

Sitemap 提交成功，為什麼頁面還是沒有被索引？

Sitemap 是發現與 canonical 偏好訊號，不是索引保證。頁面仍可能有 noindex、錯誤 canonical、重複內容、低品質回應、權限阻擋或渲染問題；應對照平台實際選擇的 canonical 與 URL inspection 結果。

JavaScript 網站一定不利於 SEO 或 AI Search 嗎？

不一定。風險在於主要內容與連結是否必須依賴 client-side 執行、API、Cookie 或互動才出現。讓核心事實先存在於伺服器回傳或預渲染 HTML，再用 JavaScript 增強互動，通常更容易跨 crawler 穩定驗收。

結構化資料驗證通過，為什麼仍沒有 rich result 或 AI citation？

語法有效只表示 markup 可解析，不代表內容符合平台所有政策、與可見頁面一致，或足以支持特定答案。結構化資料應協助辨識實體與內容類型，但平台不保證 rich result，更不保證 AI citation。

技術問題修完後，如何驗收 AI Search visibility？

先用可重現證據驗收抓取、索引、渲染與資料一致性，再以固定 query set 記錄日期、平台、地區、答案與引用 URL。技術驗收與 citation 監測要分開，因為前者是網站可控制的條件，後者仍受平台與問題脈絡影響。

參考資料