同一個首頁，無障礙檢測工具標出十來個紅字，其中超過一半，同時也是搜尋引擎爬蟲眼裡的語意破洞。這個重疊不是巧合：螢幕閱讀器讀不懂的標題結構、找不到對應的 aria 指向、缺了替身文字的圖片，爬蟲多半也讀得很吃力。所以先給結論，無障礙和排名不是同一個評分系統，卻共用大量底層訊號，把無障礙的結構問題修好，往往等於順手替爬蟲清掉語意障礙。這篇我們用一家工業儲存廠商的實際檢測結果當底，拆給你看標題階層跳級、空標題、aria 寫錯、圖片尺寸這幾類問題，各自該怎麼判斷該不該修、修的順序怎麼排。
1. 我們怎麼判斷一個標題問題該不該花時間修
標題結構是頁面語意的骨架。爬蟲靠它理解「這一段在講什麼、從屬於哪個大主題」，螢幕閱讀器的使用者則靠它跳著讀。骨架歪了，兩邊都會誤解。但不是每個標題問題都值得立刻動手，我們會先看它是「純語意瑕疵」還是「會誤導理解」，再決定要不要排進優先清單。
1.1 只有一個換行的空標題，比你想的更常見
那家廠商的首頁裡藏了一個 <h3><br></h3>，裡面沒有任何文字，只有一個換行符。檢測工具直接判定為空標題。這種寫法幾乎都是前端為了「撐出一段空白距離」順手拿標題標籤來墊，結果爬蟲看到一個被標記為重點的區塊卻空無一物，語意上是矛盾的。我們的做法很直接：有內容就補上真實文字，沒內容就換成 div 或用 CSS 的 margin 處理間距，不要讓標題標籤去做排版的工作。這類問題修起來成本極低，卻能直接消掉一個語意矛盾，我們通常會趁早清掉，免得它在檢測報告裡一直當紅字。
1.2 從 h1 直接跳到 h3，爬蟲會怎麼補這個洞
同一個首頁還有兩處跳級：h1 之後直接接 h3，以及 h2 後面突然冒出 h6，那是一則放日期的小標。搜尋引擎不會因為你跳了一級就當掉，它會嘗試自己補回中間的層級，但補出來的結構未必是你要的意思。我們在實務上看過一個案例，頁面把所有次要資訊都塞進 h6，結果爬蟲把整頁的重點權重都稀釋掉，主要產品線的段落反而沒被當成重點。正確的階層是逐級往下：h1 到 h2 到 h3，中間不跳號。你要的是讓機器照你的意思理解主從，而不是讓它自己猜。一個好懂的類比是，標題階層就像書的目錄：章底下是節、節底下是小節，讀者靠這個層次知道自己讀到哪、這段屬於哪個大主題。如果目錄裡章的下一層突然跳到小小節，讀者會搞不清楚中間那層跑去哪了，爬蟲面對跳級的標題也是同樣的困惑，只是它不會抱怨，而是默默用自己的猜測補上，然後照那個未必正確的理解去判斷你這頁的重點。
1.3 標題標籤不是拿來調字級的
上面兩個問題的共同根源，是把標題當成字級控制器。想要小一點的字就用 h6，想要一段留白就用空 h3。這在視覺上或許看不出差別，但語意層完全亂了。字級交給 CSS，標題只表達「這是第幾層的主題」，這條界線一旦守住，大部分階層問題根本不會發生。我們跟前端溝通時，通常把這句話講在最前面，因為它能預防掉後面一整串衍生的毛病，比事後一個一個抓紅字有效率得多。
2. aria 屬性寫錯，為什麼比不寫更傷
很多人以為加了 aria 屬性就等於「有做無障礙」，但 aria 是一套需要前後對應的契約，寫錯的 aria 會主動誤導輔助技術，比完全不寫還糟。那家廠商的頁面就同時踩到兩種：一種是明確的錯誤，一種是可優化的冗餘。
2.1 指向不存在 ID 的 aria-labelledby 是明確錯誤
頁面裡有一個彈窗容器，它的 aria-labelledby 指向 exampleModalCenterTitle 這個 ID，但整個頁面裡根本沒有這個 ID 的元素。這是明確的錯誤，不是風格問題。螢幕閱讀器要唸出彈窗標題時，會找不到對應內容，使用者聽到的是一個沒有名稱的對話框。修法有兩條：要嘛補上一個帶對應 ID 的標題元素，例如 <h5 id="exampleModalCenterTitle">；要嘛直接把這個錯誤的 aria-labelledby 移掉。我們偏好前者，因為彈窗本來就該有標題。這類指向落空的屬性，我們會當成明確錯誤優先處理，因為它是確定在製造問題，而不是可能有風險而已。
2.2 有 aria-labelledby 卻沒有正確 role 的區塊
另一種是語言選單和一般彈窗的容器，用了 aria-labelledby 卻沒有搭配合適的 role。這不算明確錯誤，但屬於冗餘：輔助技術拿到一個標籤關聯，卻不知道這個容器是什麼角色。我們的判斷標準是先問「這個容器真的需要被命名嗎」，需要就補上正確的 role（選單用 menu、彈窗用 dialog），不需要就把 aria-labelledby 拿掉，別留著半套。半套的 aria 就像一句只講一半的話，輔助技術反而得花力氣去猜你沒講完的部分。
2.3 我們驗收 aria 的三個順序
我們在實務上驗收 aria 有固定順序，可以幫你少走冤枉路。第一，先確認每個 aria-labelledby 和 aria-describedby 指到的 ID 都真實存在，這一步用瀏覽器搜尋 ID 就能抓出來。第二，確認有 aria 關聯的容器都掛了對應的 role。第三，才去看語意合不合理。順序反過來做，你會在細節裡卡住，卻放過最嚴重的斷鏈。我們之所以把「指向存不存在」放第一，是因為那是最容易客觀驗證、也最確定在傷害使用者的一類，先把確定的錯誤清乾淨，再處理灰色地帶，效率最高。
3. 圖片的 alt 與尺寸，兩件常被一起漏掉的事
圖片問題在檢測報告裡通常分散在不同項目，但根源往往是同一套上稿流程沒把關。那家廠商的首頁有圖片缺 alt，也有圖片的尺寸屬性寫法錯誤，我們習慣把這兩件一起收，因為它們都發生在「圖片被放上頁面」的那一刻。
3.1 缺 alt 的圖，搜尋引擎與螢幕閱讀器都讀不到
首頁有一張產品影片的圖片沒有 alt 屬性。alt 是圖片的文字替身，搜尋引擎靠它理解圖片內容、決定要不要收進圖片搜尋；視障使用者則靠它知道這張圖在講什麼。少了 alt，這張圖對兩邊都是空白。我們給客戶的原則是：凡是後台能上稿的圖片欄位，都要有 alt 填寫的地方，而且 alt 要描述圖片實際內容，不是塞關鍵字。像那張影片縮圖，合理的 alt 就是描述它是產品影片的示意畫面，而不是硬塞一串產品型號。把 alt 當成替看不到圖的人轉述畫面，方向就不會跑掉。
3.2 width 與 height 寫成 80px 為什麼是錯的
另一張聯絡我們的圖示，尺寸屬性寫成 width="80px" height="80px"。HTML 的 width 和 height 屬性只接受純數字，單位是像素但不能寫出 px。寫了 px 在寬鬆的瀏覽器裡會被忽略、退回預設行為，在嚴格模式下會被當成無效值。正確寫法是 width="80" height="80"。這個屬性除了正確性，還有一個實際好處：瀏覽器在圖片載入前就知道它要佔多大空間，能預留位置，減少頁面載入時的版面跳動。單位寫錯，這個好處就拿不到。我們處理時會連同這類小語法一起掃過，因為它單看影響不大，累積起來卻是一堆可避免的版面晃動與檢測紅字。
3.3 我們給客戶的圖片交付清單
我們的做法是把圖片驗收做成一張清單交給前端，免得每次上稿都重犯。下面這張表是我們實際在用的版本，你可以直接拿去對照。
| 檢查項目 | 錯誤示範 | 正確做法 | 影響面 |
|---|---|---|---|
| alt 屬性 | 完全省略，或塞一串型號 | 描述圖片實際內容的短句 | 圖片搜尋、無障礙 |
| 尺寸單位 | width=”80px” | width=”80″ | 相容性、版面穩定 |
| 裝飾性圖片 | 給一段無意義 alt | alt 留空字串，交給 CSS 背景 | 螢幕閱讀器體驗 |
| 尺寸屬性缺漏 | 只給 src，不給寬高 | 補上寬高，讓瀏覽器預留空間 | 載入時的版面跳動 |
4. 只給爬蟲看、對使用者隱藏的內容，風險比效益高
最後這個問題和前面幾個性質不同，它不是疏忽，而是刻意為之的手法，而且是我們會第一優先請客戶拿掉的。那家廠商的首頁有一個帶特定 class 的隱藏 h1，只對爬蟲顯示、對使用者隱藏，另外還有一個同樣手法的隱藏區塊。這類做法一旦被判定為刻意區別對待，代價遠比省下來的那點版面高。
4.1 隱藏 h1 為什麼是紅線
對搜尋引擎和使用者呈現不同內容，是各大搜尋引擎品質規範明令禁止的行為。就算你藏的內容本身沒問題，只要被判定為「刻意只給爬蟲看」，就有被降級的風險。h1 應該是頁面上看得見、也最重要的那個標題，把它藏起來只給爬蟲，等於自己踩線。我們的處理是把隱藏 class 移除，讓 h1 正常顯示；如果版面上放不下一個大標題，那就重新設計版面，而不是把它藏起來。設計上的難題要用設計解，不是用遮蔽解，後者省的是眼前的麻煩，換的是長期的信任風險。
4.2 那些「不影響 SEO」的隱藏區塊要不要一起清
另一個隱藏區塊放的是一段案例分類文字，單看它對排名的直接影響很小。但我們的建議還是清掉：爬蟲對頁面語意的分析一直在演進，今天無害的隱藏 class，難保哪天被納入判斷。與其留著說不清的灰色地帶，不如趁改版一次收乾淨。我們看待這類東西的原則是，凡是「只給機器看、不給人看」的內容，不論現在判不判，都屬於遲早要還的技術債，能早清就早清。
4.3 想隱藏又想保留語意，有沒有兩全的做法
如果你的目的是視覺上隱藏、但保留給輔助技術讀取，那要用的是正規的可及性隱藏寫法，而不是整個 display:none 再偷塞給爬蟲。兩者的差別在於意圖：前者是讓螢幕閱讀器使用者和視覺使用者拿到對等的資訊，後者是對人與機器呈現不同內容。判斷的關鍵很簡單：你隱藏這段，是為了照顧某一群使用者，還是為了對機器多講一套。前者合理，後者就是我們會請你拿掉的那種。
5. 我們實際跑一次無障礙檢測的順序
5.1 先分出「明確錯誤」和「可優化」兩堆
拿到一份無障礙檢測報告，第一件事不是從上到下逐條修，而是先把問題分成兩堆：一堆是確定在製造問題的明確錯誤，例如指向不存在 ID 的 aria、只給爬蟲看的隱藏標題、完全缺 alt 的資訊性圖片；另一堆是可優化的冗餘或風格問題，例如沒搭 role 的 aria、裝飾圖的 alt 寫法。這樣分的理由是，明確錯誤是已經在傷害使用者或違反規範的，可優化項則是「不改也還過得去、改了更好」的。我們會先把明確錯誤這堆清乾淨，因為它們的投報比最高，一個動作就消掉一個確定的傷害。那家廠商的首頁我們就是這樣切的，先盤出幾個非修不可的紅字，剩下的才排進後續優化。
5.2 同源的問題一起收，別一條一條跳著修
分完堆之後，我們會把同源的問題綁在一起處理，而不是照報告的條目順序跳著修。圖片的 alt 缺漏和尺寸單位寫錯，往往都出在同一套上稿流程沒把關，與其一張張圖去補，不如回頭把上稿的欄位與規範修好，之後的圖片就不會再犯。標題階層的跳級和空標題也類似，根源多半是把標題當字級控制器，把這個觀念跟前端講清楚，比事後一個一個抓標題有效率。我們替客戶做的時候，會刻意去找這些問題的共同來源，因為檢測工具是按現象列清單的，真正省力的修法是從現象回推到那個一次造成多個紅字的流程缺口。
5.3 修完自己用鍵盤與檢視原始碼各走一遍
改完之後，我們一定會做兩個驗證。第一個是用鍵盤的 Tab 鍵走一遍頁面，看焦點順序順不順、彈窗能不能被正確唸出標題、選單是不是能操作，這一步最能抓出 aria 與 role 有沒有真的補對。第二個是檢視原始碼，確認標題階層是逐級的、重要內容都在初始 HTML 裡、沒有殘留只給爬蟲看的隱藏區塊。檢測工具能抓出大部分語法層的問題，但「使用者實際操作起來順不順」還是得自己走一遍才算數。我們的經驗是，很多看起來檢測工具給過的頁面，實際用鍵盤一操作就會發現焦點亂跳或唸不出名稱，這類問題報告不一定標得出來，卻是使用者真正會踩到的。
6. 常見問題
6.1 標題階層跳級真的會影響排名嗎?
直接的排名扣分通常不明顯，但它會稀釋頁面重點的傳達，讓爬蟲更難判斷哪一段是核心內容。對競爭激烈的關鍵字，這種語意清晰度的差距會被放大。我們的立場是：它不是致命傷，卻是低成本就能修好的基本功，沒有理由放著。與其糾結它扣幾分，不如把它當成讓頁面語意更乾淨的順手之舉。實務上我們也觀察到，標題階層一旦理清，連帶整頁的內容大綱都會變得清楚，這對後續想做段落層級的優化、或想被 AI 摘要挑中，都是打底的工作，省下的是未來反覆回頭整理結構的成本。
6.2 alt 文字應該寫多長、要不要放關鍵字?
以能準確描述圖片內容為原則，通常一句話就夠，不必寫成一整段。關鍵字如果自然出現在描述裡沒問題，但刻意堆疊會被視為濫用，反而扣分。純裝飾用的圖片，alt 留空字串即可，讓螢幕閱讀器直接略過。判斷標準是：如果你把圖片遮住，只讀 alt，能不能大致知道這裡原本有什麼，能的話就寫得差不多了。我們也提醒客戶，同一張圖在不同頁面的脈絡下，合理的 alt 可能不一樣，重點是描述它在這個位置要傳達的訊息，而不是套用一組固定字串。
6.3 aria 屬性一定要加嗎，不加會怎樣?
原生 HTML 元素本身多半自帶語意，像按鈕、連結、表單欄位，這些用對標籤就不太需要額外 aria。aria 是補原生語意不足時才用的工具。與其到處亂加，不如先確認有沒有用對原生標籤。錯誤的 aria 會主動誤導輔助技術，這種情況下不加反而比較好。先把原生語意用對，再看哪裡真的需要 aria 補強，順序別顛倒。我們在實務上看過不少頁面，原本用對原生按鈕就好，卻硬套一層 role 和一堆 aria，結果屬性之間彼此打架，輔助技術反而唸出一串令人困惑的描述。這種時候把多餘的 aria 拿掉、讓原生語意自己講話，體驗立刻乾淨許多。
6.4 width 和 height 屬性和 CSS 的寬高有衝突嗎?
不衝突，兩者分工不同。HTML 屬性給瀏覽器一個載入前的尺寸提示，用來預留空間、減少版面跳動；CSS 負責實際的顯示尺寸與響應式縮放。標準做法是兩邊都給，HTML 屬性寫純數字的原始像素值，CSS 再用 max-width 之類的規則做彈性調整。把它們當成各司其職，而不是二選一，版面才又穩又能自適應。漏掉 HTML 的寬高屬性，最直接的後果就是圖片載入前後那一下版面晃動，不只影響體驗，也會反映在頁面穩定度的指標上。
6.5 無障礙做好了，對搜尋引擎的實際幫助有多大?
兩者不是同一個評分系統，但共享很多底層訊號。清楚的標題結構、完整的 alt、正確的語意標籤，同時服務螢幕閱讀器和爬蟲。我們在實務上看過把無障礙基礎補齊後，頁面在圖片搜尋和語意理解上一起變好。把它當成內容品質的一環，而不是額外負擔，收益會比較實在。與其把無障礙當成合規的苦差事，不如把它看成順手讓機器也讀得更懂你的投資。要補充的是，無障礙做好不代表排名就會跳，它比較像是把頁面語意的地基打平，讓後續的內容與連結更容易發揮；反過來，一個滿是語意破洞的頁面，再好的內容也可能被爬蟲誤讀。所以我們通常把無障礙基礎當成內容上線前的衛生條件，而不是期待它單獨帶來名次的工具。