多數電商行銷會議上，無限捲動與分頁的爭論常常被簡化成一句美感判斷，捲動比較新潮，分頁比較過時。這種判斷方式忽略了一件更根本的事，同一種介面放在不同的頁面上，效果完全相反。Baymard Institute 針對電商網站做的大型可用性測試就發現，分類瀏覽頁用無限捲動能讓使用者多看好幾倍的商品，搜尋結果頁用同一套介面卻幾乎注定讓使用者迷失方向。
無限捲動（infinite scroll）指的是使用者捲動到頁面接近底部時，系統自動載入下一批內容，不需要點擊換頁或翻頁按鈕。它確實能讓瀏覽變得順暢，付出的代價卻不只是檢索器抓不到這麼單純，使用者這邊也有結構性的犧牲，回不去原本位置、碰不到頁尾。先分清楚這個列表頁要服務的是哪一種任務，才有辦法回答無限捲動值不值得留下。
先看清這個列表頁服務探索還是查找
無限捲動好不好用，沒辦法脫離頁面情境單獨回答，真正決定它適不適合的，是這個列表頁服務的任務性質。有一種頁面服務的是探索型瀏覽，使用者沒有明確目標，單純想看看有什麼，社群動態消息、圖片牆都是這一類，滑到哪算哪，沒有非找到某一則貼文不可的壓力。另一種頁面服務的是查找型任務，使用者帶著具體目標而來，想找到某件特定商品、某一篇文章，或是把幾個選項擺在一起比較，電商的商品列表頁、內容站的文章清單頁，多半都落在這一類。
Baymard Institute 針對電商網站的大型可用性測試，就把這兩種任務性質的建議整個拆開來看：分類瀏覽頁（探索型任務）建議搭配延遲載入的載入更多按鈕，讓使用者能不受干擾地瀏覽完一整個分類的商品廣度；搜尋結果頁（查找型任務）則明講絕對不該用無限捲動，因為搜尋結果本來就是依照相關性排序過的，使用者應該被引導仔細檢視前面幾筆結果，而不是快速掃過一大片。這份測試也發現，使用無限捲動的網站，使用者實際瀏覽過的商品數量遠多於使用分頁或載入更多的網站，這說明無限捲動在探索型任務底下確實有真實的好處，不是這篇要否定的對象。
這兩種任務性質對無限捲動的反應是相反的，探索型頁面用無限捲動，使用者滑得更久、看得更廣，多半是加分；查找型頁面用無限捲動，使用者反而更難鎖定自己要的那一項，多半是扣分。多數電商的商品列表頁跟內容站的文章清單頁，讀者是帶著任務來的，落在查找型的機率遠高於探索型，這也是為什麼這篇的整體立場偏向多半該用載入更多或分頁搭配可爬網址，而不是無限捲動全面不能用。
換來瀏覽順暢的無限捲動，代價分別出現在四個地方
查找型任務用無限捲動多半扣分，這句話聽起來抽象，但代價其實分別藏在四個具體、各自能被驗證的地方。使用者離開清單去看單一項目後，常常回不去原本瀏覽的位置；頁尾在他碰到之前就被新內容推開；搜尋引擎的檢索器不會替使用者捲動或按下按鈕；就算檢索器願意執行網頁的程式碼，越靠後面的內容，被索引的機會也越低。
回不去原本位置，也存不住收藏連結
無限捲動的清單裡，使用者點進某一項看完整內容，例如點進一件商品或一篇文章，看完想回到原本瀏覽的清單，卻常常找不回剛才停留的確切位置，畫面會被重新整理到清單最上方，前面滑過的那一大段內容得重新捲一次才看得到。同樣的問題也出現在收藏跟分享上，往下捲很多次之後才看到的那一批內容，沒有一個真正屬於它自己的網址，想加入書籤或傳給朋友都做不到。
這不是使用者比較笨拙，是無限捲動這種介面本身的結構性限制。內容被持續附加到同一個網址上，沒有分段的座標可以指回去，Nielsen Norman Group 的研究就直接點出這個限制，無限捲動瀏覽大量同質性項目時確實能降低互動成本，但比較不適合支援找到某個特定項目這類具體任務，換句話說，它替使用者省下的點擊，換來的是使用者對自己剛剛看到哪裡失去掌控。
Baymard Institute 在分析為什麼載入更多的實作優於無限捲動時，特別提到瀏覽器上一頁鍵的行為必須被正確處理，使用者從商品清單點進某個商品詳細頁後，按下瀏覽器上一頁鍵，理應被帶回清單原本同一個位置，這一步做不好，使用者對整個介面的信任感會大打折扣。實測卻發現，受測的電商網站裡，採用載入更多按鈕的網站超過 90% 都把這件事做錯了。這個數字測的是載入更多按鈕，無限捲動由於連分段的網址座標都沒有，同一個問題只會更嚴重。
頁尾在使用者抵達前就被推出畫面
無限捲動的運作邏輯是使用者捲到接近底部就觸發載入下一批內容，這代表使用者理論上快要看到頁尾的那一刻，新一批項目就會被插進畫面，把頁尾重新往下推開。如果清單項目夠多，電商的分類頁、內容站的文章列表常常都是這種情況，使用者實質上就永遠碰不到頁尾，這不是偶爾發生的小狀況，是這種介面機制底下必然出現的結果。
Baymard Institute 的研究把這個現象講得很具體，使用者捲動接近清單底部時，結果會持續載入，使用者只能看到頁尾一兩秒鐘，接著下一批結果就會插入，把頁尾推出畫面，如果清單項目很多，這實際上會讓使用者永遠無法抵達頁尾。這件事之所以麻煩，是因為頁尾常常放著客服資訊、退換貨政策、隱私權政策，還有跨分類導覽這類重要連結，碰不到頁尾，等於這些功能對使用者來說形同消失。
行動裝置上這個問題又更明顯，同一份測試發現，手機上的無限捲動讓桌面版網站、常見問題、運送資訊這類重要的頁尾連結，對受測者來說變得完全存取不到。換句話說，這不只是使用者體驗上少了一個功能而已，客服跟物流資訊本來就是消費者做購買決策前常會確認的東西，碰不到等於直接砍掉一段轉換前的信任建立過程。
檢索器不會替使用者捲動或點擊按鈕
使用者體驗的代價之外，同一個問題放到搜尋引擎眼裡，處境更直接。無限捲動與載入更多按鈕背後，常常只靠 JavaScript 動態把新內容插入同一個網頁，沒有另外對應一組真實、可以被連結指到的網址。Google 官方在分頁最佳做法的文件裡講得很直接，Google 在檢索網站、尋找要建立索引的網頁時，通常會檢索網頁裡『a』標籤『href』屬性中找到的網址，檢索器不會點選按鈕，通常也不會觸發需要使用者操作才能更新目前網頁內容的 JavaScript 函式。
這代表如果無限捲動載入的內容沒有對應的真實網址，這些內容從檢索器的角度看形同不存在，不會出現在搜尋結果裡。Google Search Central Blog 由 John Mueller 等人具名發表的文章裡也提到同樣的機制，無限捲動的情況下，檢索器沒辦法穩定模擬使用者手動的行為，像是捲動畫面或點擊按鈕載入更多項目，所以不一定能存取到動態消息或圖庫裡的每一個項目，檢索器碰不到的內容，就不太可能出現在搜尋結果裡。這是機制問題，不是 Google 比較不喜歡無限捲動這種模糊的印象。
同一篇文章也直接點名哪種頁面適合這樣的介面，網站的動態消息或圖片釘選牆用無限捲動，使用者會很喜歡，這句話呼應了前面的判準，探索型頁面用無限捲動，連 Google 官方都認同，扣分的從來就只是查找型的頁面。
序列越往後，內容被索引的機會越低
就算檢索器願意執行 JavaScript、嘗試模擬使用者捲動，也不代表深層內容的能見度就沒有問題，這裡有兩層各自獨立的限制。第一層，Google 的 John Mueller 在一場 Google Hangout 裡被問到，Google 會不會索引無限捲動頁面上的所有內容，他當場給的答案很直接，如果頁面是持續不斷捲動下去、沒有盡頭的，Google 最終還是會停下來，不會索引全部內容，他形容那種巨大到會一直往下捲的頁面，Google 到最後就是會直接停止，同時建議應該用分類或頁碼把內容做成分頁。
第二層限制發生在抓到之後。Google 官方在分頁最佳做法的文件裡建議，把同一批搜尋結果中的每個網頁連結回清單的第一頁，藉此向 Google 強調整份清單的開頭，這麼做能告訴 Google，搜尋結果清單的第一頁比清單中其他頁面更適合當作到達網頁。換句話說，就算第七批、第八批的內容真的被檢索器抓到了，它天生也比清單第一頁更不容易被當成搜尋結果直接帶讀者落地的那一頁。
這兩層合起來才是完整的問題，抓不到是第一層，抓到了也不代表能見度一樣高是第二層，越靠序列後面的內容，同時被這兩層限制擋著。找不回位置、碰不到頁尾、檢索器不模擬操作，這幾個代價疊在一起，查找型的清單頁如果堅持用無限捲動，深層內容基本上等於自願退出搜尋結果的競爭。
電商與內容站的清單頁，多半該配載入更多或分頁
代價一項項攤開之後，回到最開頭探索型與查找型的判準，多數電商商品列表跟內容站文章清單，任務性質偏查找型。不堅持要無限捲動那種絲滑手感的話，直接換成載入更多按鈕，是 Baymard 研究裡評價最高、問題最少的做法；真心想要無限捲動的沉浸感，例如產品定位本來就偏探索型，那背後仍然要留一套 Google 建議、檢索器看得到的分頁序列，讓使用者看到的是無限捲動，檢索器看到的是一組可以逐一走訪的真實網址。
載入更多按鈕更適合多數清單頁
載入更多按鈕之所以是多數查找型清單頁的穩妥選擇，關鍵在於它讓使用者用一個明確的點擊動作，決定要不要看更多內容，這個動作本身就比無限捲動更容易讓使用者在瀏覽的同時仔細比較商品，畢竟畫面不會在使用者還在看的時候自己動。它也不會有頁尾碰不到的問題，因為新內容只在使用者主動點擊後才載入，不會不斷把頁尾往下推。
它也天生比無限捲動更容易做出檢索器看得懂的網址結構，因為這一批跟下一批之間本來就有一個明確的操作觸發點，可以對應到網址切換，這點無限捲動很難做到，因為它從一開始就沒有明確的分段動作。Baymard Institute 的可用性測試就明確給出結論，測試發現載入更多按鈕搭配延遲載入是更優越的實作方式，帶來更順暢的使用者體驗。
這份研究也依情境給出具體的門檻建議，分類頁一開始顯示 10 到 30 項，延遲載入到 50 到 100 項再顯示載入更多按鈕；搜尋結果頁預設只顯示 25 到 75 項；行動裝置上因為螢幕小、捲動操作限制多，建議只顯示 15 到 30 項就出現按鈕。這幾組數字說明載入更多從來不是單一做法，而是要依頁面類型調整門檻，不是隨便挑一個數字套用到所有清單頁上。
堅持要無限捲動，背後仍要留一套可爬的分頁
如果評估過後仍然想要無限捲動的體驗，例如產品定位本來就是要探索型的沉浸瀏覽，正確做法不是放棄無限捲動改回傳統分頁，而是讓使用者看到的畫面不變，但背後同時存在一組真實、可以被連結直接指到的分頁序列，每一批內容都有自己專屬的網址，這樣檢索器就能逐一走訪抓到全部內容。這不是理論上的猜測，是 Google 在 2014 年就給出的具體技術建議。
Google Search Central Blog 由 John Mueller 等人具名發表的建議寫得很明確，為確保搜尋引擎能爬到無限捲動頁面裡連結的個別項目，必須讓網站或內容管理系統額外產生一組分頁序列，搭配無限捲動使用。網址寫法上官方也直接舉了例子，好的寫法像是分類加頁碼參數；比較不理想的寫法，是只用網址片段標記位置，因為井字號之後的內容檢索器會直接忽略。
官方也建議搭配瀏覽器的歷史記錄 API（pushState、replaceState 這類方法），讓使用者做出類似點擊換頁的操作時，網址跟著更新，這樣使用者可以依序回頭瀏覽最近載入過的內容，也能把某個位置加入書籤或分享給別人。這套做法等於是把前面談的找不回位置跟檢索器看不到兩個問題一次解決，不必在體驗跟能見度之間二選一。
三種情境下，無限捲動仍然是對的選擇
前面幾節談的都是查找型清單頁該注意的代價與正確做法，但這不代表無限捲動全面不能用，呼應最開頭探索型與查找型的判準，動態消息跟圖庫這類產品本來就不靠搜尋落地，行動裝置上使用者操作的特性也跟桌面不同，而已經做對技術的團隊，體驗跟能見度其實可以兼得，這三種情境下，無限捲動依然站得住腳。
動態消息與圖庫本來就不靠搜尋落地
純瀏覽、探索型的產品，社群動態消息、圖片牆，單純供人隨手發現內容的頁面，使用者多半是從 App 內、社群分享，或者已經在網站裡點進來的，本來就不是靠搜尋引擎精準找到某一則貼文的第八批，這種情境下犧牲一點深層內容的可爬性，換取更流暢的探索體驗，是合理的取捨，不是偷懶。
Google 官方自己也認同這個判斷，前面提到過的那句話，網站的動態消息或圖片釘選牆用無限捲動，使用者會很喜歡，正好呼應這裡要講的例外情境。前面引用過的 Baymard 研究同樣支持這個方向，使用無限捲動的網站，使用者瀏覽的商品數量遠多於使用分頁或載入更多的網站，這代表無限捲動在純瀏覽、廣度優先的情境下，確實帶來真實的效果，不是這篇要否定的東西。
這跟電商商品列表或內容站文章清單完全是不同的邏輯，後兩者的訪客有很高比例是從搜尋引擎直接落地，需要精準找到某一項，前者的訪客則多半已經身處在同一個瀏覽情境裡，兩種產品的訪客來源結構不一樣，能不能承受深層內容不被索引的代價，答案自然也不一樣。
行動裝置上捲動省力，頁尾卻更難碰到
手機這種小螢幕、只能靠手指拖曳捲動的裝置上，傳統分頁的頁碼連結很難被精準點中，而且每次點擊通常都要重新載入整頁。Baymard Institute 的行動裝置測試就直接證實這個現象，相較之下，無限捲動在讓受測者探索大量商品這件事上非常有效，受測者在有無限捲動的測試網站上，捲動瀏覽過的商品數量是使用分頁的測試網站的兩倍以上。
這代表在行動裝置上，無限捲動能讓使用者用同一個操作，就是捲動，持續看到更多內容，操作成本反而比分頁更低。不過這裡的反方成立是有前提的，前提是行動裝置的操作特性，不是說桌面版的判準跟著改變，桌面上使用者本來就更容易精準點擊頁碼，這個優勢也就沒那麼明顯。前面提到的頁尾碰不到問題，在行動裝置上其實更嚴重，操作成本只是其中一項優點，行動裝置該不該用無限捲動，仍然要跟頁尾能不能碰到放在一起權衡。
團隊在做行動版介面決策時，操作成本跟頁尾能不能碰到，這兩件事最好分開評估，如果這個清單頁本身項目不多，或是頁尾內容不重要，操作成本這項優點就可以放心採用；如果頁尾放的是退換貨、客服這類非碰不到不可的資訊，前面提到的代價還是得優先考量。
留一套可爬分頁序列就能兩者兼得
已經照 Google 官方建議，讓無限捲動背後留一套可以被檢索器逐一走訪的真實分頁網址，搭配瀏覽器歷史記錄 API 更新網址，那麼無限捲動對 SEO 不友善這個顧慮，本身已經被技術解消，不必再因為 SEO 而放棄這個介面。
技術做對之後，該不該用無限捲動，就回到這頁是探索還是查找這個使用者體驗層面的判斷，不再是搜尋端的技術限制在替讀者做決定。
會走到這一步的通常是有工程資源、也真心認同無限捲動這種瀏覽方式的團隊，對多數清單頁來說，載入更多按鈕加正確的分頁邏輯已經夠用，不必為了體驗上一點點差異，去多背一套額外的網址與狀態管理邏輯，但如果這頁的核心價值本來就是沉浸式的探索體驗，這筆額外的工程成本，換來的是使用者體驗與搜尋能見度都不用讓步。
回到最開頭的問題，無限捲動值不值得為了搜尋放棄，答案從來不是全有或全無的二選一。查找型的清單頁，讀者是帶著任務來的，找不回位置、碰不到頁尾、檢索器看不到深層內容，這三個代價疊在一起，多半划不來，載入更多按鈕或分頁配上正確的網址結構，才是穩妥的預設。探索型的頁面剛好相反，使用者要的是廣度跟順暢，這時候該問的不是 SEO 怎麼辦，而是這頁想讓讀者做什麼。真正值得記住的判斷方式，是先看清楚這個列表頁在服務哪一種任務，再決定要不要為了體驗犧牲一點能見度，而不是先選一個看起來比較潮的介面，才回頭想搜尋引擎能不能找到它。