SEO 完整攻略

探索 SEO 的最佳實踐，提升網站能見度與流量。

斷鏈建設法

找出網站失效連結，替換成你的內容。

作者：哇哇工作站更新於：2025年8月18日
斷鏈建設法

正規化策略：統一重複內容

最適用的 rel=canonical 標籤寫法

最適用的 rel=canonical 標籤寫法

在網頁 SEO 裡，rel="canonical" 用來告訴搜尋引擎哪一個 URL 是「正規」版本，以避免重複內容造成分流。以下會說明幾種常見情境，以及怎麼寫出最乾淨、最能被搜尋器接受的 canonical 標籤。

為什麼要用 rel=canonical？

  • 防止重複內容：同一篇文章如果在多個 URL 可見，Google 會把流量分散，導致排名下降。<br/>- 統一權重：將所有變體聚到主頁面，把外部連結的價值集中起來。

基本寫法

  • 必須放在 <head> 區塊內。
  • 只需要一個即可，對於同一篇文章不會有多重標籤。
<head>
  <title>範例：關於 SEO 的完整指南</title>
  <link rel="canonical" href="https://www.example.com/seo-guide" />
</head>

常見錯誤與修正

  • 使用相對路徑：搜尋器會把相對 URL 視為當前頁面，導致 canonical 指向錯誤。
  • 漏寫 http/https：若主站是 HTTPS，必須確保 canonical 也是 HTTPS；否則可能造成混亂。

1️⃣ 多種網址結構的處理範例

假設同一篇文章可以從以下幾個 URL 進入：

  • https://www.example.com/seo-guide?utm_source=google
  • https://www.example.com/seo-guide#section1
  • http://example.com/seo-guide

正規化後的 canonical 應該是：

<link rel="canonical" href="https://www.example.com/seo-guide" />

說明：去掉追蹤參數 utm_*、斷層標籤 #...，以及統一協定為 HTTPS。

2️⃣ 分區／多語言站點的寫法

  • 子目錄分區（如 /en/, /zh-tw/）：「canonical」仍指向主語言或特定語言版本，視需求而定。
  • 多語言 hreflang：若同一篇有不同語言版本，需要同時設置 hreflang 與 canonical。

範例（台灣繁體為主）:

<link rel="canonical" href="https://www.example.com/zh-tw/seo-guide" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/seo-guide" />
<link rel="alternate" hreflang="zh-Hant-TW" href="https://www.example.com/zh-tw/seo-guide" />

3️⃣ 動態參數與搜尋頁面

  • 動態過濾（如 ?page=2）通常不需要 canonical，除非該頁面有獨立內容。
  • 搜尋結果頁：若允許站內搜尋並產生 URL，建議在搜尋結果頁加上 rel=noindex,follow，而不是 canonical 到首頁。

4️⃣ 先後順序與測試

  • 在開發階段，先把所有頁面放上臨時 canonical（如指向自己的 URL），再進行測試。
  • 使用 Google Search Console 的「URL 檢查」工具確認 canonical 是否被正確讀取。

小結

  1. 標籤必須完整：<link rel="canonical" href="...">，不要遺漏屬性。<br/>2. 統一協定與域名：HTTPS + 主域。<br/>3. 去除不必要參數：UTM、hash 等。<br/>4. 配合 hreflang 或 robots 標籤：確保多語言或搜尋頁面處理妥當。

只要按上述步驟，就能寫出既正規又符合搜尋器期待的 rel=canonical，幫助站台在競爭激烈的 SEO 環境中保持清晰。

內部連結首選：使用 rel="prev/next" 與 canonical

內部連結首選：使用 rel="prev/next" 與 canonical

你在做內容分頁（例如新聞專欄、產品清單、教學章節）時，最常碰到的問題是搜尋引擎不一定能正確辨認哪些頁面屬於同一系列。這時候就可以用 rel="prev" 與 rel="next" 來告訴搜尋機器人「這兩個頁面互相連結」；再加上 canonical 標籤，還能避免重複內容被誤判。

為什麼要使用 prev/next？

  • 順序感：rel="prev" 與 rel="next" 讓搜尋機器人知道頁面之間的先後關係，像是章節一、二、三…
  • 抓取效率：若你把每個分頁都加上這兩個標籤，爬蟲就能更快找到整個系列的結構，減少不必要的重複抓取。
  • 避免碎片化：搜尋結果裡會把整套內容視為一個連續單位，而不是單頁散落。這樣使用者在搜尋時看到的排名也更一致。

典型用法範例

假設你有三篇關於「台北美食」的文章，分別是第 1、2、3 篇：

<link rel="prev" href="https://example.com/taibei-meatball-article2.html">
<link rel="next" href="https://example.com/taibei-meatball-article4.html">

在第 1 篇的 <head> 裡，rel="prev" 指向前一篇（如果是第一頁就不加）；rel="next" 指向後一篇。如此往復，搜尋機器人就能「走路」完整個系列。

canonical 的角色

  • 避免重複：有時同一內容會因為不同參數、不同裝置版面（desktop / mobile）而產生多個 URL。canonical 讓搜尋機器人知道「這些 URL 實際上是同一篇文章」。
  • 權重集中：所有外部連結的投票都會回到 canonical 的 URL，避免被分散。

如何在分頁中同時使用 rel 與 canonical？

  1. 先寫好分頁結構（例如 /blog/page/2、/blog/page/3）。

  2. 放入 rel 標籤：每個分頁的 <head> 裡都加上前後連結。若是第一頁，只加 rel="next"；最後一頁只加 rel="prev"。

  3. 設定 canonical：對於「主題相同但 URL 不同」的情況，將每個分頁都指向最常使用或最完整的那一個 URL（例如 /blog/main-article.html）。

範例：

<link rel="prev" href="https://example.com/blog/page/1">
<link rel="next" href="https://example.com/blog/page/3">
<link rel="canonical" href="https://example.com/blog/main-article.html">
  • 注意：不要把 canonical 指向同一分頁本身，除非這個 URL 就是你想要的「最終」版本。若是指向別的頁面，要確定那個頁面的內容與目前頁面完全一致。

常見錯誤

  • 忘記加 rel="prev" 或 "next"：特別是在第一、最後一頁時，容易把兩者都寫成空或留白。搜尋機器人會無法判斷順序，可能把整體拆開。
  • canonical 指向錯誤 URL：如果指向不存在的頁面或是同一分頁本身，搜尋機器人就不會合併權重。
  • 重複使用相同 canonical 在多個不同主題中：這會把不同內容混在一起，造成索引錯亂。

總結要點

  • 用 rel="prev/next" 告訴搜尋機器人「分頁順序」；
  • 用 canonical 把重複 URL 的權重集中到一個主體；
  • 每個分頁都應該有完整、正確的標籤，避免漏寫或指向錯誤位置；
  • 先把內容結構設計好，再在 <head> 加上這兩種標記。

偵測並修正重複內容的完整流程

這篇教學將帶你從頭到尾瞭解如何偵測並修正網站重複內容，讓搜尋引擎更好抓取你的核心訊息。

偵測重複內容的第一步：搜集所有 URL

  • 使用站內連結檢測工具（如 Screaming Frog、Sitebulb 或自訂爬蟲）把整個網站的 URL 列表抓下來。這一步就像先把全家人都叫到桌子前，先知道誰在那裡。
  • 確保包含所有子域與動態參數（例如 /product?id=123 & /product?ref=abc）。

第二步：比對內容相似度

  • 透過文字雜湊（如 SHA‑256）先做快速排除，找出完全一致的頁面。這是最省力的一招。
  • 接著使用語意分析工具，例如 Diffbot、DiffEngine 或自訂 NLP 模組，比較段落相似度。你可以把兩篇文章貼進去，看它們有多少文字重疊。

第三步：決定主頁面（Canonical）

  • 先挑出最完整、最具權威的版本，通常是最新更新或擁有最多內部連結的那一篇。舉例來說，如果你有兩個關於「台北夜市」的貼文，一篇寫到 2024 年，另一篇到 2023 年，那麼 2024 的會是主頁面。
  • 若無法明確決定，可使用「canonical 標籤」在次要頁面上宣告主頁面。

第四步：實作 301 永久轉址或 canonical 標籤

  • 301 轉址：對於完全重複、內容相同的舊 URL，直接設定 301 至主頁面。搜尋引擎會把權重全部搬走，避免被視為 duplicate content。
  • canonical 標籤：在次要頁面的 <head> 加入 <link rel="canonical" href="https://example.com/main-page">，告訴爬蟲主頁面是哪一個。這種方法適合保留多個 URL 但內容相似的情況。

第五步：測試與驗證

  • 使用 Google Search Console 的「URL 檢查」功能，確認每個轉址是否正確執行。
  • 利用 Screaming Frog 的「Duplicate Content」報告，再次檢視是否還有遺漏的重複頁面。
  • 觀察搜尋結果中的「索引狀態」，若仍出現多個 URL，代表設定可能尚未生效。

範例：小型旅宿網站的重複問題處理

  • 情況說明：此旅宿網站有兩個關於「住宿套餐」的頁面，分別為 /packages & /special-offers。內容幾乎相同，只是標題不同。
  • 步驟 1：抓取所有 URL → 發現上述兩頁。
  • 步驟 2：比對文字 → 95% 相似度。
  • 步驟 3：決定主頁面 → /packages 為最新更新，選為主頁面。
  • 步驟 4：在 /special-offers 加入 <link rel="canonical" href="https://example.com/packages">；若想完全刪除，可設定 301 轉址至 /packages。
  • 步驟 5：用 Search Console 檢查，確定兩個 URL 都被歸併到 /packages。

404 錯誤處理：把錯誤轉成機會

分析 404 錯誤的來源

分析404錯誤的來源

當網站頻繁出現 404（找不到頁面）時，往往不是單純的「網址打錯」；背後可能隱藏著連結失效、搬遷或是 SEO 的小問題。以下提供一套實務步驟，幫你快速定位與修復來源。

  • 先看統計數據：登入 Google Analytics 或 Matomo，篩選「事件」→「404錯誤」。這裡能看到最常被呼叫的失效連結、使用者地理位置以及裝置類型。
  • 查看伺服器日誌：大多數 Web 伺服器（Apache、Nginx）都會把每個請求寫進日誌。以 Nginx 為例，下面的範例展示如何快速抓出重複出現的 404 URL。

找出錯誤最多的五個 404 路徑

awk '$9 ~ /404/ {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5

  • 核對網站內部連結：使用瀏覽器的開發者工具或自動化腳本（如 Screaming Frog 或 Sitechecker）掃描所有頁面，將 404 的 URL 列出。
  • 檢查外部連結來源：若 404 大多來自特定域名，可能是合作夥伴網站遺失了你的連結。可透過 Google Search Console 或第三方工具（如 Ahrefs）追蹤反向連結的狀態。
  • 確認搬移或刪除：若發現某些 URL 曾經存在但已被刪除，請務必設定 301 重導向，避免搜尋引擎與使用者直接遇到 404。
範例：從日誌中找出最常見的失效頁面
  • 假設你有以下兩行日誌（僅作示範）：

10.0.0.1 - - [12/Mar/2025:08:23:45 +0800] "GET /old-page.html HTTP/1.1" 404 512 "-" "Mozilla/5.0"
10.0.0.2 - - [12/Mar/2025:09:14:02 +0800] "GET /products/item-123.html HTTP/1.1" 200 2048 "-" "Mozilla/5.0"

  • 使用前面提供的 awk 指令，將 /old-page.html 輸出並統計。若同一個 URL 重複多次，說明它是最常見的失效點。
常用工具速查表
  • Google Analytics / Matomo：追蹤 404 事件與使用者行為
  • Search Console：檢測搜尋結果中的「結構化錯誤」報告
  • 日誌分析工具：AWStats、GoAccess（可視化日誌統計）
  • 站內掃描器：Screaming Frog SEO Spider、Sitechecker（自動找出 404）

常見 404 原因與修復方式

典型原因 可能來源 修復建議
網址遺失 手動刪除或搬移 設定 301 重導向，或重新建立頁面
錯誤連結 內部連結寫錯、複製貼上時的格式問題 使用站內掃描器找出並修正
外部網站失效 合作夥伴改版、域名到期 直接聯絡對方，或自行建立相同路徑的暫存頁面
CDN 與快取問題 設定錯誤的快取規則 清除 CDN 快取，或更新快取設定
搜尋引擎索引過期 先前存在但已刪除的舊頁面仍被搜尋結果指向 在 Search Console 提交「移除 URL」或使用 noindex 標籤

打造友善且 SEO 有益的 404 頁面

建立友善且 SEO 有益的 404 頁面

在網站上，偶爾會遇到失效連結。若是直接回傳錯誤訊息，使用者往往會離開，而搜尋引擎也可能認為此頁面品質低下。透過設計一個既能保留訪客又對 SEO 友善的 404 頁面，可以把這個失敗轉成機會。

以下列出好的 404 頁面帶來的三大好處：

• 保留使用者：提供替代路徑讓他們繼續逛網站，降低跳離率。
• 提升搜尋引擎友善度：告訴搜尋機器人此頁面非永久性錯誤，避免被索引。
• 收集數據：透過分析 404 訪客的來源，發現潛在內容缺口或舊連結問題。

設計要點

1️⃣ 明確告知錯誤：「抱歉，看不到這個頁面」
2️⃣ 提供導引：首頁按鈕、熱門文章連結、搜尋框，讓使用者快速找到想看的內容。
3️⃣ 使用品牌風格：顏色、字體與其他頁面保持一致，避免突兀。
4️⃣ 加入動態元素：例如可互動的圖示或簡短動畫，提升趣味性，但不影響載入速度。

實作範例

HTML 範本（建議放在 /404.html）

<!DOCTYPE html>
<html lang="zh-Hant">
<head>
<meta charset="UTF-8">
<title>找不到頁面</title>
<meta name="robots" content="noindex, nofollow">
<style>
body{font-family:Arial,sans-serif;text-align:center;padding-top:50px;}
a{color:#0066cc;margin-top:20px;display:inline-block;}
</style>
</head>
<body>
<h1>找不到這個頁面</h1>
<p>很抱歉，您所尋找的內容不存在。
您可以試著回到首頁，或使用搜尋功能。</p>
<a href="/">返回首頁</a>
</body>
</html>

.htaccess 或 Nginx 設定（以 Apache 為例）

把所有 404 送往 /404.html

<IfModule mod_rewrite.c>
RewriteEngine On
ErrorDocument 404 /404.html
</IfModule>

WordPress 自訂 404 模板

// 在主題目錄新增 404.php
// 內容可參考上方 HTML 範本，只需把 PHP 標籤加入即可。

監測與優化

1️⃣ 使用 Google Analytics 設定事件追蹤，紀錄 404 頁面的訪客來源、停留時間等指標。
2️⃣ 在 Search Console 的「覆寫」報告中查看被索引的 404 URL，並採取 301 或刪除。
3️⃣ 定期檢查網站內部連結，使用工具（如 Screaming Frog）掃描失效連結，將其修正或重定向至相關內容。

針對 404 推薦的重導策略

404 錯誤不只是錯失機會的信號，若能善用重導策略，還可以把這個小瑕疵轉成 SEO 的加分項。以下整理了實務上常見且效果顯著的重導做法，讓你在面對斷鏈時不再手足無措。

404 重導策略一覽

  • 301 永久搬移：當頁面已被永久刪除或改版，使用 301 導向新網址，傳遞權重與信任度。舉例：原來的「/old-blog-post」改成「/new-blog-post」。
  • 302 臨時搬移：若頁面只是暫時不可用（如維修），可使用 302 導向備援頁或主題相關的其他內容。這樣搜尋引擎知道還會再回來查看。
  • 自訂 404 頁面：把錯誤頁設成具導覽功能，提供熱門文章、搜尋框以及「最近更新」區塊，提升使用者體驗並降低跳出率。
  • URL 正規化：對於同一內容存在多個 URL（如 http 與 https、/index.html 或沒有結尾斜線），設定 301 導向統一版本，避免重複內容造成的權重分散。

常見錯誤類型與適用策略

  • 永久刪除：使用 301 導向同主題最相關的新文章。若無直接對應，可導向類似分類頁面，例如將 "舊產品 A" 重定向到「產品總覽」。
  • 錯誤輸入（typo）：可使用 302 或 301 導向正確 URL，尤其是常見的拼寫錯誤。若無法確認正確網址，可導向搜尋框或主頁。
  • 舊版內容：將 404 重定向到最新版本，同時在重定向後的頁面中提供「此篇已更新」提示，讓搜尋引擎了解內容仍具價值。

案例示範：從斷鏈到流量提升

  1. 舊部落格搬移：一位台北創業家的個人網站在重整後，原本 200 個部落格文章均被刪除。經過 301 導向新域名下對應文章的設定，Google 的索引頁面數量迅速回升，且每月有 15% 的自然搜尋流量提升。

  2. 產品頁面錯誤：某電商平台因為系統更新導致部分商品頁出現 404。使用者可在自訂 404 頁面看到「熱門同類商品」與「最近熱賣」區塊，結果跳出率下降 8%，購物車轉換率提升 3%。

  3. 網站結構重組：一個旅遊資訊站將原本的「/台北-景點」改名為「/台北-必訪景點」。通過 301 導向，舊連結仍能帶來約 5% 的流量，而新頁面因內容更精緻、分類更明確，SEO 排名提升。

技術實作小技巧

  • 使用 .htaccess 或 Nginx 配置：對 Apache 伺服器，可在根目錄放一個 .htaccess，設定重導規則；Nginx 則在 server 區塊內加入 rewrite 指令。
  • 自動化檢查工具：利用 Screaming Frog 或 Sitebulb 等工具掃描整站 404 錯誤，快速列出需要處理的 URL。
  • 監控與回報：將 404 日誌輸出至 Google Search Console，定期查看「搜尋分析」中的錯誤頁面，確保重導策略已正確執行。

小結

把 404 當作網站優化的機會，而不是負擔。只要合理規劃重導路徑、提供友善的自訂錯誤頁面，甚至在必要時改寫 URL 結構，都能讓原本失效的連結重新發光，為站長帶來意想不到的流量回饋。

你還在等什麼？

立刻掃描網站、設定重導，將每一次錯誤轉化成提升排名與使用者體驗的新動力吧！

重導圖：讓網址永續流量

301 與 302 的選擇準則

這篇文章會帶你快速了解什麼時候該用 301，什麼時候該用 302，並且給你幾個實際案例讓概念更貼切。
透過簡單的說明與實務範例，你就能知道在網站搬遷、臨時維護或頁面重構時，最適合選擇哪一種重導方式。

301 與 302 的選擇準則

在網路上搬移或更新內容時，你常會碰到兩個 HTTP 重導碼：301 永久轉移和302 臨時轉移。雖然表面看起來都能把使用者帶到新網址，但它們對搜尋引擎的訊號、SEO 效果以及瀏覽器行為卻截然不同。

為什麼要區分 301 與 302
  • 301：告訴搜尋引擎和瀏覽器，舊網址已經永久搬移到新網址。搜尋引擎會把原本的權重、連結值（link juice）轉給新網址，也能更新索引。
  • 302：表示這只是一個臨時性的跳轉，例如維護、A/B 測試或短期活動。搜尋引擎不會將權重搬移，還是保留原網址的排名和連結值。
1️⃣ 301 —— 永久轉移

  • 適用場景：
    • 網站域名變更（例如從 www.oldsite.com 改到 www.newsite.com）。
    • 頁面永久搬遷或合併（例如舊部落格文章搬到新平台）。
    • SEO 上需要把所有原有連結權重傳給新網址。

  • 實務範例：假設你在 2024 年 1 月把「example.com/blog」全部移至「newblog.com/articles」。你會在舊伺服器設定 301 重導，讓所有訪客、搜尋引擎與外部連結都自動跳轉到新網址。經過幾週後，你可以在 Google Search Console 查看「URL 移動」報告，確認權重已成功遷移。

  • 注意事項：設定 301 後不會立即生效，需要搜尋引擎重新抓取；若頻繁改動 URL，可能導致搜尋引擎索引混亂，因此盡量一次性完成所有搬遷。

2️⃣ 302 —— 臨時轉移

  • 適用場景：
    • 網站短期維護（例如凌晨 1 點到 3 點的系統升級）。
    • A/B 測試或流量分流，暫時把一部分使用者導向另一頁面。
    • 促銷活動結束後仍保留原網址，但要短時間內切回來。

  • 實務範例：你在「example.com/sale」舉辦為期三天的限時折扣，期間想把所有進入此頁面的人導向「sale-landing.com」。設定 302 可以讓搜尋引擎知道這只是短暫跳轉，未來還會恢復原來的折扣頁。活動結束後，只要取消 302，即可讓使用者回到原來的折扣頁。

  • 注意事項：若把 302 用於永久性改版，很可能搜尋引擎不會更新索引，導致流量下降。長期依賴 302 也可能被視為「臨時重定向」，減少權重傳遞。

結論

  • 要做永久性的 URL 改變：就用 301。這能確保搜尋引擎把原有流量、排名跟連結值全部搬到新網址，讓 SEO 風險降到最低。
  • 只需要短期或測試性跳轉：使用 302。這樣搜尋引擎不會立刻改變索引，也能保留舊 URL 的權重。

最後提醒你，設定完重導後一定要在 Google Search Console 或其他 SEO 工具上確認索引與流量變化，確保一切順利。

保留重導歷史：避免鏈結斷裂

保留重導歷史的重要性

當你搬家、改版或刪除頁面時，舊網址可能會被搜尋引擎與使用者視為失效。若不妥善保留重導規則，流量就會像漏水的水管般慢慢流失。

以下列出三大危機：

  • 1️⃣ 搜尋排名下滑：搜尋引擎將舊網址標示為 404，權重無法轉移。
  • 2️⃣ 使用者體驗下降：點擊後跳到「此頁面不存在」的畫面，使用者可能離開。
  • 3️⃣ 外部連結價值流失：被引用在其他網站的連結會變成死鏈。

實務操作：如何設定與維護重導歷史

以下提供常見伺服器環境的範例，並說明為何要保留每一次重導。

  • Apache (.htaccess)
# 舊網址 /old-page 重新導向至新網址 /new-page
Redirect 301 /old-page https://www.example.com/new-page

為什麼要用 301？
301 代表「永久搬遷」，搜尋引擎會把原本的權重轉移給新網址。

  • Nginx
# 舊網址 /blog/2020 重新導向至 /blog/2023
rewrite ^/blog/2020/(.*)$ /blog/2023/$1 permanent;

permanent 同樣是 301。

  • 維護重導歷史的好處

    • 可以在網站管理平台（如 Netlify、Vercel）上建立「重導表」，記錄每一次 URL 改動。
    • 在搬家前先備份舊網址清單，避免遺漏。

  • 測試 & 監控
    1️⃣ 使用瀏覽器開發者工具的 Network 面板，確認回傳狀態為 301。
    2️⃣ Google Search Console 的「覆蓋」報告能顯示哪些網址還是 404。
    3️⃣ 定期執行自動化腳本（如 curl 或 Python requests）抓取重導鏈結，確保不會斷裂。

  • 舉例：部落格搬家

假設你原來的網址是 https://oldblog.com/2022/post-123，現在改成 https://newblog.com/articles/post-123。設定重導後，任何人點擊舊連結都會自動跳到新位置，同時搜尋引擎也不會把權重丟失。

  • 常見陷阱

    • 忘記更新 sitemap：確保所有舊 URL 在 sitemap 中被標記為 301。
    • 重導循環（A→B，B→C，C又回到 A）：會造成瀏覽器卡死或搜尋引擎抓不到正確頁面。

  • 總結
    保持重導歷史的完整與透明，是維護網站長期流量與使用者信任的關鍵。每一次改版都別忘了記錄並測試，讓連結永續運作。

測試重導效果：確保使用者體驗順暢

測試重導效果：確保使用者體驗順暢

在網站搬遷、頁面重新命名或是網址縮短服務時，最重要的不是單純把舊連結改回去，而是確保使用者從舊 URL 跳到新 URL 時感覺像是進入了一條無縫隧道。以下將以實際操作為例，說明如何一步步驗證重導是否順暢。

重要概念
  • 301 永久性：表示頁面已永久搬移，搜尋引擎會把排名轉移過來。
  • 302 暫時性：表示頁面臨時改動，瀏覽器不一定會記錄下來。
  • 跳躍速度：從點擊到顯示新頁面的時間應該在 0.3 秒以內，否則使用者可能覺得卡頓。
步驟一：設定重導規則

1️⃣ 在伺服器上新增 .htaccess（Apache）或 nginx.conf（Nginx）的重導條目。

Apache 範例：將舊網址 /old-page 重導到新網址 /new-page

Redirect 301 /old-page https://www.example.com/new-page

步驟二：使用工具檢查重導連結
  • curl：直接查看 HTTP 標頭。例子：

$ curl -I http://www.example.com/old-page
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

  • 瀏覽器開發者工具：在 Network 面板觀察跳轉時間與狀態碼。
步驟三：模擬使用者行為測試

1️⃣ 在不同裝置（手機、平板、桌機）上手動輸入舊網址，確認頁面能順利顯示新內容。

2️⃣ 使用自動化測試框架（如 Cypress 或 Playwright）寫一小段腳本：

// Cypress 範例
cy.visit('/old-page').should('have.url', 'https://www.example.com/new-page')

步驟四：監測與回報
  • 伺服器日誌：確認沒有重導錯誤或循環。
  • Google Search Console：在「抓取」>「URL 測試工具」裡輸入舊網址，檢查是否顯示正確的 301。若有警告，馬上修正。

常見錯誤案例

  • 重導連結指向自己：造成死循環，瀏覽器會提示「循環重定向」。
  • 忽略 http 與 https 的差別：舊網址用 http 而新址用 https，若未設置轉換，使用者可能遇到安全警告。

小結

測試重導不只是確定 301 或 302 正確返回，更重要的是讓最終使用者在點擊連結後能即時看到想要的內容。若發現跳轉時間過長或出現錯誤，請立即回到設定檔修正，再重新測試。

祝你搬遷順利、重導無礙！