HTTP 轉 HTTPS 怎麼設定？四步完成 301 永久轉址與 SEO 檢查

內容大綱

HTTP 轉 HTTPS 的四個標準步驟

網站已正確安裝 SSL/TLS 憑證後，應透過 301 永久重新導向，將所有 HTTP 網址轉到對應的 HTTPS 網址。Apache 主機可在 public_html 或網站根目錄設定 .htaccess；Windows Server 則可透過 IIS URL Rewrite 完成。切勿在憑證尚未生效前直接啟用 HTTP 強制轉 HTTPS，否則使用者可能看到憑證錯誤、連線不安全或重新導向失敗。

STEP 01：確認 SSL 憑證與 HTTPS 可正常使用

在設定重新導向以前，先直接輸入完整的 HTTPS 網址，例如：

https://www.example.com/

確認首頁與內頁都能正常開啟，且憑證符合下列條件：

憑證仍在有效期限內。
憑證網域包含目前使用的主機名稱。
www 與非 www 版本均已納入憑證，或已統一導向其中一個版本。
憑證鏈完整，瀏覽器沒有顯示不受信任的警告。
CSS、JavaScript、字型與圖片均可透過 HTTPS 載入。

現代 Chrome 不一定會顯示傳統的綠色鎖頭，因此應以瀏覽器網址列的網站資訊、開發人員工具及憑證內容為準，不能只用圖示顏色判斷。

STEP 02：找到伺服器設定檔

Apache 常見設定位置是網站根目錄中的 .htaccess，共享主機通常位於：

public_html/.htaccess

若看不到檔案，先確認主機檔案管理器已開啟「顯示隱藏檔案」。如果原本已有 .htaccess，應先下載備份，不要直接刪除既有的 WordPress、快取或權限規則。

IIS 網站則通常使用 web.config，也可以從 IIS 管理員的「URL Rewrite」介面建立規則。搜尋 IIS HTTP 重新導向或 HTTP 轉 HTTPS IIS 的管理者，應先確認伺服器是否已安裝 URL Rewrite 模組。

STEP 03：寫入 HTTP 轉 HTTPS 規則

規則的核心是判斷目前連線是否尚未使用 HTTPS；若是，就把使用者重新導向相同網域、路徑及查詢參數的 HTTPS 網址。

STEP 04：測試首頁、內頁與重新導向狀態

設定完成後，不只要測試首頁，也應測試文章頁、分類頁、帶參數網址及不存在的頁面，例如：

http://example.com/
http://example.com/category/page
http://example.com/product?id=100

理想結果是每個 HTTP 網址只經過一次 301，直接到達最終 HTTPS 網址。若同時處理 www、非 www 和 HTTPS，最好合併規則，避免形成兩次以上的轉址鏈。

HTTP 與 HTTPS 的差異

HTTP 預設使用 TCP 80 Port，傳輸內容本身沒有經過 TLS 加密；HTTPS 預設使用 TCP 443 Port，會先建立 TLS 加密連線，再傳輸 HTTP 內容。這也是 HTTP HTTPS 差異最重要的核心。

HTTP、HTTPS 與轉址方式比較表

比較項目	HTTP	HTTPS
預設通訊埠	80 Port	443 Port
傳輸保護	未使用 TLS 加密	使用 TLS 加密
網址格式	`http://example.com`	`https://example.com`
憑證需求	不需要 SSL/TLS 憑證	需要有效的 SSL/TLS 憑證
資料風險	較容易遭攔截或竄改	可降低傳輸內容遭竊聽或竄改的風險
瀏覽器提示	可能標示為不安全	憑證正確時顯示安全連線資訊
SEO 建議	不建議作為正式版本	建議作為正式索引版本
建議轉址	轉向 HTTPS	保留為最終版本

有些人會把網址誤寫成 http:/example.com，但正確格式必須是 http://example.com，也就是在冒號後使用兩個斜線。進行 HTTP HTTPS 設定時，應完整填入通訊協定、網域與必要路徑，避免因網址格式錯誤造成規則失效。

HTTPS 能保護資料傳輸過程，但不等於網站本身絕對安全。網站仍需修補程式漏洞、更新套件、設定權限，並防範惡意程式與帳號遭入侵。

Apache 使用 .htaccess 強制轉址

當網站已安裝有效憑證，且 Apache 已啟用 mod_rewrite，可在 public_html 或網站根目錄建立 .htaccess。建議先備份原始檔案，再把規則放在其他應用程式重寫規則之前。

通用的 HTTPS 轉址規則

apache

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://%{HTTPHOST}%{REQUESTURI} [L,R=301]

RewriteEngine On 用來啟用重寫功能；RewriteCond %{HTTPS} !=on 只在目前不是 HTTPS 時執行；RewriteRule 則保留原始主機名稱與路徑，並以 301 導向 HTTPS。

如果網站架設於反向代理、CDN 或負載平衡器後方，來源伺服器可能始終收到 HTTP 連線。此時只判斷 %{HTTPS} 可能產生無限循環，必須依主機商或代理服務提供的標頭設定，例如 X-Forwarded-Proto。由於代理架構不同，不應未經確認就直接複製規則。

統一為 HTTPS 與 www 網域

若正式網址指定為 https://www.example.com，可使用固定網域：

apache

RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]

RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]

RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

請把 example.com 改成實際網域。部分校園或機構網站可在後台的「參數設定」與「基本資料設定」查詢網站域名，例如 xxx.site.nthu.edu.tw，但仍應以網站管理單位提供的正式主機名稱為準。

.htaccess 設定檢查清單

確認檔名是 .htaccess，不是 .htaccess.txt。
確認檔案位於實際網站根目錄。
確認 Apache 允許 .htaccess 覆寫設定。
確認 mod_rewrite 已啟用。
檢查規則是否與 WordPress、CMS 或快取規則衝突。
清除瀏覽器、網站、CDN 與反向代理快取。
確認回應狀態碼是 301，而不是錯誤的 200 或 302。
檢查是否出現 ERR_TOO_MANY_REDIRECTS 重新導向循環。

IIS 將 HTTP 自動轉成 HTTPS

IIS 可使用「HTTP 重新導向」功能，也可安裝 IIS URL Rewrite 模組。若目標是保留每個原始路徑並建立彈性條件，URL Rewrite 通常比較適合 HTTP 自動轉 HTTPS。

在 Windows Server 的「新增角色及功能」中，可依序展開「Web 伺服器（IIS）」、「Web 伺服器」、「一般 HTTP 功能」，再勾選「HTTP 重新導向」。若使用 URL Rewrite，則需確認該模組已安裝，之後重新開啟 IIS 管理員。

使用 IIS URL Rewrite 管理介面

開啟 IIS 管理員後，選擇要設定的網站，雙擊「URL Rewrite」，再依序選擇「新增規則」、「空白規則」，並設定：

規則名稱：Redirect HTTP to HTTPS。
要求的 URL：符合模式。
使用：規則運算式。
模式：(.*)。
條件輸入：{HTTPS}。
條件模式：^OFF$。
動作類型：重新導向。
重新導向 URL：https://{HTTP_HOST}/{R:1}。
重新導向類型：永久（301）。
勾選停止處理後續規則。

IIS 的 web.config 範例

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect HTTP to HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="^OFF$" />
          </conditions>
          <action type="Redirect"
                  url="https://{HTTP_HOST}/{R:1}"
                  redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

若 IIS 前方另有 Azure、Cloudflare、負載平衡器或其他反向代理，必須確認 HTTPS 是在哪一層終止。錯誤判斷 {HTTPS} 可能使 IIS 不斷重新導向，因此正式套用前應先在測試環境驗證。

301 與 302 重新導向如何選擇

網站正式改用 HTTPS 時，原則上應採用 301 永久重新導向。302 表示暫時轉址，適合短期測試、維護或未確定最終網址的情況，不適合長期 HTTP 到 HTTPS 遷移。

301 與 302 比較表

項目	301 重新導向	302 重新導向
性質	永久性	暫時性
適用情境	正式改用 HTTPS	短期測試或暫時搬移
搜尋引擎理解	原網址已永久更換	原網址未必永久更換
SEO 訊號	有利於整合到新網址	長期使用可能造成網址判定不明
快取影響	可能被瀏覽器長期快取	通常較容易變更
HTTP 轉 HTTPS 建議	建議使用	僅限暫時需求

301 可以協助搜尋引擎整合舊網址與新網址訊號，但不代表排名一定立即提升。搜尋引擎仍需重新檢索和處理網址，網站內容品質、效能、內部連結及技術狀態也會影響結果。

HTTPS 遷移的 SEO 設定

完成重新導向只是第一步。若頁面內部仍引用 HTTP 網址，搜尋引擎與使用者可能遭遇混合內容、重複網址或不必要的轉址。

SEO 與網站設定檢查項目

將內部連結全部改為 HTTPS。
將 canonical 標籤改為最終 HTTPS 網址。
更新 XML Sitemap，僅保留可索引的 HTTPS 網址。
更新 robots.txt 內的 Sitemap 位置。
確認 hreflang、Open Graph 與結構化資料網址。
將圖片、CSS、JavaScript、字型及 API 改為 HTTPS。
在 Google Search Console 確認 HTTPS 網址的索引與錯誤狀況。
更新 GA4、廣告平台與第三方驗證設定。
保留 HTTP 轉址，不要在遷移完成後立即移除。
避免 HTTP 先轉 www，再轉 HTTPS 的多層轉址鏈。

如網站已完成全站 HTTPS 且運作穩定，可評估加入 HSTS 回應標頭。不過 HSTS 會要求瀏覽器在指定期間內只使用 HTTPS，若憑證、子網域或服務尚未準備完成，可能導致使用者無法連線，因此不應在遷移初期貿然啟用。

為什麼 Chrome 會把 HTTP 改成 HTTPS

使用者搜尋 Chrome HTTP 不要轉 HTTPS，通常是因為 Chrome 曾記錄 HSTS、瀏覽器啟用優先使用安全連線、伺服器已回傳 301，或擴充功能與防毒軟體介入，而不一定是 Chrome 擅自修改網站設定。

排查 Chrome 自動轉向的方法

先使用無痕視窗、其他瀏覽器或命令列工具測試。如果伺服器回傳 301 或 302，應修改伺服器、CMS、CDN 或代理層規則，而不是只清除瀏覽器資料。

如果伺服器沒有回傳轉址，才進一步檢查瀏覽器的安全連線設定、網站資料、快取與擴充功能。若網域已送入 HSTS Preload List，瀏覽器會在送出 HTTP 請求前直接改用 HTTPS，網站端不能要求一般使用者忽略這項安全政策。

「HTTP 不要轉 HTTPS」只適合本機開發、封閉測試或特定相容性診斷。正式公開網站若涉及登入、表單、付款或個人資料，不應停留在 HTTP。即使沒有敏感資料，未加密內容仍可能在傳輸途中被讀取或竄改。

HTTP 轉 HTTPS 的測試方法

完成設定後，應同時檢查狀態碼、Location 標頭、憑證與頁面資源，而不是只確認首頁看起來能開啟。

使用 curl 檢查回應

bash

curl -I http://example.com/test-page

正確結果通常應包含：

HTTP/1.1 301 Moved Permanently
Location: https://example.com/test-page

接著檢查最終 HTTPS 網址：

bash

curl -I https://example.com/test-page

最終頁面應依實際情況回傳 200 OK，而不是再次回到 HTTP。若看到大量 301、302 連續跳轉，表示規則可能重複存在於 Apache、IIS、CMS、CDN 或負載平衡器。

結論

完整的 HTTP 轉 HTTPS 流程是先安裝並驗證 SSL/TLS 憑證，再透過 Apache .htaccess 或 IIS URL Rewrite 建立 301 永久重新導向，最後更新內部連結、canonical、Sitemap 與所有頁面資源。

80 Port 提供一般 HTTP 連線，443 Port 提供經 TLS 保護的 HTTPS 連線，但開放 443 Port 並不代表設定已完成。網站管理者仍要確認憑證、轉址狀態碼、混合內容、代理架構及 SEO 訊號。以單次 301 直接抵達最終 HTTPS 網址，通常是安全性、使用體驗與搜尋引擎處理上較穩定的做法。

常見問題

1. 已有 SSL 憑證，為什麼 HTTP 不會自動轉成 HTTPS？

SSL 憑證只讓伺服器具備 HTTPS 連線能力，不會自動建立轉址。您仍需在 Apache、IIS、NGINX、CMS、CDN 或主機控制台設定 301 重新導向。

2. .htaccess 應該放在哪裡？

通常放在 public_html 或網站文件根目錄。若網站位於子目錄，必須確認該子目錄是否為實際對外的文件根目錄，並先備份原有檔案。

3. HTTP 轉 HTTPS 應該使用 301 還是 302？

正式且永久改用 HTTPS 時建議使用 301。302 適合短期測試或暫時轉址，不建議作為長期 HTTPS 遷移方案。

4. 為什麼設定後出現重新導向次數過多？

常見原因是多個系統同時執行轉址，或網站位於反向代理後方，來源伺服器無法正確辨識原始 HTTPS 連線。應檢查 CDN、代理、CMS、.htaccess 與 IIS 規則。

5. 為什麼 HTTPS 頁面仍被瀏覽器標示不安全？

可能是憑證過期、網域不符、憑證鏈不完整，或頁面仍透過 HTTP 載入圖片、腳本、字型及 API。可使用瀏覽器開發人員工具檢查混合內容。

6. 只轉首頁到 HTTPS 可以嗎？

不建議。每個 HTTP 內頁都應轉到相同路徑的 HTTPS 版本，而不是全部導向首頁，否則會影響使用體驗，也可能讓搜尋引擎無法正確理解頁面對應關係。

7. HTTP 轉 HTTPS 後會立即提升 SEO 排名嗎？

不一定。HTTPS 是重要的安全與技術基礎，但排名還取決於內容品質、搜尋意圖、網站效能、連結及可索引性。遷移後也需要時間重新檢索與整合訊號。

8. 可以關閉 Chrome 的 HTTPS 自動升級嗎？

部分情況可調整瀏覽器的安全連線偏好，但若網站已設定 301、HSTS 或進入 HSTS Preload List，僅調整瀏覽器通常無法阻止轉向。應先確認轉址來源。

9. IIS 沒有看到 URL Rewrite 功能怎麼辦？

通常表示尚未安裝 IIS URL Rewrite 模組，或目前選取的管理層級不正確。完成安裝後，重新啟動 IIS 管理員，再選擇實際網站進行設定。

10. HTTP 轉 HTTPS 後可以關閉 80 Port 嗎？

一般不建議立即關閉。保留 80 Port 才能接收舊 HTTP 網址請求並回傳 301，引導使用者與搜尋引擎前往 HTTPS。若直接關閉，HTTP 使用者可能只會看到連線失敗。