HTTP 傳資料的方式，很像寄一張明信片：內容全寫在外面，從寄出到送達，每個經手的人都讀得到，要偷偷改幾個字也不難。HTTPS 則是把同一張明信片放進封好的信封，再蓋上一枚只有收件人才核對得出真偽的封緘章。差別就這麼具體，在網址列上看起來卻只多了一個字母 S。
這個差別早就不只是技術圈的事。Chrome 自 2018 年起把 HTTP 網頁標成「不安全」，2026 年 9 月 22 日進入穩定版的 Chrome 154 更進一步，預設在使用者第一次連上不支援 HTTPS 的公開網站前，先跳出警告。官網如果還停在 http://，訪客遇到的就是一道要手動放行的關卡，而經營者往往到那時才發現，網站其實沒換好。
買一張憑證、裝上去，常被當成已經換好了，其實憑證只是第一步。轉址、站內網址、搜尋引擎端的設定只要漏掉一環，網站照樣會出現警告、掉圖，甚至陷入轉址迴圈。
HTTPS 是什麼？
HTTPS 是在 HTTP 外面多包一層 TLS 加密的版本。HTTP 的全名是 HyperText Transfer Protocol，也就是瀏覽器向網站要網頁時使用的通訊協定；protocol 的中文就是「通訊協定」，指雙方事先講好的溝通規則。HTTPS 的 S 代表 Secure，網址開頭也從 http:// 換成 https://。
根據 MDN 的說明，TLS（Transport Layer Security，傳輸層安全性協定）讓用戶端（例如瀏覽器）能在不受信任的網路上，與伺服器安全地通訊，套用在 HTTP 上的結果就叫 HTTPS。所以換成 HTTPS，網站還是同一套，只是 HTTP 外面多了一層保護：網頁內容、網址結構、後台的運作方式都不變，改變的只有瀏覽器與伺服器之間那段路，從任何人攔到都看得懂的明文傳輸，改成加密傳輸。
至於 SSL 與 TLS 的關係，簡單來說，TLS 是 SSL 的後繼協定，現行版本是 TLS 1.3（RFC 8446），TLS 1.0 與 1.1 已不應再使用。不過市面上仍習慣把憑證叫作「SSL 憑證」，這個名稱指的就是 HTTPS 所用的憑證。
HTTPS 比 HTTP 多了加密、身分驗證與完整性檢查
MDN 指出，TLS 以三種方式保護連線：加密、身分驗證與完整性。每一項都對應中小企業網站會遇到的實際情境，例如聯絡表單、後台登入、公用 Wi-Fi，以及頁面在途中被插入內容。
HTTPS 防禦的對象，是所謂的中間人（Man-in-the-Middle，簡稱 MITM）：攻擊者把自己插在瀏覽器與伺服器之間，可以讀取，也可以修改雙方交換的流量。這也說明了 HTTP 的問題不在於資料夠不夠敏感，而是任何一個頁面，在傳輸途中都可能被讀取或改寫。
加密擋下的是傳輸途中的竊聽
HTTP 以明文傳輸，途中經過的任何一台設備，例如咖啡廳公用 Wi-Fi 的熱點，都有機會讀到內容。加密之後，依 MDN 的說明，攻擊者讀不到傳輸中的資料，途中攔到的只是一串看不懂的亂碼。
最容易被忽略的暴露點，是表單、登入與後台頁。訪客在聯絡表單填的姓名、電話與需求，你自己登入後台時輸入的帳號密碼，在 HTTP 下全都是明文送出。後台網址沒有人會去逛，不代表傳輸途中沒有人看得到。
身分驗證靠憑證確認網域本人
光是加密還不夠，因為加密連線的另一端，也可能是冒名頂替的假網站。憑證就是用來確認身分的。MDN 說明，憑證內含簽章過的公開金鑰（網站對外公開、用來建立加密連線的那把鑰匙），把網站的金鑰與網域名稱綁在一起，瀏覽器才知道自己連到的真的是 https://example.com，而不是中途冒充的人。
憑證如果對不上，例如已經過期，或沒有涵蓋訪客輸入的網域，瀏覽器就會在載入網頁前先擋下整頁。憑證分成 DV（網域驗證）、OV（組織驗證）、EV（延伸驗證）等不同等級，各自查核的範圍不同；不論哪一級，在 HTTPS 裡的基本作用都是證明這個網域確實是它所宣稱的那一個。
完整性檢查讓傳輸內容無法被悄悄改寫
除了「看不到」，還有「改不了」。MDN 把這一項稱為完整性：攻擊者無法在不被察覺的情況下，修改傳輸中的資料。在 HTTP 下，途中的設備可以在頁面裡塞進廣告、替換下載連結，或改掉一段腳本，訪客看到的就不是網站原本送出的版本。web.dev 在談混合內容時也提醒，攻擊者攔截資源之後，可以替換圖片、竄改頁面，主動式內容（例如腳本）甚至能讓攻擊者幾乎完全控制整個頁面。
完整性與加密是兩件事：加密擋的是讀取，完整性擋的是改寫。這也是為什麼連沒有任何輸入欄位的純展示型官網，都值得用 HTTPS。頁面上沒有需要保護的資料，內容卻仍可能被塞進不是你寫的廣告或連結，而訪客只會覺得，是你的網站出了問題。
瀏覽器對 HTTP 頁面的警告越來越直接
從訪客的角度看，HTTP 與 HTTPS 最直接的差別，在於瀏覽器怎麼標示、怎麼處理。這幾年的方向相當一致，從輕輕提醒，走到進入網站前先擋一道。
Chrome 從標示不安全開始，到 154 版起進站前先跳警告
Chromium 部落格在 2018 年 2 月說明，自 2018 年 7 月的 Chrome 68 起，網址列會對所有 HTTP 網頁顯示「Not secure」（不安全）。這是第一個階段：HTTP 網頁從此在畫面上多了一個一眼就看得到的標籤。
下一個階段是「一律使用安全連線」（Always Use Secure Connections）。依 Google 在 2025 年 10 月的公告，這項設定先在 Chrome 147（2026 年 4 月）對已開啟加強型安全瀏覽的使用者啟用，再自 Chrome 154 起改成所有使用者預設開啟。這個版本已在 2026 年 9 月 22 日進入穩定版，Chrome for Developers 的版本說明也把「預設在使用者連上不安全的 HTTP 連線時先詢問」列為更新項目。
運作方式是 Chrome 先嘗試以 HTTPS 連線，連不上時，才在第一次進入該公開網站前跳出警告（經常造訪的網站不會一再警告），說明這個網站不支援安全連線，攻擊者可能檢視或更改傳送與接收的資訊。使用者可以選擇「Continue to site」繼續，或選擇「Return」返回。
這項設定只針對公開網站，內網、區網 IP（例如 192.168.0.1）、單一標籤主機名稱（名稱裡沒有點號的主機）與 intranet/ 這類捷徑，都不在範圍內。Google 同時公布，公開網站的導覽已有絕大多數是 HTTPS：Windows 約 98%，Android 與 Mac 超過 99%，Linux 近 97%；中位數的使用者每週遇到的警告不到 1 次，第 95 百分位的使用者每週也少於 3 次。多數網站早已換好，沒換的網站反而顯眼，訪客會在進站前多看到一道要手動放行的關卡。至於有多少人會因此離開，Google 沒有公布數據。
鎖頭只證明連線加密而不保證網站可信
很多人把網址列的鎖頭，當成「這個網站可信」的保證，其實它只表示連線是加密的、網域對得上。Let’s Encrypt 在〈The CA’s Role in Fighting Phishing and Malware〉一文中說明，DV 憑證斷言的只有「某把公開金鑰屬於某個網域」，沒有提供任何關於網站內容、經營者身分或安全性的資訊；攻擊者只要換一家憑證機構申請，幾乎總能拿到憑證，而且持有的時間足以拿來傷害使用者。換句話說，釣魚站同樣可以擁有 HTTPS。
Chromium 部落格在 2023 年 5 月公布了同一個觀察：2021 年的研究顯示，只有 11% 的受試者正確理解鎖頭圖示的精確意義，而且幾乎所有釣魚網站都使用 HTTPS，也都顯示鎖頭。Chrome 因此自 2023 年 9 月發佈的 Chrome 117 起，把網址列的鎖頭換成中性的設定圖示，目的是強調安全應該是預設狀態，而不是靠一個圖示替網站背書。
這等於替 HTTPS 劃出一條邊界，它是必要條件，卻不是萬靈丹。加密連線保護的是訪客與網站之間那段路；網站內容誠不誠實、帳號設定有沒有漏洞、外掛有沒有更新，都不在它的保護範圍，所以「有 HTTPS」不能當成網站安全的全部。
HTTPS 對 SEO 的影響比坊間說法保守
換成 HTTPS 常被當成一個 SEO 動作，不過 Google 公開說過的內容，其實比坊間的說法保守許多。這件事該做，但不要期待排名因此大幅提升。
安全連線在 Google 排名中只算輕量訊號
2014 年 8 月，Google 搜尋中心部落格宣布開始把 HTTPS 納入排名訊號，同時說明這只是一個非常輕量的訊號：影響全球不到 1% 的查詢，權重也不及高品質內容等其他訊號，並表示日後可能強化。
Google 目前的〈瞭解 Google 搜尋結果中的網頁體驗〉文件，把「網頁是否以安全的途徑提供」列為自我評估的問題之一，也提供 Search Console 的 HTTPS 報表，用來找出沒有以 HTTPS 提供的頁面與原因。不過同一份文件的常見問題也說明，除了 Core Web Vitals 之外，其他網頁體驗層面不會直接幫助網站在搜尋結果中提高排名；這些層面通常讓網站更符合使用者的需求，而這大致與 Google 排名系統考量的因素相同。
較準確的說法是，換成 HTTPS 的理由是保護訪客、維持信任，SEO 是附帶的好處，而不是主因。
Google 挑選標準網址時預設偏好 HTTPS 版本
HTTPS 對搜尋最確定、也最具體的影響，出現在標準網址的挑選。標準網址（canonical URL）是同一份內容有好幾個網址時，Google 選來代表、顯示在搜尋結果裡的那一個。HTTP 與 HTTPS 兩個版本同時存在時，Google 預設選 HTTPS 當標準網址，但說明文件也列出四種例外情況，可能讓 Google 改選 HTTP：
- HTTPS 頁面的憑證無效。
- HTTPS 頁面含有不安全的相依資源（圖片除外）。
- HTTPS 頁面會把使用者重新導向到 HTTP 頁面，或經過 HTTP 頁面再轉走。
- HTTPS 頁面的 rel=”canonical” 指向 HTTP 頁面。
文件特別提醒，憑證有問題與把 HTTPS 導回 HTTP，會讓 Google 非常強烈地偏好 HTTP，而且啟用 HSTS（要求瀏覽器只走加密連線的設定，後面換站步驟的最後一步會說明）也蓋不掉這個偏好。另外，憑證必須與完整的網站網址相符，或是萬用憑證（一張涵蓋同一層所有子網域的憑證，例如 *.example.com）；example.com 這個網址送出的卻是 subdomain.example.com 的憑證，就是文件舉的錯誤例子。sitemap（網站地圖）與 hreflang（多語系版本標記）也不該列 HTTP 版本的網址。
把這四種情況反過來看，就是四件要做到的設定：憑證保持有效、頁面沒有混合內容（安全頁面裡夾帶 http 資源）、不要把 https 導回 http、canonical 指向 https 版本自己。它們剛好也是切換時最容易出狀況的四個地方。
全站換成 HTTPS 的六個步驟
Google 把網址從 HTTP 改成 HTTPS，視為網站遷移的一種，所以要照遷移的方式來做。小型與中型網站，Google 建議一次完成所有網址的遷移，不必分批；遷移期間排名可能短暫波動，中型網站的新網址通常要數週或更久，才會逐漸取代舊網址出現在搜尋結果裡；至於轉址，Google 明確說明，301（永久轉址）與其他永久重新導向不會導致 PageRank（Google 用來評估連結價值的指標）下滑。
這六個步驟的順序不能隨意調換。憑證沒裝好就先轉址，訪客會被導到一個打不開的網址；太早啟用 HSTS，一旦設定出錯，連略過警告的選項都沒有。每一步放在它的位置，都有原因。
取得並安裝涵蓋 www 與裸網域的憑證
Let’s Encrypt 的說明指出，對許多人來說，主機商會代為取得並管理憑證，可能自動完成，也可能在設定頁勾選開啟，所以第一步是先問主機商有沒有代管。主機商不處理、而且能在伺服器上執行指令時，才需要自己選一個 ACME 客戶端（自動申請與續簽憑證的程式）去申請，Let’s Encrypt 對多數人推薦的是 Certbot。
免費不代表次級。Let’s Encrypt 是非營利的憑證機構，不收費，只簽發 DV 憑證，不提供 OV 與 EV；一般官網用 DV 憑證就能滿足 HTTPS 的加密與網域驗證。預設效期目前是 90 天，2027 年 2 月 10 日起還會再縮短，所以續簽一定要靠自動化，不能靠人記得。
憑證涵蓋的主機名稱，則要與訪客實際會輸入的網址一致。裸網域（example.com）與 www.example.com 兩個版本都要在涵蓋範圍內，否則其中一個版本會直接跳出警告。前面提過，Google 的標準網址文件也要求憑證與完整網站網址相符，或使用萬用憑證。
站內寫死的 http 資源全改掉，混合內容才會消失
憑證裝好之後，頁面主體雖然走 HTTPS，但文章裡寫死的 http 圖片、腳本與字型網址，仍然會造成混合內容：HTML 以 HTTPS 載入，其他資源卻走 HTTP。web.dev 把混合內容分成兩類，被動式（圖片、影片、音訊）風險較低，主動式（腳本、樣式表、iframe 等）則可能讓攻擊者幾乎完全控制頁面。大多數瀏覽器現在會封鎖混合內容，Chrome 在某些情況下也會把被動內容自動升級成 HTTPS，沒有安全版本時就不載入。
這會直接影響訪客的使用體驗：被封鎖的主動內容，可能讓按鈕沒反應、選單失靈，或表單送不出去。要找出殘留的網址，可以打開 Chrome 開發人員工具，web.dev 說明偵測到的混合內容會記錄在「問題」分頁，主控台也會列出對應的網址。
處理的原則很單純。同網域的資源，優先改用相對網址或 https 網址；外部資源改成 https 版本，沒有安全版本就換掉或移除。如果一時改不了程式碼，MDN 提供了備援做法：在伺服器設定含 upgrade-insecure-requests 指示詞的 Content-Security-Policy，讓瀏覽器自動把這些請求升級成 HTTPS。WordPress 資料庫裡殘留的舊網址，則需要另外清理。
用單次 301 把 http 網址直接導向最終網址
全站轉址是這次切換的主軸，做法是用伺服器端的永久重新導向，把每個 http 網址對到同一路徑的 https 網址。Google 的網站遷移文件建議使用 301 或 308 這兩種伺服器端永久重新導向；MDN 說明兩者的差別在於 308 會保留請求方法與內文（例如表單送出的資料），一般網頁導覽用 301 就夠。MDN 的 TLS 說明也提到，只用 HTTPS 的網站同樣要接收 HTTP 的連線，再用 301 導向 HTTPS 版本。
轉址要一次跳到最終網址，不要形成 http → https → www 這種連鎖轉址。Google 的爬蟲 Googlebot 在轉址鏈中最多追蹤 10 個躍點，但 Google 建議越短越好，最好不超過 3 次、至少少於 5 次；每多轉一次，訪客也多等一次。所以 http 與 https、www 與非 www 要合併成同一跳，例如 http://example.com/page 直接到 https://www.example.com/page。
內部連結則直接改成 https。MDN 提醒，每次轉址都多一次 HTTP 請求的效能成本，改得了的連結就別靠轉址補。至於轉址寫在哪裡，主機後台的「強制 HTTPS」開關、伺服器設定檔與 WordPress 的轉址設定都是常見做法，原則是同一時間只留一處負責，避免互相抵銷。也別把 HTTPS 頁面轉回 HTTP，前面提過，那會讓 Google 改選 HTTP 當標準網址。
設定完成後，可以用瀏覽器開發人員工具的 Network 分頁，查看狀態碼與 Location，或在終端機用 curl 查看標頭：
curl -I http://example.com/Code language: Bash (bash)回應的狀態碼應是 301 或 308，Location 標頭則指向最終的 https 網址。
同步更新 canonical、sitemap 與內部連結
轉址只是告訴搜尋引擎「這個網站搬家了」，新網址還得自己「報到」。Google 的網站遷移文件要求，每個新網址都要有自我參照的 rel=”canonical”，使用 hreflang 的網站要把註解更新成新網址，內部連結改指向新網址，並備好含新網址的 Sitemap。canonical 要用帶有通訊協定與網域的完整網址（絕對路徑）而不是相對路徑，指向 https 版本自己。
WordPress 網站的這幾件事，多半由佈景主題與 SEO 外掛隨網站網址設定連動，但仍要抽查。檢視網頁原始碼，確認 <link rel="canonical"> 的網址開頭是 https；打開 sitemap.xml，確認裡面列的網址沒有任何一筆還是 http。同一個網頁，也不要在 sitemap 與 canonical 指定兩個不同的網址，否則等於對 Google 說了兩種答案。
用 Search Console 驗證新舊版本並追蹤收錄狀況
換完之後，要確認 Google 看得到，也處理好了。Search Console 的屬性類型會決定看得到多少資料：根據 Google 的說明，網域資源包含所有子網域與多種通訊協定（http、https），網址前置字元資源則只包含符合該前置字元的網址，連通訊協定與子網域都要一致。如果只有網址前置字元資源，就要把 http、https、www、非 www 各驗證一次，才看得到完整資料。
換網址之後，驗證狀態也要重新確認。Google 的遷移文件提醒，HTML 檔案驗證要把檔案帶到新站，meta 標記驗證則要確認新環境也有帶過去。平常可以看 HTTPS 報表，找出沒有以 HTTPS 提供的頁面與原因，再看索引狀態與 Sitemap 報表裡的數字，是否逐步移向 https 網址。
這段期間要有耐心。前面提過，Google 需要數週或更久，才會逐漸顯示新網址，所以頭幾天數字沒什麼變化、搜尋結果裡仍看得到舊網址，都屬正常，不必急著回頭改設定。
HSTS 留到轉址穩定後再啟用，期限分階段拉長
HSTS（HTTP Strict Transport Security）是整個切換最後的加固。MDN 說明，它是伺服器回應時附上的一個 Strict-Transport-Security 標頭，通知瀏覽器這個主機只能用 HTTPS 存取；之後就算訪客輸入 http 網址，瀏覽器也會直接升級，不必再走一次 301。這個標頭只能透過 HTTPS 回應傳送，經由 HTTP 傳來的會被瀏覽器忽略，以免被中間人竄改。
HSTS 放在最後，是因為它一旦生效，瀏覽器會在 max-age（瀏覽器要記住這條規則多久，單位是秒）的期限內持續遵守，遇到憑證無效等 TLS 錯誤時，也不提供略過的選項。所以 hstspreload.org 的建議是，先確認所有子網域（包含不對外公開的內部子網域）都能用 HTTPS，再分階段拉長 max-age：從 5 分鐘（max-age=300）開始，再到 1 週（max-age=604800），最後是 1 個月（max-age=2592000），並且都加上 includeSubDomains。每個階段都檢查有沒有壞掉的頁面、流量有沒有異常，等滿該階段的時間才往下走，最後一階段就是等滿一個月。
Strict-Transport-Security: max-age=300; includeSubDomainsCode language: plaintext (plaintext)HSTS 另有一個預載（preload）機制，把網域直接列進瀏覽器內建的清單。要列入預載清單，max-age 必須至少 31536000（1 年），而且要含 includeSubDomains 與 preload；但 hstspreload.org 直接說明，預載的好處相較 HSTS 本身很小，因為 Chrome 與 Safari 等瀏覽器，多半本來就會自動把 HTTP 導覽升級成 HTTPS，所以它建議使用 HSTS，不建議預載。
WordPress 內建的 HTTPS 一鍵切換不等於轉址完成
WordPress 5.7 起內建 HTTPS 的偵測與一鍵切換。根據 WordPress 核心開發筆記，站台健康狀態（Site Health）會偵測環境是否支援 HTTPS。偵測靠每日兩次的排程，用開啟憑證驗證（sslverify）的請求測試網站的加密版本，環境支援時，HTTPS 狀態區塊就會出現切換按鈕。5.7 當時的開發筆記把「未使用 HTTPS」列為重大（critical）問題，現行版本的站台健康狀態則把它歸在建議改進項目。
不過這顆按鈕不等於「全站轉址與內容清理都做完」。它改了什麼、沒改什麼，要先弄清楚，切換之後才知道該驗證哪裡。
一鍵切換只改兩個網址欄位而不重寫資料庫
按鈕做的事，是把後台「設定→一般」裡的「WordPress 位址」與「網站位址」兩個欄位，改成 https，並由 WordPress 在輸出頁面時，即時把站內的 http 網址換成 https。依核心開發筆記的說明，這些舊網址只在輸出時替換，資料庫裡的內容並沒有被改寫；管理員若想真正替換資料庫裡的網址，仍要另外處理。
按鈕的使用條件也有限：環境要先支援 HTTPS，兩個位址的網域也必須相同。兩個位址設成不同網域的進階設定不在支援範圍；用 WP_HOME 或 WP_SITEURL 常數設定網址的網站，WordPress 無法自動更新。若切換後 WordPress 沒能正確辨識出 HTTPS，設定會自動還原。核心開發筆記說明的範圍，只有這兩個網址設定與輸出時的即時替換；伺服器層的轉址設定、外部嵌入的資源與外掛寫死的 http 網址，都不在其中，所以不要把它當成「按下去就完成」。
切換之後，建議自己實測三件事：
- 用無痕視窗開 http:// 版本，看會不會導向 https 版本。
- 開首頁與主要版型，看瀏覽器主控台有沒有混合內容警告。
- 開 sitemap，看裡面的網址是不是 https 開頭。
網站前面有 CDN 或反向代理時，主機端那段連線也要確認
網站前面有 CDN（內容傳遞網路，把網站內容分散到各地節點加速）或反向代理（擋在主機前面代收請求的伺服器）時，「訪客到 CDN」與「CDN 到主機」是兩段連線，各自可以是 HTTP 或 HTTPS。以 Cloudflare 為例，它把這個設定稱為加密模式，常用的有三種：Flexible 是訪客到 CDN 加密、CDN 到主機不加密；Full 是訪客走 HTTPS 時，CDN 到主機也用 HTTPS，但不驗證主機的憑證；Full (strict) 則會驗證主機的憑證。Cloudflare 的文件也強烈建議，盡可能使用 Full 或 Full (strict)。
典型的風險出現在 Flexible 模式：訪客的網址列看起來沒問題，但主機上其實沒有憑證，CDN 到主機那一段完全沒有加密。另一種連帶問題是，WordPress 收到的是 CDN 轉來的 HTTP 請求，可能因此誤判訪客用的不是 HTTPS，輸出的連結也就變成 http。所以網站前面有 CDN 或代理服務時，除了訪客端看得到鎖頭，還要確認 CDN 到主機那段的設定，以及 WordPress 判斷 HTTPS 的方式是否一致。
換成 HTTPS 後最常見的三種錯誤
換完之後最容易出事的有三種：憑證過期或網域沒涵蓋、混合內容、轉址迴圈。它們共同的特點是，症狀都看得見，只是成因各自對應前面某一個步驟沒有做完整。
憑證一旦過期或沒涵蓋網域，訪客就會看到全頁警告
觸發的情境有兩種：憑證過期了，或是憑證沒有涵蓋實際的網址，例如只簽了裸網域，沒簽 www。這時瀏覽器會在進入網頁前先擋下，顯示全頁警告。網站若已啟用 HSTS，依 MDN 的說明，瀏覽器遇到這類 TLS 錯誤時不提供略過選項，訪客連點擊繼續都做不到。對應回前面，就是安裝憑證那一步的涵蓋範圍沒對齊，而最後一步的 HSTS 又放大了這個後果。
另一個要留意的，是憑證效期還在持續縮短，靠手動續簽只會越來越容易漏。Let’s Encrypt 目前預設發 90 天的憑證。依其 2025 年 12 月 2 日的公告，給想提早採用者選用的 tlsserver profile 已在 2026 年 5 月 13 日改發 45 天憑證；預設的 classic profile 則自 2027 年 2 月 10 日起改發 64 天憑證，2028 年 2 月 16 日再降到 45 天，授權重用期（網域驗證通過後可沿用的時間）也縮短到 7 小時。Let’s Encrypt 說明，這是配合 CA/Browser Forum（憑證機構與瀏覽器業者共同制定憑證規則的組織）的基準要求，與整個產業一起調整。
CA/Browser Forum 的 SC-081v3 投票案在 2025 年 4 月 11 日通過，規定公開信任的 TLS 憑證最長效期，自 2026 年 3 月 15 日起已降為 200 天，2027 年 3 月 15 日起為 100 天，2029 年 3 月 15 日起為 47 天。
所以續簽要自動化，而且要有失敗告警。Let’s Encrypt 建議使用 ACME Renewal Information（ARI，由憑證機構告知建議續簽時間的機制），或在憑證效期約三分之二時續簽，並說明隨著效期縮短，寫死 60 天的續簽間隔不再足夠；它也不建議手動續簽，並建議系統設有監控，在憑證沒有如期續簽時發出告警。
混合內容會引發安全警告並讓腳本與表單失靈
混合內容的症狀有兩類。第一類是頁面看起來正常，但瀏覽器對這個頁面的安全標示出現警告，多半是被動內容造成，例如寫死 http 的圖片。第二類是某個功能整個失靈，主動內容被瀏覽器封鎖，選單、表單與第三方腳本最常出現這種狀況。web.dev 說明大多數瀏覽器會封鎖混合內容，MDN 則補充，瀏覽器會依資源類型決定升級或封鎖。
成因通常是頁面、外掛或佈景主題裡寫死的 http 網址，或是外部資源本身沒有 https 版本。先用瀏覽器主控台與開發人員工具的「問題」分頁，找出殘留的網址；把該網址改成 https 之後，如果打不開，代表那個資源本身不支援 HTTPS，只能換個來源，這也是前面清除混合內容那一步最後要處理的事。
轉址迴圈多半出在 CDN 與主機同時強制轉址
瀏覽器顯示「重新導向次數過多」（ERR_TOO_MANY_REDIRECTS）時，多半是兩個地方各自在轉址，彼此互相抵銷。最典型的組合，是 CDN 設成 Flexible，到主機走 HTTP，主機又把所有 HTTP 請求導向 HTTPS：訪客要求 https，CDN 轉成 http 送給主機，主機又導回 https，如此反覆，永遠停不下來。反過來，CDN 設成 Full 或 Full (strict)，主機卻把 HTTPS 導回 HTTP，也會造成同樣的迴圈。這兩種情境，Cloudflare 的疑難排解文件都有說明。
解法的原則是只留一處負責強制 HTTPS，並讓 CDN 到主機那一段也改走加密連線（Full 以上，主機需裝有憑證）。排查時，先數一數有幾處在轉：CDN 的強制 HTTPS 設定、伺服器設定檔、WordPress 後台的網址欄位、轉址外掛，一次只留一處。MDN 也提醒，HTTP 轉址與 HTML 的 meta 轉址並存時，只改了其中一邊，同樣可能造成無限迴圈。
HTTPS 是現在網站的基本配備，但它保護的是連線，不是網站本身。訪客在網址列看到的安全標示或警告，只是整件事最外面的一層。真正要做的，是讓網站從憑證、轉址、站內網址到搜尋引擎的設定，都停在 https 這一邊，並且在憑證到期前自動續簽。
現在就可以做一件小事：用無痕視窗輸入網站的 http:// 網址，看它是否一次就跳到最終的 https 網址，而且頁面上沒有任何警告，這個結果比任何設定畫面都誠實。