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 寫成「裝憑證、打開強制轉址、收工」三步驟，卻省略了內部網址、混合內容和索引訊號的檢查。這些問題可能讓頁面載入異常，也可能拖慢搜尋系統辨識新網址。整個流程可拆成四個階段，照順序檢查比較不容易漏掉前一步的設定。

申請並部署 SSL 憑證

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

部署完之後，請務必做一個動作：用瀏覽器實際打開 https 開頭的網址，確認瀏覽器顯示安全連線，並從網站資訊或憑證檢視有效期限與涵蓋網域；Chrome 已以調整圖示取代傳統鎖頭，不宜再把「看見鎖頭」當通用檢查標準。很多人以為裝好就等於生效，結果其實憑證只涵蓋了一個子網域，其他子網域開出來還是報錯。如果你的站牽涉多個子網域，記得選擇涵蓋範圍正確的憑證類型（萬用憑證或 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 或 308 都可以；不要把 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 的圖片或腳本，現代瀏覽器會依資源類型嘗試自動升級部分 HTTP 請求，或直接封鎖不安全資源；結果可能是圖片失敗、版面異常或互動失效。不要只靠網址列圖示判斷，應在開發者工具的 Console 與 Network 確認每個資源是否透過 HTTPS 成功載入。

Mixed Content 可能造成圖片、樣式或互動功能無法正常載入，也會影響使用者對頁面的信任。這是體驗與轉換風險，不能直接推斷為 Google 的跳出率排名訊號。排查時應在瀏覽器開發者工具的 Console 與 Network 檢查資源是否被升級或封鎖；規模大的網站再搭配 crawler 盤點 HTTP 資源網址。

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

這是概念上最容易卡住的一點。對你來說，http://example.com 跟 https://example.com 是同一個網站的兩種開法。對 Google 來說，這是兩個不同的網址，需要用一對一永久轉址與一致的 canonical 等線索指定首選版本。Google 表示永久轉址有助將舊網址訊號轉移到新網址；不要把點擊資料或「排名歷史」想成一筆可搬移的固定權重。

這就解釋了為什麼前面的執行清單裡，特別把「在 Search Console 新增 HTTPS 資源」單獨列出來。你不能只是在舊的 http 資源裡改設定，若使用 URL 前置字元資源，需另加並驗證 https 版本；若已有網域資源，它原本就涵蓋 http、https 與子網域，仍可另建前置字元資源方便分開觀察。然後把兩個資源都留著觀察一陣子，舊的 http 資源讓你看到轉址流量怎麼移交，新的 https 資源讓你看到新版本怎麼累積索引與曝光。很多人換完 HTTPS 之後盯著舊資源看，發現流量掉了就崩潰，其實那是因為流量正在搬家到新資源去，你只是看錯了視窗。

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

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

前面提過 301 與 302 的差別。檢查「強制 HTTPS」時，不能只看瀏覽器最後是否到了 HTTPS，還要確認伺服器實際回傳的狀態碼。Google 將 302 等暫時轉址視為較弱的標準網址訊號；若其他 canonical 訊號一致，HTTPS 頁仍可能被索引，不能說它必然從零開始。全站永久遷移應使用伺服器端 301 或 308，並逐一測試舊網址是否導向對應的新網址。

驗證的方法很簡單，用任何可以看 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 的導入建議分階段。先確認所有子網域（包括內部使用的子網域）都能正常使用 HTTPS，再以短 max-age（例如 300 秒）開始，觀察後逐步延長。HSTS preload 不是一般站點的預設步驟；若確有需求，提交前必須符合至少一年 max-age、includeSubDomains、preload 與有效憑證等條件，而且移除清單可能需數月，應審慎評估。

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

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

遷移完成的那一刻，工作才剛開始。接下來應持續觀察 Google 重新抓取與索引新網址的過程，監測期要依網站規模與實際波動調整，這段時間你需要主動盯幾個訊號，而不是被動等結果。觀察重點列成下面這張表，照著看就能早期發現問題：

特別說明「曝光逐步移轉」：遷移後一段時間，舊 HTTP 網址可能仍有曝光，新 HTTPS 網址則逐步出現。Google 表示，中型網站改用新網址可能需要數週或更久，大型網站可能更久，沒有固定一到兩週的期限。持續比對兩組網址在 Search Console 的索引與流量；若新網址長期未被收錄，再檢查轉址、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 是一件「做對了沒人感謝你、做錯了所有人都會找你」的基礎工程。它的價值不在於把你推向第一名，而在於它幫你守住那條地板，讓你過去累積的內容、連結、信任，不會因為一個技術疏失而歸零。把這份清單走完，把地雷記清楚，你的網站就站在一個更穩固的起點上，往後再去優化速度、累積權威、衝刺排名，才有一個值得放大的地基。記住一個原則：每一次牽涉到網址結構的變動，不論是換憑證、改主機、還是調整網域，備份永遠跑在最前面，驗證永遠收在最尾巴。這個紀律一旦建立起來，你面對任何技術變更都不會再手忙腳亂。願你的鎖頭亮得踏實。