“已發現但未抓取”是搜尋蜘蛛在日誌和站長平台里常见的一種中間狀態：它從入口頁的連結知道了目标 URL 存在，却没有真正去請求這個地址。入口頁能做的只是让連結更容易被發現，並不决定蜘蛛什么时候来抓。理解這一点，排查方向才不會跑偏。
先把几種狀態分開看
很多誤判来自把不同狀態混為一谈。
- 已發現、未抓取：連結被解析到，URL 進入待抓队列，但還没有發出請求。
- 已抓取、未索引：蜘蛛已经来過，取回了内容，但判断價值不足或不适合收錄。
- 抓取被拒：robots.txt、防火墙或服務器返回碼把請求挡在了外面。
只有第一種才和“入口頁發現”直接相關，後两種要從内容和服務端找原因。
入口頁這條鏈路上的問题
入口頁自身是否被抓取
入口頁如果本身訪問频率极低，連結被解析的机會也少。可以看服務器日誌里入口頁的請求次數、返回碼和响應時間。入口頁大量返回 5xx、频繁超时，或者内容常年不變，都會降低它被反复訪問的概率。
連結是否真的可解析
連結寫在 JS 渲染後才出現的位置、依赖点击才展開的区块、或被 CSS 隐藏的容器里，都可能让解析器拿不到 href。用“查看網頁源代碼”確認目标連結是否出現在初始 HTML 中，是成本最低的一步。
單頁連結數量是否過多
一個入口頁塞進几百上千條連結，蜘蛛通常會挑選其中一部分處理。連結數量越多，單條被優先抓取的机會越小。
目标 URL 一侧的常见原因
- 頁面内容與站内其他頁面高度重复，或正文极短、几乎没有有效文本。
- URL 带大量跟踪參數、會话 ID，被判定為同一内容的多個變体。
- canonical 指向了別的地址，蜘蛛自然優先抓被指向的那個。
- 目标頁需要登入、依赖 Cookie，返回的是空壳内容。
- 服務器响應慢、频繁超时，抓取队列會把它往後排。
一個可操作的排查顺序
- 用日誌確認搜尋蜘蛛最近是否訪問過入口頁，频率和狀態碼是否正常。
- 查看入口頁初始 HTML 里是否存在目标連結，锚文本和路径是否清晰可讀。
- 抽查目标 URL 的返回碼和首字节時間，確認没有 4xx、5xx 和長時間等待。
- 检查目标頁的 robots 元标簽、canonical、移動端适配是否與预期一致。
- 减少同一入口頁的連結總量，把重点 URL 放在更靠前、更明确的位置。
- 观察两到四周，對比抓取請求數的變化，再决定下一步調整。
几個容易走偏的誤区
- 以為提交得越多、抓得越快。提交只是告知，抓取节奏由爬虫自己决定。
- 以為換個入口頁就能立刻改變结果，却忽略了目标頁本身的质量問题。
- 只看站長平台的數字，不看服務器日誌，漏掉被拦截的請求。
入口頁能做的，是让連結更容易被發現；能不能被抓、會不會被收錄，最终取决于目标 URL 自身和服務端的整体表現。
如果入口頁鏈路正常，目标 URL 却長期停在“已發現”，通常不是某一次提交没生效，而是抓取配額、内容價值和站点稳定性几件事叠在一起。按上面的顺序逐項排除，比反复更換入口頁更有效。