打開網站前台，畫面看起來完全正常，商品頁、部落格文章、聯絡表單一切照舊。可是把自己的網域丟進 Google 搜尋，或搜尋自己原本該排在前面的品牌關鍵字，跳出來的卻是一整頁陌生的日文字眼，點進去多半是成人內容或仿冒精品的購物頁面。
這種現象在資安圈稱為日文垃圾 hack（Japanese keyword hack），是 SEO 垃圾郵件的一種變形：駭客盯上的不是流量小的新站，而是本來就排名良好、被 Google 信任的既有網站，趁著這份信任把垃圾關鍵字和連結硬塞進搜尋結果，讓原本的訪客通路變成一條銷贓管道。麻煩的是，多數人發現後的第一個動作（掃一次安全外掛、砍掉可疑檔案）往往清完之後，Google 那邊的垃圾結果還是原封不動地掛著，甚至過了幾星期都沒有改善。
問題不在於清得不夠用力，而在於清錯了層次。先從最容易被忽略的辨識線索講起，再一路拆到 Google 搜尋結果遲遲不消失的真正原因。
網站前台正常運作，Google 搜尋結果卻布滿日文色情連結
Google 官方文件描述過這種手法的基本樣貌，駭客會在網站上建立一批頁面，存放在隨機產生的目錄名稱底下，例如example.com/ltjmnjp/341.html這樣的格式。這些頁面靠聯盟連結導向販售仿冒商品的購物網站賺錢。因為目錄名稱是隨機生成，站主平常根本不會點進去看，前台首頁、選單、既有文章卻完全沒被動到，才會出現「網站看起來沒事，Google 卻長滿垃圾」這種落差。
要自行確認自己有沒有中招，有兩個可以立刻做的檢查。先看看有沒有收到 Search Console 的通知，內容大致是「有陌生人驗證了你的網站」；再直接在 Google 搜尋框輸入site:你的網域，往後翻幾頁，留意有沒有看不懂的日文網址或標題出現在清單裡。如果 Google 那邊看起來乾淨，也可以換一個搜尋引擎、用同樣的關鍵字再查一次，不同搜尋引擎抓取索引的進度未必一樣。
真的點進那些可疑網址，情況往往比想像中混亂：有的會被重新導向到另一個完全不相干的網站，有的會看到一整頁亂碼，甚至有些直接顯示 404 找不到頁面，讓人誤以為問題早就自己消失了。這其實是駭客刻意的偽裝手法，一般瀏覽器打開時內容看起來乾淨，只有 Google 的爬蟲抓到時才會看到垃圾內容。
Sucuri（國際資安研究部落格）指出，日文垃圾 hack 本質上是 SEO 垃圾郵件的一種，駭客靠入侵原本排名就不錯的合法網站，把自己的垃圾關鍵字與連結接到這份既有的搜尋能見度上；搜尋這些關鍵字的人如果真的點進垃圾連結、甚至下單購買仿冒商品，很可能因此被詐騙。也因為駭客要的是既有網站的信任分數，大部分人發現中招後的第一反應都是趕快把可疑的東西清乾淨，但這個直覺動作能不能真的解決問題，又是另一回事。
外掛全部掃過，核心檔案也重灌，垃圾連結還是纏著搜尋結果
多數人發現網站中招之後，第一步幾乎都一樣，先跑一次安全外掛全站掃描，把看起來可疑的檔案刪掉，狀況嚴重一點的乾脆把整個網站的程式重灌一遍。這個直覺沒有錯，官方建議的標準清理流程確實也是從這裡開始：重新安裝 CMS 的所有核心檔案，以及自己加裝的佈景主題、模組、外掛，確保這些檔案都不含遭駭的內容；同時把.htaccess換成乾淨或預設版本。如果站主自己從來沒有手動設定過.htaccess，現在網站上那一份很可能本身就是惡意檔案，應該先另外存一份副本備查，再從網站上移除。
判斷可疑 PHP 檔案，Google 官方文件給的方法很具體。先把 CMS 預設安裝就有的檔案排除，只看不屬於預設安裝的檔案；接著依「最近修改日期」排序，抓出網站剛遭駭那段時間前後被動過的檔案；也依「檔案大小異常」抓出特別肥大的檔案；最後掃描這些檔案裡有沒有base64_decode、rot13、eval、strrev、gzinflate這幾個常被用來包裝混淆惡意程式碼的函式組合。這一套做完，多數人會覺得該清的都清了，這個判斷本身沒有錯，只是還沒完整。
為什麼還沒完整，答案就藏在官方清理步驟自己的編排順序裡。Sucuri 整理的十步驟清理流程中，「掃描並移除惡意程式碼」排在第 2 步，「更新資料庫使用者憑證」排在第 4 步，「檢查 sitemap 裡的可疑連結」則排到第 9 步，中間還夾著好幾個看起來不相干的動作。官方文件也把「移除惡意檔案和指令碼」與「檢查 sitemap」列成兩個分開的步驟。這代表清完檔案系統這一層，只等於處理完流程裡的一小段，資料庫、Search Console 帳號設定各自是獨立運作的層次，任何一層沒清乾淨，垃圾內容都會繼續被 Google 讀到。這也是為什麼很多人明明按照教學把外掛、核心檔案都處理過一輪，日文垃圾 hack 造成的搜尋結果卻幾乎沒有改善。
垃圾頁面在應用層之外仍潛伏的四個角落
檔案與程式碼只是駭客留下痕跡的其中一層。這個手法之所以難清乾淨，是因為它同時在另外四個地方留下各自獨立運作的殘留：sitemap、資料庫、Search Console 的帳號設定，再加上 CDN 快取與 Google 自己的索引庫。這四個角落彼此不相通，一個清乾淨、另一個原封不動，垃圾內容照樣會被 Google 繼續讀到或繼續顯示在搜尋結果裡。
先從最容易被忽略、也最直接影響 Google 讀什麼內容的第一個角落講起。
被竄改或新增的惡意 sitemap 檔案
清完檔案系統，垃圾網址還是一直冒出來，原因在於 sitemap 是一份獨立於前台內容之外的清單，Google 認的是這份清單本身，不是每次都重新即時掃過全站每一個頁面。Google 官方文件指出，駭客通常會修改網站原有的 sitemap，或另外新增一個 sitemap，目的都是讓自己的垃圾網址被更快建立索引。清查做法很直接：如果網站原本就有 sitemap，要打開檢查裡面有沒有混入可疑連結並移除；如果網站上出現一個站主自己不記得建立過的 sitemap 檔案，而且內容幾乎全是垃圾網址，直接整份刪除就好。
Sucuri 在 2023 年拆解過一起感染案例，惡意程式的本質是一個門戶頁產生器（doorway generator），會從外部惡意網域抓取內容，自動生成成千上萬個垃圾頁面，而且會自己生成 sitemap，鎖定 Google、Yahoo、Bing 三家搜尋引擎的爬蟲，幫助這些垃圾網址更快被找到並建立索引。這代表 sitemap 在這整套攻擊裡本身就是工具鏈的一部分，不是被動留下的殘渣。
Sucuri 在 2025 年初追查的另一起案例，直接對應到「明明清乾淨了，Google 卻還在爬垃圾網址」這個核心疑問。某案例網站已經把前台的垃圾內容清得一乾二淨，Google 卻仍持續爬取、索引一批垃圾網址。追查後發現，駭客在網站根目錄放了一個叫spamurl.txt的檔案，裡面塞了超過 3,000 個格式為網域/?m=一串隨機數字的垃圾網址，並把這份純文字檔案設定成該網站在 Search Console 裡登記的 sitemap。就算前台垃圾內容已經清掉，這份 sitemap 設定仍在 Search Console 裡保持啟用，持續指揮 Google 的爬蟲回頭爬取這些多半已經變成 404 的垃圾網址，索引裡的垃圾網址數量甚至還在持續往上爬。清理做法分三步：先在根目錄找到並刪除這個惡意檔案，再到 Search Console 的 Sitemaps 報表把這份 sitemap 移除或取消提交，最後重新提交一份乾淨正確的 sitemap，要求 Google 重新檢索。
會有效，是因為 sitemap 要讓 Google 認得，除了透過 Search Console 直接提交，也可以在robots.txt裡寫入一行宣告，例如Sitemap: https://example.com/my_sitemap.xml，Google 在下次讀取robots.txt時就會找到它；而純文字格式的 sitemap 只規定每行放一個網址、不能夾雜其他內容。這也解釋了為什麼駭客光靠一支單純的.txt檔案，就能讓自己那批垃圾網址被納入 Google 的檢索範圍，格式門檻低到幾乎沒有防呆。
資料庫裡殘留的垃圾文章與陌生管理員帳號
掃描檔案系統、換掉外掛主題，清得掉的都是「檔案」層級的東西。可是有一部分內容，是駭客直接寫進資料庫裡的：多出來的文章、被動過手腳的設定、多長出來的帳號，這些活在網站內容本身裡，跟檔案系統是分開的兩層，一般掃檔案的工具通常碰不到。
Sucuri 整理的十步驟清理流程裡，除了掃描網站檔案與目錄找異常，也要求掃描並移除資料庫裡的垃圾文章或內容，具體做法是直接到後台的文章、頁面、留言列表逐一核對，看有沒有自己不記得建立過的內容。同一份流程也把「檢查 Search Console 的使用者與資源擁有者名單，撤銷不認得的可疑帳號」排在第一步，這雖然講的是 Search Console 層級的帳號，背後卻是同一個邏輯，駭客會靠增加擁有者或使用者的方式長期維持控制權。同樣的邏輯要套用到 WordPress 後台本身的使用者列表，逐一核對有沒有自己沒建立過的管理員帳號。
Sucuri 拆解過的一起真實案例更說明這種殘留有多容易被忽略。這起感染的惡意程式碼藏在網站wp-content/mu-plugins目錄下一支經過 Base64 編碼的隱藏檔案裡，由同目錄另一支檔案負責載入執行。mu-plugins（must-use 外掛）目錄不會出現在一般後台的外掛清單介面裡，是特別容易被略過的死角。不管是掃資料庫，還是逐一核對後台的文章與外掛清單，都掃不到這種藏在檔案系統、卻不在標準外掛目錄裡的殘留，得額外去確認這個目錄底下有沒有陌生檔案。
Search Console 裡沒撤銷的網站擁有權和 sitemap 設定
就算網站本身已經徹底乾淨，如果駭客當初趁著入侵順手加進 Search Console 的身分與設定沒被清掉，那份垃圾 sitemap 對 Google 來說依然「合法」，原因是 Google 認的是 Search Console 裡登記的擁有者與提交紀錄，不是網站現在乾不乾淨。
Google 官方文件指出，駭客通常會在入侵時把自己新增為 Search Console 的資源擁有者，藉此操控地理區域目標或 sitemap 等網站設定；如果收到「有人驗證了你的網站，但你不認識對方」這類通知，網站很可能已經被駭。清除做法是到 Search Console 的驗證頁面點開「驗證詳細資料」，查看所有已驗證的使用者，把不認識的擁有者一一撤銷；同時要記得移除對應的驗證權杖，這通常是網站根目錄裡的一個 HTML 檔案，或是偽裝成該 HTML 檔案、實際上由.htaccess動態產生的規則，常見的寫法像是RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L]。如果站上找不到 HTML 驗證權杖，就要回頭檢查.htaccess裡的重寫規則有沒有類似的偽裝。
Sucuri 把「檢查 Search Console 的使用者與資源擁有者頁籤，撤銷可疑帳號」排在整套清理流程的第一步，順序上比掃描檔案、重灌核心都還前面，等於把它視為第一時間要處理的優先事項，而不是清完檔案之後才順手看一眼的次要項目。
還沒跟上清理進度的 CDN 快取與 Google 索引庫
前面三個角落，應用層檔案、sitemap、Search Console 擁有權都清乾淨之後，還是可能在自己網站或 Google 搜尋結果裡看到垃圾內容殘留一段時間。這不代表清理沒有生效，原因出在快取與索引更新本身就需要時間，操之過急重複清查反而是白工。
Google 的移除工具說明得很清楚，「暫時封鎖」功能只是暫時把網址從搜尋結果裡擋掉、連同快照一起隱藏，並不會讓網址真正從 Google 索引消失，效力大約只維持 6 個月，之後內容有可能再度出現在搜尋結果裡。封鎖網址也不代表 Google 不會再爬取這個網址，只要頁面還沒有真正清乾淨或設成 noindex，之後還是可能重新浮上來。文件明確指出，要永久移除，正確做法是把駭客建立的頁面清乾淨、或讓它回傳 404 或 410，再讓 Google 重新爬取後自然把它從索引拿掉，而不是只靠移除工具擋一次就以為結束。
確認問題都修好之後，還要在 Search Console 的安全性問題報表裡按下重新審查申請；審查通常需要幾天到幾週不等，過程中會收到 email 通知進度，審查完成前不要重複送出申請，重複送出反而會拉長下一次審查的等待時間，甚至可能被標記成累犯。另外，如果網站掛在 CDN（例如 Cloudflare）後面，就算原始站源已經清乾淨，訪客與 Google 的爬蟲實際拿到的可能還是 CDN 節點上快取的舊版本，裡面照樣夾帶垃圾內容，這種情況要主動到 CDN 後台執行清除快取，不管是清除全站快取或針對特定網址單獨清除，才能確保下一次抓取到的是乾淨版本。
確認 Google 看到的是乾淨版本，而不是駭客偽裝出的假象
回到最開頭那個困惑，網站前台看起來完全正常，Google 搜尋結果卻冒出一堆垃圾連結。這個落差背後的機制叫 cloaking（偽裝），意思是駭客讓一般訪客與 Google 的爬蟲看到的其實是兩個不同版本的頁面。只用自己的瀏覽器打開網站看起來正常，並不能代表 Google 那邊看到的也是同一個版本。
Sucuri 拆解過的一起案例最能說明這件事，案例裡的垃圾內容其實是英文賭博廣告與仿冒購物頁面而非日文，但用的是同一套偽裝手法。同一個網址，用 Chrome、Safari 打開都完全正常，看不到任何垃圾內容；但只要把瀏覽器的 User-Agent 切換成 Google 爬蟲慣用的那組字串，畫面立刻變成滿版的垃圾廣告內容。同一個網址，一般訪客與 Google 的爬蟲看到的是兩個截然不同的版本，這是判斷網站是否真的中招最直接的方法之一。
Google 的官方文件甚至建議，不要直接用瀏覽器打開這類可疑網址，一方面駭客常用的手法可能觸發瀏覽器本身的漏洞，二方面就算真的打開，看到的也可能只是偽裝過的乾淨版本。改用兩種更安全的方式核對：第一是 Search Console 裡的「URL 檢查工具」，可以直接看到 Google 實際爬到、看到的版本；第二是用 cURL 或 Wget 在命令列模擬 Google 爬蟲的請求，指定 referrer 與 user-agent，範例指令是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.html。之所以要換不同的 referrer 與 user-agent 反覆測試，是因為駭客常常只針對特定的 user-agent 或 referrer 來源觸發垃圾內容，假裝從 Google 搜尋結果點進來、假裝從大型網站連過來，結果往往不一樣。找可疑內容時，也可以直接在頁面原始碼裡搜尋eval、base64_decode、unescape這幾個關鍵字，通常就是混淆過的惡意程式碼藏身處。
Google 官方文件也建議直接在 Google 搜尋用site:網域查看自己網站被索引的頁面清單，揪出自己沒建立過的頁面；Google 開發者部落格則具體示範，可以加上關鍵字縮小查詢範圍，例如site:example.com (viagra|cialis|casino|payday loans)專門找含特定垃圾字詞的頁面。至於怎麼確定真的乾淨了，Google 官方文件給的判斷依據很明確，拿當初發現的垃圾網址，用 URL 檢查工具的「即時測試」功能重新測一次，如果回應是找不到，才代表這個網址真的乾淨了，接下來才輪到處理網站上真正的安全漏洞本身。
補強登入與更新習慣，避免同一個漏洞被再次利用
前面幾個角落一個一個清完，搜尋結果也確認恢復乾淨，還有最後一件事不能跳過，找出網站當初是怎麼被闖進來的。清完症狀卻沒找到入口，等於只是把地板擦乾淨，窗戶還是開著。
Sucuri 整理過網站會中這類攻擊的三種常見成因。第一種是網站本身有漏洞，用了帶有已知安全漏洞的過時軟體，或客製功能裡本身就藏著不安全的程式碼，駭客常用自動化工具批次掃這種弱點；第二種是密碼太弱，管理員帳號、資料庫或 FTP 密碼強度不夠，甚至還在用預設值，讓網站容易被暴力破解與自動化攻擊鎖定；第三種是後台缺乏防護，管理頁面與登入頁沒有任何防禦機制，才會讓入侵變得輕而易舉。對應的補強做法也很具體，加裝多因素驗證、限制登入嘗試次數、限制能存取後台的 IP 範圍，都能明顯降低這類入侵的風險。
Google 官方文件指出，近期的研究發現有 20%的遭入侵網站會在一天內再度被駭，如果清乾淨之後沒有真正找出並補起漏洞來源，復發的風險其實相當高。官方建議的防護清單並不複雜：定期用防毒軟體掃描自己的電腦有沒有中毒；定期更換主機服務、FTP、CMS 等所有相關帳號的密碼，而且每組帳號都要用不同的高強度密碼；能開雙重驗證的服務就開；CMS、外掛、佈景主題持續更新到最新版本，有些 CMS 本身就支援自動更新；如果網站對經營來說很重要，也可以考慮訂閱安全監控服務，長期盯著網站的狀況。
日文垃圾 hack 真正難纏的地方，不在於駭客的技術有多高明，而在於它同時卡在好幾個彼此不相通的角落，清掉一層不代表其他層也一併解決。比起追著搜尋結果一次次確認乾不乾淨，更該做的是回頭找出當初讓駭客闖進來的那個漏洞，把它真正補起來。少了這一步，不管前面清得多徹底，同一個漏洞遲早會被同一種手法再利用一次。