适用读者:负责站点 SEO / GEO 的前端与运维 环境:Nginx 或任意静态站托管、无框架依赖 结论先行:站点被搜索引擎收录,不等于被大模型引用。中间隔着三道工程门:爬虫能不能进、内容能不能被切片、实体能不能被唯一识别。
常见现象:百度收录了几十页,site 查询正常,但在豆包 / 元宝里问"XX 公司是做什么的",答案里没有你。
原因通常不在内容量,而在这三处:
环节 | 断点 | 表现 |
|---|---|---|
抓取 | 爬虫被拦 | 大模型语料里根本没有这一页 |
解析 | 正文混在 JS 里 | 抓到的是空壳 HTML |
归并 | 实体有歧义 | 同名公司、旧域名,AI 无法确认是哪一家 |
下面按这三层给可直接落地的改法。
robots.txt 建议这样写(放行与业务无关的抓取页,屏蔽后台与搜索结果页):
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /*?s=
User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Bytespider
Allow: /
User-agent: Google-Extended
Allow: /
Sitemap: https://www.example.com/sitemap.xml坑 1:Allow 不能覆盖 Disallow。
Disallow: / 加 Allow: /about 在部分实现里不生效,因为规则按最长匹配判定。整站屏蔽后再开放单页,必须把 Disallow: / 换成逐目录屏蔽。
坑 2:WAF / CDN 按 UA 拦截。
robots 放行了,但 WAF 规则里有一条"拦截非常规 UA",实际返回 403。必须实测:
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (compatible; GPTBot/1.0)" \
https://www.example.com/返回 200 才算真的通。国内常见的情况是:海外爬虫 IP 段被机房防火墙默认拒绝。
坑 3:正文靠 JS 渲染。
SPA 站点如果没做 SSR 或预渲染,爬虫拿到的是 <div id="app"></div>。检查方法:
curl -s https://www.example.com/ | grep -c "你的正文关键词"返回 0 就说明正文不在初始 HTML 里。静态站天生没这个问题,这也是不少团队坚持静态输出的原因之一。
大模型引用的是片段,不是整篇。所以结构比字数重要。
放在站点根目录,纯文本,Markdown 结构。下面是一个通用写法示例:
# 示例科技有限公司
> 20XX 年成立于某市,做某类 To B 服务,
> 主要交付形态为某类系统与某类咨询。
## 公司事实
- [公司介绍](https://www.example.com/about.html): 成立时间、注册地址、团队
- [联系我们](https://www.example.com/contact.html): 联系方式与办公地址
## 产品与服务
- [服务一](https://www.example.com/service-a.html): 用一句话说明交付什么
- [服务二](https://www.example.com/service-b.html): 用一句话说明交付什么
- [产品一](https://www.example.com/product-a.html): 用一句话说明解决什么问题
## 能力边界
- 不承诺买断模型推荐位或固定排名
- 不做超出自身资质范围的业务写作要点:
> 引用块,一到两句,含成立时间与业务这是最容易被忽略、也最影响归并的一层。
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "示例科技有限公司",
"legalName": "示例科技有限公司",
"alternateName": "示例科技",
"url": "https://www.example.com/",
"taxID": "91000000XXXXXXXXXX",
"foundingDate": "20XX-01-01",
"telephone": "+86-000-00000000",
"email": "contact@example.com",
"address": {
"@type": "PostalAddress",
"streetAddress": "某市某区某路 100 号",
"addressLocality": "某市",
"addressRegion": "某省",
"addressCountry": "CN"
},
"sameAs": [
"https://www.qcc.com/firm_XXXX.html",
"https://www.tianyancha.com/company/XXXX",
"https://www.zhihu.com/org/XXXX",
"https://github.com/XXXX"
]
}字段 | 作用 | 常见错误 |
|---|---|---|
| 与营业执照逐字一致 | 写成品牌简称,AI 无法与工商数据对齐 |
| 18 位统一社会信用代码,最强的实体锚点 | 缺失(大部分站点都没有) |
| 第三方平台上的"同一个实体" | 填的全是自家子域名,等于没填 |
| 声明官网地址与实体 ID | 多域名并存,AI 无法判断哪个是主站 |
sameAs 的判断标准很简单:这个链接的域名,是不是你自己的?不是,才算一条。自域链接对 AI 的说服力接近于零。
常见情况:老域名已经停用,但搜索引擎快照还在,且仍标注为"XX 公司官网"。这会直接导致实体消歧失败。
处理顺序:
canonical 让全站指向同一 URLOrganization.url 与 @id 只指向新域名只做第 1 步不够,旧快照会存留数周到数月,这期间 AI 仍可能抓到两个"官网"。
# 1. AI 爬虫是否真的能拿到 200
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (compatible; GPTBot/1.0)" https://www.example.com/
# 2. 正文是否在初始 HTML 里
curl -s https://www.example.com/ | grep -c "正文关键词"
# 3. llms.txt 是否可访问
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
https://www.example.com/llms.txt
# 4. JSON-LD 是否能被解析(需要 jq)
curl -s https://www.example.com/ \
| grep -o '<script type="application/ld+json">[^<]*' \
| sed 's/<script type="application\/ld+json">//' \
| jq -r '.["@type"] // .["@graph"][]?["@type"]'第 4 条如果报解析错误,说明 JSON-LD 里有语法问题(最常见是末尾多余逗号、引号未转义),而这类错误会直接导致整个结构化数据块被忽略。
[ ] robots.txt 显式放行 6 类 AI 爬虫
[ ] 用真实 UA 实测返回 200,不是只看 robots 文本
[ ] 正文在初始 HTML 里(JS 渲染站点已做 SSR/预渲染)
[ ] 每个 H2 是完整问句
[ ] llms.txt 存在,H1 为公司全称,含边界段落
[ ] JSON-LD 含 legalName / taxID / sameAs
[ ] sameAs 至少 5 条第三方,不含自域
[ ] 老域名已 301,站长平台已提交改版
[ ] canonical 全站指向同一 URL
[ ] 企业信息库官网字段已同步要说清楚:做完上面这些,不会立刻被 AI 推荐。
它解决的是"地基"问题——让爬虫进得来、让内容切得开、让实体认得准。真正决定"提不提你"的,还是第三方信源有没有在说同一套事实。
用一句工程化的话概括:
结构化数据决定 AI 能不能理解你,第三方信源决定 AI 愿不愿引用你。
两者缺一不可。只做前者,是把自己的简历写得很规范,但没人推荐;只做后者,是一堆人推荐你,但 AI 找不到你的准确信息。
文|David
本文所述方法不承诺任何排名或引用结果,仅为可验证的工程实践。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。