網站被黑後首小時應先確認甚麼？
搜尋公司名稱時突然見到日文購物頁、藥物字眼或陌生的登入畫面，首先不要把它當成普通SEO波動。網站被黑可能同時影響訪客安全、訂單資料、搜尋結果及管理員帳戶。先由指定負責人記下發現時間、原本網址、異常頁的截圖、瀏覽器警告及報告者聯絡方法；另一人核對託管商、網站開發者、網域與付款負責人。把事故分為「頁面遭竄改」、「訪客被轉址」、「後台無法登入」和「已知資料外洩」等可觀察情況，未知的部分寫未知，不要靠猜測作公告。
用不含管理權限的裝置，查看首頁、代表性的服務頁、聯絡表單和搜尋結果；暫勿在可疑頁面輸入密碼。Google的安全性問題報告可能列出已偵測的頁面與問題類型，但它不是全站乾淨與否的證明。把報告中的樣本網址、伺服器時間及首次通知一同保存，並向託管商查詢異常登入、檔案改動和流量峰值。若網站會處理付款或個人資料，應即時交由懂事故處理的人評估影響、通報與保留證據需要。
首小時由誰拍板？
指定一名事故協調人決定暫停哪些功能，技術人員負責保存快照與隔離，營運同事負責客戶查詢和廣告入口。若公司只有一人維護網站，也要記錄每項操作的時間、執行者、原因及結果。這份時間線既讓接手者明白發生甚麼，也避免一邊清除檔案、一邊由另一位同事恢復舊版，把可疑內容重新帶回線上。
先保存原始異常畫面、樣本網址、系統日誌、帳戶清單與備份時間；其後才安排隔離和修復。若訪客仍可能接觸危險頁面，應由技術負責人立即採取最小必要的阻截措施，同時記下改動。
如何隔離風險並保留檔案與存取證據？
「網站暫停」不是一個通用按鈕。被植入惡意轉址時，可能要先阻擋危險內容及暫停受影響的表單；只有一個產品頁出問題時，未必需要刪掉全部網站。由託管商與安全人員判斷要否啟用乾淨的維護頁、暫停寫入、限制後台登入或隔離主機。對外訊息用已核實的事實說明服務暫停及替代聯絡方法，不應在未查明前宣布「資料安全」或「完全沒有影響」。
保存檔案副本、資料庫快照、存取與錯誤日誌、部署紀錄、管理員及外掛清單，並記明取得時間與保存位置。現有備份未必可信，尤其是備份時間可能落在入侵之後；不要覆蓋唯一一份可疑原始資料。需要刑事、保險或個人資料層面處理時，請合資格專業人士決定證據保全與通知流程。日常網站技術維護的需求範圍與緊急鑑證工作並非同一個報價項目，應先界定由誰承擔。
網站下線後廣告怎樣處理？
檢查目前仍在引流的搜尋廣告、社交貼文、商家資料和QR碼。已知入口通往危險頁面時先暫停相關導流，給客服一個可運作的接客方法，並保留投放截圖。不要把陌生外站設成暫時落地頁，也不要用未驗證的新網址收集客人資料；這會使事故期間的信任問題變得更難解釋。對外回覆要一致，直到網站功能和安全狀態獲核實。
首日怎樣輪替密碼、金鑰及管理權限？
先盤點網域註冊商、DNS、寄存、CMS、資料庫、備份、CDN、電郵、Search Console、廣告及分析工具各由哪個帳戶持有。若只改網站管理員密碼，入侵者仍可能透過寄存控制台、外掛金鑰或已被盜的電郵信箱回來。從可信裝置及乾淨網絡處理最高權限帳戶，優先撤銷陌生管理員、未識別的工作階段與不必要的API憑證，逐項輪替密碼並啟用多重驗證。交由有權人執行，避免在事故群組直接傳送新密碼。
每一項權限都要記錄原持有人、現在持有人及撤銷證據。代理商離職帳戶、共用登入及無人知曉用途的自動化憑證尤其值得檢查。若不知道誰有權改DNS，可先依確認各項網站資產管理權的項目列名單，再向相應供應商核對。完成一次密碼更換不代表沒有惡意程式留在伺服器；權限恢復及系統清理需要兩條工作線並行，但變動要有先後記錄。
誰應收到新權限？
只給當下修復需要的最低權限，並約定有效期。開發者需要處理檔案時，不代表需要永久持有網域註冊商的主帳戶；客服需要回答客人，也不需要看到整份網站備份。事故後再由資產擁有人覆核所有臨時帳戶、第三方接駁及備援電郵，免得為求快而留下新的入口。
備份、後門與入侵入口如何一併檢查？
「把昨天備份還原」有時會帶回同一個問題。先比較數份備份的建立時間、檔案變動及已知正常畫面，再由技術負責人選可信的復原點；同時檢查核心程式、主題、外掛、上傳目錄、資料庫內容與排程任務。若只清掉搜尋結果看得見的一頁，而不處理造成寫入的薄弱權限或過期組件，重新上線後仍可能再被改動。需要深層檢測的個案交由有經驗的保安專業人員，本文的清單不能代替鑑證。
核對供應商修補紀錄、外掛來源和部署權限；不要在事故中盲目更新所有元件，先保存證據並測試相容性。由乾淨環境重新部署、檢查前後台版本，測試首頁、服務頁、查詢功能與登入入口。網站事故通常牽涉託管、開發和營運的責任界面，核對維護及修復工作界線可幫助整理原有合同內包括甚麼、另需聘誰處理，以及修復後由誰長期監察。
怎樣證明不再出現同一症狀？
建立一張「入侵前症狀—修復操作—重新測試」對照表，涵蓋原始異常網址、登出後的訪客畫面、手機瀏覽與表單投遞。若找不到初始入口，誠實記錄未確認的風險，增加監測，不要為了趕上線把「沒有再看到」寫成「已查明原因」。保留最少一名可聯絡的責任人處理重新出現的告警。
日文或藥物SEO spam網址怎樣整理？
遭入侵的搜尋頁面可表現為日文標題、藥物字詞、奇怪的查詢參數，或只有搜尋引擎看到的內容。先匯出Search Console樣本、搜尋結果及伺服器路徑，把每條網址標註為「真實業務頁」、「被改內容」、「憑空生成」或「未能確認」。少量樣本不能代表全部；查看網址規律、目錄分布及最近新增頁，但不要把正常舊頁因標題相似而大量刪掉。
修好來源後，原本不存在的惡意頁面可回應恰當的不存在狀態；被竄改的有效頁面則應恢復真實內容。301轉址、robots封鎖和移除工具各有用途，不能當作清除惡意程式的替代品。尤其不要將所有垃圾網址轉到首頁，讓訪客及搜尋引擎繼續遇到與預期不符的內容。網站可用性與索引檢查可作修復後逐頁驗證的起點；先看伺服器實際回應，再看搜尋結果如何逐步更新。
被收錄的惡意標題會即日消失嗎？
搜尋引擎需要重新抓取與處理頁面，顯示變化通常不與伺服器改動同步。記錄修復前後的網址回應、頁面內容與報告日期，按個別問題使用官方流程；不要答應客戶某一天必定清空所有搜尋片段。若網站警告仍在，先回到安全問題根源，而不是把時間全花在提交重新索引。
Search Console安全性問題與覆審如何跟進？
以資產擁有人登入Search Console，核對是否真有「安全性問題」報告與具體樣本，而不是只根據外部截圖判斷。Google會列出它偵測到的安全問題類型；清理受影響內容及修補入口後，再按報告內流程申請審核。申請說明應具體列出發現了甚麼、清除了哪些範圍、如何堵塞原因和如何避免再次發生；未清乾淨就反覆送審，既浪費時間亦無助釐清問題。
把安全性問題、人工處置和一般索引覆蓋分開看：三者的成因及申訴入口可能不同。若Search Console沒有警告，也不代表主機一定安全；需繼續核對檔案、日誌和前台。網站主事人保留審核提交日期、提交版本、Google回覆及網站當時狀態。對外只報告可證明的進度，例如「惡意頁面已在伺服器移除、審核待覆」，不宣稱搜尋排名已恢復。
請代理代提交覆審是否可以？
可以委託具權限的專業人員整理資料，但資產擁有人應看過文字和證據，明白申請涵蓋的問題範圍。安全狀態不是廣告代理的單方承諾，必要時由網站技術及資安人員共同簽核。請保留管理權，不為了處理一張報告而交出公司主要電郵登入資訊。
首星期如何驗證修復並恢復監察？
把上線視為一系列可撤回的核對。逐日看是否再次出現陌生管理員、檔案改動、可疑流量和新生垃圾網址；抽查桌面與手機、不同入口及登入前後內容。確認表單可以送達正確收件人、WhatsApp按鈕指向公司號碼、電話可撥通、購物流程及付款服務按實際業務需要正常運作。事故前後量測設定可能變了，應依復原後重新驗證查詢功能的測試方法重新做一遍真實但不包含敏感資料的查詢。
只在安全及接客能力達標後，逐步恢復暫停的廣告和商家入口。每一步記錄上線時間、責任人、抽查結果及再次停用的門檻；例如一旦又見陌生轉址，立即由技術負責人阻止受影響入口。將正常搜尋點擊、垃圾網址曝光及查詢量分開畫時間線。網站事故前後流量可能受暫停廣告、季節與搜尋系統更新共同影響，不能把單一曲線直接歸因於清理成功。
客人資料曾經受影響怎樣處理？
若有跡象顯示個人資料、付款資料或登入憑證可能外洩，停止自行推斷影響範圍，交由適當的保安與法律專業人員核對事實及通知責任。對內保存可驗證證據，對外訂一位發言人；即使結論仍未確定，也要有客服回答的更新時間和渠道。避免在公開社交帖文貼出包含客戶資料的日誌或錯誤截圖。
哪些預防措施應交由日常維護接手？
事故結束後，盤點各層負責人、最小權限、登入保護、程式更新、備份恢復演練及異常告警。備份「有檔案」與「可以在乾淨環境恢復」是兩回事，應定期抽樣還原測試，檢查資料庫和上傳檔是否齊全。訂一份簡短的值班表，確保週末也有人收到主機與Search Console通知，並知道何時找託管商或保安專業人員。
Slay Marketing的保存量測紀錄再作改動原則，同樣適合修復後的搜尋與查詢檢查，但事故鑑證仍要交給相應專家。新網站或改版時預先約定網域和備份歸屬、緊急停用權、修復回報格式，能減少下次事故中的爭拗。有需要討論網站內容和接客入口，可先準備錯誤畫面與影響範圍；涉及登入憑證或客戶資料時，請走安全渠道，不要上載到普通聯絡表單。
維護合同要列哪些事故邊界？
不少商戶以為每月繳付寄存費，就等於供應商會負責監察、安全調查、內容還原、法律通知和搜尋覆審。這些任務可能由不同單位承擔。逐欄核對現行合同內的備份頻率、保留日數、恢復測試、緊急聯絡時間、事件記錄可取範圍及額外收費條件；沒有寫明的部分標作「待商議」。即使原供應商肯協助，也先說清誰保留原始資料、誰有權改DNS、誰在正式環境批准重開，以免大家都等對方作最後決定。
若外判團隊同時持有寄存、網站、域名及分析工具，請商戶要求分開記錄主帳戶與操作帳戶。平日每季檢查權限，比到事故那天才找前員工或供應商拿回登入更可靠。對於多個網站共用一套主機的公司，盤點另一個網站會否也有相同元件或登入，因為只清理最先見到垃圾標題的網域，未必能阻止問題沿相同配置再次出現。
首小時、首日、首星期如何分工？
| 時段 | 要先拿到的證據 | 可以作的決定 | 暫不宣稱 |
|---|---|---|---|
| 首小時 | 異常網址、畫面、通知、日誌位置 | 指定負責人、阻截危險入口 | 已找出入侵原因 |
| 首日 | 帳戶、備份、改動與權限清單 | 隔離、輪替、專業檢查 | 換密碼等於全站乾淨 |
| 首星期 | 各功能重測與告警記錄 | 按核對結果逐步重開 | 排名會於指定日恢復 |
這張表是管理時間的工具，不代表每宗事故都可在一天內找出入侵點。一旦涉及正在流出的資料，處置速度應按實際危害提早；反過來，搜尋片段暫未更新而伺服器已安全，也毋須為了「三天內消失」胡亂刪站。每天留一段交接摘要，交代已證實與未證實事項，令夜班同事可以沿同一份紀錄工作。
哪些畫面可以交給技術人員？
給技術人員的截圖應包含完整網址、看到問題的本地時間、裝置與瀏覽器大致資料，並告訴對方是登入後還是一般訪客看到。不要為了證明問題，把含真實客戶地址和電話的原始後台截圖放到公開聊天群組；先用受控方式交給有權處理的人。若異常只在某些地區或搜尋關鍵字出現，描述重現條件即可，避免叫多名同事反覆打開可能有害的連結。
在未有修復團隊進場前，營運同事可整理廣告落地頁、商家資料的網站按鈕、電郵簽名檔及自動回覆中引用的網址，讓技術人員知道有哪些公開入口。先處理明顯會把新訪客送到危險頁面的入口；不必因某篇舊文章搜尋結果出現異常，就無差別關掉所有客戶聯絡渠道。真正的優先次序取決於訪客風險、資料處理和現有替代服務。
修復後如何看懂搜尋數字？
把搜尋報告分成三欄：原來正常頁的曝光與點擊、異常垃圾頁的樣本、以及修復後新增或復發的異常。垃圾頁在搜尋報告消失的時間、正常頁曝光恢復的時間與客人重新查詢的時間，不一定相同；也可能同期有廣告停投或節日低谷。記錄這些背景，讓商戶不會誤把流量一時增加當成所有安全問題已解決，也不會因一次下降便否定技術人員的修復證據。
若搜尋結果仍顯示過時標題，但網址現在已回應乾淨內容，先保存目前伺服器的回應與可見頁面，等待搜尋引擎按自身節奏重新處理。若用不同裝置看到不同內容，則應繼續請專業人員查條件式轉址或快取問題，不能只說「Google未更新」。每次抽查的日期、URL及判斷理由都值得放在同一張表，對方交接時才可以真正跟進。
復原的「完成」由誰簽收？
技術層可以檢查元件、存取權限和可疑程式；營運層應驗證產品頁、表單及客服；資產擁有人核對網域、備份和報告主帳戶仍在公司手上。若涉及法律或保險責任，另按相關專業要求處理。三者都通過才在內部紀錄標記完成，並註明仍要監察的風險及下次檢查日。把「重新可用」與「事故原因已全面查明」分開，讓管理層在證據不足時仍能作有界線的營運決定。
假如公司最終需要整站重建，舊網站的內容、轉址、客戶通知和搜尋索引也要由相應人員簽收。新站看起來漂亮不等於舊網址已妥善處理，舊站有內容備份不等於可安全再放上線。列出代表性的正常頁與異常頁，分別確定其目標狀態和驗收畫面，避免把復原項目簡化成「網站能開」。
下次演練可以怎樣安排？
毋須真的讓網站故障才可練習。每半年用一個虛構情境，例如週五下午有客人說網站跳轉，讓同事用清單找出域名擁有人、託管商緊急聯絡、可用備份、廣告停投負責人與對外客服模板。只演練找資料和決策，不接觸真實個資，也不修改正式站。若十多分鐘內找不到一位負責人或關鍵帳戶，就把那項缺口列入日常維護的下一張工單。
演練後將聯絡表、權限表和備份測試結果存於限制存取的公司位置，指定更新人與日期。新同事上任或代理合約轉換時重核一次；承包商如已停止合作，撤銷其權限並確認接手者仍能下載自己的網站資料。這些看似行政的細節，在事故首小時往往決定能否迅速隔離問題。
如網站靠外部供應商維護，如何避免反覆轉介？
事故協調人可做一張聯絡表，列出寄存商、域名商、網站開發、廣告代理與內部客服各可處理甚麼，並附工單編號及回覆時間。寄存商說檔案有異常，開發者要知道異常清單和伺服器時間；廣告代理說落地頁有問題，技術人員要得到具體網址和截圖。要求每一方把已做操作寫回同一份事故紀錄，避免下一位又從零開始查，甚至把別人的修復步驟撤銷。
如果不同供應商對問題範圍意見不一致，由公司資產擁有人召集簡短交接，先確認訪客風險、證據位置與誰有權改正式站，再決定各自的工作。對應急服務是否收費、能否取得完整備份及修復交付格式，都應以書面核對。不要把保安責任默認交給只負責撰寫內容或投放廣告的團隊，亦不要讓網站供應商在未確認前代公司向客人作完整安全承諾。
修復紀錄要保留多久？
保留期限視乎公司資料政策、合同與個案義務，不能由一篇營銷文章代你訂死。至少把重要時間線、異常樣本、已授權的修復操作、權限變動與對外通知集中在受控位置，並指定誰能讀取及何時複查。不再需要的敏感副本應按公司政策妥善處理；公開報告只寫必要進度，不把可重現漏洞的細節或客戶私隱當成案例素材。
網站事故復原的八個問題
只是搜尋結果有日文，網站現在看起來正常，可以不處理嗎？
不應只憑首頁正常就排除風險，因為陌生頁面可能只出現在特定網址或時間。保存樣本、查伺服器和Search Console，再由技術人員判斷是否遭植入內容。
第一時間應否把整個網站刪掉重建？
先阻止訪客接觸明顯危險內容並保存證據，再決定隔離及重建範圍。立即刪除唯一的檔案與日誌，可能令入侵原因、受影響資料及日後覆審難以查明。
有昨晚備份是否一定可以安全還原？
備份建立於事故發現之前，不代表入侵尚未發生。應比較多個時間點並在乾淨環境驗證檔案、資料庫及可疑管理權限，才安排復原。
換掉CMS密碼就代表後門已被清除嗎？
密碼輪替只處理部分帳戶風險，主機、外掛、資料庫及其他登入仍可能有問題。應連同入侵入口、持續執行的可疑程式及臨時權限一併查核。
Search Console沒有報警是否就毋須檢查？
安全性問題報告列的是Google已偵測到的例子，不是全面的伺服器安全檢驗。前台症狀、主機日誌及管理員異常仍需要獨立排查，必要時找保安人員。
申請Google覆審會立即恢復排名嗎？
覆審針對報告所列安全問題，結果和時間不能預先保證。頁面重新抓取、搜尋片段更新與原本流量變化也可能各有速度，請分開記錄。
公司應如何回答正在查詢的客人？
說明已確認的服務狀態、可用的替代渠道及下次更新時間。不要在未調查完成前推斷資料外洩與否，涉及敏感資料時請循合適的專業程序處理。
甚麼時候可以恢復廣告導流？
先核實入口頁安全、表單與電話可用，以及內部有人接單，才小量重開並持續抽查。若惡意轉址或警告再次出現，依預定門檻暫停受影響導流。
