客戶看著網站數據一臉困惑：「為什麼搜尋流量進來，停留時間都不到 5 秒？」打開 Elementor 編輯的搜尋結果頁，輸入一個站內根本不存在的關鍵字，頁面上只看到一個空洞的標題，下方文章區塊完全空白——沒有錯誤提示、沒有導引連結、沒有任何線索告訴訪客接下來該做什麼。這就是流量流失的起點。
WordPress 預設佈景會在搜尋無結果時自動顯示「找不到符合的內容」，但 Elementor 的 Loop Grid 或 Posts Widget 預設不會這麼做。它只會安靜地渲染一個空的容器，把訪客晾在那裡。與其讓訪客困惑地按上一頁離開，不如把這個空白頁面轉換成留住流量的中繼站。
內容導覽
為什麼 Elementor 搜尋頁不會自己顯示「找不到結果」
WordPress 的搜尋機制在查無結果時，會回傳一個正常的 HTTP 200 狀態，並透過佈景的 search.php 模板或 no-posts-found 鉤子來處理無結果畫面。但 Elementor 的 Theme Builder 走的是另一條路：它繞過傳統模板層級，直接操控內容區塊的渲染。當 Loop Grid 查詢不到文章時，Elementor 的預設行為是不輸出任何內容——沒有 fallback 文字、沒有錯誤狀態，就是一片空白。
這不是 bug，是 Elementor 的設計哲學：把畫面控制權完全交給設計者。但問題在於，多數人在建置搜尋結果頁時，只想到「有結果時怎麼排版」，忽略了「沒結果時該顯示什麼」。要補上這個缺口，我們需要在前端動態偵測 DOM 狀態，並在確認無結果後插入自訂提示。
動態偵測無結果並替換提示文字的核心方案
核心思路是：在頁面載入後，用 JavaScript 檢查文章列表容器內是否有子元素，如果沒有，就把原本的搜尋標題動態改寫成包含關鍵字的無結果提示。之所以用前端處理而非 PHP 過濾器，是因為 Elementor 的 Loop Grid 在伺服器端很難精確攔截「有幾個搜尋結果」這個資訊，直接操作 DOM 反而更可靠。
完整程式碼與放置位置
將以下程式碼放入子佈景的 functions.php，或透過 Code Snippets 外掛新增為 PHP 片段，選擇在前台全域執行：
function modify_no_results_message_for_elementor_search_page() {
// 只在搜尋結果頁執行，避免影響其他頁面
if ( ! is_search() ) {
return;
}
?>
<script>
document.addEventListener("DOMContentLoaded", function () {
function checkSearchResults() {
// Elementor 搜尋結果頁的常見內容容器選擇器
let contentBlocks = document.querySelectorAll(
".elementor-posts, .elementor-loop-container, .elementor-posts-container"
);
// 取得搜尋結果標題元素（通常是第一個 heading widget）
let resultTitle = document.querySelector(".elementor-heading-title");
// 從 WordPress 注入的搜尋關鍵字
let searchQuery = "<?php echo esc_js( get_search_query() ); ?>";
let hasResults = false;
contentBlocks.forEach(function(block) {
// 如果容器內有任何子元素，代表有搜尋結果
if (block && block.children.length > 0) {
hasResults = true;
}
});
// 無結果時改寫標題文字，保留原始 HTML 結構
if (!hasResults && resultTitle) {
resultTitle.innerHTML =
'很抱歉，沒有找到與「<span style="color: #d97342; font-weight: bold;">' +
searchQuery +
'</span>」相關的內容，請嘗試其他關鍵字。';
}
}
// 等待 500ms，確保 Elementor 的 AJAX 或 Loop Grid 已完成渲染
setTimeout(checkSearchResults, 500);
});
</script>
<?php
}
add_action( 'wp_footer', 'modify_no_results_message_for_elementor_search_page' );選擇器調整指南
上面程式碼中的 .elementor-posts 和 .elementor-loop-container 是常見的預設 class，但實際使用時需要根據你的 Elementor 頁面結構微調。打開瀏覽器 DevTools，找到包住所有文章卡片的最外層 <div>，複製它的 CSS class 或改用更具體的子選擇器即可。
💡 雙重優勢：前端處理比 PHP 過濾器更穩健
- • 不需要深入 Elementor 內部 API，避免版本更新導致程式碼失效
- •
wp_footer鉤子確保 DOM 已經載入完畢，500ms 延遲再給 Loop Grid 足夠的渲染時間，雙重保障
進階做法：在無結果頁面加入實用導引區塊
只顯示「找不到」訊息是不夠的。真正有效的轉換點設計，是在訪客發現沒結果的那一刻，立刻遞出替代方案。你可以用 Elementor 在搜尋結果頁面中額外放置一個 Section，預設隱藏，再用同一段 JavaScript 在確認無結果時把它顯示出來。
可考慮放入的導引元素
- 熱門文章列表：手動挑選 5 篇流量最高的內容，讓訪客有地方可去
- 重新搜尋的輸入框：避免訪客還要滾回頁首才能再搜一次
- 分類或標籤雲：協助訪客用瀏覽方式找到相關內容
- 聯繫表單或 CTA：如果內容無法滿足需求，給一條直接聯繫的路徑
顯示無結果專屬區塊的程式碼延伸很簡單，在 if (!hasResults) 區塊內加上一行 document.querySelector('.no-result-section').style.display = 'block'; 即可。記得在 Elementor 中將那個 Section 的 CSS class 設為 no-result-section 並預設 display: none。
踩坑提醒與實務開發建議
一、setTimeout 秒數不是越長越好
500ms 是多數情況下足夠的等待時間，但如果你的頁面載入了大量圖片或使用延遲載入外掛，可能需要在 Loop Grid 完成後才觸發檢查。一個更穩健的做法是改用 MutationObserver 監聽容器內子元素的變化，避免計時器誤判。但對九成以上的 Elementor 站點來說，500ms 直接可用，不需要過度工程化。
二、選擇器失效時不會噴錯，但也不會有效果
這段程式碼的特性是「安靜失敗」：如果 querySelector 找不到指定的元素，程式不會中斷，但也不會顯示任何提示。上線後務必實際輸入一個不存在的搜尋關鍵字測試，確認 DOM 選擇器確實抓到了你的文章容器和標題元素。
三、快取外掛可能造成行為不一致
如果你使用 WP Rocket、W3 Total Cache 等頁面快取外掛，搜尋結果頁通常會被排除在快取規則之外，這是正確的。但如果你曾手動調整過快取規則，或使用某些激進的全站快取設定，可能導致搜尋頁被快取而讓 JavaScript 判斷失準。確認搜尋頁面的 URL 模式（包含 ?s=）不在快取範圍內。
四、如果改用 WordPress 原生搜尋區塊，處理方式不同
近期 WordPress 推出了原生 Search Block 和 Query Loop Block，如果你正在從 Elementor 逐步轉向原生區塊編輯器，無結果處理的邏輯會完全不同：原生 Query Loop 內建了「No Results」區塊，可以直接在編輯器中設定 fallback 內容。這比前端 JS 方案更乾淨，但前提是整個搜尋結果頁必須建立在區塊編輯器上，而不只是局部替換。
