HTTP 換 HTTPS 完整攻略：不只更安全，還能提升 SEO 排名
HTTP 與 HTTPS 的根本差別，在於 HTTPS 多了一層 TLS 加密與身分驗證：HTTP 把密碼、表單、Cookie 當成明文送出，任何中間節點都能側錄竄改。憑證那個字母…
HTTP 與 HTTPS 的根本差別，在於 HTTPS 多了一層 TLS 加密與身分驗證：HTTP 把密碼、表單、Cookie 當成明文送出，任何中間節點都能側錄竄改。憑證那個字母本身對 SEO 的幫助有限，真正撐起價值的是它解鎖的 HTTP/2、HTTP/3 速度、E-E-A-T 的可信度，以及拿掉「不安全」警告後留下來的使用者。想先把基礎觀念補齊，可以看 HTTPS 網站加密的入門介紹。
重點先看：根據 Google Webmaster Central Blog 2014 年的公告，HTTPS 自 2014 年起被列為排名訊號，但 Google 自承只是「非常輕微的加分」（lightweight tie-breaker）；真正決定 SEO 漲跌的，是 301 轉址、混合內容、追蹤工具這三件收尾有沒有同步換好。
HTTP 與 HTTPS 的核心差異
HTTP 是未加密的明文傳輸協定，資料在中途可以被攔截、竄改；HTTPS 則是加上 TLS 加密與身分驗證的版本，能確保傳輸內容的機密性、完整性，並證明你連到的真的是官方網站，是現代網站的標準配置。兩者看似只差一個字母，底層運作卻是完全不同的兩套機制，想理解為什麼瀏覽器要對 HTTP 網站顯示「不安全」，得先把這層差異拆開看。
HTTP 把網頁資料當純文字送出，密碼、表單內容、登入 Cookie 在經過的任何節點都可能被讀走。HTTPS 則透過 TLS 交握協商出一把只給這次連線用的工作階段金鑰，後續所有資料都用這把金鑰加解密，第三方攔截到的只會是密文。如果你正在規劃 SEO 網址結構與 URL 命名建議 或整體的網站架構，HTTPS 應該被當成基礎建設的一部分，在架站初期就一併規劃進去，避免事後才回頭補。
TLS 憑證同時做兩件事：加密資料（機密性加上完整性）與驗證伺服器身分（防釣魚）。這也是為什麼裝了憑證的網站，瀏覽器網址列會出現鎖頭圖示、https:// 前綴、沒有「不安全」警示，這三個訊號是使用者第一眼判斷網站可信度的依據。口語講的 SSL 早已被淘汰（根據 IETF 文件，最後版本 SSL 3.0 因 POODLE 等漏洞被棄用），現在真正在跑的是 TLS，主流版本為 TLS 1.2 與 TLS 1.3（依 IETF RFC 8446 規範），只是大家習慣統稱 SSL／TLS 憑證。
| 比較項目 | HTTP | HTTPS |
|---|---|---|
| 傳輸方式 | 明文純文字 | TLS 加密傳輸 |
| 資料機密性 | 無，中途可被讀取 | 有，攔截到的是密文 |
| 身分驗證 | 無，無法確認伺服器真偽 | 由 CA 簽發憑證驗證身分 |
| 預設埠號 | 80 | 443 |
| 瀏覽器顯示 | 標示「不安全」 | 鎖頭圖示、https:// 前綴 |
| SEO 訊號 | 無加分、被視為落後 | Google 列為輕微排名訊號 |
| 適用情境 | 純內部測試、無輸入的靜態頁 | 所有正式網站、金流與會員站 |
明文到底「暴露」了什麼：一個欄位的旅程
要真正理解 HTTP 的風險，最有用的方式是把一筆登入請求拆成它經過的每一段路。當使用者在 HTTP 頁面按下「送出」，帳號與密碼會以純文字封包的形式，從瀏覽器出發，經過使用者的家用路由器、ISP 的接取網路、一連串骨幹節點，最後才抵達網站伺服器。在這整條路徑上，任何一個能讀到封包的節點，看到的內容都和原始輸入一模一樣，不需要解密、不需要破解，只要願意側錄就能讀走。
HTTPS 把這條旅程徹底改寫。同樣一筆登入請求在出發前，會先被工作階段金鑰加密成密文，中途經過的所有節點攔截到的都只是亂數般的字串，只有持有金鑰的伺服器能還原成原本內容。這個差異的重量，取決於頁面處理的是什麼資料：純展示的靜態文字暴露的只是頁面本身，但只要欄位裡出現密碼、身分證字號、信用卡號或個人通訊資料，明文傳輸的代價就直接跳到另一個層級。
| 欄位類型 | 明文傳輸的暴露風險 | 加密後的保護 |
|---|---|---|
| 密碼、登入憑證 | 可被側錄後直接盜用帳號 | 密文，側錄也無法還原 |
| 信用卡號、金融資料 | 可被用於盜刷與詐騙 | 密文，符合 PCI-DSS 傳輸要求 |
| 個人身分資料（身分證、地址、病歷） | 違反個資法規、損及隱私 | 密文，降低外洩衝擊 |
| 會員 Cookie、工作階段權杖 | 可被劫持冒充登入（session hijacking） | 密文搭配 Secure 屬性防竊取 |
| 純展示的公開文字內容 | 暴露有限，但仍可被中途竄改插入廣告 | 完整性保護防竄改 |
瀏覽器對 HTTP 網站標示「不安全」的成因
Chrome、Safari 把 HTTP 網站標示成「不安全」，根本原因在於 HTTP 把所有傳輸內容用明文送出，任何經過的中間節點都能讀取或竄改，瀏覽器無法替使用者擔保帳密、信用卡不會外洩，只好主動標示警告。明文傳輸的風險場景相當常見：公共 Wi-Fi（咖啡廳、機場、飯店）、企業內網閘道、被劫持的路由器，都能側錄 HTTP 流量；在封包分析工具底下，一個 HTTP 表單送出的帳號密碼會直接以明文躺在封包裡，連解密都不必。風險也不限於登入頁，只要頁面含表單、Cookie、個人資料，明文傳輸就會暴露。
根據 Google Chrome 官方部落格的說明，Chrome 自 2018 年 7 月（版本 68）起對所有 HTTP 頁面全面標示「不安全」，並非只針對有輸入欄的頁面。這個改變對使用者的實際影響很直接：跳出率上升、信任下降，尤其是電商與會員網站。顧客在結帳頁看到「不安全」三個字，願意把信用卡號填進去的比例會明顯下滑，這對 E-E-A-T 贏得 Google 信任的 SEO 策略 與站外的站外 SEO 經營來說都是直接的扣分項。
把「不安全」的殺傷力想清楚，會發現它對不同類型網站的衝擊並不均等。決定殺傷大小的兩個維度，是頁面處理的資料敏感度，以及使用者被警告後的退出成本。底下這張矩陣，把常見站點類型放進這兩個維度裡對照，幫你判斷自己的站落在哪一格，該用多快的速度補上 HTTPS。
| 網站類型 | 資料敏感度 | 「不安全」對轉換的衝擊 | 補上 HTTPS 的急迫度 |
|---|---|---|---|
| 金流結帳、線上刷卡頁 | 極高（信用卡、金融資料） | 結帳放棄率明顯升高 | 立即，不可拖延 |
| 會員登入、後台系統 | 高（帳密、個資） | 帳號被盜風險、信任崩跌 | 立即 |
| 醫療、金融諮詢頁（YMYL） | 高（隱私、財務決策） | 信任與專業形象受損 | 立即 |
| 含表單的內容站、訂閱頁 | 中（Email、聯絡資料） | 名單轉換下滑 | 短期內 |
| 純展示、無輸入的靜態頁 | 低（公開內容） | 形象扣分、可被中途竄改 | 排入排程，仍建議補 |
矩陣右側那欄的判斷邏輯，可以濃縮成一個簡單的取捨原則：頁面收集的資料越敏感，「不安全」警告對轉換與信任的折損就越嚴重，補上 HTTPS 的成本相對於潛在損失也就越微不足道。換句話說，真正該計算的從來不是憑證的價格，而是不裝憑證之後流失的訂單與名單。
把「不安全」這三個字掛在網址列，對一個用心做的網站是相當傷的形象打擊。連 HTTPS 都還沒上的站，在現代瀏覽器裡已經是預設被貼標籤的狀態。網址的呈現也會牽動使用者的第一印象，無論是 中文網址與英文網址的選擇，或帶了追蹤參數時要釐清的 網址查詢參數的作用與影響，背後都是同一個信任門檻的問題。沒有 HTTPS 的站在可信度評估上本來就吃虧。
SSL／TLS 憑證與加密交握的運作機制
HTTPS 靠 SSL／TLS 憑證建立加密連線，運作方式是：瀏覽器先向伺服器索取憑證並驗證真偽，雙方協商出一組只給這次連線用的工作階段金鑰，後續所有資料都用這把金鑰加解密，第三方攔截到的只會是密文。這套機制把「加密」和「驗證」兩件事綁在一起，缺一不可。交握過程可以拆成幾個關鍵步驟：瀏覽器發出 ClientHello 告訴伺服器自己支援哪些加密套件，伺服器回傳憑證並附上公鑰，瀏覽器驗證憑證鏈是否可信、有沒有過期或被撤銷，確認無誤後雙方協商出工作階段金鑰，接下來就用這把金鑰做對稱加密通訊。TLS 1.3 把這個流程壓縮到只需一個往返（1-RTT），甚至可以做到 0-RTT 恢復連線（依 IETF RFC 8446 規範），這也是為什麼現代 HTTPS 幾乎感受不到加密帶來的延遲。
這裡有個常被誤解的地方值得澄清：非對稱加密（公私鑰）只用來交換金鑰，真正傳資料用的是速度快的對稱加密。原因是非對稱加密運算成本高，拿來加密整個網頁傳輸會慢得無法接受，所以實務上是用非對稱加密保護金鑰交換、再用對稱加密跑資料流。憑證的角色像網站身分證，由受信任的憑證頒發機構（CA）簽發，瀏覽器據此判斷這個網站是不是它宣稱的那個。憑證驗證的是網域身分而非主機本身，所以申請網域時 DNS 指向正確與否，會直接影響憑證能不能簽發下來，這部分可對照 DNS 網域名稱指向設定教學。
至於 DV、OV、EV 三種驗證等級，差別只在「查得多嚴」，加密強度三者完全一樣。DV（網域驗證）只要證明你擁有這個網域就能簽發，幾分鐘到手；OV（組織驗證）會核對公司基本資料；EV（延伸驗證）要做最嚴格的企業身分審查（依 CA/Browser Forum 基準要求）。選哪一種，重點在於你的網站需要多高的身分證明，憑證等級也不會影響重複內容或技術性 SEO 的處理邏輯。
交握失敗時的判讀與排查
憑證裝好不代表連線一定通。TLS 交握牽涉憑證鏈、加密套件、協定版本、伺服器設定多個環節，任何一個出狀況，使用者看到的就會是一整頁錯誤，而非網站內容。常見的交握失敗多半落在幾個固定類型，差別在於瀏覽器回報的訊息與背後的成因不同。
| 失敗類型 | 典型瀏覽器訊息 | 排查方向 |
|---|---|---|
| 憑證鏈不完整（中繼憑證遺漏） | 「憑證無法驗證」，部分瀏覽器正常、部分失敗 | 把 CA 提供的中繼憑證一併部署，憑證鏈要能一路回溯到受信任的根憑證 |
| 憑證網域不符（SAN 未涵蓋） | 「憑證對這個網域名稱無效」 | 確認主網域與所有子網域（含 www 與非 www）都列入 SAN |
| 協定版本過舊（只開 TLS 1.0／1.1） | 直接拒絕連線或回報加密過弱 | 關閉 TLS 1.0／1.1，改啟用 TLS 1.2／1.3，移除不安全的加密套件 |
| 憑證過期或被撤銷 | 跳出明顯警告畫面 | 檢查到期日與自動續期排程；已撤銷者需重新簽發，不能只重啟伺服器 |
排查這類問題時，免費的 SSL Labs 線上檢測工具是很好的起點，它會把憑證鏈、協定版本、加密套件、已知漏洞一次列出評分。把評分報告抓下來對照上面的清單，通常能在幾分鐘內定位是哪一個環節出狀況，比起在伺服器逐一翻設定更有效率。
依主機環境選擇 HTTP 到 HTTPS 的遷移流程
遷移流程因主機環境而異：共享虛擬主機多能在後台一鍵啟用免費 Let's Encrypt 憑證；雲端主機（AWS、GCP）有內建憑證管理服務；自架伺服器需手動申請憑證並在 Apache／Nginx 設定；WordPress 等 CMS 則是先裝憑證再用外掛強制 HTTPS。沒有一套流程適用所有站，先確認你的網站屬於哪一種環境，才知道該走哪條路。
共享虛擬主機（如 Bluehost、SiteGround）通常在後台的 Security 選項裡就能找到 SSL 憑證開關，一鍵啟用免費 Let's Encrypt 憑證，適合新手與中小型網站。以 Bluehost 為例，登入後台進到 My Sites，點右上方 Security，下方有 Security Certificate 開關，打開後等憑證簽發完成即可，整個過程不用碰指令；託管型平台（Wix、Shopify）則直接內建 HTTPS，系統自動啟用，只要確認網址設定正確即可。詳細的後台操作可以對照 Bluehost 虛擬主機附贈 SSL 憑證教學。
雲端主機的優勢在於自動化。AWS Certificate Manager 與 Google Cloud SSL 都把申請、部署、續期全部包進平台服務，憑證到期前系統會自動換發，憑證綁在負載平衡器上，幾乎不用人工介入。自架伺服器（Apache、Nginx）則得自己用 certbot 申請憑證，手動設定虛擬主機的 443 埠與憑證路徑。在選主機時，共享、VPS、雲端主機類型比較 能幫你釐清哪一種環境最適合你的站。
WordPress 自架站多一步後台設定。憑證裝好後，到「設定 → 一般」把 WordPress 網址與網站網址兩個欄位都改成 https:// 開頭，再用 Really Simple SSL 之類的外掛強制轉向，或直接在伺服器層寫 301 規則。如果你才剛開始架站，30 分鐘架好 WordPress 網站 會把 SSL 啟用納入流程；若已經是舊站，WordPress 零停機搬家到新主機 的搬家流程也能順便把 HTTPS 一併處理掉。
不論哪一種主機，通用收尾一定要做：設 301 永久轉址、清混合內容、把分析工具與 Sitemap 切到 HTTPS 版本。這幾件事是遷移成敗的分水嶺，少做一件，後面的排名波動與數據失準就會找上門。其中 Search Console 的安裝步驟 是檢查遷移成效時最常用到的入口，Sitemap 的觀念則可參考 XML Sitemap 對 SEO 的作用。
遷移後一定要檢查的收尾清單：301 轉址、混合內容與追蹤工具
升級完成只是起點，真正決定成敗的是收尾：所有 HTTP 網址都要設 301 永久轉址導到 HTTPS、清掉頁面裡殘留的 HTTP 資源（混合內容）、並把 Google Search Console、GA4 等追蹤工具同步換到 HTTPS 版本，否則排名會波動、流量數據也會失準。
301 永久轉址能把原本的 SEO 權重傳到 HTTPS 版本，千萬不要用 302 暫時轉址。根據 Google Search Central 文件的說明，301 是傳遞排名訊號的正確做法，302 則會被當成暫時狀態，權重傳遞不完全。實務上，所有 http:// 開頭的網址都要能在伺服器層被導到對應的 https:// 版本，包含首頁、文章頁、分類頁、圖片資源，一個都不能漏。詳細的轉址差異可以看 301 與 302 轉址的 SEO 設定差異。
混合內容（mixed content）是另一個常見地雷。當 HTTPS 頁面裡還藏著 http:// 的圖片、CSS、JS，瀏覽器會把這些資源擋掉，結果就是鎖頭變灰、圖片破圖、版面崩掉（根據 Chrome 開發者文件的說明）。WordPress 站可以用 Better Search Replace 或 Velvet Blues Update URLs 批次把資料庫裡的 http:// 全部換成 https://，但跑之前記得先 WordPress 備份與還原完整指南 描述的那樣備份一次，免得改壞沒得退。
追蹤工具的同步最容易漏。Search Console 要新增一個 HTTPS 屬性（不是在舊的 HTTP 屬性裡改），並重新提交 Sitemap，因為 Google 會把 HTTP 與 HTTPS 視為兩個不同的網站；還沒接觸過這套工具的話，先從 Google Search Console 介紹 建立基本概念會比較順手。GA4 要在資料串流設定裡把網址改成 https://；如果有跑 Meta Pixel，得到 Business Manager 驗證網域。來源資訊（referrer）跨 HTTP／HTTPS 會被瀏覽器 strip，沒全站換 HTTPS 會讓流量被誤判為直接流量，這也是爬取預算優化之外，另一個會讓數據變形的隱形因素。
憑證續約千萬別拖。根據 Let's Encrypt 官方文件，憑證效期是 90 天，由 ISRG 營運，靠自動化續期維持；付費憑證通常一年到期。一旦憑證過期，瀏覽器會直接跳出大大的警告畫面，對使用者信任的殺傷力比一開始就不裝還大。自架伺服器用 certbot 設定自動續訂指令，共享主機多半已內建自動續期，網域商後台的 DNS 與憑證設定也能一併檢查。
以這類月流量約 3 萬到 8 萬的工作階段、文章數落在 150 到 400 篇的內容站為例，常見的狀況是：憑證本身在共享主機後台一鍵啟用，依典型表現幅度約 10 到 30 分鐘就能簽發完成；真正吃掉時間的是收尾，整批把資料庫裡殘留的 http:// 圖片、內文連結、範本網址換成 https://，加上補 301 規則、重新提交 Sitemap，依這類站的規模約落在 2 到 6 小時之間，視文章數與外掛批改工具的熟悉度而定。會拖長收尾時間的常見因素有幾個：文章累積年份較久、中間換過佈景主題或外掛、圖片曾用第三方圖床外連、或內文裡夾帶大量舊版追蹤參數，這些都會讓 http:// 殘留點變得分散難抓，需要靠資料庫批次替換搭配開發者工具逐一過濾才能清乾淨。另一個容易被低估的環節是外部反向連結：站內網址可以靠工具一次改完，但站外別人連過來的 http:// 連結無法直接更動，只能靠 301 把這些舊連結的權重接住，這也是為什麼收尾時 301 規則要盡可能涵蓋所有曾經存在過的網址結構，而不只是首頁與分類頁。若舊站曾換過網址結構或刪過文章，建議一併整理一份歷史網址清單，對照新的 https:// 版本逐一補上對應規則，避免少數長尾網址沒有被接住而回傳 404，讓權重白白流失。
這類站最常翻車的點不在憑證，而在混合內容沒清乾淨。常見的狀況是資料庫用外掛批次替換後，舊佈景主題或自訂欄位裡還藏著少數 http:// 資源，導致鎖頭變灰、部分瀏覽器破圖，這類殘留往往要等使用者回報才會被發現；另一個常見遺漏是 GA4 資料串流網址沒跟著換，讓流量被拆成兩組數字，搜尋來源的報表會出現一段無法對接的斷層。實務上常見的做法是遷移後用 SSL Labs 跑一次完整檢測、搭配瀏覽器開發者工具的 Console 過濾 mixed content 警告，把殘留點一個個補掉；若站上有快取外掛或 CDN，記得在驗證前先清一次快取，否則殘留警告可能被快取層暫時蓋過、過幾天又冒出來；舊佈景主題裡寫死的 http:// 路徑尤其容易被忽略，因為批次替換工具多半只掃資料庫欄位，不會去碰佈景的範本檔，這類殘留得手動進範本原始碼逐一把 http:// 改成 https://，或直接改用相對協定（protocol-relative）寫法。需要誠實提醒的是，上述流量與時長幅度是依這類站的典型表現推估的參考區間，不是精確測量值，實際數字會因站齡、外鏈結構、主機環境與收尾完整度而不同；真正該決定的不是「要不要做 HTTPS」（這在 2026 年早已不是選項），而是「要在哪個流量淡季挪一個下午把收尾一次做乾淨」，避免一邊遷移、一邊還要應付排程上的內容更新。
HTTPS 對 SEO 的實際作用
HTTPS 自 2014 年起就是 Google 公開的排名因素之一，但只是輕微的 tie-breaker；它真正撐起 SEO 價值的是三個配套：支援 HTTP/2、HTTP/3 帶來的速度提升、E-E-A-T 中「可信度」的加分、以及拿掉「不安全」警告後停留與轉換的改善。根據 Google Webmaster Central Blog 2014 年的公告，這個 tie-breaker 的意思是只有在兩個網站其他條件幾乎相同時，HTTPS 才會成為那最後一根稻草。指望裝了憑證排名就一飛衝天不切實際，但不裝等於自動放棄一個本來可以拿的分。評估成效時，除了 Google Search Console 的基礎認識，也可以用 Bing 關鍵字搜尋量的免費查詢方法 交叉比對流量來源。
| SEO 影響層面 | 直接效果 | 實際權重 |
|---|---|---|
| 排名訊號加分 | 列為排名因素 | 輕微 tie-breaker |
| HTTP/2、HTTP/3 速度 | 多工、標頭壓縮、降延遲 | 透過 Core Web Vitals 間接加分 |
| E-E-A-T 可信度 | Trust 面提升 | 對 YMYL 類網站尤其關鍵 |
| 拿掉「不安全」警告 | 降低跳出率 | 改善行為訊號，長期助益 |
| 遷移初期波動 | Googlebot 視為新網址 | 短期波動、長期恢復 |
遷移初期 Googlebot 會把 HTTPS 當成新網址，舊的 HTTP 版本仍會並存一段時間。如果沒設好 301 與 Sitemap，爬蟲可能把它當成重複內容，導致短期排名波動或流量下滑，這屬正常現象，通常會在 Google 重新抓取索引後逐步恢復。真的掉了流量先別慌，照 Google 排名下滑的急救技巧 的步驟檢查轉址與索引，多半能找到原因。HTTP 與 HTTPS 並存時容易產生 SEO 重複內容的成因與解法，這時搭配 Canonical 標記指定標準網址 來明確宣告版本，能避免權重被分散。這也是為什麼 關鍵字蠶食與重複網址的修復 在遷移後特別值得做一次健檢。
E-E-A-T 的 Trust 面會因 HTTPS 而受到正面評估，對醫療、金融、YMYL（Your Money Your Life）類網站尤其關鍵。根據 Google Search Central 品質評估指南，網站安全性被列為可信度評估的一環，這不保證直接加分，但至少不會在 Trust 這一項被扣分。拿掉「不安全」警告降低跳出率，這對行為訊號與長期排名的間接幫助，往往大於那個輕微的直接加分。這些速度改善會反映在 Core Web Vitals 的 LCP、INP 上，連帶影響排名，可對照 Core Web Vitals 核心指標優化 與 E-E-A-T 原則到底在評什麼 做整體規劃。
把 HTTPS 放回 Google 的「頁面體驗」框架裡看，會更清楚它的定位。Google 在 2020 年公布的頁面體驗排名訊號，明確把 Core Web Vitals 與既有訊號合併成一組評估，其中就涵蓋了 HTTPS 安全性與行動裝置相容性 [來源：Google Search Central Blog〈Evaluating page experience〉〈https://developers.google.com/search/blog/2020/05/evaluating-page-experience〉〈2020-05-28〉]。換句話說，HTTPS 屬於整組頁面體驗訊號裡的一塊拼圖，少了它，這一組訊號就缺了一角。對已經把 Core Web Vitals 做到合格的站來說，HTTPS 就是把整組體驗訊號補齊的最後一哩路，本身並非額外裝飾。
免費 vs 付費 SSL 憑證：加密一樣強，差在驗證與保障
兩者在加密強度上完全相同，差別在身分驗證嚴格度、有效期限長短、技術支援與賠償保障：免費憑證（如 Let's Encrypt）只做網域驗證、期限短但自動續期，適合個人與小型站；付費憑證有 OV／EV 等級、效期長、有客服與賠償，適合金流與企業網站。選哪種，純粹是風險管理的考量，跟加密安全度無關。
先把一個常見誤解拆掉：免費憑證不會比付費「弱」。兩者用的是同一套 TLS 加密標準，瀏覽器看到的鎖頭、加密強度完全一樣，差別只在於憑證背後驗證了什麼。Let's Encrypt 只做 DV（網域驗證），證明你擁有這個網域就簽發，效期 90 天，靠 ACME 協定自動續期，零成本（依 Let's Encrypt 官方文件），已成為全球使用最廣的免費憑證來源之一。
| 比較項目 | 免費憑證（Let's Encrypt） | 付費憑證（OV／EV） |
|---|---|---|
| 加密強度 | 與付費相同 | 與免費相同 |
| 驗證等級 | DV 網域驗證 | OV 組織驗證、EV 延伸驗證 |
| 有效期限 | 90 天，自動續期 | 約 1 年 |
| 技術支援 | 社群文件、無客服 | 有客服與技術支援 |
| 賠償保障 | 無 | 有憑證瑕疵賠償 |
| 適用網站 | 純內容站、部落格、個人站 | 金流、個資、企業形象站 |
付費憑證可選 OV（組織驗證）或 EV（延伸驗證），CA 會核對公司登記、聯絡資訊、營運狀態，效期較長，通常附技術支援與憑證瑕疵賠償保障。這筆保障金對營利型網站來說是一種風險移轉，萬一因為憑證問題造成損失，至少有求償管道。選擇原則其實很簡單：純內容站用免費就夠，涉及金流、個資、企業形象的網站，建議往上買到 OV 或 EV 等級。如果你經營的是電商，WordPress 自架網站費用拆解 與 網站維護費用自己做 vs 委外 應該把憑證成本算進去；為了省一點小錢把信任風險全扛下來，並不划算。憑證裝好後，再回頭打磨 Title Tag 標題標籤的寫法，安全與內容齊頭並進，網站才有競爭力。
免費憑證的出現把 HTTPS 的門檻降到接近零，這對中小網站是大利多。主流主機商（SiteGround、FastComet、HostGator、A2 Hosting、Bluehost 等）幾乎都內建 Let's Encrypt 自動續期，裝好就有、到期自動續，沒有預算藉口，只有做不做的選擇。
HTTPS 與速度的關係：HTTP/2、HTTP/3 與 CDN
HTTPS 不會拖慢網站，反而通常更快。HTTPS 是 HTTP/2 與 HTTP/3 的前提，這兩個協定能多工處理連線、壓縮標頭、降低延遲；再加上 CDN 對 HTTPS 的全球加速支援，整體速度往往勝過舊的 HTTP。TLS 1.3 已經把交握輪次壓到最低，加密成本對現代硬體來說幾乎可以忽略；真正帶來速度紅利的是 HTTP/2 的多工（multiplexing）與標頭壓縮（HPACK／QPACK），讓一個連線可以同時處理多個請求，不再像 HTTP/1.1 那樣排隊，但主流瀏覽器只在 HTTPS 連線啟用 HTTP/2（依 RFC 7540 與主流瀏覽器實作）。CDN 普遍支援 HTTPS 加速，能在邊緣節點終結 TLS、快取內容，CDN 網站加速與 HTTPS 節點 與 網站快取 Cache 設定教學 把這層紅利再放大一層。
若升級後感覺變慢，問題通常出在憑證鏈不完整（逼瀏覽器額外查詢中繼憑證）、沒啟用 OCSP stapling、或頁面混入了阻塞型的大資源，與 HTTPS 本身無關。確認 HTTP/2 已開、掛上 CDN 把 TLS 終結與快取交給邊緣節點，就能進一步壓低延遲。把這些查完，可以再用 網站載入變慢的診斷與解法 搭配 Lazy Loading 延遲載入提升效能、圖片壓縮工具實測比較 依序把資源瘦身。
速度紅利最終會反映在 Core Web Vitals 的 LCP 與 INP，連帶影響排名。對電商這類轉換率與速度高度相關的網站來說，HTTPS 不只是安全防護，更是留住顧客與撐住轉換率的關鍵。速度對營收的影響有公開案例佐證：電信業者 Vodafone 把 LCP（最大內容繪製時間）改善 31%，隨之帶來 8% 的銷售成長 [來源：web.dev（Google）〈Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。這個數字說明，速度紅利會直接換算成訂單與營收，而 HTTPS 正是享用這波速度紅利的前提。
結語：憑證只是門票，收尾才是成敗
HTTPS 對排名的直接加權很小，這是 Google 自己承認的。它的真實價值來自它解鎖的一整套現代網站能力：HTTP/2、HTTP/3 的速度、E-E-A-T 的可信度、沒有「不安全」警告帶來的停留與轉換。裝憑證只是一張入場券，真正決定 SEO 往上還是往下的，是 301 轉址、混合內容、追蹤工具這些收尾動作有沒有做齊。配套做好，初期波動會在重新索引後恢復；配套做壞，遷移那陣子流量反而會先跌一截。網站要不要上 HTTPS，這件事在 2026 年早就不是問題了，剩下的問題只是收尾做得多乾淨。
如果你還在規劃階段，建議把 架站方式 WordPress、寫程式、平台比較 與 網域申請購買與 DNS 設定全攻略 一次想清楚，HTTPS 應該從一開始就寫進基礎建設，避免最後才回頭補。裝憑證、設轉址、清混合內容、同步追蹤工具，這幾件事做齊，HTTPS 就會是幫你加分的底層，日後也不必再回頭修補。想把整套 SEO 觀念串起來，可以參考 SEO 排名攻略學的系統化課程。
常見問題
哪些網站最該優先用 HTTPS？
涉及金流、個資、會員登入的電商、金融、醫療與 YMYL 類網站最該優先，因為「不安全」警告對這類網站的轉換率與信任殺傷最大。
什麼是 HSTS，網站需要設定嗎？
HSTS（HTTP Strict Transport Security）是透過回應標頭告訴瀏覽器「這個網站只能用 HTTPS 連線」的機制，能擋掉使用者誤打 http:// 或被中途劫持降級的風險。已經全站 HTTPS 的網站建議開啟 HSTS，並在確認轉址穩定後進一步申請加入瀏覽器預先載入清單（HSTS preload），讓第一次造訪的使用者也受到保護。設定時要先確定所有子網域都支援 HTTPS，否則可能把部分頁面鎖死無法開啟。
自簽憑證跟 CA 簽發的憑證有什麼差別？
自簽憑證可以自己產生、不用經過第三方，加密機制與正式憑證相同，但因為沒有受信任的憑證機構背書，瀏覽器會跳出警告、無法驗證網站身分。自簽憑證只適合內部測試或開發環境，正式上線給大眾使用的網站一律要用 CA 簽發的憑證，瀏覽器才會顯示鎖頭、使用者才不會看到警告畫面。
HTTP／HTTPS 並存會造成重複內容問題嗎？
會。Google 會把 http:// 與 https:// 視為兩個不同網站，若兩者同時可被索引又沒有 301 轉址與 Canonical 指向，權重就會被分散，甚至被判定為重複內容。解法是設好 301 把 HTTP 永久導向 HTTPS，並用 Canonical 標記明確宣告 HTTPS 為標準版本。