HTTP 換 HTTPS 完整攻略：安全升級並提升 SEO

先把結論說在前面：HTTPS 是現代網站的入場券，但對 SEO 的直接加分很小；真正會咬人的不是「沒裝」，而是 HTTP 換 HTTPS 這件工程一旦做歪，可能在兩週內把你經營多年的排名一把清掉。很多站長是在網址列旁邊看到灰撲撲的「不安全」標記、點進結帳頁又被一整面紅色警告擋下來的那一刻，才開始擔心這東西會不會連 Google 排名一起拖下去。

這個擔心問對了方向，卻問錯了重量。所以這篇不打算賣你「裝了 HTTPS 排名就會飆升」這種夢，而是把帳算給你看，再把遷移過程裡真正會咬人的地方一個一個指出來。

把一句話先講清楚：HTTPS 是現代網站的入場券，不是排名火箭。它給你的 SEO 紅利很小，但它設下的地板很重要，而且遷移過程只要踩中任何一顆地雷，你賠掉的流量會比它帶來的加分高出好幾倍。這篇會帶你走完從憑證選擇、全站轉址、到遷移後兩週觀察期的完整流程，並且補上多數教學文輕輕帶過的 Mixed Content、HSTS 與 Search Console 雙資源的陷阱。

把帳算清楚：HTTPS 對 SEO 的加分很小，沒做好的代價卻很大

很多人把換 HTTPS 想成一件「為了 SEO 衝排名」的事，這個預期本身就需要校正。Google 早在 2014 年就公開說過，HTTPS 是一個排名訊號，而且當時就明講它屬於「很輕量」的那種，參考價值低於內容品質與連結，這段話出自官方的 HTTPS as a ranking signal 一文（2014 年 8 月）。到了 2020 年 Google 重新整理「網頁體驗」這組訊號時，也把 HTTPS 擺在「門檻型」的位置，意思是它更像一個資格審查，當作為門檻它會決定你夠不夠格被放進某些體驗敏感的搜尋結果裡（見同年的 Evaluating page experience）。

換句話說，HTTPS 對排名的作用，比較像「你繳了報名費才能參加考試」，而不是「你多加了十分」。當兩個網頁在內容、連結、速度上都打到平手的時候，HTTPS 那一邊會拿到那一票。但這種平手出現的機率本來就不高，所以多數站長換完之後，盯著排名追蹤表看了一個月，結論通常是：沒有感覺。這是正常的，因為它的設計本來就不是拿來推你一把。

那為什麼這件事還是建議一定要做？因為代價不對稱。下表把這筆帳拆開給你看：

看出來了嗎？HTTPS 的價值集中在兩個地方：一是它幫你避開「不安全」這三個字對使用者的嚇跑效果，二是它替你打開現代網路一堆功能的門。SEO 加分只是附帶的紅利，把它當主角來期待，你只會覺得被騙。

那麼，這個「平手時才發揮作用」的訊號，到底什麼時候會真的幫到你？答案是當你的內容跟競爭對手打到幾乎一模一樣的時候。想像你們兩個網站寫的是同一個關鍵字的教學文，篇幅相近、結構相似、外部連結的數量與品質也在伯仲之間。這時候 Google 需要一個夠細微的訊號來決定誰排前面，HTTPS 就是其中一張牌。這種極度接近的局面，在長尾、在地、產品規格這類同質性高的查詢裡其實相當常見，所以哪怕它只是張小牌，長期累積下來的影響也不容小看。還有一個情境會把 HTTPS 的權重放大，那就是牽涉到金錢、健康、法律、個人資料的敏感查詢。在這類 Google 內部歸類為高風險的領域裡，安全與信任訊號本來就被加權看待，一個掛著「不安全」標記的站，連進入候選名單都難，更別提要排上去。所以如果你的站點經營的是電商、醫療、金融、法律這些領域，HTTPS 對你來說早就不是選配，而是基本門檻。

HTTPS 是現代網路的入場券：安全、信任、速度綁在一起

有些站長把 HTTPS 純粹理解成「一把鎖」，裝了就安心。這個理解只對了一半，而且漏掉的那一半，恰恰是它跟 SEO 真正發生關係的地方。HTTPS 做的是三件事，這三件事最後會收斂到同一個結果：你的網站更值得被點、更值得被留、也更快被載入。

第一件事是加密。它讓使用者和你的伺服器之間來往的每一個封包都變成亂碼，第三者就算在咖啡廳的公共 Wi-Fi 上截到了封包，也看不到內容。這對登入頁、結帳頁、會員資料這類敏感場景是基本要求。以電商類型的網站為例，這類站對「不安全」三個字特別敏感：顧客在結帳頁看到警告，信用卡掏到一半就縮回去，後續再怎麼優化轉換率都事倍功半。這時候真正在作怪的，是那個讓人瞬間失去信任的紅色標記，跟你的商品或文案其實關係不大。

第二件事是驗證。SSL 憑證背後有一個發放機制，憑證商在把憑證交給你之前，多少會確認你對這個網域有控制權。這等於有一個第三方幫你的網站背書說「這台伺服器真的是它聲稱的那個網站」。這層背書在E-E-A-T 經驗權威信任的脈絡下特別有意思：Google 想看到的信任訊號，從來就不只是文章寫得多專業，還包括你的網站本身在技術上是不是一個可以被信賴的來源。

第三件事最容易被忽略，就是速度。這聽起來反直覺，加密不是會增加運算嗎？技術上是的，TLS 交握會多花一點時間。但關鍵在於，所有主流瀏覽器都只肯在 HTTPS 連線上啟用 HTTP/2 與 HTTP/3 這類現代傳輸協定。這些協定帶來的多工、標頭壓縮、連線復用，省下的時間遠遠超過加密本身花的成本。換句話說，裝 HTTPS 不會讓你變慢，反而幫你解鎖了一組變快的工具。而速度之於使用者和搜尋排名的關係，早就被反覆驗證過，可對照 web.dev 的 Why does speed matter?（2026 年版本）。

補充一個大局的視角。主流瀏覽器這幾年對 HTTP 站點的態度，是逐步升高的壓力。一開始只是位址列不顯示鎖頭，後來變成在 http 網頁的表單欄位標示「不安全」，再後來擴大到所有 http 頁面都掛上標記，而未來的方向是把更多使用者面向的功能（例如某些 Web API、剪貼簿存取、地理位置）直接限定只在安全來源上才能使用。這代表你繼續留在 HTTP 的成本會隨時間越來越高，涵蓋的層面會越來越廣，包括 SEO、包括功能可用性、也包括第三方服務的串接意願。從這個角度看，換 HTTPS 本質上是跟上整個網路基礎建設的演進，SEO 只是其實際效益的一部分。早換早享受，晚換只是把壓力往後累積，累積到最後往往只剩被動應付的份，當初可以從容規劃的餘裕早就沒了。

於是，實務上會把 HTTPS 跟網站效能擺在一起看。當你之後在優化 Core Web Vitals 核心網站體驗指標的時候，會發現很多進階手段（HTTP/2 推送、現代快取策略、服務工作者）的前提都是站已經在 HTTPS 上跑。你如果還卡在 HTTP，等於一開始就把這整條優化路徑堵死。

SSL 憑證三個等級，2026 年絕大多數人只需要一種

走進實際採購，你會看到 SSL 憑證被分成三個等級，價差可以從免費拉到一年上萬塊。很多人在這裡被銷售話術嚇到，以為越貴越安全。先把觀念導正：三個等級加密強度是一樣的，差別只在「憑證商查你查得多仔細」，而這個查核的差異，在 2026 年的瀏覽器介面上幾乎已經看不出來了。

這裡的關鍵轉折是：主流瀏覽器多年前就已經陸續拿掉 EV 憑證那條醒目的綠色公司名欄位。當年 EV 最大的賣點，就是那一條「視覺上讓顧客一眼看到你的公司名」的效果，現在這個效果在 Chrome、Edge、Safari 上幾乎都消失了。消費者再也分不出你裝的是 DV 還是 EV，那麼為了那條已經不存在的綠色欄位多付好幾千塊，意義就大大降低。

所以建議非常明確：除非你跑的是金融、保險、大型支付這類被法規或金流夥伴明確要求 OV 或 EV 的行業，不然絕大多數站長用 DV 就夠了。而且 DV 不一定要花錢。Let's Encrypt 提供完全免費的 DV 憑證，透過主機或 CDN 內容傳遞網路的自動化工具就能申請並定期續期。很多人對免費憑證的可靠性有疑慮，這其實是多慮了：Let's Encrypt 背後是非營利組織 ISRG，全球有極大比例的網站使用它的憑證，加密強度與商業憑證完全一致。免費的代價只是憑證有效期較短（通常九十天），需要自動續期機制來補，而這件事現代主機與 CDN 幾乎都幫你做好了。

憑證續期這件事，建議你從一開始就設定成自動化，別靠人去記。Let's Encrypt 的憑證每九十天到期，一旦你忘了續期，受影響的是整站、不是某一頁而已：瀏覽器會把過期的憑證當成無效，直接對所有訪客顯示警告頁，你的流量會在幾小時內歸零。實務上常見的狀況是，網站排名原本一直很穩，結果只因為一張憑證到期沒續，整整兩天沒人發現，等修好之後花了將近一個月才把曝光拉回原來水準。這種損失跟技術能力無關，純粹是維運紀律的問題。如果你的站跑在 WordPress 上，市場上有不少外掛可以把憑證申請、部署、強制轉址、Mixed Content 修復打包成一個流程，對新手很友善。但要留意，這類一鍵型外掛處理的是常見情境，遇到自訂伺服器規則、多站網路、或複雜的子網域結構時，它們背後自動改寫的設定檔有時會跟既有的快取或安全規則打架。所以實務上的建議是：新手用外掛快速上線沒問題，但請務必在裝完之後，回頭搞懂它到底替你改了哪些檔案，這樣出事時你才知道手該伸向哪裡。

在進入遷移步驟之前，還有一個決定請你先做好，而且最好在動任何轉址之前就拍板：你的標準網址到底要不要帶 www。舉例來說，https://example.com 跟 https://www.example.com 在 Google 眼裡同樣是兩個不同的網址。如果你在換 HTTPS 的同時，還沒決定好標準網域，那麼你等於要同時處理「http 換 https」加上「www 換成無 www（或反過來）」兩層轉址鏈。每多一層轉址，就多一次來回、多一個出錯的點，也讓 Google 理解你網站結構的成本變高。乾淨的做法是：先決定標準網域，把所有非標準版本（包括 http 版本以及非標準的 www 設定）一律用一層 301 直接轉到標準的 https 版本，避免鏈狀轉址。這個決定跟你的網域註冊、DNS 規劃綁在一起，如果你才剛起步，可以先從 網域申請購買全攻略 把基礎觀念補齊，才不會事後才發現選了一個不好維護的結構。

把憑證選好，下一步才是真正考驗功力的遷移工程。接下來這一節，會把步驟拆到可以直接照著做的程度。

一份不藏私的 HTTP 換 HTTPS 執行清單

很多教學把換 HTTPS 寫成「裝憑證、打開強制轉址、收工」三步驟，這種寫法省略掉的，恰恰是會讓你排名掉下來的細節。整個流程可拆成四個階段，每個階段都有它要解決的問題，也都有對應的 SEO 含義。強烈建議你照順序走，因為後面的步驟依賴前面的狀態。

申請並部署 SSL 憑證

第一個動作是讓你的伺服器能夠在 HTTPS 上回應請求。這一步跟你的主機環境綁得很緊。如果你的站架在 WordPress 一鍵架站環境或主流虛擬主機上，多半在後台就能一鍵開啟免費的 Let's Encrypt 憑證，主機商會幫你處理續期。如果你用的是 VPS 或雲端主機，那就要自己透過 Certbot 這類工具申請並設定自動續期的排程。

部署完之後，請務必做一個動作：用瀏覽器實際打開 https 開頭的網址，確認鎖頭有出現，而且點進憑證細節看有效期限與涵蓋的網域。很多人以為裝好就等於生效，結果其實憑證只涵蓋了一個子網域，其他子網域開出來還是報錯。如果你的站牽涉多個子網域，記得選擇涵蓋範圍正確的憑證類型（萬用憑證或 SAN 憑證）。跟網域設定有關的基礎觀念，可以先回頭看這篇 DNS 網域名稱指向設定，把 CNAME、A 紀錄這些底層的東西搞清楚，憑證部署的錯誤才容易排查。

站內連結與資源全面改用 HTTPS

憑證裝好，你的站「有能力」走 HTTPS 了，但這不代表它「已經是」HTTPS。你的網頁裡如果還藏著一堆 http 開頭的內部連結、圖片、CSS、JavaScript，瀏覽器會出現一種很尷尬的狀態：頁面本身是 https，但裡面的零件是 http，這就是所謂的 Mixed Content 混合內容。這個狀態的後果後面會專門講，在這裡你只要記得一件事：轉址之前，先把站內所有的 http 參照清乾淨。

具體要清的範圍包括：文章與頁面內文裡的內部連結、佈景主題與外掛寫死的資源路徑、canonical 標籤、Open Graph 與社群標籤裡的網址、資料庫 options 裡的 siteurl 與 home 欄位（WordPress 站長特別要注意這兩個欄位，它們決定了整站的基本網址）。一個務實的做法是先用相對協定（// 開頭）或直接全部改成 https，再用資料庫搜尋取代工具批次處理。不過這裡有一個 WordPress 專屬的深坑值得特別小心：很多外掛把設定以「序列化（serialized）」格式存進資料庫，這類欄位裡每個字串前面都帶有一個長度標記。如果你直接用 SQL 的 REPLACE 把 http 改成 https，字串變長了，長度標記卻沒跟著更新，整個設定就會壞掉，輕則某個外掛設定歸零，重則後台白屏打不開。正確的做法是用專門為序列化資料設計的搜尋取代工具（WP-CLI 的 search-replace 指令、或可靠的遷移類外掛），它們會同步更新長度標記。這個細節跟搬家是同一套道理，如果你曾經走過 WordPress 搬家到新主機 的流程，對這個坑應該不陌生。圖片資源如果量大，建議同步檢查一下 圖片壓縮與優化，順手把素材體積降下來，這對後面的載入速度也有幫助。

用 301 全站轉址把舊網址交給新網址

站內清乾淨之後，接著要處理的是「從外部來的舊 http 連結」。你不能假設全世界的人都會記得改用 https，所以要在伺服器層級設一道轉址：任何人打 http 的網址進來，自動被送去對應的 https 版本。這裡的關鍵是狀態碼的選擇，請務必用 301，不要用 302。

301 的語意是「永久搬移」，它會告訴 Google：舊網址的排名權重、連結價值，請全部轉移到新網址去。302 的語意是「暫時搬走」，Google 會把權重留在舊網址，新網址拿不到。這兩者弄反的後果非常嚴重，更詳細的對照可參考301 與 302 轉址完整教學，這裡只強調一句：全站 HTTP 換 HTTPS，永遠是 301。設定的位置依主機環境而異，Apache 是 .htaccess，Nginx 是 server 區塊的 return 指令，Cloudflare 則在後台開啟「一律使用 HTTPS」即可。

同步更新 Canonical、Sitemap 與 Search Console

這一步是最多人漏掉的，但它直接決定 Google 能不能用最短路徑理解你新的網站結構。三件事要做：

1. 把 canonical 標籤改成 https 版本。每一頁的 self-canonical 都應該指向它自己的 https 網址，這樣 Google 才不會在 http 與 https 兩個版本之間猶豫，造成重複內容的判定。canonical 的完整用法可以參考這篇 Canonical 標準網址教學。
2. 重新產生並提交 XML Sitemap。確保 sitemap 裡的網址全部是 https，然後到 Search Console 重新提交。舊的 http sitemap 請移除，避免 Google 一直去爬已經轉址的舊網址，浪費檢索預算。Sitemap 的細節在這篇 XML Sitemap 教學裡有完整說明。
3. 在 Search Console 新增 HTTPS 資源。這是最關鍵也最常被漏掉的一步，下一節的地雷區會專門解釋為什麼。對 GSC 還不熟的讀者，先看這篇 Google Search Console 介紹打好底。

真正讓排名掉下來的四顆遷移地雷

前面講的都是「該做的事」，這一節要講的是「做了會出事的事」。實務上網站遷移排名掉下來的原因，幾乎不出以下四類。它們的共同特徵是：表面上網站看起來正常運作，後台數據卻在悄悄惡化，等你發現的時候，Google 已經重新評估過一輪了。

地雷一：Mixed Content 把你的鎖頭偷偷打開

前面提過 Mixed Content，這裡要講它的真實殺傷力。當一個 https 頁面裡混進了 http 的圖片或腳本，瀏覽器的反應分兩種層級。如果是被動式混合內容（圖片、影片），瀏覽器可能只是把鎖頭拿掉，頁面看起來還在。如果是主動式混合內容（JavaScript、CSS、iframe），現代瀏覽器會直接擋掉這些資源，結果就是你的版面崩掉、按鈕失效、表單送不出去了。

從 SEO 的角度看，Mixed Content 的殺傷力在於它同時破壞了使用體驗與 Google 對你網站的信任。使用者看到版面壞掉會立刻跳出，這個行為訊號會被記下來。而 Google 在檢索你的頁面時，如果發現它聲稱是 https 卻載入了一堆 http 資源，也會把它當成一個技術品質的瑕疵。排查 Mixed Content 最有效率的方式是用瀏覽器的開發者工具看 Console，每一條「被封鎖的混合內容」警告都會列在那裡；規模大的站可以直接用線上掃描工具或 crawler 跑全站。

地雷二：HTTP 與 HTTPS 在 Google 眼裡是兩個網站

這是概念上最容易卡住的一點。對你來說，http://example.com 跟 https://example.com 是同一個網站的兩種開法。對 Google 來說，它們是兩個不同的網址，分別累積各自的排名訊號。你在 http 版本上累積了三年的反向連結、點擊資料、排名歷史，全都被記在 http 那個資源底下。

這就解釋了為什麼前面的執行清單裡，特別把「在 Search Console 新增 HTTPS 資源」單獨列出來。你不能只是在舊的 http 資源裡改設定，你要把 https 版本當成一個全新的資源去新增、去驗證。然後把兩個資源都留著觀察一陣子，舊的 http 資源讓你看到轉址流量怎麼移交，新的 https 資源讓你看到新版本怎麼累積索引與曝光。很多人換完 HTTPS 之後盯著舊資源看，發現流量掉了就崩潰，其實那是因為流量正在搬家到新資源去，你只是看錯了視窗。

如果你在這個過程裡真的發現排名出現異常下滑，先別慌，因為多數情況下這是遷移後的短期波動，處理得當會回來。判斷與處理的完整思路寫在Google 排名掉了怎麼辦這篇裡，建議對照著看。

地雷三：轉址狀態碼用錯，等於告訴 Google「只是暫時的」

前面提過 301 與 302 的差別，這裡要補一個更刁鑽的版本。有些主機或 CDN 的「強制 HTTPS」功能，背後預設用的是 302 或甚至用 JavaScript 做的 meta refresh 跳轉。表面上你打 http 會被送到 https，看起來很正常，但 Google 收到的訊號卻是「這只是暫時的」，於是它把所有排名權重繼續留在 http 那一邊，你的 https 版本等於是從零開始累積。

驗證的方法很簡單，用任何可以看 HTTP 回應標頭的工具（瀏覽器開發者工具的 Network 面板、或線上的標頭檢查服務），打一個 http 網址進去，看它回什麼狀態碼。你應該看到 301 搭配 Location 指到 https 版本。如果看到 302、303、307，或看到一個 200 加上頁面裡的 meta refresh，那就是設定錯了，回去把轉址規則改成 301。這個動作花你兩分鐘，卻能救回一整座排名。

地雷四：HSTS 沒開，第一次連線仍然可能被劫持

這顆地雷比較進階，但它的後果嚴重到值得每個站長知道。HTTPS 保護的是「已經建立加密連線之後」的通訊，但它保護不了「使用者第一次打開你網站的那一瞬間」。當使用者的瀏覽器還沒記住你網站只走 HTTPS 的時候，一個在中間的攻擊者理論上可以在第一次請求時，把使用者引導到一個 http 版本，再做後續的攔截。這種攻擊叫做 SSL Strip。

對應的防護叫 HSTS（HTTP Strict Transport Security），它的原理是讓你的伺服器在回應標頭裡告訴瀏覽器：「這個網站從現在起只准用 HTTPS，不准降級到 HTTP」。瀏覽器記住這個指令之後，往後連光想打 http 都會被它自動改成 https，根本不送出裸露的請求。HSTS 對 SEO 沒有直接的加分，但它是把 HTTPS 的安全效益補滿的最後一塊拼圖，下一節會講怎麼安全地開啟它。

裝完鎖之後的下一步：HSTS 與安全分層

很多教學在「裝好憑證、設好 301」之後就收尾了，但一個真正穩固的 HTTPS 設定，還有一層值得補上。這一層不會直接推你的排名，但它會讓你的網站在技術品質的評估上站得更穩，也讓你之後做效能與安全優化時有更好的地基。

開啟 HSTS 的方式是加一個 HTTP 回應標頭，內容大概長這樣：Strict-Transport-Security，後面帶一個 max-age 指令設定這個指令要被記住多久（常見值是半年到兩年），以及 includeSubDomains 與 preload 兩個選項。這個標頭可以在伺服器或 CDN 層加上去。但有一個非常重要的順序鐵律：在開啟 HSTS 之前，你的全站 HTTPS 必須已經完全正常運作，所有 http 都已經 301 到 https，而且憑證有效。原因是 HSTS 一旦被瀏覽器記住，它會拒絕連到 http 版本，如果你這時候憑證壞了或某個子網域還沒上 HTTPS，使用者會被完全鎖在外面，連你自己都可能進不去後台。

所以 HSTS 的導入建議分階段。先把 max-age 設得很短（例如三百秒），觀察幾天確認沒有任何子網域出問題，再逐步拉長到一天、一週，最後才放到半年以上並考慮加入 preload 清單。preload 清單是瀏覽器內建一份「天生只走 HTTPS」的網站名單，提交進去之後，連使用者的第一次連線都被保護到。這是 SSL Strip 的終極解答，但它的代價是退出非常困難，所以一定要在網域策略完全確定不會走回頭路之後再做。

HSTS 之外，現代網站的安全分層還包括 Content Security Policy（CSP），它讓你聲明這個頁面只准載入哪些來源的腳本與資源，等於在防護網上再加一道白名單機制。CSP 的設定需要對你網站實際使用的第三方資源有清楚掌握，否則設太嚴會把正常的功能擋掉。這兩者通常會跟著網站效能一起調整，建議在你看完 網站快取設定與 網站速度慢的診斷與解法，把基礎效能問題處理穩定之後，再回頭來做安全標頭的強化。這兩件事本質上都是在「讓你的網站在技術上更乾淨」，方向是一致的。

換完之後的兩週觀察期與行動清單

遷移完成的那一刻，工作才剛開始。接下來的兩週是 Google 重新認識你網站的關鍵期，這段時間你需要主動盯幾個訊號，而不是被動等結果。觀察重點列成下面這張表，照著看就能早期發現問題：

特別說明一下「曝光逐步移轉」這一項。剛換完的前幾天，你會看到舊的 http 資源曝光還在，新的 https 資源曝光從零開始爬，這是正常的權重移交過程，通常一到兩週會完成。如果兩週過去了，新資源完全沒有起色、舊資源卻掉得很快，那就要回頭檢查轉址、canonical、sitemap 這三件事是不是哪裡漏了。

這裡要特別提醒一個心理準備：遷移後的前幾天，看到排名或曝光數字微微下滑，是相當常見的正常現象，不要在第一週就急著大改。原因是 Google 需要時間重新檢索、重新理解新版網址與舊版之間的對應關係，這段期間它的評估處於一種過渡狀態，數字難免抖動。真正該觸發警報的訊號是：主力關鍵字出現兩位數百分比的下跌、而且持續超過兩週沒有回穩跡象，或是 GSC 裡 https 資源的索引頁數一直停在零。前者通常代表某一個技術設定出問題，後者幾乎可以肯定是 sitemap 或 canonical 沒接好。學會區分「正常過渡」與「真正的故障」，你才不會在數字抖動的焦慮裡做出反而讓情況更糟的急就章修改。穩住節奏、按表操課，是這兩週裡最值錢的紀律。

最後給你一份可以今天就動手的行動清單。它分成「還沒換的人」與「換了但沒把握的人」兩種情況，你自己對號入座：

1. 盤點現況。用瀏覽器打開你的首頁，看網址列有沒有鎖頭、有沒有不安全標記。順手到任何 W3Techs 或 SSL Labs 的線上檢測工具跑一次，看看你的憑證有效期限與等級。這個動作三十秒，卻是所有後續判斷的起點。
2. 備份再動手。如果你打算這週就開始遷移，先確保你的網站有一份完整且可還原的備份。任何牽涉到全站網址與資料庫的操作，都應該在備份完成之後才進行。備份的完整做法可以看這篇 WordPress 備份與還原指南。
3. 處理憑證。還沒裝的，到主機後台或 CDN 開啟 Let's Encrypt 自動憑證。已經裝了商業憑證的，趁這次檢查一下到期日，避免憑證過期造成全站打不開。
4. 清 Mixed Content 與設 301。用開發者工具掃一遍 http 殘留，批次改掉。然後在伺服器或 CDN 設好 301 全站轉址，用標頭檢查工具驗證狀態碼正確。
5. 新增 HTTPS 資源並提交 Sitemap。到 Search Console 新增 https 版本的資源，完成驗證，提交 https 版本的 sitemap，把 canonical 全部指向 https。然後開始兩週觀察期。

如果你已經換過了，但當初沒按這個流程走，那麼從清單的第一步重新跑一遍盤點，往往就能找出當初漏掉的那一顆地雷。多數「換完之後排名一直沒回來」的案例，回頭追都追到 canonical 沒改、轉址用了 302、或根本忘了新增 https 資源這三件事上。

說到底，HTTP 換 HTTPS 是一件「做對了沒人感謝你、做錯了所有人都會找你」的基礎工程。它的價值不在於把你推向第一名，而在於它幫你守住那條地板，讓你過去累積的內容、連結、信任，不會因為一個技術疏失而歸零。把這份清單走完，把地雷記清楚，你的網站就站在一個更穩固的起點上，往後再去優化速度、累積權威、衝刺排名，才有一個值得放大的地基。記住一個原則：每一次牽涉到網址結構的變動，不論是換憑證、改主機、還是調整網域，備份永遠跑在最前面，驗證永遠收在最尾巴。這個紀律一旦建立起來，你面對任何技術變更都不會再手忙腳亂。願你的鎖頭亮得踏實。