这两年做网站的站长应该都有一个明显感受传统搜索流量在下滑AI 搜索带来的推荐流量在涨。但很多人发现自己的内容明明写得很认真搜索结果页排名也不错偏偏在 AI 搜索里不被引用甚至一次都没出现过。我花了大半年时间做 GEOGenerative Engine Optimization生成引擎优化把十几个站的引用率从零拉到了平均 15% 左右。这篇就把我踩过的坑都说清楚为什么 AI 搜索不引用你的网站以及如何用代码把这件事改掉。文章既适合站长、内容运营看也适合前端开发者参考我会尽量少讲玄学多给能直接抄的代码和步骤。1. 为什么 AI 搜索不引用你的网站先理解“引用”的本质很多人一上来就问“怎么提高 GEO 排名”但忽略了一件最关键的事AI 搜索引擎压根没有一个叫“排名”的东西它只有“引用决策”。这俩是完全不同的逻辑。1.1 “引用”不是排名而是生成阶段的证据选择传统搜索引擎的工作方式是用户输入关键词搜索引擎在索引库中匹配网页按相关性从高到低排列用户自己点。这个过程里搜索引擎只负责“排序”把选择权交给人。AI 搜索也就是生成引擎完全是另一套玩法用户用自然语言提问系统先在索引库和网页库里检索候选材料然后大语言模型综合多个来源生成一段连贯回答并在合适的位置标记“[1]”“[2]”这样的引用来源。注意这句话模型不是在“排名”它是在“选证据”。这就像你写论文时会引用哪篇文章不是“排在第一位的”而是“结论明确、结构清晰、能直接支撑你论点的那篇”。AI 搜索也一样。它会优先把网页中可以直接抽取、并能支撑回答的内容当作证据源。如果你的网站内容信息密度低、结论含糊被淹没在长段落里或者缺少可识别的作者、发布时间、组织信息模型就不会认为你是“可靠证据”自然不引用。这个认知差异决定了后续所有优化方向SEO 盯的是关键词、链接、排名GEO 盯的是“内容是否容易被模型选中作为证据”。1.2 三个容易被忽略的过滤环节在我实测的几十个站点里绝大多数“内容不错但没引用”的问题都不是内容本身烂而是卡在了这三个环节中的一个。第一层是索引阶段爬虫根本没有把你的页面抓进索引库。常见原因是 JS 渲染太重、robots.txt 里误屏蔽了某些抓取工具、页面加载速度太慢导致超时。第二层是检索阶段你的内容虽然被索引了但模型在召回候选材料时觉得你的页面和用户问题相关性不够。这个阶段看的是语义匹配不是关键词匹配。比如用户问“如何提升网站在 AI 搜索里的可见性”你页面里全是“GEO 优化”“生成引擎排名”这类词但没有一句话能直接回答“如何做”这个动作语义匹配度就偏低。第三层是生成阶段模型面对多个候选证据时会做可信度判断。权威性更高的站点、带明确作者和出处的页面、信息并与其他页面重复度更低的内容更容易被选中。如果你的文章是从某个热门话题的公开信息里“洗”出来的没有独家数据、没有明确结论模型宁可引用原始出处也不会引用你。1.3 为什么“有排名”不等于“被引用”我把 SEO 和 GEO 的差异用一张表说明白维度SEOGEO用户行为输入关键词浏览多个结果用自然语言问问题等待一个答案核心考核排名位置、点击率引用次数、答案覆盖率内容要求关键词密度、外链、页面权重实体丰富、结论可提取、可验证技术重点robots、sitemap、加载速度、外链结构化数据、纯文本可读性、知识实体结果形态列表页用户自己挑一段答案附带引用来源所以一个网站在 Google 排第一完全不代表它在 AI 搜索里会被引用。两个系统的“入口”完全不同一个入口是搜索框一个入口是问题对话框。想通这一点你才能理解为什么接下来那些代码层面的改造会有效。因为代码改的不只是“给爬虫看的东西”而是“模型能不能从你的页面里顺畅提取出它想要的东西”。2. 用代码改掉这件事机制与边界标题说了“如何用代码改掉它”但代码不是魔法。它解决的是可读性、身份标识、可提取性这三件事。我先讲清楚机制再讲边界。2.1 代码解决的核心问题可读性、身份、可提取性第一个问题是可读性。很多前端为了体验用 React、Vue 等框架做整页客户端渲染爬虫访问只能拿到一个空的 div 容器真正的文章内容要靠 JS 执行后才会出现。传统搜索引擎的爬虫大多支持 JS 渲染但 AI 搜索的数据采集器、第三方的索引代理很可能在图省事的情况下直接读取原始 HTML结果就是你的内容对它不可见。这种问题用代码改成“SSR 服务端渲染”或者“预渲染”甚至只是把关键内容同步输出在 HTML 里就可以解决。第二个问题是身份标识。模型判断“这个网页是谁写的、什么时候发布的、是否可信”时主要靠页面里的结构化数据。很多网站连最基本的 JSON-LD 都没有等于递给模型一张没有署名的传单。用代码在页面里加上 schema.org 的 Article、Person、Organization、FAQPage 标记就等于给了模型一张机器可读的身份名片极大降低可信度判断难度。第三个问题是可提取性。模型读完你的页面后需要在几秒钟内判断“这段话能不能直接支撑某个观点”。如果关键结论藏在 3000 字的经历叙述里没有任何摘要、列表、加粗结论模型的抽取成本很高它会去选择更容易抽取的页面。代码层面的解决方案是给每篇文章增加摘要块、FAQ 块、结论前置段落并用结构化的 HTML 标签标记出来。2.2 GEO 代码优化的三个原则一致、增量、可验证我在实际项目中总结出三条铁律违反任何一条都会翻车。第一条是“爬虫看到的内容和用户看到的内容必须一致”。别想着做一个精美的用户页面再做一个纯文本版本给 AI 爬虫这叫伪装一旦被识别整站都会进黑名单。GEO 不是欺骗 AI而是把已经在页面里的信息翻译成更容易被机器理解的语言。第二条是“做增量不做替代”。不要在页面上删除原来丰富的内容只留摘要那样会伤害真实用户。正确的做法是在保留完整内容的基础上增加摘要、FAQ、结构化数据这些“增量层”让爬虫和用户各取所需。第三条是“每次改动都要可验证”。GEO 这块目前没有标准化的度量仪表盘你需要自己搭建验证工具。我在第四节给的检查器脚本就是干这个的每次部署代码前后跑一遍对比提取结果你才知道改动到底有没有用。2.3 代码改不掉的部分权威性与信息差必须诚实地说代码能解决的是“让好内容被看见”不能解决“内容本身不够好”。模型判断是否引用时还会看这个网页的权威性信号比如外部站点是否引用过你、作者在垂直领域有没有历史背书、有没有真实的数据来源。这些不是靠几行代码能堆出来的。同样如果你的内容只是把公开资料换个顺序重写一遍没有任何增量信息代码层面做得再完美模型也会舍你而去选原始出处的站点。所以 GEO 项目的正确打开方式是代码负责把内容“翻译”给 AI内容本身负责给 AI 一个引用的理由。两者缺一不可。3. 全套代码改造从元数据到内容结构接下来进入实操。我会按一个真实页面的改造顺序来讲从本地测试环境到 schema 标记再到 robots 和 sitemap最后给一个比较进阶的“答案端点”方案。3.1 准备本地测试环境先把页面在本地跑起来方便快速验证。假设你的项目是静态站点最简单的方式是cd /path/to/your/site python3 -m http.server 3000或者用 Node 生态npx serve .推荐用本地 server 而不是直接file://打开是因为后面那些验证脚本抓取、解析、检查 JSON-LD都会用 HTTP 请求去访问页面本地 server 更接近生产环境。如果你在生产环境调试直接换成线上域名访问就行。3.2 给页面加上最标准的 JSON-LD这是投入产出比最高的一步。在页面的head区域插入一段application/ldjson脚本。我以一篇技术教程文章为例script typeapplication/ldjson { context: https://schema.org, type: Article, headline: 如何提升网站被 AI 搜索引用的概率, description: 本文介绍 GEO 的基本原理并给出 JSON-LD、robots.txt、答案端点等代码层面的可落地方案。, author: { type: Person, name: 你的作者名, url: https://example.com/author/name }, publisher: { type: Organization, name: 你的站点名, url: https://example.com }, datePublished: 2025-06-01T08:00:0008:00, dateModified: 2025-06-05T10:00:0008:00, mainEntityOfPage: https://example.com/post/how-to-get-cited-by-ai-search } /script你可能会问这篇文章标题是“如何提升网站被 AI 搜索引用的概率”那段 JSON-LD 的 headline 也这样写没问题。关键是让 headline 和 description 直接包含核心实体和问题意图这样模型在检索阶段更容易判定“这个页面和用户问题相关”。如果页面里有明确的 FAQ 区块可以再加 FAQPage 结构script typeapplication/ldjson { context: https://schema.org, type: FAQPage, mainEntity: [ { type: Question, name: GEO 和 SEO 的区别是什么, acceptedAnswer: { type: Answer, text: SEO 优化的是搜索引擎排名GEO 优化的是生成引擎引用率。 } }, { type: Question, name: 被 AI 引用需要哪些代码改造, acceptedAnswer: { type: Answer, text: 主要改造 JSON-LD、robots.txt、sitemap以及页面内容的结构化。 } } ] } /script注意一个坑FAQ 结构必须与页面里真实展示的问答内容一一对应不能页面里没有这个问题却单独在 JSON-LD 里写一个这是典型的伪装行为。3.3 robots.txt 与 sitemap 的最低配置很多人以为 robots.txt 是 SEO 才要关心的东西其实 AI 搜索的爬虫同样会遵守它。如果你的 robots.txt 不小心屏蔽了某个 AI 搜索引擎的爬虫 UA你的页面就永远进不了它的索引库后面做再多 GEO 都是白费。我给自己项目的 robots.txt 最低配置是这样User-agent: * Allow: / Sitemap: https://example.com/sitemap.xmlsitemap 里必须列出你想被 AI 引用页面的规范链接canonical URL。给一个最简单的 sitemap 片段?xml version1.0 encodingUTF-8? urlset xmlnshttp://www.sitemaps.org/schemas/sitemap/0.9 url lochttps://example.com/post/how-to-get-cited-by-ai-search/loc lastmod2025-06-05/lastmod changefreqmonthly/changefreq priority0.8/priority /url /urlset改完后一定要主动提交。最主要的提交入口就是各大搜索引擎的站长平台把 sitemap URL 贴进去能显著加快抓取速度。不要等爬虫自己发现你AI 搜索迭代很快早一步进索引早一步拿到引用红利。3.4 为 AI 单独准备一个“答案端点”这一步属于进阶玩法效果明显但需要一定开发能力。思路是写一个轻量 API当 AI 爬虫或检索系统拿到你的 URL 时自动返回一篇包含摘要、关键结论、核心实体的纯文本版本。相当于给你的页面再加一条“AI 专用入口”。用 FastAPI 实现一个最简单的版本from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class AnswerResponse(BaseModel): url: str title: str summary: str key_points: list[str] content: str app.get(/ai-answer/{post_id}) def ai_answer(post_id: str): # 这里从你的数据库或静态文件中读取文章数据 article fetch_article_by_id(post_id) response AnswerResponse( urlarticle.url, titlearticle.title, summarygenerate_summary(article.content), key_pointsextract_key_points(article.content), contentarticle.get_plain_text() ) return response这个端点的价值在于当检索系统访问你的页面时可以得到一段天然结构化的、机器友好的正文。但注意这个端点的输出必须与页面上展示的信息完全一致只是排版更精简而已这里不是在搞黑帽。如果你不想维护这个 API也可以直接在 HTML 里做同样的事用details加summary把每篇文章的核心结论放在最前面再用h2把要点拆开。模型对规范的 HTML 标签解析能力很强有时候不需要额外 API 也够用。4. 实战把理论跑成可验证的代码方案讲得再好不如一个能跑的检查器。我用 Python 写了一个“AI 友好度检查器”帮你快速看某个页面在模型视角下到底是什么样。4.1 改造前一段典型的“纯文本”页面很多博客页面长这样一个article标签里面是连续十几个p段落没有摘要、没有小标题、没有 JSON-LD。这种页面给爬虫看就是一面文字墙。改造后的页面应该是article里包含一个meta namedescription、一个h1之后紧跟摘要section、正文用h2/h3分节、结尾放一个 FAQ 区块、head里放完整的 Article FAQPage JSON-LD。这些结构并不是为了好看而是为了降低模型识别和抽取的成本。4.2 用脚本检查自己的页面在 AI 眼里长什么样先把requests和beautifulsoup4装好pip install requests beautifulsoup4然后写检查器import requests from bs4 import BeautifulSoup def check_ai_friendliness(url): resp requests.get(url, timeout10) soup BeautifulSoup(resp.text, html.parser) print( 基础检查 ) print(内容长度, len(soup.get_text())) print(H1 数量, len(soup.find_all(h1))) print(H2 数量, len(soup.find_all(h2))) print( 结构化数据检查 ) ldjson soup.find_all(script, typeapplication/ldjson) print(JSON-LD 块数量, len(ldjson)) for block in ldjson[:3]: print(block.string[:200] if block.string else empty) print( 可提取性检查 ) article soup.find(article) text article.get_text( , stripTrue) if article else soup.get_text( , stripTrue) print(摘要位置, 摘要 in text[:300] or summary in text[:300].lower()) print(前500字) print(text[:500]) if __name__ __main__: check_ai_friendliness(https://example.com/post/how-to-get-cited-by-ai-search)跑完这个脚本你基本能知道自己的页面在“机械解读”层面有什么硬伤。常见的出厂结果很扎心H1 有 3 个JSON-LD 块 0 个前 500 字全是废话。这些问题不用动内容纯用代码就能修。4.3 用 AI 模型反向测试引用率自测脚本看懂页面结构还不够最直接的方式是让模型“读”你的页面内容看它能不能提取出有效答案。用 OpenAI 的接口来测试先安装pip install openai然后写一个覆盖测试脚本把你的页面文字交给模型让它总结并判断是否有引用价值from openai import OpenAI import requests from bs4 import BeautifulSoup client OpenAI(api_key你的API_KEY) def extract_plain_text(url): resp requests.get(url, timeout10) soup BeautifulSoup(resp.text, html.parser) article soup.find(article) or soup for tag in article([script, style, nav, footer]): tag.decompose() return article.get_text( , stripTrue)[:3000] def test_ai_visibility(url, question): content extract_plain_text(url) prompt f 请阅读以下网页内容判断它能否回答用户提问。 用户提问{question} 网页内容 {content} 请直接回答 一、内容中是否包含问题的直接答案包含或不包含。 二、如果包含提取出可引用的原句。 三、这个页面适合作为你回答该问题的引用来源吗适合或不适合。 response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}] ) return response.choices[0].message.content if __name__ __main__: page https://example.com/post/how-to-get-cited-by-ai-search q 网站怎么做才能获得 AI 搜索的引用 print(test_ai_visibility(page, q))这个测试很有效如果模型说“内容中不包含直接答案”说明你的页面信息组织和语义表达有问题如果它说“包含但如果要引用我会引用原文”说明结构化改造成功了。我更建议你准备一组 20 个和网站主题相关的问题循环跑一遍统计“适合引用”的比例这个数据就是你的引用率基线。每轮代码改动后再跑一遍用数字对比验证改进效果这比“感觉应该有用”靠谱得多。5. 常见问题与排查技巧实录这部分是我做 GEO 项目时被问得最多的问题也是我自己踩过最深的坑。5.1 加了 schema 还是不被引用先检查这三件事第一个可能是 schema 类型不对。很多站点只加了WebSite类型的 JSON-LD但文章页需要的是Article或BlogPosting模型在提取具体文章信息时WebSite根本没用。我见过太多人整体加了WebSite以为就算“加了结构化数据”实际上等于没加。第二个可能是 JSON-LD 放错了位置。它必须放在head区域并且是独立的script typeapplication/ldjson块不能用普通的script标签。有些静态站点生成器会转义 JSON导致爬虫收到的是被转义的一串字符解析不出来这种情况需要检查构建产物。第三个可能是部署没生效。改完代码后先去浏览器或 curl 里直接看原始 HTML确认新的 JSON-LD 真的出现在生产环境里再去站长平台提交抓取。我碰到过改完了但 CDN 缓存旧版缓存了三天的情况这个坑很容易被忽略。5.2 sitemap 提交很久没反应大概率是路径或格式问题sitemap 提交后 3 到 7 天没有收录先检查四件事一sitemap 文件本身能不能通过浏览器直接访问返回的是 XML 而不是 404 二robots.txt 里声明的 Sitemap 地址和你提交给站长平台的地址是否完全一致 三sitemap 里的 URL 是否全部是规范的 https 版本 四有没有用lastmod标记最近修改时间这能提醒爬虫“这个页面最近更新过”。如果这些都排查过了可能就是单纯的索引延迟。AI 搜索的数据源头不只是一个搜索引擎多平台覆盖需要时间一般两周内会有变化。5.3 要不要给 AI 单独做“优化版页面”这个问题我几乎每次分享都会被问。我的回答是不要。理由很简单当爬虫和用户看到的内容不一致时轻则被判定为伪装严重时整站会被降权。所谓的“答案端点”不是给你一个隐藏页面用的它是给你的公开页面增加一种“更结构化呈现方式”输出内容必须和页面上真实内容完全一致只是排版更友好。如果你担心页面太花哨影响机器读取优先考虑用语义化 HTML JSON-LD 解决问题而不是做一个“纯净版”。前者是优化后者是黑帽。5.4 常见错误快查表问题表现可能原因解决方案页面完全不被任何 AI 搜索提及robots 误屏蔽、无 sitemap检查 robots.txt提交 sitemap页面被提及但总是排在“其他来源”里权威性不足、引用证据不够增加外链引用、明确作者、补充独家数据有了 JSON-LD 但没效果schema 类型不对或格式错误改成 Article 类型校验 JSON 语法内容好但没有可抽取结论关键段落被淹没增加摘要区块、FAQ 区块、结论前置内容被引用但经常摘错意思实体与关键词不够明确统一实体名称增加上下文定义改动后一天内看数据没变化索引和模型更新有延迟至少等待两周再做结论我做这个项目最大的体会是AI 搜索的优化窗口期还在早期很多站点还没来得及做代码层面的改造谁先做到位谁就能吃到这波推荐流量的红利。但这个过程不是“改一次代码就一劳永逸”模型的抓取策略、解析方式、页面索引逻辑都在快速迭代建议每季度重跑一次检查脚本保持对数据和变化的敏感度。在你动手之前先挑五个流量核心页面做试点跑出基线数据再决定要不要对全站推广别一上来就把整站翻个底朝天。