`在進入了解工程面上如何進行 301 轉址前，我們先快速講解什麼是 301 轉址：
* 轉址簡單來說就是「將對 A 網址的請求，轉移至 B 網址」例如 https://apple.com 轉移至 https://apple.tw 或是 hello.com/source 轉移至 https://hello.com/destination 只要是將 A 轉至 B 都稱為「轉址」。
* 301 在網際網路中的意思是「永久轉移」
整合起來可將「301 轉址」解釋為「永久將對 A 網址的請求，轉移至 B 網址」
## 請先試想一個問題「為什麼請求可以從 A 轉到 B？」
一個 301 轉址是這樣完成的：
1. 你先對 A 網址進行請求
2. 在 A 網址的「終端」會有回覆你「請前往 B」
3. 你因應「A 終端」的回覆對 B 請求
4. 得到最終 B 網址的內容回應
此時我們可以把關注點放在這個「終端」，因為整個流程上要是沒有這個「終端」告訴你你的請求該去哪裡，那麼這個轉址過程就不會成立。那麼什麼是這個「終端」呢？事實上我們可以大致上可以用三種方式來建立這個「終端」，分別是
* 網域層級轉址
* 主機 Web Server 層級轉址
* 主機後端應用程式轉址
在閱讀接下來的工程轉址操作前，[請先確保你了解什麼是網域、主機、網站，他們在工程上的差異是什麼](https://inbound.technology/%E4%BB%80%E9%BA%BC%E6%98%AF%E7%B6%B2%E5%9F%9F%EF%BC%9F%E4%B8%BB%E6%A9%9F%EF%BC%9F%E7%B6%B2%E7%AB%99%EF%BC%9F%E5%B0%8B%E6%89%BE%E7%B6%B2%E7%AB%99%E5%85%AC%E5%8F%B8%E5%89%8D%E7%9A%84%E5%BF%85%E4%BF%AE/ “請先確保你了解什麼是網域、主機、網站，他們在工程上的差異是什麼”)，如果你仍然是一知半解的狀況下往下看，那麼你很有可能會理解錯誤。
## 從網域層級進行 301 轉址
這是個比較少見的轉址方式，有些網域商或是網域託管商會提供這樣的網域轉址服務，你可以在它們的後台直接指定將你擁有的網域網址導向另外一個目標網址。此時網域託管商變成為前述所為「終端」的角色。
要注意是否提供這個服務取決於你的網域託管商，請跟網域託管商確認有提供服務才有機會選擇這種轉址方式，最後理所當然的「你一定要有網域管理的權限才能選擇這種轉址方式」。
例如下面是一個 Cloudflare 的 Page Rule 功能，將 inboundmarketing.tw 的請求全都轉址至 inboundmarketing.com.tw。要注意因為 Cloudflare 的 Page Rule 免費版本只有 3 個 Page Rule，對於要做多組指定轉址來說非常不友善。
更新：2023-05-15 時，我們發現 [Cloudflare 有推出新的 Redirects 功能（Beta 版本）](https://developers.cloudflare.com/rules/url-forwarding/ “Cloudflare 有推出新的 Redirects 功能（Beta 版本）”)，它可以讓你進行單一網址或是同時進行多個網址的重新導向，免費版本可以進行 10 個單一轉址 (Single Redirect) 跟 20 個群組轉址 (Bulk Redirect)。
## 從主機 Web Server 層級進行 301 轉址
這個是常見的轉址方式之一，理所當然你得要有主機 Web Server 設定檔更改的權限，常見的 Web Server 有 Apache, IIS, Nginx…等，每一種 Web Server 的設定方式都不同，請先確認自己是使用哪一種 Web Server 後尋求官方文件進行正確的設定。
例如下面是一個 nginx 的設定範例，這個設定是將所有對 sinocell.com.tw 的請求轉移至 www.supercell-biotech.com
“`
server_name .sinocell.com.tw;
rewrite ^ https://www.supercell-biotech.com$request_uri? permanent;
“`
可以看到這個設定會需要一定的資訊知識才有可能進行，因此對於非工程師的人員來說，這不是一個友善的轉址選擇。
## 從主機上的應用程式層級進行 301 轉址
這個是最常見的轉址方式，由於這個請求已被 Web Server 做接收，轉交給「後端的程式語言」，我們也會稱這種轉址方式為「後端程式轉址」，這個轉址發生的方式無論是工程師自行撰寫程式語言或是一般使用者透過工程師開發的介面設定轉址都包含在內。
這邊用流程圖解釋：事實上在 A 請求的接收上會先由 Web Server 進行接收後轉交給應用程式處理，最終才會將請求回覆給請求者。
應用程式可以用任何的後端程式語言撰寫，例如 PHP、Python、C#…等，當然為了對於非工程師使用者友善，工程師們會開發後台讓使用者可以「用介面設定程式的運作」，例如在 WordPress 中你可以安裝 Redirection 外掛來自訂任意的轉址規則，處理這個轉址的流程便會如下流程所述：
1. 請求者對 A 請求至 Web Server
2. Web Server 將請求轉至應用程式
3. 應用程式依據使用者設置的規則告知 Web Server 應回覆請求者要轉至 B
4. Web Server 如實稟告回覆使用者
5. 請求者得知 A 已轉移至 B
6. 請求者對 B 進行請求後取得回覆
最後，如果你沒有程式碼修改的權限或是網站廠商不願意配合開發轉址程式，那麼你也沒辦法選擇這種轉址方式。
## 案例1：我想將 https://example.com/old 轉移至 https://example.org/new ，但不想影響 https://example.com/preserve 該用什麼做法？
如果你仍然想保留 https://example.com 上的其他網址，那麼你肯定在 https://example.com 有運作著 Web Server 或是應用程式。如果你的網站應用程式有支援後台直接設定重新導向規則，那麼我們會建議你直接在應用程式設定，如果沒有的話，次之可以更改 Web Server 的設定，最後不行的話才會選擇更改網域設定。
## 案例2：我不想要 https://origin.com 了，我想要全都轉移至 https://another.com 該用什麼做法？
因為你已決定不再需要 origin.com，此時你可能會想要將原先在 origin.com 的網域、主機、網站都放棄掉。但這邊要提醒你請保留 origin.com 網域至少一至兩年、甚至永久的擁有權，以確保接續的轉址可以有效維持。
關於 origin.com 主機和網站你可能是委託外部廠商維護，理論上這兩個項目會隨著你的合約消失，因此你可能會想說首選方式是「網域層轉址」，但支援網域層轉址的託管商並不多且很多又有數量上的限制導致無法 1:1 的做轉址，因此我們建議你應至少建立「主機 Web Server」或是「主機 Web Server + 應用程式」來進行轉址。如果你不會建立「主機 Web Server」或是「主機 Web Server + 應用程式」，那麼歡迎聯絡我們進行協助，我們有轉址主機託管方案，您只需將網域指向我們的主機即可，我們會使用「從主機 Web Server 層級」進行 301 轉址的方式，[詳細的 301 轉址流程可以參考我們的服務流程](https://inboundmarketing.com.tw/301-%e9%87%8d%e6%96%b0%e5%b0%8e%e5%90%91%e6%b5%81%e7%a8%8b%e6%95%99%e5%ad%b8%ef%bc%8c%e8%bd%89%e5%9d%80%e4%bf%9d%e7%95%99%e7%b6%b2%e7%ab%99-seo-%e6%ac%8a%e9%87%8d%e5%92%8c%e6%b5%81%e9%87%8f/ “詳細的 301 轉址流程可以參考我們的服務流程”)。
## 延伸閱讀
* [301 重新導向流程教學，轉址保留網站 SEO 權重和流量](https://inboundmarketing.com.tw/301-%e9%87%8d%e6%96%b0%e5%b0%8e%e5%90%91%e6%b5%81%e7%a8%8b%e6%95%99%e5%ad%b8%ef%bc%8c%e8%bd%89%e5%9d%80%e4%bf%9d%e7%95%99%e7%b6%b2%e7%ab%99-seo-%e6%ac%8a%e9%87%8d%e5%92%8c%e6%b5%81%e9%87%8f/ “301 重新導向流程教學，轉址保留網站 SEO 權重和流量”)
* [WordPress 使用 Redirection 外掛進行 301 重新導向設定](https://inboundmarketing.com.tw/wordpress-%e4%bd%bf%e7%94%a8-redirection-%e5%a4%96%e6%8e%9b%e9%80%b2%e8%a1%8c-301-%e9%87%8d%e6%96%b0%e5%b0%8e%e5%90%91%e8%a8%ad%e5%ae%9a/ “WordPress 使用 Redirection 外掛進行 301 重新導向設定”)
`
