先说结论：大多數情况下，搜尋蜘蛛會先看 HTTP 响應头里的 Content-Type（以及 charset）。如果返回的不是 text/html 或 application/xhtml+xml，即使响應体里寫着完整的 a 标簽連結，被当作連結解析的概率也會明顯下降。也就是说，入口頁的連結寫得再工整，内容類型标错了，前面的功夫可能白費。
為什么 Content-Type 會影响連結解析
抓取和解析大致分两步：抓取器先把 URL 取回来，再交给解析器决定用哪種方式處理响應体。解析器在很大程度上依赖 Content-Type 来判断“這是什么内容”，再决定是走 HTML 解析、XML 解析，還是只当一段文本收下。連結提取只發生在 HTML 解析這條路径上，走其他路径时，頁面里長得像連結的字符串通常不會被当成待抓取的 URL。
常见的几種内容類型
- text/html：正常網頁，按 HTML 解析，連結會被提取。
- application/xhtml+xml：一般也會按 HTML 處理，但要注意 XML 的嚴格语法，标簽未閉合可能導致解析中断。
- text/plain：多數抓取器會当成纯文本，不做連結提取。
- application/json、text/xml、application/xml：通常按資料接口處理，里面的 URL 不會自動變成可抓取的連結。
- 缺失 Content-Type：不同蜘蛛、不同版本的兜底策略不一样，有的會猜成 HTML，有的直接跳過，属于不可控狀態。
容易踩坑的几種情况
- 後端统一返回 application/json，正文里塞了一段 HTML 字符串，浏览器看着像頁面，蜘蛛看到的只是資料。
- 服務器没有為某些扩展名配置預設 MIME 類型，返回 application/octet-stream，蜘蛛會把它当成待下载的文件。
- CDN 或反向代理改寫了响應头，源站是對的，到蜘蛛這邊變成了 application/json。
- 入口頁是静態文件但没有扩展名，服務端預設给了 text/plain。
- 用 XML 语法寫 XHTML，却声明成 application/xhtml+xml，一個未閉合标簽就可能让解析停在半路。
怎么判断自己的入口頁有没有問题
- 用 curl 或能查看响應头的工具請求入口頁，重点看 Content-Type 這一行。注意單纯用 HEAD 請求时，有些服務器返回的头和 GET 不一致，最好直接看 GET 的完整响應头。
- 如果返回的不是 text/html，先確認是代碼里手動設定的，還是服務器或網關的預設行為。
- 检查 charset 是否與實际编碼一致，编碼错乱也可能让解析器放弃提取連結。
- 改完後再用同一工具复测，確認响應头已经變成 text/html 且编碼正确。
除了 Content-Type，還要顺带看這几項
- Content-Encoding：声明了 gzip 或 br，實际返回的却是未压缩内容，或反過来，蜘蛛都可能拿到乱碼。
- Content-Length：與實际長度不符时，部分抓取器會截断响應体，排在後面的連結自然讀不到。
- 狀態碼：Content-Type 再正确，如果是 403、404、410 或 5xx，連結解析都無從谈起。
- X-Robots-Tag：這個头一般不影响連結解析，但會影响頁面本身是否被索引，別把两件事混為一谈。
入口頁的核心任務是“被正确解析”，而不是“被索引”。把 Content-Type 当成第一道闸门来检查，比事後反复猜测蜘蛛為什么不抓要省事得多。
小结
入口頁里的連結能不能被發現，前提是蜘蛛把它当成 HTML 来讀，而 Content-Type 就是最直接的判断依據。建议把“响應头是否為 text/html 加正确 charset”加入上线前的常規检查項，尤其是入口頁由後端動態輸出、又经過 CDN 或網關轉發时，更要留意响應头有没有被中途改寫。它不保證任何收錄或排名结果，但至少能保證蜘蛛看到的内容，就是你希望它看到的那些連結。