官網上線前，建議依索引、metadata、結構化資料、AI 爬蟲可讀性、效能與量測六大類，逐一核對至少 25 個檢查項目——少做任何一類，都可能讓網站上線後不被 Google 或 AI 引擎完整收錄。以下每項都附上「為什麼要做」與「怎麼驗證」，其中幾項直接來自我們自己在 noise-and-signal.com 上線與稽核時踩過的坑，包含 Next.js metadata 合併陷阱、hreflang 代碼不一致，以及 sitemap 網址數與 Google 實際收錄數的落差。
索引（Indexing）
- Sitemap 涵蓋所有正式路由，並含 hreflang alternates：只有列在 sitemap 裡的網址才容易被完整爬取與索引，尤其是動態產生的頁面（如文章、案例）容易被遺漏。怎麼驗證：直接開啟
/sitemap.xml，確認筆數與實際頁面數量相符，並抽查幾筆是否帶有0標籤。 - robots.txt 對合法爬蟲逐條 allow，並明確排除後台與 API：籠統的
Disallow: /會連 SEO 與 AI 爬蟲一起擋掉；只排除真正不該公開的路徑，才不會誤傷收錄。怎麼驗證：用curl https://你的網域/robots.txt直接看規則清單，確認沒有整站擋爬蟲的設定。 - 每頁 canonical 標籤唯一且自我指向：canonical 設錯會讓 Google 把多個頁面判定為同一頁的重複版本，稀釋排名訊號。怎麼驗證：View Source 檢查
0，或用 Google Search Console 的「網址檢查工具」比對「使用者指定的 canonical」與「Google 選定的 canonical」是否一致。 - 提交 sitemap 後追蹤「已建立索引」與「排除」頁數的落差：sitemap 裡列了多少網址，不等於 Google 真的收錄多少頁；我們自己上線初期（GSC 資料範圍 2026-09-14~09-19）sitemap 有 114 個網址，Google 卻只認識 51 頁，其中已建立索引 30 頁、未建立索引 21 頁（3 頁「已檢索尚未索引（驗證失敗）」、18 頁「已找到尚未索引」）。怎麼驗證：Search Console「頁面」報表逐一核對「已編入索引」與「未編入索引」的原因分類。
- 語系自動偵測不要用 307 蓋掉非預設語系的 canonical 頁：next-intl 之類的框架預設會依
Accept-Language標頭做 307 轉址；Googlebot 通常不送這個標頭，但 ChatGPT-User、部分瀏覽器型抓取工具與 Lighthouse/PageSpeed Insights 會送，導致你的 zh-TW canonical 頁對它們「等於不存在」。怎麼驗證：用curl -H "Accept-Language: en-US" -I 0 307 轉址、回應是否缺少Vary: Accept-Language` 標頭。
Metadata
- 每頁 title 與 description 客製化，不共用同一組樣板：重複的 title/description 會讓 Google 在搜尋結果自動改寫，也削弱每頁鎖定的關鍵字。怎麼驗證：抽查 5-10 個不同頁面的 View Source，確認
0與1內容不同且對應該頁主題。 - 子頁的 openGraph／twitter 設定不要整個蓋掉父層：Next.js 的 metadata 是淺層覆蓋、不是深層合併——子頁若只回傳
openGraph: { url, images }，會讓繼承自父層的og:site_name、og:locale、og:type整組靜默消失，twitter物件也一樣。我們自己就踩過這個坑，後來統一改用單一buildPageMetadata()helper 讓全站頁面走同一套邏輯。怎麼驗證：View Source 檢查子頁的0與1是否還在，而不是只看該頁自己加的og:url/og:image。 - hreflang 代碼全站統一，不要
zh-TW與zh-Hant混用：我們自己在 2026-09-16 的稽核中就發現頁內0用的是zh-Hant，但 sitemap 與 HTTP Link header 卻用zh-TW，三處代碼不一致等於給搜尋引擎互相矛盾的訊號，後續才統一修正。怎麼驗證：同時對照頁內1、sitemap.xml與 HTTP 回應的Linkheader 三處代碼是否一致。 - 動態產生的 404 頁面也要有正確的
0：多語系框架某些版本的動態notFound()產生的原始 HTML 可能缺少lang屬性（這是上游框架的已知限制，我們評估後選擇接受，因為 404 頁本來就設定 noindex）。怎麼驗證：curl一個刻意打錯的網址，檢查回應 HTML 的1標籤是否帶有lang屬性。
結構化資料（Structured Data）
- Organization JSON-LD 填齊法人資訊與 sameAs：包含
legalName、統一編號、地址、sameAs等欄位，是讓搜尋引擎與 AI 辨識「這是哪一家公司」的基礎資料。怎麼驗證：用 Google 的 Rich Results Test 貼上首頁網址，確認 Organization 被正確解析且沒有缺漏欄位警告。 - FAQPage／HowTo／Article schema 對應到正確的內容頁型態：型態放錯或欄位不全，結構化資料等於白做——Google 不會因為你「有放」JSON-LD 就給予額外評價，還是要看是否符合規範。怎麼驗證：逐頁跑 Rich Results Test，確認沒有「缺少必要欄位」或「無效項目」的警告。
- 多層頁面加上 BreadcrumbList：讓搜尋結果能顯示頁面在網站中的路徑層級，也強化頁面之間的語意關聯。怎麼驗證：Rich Results Test 或 View Source 檢查
0內BreadcrumbList的itemListElement順序是否正確對應實際頁面路徑。 - 結構化資料要看「完整度」，不是只看「有沒有放」：我們自己的網站在 Organization、WebSite、Service、Article、HowTo、FAQPage、Person、DefinedTermSet 等多種類型都已建置 JSON-LD，但 2026-09-16 稽核時「結構化資料」這一類仍只拿到 50/100 分——型態覆蓋率高，不代表這一類就能拿高分。怎麼驗證：除了 Rich Results Test 的「通過/警告/錯誤」，也要對照 Google 結構化資料官方文件 逐一核對必填與建議欄位。
AI 爬蟲（AI Crawlers）
- robots.txt 明確 allow 主流 AI 爬蟲的 User-Agent：不主動擋，才有機會被 GPTBot、ChatGPT-User、ClaudeBot、anthropic-ai、PerplexityBot、Google-Extended 等爬蟲讀取進而被引用。我們自己的 robots.txt 對 GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、anthropic-ai、PerplexityBot、Google-Extended、Amazonbot、Applebot-Extended、Cohere-ai、CCBot、Bingbot、DuckAssistBot、Meta-ExternalAgent、Bytespider 逐一設定 allow「/」，只排除
/admin與/api/。怎麼驗證：curl https://你的網域/robots.txt，逐條比對你想開放的 AI 爬蟲 UA 是否都被 allow。 - 提供
/llms.txt摘要與更完整的全文版：依規格網站的說明，llms.txt是一份提案（並非 W3C 或 IETF 標準），用一份 Markdown 檔提供給大型語言模型閱讀的背景說明與連結，已有數千個網站發佈（2026 年 9 月查證）。我們自己提供/llms.txt，並另外提供收錄完整內容的/llms-full.txt。怎麼驗證：直接開啟/llms.txt，確認它有分節內容（grep -c "^##"）而不是空的樣板檔。 - 支援 Markdown 內容協商，讓 AI agent 更省 token 抓取內容：若 AI agent 以
Accept: text/markdown請求頁面，我們自己的文章頁面透過 middleware 把這類請求 rewrite 到專屬的/md/[locale]/[slug]路由，回傳乾淨的 Markdown 而非完整 HTML。怎麼驗證：curl -H "Accept: text/markdown" https://你的網域/insights/文章slug，確認回應是純文字 Markdown 而不是 HTML。 - 不要迷信「有特殊 AI schema 就會被引用」：Google 官方明講，要出現在 AI Overviews 或 AI Mode「不需要建立新的機器可讀檔案、AI 文字檔或標記」，也「沒有額外的技術要求」——換句話說，該做好的還是標準 SEO 的索引資格與內容品質。怎麼驗證：對照 Google 官方文件（2026 年 9 月查證），確認自己是先把一般索引狀態做好，而不是只檢查有沒有 llms.txt。
效能（Performance）
- 用行動裝置模擬跑一次效能測試並存檔：載入速度直接影響使用者體感；上線前沒量過，改版後就無法比對進退步。怎麼驗證：用 PageSpeed Insights 或 Lighthouse（mobile 模擬）跑一次，記錄 LCP、TBT、CLS 等數字存檔備查。
- 找出真正拖慢 LCP 的元凶，不要只猜是圖片：我們自己 2026-09-16 稽核當下（Lighthouse 13.4.1 mobile 模擬）首頁 LCP 5.9 秒、文章頁 LCP 5.3 秒，真正原因不是圖片，而是背景動畫元件在每頁掛載時吃掉主執行緒 650-1100 毫秒，以及文章內文的淡入動畫讓伺服器端渲染出的文字維持
opacity:0直到 hydration 完成才顯示。修正後（改用requestIdleCallback延後掛載動畫、內文淡入排除首屏）線上實測首頁 LCP 降到 2.5 秒、文章頁降到 2.3 秒。怎麼驗證：Lighthouse 報告裡的 Diagnostics／elementRenderDelay細項，或用 Chrome DevTools 的 Performance 面板實際錄一次載入過程，確認耗時卡在哪個階段。 - 尊重使用者的減少動態偏好設定：裝飾性動畫如果不尊重
prefers-reduced-motion，除了體驗問題也是白白消耗的效能。我們自己的背景動畫元件偵測到這個偏好設定時會直接跳過掛載。怎麼驗證：Chrome DevTools 的 Rendering 面板勾選「Emulate CSS media feature prefers-reduced-motion: reduce」後重新整理頁面，確認背景動畫沒有出現。 - 上線後持續用真實使用者數據追蹤效能：Lighthouse 是模擬環境，實際訪客的裝置與網路條件差異很大。我們自己上線後就接上了 Vercel Speed Insights。怎麼驗證：定期查看效能監測工具（如 Vercel Speed Insights、Google Search Console 的「核心網頁指標」報表）裡真實使用者的分布，不要只看單次模擬分數。
量測（Measurement）
- 上線前就設定好 Google Search Console 與 Bing Webmaster Tools 並提交 sitemap：沒驗證網域、沒提交 sitemap，上線後就完全看不到任何點擊或曝光資料。怎麼驗證：兩邊都完成網域驗證後，到 Sitemaps 分頁確認送出狀態是「成功」而不是「無法擷取」。
- 把 GSC 的「總曝光/點擊」跟「涵蓋範圍」分開看，不要只看單一數字：我們自己上線初期（資料範圍 2026-09-14~09-19）總點擊 9 次、曝光 68 次、平均 CTR 13.2%、平均排名 9.1，表現最好的頁是首頁（8 點擊/38 曝光/CTR 21.1%/平均排名 3.7）；但同期涵蓋範圍卻是 sitemap 114 個網址、Google 只認識 51 頁。點擊曝光數字好看，不代表收錄狀況也健康，兩份報表要分開追蹤。怎麼驗證：GSC 左側選單分別查看「成效」與「頁面（索引）」兩個報表，不要只看首頁的加總數字。
- 用 IndexNow 加速非 Google 引擎的收錄：IndexNow 由 Bing、Yandex 等引擎支援，Google 並不支援（我們的提交腳本註解也特別寫明），不要誤以為送了 IndexNow 就等於通知了 Google。我們自己的批次提交腳本累計送出 406 個網址（2026 年 9 月 19 日 292 個、9 月 20 日 114 個），Bing Webmaster 那邊也顯示 sitemap 112 個網址、0 錯誤 0 警告，提交後隔天就檢索成功。怎麼驗證：檢查你的 IndexNow 提交紀錄與回應碼，並在 Bing Webmaster Tools 的 Sitemaps 分頁確認檢索狀態。
- 量測站外品牌訊號，不要只看網站內部的技術分數：我們自己 2026-09-16 的 GEO 稽核裡，技術基礎拿到 86 分，但品牌權威訊號（權重 20%）只有 5 分——因為當時 LinkedIn、Wikidata、GitHub、第三方評測平台全部查無我們的公司名稱。技術做對了，不代表 AI 引擎信任你、願意引用你。怎麼驗證：自行搜尋公司名稱在 LinkedIn、Wikidata、Google 商家、GitHub 等平台是否有結果，用「有/無」盤點站外存在感，而不是只看 Lighthouse 或稽核分數。
下一步
這 25 個項目不必等到全部做完才上線，但建議至少在正式對外宣傳前跑過一輪，並把每一項的驗證結果存檔，方便日後改版時比對進退步。如果你正在規劃新官網或準備替既有網站補齊 SEO/GEO 基礎，歡迎參考我們的網站服務，或直接到聯絡我們討論你目前卡在哪一項。
參考資料
- Google：AI Overviews 與 AI Mode 的技術需求說明 — Google Search Central，2026 年 9 月查證
- Google：結構化資料入門 — Google Search Central，2026 年 9 月查證