多數人討論側邊欄，吵的是「留不留」，把它當成一次要嘛整組保留、要嘛整組砍掉的二選一問題。但同一組側邊欄放在桌面版和手機版，際遇完全不同：桌面版還有多餘寬度撐住導覽、相關文章與篩選條件，換到手機版，螢幕一窄，整組欄位常常被擠到頁面最底端，讀者要滑完整篇內容才碰得到，等於白放。
側邊欄（sidebar）指的是主內容欄之外的第二欄，裡面通常混著兩種性質完全不同的東西：一種是幫讀者完成任務的功能型元件，像篩選條件、目錄、相關文章內鏈；另一種是純粹填版面的裝飾型小工具，像人氣排行、贊助欄位、社群按讚數。留不留、放哪裡，不該按「側邊欄」這個容器一次決定，而要拆開來按元件個別判斷，這正是行動版體驗常常做壞、桌面版也很少認真檢討的地方。
側邊欄是什麼？從桌面版的萬用抽屜到行動版的沉底元件
側邊欄常見放三種東西：導覽或篩選、相關文章與內鏈、廣告與小工具。固定寬度的桌面版面時代，這個第二欄幾乎是標準配備，畫面本來就比手機寬，分出一欄放暫時用不到但可能有用的東西，不太會壓縮到主內容的可讀行寬。這也是為什麼從早期的部落格版型到現在的電商後台，側邊欄的位置幾乎都固定在同一處。
Nielsen Norman Group 對垂直導覽的研究點出了這個設計能成立的前提，左側垂直導覽可以容納任意數量的頂層項目，不必為了塞進版面而壓縮文字，但代價是佔用更多螢幕面積，連帶壓縮主內容可用的寬度。換句話說，桌面版能放得下側邊欄，是因為畫面寬度先滿足了主內容，才有餘裕分給第二欄。
後來手機成為多數網站的主要流量來源，這個前提整個反過來。手機螢幕寬度通常只有 360 到 430 像素左右，扣掉安全邊界，根本容不下主內容欄加次要欄並排還維持可讀行寬。響應式框架處理這個限制的方式，幾乎都是把並排的兩欄疊成一欄，而疊起來的順序多半照 HTML 原始碼順序走，側邊欄的位置通常排在主內容之後，疊完自然就沉到頁面最底端。這不是設計師刻意把它藏起來，是版面在窄畫面下的必然結果。
真正該問的問題，從來不是「側邊欄該不該存在」，而是「裡面放的東西，值不值得占用這塊版位」。桌面版能負擔第二欄的空間成本，不代表裡面的內容就有存在價值；手機版把它擠到最底端，也不代表裡面的內容本來就沒用，只是被擺錯了位置。
行動版面沒有多餘寬度容納第二欄內容
手機螢幕寬度通常只有 360 到 430 像素，扣掉安全邊界後，能給內容用的行寬本來就有限。要在這個寬度裡同時塞進主內容欄與次要欄，兩欄都會被壓得太窄，字級不是被迫縮小就是換行點亂跳，讀起來比單欄還累。這也是為什麼幾乎所有響應式框架，遇到窄螢幕的處理方式都一樣，把兩欄疊成一欄，讓內容各自維持一個舒服的行寬，而不是硬擠出兩個欄位。
疊欄的順序不是重新排過，而是照 HTML 原始碼的順序往下排。多數網站的側邊欄程式碼寫在主內容之後，疊起來就自然落到頁面最底端。這是排版的物理限制，不是設計團隊故意把它藏起來，但後果不會因此變輕。側邊欄裡如果放的是讀者這個任務當下用得到的東西，例如目錄、篩選器，讀者得先滑過整篇內容才碰得到，等於這個功能在手機上形同不存在。
Google 的行動版內容公平性文件把這件事講得很直接，行動版必須包含與桌面版相同的主要內容（”Make sure that your mobile site contains the same content as your desktop site”）。但這份文件同時也給了彈性，可以用不同的設計來提升手機使用體驗，例如把內容收進手風琴或分頁（”You can have a different design on mobile to maximize user experience， for example moving content into accordions or tabs”），條件是內容本身要對等。換句話說，如果側邊欄放的是主要內容，像篩選條件或目錄，行動版可以換個呈現方式，收合起來、置頂顯示，但不能整個消失或被推到讀者根本滑不到的位置；如果放的只是裝飾性小工具，直接在行動版隱藏反而更貼近這份指引的精神。
使用者已經學會無視側邊欄的廣告位置
側邊欄長期被拿來放廣告，讀者已經練出一套視覺迴避機制，眼睛還沒真正聚焦就先把長得像廣告的區塊濾掉。Nielsen Norman Group 的可用性研究裡，受訪者看著側邊欄裡其實有用的內容，說出的原話是「我看到了，但它看起來像廣告，所以我忽略了」（”I saw that， but it looked like an ad， so I ignored it”）。這代表使用者不是沒看見，是主動關掉了注意力。
這套自我防禦機制的判斷依據，不是內容本身，是長得像什麼。同一份研究指出，使用者已經發展出一套對廣告的自衛系統，只要版面用了色塊、縮圖加標題的制式排版，即使裡面放的是相關文章連結或有用的資訊，一樣會被歸類成廣告直接跳過。也就是說，就算側邊欄裡的內容貨真價實，只要視覺樣式跟廣告太像，一樣會被當成雜訊濾掉。
格式塔原則能解釋這件事為什麼還會拖累主內容的可信度。並排放在一起的元素，會被讀者認知成彼此相關（”people perceive elements that are placed together to be related”）。廣告色塊如果緊貼著側邊欄裡的其他內容，讀者會把兩者當成同一掛，連帶懷疑旁邊那些看起來也像廣告的東西是不是也在騙點擊。解法方向也不難理解，側邊欄裡真正想被看見的內容，樣式要跟廣告切割開來，選擇簡潔、不套色塊模板的呈現方式，縮圖也要放真正能傳達資訊的圖片，而不是純粹裝飾用的插圖。內容做得越不像廣告，讀者才會願意分一點注意力給它。
多一個小工具，就多一份載入與跳動的代價
側邊欄常見的社群外掛、廣告聯播、第三方嵌入，每加一個，就多一段要載入的 JavaScript 或 iframe。這些元件有個共同的麻煩，實際高度通常要等內容抓回來才確定，瀏覽器一開始只能先預留一個大概的空間，等內容回來、高度確定，畫面就會被往下推或往上收，也就是版面跳動（layout shift）。讀者正要點某個連結，手指都已經移動到位，畫面卻因為側邊欄的小工具突然跳出結果點到別的地方，這種體驗很難不留下壞印象。
Google 的效能文件 web.dev 直接把廣告與嵌入內容列為造成版面跳動的常見原因之一，原文寫的是”third-party ads or widgets that dynamically resize themselves”會造成版面位移。這個現象反映在 Core Web Vitals 的 CLS（Cumulative Layout Shift，累積版面位移）指標上，Google 官方定義 CLS 在 0.1 以下算好、超過 0.25 算不佳，而且是抓頁面訪次的第 75 百分位數計算，不是只看單一次載入。這些第三方程式碼不只讓版面跳動，還會佔用網路頻寬與主執行緒的運算時間，同時拖慢最大內容繪製時間（LCP，Largest Contentful Paint），原本該優先出現的主內容，反而因為側邊欄同時搶頻寬而跟著變慢。
同一份文件也給出具體修法，把晚載入的內容（像廣告）一開始就在版面裡預留空間，例如設定 min-height 或用 aspect-ratio 這類 CSS 屬性，讓瀏覽器提前保留好版位，內容回來時直接填進去，不會再擠壓或推移周圍的畫面。這代表側邊欄小工具不是不能留，但至少要先做好這一步，不然每加一個工具，付出的不只是頁面多一段程式碼要跑，是實際會被 Google 納入評分的載入體驗跟著往下掉，非必要的小工具，效能成本很可能已經大於它帶來的價值。
功能型元件與裝飾型小工具的取捨界線
行動版擠不下的是版面空間，不是內容本身的價值；會被讀者視覺迴避的是廣告樣式，不是側邊欄這個位置；會拖累載入與版面穩定性的是高度不確定的第三方元件，不是側邊欄這個概念。三個現象合在一起，指向同一個判準：不是「側邊欄該不該有」，是「這個元件，讀者這一刻用得上嗎」。
功能型元件包括篩選條件、目錄、相關文章內鏈，這些都在讀者完成任務的路徑上，少了它們，讀者得多做一件事才能達到原本的目的，像是重新搜尋、從頭找章節、自己再去查有沒有相關內容。裝飾型小工具則是人氣排行、贊助商欄位、標籤雲、社群按讚數，這些拿掉之後，讀者不會少做任何一件事，因為它們本來就不在任務路徑上。判準不是「這個元件看起來有沒有用」，是「拿掉它，讀者會不會少做成一件事」。
這個判準也解釋了前面三節現象為什麼會這樣分佈，功能型元件值得想辦法在行動版保留，哪怕換一種呈現方式，例如收合成可展開的選單；裝飾型元件本來就該被效能與注意力的成本淘汰，留著只是徒增載入時間跟版面跳動的風險，卻換不到讀者真正會用的東西。
篩選、目錄與相關文章內鏈的存留理由
篩選條件常見於電商分類頁與知識庫，讀者靠它縮小範圍，不必回頭重新輸入關鍵字搜尋一次。少了篩選，讀者得自己在一長串結果裡逐條核對，或是退回搜尋頁重新打關鍵字，多做的這幾步，很容易讓人乾脆放棄。
目錄則是長文與文件站的必要配備。讀者拿到一份技術文件，通常不是從頭讀到尾，是帶著特定問題來找特定段落，目錄讓他直接跳到需要的位置，而不是靠 Ctrl+F 或往下滑猜位置。相關文章內鏈幫讀者接續下一步的資訊需求，同時也是站內連結權重的合理去處，讀者讀完一篇還想深入，內鏈省下他重新搜尋的力氣。
這三種元件的共同點是，都是讀者正在做的任務的一部分，拿掉就是拿掉功能，不是拿掉裝飾。Google 的行動版內容公平性文件那句可以用手風琴或分頁重新組織版面，正好對應這三類元件在窄螢幕上該有的處理方式，收合起來，而不是整個刪除。篩選條件可以摺成一個可展開的面板，目錄可以做成置頂的浮動按鈕，相關文章內鏈可以移到內文段落之間，只要讀者找得到、點得到，呈現方式怎麼換都不影響它的功能性。
人氣排行、贊助欄位多半只是版面裝飾
人氣排行榜、贊助商欄位、社群帳號小工具、標籤雲，這些元件的存在理由，通常經不起細問，放上去多半只是因為其他網站也有，而不是回答讀者當下的問題。讀者打開一篇文章，不會因為看到旁邊有一個人氣排行榜就更容易讀懂正文，也不會因為看到贊助商的商標就更信任內容本身。
前面已經證明這類元件會被視覺迴避，讀者的眼睛還沒對焦就先跳過；也會拖累載入速度跟版面穩定性，每一個小工具都是額外的載入請求，高度還不一定確定。成本確定、效果存疑，這正是行動版第一個該砍掉、桌面版也該重新檢討的區塊。留著它們，付出的代價是讀者的注意力跟頁面的效能分數，換到的回報卻很難證明。
文件、篩選和應用程式頁面桌面版仍仰賴側邊欄動線
不是所有頁面的側邊欄都該砍。技術文件站、知識庫、電商分類篩選頁、應用程式型工具，這幾類頁面的讀者需要在多個章節或分類之間反覆橫向移動，垂直側邊導覽讓他們不必每次都先回上一層，再往下找下一個分類。
Nielsen Norman Group 對垂直導覽的研究指出，這種形式特別適合內容廣泛或持續成長的網站，像文件站、企業站、政府站、高等教育與醫療站，原因是垂直導覽能容納任意數量的頂層分類，不必為了塞進版面壓縮文字。同一份研究也指出使用者有 80% 的時間注視落在畫面左半（”users look at the left half of the screen 80% of the time”），這是左側垂直導覽在視覺搜尋效率上優於水平導覽的原因之一。研究並舉 Slack 與 Gmail 為常見的應用程式型側邊導覽案例（”Slack and Gmail are examples of widely used web applications that use vertical left-side navigation”），強調這類介面的側邊欄是核心動線，讀者一整天都靠它在不同頻道或信件夾之間切換，不是可有可無的附加物。
這類頁面的側邊欄本質是導覽骨架，不是附加內容，拿掉反而增加讀者的操作步驟，每切換一個分類就得先回上一層選單，再重新往下找。就算在行動版，這類側邊欄也該想辦法保留，收合成可展開的選單，而不是整個拿掉，因為讀者在這類頁面上本來就需要頻繁跨分類移動，少了這條動線，整個使用流程都會變得繞路。
拿掉側邊欄的長文頁面，讀起來反而更專注
部落格文章、深度報導、單一主題教學這類內容型頁面，讀者的任務單純只是把這篇讀完，不需要在讀的過程中被篩選條件打斷，也不需要跳去別的分類，更不需要側邊欄裡的廣告來分散注意力。這類頁面拿掉側邊欄之後，主內容欄可以拉寬到更適合的閱讀行寬，少了視覺迴避造成的雜訊，也少了第三方小工具帶來的版面跳動風險。
Nielsen Norman Group 另一份關於降低認知負荷的研究，把這個道理講得很清楚：多餘的連結、不相關的圖片、毫無意義的排版裝飾都會拖慢使用者（”redundant links， irrelevant images， and meaningless typography flourishes slow users down”），而這份研究列出的減少認知負荷第一項建議，就是避免視覺雜亂（”Avoid visual clutter”）。內容型長文頁面拿掉側邊欄之後普遍變得更好讀，原因正是版面上少了這些跟閱讀任務無關的雜訊。
內容型頁面的讀者任務就是專心讀完這一篇，篩選條件用不上，跨分類導覽也用不上，側邊欄裡的功能型元件在這裡幾乎沒有存在的理由，裝飾型元件更是純粹扣分。
側邊欄該不該留，答案從來不是整組保留或整組砍掉，是把裡面的每一個元件單獨拿出來問一次，拿掉它，讀者會不會少做成一件事。篩選條件、目錄、相關文章內鏈答案是會，人氣排行榜、贊助欄位、社群按讚數答案通常是不會。桌面版有餘裕負擔第二欄的空間成本，不代表裡面每一項都該留；手機版把整組側邊欄擠到最底端，也不是叫設計者放棄功能型元件，而是提醒該換一種呈現方式，把讀者真正用得上的東西收合起來、擺到搆得到的地方，而不是連內容一起沉到看不見的最底端。