HTTPS 是什麼？網站為什麼需要 SSL 憑證

HTTPS 透過 TLS 保護瀏覽器與伺服器之間的連線。它提供加密、身分驗證與完整性保護，但不能證明網站內容可信或沒有惡意程式。Chrome 已在 2023 年將主要鎖頭圖示改為網站控制圖示，不能再以是否出現綠色鎖頭判斷整個網站安全。

本文說明 HTTPS 的作用、與搜尋及使用體驗的關係，以及憑證、轉址和混合內容的檢查方式。這些檢查能找出常見連線問題，不能取代完整的網站安全評估。

啟用 HTTPS 的主要理由是傳輸安全與現代瀏覽器功能支援。不能把未使用 HTTPS 換算成固定排名扣分，也不能宣稱其他 SEO 工作會因此全部歸零。

HTTPS 是什麼？用「明信片與密封信封」一次看懂

HTTP 本身不加密請求與回應，能觀察或控制傳輸路徑的第三方可能讀取或竄改資料。HTTPS 使用 TLS 保護傳輸；仍需留意端點、代理伺服器與應用程式本身的安全。

HTTPS 可比作加密傳遞的訊息：TLS 在連線兩端之間提供機密性與完整性保護，並透過憑證驗證服務名稱。這不代表收件網站本身值得信任，也不涵蓋資料到達伺服器後的儲存與處理。

「SSL 憑證」是沿用的市場名稱，現代 HTTPS 使用的是 TLS。RFC 7568 在 2015 年禁止使用 SSL 3.0；不能因此說 SSL 與 TLS 是同一協定。選購與設定時應確認目前支援的 TLS 版本、憑證與自動續約方式。更多說明見 SSL 憑證完整解析。

網站透過 HTTPS 提供頁面，表示這次連線使用 TLS 保護傳輸。應查看瀏覽器提供的連線資訊與憑證狀態，不能把網址列圖示當成內容、商家或交易的可信保證。

TLS 保護哪些環節：加密、身分驗證與完整性

TLS 的核心保護包括機密性、服務身分驗證與完整性。以下表格以正常驗證的連線為前提；裝置或伺服器遭入侵，仍可能使資料外洩。

加密降低傳輸路徑上的竊聽風險。即使使用公共網路，也不應忽略網址是否正確、憑證警告與裝置安全；HTTPS 不是免除其他防護的理由。

公開網站通常使用受信任 CA 簽發的憑證，讓瀏覽器驗證連線的服務名稱與憑證鏈。DV 主要確認網域控制權，OV 與 EV 另有組織驗證要求，但都不能證明網站內容或交易安全。還沒申請網域可先看〈網域申請全攻略〉；上線後仍需檢查名稱、期限、信任鏈及瀏覽器回報，不能只看鎖頭圖示。

TLS 會驗證受保護資料的完整性，偵測到不合法的竄改時拒絕接受。這可防止傳輸路徑上的內容被悄悄改動，但如果原始伺服器本來就提供惡意檔案，HTTPS 不會把它變安全。

這三項機制主要保障連線傳輸，不等於完整的網站安全。帳號權限、資料儲存、程式漏洞與內容可信度仍要另外處理。

為什麼「不安全」比你想的更傷：三個被錯過的成本

HTTP 可能造成瀏覽器警告、參照來源資訊減少，或無法使用要求安全環境的 API。實際影響取決於瀏覽器、功能和分析設定，不能保證每個網站都會出現相同的流量或轉換損失。

第一個成本：瀏覽器直接在你的網址列貼標籤

Chrome 68 在 2018 年開始將所有 HTTP 頁面標記為不安全；2023 年又調整 HTTPS 的網址列圖示，以避免使用者把安全連線誤認為可信網站。提示樣式依瀏覽器及平台而異，HTTP 提示也不等同憑證錯誤的阻擋畫面。

換個方式想：你在實體店面門口掛一個「這間店可能不安全」的紅牌，再怎麼促銷，都可能流失在門口猶豫的客人。對陌生訪客來說，瀏覽器警告比標題、商品圖與價格更顯眼。若表單轉換突然下滑，應把 HTTP 警告、混合內容與憑證錯誤列入檢查，而不是只改文案或按鈕。

第二個成本：你的流量來源資料會憑空消失

常見的預設 strict-origin-when-cross-origin 參照來源政策，會在 HTTPS 降級到 HTTP 時省略 Referer。其他政策可能有不同行為；UTM、自動標記與分析平台的歸因也會影響來源，因此不能說所有 HTTPS 導入流量都必定變成 direct。

比較廣告、社群與 反向連結 的成效時，應同時確認 HTTPS、行銷參數、轉址是否保留必要參數，以及分析標記。Referer 減少是一個可能原因，不等於整份來源報表必然失真。

如果 GA4 出現來源異常，先用實際導覽流程檢查網址、標記與歸因設定，再判斷是否與 HTTPS 降級或轉址有關。單看 direct 增加無法確定原因。

第三個成本：現代網頁功能會被悄悄關掉

攝影機、麥克風、地理位置、Service Worker 等功能通常要求 secure context，HTTPS 是公開網站常見的達成方式；localhost 等可信本機環境可能例外。各 API 還有權限、瀏覽器與裝置限制，不能只開 HTTPS 就保證可用。

不符合 secure context 時，API 可能不存在、拒絕請求或回報錯誤。開發者應查看 Console、功能偵測結果與 API 文件，不能把所有失敗都描述為沒有任何錯誤訊息。

有收集個人資料的網站，應將傳輸加密納入整體安全設計，同時檢查權限、儲存、更新與事件處理。HTTPS 本身不是完整的安全稽核，也不能當成已符合所有法律或免責條件的證明。

Google 與瀏覽器推動 HTTPS 的歷史脈絡

以下是與 HTTPS 普及有關的歷史節點。舊公告中的查詢比例或介面說明只適用於當時，不應直接當成今日的固定排名公式。

歷史公告說明 Google 曾把 HTTPS 納入搜尋訊號；現行網頁體驗文件則強調整體使用體驗，並表示 Core Web Vitals 以外的體驗面向不直接提高排名。實務上應把 HTTPS 當作安全連線基礎，不估算固定 SEO 加分。

HTTPS 跟 SEO 排名的真實關係：被高估，也被低估

HTTPS 不保證排名上升。先區分歷史排名公告與今天的使用需求：安全連線仍重要，但公開資料不足以替特定網站計算 HTTPS 帶來的排名幅度。

Google 在 2014 年的 HTTPS as a ranking signal 公告，將它描述為非常輕量，當時影響不到全球 1% 查詢。這不是今日的固定比例，也不能推導成只有其他因素完全相等時才會生效。

「平手打破器」可以用來提醒讀者別高估技術設定，但不能當成 Google 公開的精確排序規則。啟用 HTTPS 後仍應檢查內容、可索引性與實際體驗，而不是預期勝過某個 HTTP 對手。

2020 年的公告預告網頁體驗更新，之後在 2021 年逐步推出。現行文件表示沒有單一的 Page Experience 訊號，Core Web Vitals 會被排名系統使用，其他體驗面向不直接提高排名；HTTPS 仍是提供安全連線的基本做法。

升級 HTTPS 的效益應從連線保護、功能相容與使用體驗評估。沒有排名跳升不表示 HTTPS 沒用，也不代表未升級時所有 SEO 努力都被抵銷。

從 HTTP 換到 HTTPS：五個會讓流量掉下來的陷阱

HTTP 改為 HTTPS 涉及 URL 變更，可能需要重新爬取與索引。下列常見設定問題應檢查，但無法承諾固定恢復時間；完整流程見 HTTP 換 HTTPS 完整攻略。

陷阱一：混合內容（Mixed Content）

主頁改用 HTTPS 後，若圖片、CSS、JavaScript、字型或追蹤程式仍請求一般 http:// 子資源，就要檢查混合內容。瀏覽器可能升級部分請求，也可能封鎖資源，造成破圖或功能失效。用瀏覽器開發者工具（F12）的 Console 與 Network 核對實際請求，將子資源改成確認可用的 https:// 網址；一般外部導覽連結與載入子資源是不同情況，不宜盲目全站替換。

陷阱二：永久轉址不完整或形成長鏈

永久遷移時，將舊 HTTP 網址以伺服器端 301 或 308 永久轉址導向對應的最終 HTTPS 頁面，見 Google 的〈永久轉址說明〉。若兩個版本都能直接存取，應處理重複內容與標準網址訊號；若經過 HTTP→HTTPS→www→非 www 多次跳轉，則應縮短轉址鏈。額外跳轉需要更多請求，可能影響載入與爬取預算，但不能換算成每層固定的流量或排名損失。

陷阱三：Canonical 標籤還指向 HTTP

遷移後若 Canonical 標籤 仍指向 HTTP，就可能與 HTTPS 轉址和其他偏好訊號矛盾。Google 會綜合訊號選擇標準網址，不是把兩個版本分配固定權重。可用 Screaming Frog 檢查 canonical，再以 Search Console 抽查 Google 的選擇；不要假設工具沒有報錯就一定一致。

陷阱四：HSTS 範圍與部署不符

HSTS 透過 HTTPS 回應標頭，要求瀏覽器在指定的 max-age 期間只使用 HTTPS；不是永遠有效，也不是排名必需項目。一般 HSTS 在瀏覽器第一次成功收到標頭前沒有保護，preload 可補這個缺口，但加入前須確認相關主機與子網域長期支援 HTTPS。先測試短效期，再審慎評估 includeSubDomains 和 preload。

陷阱五：憑證到期沒有人記得

憑證有期限，不能用「付費一年、免費 90 天」概括。依 CA/Browser Forum 規則，自 2026 年 3 月 15 日起新簽的公開信任 TLS 憑證最長 200 天，供應商可更短。應確認實際效期、設定自動續約與失敗通知，並監控正式網站是否已載入新憑證。選擇與安裝見 SSL 憑證完整教學。

SSL 憑證不是只有一種：DV、OV、EV 怎麼挑？

這一節我給你一個快速判斷的框架，不講申請流程（那一樣在憑證專文裡）。市面上常見的 SSL 憑證分成三個驗證等級，差別不在「加密強度」（TLS 的加密強度跟憑證等級無關），而在「憑證機構查了你多少東西」。

這裡有一個很多人不知道的歷史。EV 憑證在 2018 年以前，會在瀏覽器網址列直接顯示公司全名（那條綠色的公司名），是它最大的賣點。但從 2018 到 2019 年間，Chrome 與 Firefox 相繼移除了這條綠色公司名顯示，因為多數使用者根本不會注意它，而且它造成「有綠色名字等於絕對安全」的錯誤印象。所以現在花大錢買 EV，看得到差異的只剩憑證詳細資料頁面，對一般讀者來說跟 DV 的視覺差別已經很小。我的建議是：除非你的產業有合規需求、或你的客戶會主動點開憑證看公司名字（極少數 B2B 場景），否則 DV 已經完全夠用。

*.example.com 萬用憑證涵蓋單層子網域，例如 www.example.com，不自動涵蓋 example.com 或 www.blog.example.com。SAN 憑證可列出多個名稱；要同時支援裸網域和萬用名稱，需確認兩者都列在憑證內。Let's Encrypt 支援多名稱與萬用憑證，萬用名稱使用 DNS 驗證。

免費 Let's Encrypt 出現後，付費憑證還值得嗎？

Let's Encrypt 提供免費、自動化的 DV 憑證。截至本次查核，classic profile 預設為 90 天；選用 tlsserver profile 則自 2026 年 5 月 13 日起為 45 天，另有短效期 profile。官方規劃 classic 在 2027 年縮至 64 天、2028 年縮至 45 天；應以實際憑證和官方公告確認，不把效期永久寫死。

若只需要網域驗證，Let's Encrypt 是可評估的免費方案；是否適合仍取決於自動化、平台支援與組織要求。主機商和 CDN 可能使用不同 CA 或提供不同範圍的憑證管理，不能說所有平台都已整合 Let's Encrypt 且一鍵完成。

那付費憑證什麼時候才有意義？我整理出四種你會真的需要它的場景：

• 你需要萬用憑證（Wildcard）：免費 Let's Encrypt 也支援萬用憑證，但設定門檻較高；如果你有很多子網域、又沒有技術人力，付費萬用憑證的便利性還是有價值。
• 你需要 OV 或 EV 等級：Let's Encrypt 只發 DV，所以合規要求 OV/EV 的產業，只能找付費 CA。
• 你需要特定保固條款：先閱讀供應商合約中的適用對象、承保事件、上限與排除事項，不把憑證保固當成網站被駭或交易損失的一般保險。
• 你需要維運支援：比較是否提供安裝、續約排障與回應承諾。付費不代表自動附帶 SLA，仍需確認服務契約。

TLS 安全性取決於協定、密碼套件、金鑰與實作，不由憑證價格決定。付費產品可能增加組織驗證或支援服務，應依實際需求比較，不能把「付費」等同「加密更強」。

HTTPS 的初步檢查流程

這一節是一套快速檢查流程，能先排除常見的 HTTPS 與憑證問題，也讓你對網站基本設定有初步判斷。它就像汽車進廠保養前的第一輪巡檢；若這一層已出現異常，再進一步檢查伺服器、憑證鏈與轉址設定。

1. 查看 TLS 測試報告：可用 SSL Labs SSL Server Test 檢查協定、憑證與組態。依報告找原因，而非只看字母等級；測試通過也不代表應用程式整體安全。
2. 檢查憑證效期與續約狀態：依 CA、profile 與自動化工具的建議提前續約，監控續約失敗及正式站載入的新憑證；短效期憑證不能套用固定 30 天提醒。
3. 掃混合內容：在要檢查的頁面按 F12 打開 Console，重新整理，看有沒有黃色的 mixed-content 警告；同時開 Network 面板，看有沒有 http:// 的請求。
4. 測試 HTTP 到 HTTPS 的回應：用 Network 面板或 HTTP 工具確認伺服器回傳 301／308 並到達對應 HTTPS 頁。瀏覽器也可能先因 HSTS 或 HTTPS-First 升級，單看網址列不足以證明伺服器轉址正確。
5. 檢查 HSTS 設定：在 HTTPS 回應查看 Strict-Transport-Security，確認效期與子網域範圍符合部署；不要未測試就把 max-age 拉長。

這些動作能初步檢查傳輸與憑證設定，不能證明網站沒有漏洞。維護時仍應搭配 Google Search Console、年度內容與技術健檢，檢查已知安全事件、程式更新與必要的權限。

HTTPS 之外：Google 眼中的「安全網站」還包含什麼？

上述檢查只能找出部分常見問題。HTTPS 不等於網站安全，測試通過後仍需持續監控憑證、伺服器與程式設定，並另外處理惡意內容、權限和資料保護。

Google 的安全問題報表可顯示遭入侵內容、惡意程式或社交工程等問題，搜尋或瀏覽器可能對受影響網址顯示警告。HTTPS 不會防止伺服器本身被入侵；使用 WordPress 等系統時，仍需更新、存取控制、備份及適當監控。

網頁速度、Core Web Vitals、行動版呈現與干擾閱讀的插頁都值得檢查。Google 說明 CWV 會被排名系統使用，但沒有公開固定權重，良好分數也不保證排名；其餘體驗面向仍應為使用者改善。

E-E-A-T 著重內容是否有可信依據；HTTPS 保護傳輸，並不證明內容正確。健康、財務等可能造成重大傷害的主題，還要重視適當專業與可靠來源。這些工作都需要持續維護，不能用一份簡短檢查表宣布全部完成。

三個最常見的 HTTPS 迷思，一次破解

討論 HTTPS 時，常會反覆聽到同一批誤解。這些誤解最危險的地方，不在於它們講錯了某個技術細節，而在於它們會讓你做出錯誤的投資決策，該花的錢不花、不該花的錢卻砸下去。底下這張表是我整理出來、出現頻率最高的三個迷思，配上實際的情況，讓你一次對照清楚。

沒有金流的內容站仍應使用 HTTPS，保護傳輸並支援現代功能。瀏覽器警告、參照來源政策與 API 限制都值得檢查，但不代表每個網站會遭受相同損失。

五個動作，今天就檢查你的網站安全體質

HTTPS 的主要價值是保護連線。完成初步設定後，還要監控自動續約、資源 URL、伺服器回應與瀏覽器相容性，不能視為一次安裝就永久完成。

以下清單可用來安排初步檢查；實際工時取決於網站規模與問題，不能在固定時間內保證完成完整安全盤點。

1. 檢查 TLS 報告：查看憑證、協定與密碼套件的具體結果，依問題安排修正，不把 A 等級當成整個網站安全證明。
2. 檢查 HTTP 回應：測試伺服器是否將各舊 URL 以 301／308 導到對應 HTTPS 頁，同時避免把瀏覽器的 HSTS 升級誤當成伺服器轉址。
3. 檢查混合內容：抽查重要頁面的 Console 與 Network，將 HTTP 子資源改為確認可用的 HTTPS URL；不要盲目替換外部連結，或再使用省略協定的寫法。
4. 監控自動續約：依實際憑證效期與 ACME 工具建議設定通知，確認續約成功且正式站已載入新憑證；短效期方案要採更短的監測週期。
5. 把「網站安全」排進每月的例行維護：跟 內部連結、robots.txt、XML Sitemap 一起，當成網站體質的基本檢查項，定期看，別等出事才補救。

自動續約可以降低維護負擔，但仍可能因 DNS、驗證權限、排程、部署或帳號變更而失敗。持續監控正式站憑證和續約結果，比只在安裝當天測試更可靠。

還在使用 HTTP 時，先規劃憑證、轉址與資源更新；已使用 HTTPS 則確認續約與回應正常。這些工作與 站內 SEO、認真寫的內容 相互配合，但安全連線不能代替內容品質或其他安全防護。