全球超過四成的網站是用 WordPress 架設的，這是 W3Techs 最新統計出的數字。這麼多網站共用同一套系統，一份好用的 WordPress 上線前檢查清單，該盤點的關卡也高度共通：不管你經營的是部落格、公司形象網站還是線上商店，容易被漏掉的往往就是那幾項。
架站期間，為了避免搜尋引擎收錄半成品、方便自己測試，你通常會先開啟幾個暫時性設定：在「設定」裡勾選不允許搜尋引擎索引、放上示意用的佔位文字與測試圖片、留一組方便自己登入的測試帳密。這些設定在開發階段很合理，卻常在按下發布鍵那一刻被忘記。問題不是網站本身沒做好，而是最後一哩路的檢查漏了。
這篇把永久連結、SEO 基礎設定、安全性、備份、選單這幾項你原本分散學過的東西，整合成一份「按下公開前」的總檢查表，也把這幾年才冒出來的新功課一起算進去，那就是 AI 搜尋引擎讀不讀得懂你的網站。先從最容易被忽略的殘留內容講起，再一路盤到上線後你該盯的事。
頁面上還留著佔位文字或測試圖片嗎？
架站過程中，為了先看排版效果，你通常會塞進佈景主題內建的示範文字與示範圖片。這一類內容最容易被忽略，也最容易在上線後被訪客抓包。上線前，這幾樣值得你逐一點開來看一次：
- 佈景主題的示範文字與示範圖片，是否都已經替換成真實內容
- WordPress 預設安裝時附的「Hello World」文章與「Sample Page」頁面，是否已經刪除或改成正式用途
- 每一張圖片是否都補上替代文字（alt text）
- 全站文案是否做過一次完整的錯字校對
替代文字不只是為了 SEO，它同時是無障礙網頁的基本要求。W3C 官方的無障礙標準〈Web Content Accessibility Guidelines〉就把圖片替代文字列為國際通用的基礎準則，讓使用螢幕報讀軟體的訪客，也能理解圖片實際傳達的內容。
如果你的網站用的是區塊編輯器或網站編輯器（Site Editor）環境，示範內容常常是以「樣式」「版型」的形式匯入，不是單純躺在文章列表裡，比舊版經典編輯器更容易被漏看。某個子頁面套用的版型裡，可能還藏著範例文字，檢查時別只看文章列表，版型與區塊樣式也要點開來看一遍。
永久連結的結構，上線後最好別再動
永久連結（permalinks）決定的是網址的長相，也就是每篇文章、每個頁面最終呈現的網址結構。這件事在上線前定案很重要：內容一旦被搜尋引擎收錄、被其他網站或社群分享出去，事後再更動網址格式，等於讓所有已經存在的連結全部失效，除非另外設定轉址規則。與其上線後補救，不如在公開之前就把「設定→永久連結」的結構確認好，之後盡量不再變動。
跟永久連結綁在一起、也該一併確認的是網域版本。同一個網站如果同時存在「有 www」和「沒有 www」、或「http」和「https」都能被訪客打開，等於同一份內容被搜尋引擎當成兩個不同網址，會被判定為內容重複。上線前要確定唯一的正式版本，並把其他版本都設好轉址到這個版本；內部連結與選單，也要逐一確認是導向正式網域，而不是還留著開發階段用的測試網址。
WordPress.org 官方文件〈Settings Permalinks Screen〉對永久連結設定有完整說明，值得在上線前重新讀一次，確認沒有漏掉的選項。
SEO 基本設定，搜尋引擎找不找得到你？
上線前最容易漏掉、卻也最影響能不能被收錄的，是幾項基礎的 SEO 設定，也是這份 WordPress 上線前檢查清單裡最關鍵的一段。這裡不重講關鍵字研究或內容策略這類需要長期經營的事，只聚焦一件事，也就是該設定的地方，你有沒有真的設定對。
「不允許搜尋引擎索引」的勾選，拿掉了嗎？
多篇研究到的上線清單，不約而同把這件事列為頭號地雷。WordPress 在「設定→閱讀」裡有一個「勸阻搜尋引擎索引本網站」的選項，開發階段為了避免半成品被收錄，常常會先勾選起來。問題是，這個設定一旦忘記在上線前取消，不管網站做得再完整、內容再好，搜尋引擎都不會把它收進索引，整個網站對搜尋引擎來說形同隱形。
要確認這件事，建議你雙重檢查：第一次在後台路徑直接查看設定是否已取消勾選；第二次用瀏覽器檢視網頁原始碼，或用線上工具查一次首頁的 meta 標籤，確認沒有殘留 noindex 標記。Google Search Central 官方文件〈Robots meta tag， data-nosnippet， and X-Robots-Tag〉對 noindex 標籤的運作方式有清楚說明。有些外掛快取或 CDN 快取，會讓後台的設定跟實際輸出的網頁內容不同步，確認完設定之後，記得也把快取清乾淨，才能確保你檢視到的是真正生效的版本。
標題、描述與 Sitemap，各頁都設定了嗎？
檢查完索引開關，接著看的是每個頁面能不能被正確理解與收錄。先看每個頁面是不是都有獨立、不重複的標題與描述，多數 SEO 外掛都能批次檢查這件事；重複的標題與描述，會讓搜尋引擎搞不清楚該把哪一頁排在前面。
接著確認 XML Sitemap 是否已經產生、連結能不能正常打開，以及 robots.txt 有沒有不小心擋到重要的頁面或目錄。多數上線清單只提醒一句「要有 sitemap」，卻沒講清楚順序。正確的做法是在上線前就先把 Google Search Console 的資源備妥，等網域正式生效的當下立刻送出 sitemap，縮短第一次被爬取的等待時間，而不是等網站上線好幾天之後才想起這件事。Google Search Console 官方說明中心的〈Sitemaps report〉對這套提交流程有完整說明。
AI 搜尋引擎，讀得懂你的網站內容嗎？
這是研究到的多篇上線清單都沒提到的一塊，卻是最近才真正該補上的功課。現在的搜尋引擎不只 Google 一家，ChatGPT、Claude、Perplexity 這些 AI 助理，都有各自的爬蟲會抓取網站內容，用來訓練模型或即時回答使用者的問題。上線前值得確認的是，robots.txt 有沒有不小心把這些爬蟲全部擋在外面。有些資安外掛的預設規則，或是舊版留下來的防爬設定，常常會連 AI 爬蟲一起封鎖掉，而不是只擋惡意程式。
值得先弄清楚的是，「訓練用」的爬蟲跟「即時查詢用」的爬蟲並不是同一件事，你可以分開決定要不要放行。OpenAI 官方文件〈Overview of OpenAI’s crawlers〉把 GPTBot 定義為蒐集訓練資料用的爬蟲，ChatGPT-User 則是使用者向 ChatGPT 提問時，即時造訪頁面來協助作答的爬蟲（另外還有專門讓網站出現在 ChatGPT 搜尋結果裡的 OAI-SearchBot，官方註明同樣不用於模型訓練）。Anthropic 官方說明〈Does Anthropic crawl data from the web， and how can site owners block the crawler？〉也把 ClaudeBot（訓練用）跟 Claude-User（回答使用者提問時即時抓取）分成兩支獨立的爬蟲，各自可以單獨允許或封鎖。
Perplexity 官方文件〈Perplexity Crawlers〉則說明，PerplexityBot 是用來把網站收錄進 Perplexity 搜尋結果的爬蟲，Perplexity-User 才是使用者向 Perplexity 提問時，即時造訪頁面來協助作答的爬蟲；官方特別註明這兩支爬蟲都不會被拿去蒐集資料訓練 AI 模型。Google 官方〈Google’s common crawlers〉則說明 Google-Extended 這個控制項，決定的是內容能不能被用來訓練 Gemini 等生成式 AI 產品，跟一般的 Googlebot 收錄與排名是分開運作的。
也就是說，不想讓網站內容被拿去訓練模型，不代表要連使用者用 AI 助理查資料時都找不到你的網站，這兩件事可以分開設定。舉例來說，一份 robots.txt 可以只擋訓練型爬蟲，放行查詢型爬蟲：
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-User
Allow: /
User-agent: Perplexity-User
Allow: /Code language: plaintext (plaintext)
還有一個常被問到的名詞是「llms.txt」，目前部分網站開始嘗試在網站根目錄放一份給 AI 閱讀的摘要檔案。這屬於還沒有成為正式標準的可選做法，不是上線前的必要條件，不用因為還沒做就覺得網站沒準備好。放行或封鎖 AI 爬蟲的決定，才是這一節真正該花時間確認的事。
SSL 憑證與帳號防護，先確認這幾項
安全性在這裡只做「上線前最後確認」的濃縮版，不重講完整的新手安全設定教學，只挑幾項沒做會直接出事的項目。
第一項是 SSL 憑證。確認憑證正確安裝之後，也要留意瀏覽器有沒有跳出混合內容警告，這代表網頁裡還有部分資源，像圖片或指令碼，仍然用不安全的 http 載入，瀏覽器會因此把整個頁面標示為不安全，即使憑證本身沒有問題。
第二項是帳號。系統管理員帳號是不是還在用預設的「admin」，密碼強度夠不夠，這兩件事合在一起看，決定的是網站最外層的防線夠不夠扎實。最後一項是版本更新：WordPress 核心、佈景主題與所有外掛，是否都已經更新到最新版本，舊版本留著的已知漏洞，是攻擊者最常利用的入口。WordPress.org 官方文件〈Hardening WordPress〉對這幾項安全建議有完整整理，涵蓋帳號設定與更新頻率兩個面向。
備份沒測過還原，都不算數
多數上線清單的盲點在這裡。只確認「有裝備份外掛」就當作這件事做完了。但備份真正該檢查的，是排程有沒有真的啟用中、最近一次備份是不是確實成功執行，而且要實際做過一次還原測試，確認真的能救回來，而不是等網站真正出事那天，才發現備份檔案本身是壞的，或者根本沒人知道還原的步驟該怎麼操作。
WordPress.org 官方文件〈Backups〉特別強調，備份的範圍要同時涵蓋檔案與資料庫。少了任何一邊，還原出來的網站都不完整。資料庫沒備份到，文章內容全部消失；檔案沒備份到，佈景主題與上傳的圖片救不回來。這也是為什麼「備份排程開著就好」不夠，還原測試才是真正能證明備份有效的那一步。
選單、404 頁面與表單，訪客走得通嗎？
前面幾節多半是後台設定，這一節換個角度，把「訪客實際走一遍網站」該檢查的項目整理出來，分成導覽與表單兩個面向。
導覽選單與連結，有沒有走到死路？
主選單、頁尾選單裡的每一個項目，是否都導向正確的頁面，而不是還留著測試站當時用的舊網址。內文裡的連結也要重新點過一輪，確認沒有連到 404 錯誤頁。更重要的是，網站本身要有一個自訂的 404 頁面，而不是主機或 WordPress 內建的陽春錯誤畫面。訪客不小心點到失效連結時，自訂的 404 頁面能把他導回站內，繼續找到原本想看的內容，而不是直接關掉分頁離開。
每個表單，都送出測試過了嗎？
表單顯示正常，不代表它真的能用。上線前要用一組真實的信箱，實際送出一次測試，確認通知信真的寄到該收的信箱，而不是落入垃圾郵件匣；回覆地址（reply-to）是不是設定正確；自動回覆的內容讀起來合不合理，有沒有還留著測試用的字句。如果網站有串接第三方服務，像電子報平台或線上預約系統，也要確認接的是正式環境的金鑰，而不是還留在測試環境裡的那一組，金鑰接錯，表單看起來能送出，資料卻進不了正式系統。
上線前，速度與跨裝置顯示都測了嗎？
功能都確認過之後，接著該測的是速度與顯示。用 Google 官方的效能檢測工具檢查一次核心網頁指標（Core Web Vitals）：最大內容繪製（LCP）在 2.5 秒內、互動下一次繪製（INP）在 200 毫秒內、版面穩定度（CLS）在 0.1 以下，是 Google 官方 web.dev〈Web Vitals〉頁面訂出的「良好」門檻。
有一個細節特別容易被忽略。首屏（above the fold）的主視覺圖不該設定延遲載入（lazy load）。延遲載入原本是用來加速頁面的技巧，但如果連使用者一打開就看到的主視覺圖都套用這個設定，反而會拖慢最大內容繪製的時間，等於好心辦壞事。快取是否真的有作用，也不能只靠「裝了外掛就假設它在運作」這種想法，你可以打開瀏覽器的開發者工具，查看回應標頭裡的快取狀態，確認真的有命中快取，而不是每次都重新產生頁面。
跨裝置測試也一樣不能只靠瀏覽器內建的模擬器。模擬器能模擬螢幕尺寸，卻模擬不出真機的網路環境、輸入方式與瀏覽器版本差異，最好找一支實體手機，實際滑過一輪主選單、表單與比較長的頁面，很多在模擬器上看起來沒事的問題，只有在真機上才會冒出來。
上線當天怎麼按，上線後該盯什麼？
前面每一節都在講「該檢查什麼」，這一節換個角度，把它們收束成一條時間軸，上線當天該按什麼順序做，上線後第一天你又該盯著什麼。
按下發布前，這幾件事的順序不能顛倒
多數清單只列出項目，沒講先後順序，實際操作時順序顛倒很容易出狀況。建議的順序是這樣：
- 先手動做一次完整的備份快照，不是等排程執行，而是上線前自己再存一次當下的版本
- 確認網域與 DNS 已經指向正式的主機空間
- 回到「設定→閱讀」，取消「不允許搜尋引擎索引」的勾選
- 最後再手動測試一次表單與幾個重要連結，確認一切都在正式網域上正常運作
這個順序本身就是重點。備份留在最後才做，一旦上線過程出狀況，連退回舊版本的機會都沒有。
上線後 24 小時，這幾個地方要盯著
上線不是這份清單的終點。把 Sitemap 送進 Search Console 申請索引，是你該做的第一件事，愈早送出，愈早開始被爬取。接著確認流量分析工具是不是真的即時收到資料，不是裝了追蹤碼卻沒有正確觸發。
也要重新檢查一次正式網域的 SSL 是否正常，正式網域跟先前測試網域的憑證設定可能不一樣，不能假設測試環境沒問題，正式環境就一定也沒問題。這 24 小時裡，也要留意表單信箱與留言區有沒有出現異常，愈早發現問題，愈早補救。
這份 WordPress 上線前檢查清單不是只在第一次上線那天用一次，用完就可以丟進抽屜。任何一次大改版、換佈景主題，或是搬遷主機，都值得你重新跑一遍，道理跟第一次上線是一樣的。設定被改動過，舊的檢查結果就不再算數。尤其是 AI 搜尋引擎與爬蟲規則，眼下還在快速變動的階段，現在放行的名單，半年後可能就該重新檢視一次。把這份清單存起來，下一次改版時，直接照著再走一輪就好。