Search Console 未編入索引怎麼解決?先修模板層,別一頁一頁點

Search Console 未編入索引怎麼解決?

Search Console 顯示「未編入索引」,多數不是單頁問題。順序要對:先查這些網址是哪來的,再查為什麼沒被收錄。順序反了,你會花三天去修一批本來就不該存在的網址。

我們自己的官網(a-ark.com.tw)2026-09-11 有 310 個網址未建立索引,源頭是 WordPress 自動為媒體庫 491 張圖產生的附件頁——幾百個網址全被 301 轉到首頁。改一條模板規則能涵蓋的量,遠多於一頁一頁按「要求重新檢索」。

這篇怎麼寫的:GSC 數字、附件頁回應碼、robots.txt 都是我在後台與瀏覽器實際查的;官方定義的整理與初稿是我和 AI 一起做的,數字逐筆對過截圖。沒有的資料我直接寫「還沒查」,不補推測值。

Search Console 未編入索引是什麼意思?先把它分成三群

「未編入索引」的意思是:Google 手上有這個網址,但沒把它放進可被搜尋的索引庫。被抓過不代表會收,沒被收也不代表 Google 不知道它存在。網頁索引報表的官方說明對每個狀態都有定義。

我把所有未編入索引的狀態分成三群,因為三群該動的手完全不同:

分群 代表狀態 意思 該動的手
①抓了但不收 已檢索-目前尚未建立索引 Google 看過內容後判斷不值得收 改內容、補內部連結
②還沒抓 已找到-目前尚未建立索引 在排隊,多半是檢索配額或 sitemap 問題 修 sitemap、伺服器回應、內部連結
③結構造成的整批問題 這是重複網頁/轉址式 404 模板或轉址規則錯了 改模板設定與 canonical

⚠ 2026-10-07 校正:這張表裡的 127 來自 sitemap(只涵蓋正規主機),719 與 310 來自網域資源(連 http 與非 www 的變體都算進來)。兩個範圍不同,所以最後那行「592 筆被收錄但不在網站地圖裡」是無效的推算。正確的算法與數字在後面兩節。

多數文章沒講的分界在這裡:狀態名稱只是症狀分類,真正的修法取決於這批網址是人做的頁,還是系統自動生出來的頁。同樣是「已檢索-目前尚未建立索引」,一篇你花三小時寫的文章,跟一個只有一張圖的附件頁,處理方式差很多。另外 GSC 報表有時間差,判斷看趨勢,不要看單日跳動。

我們自己官網查出什麼?127 個網址對上 719 頁收錄

最大的發現:網站地圖只宣告 127 個網址,Google 卻收錄了 719 頁。以下全部是 2026-09-11 的實際數據。

來源 數量
網站地圖宣告(post 7+page 21+case 88+case_cat 11) 127
GSC 已建立索引 719
GSC 未建立索引 310
Google 手上總網址數 1,029
被收錄但不在網站地圖裡 592

310 筆的 10 個原因(GSC 原文照抄):已檢索-目前尚未建立索引 129、這是重複網頁;使用者未選取標準網頁 116、轉址式 404 27、已找到-目前尚未建立索引 21、頁面會重新導向 11、遭到 robots.txt 封鎖 2、遭到「noindex」標記排除 1、找不到網頁(404) 1、替代頁面(有適當的標準標記) 1、這是重複網頁;Google 選擇的標準網頁和使用者的選擇不同 1。

兇手:媒體庫有 491 張圖,WordPress 預設會為每張上傳的圖產生一個獨立網址(附件頁),頁面上只有那張圖。我實測三個(2026-09-11):/優勢方舟官方-LINE-QR-code/ 301 轉首頁、/tainan-web-design-cost-cover/ 301 轉首頁、/case/zaichang-design/zaichang-mobile-下/ 301 轉母文章。規律是有母文章的轉母文章(正確),直接上傳到媒體庫的轉首頁(錯誤)。

116+129+21=266,量級跟 491 張圖扣掉有母文章的那些對得上。robots.txt 確認過是乾淨的,不是它造成的。近三個月未建立索引從約 530 降到 310,已建立索引持平。修正後的對照數字我刻意還沒做——修完才有得比。26 天後我回來量了第二次,結果跟預期完全不同,寫在下一節。

Search Console 未編入索引 怎麼解決實測:a-ark.com.tw 的 Google Search Console 網頁索引報表,顯示已建立索引 719 頁、未建立索引 310 頁,下方長條圖顯示近三個月未建立索引從約 530 逐步降到 310
2026-09-11 的實際報表:已建立索引 719 頁、未建立索引 310 頁。我們的網站地圖只宣告 127 個網址。
Google Search Console「網頁未編入索引的原因」表格,列出十個原因與各自頁數:已檢索但尚未建立索引 129、重複網頁使用者未選取標準網頁 116、轉址式 404 27、已找到但尚未建立索引 21、頁面會重新導向 11,其餘各 1 至 2 頁
310 筆的十個原因。前三名加起來 272 筆,全部指向同一個源頭:圖片附件頁。

一個月後再測一次:數字沒降,因為我看錯資源了

2026-10-07,距離第一次量過了 26 天。附件頁的 301 早就在跑,我預期未建立索引會明顯下降。

結果是:完全沒降。同一個資源(網域資源 a-ark.com.tw)的未建立索引還是 310,已建立索引從 719 變成 768——不但沒改善,還微幅上升。

正要結論「模板層修法無效」的時候,我切到另一個資源(網址前置字元資源 https://www.a-ark.com.tw/),同一天、同一個網站,數字完全不一樣:

2026-10-07(同一天) 網域資源 a-ark.com.tw 網址前置字元 https://www.a-ark.com.tw/
未建立索引 310 73
已建立索引 768 194
合計 1,078 267
Search Console 未編入索引報表,2026-10-07 正規主機資源顯示未建立索引 73 頁、已建立索引 194 頁
2026-10-07,資源切成 https://www.a-ark.com.tw/:未建立索引 73、已建立索引 194。跟網域資源的 310 / 768 是同一天、同一個網站。

所以問題不是附件頁有沒有修好,是我第一次量的時候沒確認自己在看哪一個資源。

誠實講一個限制:因為 9/11 那次沒有留下正規主機資源的數字,這篇做不出合法的前後對照。要比對得從 2026-10-07 這組數字重新起算。拿兩個不同範圍的數字相減再宣布「降了七成」,是我在別人文章裡最常看到的錯誤,我自己差一點就犯了。

為什麼同一個網站,兩份索引報表差了四倍?

Search Console 有兩種資源,涵蓋的範圍差很多:

資源類型 涵蓋範圍
網域資源(a-ark.com.tw) 所有子網域、所有通訊協定:http、https、www、非 www 全部算進來
網址前置字元資源(https://www.a-ark.com.tw/) 只算這一組前置字元底下的網址

四種組合:http://a-ark.com.tw/、https://www.a-ark.com.tw/、https://a-ark.com.tw/、https://www.a-ark.com.tw/。267 × 4 = 1,068,跟網域資源的 1,078 幾乎完全對得上。

查下去才發現的真正問題:http 內頁根本不轉址

正常情況下,那四種組合應該全部 301 導到正規網址,只有一份會被收錄。我實測之後發現不是這樣(2026-10-07):

https://www.a-ark.com.tw/           → 301 → https  ✓nhttps://www.a-ark.com.tw/webdesign/ → 200          ✗nhttps://www.a-ark.com.tw/prices/    → 200          ✗nhttps://www.a-ark.com.tw/showcase/  → 200          ✗

只有首頁會從 http 導到 https,所有內頁都不會。也就是說,站上每一頁都同時存在一個加密版、一個不加密版,兩個都能直接讀取。這就是網域資源數字膨脹的來源。

当時是靠 <link rel="canonical"> 指回 https 版擐著,但 canonical 是「建議」不是「強制」,而且使用者從舊連結點進 http 版會看到瀏覽器的「不安全」警告。

我們当天就補上強制轉址。修完之後全部一步到位,沒有多餘的跳轉:

https://www.a-ark.com.tw/webdesign/ → 1 跳 → https://www.a-ark.com.tw/webdesign/nhttp://a-ark.com.tw/webdesign/     → 1 跳 → https://www.a-ark.com.tw/webdesign/nhttps://a-ark.com.tw/prices/       → 1 跳 → https://www.a-ark.com.tw/prices/

你可以拿這行指令測自己的站,num_redirects 超過 1 就是有轉址鏈,回 200 就是根本沒轉:

curl -s -o /dev/null -L -w "%{url_effective} %{num_redirects}n" http://你的網址/任一內頁/

你該看哪一個資源?

判斷標準很簡單:你的 sitemap 提交在哪個資源,就看那一個。因為「宣告了幾個」跟「收錄了幾個」必須是同一個範圍,相減才有意義。

Search Console Sitemap 報表,2026-10-07 系統探索到 153 個網頁
Sitemap 提交在 https://www.a-ark.com.tw/ 這個資源底下,系統探索到 153 個網頁。

回頭看我前面那張「127 對 719」的表:127 是 sitemap(只涵蓋正規主機),719 是網域資源(涵蓋四種組合)。兩個範圍不同,相減出來的「592 筆被收錄但不在網站地圖裡」是無效的。

用同一個資源重算:sitemap 宣告 153、已建立索引 194,差 41。那 41 多半是分頁(/page/2/ 這類)。落差從「六倍」變成「多出四成」——這才是一個正常網站該有的樣子。

2026-10-07 網頁未編入索引的原因表,十個原因合計 73 頁
正規主機資源的 73 筆分成十個原因。最大一群是「重複網頁;使用者未選取標準網頁」28 筆,不再是圖片附件頁。
2026-10-07「頁面會重新導向」只剩 5 筆的網址清單
「頁面會重新導向」只剩 5 筆,而且全部不是附件頁:四筆是作品分類頁沒加結尾斜線的變體,一筆是外掛目錄的空白索引檔。

在正規主機資源裡,圖片附件頁已經完全不在報表上——模板層那一條規則是有效的,只是我之前在錯的資源裡找證據。

為什麼一頁一頁要求重新檢索是白費力氣?

因為266 筆同源網址逐筆處理的時間成本撐不住,而且下週新上傳的圖又會生出新的附件頁。要求重新檢索網址的官方文件寫得很明白:網址檢查工具有提交配額、重複提交同一網址不會加快處理,大量網址應該改用 Sitemap 批次提交。

模板層的常見成因就這幾類:WordPress 圖片附件頁(多數 SEO 外掛都有這個開關,Rank Math 在「一般設定 → 連結 → 重新導向附件」)、分頁與篩選參數網址(canonical 指回主頁或直接 noindex)。

轉址不是萬靈丹。Google 的規則是轉址要轉到「內容相當的頁」。幾百個網址全部指向首頁會被判定成假轉址,於是變成「轉址式 404」「重複網頁」「已檢索但未建立索引」——正是我們 310 筆裡的前三名。

附件頁的正確做法選一個:①關掉附件頁網址(SEO 外掛的媒體附件重新導向設定),圖片沒有獨立搜尋價值時最乾淨;②轉到母文章,我們推薦的主做法,保留連結權重又符合「內容相當」;③回 410 只當備案,用於整批網址確定永久移除、且沒有母文章可轉的情況。

但重點是:先確認這批網址「本來該不該存在」。不該存在就讓它消失,不要花三天把它們修到能被收錄。這個順序跟我們做網站建置與網站改版時第一步先盤網址結構是同一個道理。

為什麼一頁一頁要求重新檢索是白費力氣

為什麼「已建立索引 719」不代表健康?

收錄數越大不一定越好。被收錄的網址如果有很大比例是系統自動產生的空頁面,檢索配額就被吃掉了,真正重要的新頁面反而得排隊。719 放在報表上很好看,但它跟網站地圖差了 592 個——那 592 個我沒宣告過,卻在 Google 手上。

十分鐘能做完的自檢:

  1. GSC 網頁索引報表 →「已建立索引」→ 匯出網址清單。
  2. 開 sitemap(通常是 sitemap_index.xml),把網址整理成一欄。
  3. 用 VLOOKUP 或 XLOOKUP 比對,算出「不在 sitemap 裡卻被收錄」的數量。我們是 592 個。
  4. 把多出來的網址分類:附件頁、參數網址、分頁、測試頁、被誤收的後台或預覽網址。

該追的指標不是總收錄數,而是sitemap 內網址的收錄率(127 個宣告網址有幾個真的進索引)與新頁面從發布到進索引的天數。前者反映結構健康度,後者反映 Google 對這個站的檢索意願。

那 719 個已收錄網址裡有幾個是真內容、幾個是附件頁,我還沒逐筆清查,所以這篇只講「落差 592 個」這個確定的事實。做SEO 搜尋優化最怕拿沒查證的比例下結論,照著錯的方向修三個月——這跟我們寫GPT-6 Astra 企業應用實測時把難看的數字一起攤開是同一個原則。

等多久才算異常?新頁面沒進索引該不該急

先建立你自己網站的基線,才有資格說「這次比較慢」。Google 的官方說明講得直接:不保證收錄所有網頁,新網頁被檢索與建立索引需要時間,沒有標準天數可以套。

基線怎麼抓:找過去 10–20 篇已收錄的頁面,用 GSC 網址審查的「上次檢索日期」減發布日期,算中位天數。接著依狀態設不同耐心:

網址類型 該等的情況 該動手的觸發條件
新發布單頁 狀態是「已找到-尚未建立索引」且未超過自家中位天數 2 倍 超過 2 倍、或站內完全沒有連結指向它
改版頁 舊網址轉址正確、新網址已在 sitemap 內 出現「頁面會重新導向」卻找不到終點頁被收錄
整批自動產生頁 不用等 同批網址狀態一致=模板問題,直接跳過等待期

「已找到」是排隊,優先做 sitemap 與內部連結;「已檢索」是被看過後放棄,只有改內容才有用。我們官網這兩項分別是 21 和 129 筆,比例就告訴你該往哪邊使力。最近 7 天上線的 9 個服務頁進索引天數還在觀察,有數字再補。可操作的加速動作只有四件:sitemap 正確、站內有連結指到它、伺服器回應正常、內容不是模板複製;其他都是玄學。內部連結我們在網站建置流程裡是規劃階段就排好的。

幾百上千筆網址怎麼批次處理?

全部倒成一張表,先分類再修,不要打開 GSC 一筆一筆點。我們處理 310 筆的流程是這五步。

  1. 匯出與合併。GSC 逐個原因匯出 CSV(先確認當下每個表格的匯出列數上限,Google 調整過),合併成一張表。欄位:網址、狀態、網址類型(人做/自動產生)、所屬模板。
  2. 批次抓回應碼。用 Screaming Frog 或 curl 跑一遍,記錄狀態碼與轉址目的地,標出「301 但目標是首頁」的那一群——這群通常最大宗,我們的 266 筆就是這樣揪出來的。
  3. 排修復優先順序。(1) 會賺錢的頁被擋 (2) 整批模板錯 (3) 真內容但沒被收 (4) 本來就該消失的網址。第 4 類花的時間應該最少。
  4. 每日抽樣監測。用 Search Console 的 URL Inspection API 抽樣查狀態,掉了自動通知。該 API 有每日配額,動手前到官方文件確認當下數字,不要照別人文章裡的舊數字排程。
  5. 留驗證方式。固定抽 20 個代表性網址每週查一次,記錄變化日期。沒有覆查機制的修復,三個月後你不會知道它有沒有回復原狀。

做完你手上會有一張能交接的表,而不是一堆「我好像有點過那頁」的印象。這類技術檢查我們整理成固定格式,跟AI 雷達的監測邏輯是同一套:可重複、可驗證、掉了會叫。

沒被 Google 索引,ChatGPT 和 Perplexity 還引用得到嗎?

不等於一定不會被引用,但你少了一條主要通路。AI 搜尋的引用來源有的走搜尋引擎索引、有的走自家爬蟲,兩者不完全重疊。所以「沒被 Google 收錄」跟「不會被 AI 引用」不是同一件事,但把主要通路關掉本來就不聰明。

三件事要做:①robots.txt 對 AI 爬蟲的開放設定要有意識地決定,並記錄開了哪些、擋了哪些(我們站上目前只擋 /wp-admin/,等於對 AI 爬蟲全開,這是決定不是忘了設);②同一個模板層問題會同時傷兩邊,幾百個只有一張圖的空頁面,對 Google 是浪費檢索配額,對 AI 抓取是稀釋內容密度;③不要把 AI 引用當成索引問題的替代方案,頁面能獨立回答一個問題才是被引用的前提,一個 301 到首頁的附件頁兩邊都不會要它。

同一批網址在 Google 與各家 AI 工具的實際出現狀況,我們還沒做對照實測,所以不臆測,等附件頁修完會補。想知道品牌現在在 AI 回答裡的位置可以從AI 能見度檢測看;怎麼把頁面寫成「能被獨立引用的一段」整理在GEO 生成式引擎優化,整體做法則在AI 行銷。

沒被 Google 索引,ChatGPT 和 Perplexity 還引用得到嗎

常見問題

Q1. Search Console 未編入索引 怎麼解決最快?

先分群再動手:匯出清單,看同一個原因是不是集中在同一類網址上。是的話那是模板設定問題,改一次就涵蓋幾百筆;分散在少數人工頁面,才進入逐頁處理。順序顛倒你會在最沒價值的網址上花掉最多時間。

Q2.「已檢索-目前尚未建立索引」跟「已找到-目前尚未建立索引」差在哪?

前者 Google 抓過內容後決定不收,方向是內容與內部連結;後者是還沒抓,多半跟檢索配額、sitemap 或伺服器回應有關。我們官網 2026-09-11 這兩項分別是 129 和 21 筆——差距這麼大就代表該先修內容層。

Q3. WordPress 的圖片附件頁要不要關掉?

如果那些頁面只有一張圖,建議關掉或轉到母文章(多數 SEO 外掛都有這個開關,Rank Math 在「一般設定 → 連結」)。我們實測發現沒有母文章的附件頁會 301 到首頁,Google 就把它判成轉址式 404 或重複網頁。

Q4. 未建立索引的數量一直沒下降,是被懲罰了嗎?

不一定。我們自己近三個月未建立索引從約 530 降到 310,同期已建立索引持平——這是正常的消化過程。先比對已收錄網址和 sitemap 的差距,確認多出來的是哪一類,再判斷是健康問題還是結構問題。

下一步:先把網址來源盤清楚

如果你手上也有一份三位數的未編入索引清單,先別點開第一筆。把它匯出來分成「人做的頁」和「系統自動產生的頁」兩堆,你會發現八成以上落在第二堆——那堆的解法是一個設定,不是一百次點擊。

我們正在記錄 a-ark.com.tw 附件頁修正後的變化,有結果會回來更新這篇。想先讓人看一眼你站上的網址結構與索引落差,把網址寄給我們,我們用同一套流程跑一遍;做過哪些站可以翻成功案例,平常怎麼記錄這類實測都放在行銷部落格。

相關文章