Search Console 說已探索但未索引？內容站 Sitemap 與 robots 巡檢筆記

Search Console 顯示「已探索，目前尚未建立索引」時，最容易做的事是一直按重新提交。但對內容站來說，這通常不是最有效的第一步。文章是否值得索引，和 sitemap 是否可讀、robots 是否擋住、canonical 是否一致、內部連結是否清楚、頁面是否真的有獨立價值都有關。

我會把這件事當成 內容營運巡檢，而不是單純的 SEO 按鈕操作。尤其 UCAMC 這類由舊 WordPress Blog 延伸到 Next.js 的技術筆記站，每天新增文章後，更需要一套可重複檢查的流程，避免 sitemap 看似存在，但實際上沒有把最新內容穩定交給搜尋引擎。

先確認 sitemap 不是舊部署

第一個檢查點是 sitemap 本身是否包含新文章 canonical URL。UCAMC 文章 canonical 是 root-level /{slug}，所以 sitemap 裡應該出現文章的根路徑，而不是把新文章寫成 /blog/{slug}。

我會檢查：

curl -s https://www.ucamc.com/sitemap.xml \
  | grep "search-console-sitemap-indexing-troubleshooting"

如果本機 build 的 sitemap 有新文章，但正式站沒有，問題可能不是文章內容，而是部署尚未更新、Vercel 快取仍在 serving 舊版本，或自訂網域指向了舊 deployment。這時要先分清楚「內容已提交」與「正式站已更新」兩件事。

robots.txt 要明確指向 sitemap

robots.txt 不只是用來封鎖爬蟲，也可以清楚告訴 crawler sitemap 在哪裡。內容站至少要確認：

User-agent: *
Allow: /
Sitemap: https://www.ucamc.com/sitemap.xml

如果 robots.txt 回 404，搜尋引擎通常仍可能爬站，但對長期營運的品牌內容站來說，這是不必要的不確定性。比較好的狀態是 robots 與 sitemap 都由同一套內容讀取邏輯產生，讓文章新增後自動被列入 sitemap。

canonical 要和實際文章路徑一致

Search Console 常見混亂來源是同一篇文章有多個看似可用的路徑。例如舊 WordPress 轉換站可能曾經有 ID-prefixed URL，新站又有 root-level canonical。UCAMC 的規則是：

• 正式文章網址：/{slug}
• Blog 列表：/blog
• 舊 WordPress ID-prefixed URL：301 到 /{slug}
• 不為新文章建立通用 /blog/{slug} canonical

所以文章頁 metadata、內部連結、sitemap 與分享網址都應該指向同一個 root-level URL。若 sitemap 指向 A，頁面 canonical 指向 B，內部連結又連到 C，搜尋引擎就可能延後判斷。

內部連結比反覆提交更重要

有些文章出現在 sitemap，卻在網站內幾乎沒有入口。對 crawler 來說，這篇文章雖然被列出，但網站結構沒有明確告訴它「這是重要內容」。我會確認新文章至少出現在：

• /blog 最新文章列表。
• 首頁最新文章或本日重點區塊。
• 對應分類頁，例如 /category/seo 或 /category/網站經營。
• 文章內有合理的相關內部連結，而不是孤立頁面。

內部連結的錨文字也要自然描述內容，例如「Next.js route health check」或「WordPress 排程排查」，不要全部寫成「點這裡」。

頁面品質要像可收藏筆記，不像索引占位頁

「已探索但未索引」不一定代表技術錯誤。有時搜尋引擎只是還沒判斷該頁值得收錄。內容站的改善方向不是塞關鍵字，而是讓文章本身更有用：

• 有明確問題情境與判斷順序。
• 有可執行指令或檢查項目。
• 有和舊文章或相關分類的內部連結。
• 有完整 title、description、Open Graph 圖片與摘要。
• 沒有 placeholder、裸露範例 URL 或看起來像未完成草稿的段落。

這也是為什麼我會在新增文章後順手看 /blog、文章頁與 sitemap，而不是只確認 Markdown 檔案存在。

我會使用的巡檢順序

遇到索引延遲時，可以用這個順序縮小範圍：

1. /{slug} 是否回 200。
2. 頁面 <link rel="canonical"> 是否指向同一個 root-level URL。
3. /sitemap.xml 是否包含該 slug。
4. /robots.txt 是否允許全站並宣告 sitemap。
5. /blog 與分類頁是否有連到該文章。
6. 舊 ID-prefixed URL 是否 301 到 canonical。
7. 正式網域和 preview/deployment 網域是否內容一致。
8. Search Console 重新提交前，先確保頁面內容不是薄內容或模板頁。

這個順序可以避免把「部署還沒更新」誤判為「Google 不收錄」，也可以避免把 canonical/linking 的小錯誤拖到大量文章都受到影響。

索引不是即時，但可觀測性要即時

搜尋引擎收錄不會保證即時發生；但內容站本身可以做到即時可觀測。每天新增文章後，至少留下 route、sitemap、robots 與 listing 的檢查結果，未來才知道問題是出在內容、部署、快取還是搜尋引擎排程。

對 UCAMC 來說，這類巡檢的價值不只是讓單篇文章被收錄，而是讓整個技術內容庫保持可搜尋、可追蹤、可長期維護。SEO 不是一次提交 sitemap 就結束，而是每次發布內容時，都確認網站結構仍然清楚地告訴讀者和搜尋引擎：這篇筆記在哪裡、屬於什麼主題、值得怎麼繼續閱讀。