301 永久轉址：內容永久搬家時的最佳選擇
什麼是 301？
301 永久轉址（HTTP 301 Moved Permanently）是伺服器端轉址，表示請求的資源已經永久搬遷到新的網址。當使用 301 時，搜尋引擎會將新網址視為主要頁面，在搜尋結果中顯示新網址而非舊網址。同時，301 轉址被視為一種強烈的 canonical 信號，意味著舊頁面的排名信號（如外部連結的權重）會傳遞給新頁面。換言之，如果頁面 A 有很多反向連結，透過 301 轉到頁面 B，Google 會將這些連結權重幾乎完整地算到頁面 B 上，讓新頁面像直接獲得了那些連結一樣。這也是為什麼 301 是 SEO 上公認最友好的轉址方式之一。
適用情境
當你確定某個頁面或網站網址要永久變更時，應該使用 301。典型例子包括：
- 網站改版更換網域或路徑（如從 http:// 切換到 https://，或從舊網域搬到新網域）。
- 合併內容或刪除頁面：將舊頁面的流量永久引導至新頁面或相關頁面。
- 解決 www/non-www 兩種網址重複問題（將非首選版本永久轉到首選網址）。
- 永久變更網站的 URL 結構（例如分類調整後舊URL重定向到新URL）。
SEO 影響
301 永久轉址對 SEO 通常有正面效果。Google 官方建議若需要改變頁面網址並希望搜尋結果顯示新網址時，盡可能使用永久轉址，這是確保 Google 和使用者都被帶往正確新頁面的最佳方法。歷史上曾有傳言認為 301 轉址會損失部分排名權重，但自 2016 年起 Google 多次澄清：無論 301、302 或 307，只要實作正確，它們都會傳遞 PageRank 等權重，Google 並不在乎你用哪種轉址方法。也就是說，301 轉址不會讓你的排名權重流失。Moz 的觀察亦指出，301 轉址所傳遞的鏈接權值幾乎不會降低。相反地，若不使用轉址處理搬遷，任由大量死鏈存在，才會對SEO造成真正危害。
不過要注意，301 的作用是在於「永久」。使用 301 後，搜尋引擎會認為舊網址不再有效，後續主要索引新網址。如果日後又將內容搬回舊網址，可能需要一段時間才能恢復排名。因此在尚未完全確認永久搬遷時，不要輕易使用 301。
實作方式
301 必須由伺服器端發送 HTTP 回應頭來實現。以下是幾種常見實作方法：
Apache .htaccess 規則：
在 Apache 伺服器上，可以透過 .htaccess 檔案加入轉址規則。例如使用 mod_alias 模組簡單設定：
# 將 /old 永久轉到指定新網址
Redirect permanent "/old" "https://example.com/new"
上述規則會將「站內路徑 /old」的請求永久轉向至指定的新完整網址。
後端程式轉址（例如 PHP）：
在 PHP 中，可在輸出任何內容前設定 header：
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();
如此後端收到對舊網址的請求時，會回傳 301 狀態碼並告知瀏覽器新位置。
其他環境：
不同伺服器或框架有不同做法。例如 Nginx 可在設定檔中使用：
return 301 https://example.com/new-page;
來實現永久轉址。重點是確保回應的狀態碼為 301 並提供正確的新 URL。
常見錯誤
即使 301 對 SEO 有利，但使用不當仍可能出問題：
轉址目標不相關： 切忌將內容不相干的頁面用 301 硬轉到另一頁。例如把一篇部落格文章轉到首頁，Google 可能會視這種不相關轉址為「軟 404」而不傳遞權重。轉址應儘量保持「一對一、內容相關」，確保新頁面能滿足舊頁面的使用者意圖。
轉址鏈過長： 連續的轉址鏈會增加抓取難度。如「A→B→C→D」，Googlebot 可能只追蹤部分，導致權重無法順利傳遞。應該直接將舊頁面轉到最終目標頁，避免多段跳轉。
過早移除轉址： Google 建議對於網站搬家類的永久轉址至少保留一年以上。如果過早拿掉 301，Google 可能還沒充分處理舊址到新址的關係，導致舊網址又重新出現在搜尋結果中。為穩妥起見，最好長期保留這些轉址（甚至無限期保留），特別是高權重頁面。
302 暫時轉址：臨時變更網址的利器
什麼是 302？
302 暫時轉址（HTTP 302 Found）是另一種常見的伺服器端轉址，但用途是臨時性質。當伺服器回傳 302 時，表示請求的資源暫時位於另一個網址，可能日後還會回到原網址。對使用者來說，302 與301的行為相同：都會將瀏覽器自動導向新位置。然而在搜尋引擎端，302 被視為較弱的 canonical 信號。Google 會傾向保留原本的舊網址在索引中，因為系統認為你未必是永久搬遷。換句話說，使用 302 時，Google 搜尋結果通常仍顯示原網址，而非新網址。只有當 302 持續相當長一段時間、累積足夠多信號時，Google 才可能最終將其視同永久轉址處理，改以新網址為主。
適用情境
302 合適用在暫時性內容調動的場合：
- 網站維護或功能暫停： 若網站某項服務暫時不可用，可用 302 將用戶帶到一個說明維護狀態的頁面，待服務恢復後再移除轉址。
- 限時活動或促銷頁： 活動期間將原頁面 302 到活動頁，活動結束後再轉回原頁面。
- A/B 測試： 臨時將部分流量導向新版本頁面進行測試，但最終可能回到原版本。
- 依條件導流： 例如根據用戶裝置、地區等暫時導向不同頁面（但此種情況也常用 302）。
總之，當你預計稍後還要讓用戶返回原始網址時，就應選擇 302 而非 301，以告知搜尋引擎這只是暫時改道。
SEO 影響
由於 302 被視為「暫時且弱」的轉址信號，Google 會較長時間保留舊網址的索引和排名。在暫時轉址期間，連結權重通常停留在原頁面，並不會立即轉移給目標頁。Moz 的研究指出，302 最終也可能傳遞權重，但往往要經過相當長時間才發生；相較之下，301 的鏈接信號傳遞則快得多。因此短期內 302 對 SEO 影響較中性：既不會像 301 一樣立刻讓新頁面繼承權重，也不至於像 404 那樣丟失權重——因為舊頁面還在索引中。
關鍵在於轉址持續的時間長度：如果一個 302 長期不拿掉，Google 可能會開始視它為永久搬遷，轉而索引新網址。John Mueller（Google 搜尋倡導者）也曾表示，302 若一直存在，Google 最終會當作 301 看待。所以務必按實際需求使用 302：能盡快取消時就取消，避免無意中讓搜尋引擎以為轉址變「永久」。
值得一提的是，有些第三方服務或舊有設定可能誤用 302 導致SEO問題。例如：許多網域代管商的URL 轉發預設是 302，導致換網域時新網域SEO權重遲遲無法提升。還有網站開發時未注意，將永久遷移錯用了 302。這些情況都可能讓 Google 繼續把舊網址當主要頁面，新頁面得不到應有排名。因此，務必在永久與暫時轉址間做出正確選擇。
實作方式
302 的技術實現與 301 類似，也是透過伺服器回應。只需將狀態碼改為 302，並提供目標 URL。例如在 Apache .htaccess 中可以這樣設定暫時轉址：
Redirect temp "/old-page" "/temporary-page"
以上規則會將 /old-page 暫時導向 /temporary-page（網站內相對路徑）。或者在 PHP 中將狀態碼調整為 302：
header('HTTP/1.1 302 Found');
header('Location: https://example.com/temporary-page');
exit();
執行後告知瀏覽器資源暫時移至 temporary-page。實作上和 301 幾乎一樣，差別只是狀態碼不同。
常見錯誤
使用 302 時要避免以下誤區：
不該用 302 卻用了 302： 正如前述，如果實際是永久搬遷卻用了 302，會誤導搜尋引擎。這在網站改版、換網域時尤其傷害SEO。記得永久變更必用 301。
長期遺忘移除： 暫時轉址應該真的是「暫時」。如果某個 302 持續了幾個月甚至更久，請重新評估是否應改成 301 或直接撤銷轉址。長期的 302 可能導致搜尋引擎最終索引了錯誤的頁面版本。
302 鏈或循環： 如同 301，避免多重跳轉或迴圈（A→B→A）。暫時轉址也應保持路徑簡潔，否則用戶體驗和爬蟲爬取都會受影響。
307 Temporary Redirect：現代暫時轉址的變體
什麼是 307？
307 Temporary Redirect 是另一種臨時轉址狀態碼。它在語義上類似 302，都表示資源暫時搬到新位置；主要差異在於 HTTP 方法的保留。當使用 307 時，瀏覽器會保留原請求的方法（GET 或 POST）再發送至新網址，而傳統的 302 在早期標準下可能不保證這一點。對一般網站跳轉而言，GET 請求占多數，因此 302 和 307 的效果幾乎相同；但若牽涉表單提交（POST 請求），307 能避免用 GET 重新提交表單的問題。因此可以理解為：307 是 HTTP/1.1 規範下更嚴謹的「暫時重定向」。
適用情境
307 的使用場合與 302 相近，也是處理臨時狀況。不過因為其對方法的特殊處理，如果你的轉址需要保留 POST 資料（例如一個表單結果臨時轉到另一URL），使用 307 會比 302 更合適。在一般內容臨時搬移、A/B測等情境下，302 與 307 均可達成目的。
SEO 影響
從 SEO 角度，Google 將 307 視作與 302 幾乎相同的暫時轉址。Google 不介意你用 301、302 還是 307，只要轉址存在，它們都能傳遞 PageRank，並會依轉址持續時間強度決定最終索引哪個網址。因此，307 同樣是弱 canonical 信號，短期內Google會保留原網址索引，長期持續則可能被當作永久搬遷處理。簡言之，對 SEO 而言 307=302，只是技術實現上略有不同。因此在閱讀許多 SEO 文獻時，302 通常已涵蓋了307的情況。
實作方式
大多數網站後端框架較少預設使用 307，但你可以明確指定。例如在 Apache .htaccess 裡可用 [R=307] 來標示暫時轉址：
RewriteRule ^old-form-page$ /new-page [R=307,L]
這樣瀏覽器對 old-form-page 的請求將以 307 重定向至 new-page，保留原請求方法。同樣地，在其他語言也能設定相應的狀態碼。由於 307 不如 301/302 常見，使用前請確認你的伺服器或程式庫支援該狀態碼。
常見錯誤
307 沒有額外的新陷阱，只要避免和 302 相同的誤用即可。例如不要把應永久的轉址錯用成 307（同樣道理：永久就應301），以及避免不必要的複雜跳轉。絕大多數SEO問題還是出在 301/302 的錯用上；307 更多是技術細節，初學者如感到困惑，可以暫時將它與 302 歸為一類理解。
Meta Refresh 轉址：利用 HTML Meta 標籤的轉址技巧
什麼是 Meta Refresh？
Meta Refresh 轉址是一種在前端執行的轉址方法：透過在 HTML 頁面的 <head> 中放置 <meta http-equiv="refresh"> 標籤來實現。這個標籤通常用於設定幾秒後刷新頁面或跳轉至新網址。例如：
<meta http-equiv="refresh" content="0; URL=https://example.com/new-page">
上述代碼告訴瀏覽器在0秒後（立刻）將使用者導向指定的新頁面。如果 content參數中的秒數大於0，則表示延遲幾秒再跳轉。
適用情境
Meta Refresh 最初用途在於自動重新整理頁面（如新聞網站每隔60秒刷新一次頭條）。作為轉址手段，通常是在無法進行伺服器端轉址的場合下的下策。例如一些靜態網站或部落格平台不允許自定義伺服器設定，站長可能會採用 Meta Refresh 將某頁面轉到新位置。另外，有時也用於倒數幾秒後跳轉的情境（比如下載頁面的中轉提示）。總的來說，如果可以用伺服器 301/302，通常不建議用 Meta Refresh；但在環境受限時，它是一個可行的替代方案。
SEO 影響
由於 Meta Refresh 發生在用戶端，穩定性和及時性不如伺服器轉址。Google 對 Meta Refresh 的處理是：若刷新時間為 0 秒，視同永久轉址（類似 301）；若延遲數秒才跳轉，則視為暫時轉址（類似 302）。因此，從純搜尋引擎信號上看，0秒的 Meta Refresh 可以傳遞權重給新頁面，而延時跳轉則不會立即傳遞。不過實務中，Meta Refresh 可能幾乎不傳遞連結權重。有研究指出，Meta Refresh 標籤幾乎無法傳遞任何「link juice」（權重傳遞值)。這可能是因為一些搜尋引擎或工具對此支持較弱，而且 Meta Refresh 常被濫用或視作不良手法。此外，用戶體驗層面，Meta Refresh 也有缺點：舊瀏覽器可能不支援、跳轉過快用戶無法點返回上一頁等。因此業界普遍將 Meta Refresh 視為非萬不得已不使用的過時方案。
Google 官方也明確表示，最好僅在無法實現伺服器轉址時才考慮使用 Meta Refresh，而且應盡量使用立即跳轉（0 秒）以避免混淆。總結來說，Meta Refresh 能被 Google 認可，但效果穩定性遠遜於 3xx 轉址。
實作方式
如上所示，只需在 HTML 頁面 <head> 加入一行 Meta Refresh 標籤即可。若要立即跳轉，時間設為 0 秒；若希望延遲，例如停留5秒再轉址，則設為 content="5; URL=新網址"。注意 Meta Refresh 必須置於<head>區塊內才能正常運作。另外，也可透過伺服器發送 HTTP Header 的方式實現類似效果，例如：
Refresh: 0; url=https://example.com/new-page
這其實是 HTTP 協定中對應的刷新頭，效果等同於 HTML Meta Refresh。
常見錯誤
過長延遲跳轉： 如果把 Meta Refresh 設定為幾秒以上的延遲，使用者可能以為頁面卡住或體驗不佳。同時搜尋引擎可能在這幾秒內抓取到的是舊頁面內容，對轉址判斷不明確。通常將秒數設為0或接近0，避免延遲過長。
全站大量使用： Meta Refresh 偶爾用在個別頁尚可，但絕不可全站替代 301。大量頁面用 Meta Refresh 轉址可能被搜索引擎判定為垃圾重定向行為。
忽略用戶體驗： 有些站長在404頁上用 Meta Refresh 幾秒後跳轉首頁，試圖留住訪客。這看似友好，但若未告知用戶就跳轉，反而可能造成困惑。正確做法應在頁面上提示「幾秒後將帶您回首頁…」之類的訊息，給用戶心理預期。否則突然跳轉可能增加跳出率，間接影響SEO。
總之，Meta Refresh 是一種權宜之計。在能用正規 301/302 的情況下，應優先使用後者，以確保最佳的 SEO 效果和用戶體驗。
JavaScript 轉址：腳本實現的前端轉址
JavaScript 轉址是什麼？
JavaScript 轉址指的是利用瀏覽器客戶端的腳本來實現跳轉。常見做法是在頁面中放置一小段 JS，例如：
<script>
window.location.href = "https://example.com/new-page";
</script>
當使用者或爬蟲載入該頁面時，腳本會自動將瀏覽器導向新網址。JavaScript 轉址本質上也是發生在客戶端，因此歸類為前端轉址。
適用情境
一般來說，不建議專門使用 JS 進行轉址，因為還是伺服器端直接轉址最穩健。不過在某些情況下 JS 轉址可能成為不得已的選擇：
- 單頁應用（SPA）： 有些前端框架（如 React、Angular）可能用 client-side routing，如果需要在某條件下跳轉至其他頁面，會用 JS 實現。
- 無法修改伺服器設定時： 與 Meta Refresh 類似，若站長無權進行伺服器配置，只能透過前端程式碼完成跳轉。
- 根據動態條件轉址： 例如根據使用者操作或特定事件再決定跳轉目標（這是 JS 所長）。
SEO 影響
JavaScript 轉址對 SEO 來說是最不穩定、也最不建議依賴的方式之一。原因在於搜尋引擎對 JS 的處理需要「渲染」。Google 雖然宣稱幾乎會嘗試渲染所有抓取的頁面，但這個過程有可能失敗或延遲。如果 Googlebot 沒有成功執行頁面中的 JavaScript，就無法發現轉址目標，等同於轉址失效。相比之下，伺服器端 301/302 是立即在HTTP層告知跳轉，Googlebot 更容易正確處理。因此 JS 轉址被視為支援度最低、可靠性最差的方案，應該只有在無法使用前述方法時才使用。正如 Google 官方所說：「除非你無法使用伺服器端或 meta refresh，否則不要依賴 JavaScript 轉址」。
當然，Google現今對 JS 的支持比過去強，許多單頁應用的內容Google也能索引。如果確實用了 JS 轉址，可以透過 Google Search Console 的 URL 檢查工具來驗證：輸入原網址看看 Google 是否已將其識別為轉址並索引了目標頁面。但對於初學者和一般站長而言，能用簡單的 301/302 解決的，就沒必要繞遠路用 JS。
實作方式
上述範例已展示最典型的 JS 轉址——在頁面載入時執行 window.location。具體可將此 <script> 放在頁面 <head> 內，以便儘早執行。有時也見到透過 setTimeout 延遲幾秒跳轉，或在單頁應用的路由配置中設定跳轉邏輯。不論如何，記得不要依賴使用者觸發（如按鈕點擊）來實現重要的 SEO 轉址，因為搜索引擎不會有人為操作去點擊你的按鈕。
常見錯誤
忽略搜尋引擎渲染限制： 認為只要寫了 JS 跳轉，Google 一定能看到。事實上如果頁面JS很多、渲染任務重，Googlebot 可能延遲很久才執行，甚至跳過。JS 轉址可能被漏掉，尤其當轉址腳本未在頭部或沒有適當觸發。
多重轉址混用： 有些人同時在後端和前端都寫轉址，結果導致混亂或重複跳轉。應避免同一URL設定多種轉址，挑選一種可靠方式即可。
依賴瀏覽器特性： JS 轉址需要瀏覽器支持並執行腳本。如果使用者關閉JS或使用不支援的爬蟲（某些簡單爬蟲不跑JS），轉址就失效。因此千萬不要把重要頁面的唯一導覽方式做成JS跳轉，至少提供一個普通的連結備用。
簡而言之：JS轉址能不用就不用。如果用了，也請仔細測試在搜尋引擎中的效果，並考慮配合 sitemap 或 <noscript> 提示，確保搜尋引擎即便不跑JS也能找到關鍵頁面。
Canonical 標籤：非轉址但能告知首選頁面的利器
Canonical 是什麼？它是轉址嗎？
Canonical（規範化）標籤並非真正意義上的「轉址」，而是一種供搜尋引擎參考的 HTML 標記。其格式為：
<link rel="canonical" href="https://example.com/preferred-page" />
放在網頁的 <head> 裡。這行的意思是向搜索引擎聲明：「本頁內容的首選版本（權威網址）是 preferred-page 這個URL。」當一個網站有多個 URL 有高度相似或重複內容時，使用 canonical tag 可以讓站長指定哪一個是主要頁面。
適用情境
處理重複內容 是 canonical 標籤的主要用途。例如：
- 同內容不同參數頁面： 電商網站的商品列表頁可能有多種排序參數導致 URL 不同，但內容類似。可以在不同排序頁都指定 canonical 指向主要的標準頁面，以免被判定重複內容。
- 跨域內容同步： 如果你授權其他網站轉載你的文章，可要求對方在轉載頁加上 canonical 指回你的原始文章 URL。這樣即使兩邊內容一樣，搜尋引擎也知道以你的原創頁面為主。
- 移轉過程暫時雙線上： 當網站搬家尚未完成，用 canonical 指向新站，可在短期內告知搜索引擎主要內容所在地（但理想狀況還是及早改成 301）。
SEO 影響
Canonical 標籤被稱為搜尋引擎的建議性（非強制）訊號。它不會像 301 那樣直接跳轉用戶，僅是在後台告訴搜索引擎哪個 URL 應該被視為主要版本。因此：
- 不影響用戶體驗： 用戶可以透過不同 URL 訪問重複內容頁，但他們不會被自動帶走，所有版本頁面仍可瀏覽。
- 合併權重： 若搜索引擎接受你的 canonical 提示，會將不同版本頁面的信號彙總，主要計入 canonical 指定的那個URL。這有點像「軟性」地把分散的連結權重集中起來。然後搜尋結果中通常只會顯示 canonical 指定的網址，其他重複頁則被淡化處理。
- 非絕對指令： 需要注意，搜尋引擎不保證一定遵循你的 canonical。它們會自行判斷頁面是否真的重複以及哪個版本更適合用戶。如果標記錯誤（例如兩個內容完全不同的頁面互相 canonical），搜索引擎可能會忽略你的標籤。
相比之下，301 轉址是直接且強制的——用戶和爬蟲都被送到新頁面，原頁面完全不再參與排名。而 canonical 只是個建議，各版本頁面仍存在。所以canonical 不會像轉址那樣傳遞即時的排名提升，它只能避免同站內容互相競爭排名，本質上沒有「將權重從A轉給B」的設計（因為A頁還在，只是不被顯示）。
實作方式
在每個重複頁的 <head> 加入 <link rel="canonical" href="主要頁URL"> 即可。務必使用絕對網址（包含協定和網域）作為 href 值，以免相對路徑造成誤判。另外，canonical 標籤只在 HTML <head> 有效，若使用 JavaScript 動態插入也需確保正確執行。對於非HTML文件（PDF等），可在 HTTP Header 中加入 Link: <URL>; rel="canonical" 來實現。
常見錯誤
濫用 canonical 作為轉址替代： 有些人誤以為 canonical 能取代 301。實際上，如果你真的不希望舊頁面被訪問，就應該用 301。Canonical 適用於你希望保留多個頁面供用戶訪問，但不想它們各自出現在搜索結果的情況。例如手機版和桌面版網站使用不同URL，Google推薦用 canonical+alternate 而非轉址。切忌用 canonical 標籤連向一個完全不相關的頁面，這等於告訴搜索引擎「我的內容搬家了」，但使用者卻還留在原頁，會造成混亂。
自我 canonical 或相互 canonical： 每個頁面都應該只 canonical 到真正的主要頁。不要出現 A canonical 到 B，B 又 canonical 回 A 的迴圈，這會讓搜索引擎無所適從。一般地，如果頁面就是自己的最佳版本，那就 canonical 指向自己（許多 CMS 預設會在每頁加自引用canonical）。
忽視 hreflang 搭配問題： 若網站有多語言版本並用 hreflang 註記，canonical 應在相同語言版本之間使用，而不應跨語言 canonical。否則會使 Google 認定某語言版本為主要，其他語言可能被排除索引。這方面 Google 有明確區分：帶 hreflang 等屬性的連結不會被當作 canonical 使用。所以多語網站要同時正確使用 hreflang 和 canonical，避免彼此衝突。
總之，canonical tag 是 SEO 工具箱中很重要的一項，但它不是用來挽救網站搬家或大規模URL變更的。那類情況下還是要靠 301 永久轉址處理。Canonical 更像內容管理的輔助信號，避免重複內容損害你的搜尋表現。
hreflang 與地理轉址的衝突：自動導向地區版本是好是壞？
當網站面向不同語言或地區用戶時，hreflang 標籤是一種常用方案。它允許站長在頁面中指定「此頁有其他語言/地區版本」供搜尋引擎參考。然而，有些站長會額外實作地理轉址（Geo-redirect）：根據使用者 IP 所在國家自動將其導向相應語言的網站版本。比如來自法國的訪客自動跳轉到法文站。表面看這能讓用戶直接看到匹配語言內容，但從 SEO 角度卻存在潛在衝突。
問題在哪裡？
Google 官方明確建議：避免依據用戶所在地或語言偏好進行自動轉址。原因有兩點：其一，自動轉址可能被視為一種 cloak 行為（對不同地區的 Googlebot 返回不一樣的內容，嚴重可被認定作弊）；其二，這樣做會阻止搜索引擎抓取所有語言版本頁面。舉例而言，Googlebot 大多來自美國IP，如果你把美國IP一律轉到英文版，那麼 Googlebot 可能無法索引其他語言的頁面（因為每次抓取非英文頁都被重定向走了）。結果就是你的其他語言內容可能沒機會出現在搜索結果中。
hreflang 的作用是讓搜索引擎了解不同URL間的語言對應關係，前提是搜尋引擎必須能抓取到這些URL。如果自動轉址攔截了它們，hreflang 標籤就形同虛設。因此，hreflang 與強制型的地理轉址本質上會衝突。
正確的國際化作法
- 允許用戶選擇版本： 最佳實踐是不要直接跳轉，而是在頁面提供明顯的語言/地區切換選項（如頂部旗幟或彈窗建議：「檢測到您在法國，是否前往法文版？」）。這樣用戶有自主權，而搜尋引擎也能透過爬行發現各語言頁面。
- 使用 hreflang 註明關聯： 在各語言版本頁的 <head> 中加上彼此的 hreflang 標記，告訴 Google「這些頁面是同內容不同語言」，讓 Google 自行在不同地區顯示對應版本。而不要用程式把訪客強制定向。
- 避免依 IP 的 302 重定向： 有些網站做法是使用 302 根據IP跳轉，期望搜索引擎不受影響（因為 302 是暫時的）。但實際上，這依然可能使 Googlebot 無法遍歷所有語言頁，而且可能誤認為你的不同語言內容是重複的（因老是看到同一版）。
John Mueller 也在論壇中提醒過，自動語言導向往往會弄巧成拙，不如讓 Google 自己透過 hreflang 決定顯示適合的版本。總而言之，為了 SEO，盡量避免強制的地理轉址。如果一定要做，至少對搜尋引擎 user-agent 放行或提供一個所有語言列表的中間頁供爬蟲索引。但這種處理較繁瑣且容易出錯，所以新手站長最好採納簡單直接的方式：人工提供選擇 + hreflang 標記，雙管齊下實現國際化，而非試圖用轉址「自動化」解決。
轉址最佳實踐與監測：總結與建議
在執行任何轉址之前，請先考慮以下 SEO 策略與建議：
選對轉址類型： 永久性變動選 301，臨時性用途選 302/307。如果不確定是否會恢復原頁，傾向先用 302，避免過早讓原頁掉出索引。等確定永久搬遷時，再改用 301。
一對一精確轉址： 尤其網站換網域或大改版時，每個舊頁面應有對應的新頁面並設置轉址。不要所有舊頁都指向同一新頁，這樣不僅用戶體驗差，還可能被搜索引擎視為無效轉址或作弊。利用 sitemap 或其他方法確保無遺漏任何重要頁面的轉址。
保持轉址持續足夠長： 正如 Google 的建議，轉址至少要保持一年以上。實際操作中，更建議長期保留，因為即便搜尋引擎早已更新索引，仍可能有其他外部網站的舊鏈接需要透過轉址導流。另外，長期保留轉址沒有負面影響，反而是一種穩健的做法。
使用 Google Search Console 輔助： 當你實施了重要轉址（例如整站搬家），請在 GSC 中使用「變更地址」工具告知 Google 新網域，並提交新的 sitemap。透過 GSC 的 URL 檢查工具，你可以查詢某個舊網址，看看 Google 是否已將其視為轉址，及其對應的規範網址是哪個。另外，在「覆蓋狀態」報告留意是否有轉址錯誤（如轉址鏈過長、循環等）並及時修正。
監控轉址效果： 利用第三方 SEO 工具（如 Ahrefs、Screaming Frog 等）監控轉址是否生效。Ahrefs 的 Site Explorer 可以幫助你檢查舊網址的反向連結是否已轉移至新網址（例如查看新頁面的反鏈中是否出現來自以前鏈接舊頁面的網域）。若發現重要連結沒有通過轉址傳遞，可能是轉址未正確設置或被視為無效，需要重新檢查。也可使用爬蟲工具模擬抓取全站，確保所有舊鏈接都返回正確的 3xx 狀態碼至新頁。
結語
轉址看似技術實作上的一行代碼，但背後涉及的 SEO 考量非常重要。正確選擇和實施轉址類型，能將網站改動對排名的影響降到最低，甚至利用轉址策略來鞏固權重、提升用戶體驗。相反地，錯誤的轉址方式可能導致搜索引擎困惑、權重流失以及排名下跌。
希望這篇指南式教學讓初學者對 301、302、307 等 HTTP 轉址，以及 Meta Refresh、JavaScript 轉址、Canonical 標籤等有了全面的認識。在實際操作時，記得遵循上述最佳實踐並善用工具監控。這樣一來，無論是網站搬家還是內容調整，你都能胸有成竹地處理轉址，而不必擔心 SEO 惡夢。祝你的網站轉址順利，排名穩健成長！
