WordPress 區塊編輯器發布前 QA｜標題、圖片 Alt、預覽與 SEO 檢查

WordPress 區塊編輯器讓內容排版比舊版 classic editor 更直覺：標題、圖片、引言、按鈕、表格與嵌入都可以用 block 組合。但越方便的工具，也越容易讓人把發布流程當成「看起來差不多就按 Publish」。

對長期經營的技術 Blog 來說，發布前 QA 不是拖慢速度，而是把容易返工的問題提早攔下來：標題層級是否合理、圖片 Alt 是否能描述內容、手機預覽是否可讀、內部連結是否有效、SEO 摘要是否像真人會點的搜尋結果。

先把區塊編輯器當成內容驗收介面

Gutenberg 的優點不是只有拖拉區塊，而是它把文章結構拆成可檢查的單位。發布前可以沿著這幾個層次看：

文章結構：H1 只留給文章標題，內文從 H2 / H3 組織段落。
媒體資產：每張重要圖片都要有 Alt、尺寸與用途說明。
導讀與摘要：excerpt、SEO title、meta description 要能獨立說明文章價值。
閱讀體驗：手機預覽、表格、程式碼區塊、按鈕與嵌入內容不能破版。
發布證據：上線後至少確認文章頁、分類頁、搜尋摘要或社群預覽資料。

這些檢查不需要變成厚重表單，但最好能留下紀錄，否則下一次改版或排查 SEO 問題時會不知道當初驗收過什麼。

標題層級：先看大綱，再看文字

發布前第一個動作是檢查文章大綱。很多文章不是內容不好，而是 H2 / H3 被當成視覺大小使用，導致搜尋引擎與螢幕閱讀器看到的結構很混亂。

我會用這個規則快速判斷：

文章標題是唯一 H1。
主要段落使用 H2。
H3 只用來補充上一層 H2，不跳級裝飾。
不用空標題區塊製造間距。
若標題本身太長，先改文案，不要只靠 CSS 硬縮。

如果文章是教學或 troubleshooting，H2 最好能讓讀者只看目錄就知道流程順序。例如「症狀」、「先備份」、「觀察錯誤」、「隔離外掛」、「發布後驗證」，比一串抽象口號更容易被搜尋與重用。

圖片 Alt：不是塞關鍵字，而是描述用途

區塊編輯器每次插入圖片時，都應該順手補 Alt。Alt 不是 SEO 關鍵字倉庫，而是在圖片無法顯示、或使用螢幕閱讀器時，幫讀者理解圖片用途。

一個好 Alt 可以包含：

圖片主體：例如 WordPress 區塊編輯器畫面、手機預覽、錯誤訊息。
使用情境：例如發布前 QA、圖片 Alt 欄位、標題層級檢查。
必要資訊：如果圖片是流程圖或截圖，描述它在文章中要證明什麼。

避免這種寫法：

WordPress SEO 圖片 最佳化 Gutenberg 發文 教學

比較好的寫法是：

WordPress 區塊編輯器發布前 QA 截圖，顯示圖片 Alt 欄位、手機預覽與標題層級檢查項目

如果圖片只是裝飾，也可以讓 Alt 保持空值；但文章主圖、步驟截圖、錯誤畫面通常不該空白。

手機預覽：不是只看首頁，而是看文章內文

許多 WordPress 內容問題是在桌機編輯器裡看不出來的。發布前至少用 preview 檢查一次手機寬度：

表格是否需要橫向捲動，還是可以改成短列表。
長網址、指令、Prompt 是否把版面撐出水平捲動。
圖片比例是否正常，是否出現被裁切到失去意義的截圖。
CTA 按鈕文字是否過長，手機上是否換行難看。
嵌入 YouTube、社群貼文或 iframe 是否有保留可讀寬度。

如果是技術文章，我也會特別看 code block。很多問題不是 CSS 壞掉，而是 fenced code block 裡塞了一整行超長指令；與其急著改全站樣式，不如先把範例指令拆成較短且可複製的行。

內部連結：讓新文章接回舊內容

UCAMC 這類長期內容站，內部連結不只是 SEO 裝飾，也是知識庫的路標。發布前可以檢查三種連結：

向前連結：新文章是否能連回既有相關文章，例如 WordPress 維護、圖片 Alt、sitemap 或部署驗證。
向後補鏈：重要舊文是否值得在下一輪整理時補上新文章連結。
分類入口：文章分類是否符合使用者期待，不要只因為「看起來像」就亂放。

例如這篇談發布前 QA，可以延伸閱讀 UCAMC 既有的 WordPress 圖片 CDN 與 Lazy Load 排查、WordPress REST API 健康檢查，以及 Cover / Open Graph 圖片巡檢。

SEO 欄位：用搜尋結果的角度重讀一次

發布前不要只確認 SEO plugin 顯示綠燈。比較實際的做法是把 SEO title 與 description 當成搜尋結果摘要重讀一次：

SEO title:
WordPress 區塊編輯器發布前 QA｜標題、圖片 Alt、預覽與 SEO 檢查

SEO description:
整理 WordPress Gutenberg 區塊編輯器發布前 QA 流程：
檢查標題層級、圖片 Alt、手機預覽、內部連結、SEO 摘要，
並留下發布後驗證紀錄，降低內容上線後返工。

檢查重點是：

標題是否說清楚文章能解決什麼問題。
描述是否具體，不只寫「完整教學」、「最佳指南」。
是否自然包含主要名詞，而不是 keyword stuffing。
若文章有工具、版本或平台限制，是否有在摘要裡提醒。

發布後留下最小驗證紀錄

文章按下 Publish 之後，還有一段很容易被忽略的驗證。最小紀錄可以長這樣：

Observe:
- WordPress preview desktop / mobile 都可讀。
- 文章有 H2 結構、主圖 Alt、SEO title 與 description。

Change:
- 補上內部連結到相關 WordPress 維護文章。
- 修短一行過長 Prompt，避免手機 code block 視覺裁切。

Verify:
- 正式文章 URL 200。
- 分類頁看得到新文章。
- 主圖載入 200 且 Alt 描述符合內容。
- 社群預覽 / Open Graph 圖片沒有抓到舊圖。

這份紀錄不用很長，但它能讓團隊之後知道：這篇文章不是「憑感覺發布」，而是有檢查過結構、圖片、手機閱讀與搜尋摘要。

結語：把 Publish 變成可重複流程

WordPress 區塊編輯器已經把內容製作拆成一個個可操作的 block；網站經營者要做的，是把發布前後的檢查也拆成可重複的步驟。

當標題層級、圖片 Alt、手機預覽、內部連結與 SEO 摘要都留下基本證據，文章就比較不會在上線後才發現主圖不符、摘要空泛、手機破版或分類錯位。這也是 UCAMC 經營技術內容時最重視的方向：不只發文，而是讓每一篇文章都能被驗證、被回查、被下一次維護繼續使用。

WordPress 區塊編輯器發布前 QA：把標題、圖片 Alt、預覽與 SEO 檢查留成紀錄