Sitemap 卡「無法擷取」三個月？修了四輪 XML 都沒用，最後把它搬到 Cloudflare Worker 才過關
今天打開 Search Console，看到這一行： 1/sitemap.xml 2026年6月8日 2026年6月11日 成功 612 狀態「成功」，系統探索到的網頁 612。我盯著它看了幾秒，因為文章也累積到一些數量了，想著要讓Google搜尋能搜尋到，結果到現在，這一欄一直是紅色的「無法擷取」。整整三個月，Google 連我的 sitemap 都不願意讀，全站文章只有首頁被索引。 最後解決問題的那一步，跟 sitemap 的內容一點關係都沒有。這篇把整個排查過程寫下來，包含三次「修對了東西但沒解決問題」的彎路——如果你的 GitHub Pages 部落格也卡在這個狀態，也許可以少走幾步。 問題長什麼樣我的部落格是 Hexo 生成、部署在 GitHub Pages（kyosora.github.io）。三月中建站時把 sitemap.xml 提交到 Search Console，狀態顯示「無法擷取」（Couldn't fetch）。 當時想說剛建站，Google 需要時間。結果這個狀態凍結了快三個月，期間「已送出」日期一直停在 3 月 17 日，系統...
IIS 網站被植入惡意轉址：用 Google Search Console 驗證擁有權與清查後門
先搞清楚：你遇到的多半不是「DNS 污染」訪客連到你的站，結果被導去陌生的廣告頁；Google 搜尋結果裡你的網頁掛著一堆藥品或博弈關鍵字；你打開首頁原始碼，發現 <head> 多了一段看不懂的 <script>。第一個冒出來的念頭通常是「我被 DNS 污染了」。 但這兩件事發生的地方完全不同，搞錯方向會白忙一場。 DNS 快取污染（DNS cache poisoning / spoofing）發生在 DNS 解析器，不在你的伺服器上。 攻擊者往遞迴解析器塞假的解析結果，讓所有用到那台解析器的人把你的網域解析到攻擊者的 IP。受害的是解析層，動到的是別人家的快取，你改自己網站的 web.config、清 wwwroot、封鎖 .php，一點用都沒有，因為惡意內容根本不是從你的主機送出去的。這類攻擊通常範圍很大（一台 ISP 解析器可能服務上百萬人），而且你在自己機器上 nslookup 出來的 A 記錄往往是正常的。 如果出現的症狀是「首頁原始碼被塞了東西」「wwwroot 多出沒見過的 .php / .aspx 檔」「IIS 記錄檔有可疑的 POST」，...
