WPTOOLBEAR網站工具熊Google Safe Browsing 標記網站不安全：WordPress 排查與複審步驟
網站被 Google Safe Browsing 標記為不安全，應先確認警告類型，再備份、清除惡意內容、修補漏洞，最後申請複審。若畫面顯示「您的連線不是私人連線」，則應優先排查 HTTPS 憑證，兩者的處理方式不同。
對 WordPress 管理員來說，清除入侵根因才是解除警告的基礎。先依畫面與 Google 報告定位問題，避免一開始就重裝網站或關閉防護。
重點整理
- 紅色危險網站警告與憑證驗證錯誤不同，不能用同一套方法處理。
- 修改前先備份檔案、資料庫與紀錄，清理範圍不能只限於 Google 提供的範例網址。
- 確認全站問題已解決，再提交安全性審查；不要引導訪客略過警告。
先分清楚：網站危險，還是連線不安全？
Chrome 的安全提示，可能指向網站內容、加密連線或網頁資源。
先依畫面判斷排查方向：
| 畫面或訊息 | 主要問題 | 優先處理 |
|---|---|---|
| 紅色危險網站、詐騙或惡意軟體警告 | Safe Browsing 偵測到風險 | 查安全性問題報告、清理網站 |
| Your connection is not private | HTTPS 憑證驗證失敗 | 查日期時間、網域與憑證 |
| 網址列顯示 Not secure | HTTP 連線或其他連線安全問題 | 點開網站資訊，查看原因 |
「Your connection is not private」可能附帶 NET::ERR_CERT_COMMON_NAME_INVALID，通常表示網址與憑證涵蓋的名稱不符。
另外，加密頁面若載入 HTTP 資源，就會形成混合內容（mixed content）。Chrome 可能升級或封鎖資源；點選網址列的網站資訊或「Not secure」，可查看連線細節。
Safe Browsing 能快速攔截新出現的釣魚（phishing）網站。不過，網路討論中「Chrome 約 30 分鐘封鎖，Firefox、Safari、Edge 落後數小時」的說法只是個別測試，不能當成固定速度或瀏覽器排名。
用 Google 報告確認範圍，修改前先備份
查詢網站狀態與安全性問題
先透過 Google Safe Browsing 網站狀態工具查詢網域，再登入已驗證網站擁有權的 Search Console，開啟「安全性問題」。
展開每個問題，記下類型、受影響網址與首次發現時間。惡意軟體、欺騙性內容及遭入侵頁面，需要不同的清理方式。
報告中的網址只是範例，並非完整清單。首頁正常，也不能排除文章、附件、子目錄或第三方腳本仍有問題。
保存備份與可追查的證據
開始刪檔或更新前，完整備份網站檔案與資料庫，至少保留一份於站外。受感染的備份要另外標記，不能當成乾淨還原點。
同時保存警告截圖、掃描結果、可疑檔案路徑、修改時間與主機紀錄。分享資料前，遮蔽 Cookie、授權標頭、個資及 API 金鑰。
若網站仍在轉址或散布惡意內容，應先限制受影響服務，並保留調查資料。不要為了讓首頁恢復，就立刻覆蓋所有檔案。
WordPress 清理：檢查檔案、外掛與資料庫
找出被植入的內容與後門
使用既有安全工具或主機掃描，搭配乾淨版本比對檔案。可用 Wordfence 協助掃描，但不能只憑一次綠燈判定安全。
優先檢查 wp-content、外掛、佈景主題、mu-plugins、上傳目錄及 wp-config.php。也要檢查資料庫文章、網站設定、不明管理員與排程工作。
Apache 環境另外檢查 .htaccess 的轉址規則；純 Nginx 不讀取這個檔案。陌生程式碼先隔離分析，不要把所有被標記檔案一律刪除。
完整清理可依照我們的 WordPress 惡意軟體移除指南逐項進行，並保留每次修改的結果。
修補漏洞，更新軟體與撤銷憑證
清除惡意內容後，更新 WordPress 核心、外掛及佈景主題。停止維護或來源不明的套件應移除；停用但留在主機上的外掛，也要納入盤點。
更新與 PHP 調整先在隔離的測試站驗證，不要同時更動多項設定。每次記錄原值、新值與測試結果，才能找出問題來源。
接著重設管理員、主機、SFTP 與資料庫密碼，撤銷不需要的應用程式密碼及金鑰，並啟用雙重驗證。若只清除頁面內容，卻留下外掛漏洞或後門，網站可能再次感染。
確認清理完成，再申請 Google 複審
依照 Google 安全性問題報告說明，必須修正所有列出的問題，以及網站上所有受影響頁面，才提出安全性審查要求。
實際送審順序如下：
- 重新掃描並比對檔案，確認惡意內容、轉址、後門與不明帳號已清除。
- 測試原本被標記的網址，並擴大檢查其他目錄、手機版與未登入狀態。
- 在 Search Console「安全性問題」中選擇「要求審查」，說明發現的問題、清理方式、漏洞修補與驗證結果。
- 送出後等待電子郵件通知，審查可能需要幾天至幾週；尚未取得結果前，不要重複送件。
複審說明應填寫實際完成的處置，例如移除了哪些受感染檔案、修補哪個套件漏洞，以及如何確認沒有再生。不要只寫「已安裝 SSL」或「請解除封鎖」。
刪除 Google 列出的範例頁面，不能證明全站已清理完成；複審前仍須排除其他路徑與漏洞。
送審前也應確認網站沒有被整站密碼保護或防火牆阻擋，以免妨礙 Google 驗證修正結果。
若只有你的電腦出錯，先查時間與攔截程式
HTTPS 都失敗時，先同步日期時間
如果只有一部電腦出錯，先開啟作業系統的自動校時，確認 date and time（日期與時間）及時區設定正確，再更新 Chrome 並重新啟動。
時間錯誤可能讓憑證被判定尚未生效或已過期。HTTP 能開、加密連線全部失敗，是排查線索，但不代表應改用 HTTP；不要透過未加密連線登入或付款。
接著用另一部裝置與手機網路交叉測試，區分網站端、本機及公司網路問題。測試時不要略過危險網站警告。
防毒、VPN 與代理可能改變憑證
Avast Web Shield 等防毒程式（antivirus）的網頁防護可能檢查加密流量，並向瀏覽器呈現替換後的憑證。日期錯誤、SSL certificates 涵蓋的網域不符，或信任鏈設定異常，都可能造成憑證警告。
舊案例曾因短暫關閉 Web Shield，或解除安裝 Sendori 而恢復。但這些只提供調查方向，不能證明你的電腦也有相同原因。
需要停用防護測試時，應由熟悉設定的人員短暫操作，只測可信網站、不輸入敏感資料，完成後立即恢復。
此外，VPN、proxy 設定異常及公司次世代防火牆的 man-in-the-middle（中間人）檢測，都可能影響憑證驗證。公司設備應交由 IT 比對政策與紀錄，不要自行移除企業憑證。
查看憑證時，不要只認發行者名稱
Windows 或 Linux 的 Chrome 可按 Ctrl+Shift+I 開啟開發人員工具，再進入 Security 分頁，選擇 View certificate。部分舊教學稱為 View Cert；若分頁未顯示，可從開發人員工具的工具選單開啟。
檢查網址是否包含在憑證的主體別名、有效期間是否正常，以及信任鏈有無錯誤。若憑證發行者（certificate issuer）顯示為防毒軟體或公司設備名稱，就應進一步調查加密流量檢查。
Google Internet Authority G2 是舊憑證名稱，不能要求現在的網站都由它簽發。憑證有效也只代表連線驗證通過，不代表網站沒有釣魚內容。
同樣地，Let’s Encrypt 在 2020 年當時採用 90 天憑證；該年 3 月撤銷的那批憑證早已到期，無法解釋現在才出現的警告。
不要使用 --ignore-certificate-errors 略過錯誤。這只會取消保護，不能修復名稱不符、信任鏈或攔截設定。
修復驗收要涵蓋前台與背景工作
重走原本失敗的操作
清理後，除了首頁，還要測試後台登入、儲存、圖片、表單寄信與主要頁面。WooCommerce 網站也要驗證購物車、測試付款及訂單更新。
如果曾有排程異常，可建立一篇預約於 10 至 15 分鐘後發布的測試文章，並比對執行紀錄。備份則要確認檔案確實產生且能還原，不能只看成功通知。
最後恢復暫停的防護，移除測試例外，並持續觀察可疑檔案或帳號是否再次出現。
管好管理員使用的瀏覽器
企業可透過 Chrome Browser Cloud Management 集中管理瀏覽器，並參考 CIS Chrome Benchmark 設定更新、權限與擴充功能政策，納入整體 cyber security（資安）管理。
browser extensions（瀏覽器擴充功能）若缺乏控管，可能存取網站內容與登入資料。選擇 Chrome、Firefox、Edge 或 Brave，都不能取代更新、擴充功能審核與釣魚辨識。
日常維護可依照我們的 WordPress 網站安全檢查清單，持續盤點權限、外掛與備份。
常見問題
出現警告，就代表 Google 帳號被盜嗎？
不能只憑警告判定。若你曾在可疑頁面輸入密碼、驗證碼或授權存取，應立即從可信裝置更改密碼、檢查登入活動並撤銷不明授權。
無痕模式也不能讓危險網站變安全，或避免網路管理者看到連線活動。
網站回傳 403，也是 Safe Browsing 封鎖嗎？
403 表示伺服器理解請求，但拒絕存取，不能單憑它判定網站感染。應記下路徑、時間、請求方法與識別碼，再比對 CDN、WAF 及主機紀錄。
可參考我們的 WordPress 403 錯誤排查。若確認是誤擋，採最小範圍例外，不要永久關閉防火牆或將權限全部改成 777。
解除警告，從可驗證的修復開始
Google Safe Browsing 標記網站不安全時，先辨識警告，再保留證據、清理全站並修補漏洞。確認問題已解決，才進入複審流程。
若缺乏主機或程式分析能力，可以把警告截圖、網址與發生時間交給我們協助判斷。修復目標是讓訪客能安全使用網站，而非只讓警告畫面消失。