Google Search Console-頁面未被索引的原因分析與解決方案

Google Search Console 教學 3 – 頁面未被索引的原因分析與解決方案(上篇)

在這個競爭激烈的 SEO 世界中,如何提高網站排名和可見性是每個網站管理者都關心的問題。因此,我們可以從 Google Search Console 的索引頁面中,確認哪些頁面沒有被 Google 索引,進而分析並解決問題,讓頁面有機會可以被 Google 索引,提升自己網站的權重。

以澤稼的經驗來說,一般請我們協助對既有網站做SEO檢查的客戶,常見的 Google Search Console 頁面索引問題大多是「重複內容」或「轉址問題」,而這些問題都會嚴重影響網站的SEO排名,因此如果您有發現在 Google Search Console 回報的相關問題,建議盡快依照本文的說明與建議進行處理或確認。

檢查網頁狀態碼的 Chrome 擴充套件:Redirect Path

本文我們優先跟各位介紹「網頁狀態碼類型」的 Google Search Console問題,在此之前,建議各位可以先行安裝一個好用的 Chrome擴充套件:Redirect Path

Redirect Path

Redirect Path 是一款Chrome擴充程式外掛,能夠快速查詢特定網頁的HTTP狀態碼,方便我們查詢網頁回傳代碼為200、404、或是301、302轉址等,特別是務必要修改的「多層轉址」或「軟404」。雖然我們在「SCREAMING FROG-網站SEO工具應用介紹」介紹過Sreaming Frog可以一樣掃描整個網站的HTTP狀態碼,但如果針對單一特定頁面,Redirect Path Chrome擴充套件會是一個比較快速的方式。

常見HTTPCode狀態碼整理

除了可以參閱「SCREAMING FROG-網站SEO工具應用介紹」一文提到的簡述之外,這邊另外用表格幫各位整理一下,針對SEOl操作來說,一定要知道的 HTTPCode狀態碼,並且進一步去修復:

狀態代碼意義
200正常頁面;表示伺服器已成功處理請求並返回所請求的資源。
301該頁面已經永久轉址,Google信號最強。
302該頁面臨時轉址,Google信號最弱。
307也是臨時轉址的一種,但Google信號較302來得大。關於轉址的部分,可以參照「維基百科」。
403禁止開啟,通常主機端的資源權限問題(例如不開放連結某個檔案)。
404該頁面未找到或是已經移除。
500伺服器內部錯誤。

大致可以以開頭做為分類:200表示正常、3XX為轉址、4XX通常為用戶端錯誤、5XX則表示伺服器出現了問題。 代碼的正確使用及時修復能有效改善網站狀態。 

以下我們就為各位先介紹 Google Search Console 常回報關於狀態碼問題,導致頁面不被索引的項目:

轉紙類問題

頁面會重新導向

Google Search Console的「頁面會重新導向」,告知我們清單裡的網址會轉址(重新導向),因此我們主要確認「頁面是否301轉址到正確的目標頁面」即可,當然,如果目標頁面錯誤,請直接重新設定轉址目標頁面。但這類問題清單裡,也有可能存在與「重新導向錯誤」相同的問題,因此建議逐一檢查比較安全。

重新導向錯誤

「重新導向錯誤」表示在處理網址重新導向時出現了問題,常見的情況如下,建議務必要調整,亦可用上述的「Redirect Path」Chrome擴充套件進行檢查:

多重轉址

有些時候,我們需要針對某些頁面進行轉址,但轉了許多次,就會造成多重轉址,也就是從A轉到B,再轉到C的情況;多重轉址容易造成網站效能的問題,也會令Google爬蟲花費更多檢索預算在這上面,因此多重轉址建議務必要修改:只要要請工程師將轉址的流程,直接從A轉C即可。

用擴充套件檢查多重轉址問題

302轉址

302轉址屬於暫時性轉址,且Google轉址信號偏弱,通常在以下情況下使用:

  • 網站正在進行維護或更新,需要臨時將使用者重定向到另一個頁面。
  • 進行A/B測試時,將一部分流量重定向到不同的頁面,以便比較兩個版本的效果。

因此如果頁面真的已經轉移到新頁面,302則不適合,建議使用強轉址信號的301或308轉址。

JavaScript轉址

JavaScript轉址是使用JavaScript程式碼在瀏覽器中執行的一種轉址方式,雖然也是屬於強信號,但Google建議使用「伺服器轉址」為優先,因此如果可以,還是建議以301轉址為優先的做法。

Meta Refresh轉址

Meta Refresh 轉址是通過在HTML頁面的<head>區塊中添加特定的Meta標籤進行轉址,通常可以設定時間(0秒為強信號,大於0秒為弱信號),與javascript轉址一樣,不是「伺服器轉址」,因此也是較不建議的方式。

用擴充套件檢查302與js轉址問題

轉址的信號強度

因其他 4xx 問題而遭到封鎖

Google Search Console回報的「因其他4xx問題而遭到封鎖」,意味著Google 爬蟲無法訪問某些返回4xx類型的狀態碼的網址,而這些4xx的錯誤,通常為下述的403、404、405三種,以下一一為各位做說明:

因其他 4xx 問題而遭到封鎖

除了以上轉址所發生的問題之外,還有4XX類的問題也很常見:

4XX類的問題

因拒絕存取(403)而遭到封鎖

頁面的403錯誤代碼通常是由於伺服器設定關係、資源權限或安全性限制所引起,建議可以針對以下的各種原因做檢查與解決:

403錯誤

  • 錯誤的URL或隱藏文件:有時403錯誤是由於使用者請求了一個不存在的資源或使用了錯誤的網址導致,或是在主機端的檔案有設定隱藏,也會造成403錯誤。
  • 如果WordPress架站,也有可能是外掛設定錯誤,或是其中有外掛不相容造成衝突,也有可能發生403錯誤。
  • IP位址限制:有時伺服器會根據IP位址來限制對某些資源的訪問。如果您受到IP位址限制,您可以嘗試使用不同的網絡連接,或者聯繫網站管理員以了解是否有其他方法可以解除這個限制。
  • 防火牆限制:某些伺服器可能使用防火牆來限制對特定資源的訪問,例如Hotlink Protection(圖片防盜)功能,也有可能造成403禁止訪問的錯誤。
  • 補充一項,因為澤稼之前幫客戶健診時,有發現此項錯誤:對於工程師來說,屬於低級的錯誤,一般是不會發生的,但建議還是可以檢查一下:網站的首頁不是 index.html 或是 index.php。
  • 檔案資源的權限問題:當使用者試圖開啟一個需要特定權限才能存取的資源時,伺服器會返回403錯誤。解決這個問題的方法是檢查該資源的權限設置,確保用戶具有足夠的權限進行訪問。

主機資源檔案的權限

修正 403錯誤建議方案

  • 檢查URL的正確性:再次確認輸入網址是否正確。
  • 檢查首頁檔名:可以直接更改首頁名稱為「index.php」或「index.html」,檢查是否恢復正常。
  • 確認網址沒有問題的話,可以先聯繫您的主機商,請他們確認是否為「IP位址」或「防火牆限制」的原因;如果都不是,可以先利用網址打開網站其他頁面,看是「全站403」或是「部分頁面403」,或是先清除網站快取,重新打開頁面看是否正常。
  • WordPress 外掛問題:建議先停用所有 WordPress的外掛,但一個一個太過麻煩,可先到網站資料夾中,將外掛資料夾改名,此時 WordPress網站會抓不到所有外掛(停用),再打開頁面,如果正常,就代表是外掛出問題,再行逐一的檢查即可。
  • 檢查主機資料夾內的檔案是否有隱藏,或是檔案權限是否有錯誤:一般來說,文件檔案的權限應該設置為644,目錄的權限應該設置為755。如果有隱藏或是權限問題,可以利用.htaccess來進行設定(這部分建議請工程師處理,較不會出問題)

如果是WordPress架站,發生403錯誤,可以參考「How to Fix the 403 Forbidden Error in WordPress (Easy Method)」。

補充說明:頁面405錯誤

有時候會看到頁面回傳 405錯誤,絕大機會情況是表單頁面,當送出請求時,方法錯誤,例如POST請求送出表單卻進行302轉址 (通常要301轉址到感謝頁),而302轉址會更改請求方法,因此伺服器可能因為辨識錯誤而回報405錯誤。

因此針對405錯誤,建議可以再檢查一下轉址是否正確使用301,抑或是檢查網頁表單的送出方 (Method)的設定即可。

頁面405錯誤

找不到404

「找不到404」的錯誤訊息意味著瀏覽器無法找到所請求的網頁或資源,如果網站中存在大量的404錯誤,搜尋引擎可能會降低對該網站的排名。這是因為404錯誤被視為網站結構不良或使用者體驗差的信號。通常會發生的原因如下:

  • 網址打錯:最常見的原因是輸入或鏈接了錯誤的URL。這可能是由於拼寫錯誤、大小寫不正確、遺漏或多餘的字符等引起的。
  • 頁面搬移、刪除或更改網站結構:如果最近搬遷或更改了網站的頁面結構,並未進行正確的轉址或更新內部連結的話,就有可能會導致某些頁面無法找到404。

當然,我們在經營網站的過程中,無可避免有些舊頁面或是商品下架頁面必須移除,但針對SEO來說,404頁面其實有比較好的做法:

404頁面的建議作法

404優先建議

直接修改舊頁面內容,例如原本是iphone 8商品頁,現在停售下架,頁面已經404,但有新的iphone 10商品頁新上架,如果後續確定iphone 8不會上架,那麼iphone 10的商品內容可以直接拿舊的iphone 8頁面來改。

貼心提醒

如果要修改舊頁面內容,要確保網址不變(過去澤稼幫客戶健診,發現很高比例用戶的網站頁面網址,會直接套用Title或h1標籤),且原先網站架構的網址不要帶入年份或日期。例如「https://abc.com/2022-11-12-postname」。

此外,除了替換舊頁面內容,也可以直接301轉址,將舊頁面轉址到「適合且相關」的替代頁面(新商品或是商品的分類頁皆可,但不能是301轉至「網站首頁」)。

404其次建議

如果商品只是售完,處於待補貨的狀態,那麼後續還是會上架,因此就不能直接更換舊頁面內容或是301轉址,那麼就直接把舊頁面暫時404(請記得務必把http狀態碼設定為404,以免造成「軟404問題」)。

如果是維持404頁面,建議可以請利用後端程式對404做一下設計,除了視覺美觀之外,在SEO與使用者體驗角度,建議可以放置相關推薦商品,讓使用者可以進行下一步的網站動線行為,而不是直接關閉網頁。如下圖博客來的404頁面。

博客來的404頁面

404不建議作法

Google官方文件有提及,404頁面做301轉址時,建議不要轉至網站首頁,原因在於使用者希望找到他要的商品,卻又強制把他帶回首頁,從頭來過,是一種很不好的使用者體驗。

轉址式404

前面有提到404頁面,但是澤稼在幫客戶做網站SEO健診時,很常發現部分頁面真的需要404,但是在HttpCode回傳代碼卻是200,意謂告訴Google說這是一個正常頁面,這當然也意謂著:我們傳遞給Google的訊息與現實不符,因此我們通常把這類頁面稱為「軟性404」或是「轉址式404」。

轉址式404

容易導致轉址式404的原因及建議方案

單純工程師設定錯誤

例如像下方附圖,為澤稼小編朋友剛好在591網站上找房子時,突然發現該頁面已經沒東西了(404頁面),因此小編順便利用「disable-HTML」檢查一下,剛好真的是回傳200的HttpCode,此時只要請工程師從主機伺服器做好回傳HttpCode代碼即可。

軟式404

該網頁內容過少或沒有內容

如果一個頁面內容過少,或甚至沒有內容,會有極大機會被 Google 判定為404頁面,但因為這類頁面如果是人為設定,當然就是轉址式404;另一種情況,就是用javascript產生的頁面內容,如果不是用SSR(Server Side Render),也很容易因為第一時間無法讀取內容,而導致轉址404。

另一種情況,在網站裡的「標籤頁」、「分類頁」,或是「站內搜尋的無結果頁面」,也會因為常常文字內容過少,而產生轉址404問題:

  • 標籤/分類頁:如果網站有設定「標籤」的功能,建議一個標籤涵蓋的文章或商品頁數,至少5個以上。如果該標籤/分類涵蓋的數量過少,建議可以先刪除該標籤/分類頁,並且回傳404;亦或是如要保留,建議可以在頁面上增加一些文字文案。
  • 站內搜尋的無結果頁面:以noindex或robots.txt讓Google不要檢索索引該頁面。

伺服器錯誤(5xx)

500伺服器錯誤通常表示伺服器在處理請求時發生了內部錯誤,可能是伺服器遇到了程式碼錯誤、資源不足、配置問題或網路連接問題等問題,除了主機升級,擴充伺服器資源之外,也可以稍帶一陣子,在嘗試重新連線;因為有時候只是單純剛好主機掛掉而已,因此無需太過擔心,但如果持續都連不上,顯示500錯誤,那就真的需要調整主機效能。