經營電商或商品分類頁時,您可能曾經為了「商品要分頁顯示還是無限捲動」、「Google 廢除 rel=prev/next 後該怎麼設定」、「Load more 按鈕到底會不會被索引」這些問題困擾。商品分頁 SEO 的核心,在於讓 Googlebot 能完整爬到每一個商品,同時讓使用者快速找到想看的內容。Google 於 2019 年正式宣布廢除 rel=prev/next 後,許多舊文章的建議已經不再適用。在 2026 年的 AI 搜尋時代,ChatGPT、Perplexity、Google AI Overviews 不只看單一頁面,而是會評估整個站台的內容可達性,商品分頁的處理就變得更關鍵。本篇將完整說明分頁、無限捲動與 Load more 三種模式的取捨,以及實際的技術設定方法。
Google 廢除 rel=prev/next 後的處理方式
rel="prev" 與 rel="next" 是 Google 早期建議用來告訴搜尋引擎「這些分頁屬於同一個系列」的標記。但 Google 在 2019 年 3 月公開表示,已多年未使用這兩個標記作為索引訊號,因此即使您的網站還保留這些標籤,對 Google 排名沒有任何幫助,也不會造成扣分。
Google 官方立場:分頁系列已不再需要 rel=prev/next,但 Google 仍會自行透過頁面間的連結結構,辨認分頁關係。
那 2026 年該怎麼做?
現代的商品分頁 SEO,重點不在「告訴 Google 這是分頁系列」,而是讓 Googlebot 能透過清楚的內部連結,逐頁爬到所有商品。實務上的處理方式如下:
-
每一個分頁都使用獨立的 URL
分頁網址應該是可獨立存取的,例如
/products/?page=2或/products/page/2/。不要使用 fragment(#)、不要全部用 JavaScript 動態載入,否則 Googlebot 無法把每一頁當作獨立頁面爬取。/products/、/products/?page=2、/products/?page=3 各自有獨立 HTML 與商品列表。 -
分頁列必須是真實的 a 連結
「下一頁」、頁碼按鈕應該是
<a href="...">而非僅靠 JavaScript onclick。Googlebot 才能透過爬連結的方式,自然抵達所有分頁。<a href="/products/?page=2">2</a> ✓;<span onclick="loadPage(2)">2</span> ✗ -
每一個分頁的 self-canonical 指向自己
/products/?page=2的 canonical 應指向/products/?page=2,而非首頁。這是廢除rel=prev/next後最常見的錯誤。分頁的 canonical 指向首頁 = Googlebot 認為其他頁不存在,商品索引覆蓋率大幅下降。 -
每一個分頁的 title 與 meta description 要有差異
可以使用「商品分類名稱 - 第 N 頁」這樣的格式,避免所有分頁完全相同的 title 與 description 被 Google 視為重複內容問題。
「女裝洋裝 - 第 2 頁 | 品牌名」,每頁加上頁碼,既差異化又仍維持主關鍵字。
rel=prev/next,不需要急著移除。Bing 與其他搜尋引擎仍可能使用這些標記,且保留也不會造成 Google 端的問題。重點是把上述四個基礎做好,而不是糾結於 rel 屬性。
無限捲動的索引問題與解法
無限捲動(Infinite Scroll)是電商與內容網站常見的瀏覽模式——使用者滾到頁面底部,系統自動載入下一批商品。對使用者來說體驗順暢,但對 SEO 而言,卻是商品被遺漏索引的主要原因。
為什麼無限捲動對 SEO 不友善?
Googlebot 雖然能執行 JavaScript,但行為與真實使用者不同。它不會像人一樣捲動頁面,因此無限捲動載入的後續商品,如果只透過 JavaScript 動態插入 DOM,Googlebot 可能完全看不到。具體問題包括:
- 第一屏之後的商品無法被爬取與索引
- 商品分類頁的「內部連結權重」無法傳遞給後段商品
- 使用者透過搜尋結果進入頁面後,無法直接跳到第 5 屏的商品
- 單頁 DOM 過大,Core Web Vitals 表現變差,影響行動裝置排名
無限捲動的 SEO 友善做法
無限捲動並非完全不能用,而是必須採用「分頁化的無限捲動」(Paginated Infinite Scroll)架構。也就是在前端視覺上是無限捲動,但底層其實仍有獨立的分頁 URL:
<!-- 視覺上是無限捲動,但每捲動一段就用 History API 改寫 URL -->
<a href="/products/?page=2" class="next-page">載入更多</a>
// JavaScript 在捲動時呼叫:
history.replaceState(null, '', '/products/?page=2');這樣做的好處是:Googlebot 沿著 <a href> 連結爬取每一頁,真實使用者則享受無感的捲動體驗。實作要點:
- 每一批要載入的商品,背後對應一個獨立的分頁 URL
- 頁面中保留可被爬蟲讀取的「下一頁」
<a>連結 - 使用
history.replaceState或pushState同步更新瀏覽器網址列 - 分頁 URL 各自輸出完整 HTML,可被 view-source 看到商品列表
- 禁用 JavaScript 時,使用者仍能透過分頁連結瀏覽全站商品(漸進增強)
Load more 按鈕 vs 傳統分頁的取捨
除了無限捲動,還有一種折衷做法是「Load more 按鈕」——使用者點擊按鈕才載入下一批商品。它介於傳統分頁與無限捲動之間,但SEO 風險與無限捲動類似:如果按鈕只透過 JavaScript 動態載入內容,Googlebot 同樣會看不到後續商品。
三種模式的 SEO 與 UX 比較
| 模式 | SEO 友善度 | 使用者體驗 | 實作難度 | 適用情境 |
|---|---|---|---|---|
| 傳統分頁 | ★★★★★ 最佳 | ★★★ 一般 | ★ 容易 | 商品 100 件以上、SEO 為主要流量來源的電商 |
| Load more 按鈕 | ★★★ 中等(需配合分頁 URL) | ★★★★ 流暢 | ★★★ 中等 | 內容型網站、部落格列表、希望兼顧體驗的中型電商 |
| 無限捲動 | ★★ 風險高(需架構分頁化) | ★★★★★ 最佳 | ★★★★ 較難 | 圖片導向(如服飾、家具)、行動裝置流量為主 |
Load more 的 SEO 正確做法
如果您決定使用 Load more 按鈕,可以採用「按鈕 + 真實連結」雙軌做法。視覺上是按鈕,語意上是連結,讓使用者與 Googlebot 各取所需:
<a href="/products/?page=2"
class="load-more-btn"
data-ajax-load="true">
載入更多商品
</a>
// JavaScript 攔截點擊,改用 AJAX 載入
document.querySelector('.load-more-btn').addEventListener('click', function(e) {
e.preventDefault();
fetchProducts(this.href);
history.pushState(null, '', this.href);
});這種做法的精髓是:真實使用者體驗到 AJAX 無刷新載入,但 Googlebot 看到的是一個可爬取的 <a href> 連結,會自然跟進到 ?page=2 並索引那一頁的商品。台灣許多中小型電商使用 Shopify、WooCommerce 或自架平台時,只要修改前端模板就能達成這個架構,不需要重寫後端。
Pagination 與 canonical 的正確互動
商品分頁與 canonical 的關係,是這個議題中最容易出錯的地方。許多網站的設計師或工程師,因為怕「分頁被當作重複內容」,會把所有分頁的 canonical 全部指向首頁——這是嚴重的 SEO 錯誤。
錯誤做法 vs 正確做法
/products/ 首頁。結果:Googlebot 認為其他分頁「不該被索引」,只把第 1 頁納入,後續分頁的商品全部消失。?page=2 的 canonical = ?page=2。這樣每一頁都被視為獨立可索引頁面,商品才能被完整爬取。?sort=price),才應將該變體 canonical 指向不含參數的版本,但分頁本身仍維持 self-canonical。常見參數組合的處理範例
| URL 範例 | canonical 應指向 | 說明 |
|---|---|---|
| /products/ | /products/ | 首頁(self-canonical) |
| /products/?page=2 | /products/?page=2 | 分頁(self-canonical),不可指向首頁 |
| /products/?sort=price | /products/ | 排序變體指向原始 URL,避免重複 |
| /products/?page=2&sort=price | /products/?page=2 | 分頁 + 排序 → canonical 指向「對應頁的原始版」 |
| /products/?filter=red | /products/?filter=red | 若篩選頁本身有獨立 SEO 價值(如「紅色洋裝」),可 self-canonical |
何時用單一長頁、何時用分頁(依商品數量分析)
不是所有商品列表都需要分頁。如果商品數量不多,把所有商品放在同一個長頁,反而是更好的 SEO 與 UX 做法。判斷標準主要看商品數量、頁面載入時間,以及商品圖片數量。
依商品數量的建議架構
| 商品數量 | 建議架構 | 原因 |
|---|---|---|
| 1–30 件 | 單一長頁,不分頁 | 頁面負擔小、所有商品一次曝光、爬蟲一次爬完權重集中 |
| 30–100 件 | 單頁或 2 頁分頁皆可 | 看圖片大小,如果商品圖多可分頁減輕 LCP 負擔 |
| 100–500 件 | 傳統分頁(每頁 24–48 件) | 分頁可控制 DOM 大小,維持 Core Web Vitals 表現 |
| 500 件以上 | 分頁 + 子分類 + 站內搜尋 | 大型電商必須用「分類 + 篩選 + 分頁」三層結構,避免任何頁面過長 |
單一長頁的優勢
- 所有商品在同一個 URL 累積 SEO 權重,排名容易集中
- 爬蟲一次爬完,內部連結一次傳遞給所有商品頁
- 使用者用 Ctrl+F 可以在頁內搜尋,UX 反而好
- 不會有 canonical、分頁標記、URL 參數的複雜性
分頁的優勢
- 每一頁 DOM 較小,LCP、INP 等 Core Web Vitals 指標較好
- 每一頁可以針對不同關鍵字組合做 title 與 meta description
- 分頁本身也可以累積各自的長尾關鍵字排名
- 方便使用者快速跳到記憶中的「第 3 頁那個商品」
商品分頁 SEO 常見錯誤
以下是台灣中小企業電商與部落格在處理商品分頁時,最常見的六個錯誤。檢查您的網站是否有類似情形:
- 所有分頁的 canonical 都指向首頁 最致命的錯誤。會導致除了第 1 頁以外的所有商品都無法被 Google 索引。改善方式:每個分頁都設定 self-canonical,指向自己的 URL(含 page 參數)。
-
分頁連結只用 JavaScript 控制
「下一頁」按鈕用
onclick而非<a href>,Googlebot 無法跟進。改善方式:分頁列必須使用真實的 a 標籤,即使搭配 AJAX 載入也要保留可點擊的 href。 - 無限捲動沒有對應的分頁 URL 純 JavaScript 無限捲動,Googlebot 只看得到第一屏的商品。改善方式:採用分頁化無限捲動架構,捲動時用 History API 改寫 URL。
- 所有分頁的 title 與 description 完全一樣 被 Google 視為近重複內容,影響每一頁的索引品質。改善方式:title 加上「第 N 頁」、description 加上頁碼或該頁特色商品名稱。
- 用 noindex 阻止分頁被索引 想避免重複內容而把 page=2 之後全部設為 noindex,結果商品也跟著消失。改善方式:分頁不應使用 noindex,讓 Google 自然透過分頁爬到所有商品。
- 商品數量很少還硬要分頁 只有 20 件商品卻分成 4 頁,每頁只 5 件商品,稀釋了頁面內容與權重。改善方式:商品在 30 件以內,改為單一長頁,反而對 SEO 與使用者更有利。
結論:讓 Googlebot 看得到、使用者用得順
商品分頁 SEO 在 rel=prev/next 廢除後,看似變得寬鬆,實際上是把責任轉回到網站結構與技術實作。Google 不再需要您「告訴」它哪些頁是同一系列,但您必須確保 Googlebot 能透過真實的連結結構,爬到每一個分頁的每一個商品。
如果您正在規劃或檢查網站的商品分頁,可以先從五個問題自我檢查:
- 每一個分頁是否有獨立可存取的 URL,且能直接被瀏覽?
- 分頁列是否使用真實的
<a href>連結,而非僅靠 JavaScript? - 每一個分頁的 canonical 是否指向自己,而非首頁?
- 無限捲動或 Load more 是否搭配 History API 同步更新 URL?
- 商品數量是否足夠多到需要分頁,或更適合用單一長頁?
常見問答 FAQ
Google 真的完全不再使用 rel=prev/next 了嗎?
rel=prev/next 作為索引訊號。也就是說,即使您的網站還保留這兩個標記,對 Google 排名沒有任何幫助。但這不代表您必須急著移除它們——保留也不會被扣分,而且 Bing、Yandex 等其他搜尋引擎可能仍會使用這些標記。建議的處理方式是:不要再花時間維護 rel=prev/next,但已存在的可以暫時保留。把資源轉移到真正影響分頁 SEO 的核心要素——獨立可存取的分頁 URL、真實的 a 連結、正確的 self-canonical、差異化的 title 與 meta description。這四件事做好了,您的商品分頁就會被 Google 完整爬取與索引。
無限捲動真的對 SEO 那麼不友善嗎?
?page=2 URL;使用 History API 在捲動時同步更新瀏覽器網址列;停用 JavaScript 時,使用者仍能透過分頁連結瀏覽。這樣 Googlebot 沿著連結爬,使用者享受無感體驗,雙贏。台灣許多服飾與家具電商採用這種架構,既保留行動裝置的 UX,又不犧牲索引覆蓋率。
分頁的 canonical 應該指向首頁還是自己?
?sort=price 這種變體 URL),而不是用來解決「分頁」。分頁本身不是重複內容,因為每一頁的商品都不同,自然應該各自 self-canonical。
商品數量多少才需要做分頁?
Load more 按鈕和無限捲動哪個比較好?
分頁可以用 noindex 阻止被索引嗎?
<meta name="robots" content="noindex">。結果是分頁本身不被索引,但更嚴重的問題是:Googlebot 仍會爬這些頁面,但會逐漸降低爬取頻率,長期下來這些分頁上的商品連結也會失去傳遞權重的能力,後段商品的索引品質會下降。Google 官方建議的處理方式是讓分頁正常被索引——它們本身就是合法的、內容不同的頁面,不需要也不應該被 noindex。如果您擔心分頁佔用搜尋結果版面,正確做法是透過正確的 title、meta description、內部連結權重分配,讓 Google 自然知道哪一頁最重要(通常是第 1 頁),而不是用 noindex 強制阻止索引。
分頁 URL 用 ?page=2 還是 /page/2/ 比較好?
?page=2 是 query string 形式,WooCommerce、Shopify、許多 PHP 框架預設使用;/page/2/ 是路徑形式,WordPress 預設使用,看起來較整潔。從 SEO 角度,兩者都能被 Googlebot 正確爬取與索引,沒有優劣之分。實務上的選擇建議:使用您網站平台預設的格式,不要為了「看起來漂亮」而強行改寫 URL 結構,因為改寫後可能造成 301 重新導向鏈、舊網址索引殘留等問題。如果您正在新建網站,可以選擇 /page/2/ 路徑形式,因為它與其他主要內容路徑(如 /products/category/)在結構上更一致,也較容易讓人辨識為「目錄結構」。但已上線的網站,維持現狀即可,不需要為此重做。
