多數人以為把內容摺進 accordion，等於把它藏到 Google 看不到的地方，於是乾脆什麼都不折，深怕一折，那些文字就從搜尋結果裡消失。也有人反過來想，反正讀不讀得到都一樣，不如什麼內容都往裡面塞，頁面看起來乾淨清爽就好。這兩種反應的出發點都錯了，Google 從 2013 年起就公開澄清過，摺疊起來的文字照樣會被讀進索引，這件事早就不是懸念。
真正該問的問題，從來不是搜尋引擎讀不讀得到，而是另外三件事：摺起來之後，第一次到訪這個頁面、正在找答案的人，還會不會願意點開它？手機螢幕上多按一次，實際要付出多少代價？AI 生成摘要的時候，又是怎麼挑段落的？這三個問題，才是決定一段內容該不該摺的關鍵，跟索引讀不讀得到是兩件完全不同的事。
這篇要講清楚的判斷是，摺疊本身不是問題，亂折才是。讀完這篇，會建立一套具體的判準，知道哪些內容適合收進摺疊面板，哪些內容一折就等於把讀者往外推。先從摺疊等於內容消失這個說法，是怎麼被反覆闢謠的講起。
折疊等於內容消失是被反覆闢謠的說法
這個誤解已經被 Google 自己否認了三次，而且一次比一次直接。2013 年，Matt Cutts 在一支官方影片裡回應「把文字藏在查看更多按鈕後面，算不算欺騙搜尋引擎」的提問，他給的答案很寬鬆，只要不是為了操弄排名才刻意隱藏文字，這種做法完全在允許範圍內，網站經營者不必為此擔心。
三年後，行動裝置優先索引（mobile-first indexing）正要全面上路，同樣的問題換了個角度再被問一次，摺疊起來的內容在手機上，會不會因為使用者體驗的考量被打了折扣。2016 年 11 月，Google 的 Gary Illyes 回答一樣簡短明確，在行動優先的世界裡，為了使用者體驗而收起來的內容，應該得到完整的權重，不會因此被扣分。
到了 2020 年，這個問題第三次被直接攤開來問。在 Google Search Central 的線上問答裡，有人問 John Mueller，分頁籤（tab）與摺疊面板裡的隱藏內容，在行動優先索引下會不會因為使用者看到的機率較低而被降權。Mueller 的回答很明確：「不會，特別是行動裝置頁面的內容，我們會把 HTML 裡的任何東西都納入考量。如果有些內容在某個時間點可能會顯示給使用者看，我們就會把它納入索引，這完全正常。」（經 Search Engine Journal 整理報導）
3 次表態的方向完全一致，只要內容確實存在於頁面的 HTML 裡，而且有機會顯示給使用者看，就會被正常索引，不會因為預設收合而被扣分。這背後有個技術原因可以解釋為什麼做得到。Google 官方文件說明，Googlebot 會用常綠版（evergreen）的無頭 Chromium 瀏覽器渲染頁面、執行 JavaScript，再用渲染完成後的 HTML 建立索引。換句話說，只要摺疊區塊裡的文字本來就寫在頁面的 DOM 裡，只是用 CSS 或某個屬性把它收合起來，Googlebot 渲染時一樣讀得到那段文字，跟它在畫面上是攤開還是收合無關。
不過，進得了索引跟使用者真的會點開它，完全是兩碼事。搜尋引擎的爬蟲不嫌麻煩，願意渲染完整個頁面才建立索引；真人使用者可沒有這種耐性，捲到一半看到一個標題不夠吸引人的摺疊區塊，多半直接略過。這個落差，才是接下來要拆的重點。
能被索引到，不代表讀者真的會點開
把搜尋引擎讀不讀得到，和使用者實際會不會讀到，徹底分開來看，才是判斷摺疊該不該用的起點。摺疊不是把內容藏起來給機器看、給人看不到，而是把顯示的時間延後，而延後顯示是有代價的，代價就是可及性（discoverability）下降。Nielsen Norman Group 的研究指出，用摺疊元件收起次要內容雖然讓頁面看起來簡潔，但同時也犧牲了被收起那部分內容的可及性。
這個代價具體會怎麼發生？最直接的情況是，標題如果沒有提供夠吸引人、夠清楚的預告，使用者根本不會點開那個區塊，裡面的內容就等於完全被錯過。同一份研究也指出，如果摺疊又設計成一次只能展開一個區塊、展開新的就自動收起舊的，使用者會沒辦法同時比對多個區塊的內容，容易漏掉需要跨區塊對照的資訊，這是另一種讀得到但讀者拼不起來的代價。
有人可能會反問，反正使用者本來就不看頁面下半部，摺疊起來省事，好像也沒差。這個說法本身就站不住腳。Nielsen Norman Group 另一份針對頁面捲動的眼動追蹤研究發現，使用者確實把最多注意力（約 57%）放在頁面第一屏，但下捲之後的內容並非完全被忽略，第二屏還留住約 17% 的觀看時間，其餘則分散在更下方的頁面裡；只要內容相關、格式排得好，使用者仍然願意主動往下捲動閱讀，不會因為位置在下面就不看。換句話說，怕使用者看不到就把內容折起來，理由本身就不成立，真正決定使用者看不看的，是內容夠不夠相關、夠不夠好讀，不是靠折疊解決的。
這也代表，摺疊不能拿來當作內容品質不佳的補救辦法。一段內容如果本來就寫得零散、標題也下得含糊，折起來只會讓它更難被找到，不會因為藏在收合面板裡就變得比較有價值。真正決定讀者會不會點開的，是接下來手機螢幕上那次點擊要付出多少代價。
手機螢幕上點開一次要付出的隱形成本
互動成本（interaction cost）聽起來抽象，拆開來看其實是很具體的一連串動作。Nielsen Norman Group 把展開一個摺疊區塊拆成 5 個實際步驟：捲動頁面、掃視各個標題、決定要點開哪一個、把點擊精準對到那個標題上、等待內容跑出來。每一個子動作單獨看都很小，但累加起來，就會變成使用者實際感受到的負擔。
這 5 個動作放到手機螢幕上，每一個都比在桌機上更吃力。螢幕小，能一次顯示的標題數量有限，捲動的次數自然變多；點擊的目標區域也跟著縮小，拇指要精準對到一行文字並不容易，誤觸鄰近區塊的機會比滑鼠游標高出許多。桌機上一次動作能完成的事，在手機上往往得拆成好幾次才能到位，互動成本就這樣一步步疊上去。
同一份研究也提到，摺疊在印刷與跨區塊對照的情境下特別不利。使用者要一次印出或比對整頁內容時，得先把每個摺疊區塊一一展開；如果又是展開一個就自動收合其他的設計，甚至沒辦法一次看到全部內容，得反覆點開又收起，才能拼出完整的樣貌。
不過，摺疊在手機上並非全無道理。另一篇針對行動裝置的研究指出，手機螢幕能顯示的內容有限，摺疊可以讓使用者先看到大局，再選要不要深入細節，這也是摺疊在手機上比桌機更常被建議使用的原因。同一篇研究也點出一個常見的副作用，使用者展開內容之後，畫面被推到很下面，容易誤以為自己換了一個頁面，反而找不到路回去原本的位置。
這一節的判斷是，摺疊在手機上，是把一次性的捲動成本，換成使用者自己選擇要不要付出的點擊成本。這是划算的交換，但前提是使用者知道自己在選什麼，標題要夠清楚，他才判斷得出這個區塊值不值得點開。標題寫得清楚，只解決了「使用者願不願意點開」這一關；內容本身寫得好不好、能不能被機器獨立抽出來用，又是另一件事。
AI 摘要挑的是好抽的段落，不是排版好看與否
這一節的判斷，是我們依前面已經確認的兩件事（Google 官方的索引立場、可及性研究的發現）做的推論延伸，不是引用某一份專門針對 AI 摘要與摺疊內容的研究結論。事實上，目前也沒有一份公開研究直接證實摺疊內容在 AI 摘要裡會被打折扣，我們判斷的邏輯是，AI 生成回答時仰賴的是把網頁拆成一個個可獨立理解的段落再抽取，段落本身寫得好不好、獨不獨立成立，理論上比它在頁面上是攤開還是收合更關鍵。
Google 官方文件也支持這個方向。文件〈AI Features and Your Website〉明確指出，要出現在 AI Overview 或 AI 模式的輔助連結裡，頁面本身要先符合被 Google 搜尋正常索引、能顯示摘要的技術條件，並強調沒有額外的特殊要求或優化，一般搜尋排名的基礎 SEO 原則同樣適用於 AI 功能。這代表 Google 官方立場並沒有另外針對摺疊內容訂出對 AI 更嚴苛的規則，延續前面第一節內容一樣會被正常索引的結論，目前沒有官方證據支持摺疊內容在 AI 摘要裡被特別扣分這種說法。
不過，這裡有一個真正該留意的技術分界，是我們根據 Google 自家的渲染文件推導出的合理判斷。如果一個摺疊區塊的內容，本來就寫在頁面的 HTML 或 DOM 裡，只是預設用 CSS 或屬性收合，那麼不管是搜尋引擎的渲染流程，還是任何會抓取渲染後頁面的擷取系統，都拿得到這段文字。但如果內容是使用者按下按鈕之後，才由 JavaScript 動態產生、插入頁面，在沒有人真的去點擊觸發那個事件的情況下，這段內容可能根本不存在於任何自動化流程會看到的頁面快照裡。這才是真正會讓內容消失的做法，跟摺疊本身無關，是實作方式的問題，下一節會具體落地成該怎麼做、不該怎麼做。
換個角度想，與其糾結一段內容該攤開還是收合，不如先確認每一段文字本身能不能離開上下文獨立成立。一段寫得清楚、自成一個完整答案的文字，不管它顯示在頁面的哪個狀態，對機器或對人都比較容易被理解跟引用；一段本來就寫得含糊、要靠前後文才看得懂的內容，就算全部攤開放在頁面最上方，一樣不容易被抽出來用。
FAQ 與規格表適合收進去，敘事型內容不適合
把前面的判準落地成具體的內容類型清單，對照自己網站上的內容屬於哪一種，會清楚很多。核心邏輯延續前面的研究發現：內容彼此獨立、讀者通常只需要其中一小塊時，摺疊是好工具；內容需要連貫閱讀，或讀者往往需要同時看到大部分內容時，摺疊反而製造障礙。
適合收進摺疊面板的情境有幾種。使用者只需要頁面上一小部分內容時，摺疊剛好把不相關的部分先收起來；主要任務是有先後順序的多步驟流程時，摺疊可以只顯示當前步驟相關的內容，隱藏其餘干擾；各區塊內容彼此獨立、讀者不太需要同時參照多個區塊時，摺疊也很合適，這也是 FAQ 頁與產品規格區塊常被視為摺疊良好候選的原因。舉例來說，一家做客製化商品的電商，商品規格表裡材質、尺寸、保固條款天然分成好幾個獨立小塊，讀者通常只想確認其中一兩項，這種情境適合折。
不適合摺疊的情境同樣清楚。讀者需要頁面上大部分或全部內容才能找到答案時，這種情況該整頁攤開顯示，例如一家提供訂閱服務的網站，方案比較頁如果把三個方案的完整條款都收進摺疊面板，讀者得反覆展開又收起才能比較，實際上讀者通常需要同時看到三個方案才能決定，比較表格式或保持攤開會更合適。頁面內容本來就很少時也不該摺，摺疊反而讓頁面看起來空蕩蕩，讓人誤以為沒有有價值的資訊而直接離開。
內容有很深的巢狀階層時也該避開摺疊，攤平成摺疊清單反而讓使用者搞不清楚自己在哪一層；內容零散、很難濃縮出有代表性的標題時，硬折會讓標題詞不達意。最後一種情境最容易被忽略，讀者預期會沉浸式連貫閱讀時，即使篇幅長也應該避免摺疊。一篇說明產業趨勢的敘事型長文，段落之間有因果與時間順序，不該為了讓頁面看起來短一點，就把中段折起來，那樣只會打斷讀者原本順著讀下去的節奏。
判斷完哪些內容該折、哪些不該折之後，接下來還要確認摺疊本身做得對不對，這才是真正決定內容會不會消失的關鍵。
CSS 藏起來的內容跟點擊插入的內容不是同一回事
前面提到的技術分界，在這裡要具體落地成該怎麼做、不該怎麼做。內容要真的存在於 DOM 裡，只是視覺上收合，不能是使用者點擊後才由 JavaScript 動態插入的。判準沿用前面確認過的事實，Googlebot 靠常綠 Chromium 渲染頁面、執行 JavaScript 之後才用渲染完成的 HTML 建立索引，據此可以合理推導出實作上的分界線，內容原本就寫進頁面的 HTML 或 DOM，只是用 CSS（如隱藏屬性或高度限制）收合，這種摺疊，內容仍在渲染後的頁面裡，不管是搜尋引擎或任何抓取渲染後頁面的流程都讀得到；但如果收合的內容要等使用者點擊之後才由 JavaScript 動態產生並插入頁面，在沒有實際點擊事件觸發的情況下，那段內容可能根本不存在於任何自動化流程看到的頁面快照裡。這是最核心、也最容易被誤解的一條界線。
折疊做錯，代價不只是排版難看，而是讓內容真的變得不可及，不管對螢幕閱讀器使用者、鍵盤操作者，還是自動化擷取流程都一樣。無障礙上有兩個具體要求要滿足。折疊標題本身要能像按鈕一樣被鍵盤操作，可以用 Tab 鍵移到、用 Enter 或空白鍵觸發；螢幕閱讀器要能唸出目前是展開還是收合的狀態。當摺疊區塊收合時，裡面的內容必須視覺上看不到，而且程式邏輯上也真的不可及，不能只在畫面上藏起來，實際上鍵盤使用者還是能不小心操作到看不見的內容，造成困惑。
還有一種常見誤區，值得放在同一節一起講清楚。分頁籤（tab）介面常見的實作方式，是同一時間只有目前選中的那個分頁內容留在頁面裡，其餘分頁內容整段被移除或根本沒有被載入，這跟 accordion 所有區塊內容其實都在頁面裡、只是收合看不見不一樣。如果一套自動化流程只抓取到頁面當下的一次快照，分頁籤介面比摺疊元件更容易造成只抓到目前那一個分頁的遺漏，這一點在規劃內容分頁籤還是摺疊清單時，特別值得留意。
摺疊做對了，內容才真的還在那裡等著被讀到，不管讀的是人還是機器。但就算實作全部正確，還有最後一個問題要回答，哪些內容才值得放進去。
核心答案留在外面，次要補充才收進折疊裡
前面幾節分別確認了 Google 官方立場、可及性與互動成本的研究、AI 摘要邏輯的合理推論、內容類型判準，以及正確的實作方式，整合起來，可以收成一句可以直接拿去用的判斷準則，摺疊是資訊層級工具，不是拿來塞內容的地方。
判斷一段內容算不算核心，有一個具體的問法可以自問：這段內容，對第一次到訪、正在找答案的人是不是必要？用這個問法回頭檢視前面提過的內容類型清單，就能看得更清楚。以商品規格表為例，材質、保固條款這類細節可以折，但這項商品有沒有某個核心功能這種決定性資訊，不該折起來，因為那正是讀者第一次到訪時最需要立刻確認的答案。同樣道理放到方案比較頁，個別條款的細節可以收，但三個方案彼此的核心差異，得讓讀者一眼看到，不能靠展開再展開才拼湊出來。
摺疊也不是省事的工具。標題寫不清楚、內容類型判斷不準，摺疊反而會製造前面幾節講過的那些代價，讀者錯過該看到的答案、手機上多付出不必要的點擊成本，內容也可能因為實作方式不對而真的變得讀不到。Nielsen Norman Group 有一句提醒，幾乎就是這整套判準的濃縮版本：「避免把關鍵資訊藏進收合的面板裡，重要的資訊應該放在摺疊元件之外，確保它隨時可見、不會被忽略。」
下次要決定一段內容該不該折，不必再糾結搜尋引擎讀不讀得到，那從來都不是真正的問題。真正該做的判斷，是回頭看這段文字對正在找答案的那個人重不重要。重要的留在外面，次要的補充收進去，摺疊才會是幫使用者理清資訊層級的工具，而不是變成讓核心答案跟著一起消失的地方。