有些站点做入口頁时图省事，會把一批目标 URL 直接以纯文本或 JSON 的形式吐出来，觉得“反正搜尋蜘蛛能讀到内容就行”。實际上，搜尋蜘蛛會不會顺着里面的 URL 繼續走，取决于它拿到的响應是不是一個它愿意解析的 HTML 文档。這一点经常被忽略。
搜尋蜘蛛拿到响應後，先看的是什么
搜尋蜘蛛抓取一個 URL 时，第一步是拿到 HTTP 响應，然後看狀態碼、Content-Type 以及内容本身。只有当一個响應被判定為可解析的 HTML 頁面时，里面的 a 标簽連結才會進入它的連結提取流程。如果 Content-Type 明确寫着 application/json、text/plain，或者服務端返回的是 PDF、图片，那么即便响應体里明明白白寫着 https://example.com/a，也不會被当作頁内連結来跟進。
Content-Type 和實际内容不一致會怎样
搜尋引擎一般以响應头的 Content-Type 為主，同时也會做一定的内容嗅探。如果服務端把 HTML 错标成 text/plain，連結被解析的概率會大幅下降；反過来，把一段 JSON 标成 text/html，也不代表搜尋蜘蛛就會認真提取里面的 URL——它更可能把整段内容当成一堆無意义的文本。两種错法都不划算。
几種常见的非 HTML 响應，分別是什么结果
- text/plain：會被当成纯文本處理，通常不提取連結。把 URL 列表直接寫在响應体里，基本等于只做了一次告知動作，而不是一次頁面級的發現。
- application/json：接口返回的 JSON 會被当作資料文件，除非它同时被用作渲染頁面的資料源，否則里面的 URL 不會被跟進。
- application/pdf：正文中的連結可能被部分识別，但處理方式和 HTML 完全不同，也不稳定，不适合作為入口頁的主要形式。
- XML（sitemap / RSS）：這属于另一套机制。sitemap 里的 URL 是集中提交，不是頁内連結發現，两者不要混為一谈。
- 图片、二進制文件：一般只作為资源被抓取，不會從中提取連結。
想让 URL 被發現的几種正经做法
- 入口頁用标准 HTML 返回，連結放在 a 标簽的 href 里，不要只放在 JS 變量或纯文本里。
- 確認响應头的 Content-Type 是 text/html; charset=utf-8 之類的正确值，別让编碼和類型错位。
- 如果确實要用接口吐資料，就让前端拿到資料後渲染成真實連結，並保證渲染後的 DOM 里能出現 a 标簽。
- 另一條路是走提交渠道，比如 sitemap 或主動推送接口。入口頁解决的是“被反复發現”，提交解决的是“被明确告知”，两者互补而不是替代。
怎么自查
用 curl 或浏览器的開發者工具看一下入口頁返回的 Content-Type，再用“查看網頁源代碼”確認連結是不是真的寫在 HTML 里。如果源代碼里根本看不到連結，只能靠接口拼出来，那就先假设搜尋蜘蛛看不到它。
一個简單的判断标准：禁用 JavaScript 後打開入口頁，如果頁面上看不到任何可点的連結，搜尋蜘蛛大概率也看不到。
入口頁的形式可以简化，但不能简化到不像一個網頁。只要目标 URL 需要被搜尋蜘蛛發現，就尽量让它出現在一個正常的 HTML 文档里，其它形式适合作為补充，而不是主力。