許多網站在設計「返回上一頁」功能時，習慣直接用 JavaScript 的 history.back() 或 window.history.go(-1) 來實現。但這樣的作法其實存在風險：當使用者不是透過正常的點擊流程，而是直接從搜尋引擎點進來，或是外部連結跳轉時，這個「上一頁」按鈕可能會帶他們回到一個完全不相關的頁面，甚至是空白頁。對使用者體驗不友好，也可能導致 SEO 層面上的問題，因為搜尋引擎無法正確理解頁面之間的關聯性。
問題分析
從 SEO 的角度來看，JavaScript 的 history.back() 最大的問題是「不具語意」。搜尋引擎在爬取網頁時，主要依賴 HTML 結構與超連結來理解頁面之間的關係。如果「回上一頁」只是透過 JS 操作瀏覽器歷史紀錄，Google 無法確定使用者會被帶往哪個頁面，也就無法建立穩定的鏈結關係。這樣會導致內部連結結構斷裂，降低爬蟲效率。
另外，從使用者體驗角度來看，若訪客是直接從 Google 搜尋結果點進來，這時候「上一頁」按鈕可能會把他送回搜尋引擎頁面，甚至跳到一個完全無關的外部網站。對使用者來說，這樣的結果不但混亂，也會讓人對網站失去信任。
補充：早期錯誤寫法，用「變動參數」硬算上一頁
老舊專案常見的「頁碼 / back 參數」返回上一頁問題
有些專案會透過 ?page=2 或 ?back=/products?page=2&sort=hot 來模擬返回列表頁，但這種設計潛藏不少隱憂：
- 不具語意且易失真： 詳情頁並不知道使用者真正來自哪一個列表（分類、篩選、搜尋結果皆可能不同），硬塞 page 只會「猜錯」。
- SEO 結構不穩： 搜尋引擎看到的只是任意參數，無法穩定理解「詳情 ←→ 上層集合」的結構關係。
- 快取與重複內容： 同一個詳情頁因不同 back/page 參數產生多個 URL 版本，增加 duplicate content 風險。
- 資安風險（Open Redirect）： 若直接將 back 當跳轉目的地且未做白名單驗證，攻擊者可植入外部網址，造成開放式重新導向漏洞。
正確做法：用 PHP 輸出「回上一頁」連結
if (isset($_SERVER[‘HTTP_REFERER’])) {
// 有來源頁就顯示回上一頁連結
echo ‘<a href="’ . htmlspecialchars($_SERVER[‘HTTP_REFERER’], ENT_QUOTES) . ‘">← 回上一頁</a>’;
} else {
// 沒有來源頁就回列表，避免空白畫面
echo ‘<a href="/articles">← 回列表頁</a>’;
}
?>
我的專業建議
在網站設計中，「回上一頁」看似簡單，卻常被誤用 JavaScript history.back() 或早期的動態參數方式，導致搜尋引擎無法辨識內部結構、使用者被帶到錯誤頁面，甚至引發安全風險。
正確做法應該是：
- 使用 PHP $_SERVER[‘HTTP_REFERER’] 輸出穩定的 <a> 超連結。
- 若沒有來源頁，至少提供一個 預設的「回列表頁」路徑，確保 UX 與 SEO 都完整。
- 在輸出時記得做 HTML 過濾，避免 惡意注入。
如此一來，你的網站既能維持 SEO 結構的完整性，又能保障 使用者體驗與安全性，不再踩到「回上一頁」的隱形陷阱。
💡 你在網站設計過程中，也遇過「回上一頁」或其他 SEO 技術問題嗎？
別擔心，我們專門協助企業解決網站架構與搜尋優化的各種疑難雜症。
有任何需求，歡迎聯繫我們，一起讓網站更穩定、更有流量。
