` 與 `<meta name="description">` 內容不同且對應該頁主題。 - **子頁的 openGraph／twitter 設定不要整個蓋掉父層**：Next.js 的 metadata 是淺層覆蓋、不是深層合併——子頁若只回傳 `openGraph: { url, images }`，會讓繼承自父層的 `og:site_name`、`og:locale`、`og:type` 整組靜默消失，`twitter` 物件也一樣。我們自己就踩過這個坑，後來統一改用單一 `buildPageMetadata()` helper 讓全站頁面走同一套邏輯。怎麼驗證：View Source 檢查子頁的 `<meta property="og:site_name">` 與 `<meta property="og:locale">` 是否還在，而不是只看該頁自己加的 `og:url`/`og:image`。 - **hreflang 代碼全站統一，不要 `zh-TW` 與 `zh-Hant` 混用**：我們自己在 2026-09-16 的稽核中就發現頁內 `<link>` 用的是 `zh-Hant`，但 sitemap 與 HTTP Link header 卻用 `zh-TW`，三處代碼不一致等於給搜尋引擎互相矛盾的訊號，後續才統一修正。怎麼驗證：同時對照頁內 `<link rel="alternate" hreflang="...">`、`sitemap.xml` 與 HTTP 回應的 `Link` header 三處代碼是否一致。 - **動態產生的 404 頁面也要有正確的 `<html lang>`**：多語系框架某些版本的動態 `notFound()` 產生的原始 HTML 可能缺少 `lang` 屬性（這是上游框架的已知限制，我們評估後選擇接受，因為 404 頁本來就設定 noindex）。怎麼驗證：`curl` 一個刻意打錯的網址，檢查回應 HTML 的 `<html>` 標籤是否帶有 `lang` 屬性。 ## 結構化資料（Structured Data） - **Organization JSON-LD 填齊法人資訊與 sameAs**：包含 `legalName`、統一編號、地址、`sameAs` 等欄位，是讓搜尋引擎與 AI 辨識「這是哪一家公司」的基礎資料。怎麼驗證：用 Google 的 [Rich Results Test](https://search.google.com/test/rich-results) 貼上首頁網址，確認 Organization 被正確解析且沒有缺漏欄位警告。 - **FAQPage／HowTo／Article schema 對應到正確的內容頁型態**：型態放錯或欄位不全，結構化資料等於白做——Google 不會因為你「有放」JSON-LD 就給予額外評價，還是要看是否符合規範。怎麼驗證：逐頁跑 Rich Results Test，確認沒有「缺少必要欄位」或「無效項目」的警告。 - **多層頁面加上 BreadcrumbList**：讓搜尋結果能顯示頁面在網站中的路徑層級，也強化頁面之間的語意關聯。怎麼驗證：Rich Results Test 或 View Source 檢查 `<script type="application/ld+json">` 內 `BreadcrumbList` 的 `itemListElement` 順序是否正確對應實際頁面路徑。 - **結構化資料要看「完整度」，不是只看「有沒有放」**：我們自己的網站在 Organization、WebSite、Service、Article、HowTo、FAQPage、Person、DefinedTermSet 等多種類型都已建置 JSON-LD，但 2026-09-16 稽核時「結構化資料」這一類仍只拿到 50/100 分——型態覆蓋率高，不代表這一類就能拿高分。怎麼驗證：除了 Rich Results Test 的「通過/警告/錯誤」，也要對照 [Google 結構化資料官方文件](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) 逐一核對必填與建議欄位。 ## 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` 摘要與更完整的全文版**：依[規格網站](https://llmstxt.org/)的說明，`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 官方文件](https://developers.google.com/search/docs/appearance/ai-features)（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 基礎，歡迎參考我們的[網站服務](https://noise-and-signal.com/services/website)，或直接到[聯絡我們](https://noise-and-signal.com/#contact)討論你目前卡在哪一項。 ## 參考資料 - [Google：AI Overviews 與 AI Mode 的技術需求說明](https://developers.google.com/search/docs/appearance/ai-features) — Google Search Central，2026 年 9 月查證 - [Google：結構化資料入門](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) — Google Search Central，2026 年 9 月查證 ## FAQ ### 官網上線前一定要做哪些 SEO 檢查？至少要核對索引（sitemap、robots.txt、canonical）、metadata、結構化資料、AI 爬蟲可讀性、效能與量測六大類項目。少做任何一類，都可能讓網站上線後不被 Google 或 AI 引擎完整收錄。 ### 為什麼結構化資料都放了，GEO 稽核分數還是不高？「有放」不等於「放得完整」。我們自己的網站結構化資料涵蓋 Organization、Article、FAQPage 等多種類型，但 2026 年 9 月 16 日稽核時，結構化資料這一類仍只拿 50/100 分；類型多不代表得分高，仍要對照官方文件逐一核對欄位。 ### robots.txt 要開放哪些 AI 爬蟲？想被 AI 引用的內容，至少不要擋 GPTBot、ChatGPT-User、ClaudeBot、anthropic-ai、PerplexityBot、Google-Extended 等 AI 爬蟲，並排除後台與 API 路徑。我們自己的 robots.txt 共 16 條規則，逐一列出這些爬蟲。 ### llms.txt 是必要的嗎？不是必要的。依 llms.txt 規格網站的說明，它目前是一份提案而非正式標準，但已有數千個網站發佈；Google 也表示出現在 AI 功能中不需要 AI 專用檔案。我們自己有提供 llms.txt 與全文版 llms-full.txt，當作給 AI 代理人的導覽。 ### 網站上線後多久要開始看 Search Console？建議提交 sitemap 後就開始追蹤，因為「sitemap 裡有多少網址」跟「Google 實際認了多少頁」經常有落差——我們自己的 sitemap 有 114 個網址，Google 一開始（2026 年 9 月 14 日至 19 日）只認得 51 頁，這個落差要靠 GSC 涵蓋範圍報表持續盯著。

# 官網上線前的 SEO/GEO 檢查清單：25 個一定要做的項目 > 官網上線前的 25 個 SEO/GEO 檢查項目，分六大類，每項附為什麼與怎麼驗證。 - URL: https://noise-and-signal.com/insights/seo-geo-website-launch-checklist - Author: 翁睿承 (諾訊科技 Noise & Signal) - Published: 2026-09-27 - Tags: 網站製作 - Language: zh-TW --- 官網上線前，建議依索引、metadata、結構化資料、AI 爬蟲可讀性、效能與量測六大類，逐一核對至少 25 個檢查項目——少做任何一類，都可能讓網站上線後不被 Google 或 AI 引擎完整收錄。以下每項都附上「為什麼要做」與「怎麼驗證」，其中幾項直接來自我們自己在 noise-and-signal.com 上線與稽核時踩過的坑，包含 Next.js metadata 合併陷阱、hreflang 代碼不一致，以及 sitemap 網址數與 Google 實際收錄數的落差。 ## 索引（Indexing） - **Sitemap 涵蓋所有正式路由，並含 hreflang alternates**：只有列在 sitemap 裡的網址才容易被完整爬取與索引，尤其是動態產生的頁面（如文章、案例）容易被遺漏。怎麼驗證：直接開啟 `/sitemap.xml`，確認筆數與實際頁面數量相符，並抽查幾筆是否帶有 `` 標籤。 - **robots.txt 對合法爬蟲逐條 allow，並明確排除後台與 API**：籠統的 `Disallow: /` 會連 SEO 與 AI 爬蟲一起擋掉；只排除真正不該公開的路徑，才不會誤傷收錄。怎麼驗證：用 `curl https://你的網域/robots.txt` 直接看規則清單，確認沒有整站擋爬蟲的設定。 - **每頁 canonical 標籤唯一且自我指向**：canonical 設錯會讓 Google 把多個頁面判定為同一頁的重複版本，稀釋排名訊號。怎麼驗證：View Source 檢查 ``，或用 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 https://你的網域/zh-TW頁面`，檢查是否被 307 轉址、回應是否缺少 `Vary: Accept-Language` 標頭。 ## Metadata - **每頁 title 與 description 客製化，不共用同一組樣板**：重複的 title/description 會讓 Google 在搜尋結果自動改寫，也削弱每頁鎖定的關鍵字。怎麼驗證：抽查 5-10 個不同頁面的 View Source，確認 `` 與 `<meta name="description">` 內容不同且對應該頁主題。 - **子頁的 openGraph／twitter 設定不要整個蓋掉父層**：Next.js 的 metadata 是淺層覆蓋、不是深層合併——子頁若只回傳 `openGraph: { url, images }`，會讓繼承自父層的 `og:site_name`、`og:locale`、`og:type` 整組靜默消失，`twitter` 物件也一樣。我們自己就踩過這個坑，後來統一改用單一 `buildPageMetadata()` helper 讓全站頁面走同一套邏輯。怎麼驗證：View Source 檢查子頁的 `<meta property="og:site_name">` 與 `<meta property="og:locale">` 是否還在，而不是只看該頁自己加的 `og:url`/`og:image`。 - **hreflang 代碼全站統一，不要 `zh-TW` 與 `zh-Hant` 混用**：我們自己在 2026-09-16 的稽核中就發現頁內 `<link>` 用的是 `zh-Hant`，但 sitemap 與 HTTP Link header 卻用 `zh-TW`，三處代碼不一致等於給搜尋引擎互相矛盾的訊號，後續才統一修正。怎麼驗證：同時對照頁內 `<link rel="alternate" hreflang="...">`、`sitemap.xml` 與 HTTP 回應的 `Link` header 三處代碼是否一致。 - **動態產生的 404 頁面也要有正確的 `<html lang>`**：多語系框架某些版本的動態 `notFound()` 產生的原始 HTML 可能缺少 `lang` 屬性（這是上游框架的已知限制，我們評估後選擇接受，因為 404 頁本來就設定 noindex）。怎麼驗證：`curl` 一個刻意打錯的網址，檢查回應 HTML 的 `<html>` 標籤是否帶有 `lang` 屬性。 ## 結構化資料（Structured Data） - **Organization JSON-LD 填齊法人資訊與 sameAs**：包含 `legalName`、統一編號、地址、`sameAs` 等欄位，是讓搜尋引擎與 AI 辨識「這是哪一家公司」的基礎資料。怎麼驗證：用 Google 的 [Rich Results Test](https://search.google.com/test/rich-results) 貼上首頁網址，確認 Organization 被正確解析且沒有缺漏欄位警告。 - **FAQPage／HowTo／Article schema 對應到正確的內容頁型態**：型態放錯或欄位不全，結構化資料等於白做——Google 不會因為你「有放」JSON-LD 就給予額外評價，還是要看是否符合規範。怎麼驗證：逐頁跑 Rich Results Test，確認沒有「缺少必要欄位」或「無效項目」的警告。 - **多層頁面加上 BreadcrumbList**：讓搜尋結果能顯示頁面在網站中的路徑層級，也強化頁面之間的語意關聯。怎麼驗證：Rich Results Test 或 View Source 檢查 `<script type="application/ld+json">` 內 `BreadcrumbList` 的 `itemListElement` 順序是否正確對應實際頁面路徑。 - **結構化資料要看「完整度」，不是只看「有沒有放」**：我們自己的網站在 Organization、WebSite、Service、Article、HowTo、FAQPage、Person、DefinedTermSet 等多種類型都已建置 JSON-LD，但 2026-09-16 稽核時「結構化資料」這一類仍只拿到 50/100 分——型態覆蓋率高，不代表這一類就能拿高分。怎麼驗證：除了 Rich Results Test 的「通過/警告/錯誤」，也要對照 [Google 結構化資料官方文件](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) 逐一核對必填與建議欄位。 ## 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` 摘要與更完整的全文版**：依[規格網站](https://llmstxt.org/)的說明，`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 官方文件](https://developers.google.com/search/docs/appearance/ai-features)（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 基礎，歡迎參考我們的[網站服務](https://noise-and-signal.com/services/website)，或直接到[聯絡我們](https://noise-and-signal.com/#contact)討論你目前卡在哪一項。 ## 參考資料 - [Google：AI Overviews 與 AI Mode 的技術需求說明](https://developers.google.com/search/docs/appearance/ai-features) — Google Search Central，2026 年 9 月查證 - [Google：結構化資料入門](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) — Google Search Central，2026 年 9 月查證 ## FAQ ### 官網上線前一定要做哪些 SEO 檢查？至少要核對索引（sitemap、robots.txt、canonical）、metadata、結構化資料、AI 爬蟲可讀性、效能與量測六大類項目。少做任何一類，都可能讓網站上線後不被 Google 或 AI 引擎完整收錄。 ### 為什麼結構化資料都放了，GEO 稽核分數還是不高？「有放」不等於「放得完整」。我們自己的網站結構化資料涵蓋 Organization、Article、FAQPage 等多種類型，但 2026 年 9 月 16 日稽核時，結構化資料這一類仍只拿 50/100 分；類型多不代表得分高，仍要對照官方文件逐一核對欄位。 ### robots.txt 要開放哪些 AI 爬蟲？想被 AI 引用的內容，至少不要擋 GPTBot、ChatGPT-User、ClaudeBot、anthropic-ai、PerplexityBot、Google-Extended 等 AI 爬蟲，並排除後台與 API 路徑。我們自己的 robots.txt 共 16 條規則，逐一列出這些爬蟲。 ### llms.txt 是必要的嗎？不是必要的。依 llms.txt 規格網站的說明，它目前是一份提案而非正式標準，但已有數千個網站發佈；Google 也表示出現在 AI 功能中不需要 AI 專用檔案。我們自己有提供 llms.txt 與全文版 llms-full.txt，當作給 AI 代理人的導覽。 ### 網站上線後多久要開始看 Search Console？建議提交 sitemap 後就開始追蹤，因為「sitemap 裡有多少網址」跟「Google 實際認了多少頁」經常有落差——我們自己的 sitemap 有 114 個網址，Google 一開始（2026 年 9 月 14 日至 19 日）只認得 51 頁，這個落差要靠 GSC 涵蓋範圍報表持續盯著。