客戶傳訊問你，說從 Google 搜尋結果點進官網，卻被跳到一個從沒看過的博弈網站；你把同一個網址複製貼進網址列，畫面卻完全正常，連手機測過一輪也一樣沒事。請熟識的工程師幫忙檢查主機、掃毒外掛也跑過一輪，結果全都是乾淨的，問題好像只在客戶那邊才會發生，自己怎麼測都測不出異狀。
這種自己看到的和外界看到的不一樣的落差，多半不是巧合，而是偽裝（cloaking）在起作用。Google 官方把偽裝定義得很直接，說的是為了操控搜尋排名、誤導使用者，刻意讓一般使用者與搜尋引擎看到不同內容的手法。網站被入侵之後常見的重導，正是這種手法最陰險的一種用法，駭客讓重導只鎖定從 Google 搜尋結果點進來的訪客，或只鎖定手機瀏覽器，管理員自己用電腦直接開網站，自然什麼異狀都看不到。放著不管，輕則排名被拖累，重則被 Google 標成有安全性問題，搜尋結果直接掛上警告標籤。
好消息是，要確認網站有沒有中招不必靠猜，也不用真的假裝成 Google 的伺服器。用 Google 官方開放的工具，加上幾個命令列指令，就能重現 Google 與一般訪客看到的落差。
偽裝重導是什麼？只對搜尋引擎或行動裝置觸發的入侵手法
在「遭入侵的內容」這一大類問題裡，偽裝重導屬於「重新導向」這個子類。駭客把惡意程式碼植入網站，讓部分訪客被導向有害或垃圾資訊網頁，而這種重導往往依照參照網址（referer）、使用者代理程式（User-Agent）或裝置類型而不同，點選 Google 搜尋結果的網址會被導走，直接在瀏覽器貼上同一個網址卻完全沒事。
駭客選這種做法不是隨機，而是刻意利用它拖延被發現的時間。Google Search Console 的官方說明點出，駭客常靠偽裝手法讓網站擁有者難以偵測入侵情況，伺服器會先看這次請求帶著什麼身分資訊，再決定要給哪一個版本的內容，這正是自己怎麼測都測不出異狀的根本原因。換句話說，問題不是網站全部都壞掉，而是一段藏在背景的判斷邏輯出了狀況，管理員自己這一次的請求剛好沒被那段邏輯認定為目標，才會看起來一切正常。常見的判斷依據不出 3 種：User-Agent 字串、referer 來源，以及裝置或地區。
User-Agent 字串是最基本的判斷依據
最陽春的一種做法，是直接檢查請求裡的 User-Agent 字串，判斷這串文字裡有沒有包含 Googlebot 的特徵、或是不是手機瀏覽器常見的字串樣式，符合條件就換一套內容給對方。SEO 顧問 Mike King 整理多種偽裝手法時，把 User Agent Detection 列為最不精密、也最容易被人工檢查揪出的一種，頁面只是單純判斷請求的 user agent 是不是 Googlebot，是的話就回傳不同版本的內容。
正因為判斷依據只有一段文字，而且這段文字是使用者端自己在請求裡宣告的，任何人都能在發送請求時填自己想填的內容。這也是命令列冒充身分測試法之所以能奏效的原因，只要把 User-Agent 換成跟 Googlebot 一樣的字串送出去，遇到只做這種陽春判斷的程式碼，就會被誤認成真正的 Google 爬蟲，回傳跟一般訪客不一樣的內容。
referer 只認得從 Google 點進來的人
第二種常見依據不看你是誰，只看你從哪裡連過來。程式會檢查請求裡的 HTTP 參照網址（referer）是不是 google 這類搜尋引擎網域，是的話才觸發重導；如果直接在網址列貼上同一個網址，或是從書籤點進去，請求裡完全沒有 referer 資訊，自然也不會觸發，這正是管理員自己怎麼測都測不出來的另一個常見原因。
Google 官方在說明裡示範的 JavaScript 重導，就是典型的 referer 判斷，程式先檢查document.referrer是不是符合 google.com，符合才執行window.location跳轉到惡意網站。Mike King 的真實案例也證實同一種機制，他用命令列換上不同的請求標頭測試後發現，只有 referer 來自 google.com/search 時，才會觸發 302 重導到一個仿冒商品的網站，其他情況一律回傳正常內容。
裝置與地區是觸發重導的第三種依據
第三種篩選維度是裝置與地區，只對手機瀏覽器、或只對特定國家與地區的流量觸發重導，因為這類流量對詐騙廣告、博弈網站來說轉換率更高，桌機訪客反而被放過，看到的還是正常版本。這種依據常常不是單獨使用，而是跟前面兩種疊加，例如 referer 是 Google 而且裝置是手機才觸發，測試時如果只驗證了一種條件就下結論說沒事，很容易漏掉真正在運作的那一組組合。
資安業者 Content Guard Pro 分析過一起真實案例，惡意程式碼一次疊加了好幾層條件，先判斷來訪的是不是已登入的管理員，是的話一律給乾淨版本；接著看 referer 是不是搜尋結果頁；再用android|iphone|ipad這類字串比對裝置類型；最後還加了一道節流機制，同一個 IP 在 24 小時內只會觸發一次重導，用 WordPress 內建的set_transient()函式實作。條件疊得越多，一般人只憑感覺測一兩次，就越容易誤判網站沒問題。
Search Console 通常最早洩漏異常的三個位置
在動手用工具重現問題之前，多數人其實不是自己起疑，而是先在 Search Console 看到異狀。偽裝重導不影響一般人肉眼瀏覽，卻會在 Google 端留下 3 種可觀察的痕跡，安全性問題報告、成效報表裡冒出來的異常字詞與地區流量，以及被額外收錄的陌生頁面。定期檢查這 3 處，通常比自己憑感覺懷疑網站是不是被駭了更早發現問題。
安全性問題報告列出的入侵內容分類
Google 官方說明把安全性問題（Security issues）報告分成 3 種類型，遭入侵的內容（Hacked content）、惡意軟體與非自願軟體、社交工程。如果目前沒有安全性問題，這裡會顯示一個綠色勾勾；一旦有問題，報告會標出首次偵測到的日期、簡短描述，以及一份受影響網址的樣本清單，注意是樣本，不是完整清單。
更重要的是，報告會進一步標明遭入侵的內容屬於哪一種型態，Hacked: Code injection（植入程式碼）、Hacked: Content injection（植入內容），或 Hacked: URL injection（新增含垃圾連結的網頁）。偽裝重導多半被歸進植入程式碼這一類，官方對這個型態舉的例子就包含把訪客重導到惡意網站，也是接下來要拆解的重點；先看清楚屬於哪一類，能縮小接下來要查的範圍。
成效報表冒出陌生的搜尋字詞與海外流量
另一個線索藏在成效（Performance）報表裡。如果報表突然冒出一堆跟網站主題完全無關的搜尋字詞，例如博弈、成人或藥品類詞彙，或是平常沒有的海外地區曝光量暴增，代表 Google 已經把某些被植入的隱形頁面或隱形內容納入索引，而且已經開始曝光，即使自己在網站上完全找不到那些頁面，也搜尋不到那些字詞。
這呼應前面提到的植入網頁（Search Console 標記為 Hacked: URL injection）。駭客會在網站裡加入含垃圾資訊或惡意內容的新網頁，通常用來操控搜尋排名或做網路釣魚；現有的網頁可能完全沒有遭入侵的跡象，但那些新增的網頁，對訪客有害，對搜尋排名也是負面的。
用 site 語法揪出你沒有建立過的頁面
不需要任何工具、任何人都能立刻動手做的第一步，是在 Google 搜尋框輸入site:加上自己的網域，直接看 Google 實際收錄了哪些頁面。小型網站可以直接用這個語法看完整清單；網站規模較大時，可以加上關鍵字縮小範圍，例如site:example.com pharmacy只列出含特定垃圾字詞的頁面，或site:example.com/wp-admin/檢查後台目錄底下有沒有不該被收錄的頁面。
這個做法出自 Google 官方針對駭客新增網頁這類問題給的排查建議，不需要登入 Search Console，只要有 Google 搜尋就能查。把跑出來的每個網址跟自己記憶中的網站架構核對一次，凡是說不出來自己什麼時候建立過的頁面，就值得列進後面要重點檢查的名單。
網址檢查工具還原 Google 實際抓取的畫面
用 site 語法找到可疑頁面之後，下一步是看清楚 Google 那一端實際看到的畫面長什麼樣子，這時要靠網址檢查工具（URL Inspection Tool）。它不用寫任何程式碼，直接把 Google 上次抓取那個網址時實際拿到的畫面、HTML 與螢幕截圖攤開給你看，如果駭客的偽裝手法只鎖定 Google 的爬蟲身分，這裡看到的內容就會跟自己瀏覽器看到的不一樣，而且是官方工具跑出來的結果，拿去跟代管商或客戶說明時也更有說服力。
進入這個工具的方式很簡單，在 Search Console 頂端的檢查列直接貼上網址，或是點成效報表裡某個網址旁的檢查圖示。接下來要留意的是它有「已建立索引」與「即時測試」這 2 種檢視模式，以及能從中挖出哪些痕跡。
螢幕截圖還原 Googlebot 看到的實際畫面
檢查網址之後，點「測試線上網址」執行即時測試，完成後點「查看已測試的網頁」，再切到「螢幕截圖」分頁，就能看到 Google-InspectionTool 渲染這個頁面時實際呈現的畫面。官方說明這項功能能顯示 Google-InspectionTool 檢視轉譯後的網頁時所見畫面的螢幕截圖，如果發現任何差異，通常是因為某些資源被禁止讓 Google-InspectionTool 存取。
如果這張截圖跟自己瀏覽器打開看到的內容不一樣，例如截圖裡出現自己從沒放過的文字、連結，或整個畫面根本文不對題，就是偽裝已經發生的直接視覺證據。這個分頁只有在測試成功時才會提供內容，測試失敗代表要先排除其他阻擋因素，才能拿到這張截圖。
已檢索的 HTML 與資源清單藏著被動手腳的線索
比截圖更深一層的檢查，是同一個頁面點「查看已檢索的網頁」後再點「更多資訊」，這裡可以看到當時的 HTTP 要求與回應（包含標頭）、Google 實際拿到的 HTML 原始碼，以及頁面載入了哪些資源。把這份 HTML 跟自己瀏覽器檢視原始碼看到的版本逐字比對，只要多出一段自己沒寫過的<script>、一個隱藏連結，就是偽裝的鐵證。
Content Guard Pro 的技術分析也把這一步定位成最可靠、不需要任何額外工具的診斷方式，對受影響頁面跑一次即時測試，拿到的是來自真正 Google IP、真正爬蟲身分請求得到的渲染後 HTML，如果裡面出現自己瀏覽器看不到的 script 標籤或重導邏輯，就已經確認偽裝重導存在，不必自己想辦法假冒 Google 的 IP。
即時測試與已建立索引版本經常出現落差
前面提到的 2 種檢視模式有什麼差異，分清楚才不會看錯資料、下錯結論。「已建立索引」顯示的是 Google 上次實際抓取並收錄的舊版本，官方說明寫得很明白，系統顯示的搜尋結果來自最近建立索引的版本，不是即時結果；「即時測試」則是這次點擊當下重新抓一次的最新結果，官方形容它會即時擷取網址並進行檢測。
兩者出現落差是正常現象，例如剛清完毒，已索引版本可能還停在中毒畫面，即時測試才會顯示乾淨版本。所以要判斷現在乾不乾淨看即時測試，要判斷 Google 收錄的是不是中毒版本則要看已建立索引那份，拿錯版本去下結論，常常是誤判的起點。
用 cURL 冒充 Googlebot 重新請求同一個網址
網址檢查工具很好用，但它要等 Google 重新抓取，不一定馬上就能重現問題。更貼近自己動手重現的做法，是直接用命令列工具換上不同的身分，User-Agent、referer，去請求同一個網址，比對回應內容有沒有不同。這正是 Google 官方文件自己教的排查方法，而且附了完整的範例指令，任何人都可以照著在自己電腦上跑一次。
用cURL而不是直接開瀏覽器測試，原因很單純，cURL能精準控制這次請求要帶哪些身分資訊，不會像瀏覽器一樣真的把可能有害的內容整個載入渲染出來。基本語法很簡單，先用curl -I只看回應標頭，能立刻看到有沒有 301 或 302 重導、以及Location標頭指向哪個網域；確認有異狀再用curl -i把標頭跟內容一起印出來細看。Google 官方也提醒，如果第一次沒測出異狀，可以換不同的 referer 位址，例如其他大型網站或不同搜尋引擎的連結，多試幾組再下結論。
換上 Googlebot 的 User-Agent 送出請求
最基本的一組測試，是只換掉 User-Agent，其他都維持原樣，看回應跟平常瀏覽器拿到的內容或狀態碼是不是不一樣。Google 官方文件列出桌機版 Googlebot 目前實際會帶的 User-Agent 是Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36（W.X.Y.Z 是隨版本變動的 Chrome 版本號）；不過多數偽裝判斷邏輯只做Googlebot這個關鍵字的簡易比對，Mike King 示範測試時用的是精簡版字串，對應指令是curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)" https://www.site.com/，一樣能觸發只看字串裡有沒有Googlebot的陽春判斷。
如果這組測試就已經跑出跟正常瀏覽不一樣的內容或重導，代表對方的判斷邏輯還停留在只看 User-Agent 字串這種最陽春的層級，不用再往下測其他組合，直接可以確認有偽裝重導在運作。
加上 Google 搜尋結果的 referer 重現點擊
如果只換 User-Agent 沒測出異狀，下一步是在原本的基礎上再加一個--referer參數，指向 google.com，模擬使用者從 Google 搜尋結果點連結進來這個情境。Mike King 提供的對應指令是curl --referer https://www.google.com/search https://www.site.com/。很多偽裝重導其實只認 referer、根本不特別驗證 User-Agent 字串，這組測試常常才是真正抓到問題的關鍵組合。
他也提醒，可以在 Chrome 開發人員工具的「Network Conditions」裡把 User-Agent 換成 Googlebot 字串，並勾選 Network 分頁的「Preserve Log」保留重導紀錄再觀察，重導往往發生得非常快，沒有勾選這個選項，常常一眨眼就看不到中間跳轉了幾層。
換成行動裝置的 User-Agent 測試手機限定重導
如果前兩組測試都沒有異狀，別急著認定網站乾淨。前面提到只鎖定行動裝置的那類偽裝，桌機版 User-Agent 無論怎麼測都不會被觸發，一定要換成手機版字串才測得出來。Google 官方文件列出的智慧型手機版 Googlebot User-Agent 是Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)。
比較保險的做法，是把桌機 UA、Googlebot 桌機版、Googlebot 手機版、Googlebot 手機版加上 Google referer 這 4 種組合都各測一次，互相比對結果，而不是隨便測一組沒異狀就下結論說沒問題。畢竟前面已經看到，不同判斷依據可以疊加使用，少測一種組合，就有可能漏掉真正在運作的那一段邏輯。
User-Agent 換了卻沒用，對方連 IP 網段都驗證
如果前面 4 組cURL測試全部都沒測出異狀，先別急著鬆一口氣，這不代表網站一定沒事，有可能是對方的判斷邏輯比想像中精密，已經不只看 User-Agent 字串，而是直接驗證這次請求來源的 IP 是不是真的落在 Google 的爬蟲網段裡。測不出來其實有 2 種完全不同的意思，一種是真的乾淨，另一種是自己的測試方法還不夠格騙過對方，兩者接下來該做的事完全不一樣。
資安團隊 Sucuri 在 2026 年 1 月發布的一份技術分析，拆解過一支被植入 WordPress 網站index.php裡的偽裝程式碼，它不是單純比對 User-Agent 字串，而是內建一份 Google 自治系統編號（ASN）的 IP 網段清單，採用 CIDR 格式，用位元運算精確計算來源 IP 是不是真的落在 Google 網段內，而且完整支援 IPv6。Sucuri 的分析點出重點，多數攻擊者只靠 User-Agent 過濾機器人，這支程式碼的技術細節精細得多；驗證通過才會即時用 cURL 去外部抓取惡意內容並印在頁面上冒充原生內容，驗證失敗則記一筆偵測到假冒 Googlebot 的錯誤紀錄，照樣導去正常首頁。資安業者 Content Guard Pro 分析同類手法時講得更直白，curl -A "Googlebot/2.1"指令觸發不了重導，不是指令下錯，而是這套程式根本沒在檢查 UA 字串，它在檢查的是 IP 位址是不是真的落在 Google 爬蟲網段內；整天從一般家用網路送出一模一樣的 Googlebot User-Agent 字串，程式照樣把你當成一般人，給你看乾淨版本，唯一會觸發重導的是通過驗證的真正爬蟲 IP，而這一點沒辦法從瀏覽器或一般主機造假出來。
驗證真實 IP 網段比單純比對 UA 字串更難被瞞過
為什麼這一類判斷比單純比對 UA 難破解？原理不難懂，User-Agent 字串是使用者端自己在請求裡宣告的一段文字，任何人都能在發送請求時填自己想填的內容；IP 位址則是這次連線本身的來源，一般使用者的電腦或家用、公司網路，沒有辦法讓對方誤判成 Google 資料中心的 IP。前面幾組cURL測試能奏效，靠的正是判斷依據只看得懂宣告的文字這個弱點，一旦對方換成驗證連線本身的來源，這個弱點就不存在了。
換句話說，判斷依據從你自稱是誰，進化成你實際上是從哪裡連過來的，難度完全不同一個層級。一般人不太可能取得一台落在 Google 資料中心網段裡的主機去發送請求，這也是為什麼遇到這種等級的偽裝，得換一個完全不同的方向去查，而不是繼續換更多組cURL指令碰運氣。
伺服器存取紀錄比對出真正的 Googlebot 請求
既然沒辦法從自己的電腦偽造出一個真的 Google IP，方向就要換成回頭查主機的存取紀錄（access log）。把真正 Googlebot 的造訪紀錄挑出來，也就是 User-Agent 含 Googlebot 字串的那些請求，看它們實際拿到的 HTTP 狀態碼是不是 301 或 302，回應內容的長度跟正常頁面比起來是不是明顯不同。這一步需要有主機或代管的存取權限，是這整套診斷邏輯裡自己測不出來就往更底層查的最後一站。
這也自然銜接回前面網址檢查工具那一節，網址檢查工具的即時測試結果，本質上就是 Google 官方幫你做了這裡想做卻做不到的事，用一個真正的 Google 身分去請求一次同一個網址，再把結果攤開給你看。如果連存取紀錄都調不到，或看不出頭緒，回到網址檢查工具重新確認一次，通常是最快能拿到答案的路。
偽裝重導最常被藏進的檔案與資料庫欄位
前面幾節證明了重導確實存在，接下來要弄清楚的是，那段判斷邏輯躲在哪裡。以下是 WordPress 網站裡最常被動手腳的幾個位置，從最容易想到的核心檔案，到掃毒外掛完全掃不到的資料庫欄位都有，這一節只負責指出位置、示範怎麼用唯讀的方式檢查確認，不涉及後續清除或修復的完整操作。
index.php 裡被植入的重導判斷邏輯
Sucuri 公開分析過一起真實案例，攻擊者直接改寫 WordPress 根目錄的index.php，讓它變成一支先判斷訪客身分、再決定載入哪個版本的守門程式。判斷通過，就用 cURL 去外部抓惡意內容印出來冒充原生內容；判斷不通過，就照原本流程繼續。程式碼裡會呼叫require_once __DIR__ . '/wp-load.php'，把 WordPress 環境開機起來，取得資料庫與網站設定的存取權，最後才引入wp-blog-header.php，這支檔案原本就是正常index.php執行到最後一定會用到的檔案。
也就是說，外觀上這支被動過手腳的index.php執行到最後，一般情況下仍然會把正常網站跑起來，惡意邏輯只是插在最前面。這正是多數時候肉眼瀏覽完全看不出問題的原因，程式碼並沒有讓網站整個壞掉，只是在判斷通過的那一次請求裡，插隊做了別的事。
.htaccess、主題 functions.php 裡的重導判斷
另一類常見的藏匿位置在伺服器層級，不用碰任何 PHP 程式碼。Apache 的.htaccess或httpd.conf可以直接對特定網址下重導規則，Google 官方文件把這種手法稱為 Header 重導，回應 301 狀態碼並帶Location標頭指向惡意網站。主題的functions.php或某個外掛檔案裡，也可能被塞進一段依 referer 或 User-Agent 判斷的 JavaScript 或 PHP 重導邏輯，前面提到的document.referrer判斷範例就是這一類。
跟核心檔案裡的注入相比，這類設定檔與主題檔案的改動，通常更容易在主題或外掛更新時被覆蓋掉，也更容易被基本的檔案掃描工具揪出來，這也是下面資料庫裡的版本反而更棘手的原因。
資料庫序列化選項是檔案掃描工具的死角
最容易被忽略的一點是，惡意的重導邏輯不一定寫在任何檔案裡。它可能直接以一筆序列化資料存在 WordPress 資料庫的wp_options資料表，例如偽裝成某個外掛會用到的選項名稱；也可能存在文章或頁面建構工具用來存版面資料的wp_postmeta欄位裡。這類注入完全不動任何檔案，一般以掃描檔案異動為主的防護外掛天生就掃不到。
Content Guard Pro 分析過的一起真實案例裡，惡意 payload 完整存在wp_options資料表一筆序列化選項中，對所有檔案層掃描工具來說完全隱形，只有在偵測到 Googlebot IP、或符合條件的手機訪客首次造訪時才會觸發。頁面建構外掛把版面資料以序列化 JSON 或 PHP 物件的形式存進wp_postmeta，同樣是檔案層掃描工具碰不到的位置。要確認乾不乾淨，得直接對資料庫做唯讀查詢，找出內容裡混著<script>、外部網域連結，或base64_decode這類可疑字樣的欄位，而不是只看檔案有沒有被改過。
eval 與 base64_decode 是混淆關鍵字
這裡整理一份具體、可以直接拿去搜尋比對的關鍵字清單。不管惡意程式碼藏在檔案裡還是資料庫裡，為了不讓人一眼看懂，通常會用編碼過的寫法包起來，例如eval(base64_decode("d2luZG93LmxvY2F0aW9uPScvL2dvb2dsZS5jb20nOw=="));，這段經過base64_decode解碼之後，其實就是一段把頁面導去 Google 的程式碼。
Google 官方文件建議，在回應內容與網站程式碼裡搜尋可疑字詞時，實用的搜尋字詞包括search、eval、base64_decode與unescape。看到程式碼或資料庫欄位裡出現這幾個字，就算一時看不懂完整邏輯，也該提高警覺，進一步確認這段內容是不是自己或安裝的外掛主動加上去的，還是被人偷偷塞進去的。
清除後用同一套工具確認 Google 畫面已經乾淨
處理完問題之後，不能只憑自己瀏覽器看起來正常就結案。偽裝的本質原本就是自己看到的和 Google 看到的不一樣，清除完的驗收，理所當然也要換成 Google 的角度去看，不能再靠肉眼判斷。做法很直接，把前面用來證明中招的那幾套方法原封不動再跑一次，確認 Google 那一端看到的也已經是乾淨版本，才算真正處理完，也才有底氣進行最後一步，也就是跟 Google 回報已經修好。
即時測試確認渲染後的畫面已經正常
回到網址檢查工具，對同一批曾經異常的網址重新執行「測試線上網址」的即時測試，這次應該要在螢幕截圖與已檢索的 HTML 裡都看不到任何自己沒放過的內容或連結。Content Guard Pro 的建議收尾動作講得很直接，清乾淨之後，重新打開 Search Console 的網址檢查工具，對受影響的網址再跑一次即時測試，如果渲染後的 HTML 裡看不到外來的 script 標籤，而且頁面畫面正確，拿到的才是重導已經真的消失的確認，而不是暫時被壓下去而已。
如果測試結果跟自己瀏覽器看到的版本一致，才代表 Google 端也已經看不到偽裝的那一面；如果截圖或 HTML 裡還留著任何一絲異常，代表清除工作還沒做完整，得回到前面列的幾個藏匿位置繼續查，而不是急著申請複查。
重新送出的 cURL 請求應該回到原本內容
接著把前面用過的幾組cURL指令原封不動再送一次，桌機版 Googlebot、加上 referer、手機版，每一組都要測。這一次每一組都應該回傳跟正常訪客一樣的內容與 200 狀態碼，不該再出現任何 301 或 302 重導，也不該有陌生的回應內容。
如果其中任何一組還是被導走，代表清除得不夠完整，得回到藏進檔案與資料庫欄位那一節列出的幾個位置繼續查，尤其是資料庫裡的序列化選項，這正是最容易被漏掉、卻也最常見殘留惡意邏輯的地方。
安全性複查申請送出後的等待與後續
如果這個網站曾經被 Google 標成有安全性問題，光是自己測出來乾淨還不夠，搜尋結果裡的警告標籤，需要透過「要求複查」才會解除。Google 官方說明複查通常需要幾天到幾週不等的時間，過程中會透過電子郵件通知進度；而且好的複查申請要做到三件事，說明網站上確切的品質問題出在哪裡、描述採取了哪些修正步驟、記錄修正後的結果，三件事缺一不可，不是隨便按下申請按鈕就會過。
官方也特別提醒，在收到最終決定前不要重複送出申請，太早重複送件反而可能被視為累犯，拉長下一次審核所需的時間。如果網站沒有被標記過安全性問題，只是單純被成效報表或site:語法發現異常，就不需要走複查申請這一步，前面兩節的重測結果就是最終確認。
偽裝重導最麻煩的地方，從頭到尾都是同一件事，你和 Google 看到的是兩個版本。查證的邏輯也一路圍繞著這件事，用官方工具、命令列指令，親自站到 Google 的角度去看一次自己的網站，而不是靠肉眼判斷看起來正常。等到自己的瀏覽器、命令列測試、網址檢查工具三方看到的都是同一個乾淨版本，才真正代表這件事處理完了。