UCAMC
← 回到 Blog
WordPress約 3 分鐘閱讀

WordPress 站內搜尋零結果排查紀錄：從索引、REST API 到使用者關鍵字留下證據

Updated 2026/08/23Leon
分類WordPress網站經營SEO
標籤#WordPress#站內搜尋#內容維護#REST API#SEO#維護紀錄
WordPress 站內搜尋排查 cover，顯示搜尋框、索引資料庫、REST API、快取 header 與驗證完成狀態

站內搜尋是很多內容型網站的隱形入口。讀者不一定會從首頁分類慢慢找，而是直接輸入「SMTP」、「Lazy Load」、「Next.js sitemap」這類關鍵字。如果搜尋頁突然顯示零結果，很容易被誤判成「文章不見了」或「SEO 掉了」，但真正原因可能在關鍵字、搜尋 URL、索引、REST API、快取或前端模板。

我會把 WordPress 站內搜尋問題當成一條可驗證的查詢鏈：使用者輸入什麼、前台送到哪個 URL、WordPress 查詢有沒有命中文章、搜尋外掛或索引是否更新、快取/CDN 是否回舊頁面，以及修復後哪些關鍵字真的恢復。這篇不是要收集真實使用者個資，而是建立一份安全、可回溯的搜尋排查紀錄。

先保存「零結果」的原始症狀

看到搜尋沒有結果時，不要第一時間重建索引或換外掛。先把症狀記下來，尤其是關鍵字、搜尋頁 URL、時間與使用者看到的結果。

Search symptom record
- keyword: SMTP
- search URL: /?s=SMTP
- time: 2026-08-23 09:10 +08:00
- frontend result: 0 results shown
- expected content: form email delivery article exists
- user data: do not store personal query logs here

這個紀錄能避免排查時只剩「好像查不到」。如果同一篇文章用標題可查到、用同義詞查不到，問題可能是內容命名或摘要；如果任何關鍵字都查不到，才更像查詢、索引或模板層的問題。

分開檢查搜尋 URL、文章狀態與 REST API

WordPress 站內搜尋的第一層驗證可以用無破壞性的 GET 請求。先確認搜尋頁存在、目標文章不是草稿或私密文章，再用 REST API 看文章是否能被查到。

curl -I 'https://example.com/?s=SMTP'
curl -s 'https://example.com/wp-json/wp/v2/search?search=SMTP'
wp post list \
  --post_type=post \
  --post_status=publish \
  --s='SMTP' \
  --fields=ID,post_title,post_status

如果 REST API 有結果、前台搜尋頁沒有結果，可能是佈景主題模板、搜尋結果 component 或快取問題。如果 WP-CLI 和 REST API 都沒有結果，就要看文章內容、索引、搜尋外掛設定或資料庫查詢。

搜尋外掛與索引要留下版本與操作紀錄

很多 WordPress 網站會使用 Relevanssi、ElasticPress、Algolia 或主機提供的搜尋服務。這些工具通常有自己的索引狀態；搜尋零結果不一定代表文章不存在，也可能只是索引沒有更新。

Search index observation
- plugin/service: Relevanssi / ElasticPress / native search
- version: record from plugin list
- index status: complete / rebuilding / failed / unknown
- last content update: article published at 08:45
- destructive action: none before evidence saved

如果需要重建索引，我會把它寫成 change record，而不是口頭說「我重跑了一下」。例如：先截下目前索引狀態、記錄外掛版本、執行重建，再用同一組關鍵字驗證結果。這樣即使修復後又復發，也能知道上次有效的是哪個動作。

快取層可能正在回舊的搜尋結果

搜尋頁通常不應該被長時間靜態快取，但 CDN、頁面快取外掛或反向代理設定錯誤時，可能會讓 /?s=keyword 回傳舊 HTML。這時要看 header，而不是只刷新瀏覽器。

curl -I 'https://example.com/?s=SMTP'
curl -I 'https://example.com/?s=SMTP&ucamc_probe=1'

紀錄時可以保留這些欄位：

Cache evidence
- status: 200
- cache-control: no-cache / private / max-age value
- age: 0 or cached seconds
- x-cache / cf-cache-status: HIT / MISS / BYPASS
- query-string bypass: changes result / no change

如果加上測試 query string 後結果正常，原始搜尋頁卻仍然零結果，就要檢查快取排除規則。這比直接停用所有快取外掛更安全，也比較容易回滾。

把關鍵字品質和內容命名一起檢查

不是所有零結果都是技術故障。有時候讀者用「寄信壞掉」搜尋，但文章標題只寫「SMTP handoff」；或文章主要關鍵字都放在圖片裡，搜尋自然命中不到。這時改善內容比調外掛更有效。

Keyword/content mapping
- user keyword: 寄信壞掉
- matching article: WordPress 聯絡表單郵件排錯紀錄
- visible title/excerpt contains: 聯絡表單、郵件、SMTP
- missing synonym: 寄信、收不到信、表單通知
- editorial action: add natural synonym in intro/excerpt if accurate

這種整理要避免 keyword stuffing。好的做法是把真實讀者會說的詞自然放進摘要、第一段或小標，而不是在文章底部堆一串關鍵字。

修復後要用同一組關鍵字回測

搜尋問題最怕「修好了」但沒有留下驗收。每次修復後，我會用同一組關鍵字做 before / after 比對，包含前台、REST API、必要時再補瀏覽器畫面。

Search verification
- keyword: SMTP
- before: 0 frontend results
- after: target article appears in first page
- API check: /wp-json/wp/v2/search?search=SMTP returns target title
- cache check: plain URL and cache-busting URL match
- rollback: restore previous plugin/cache setting if result regresses

如果只改了內容摘要，也要註明是 editorial fix；如果重建索引或改快取規則，就要註明是 operational fix。兩者的風險和回滾方式不同，不應混在一起。

一份可重用的站內搜尋排查紀錄格式

我會把站內搜尋問題收斂成下面這種安全紀錄，讓下一次維護不用重新猜：

WordPress search incident note
- affected keywords:
  - SMTP
  - 寄信壞掉
- affected surface:
  - frontend search page
  - REST API search
  - search plugin index
- evidence before change:
  - status/header summary
  - screenshot or browser note
  - WP-CLI/plugin version summary
- change made:
  - rebuild index / adjust cache bypass / improve excerpt
- evidence after change:
  - target articles visible
  - API result contains target title
  - cache headers no longer serve stale HTML
- rollback:
  - restore previous cache rule or plugin setting

站內搜尋的價值不只在「查得到」。它也能反映內容命名、分類、摘要、同義詞與舊文章整理是否健康。當搜尋排查紀錄累積起來，網站經營者會更清楚讀者如何找內容，也能用更少猜測維護長期內容庫。