前阵子和一位做企业站的朋友聊起流量，他说了句让我印象很深的话：“现在用户在AI对话框里搜我们这类服务，出来的答案里有好几家同行，但没我们。可我们在百度谷歌的排名并不差。”这个问题其实正在大面积发生。原因很简单：传统SEO优化的对象是搜索引擎的“检索结果页”，而AI搜索优化的对象是“生成式答案”。检索结果页有个固定位置可以争取排名，生成式答案拼的是“谁的内容被模型选中、作为论据被引用”。这中间隔着的，就是GEO（Generative Engine Optimization，生成引擎优化）。
GEO并不是什么玄学，它要解决的核心问题只有一个：让AI在生成回答时，基于你的官网内容来表述，而不是引用别人的、或者干脆编一个。要做到这件事，目前最确定、且已经在大量AI产品中被验证的落地路径有三条：Schema结构化数据、OG标签规范、llms.txt导览文件。这篇文章就围绕这三条路径展开，把每一步怎么操作、为什么要这么做、以及过程中容易踩的坑完整讲清楚。适合企业官网的运营者、技术负责人，以及所有正在为“AI不引用我”而发愁的人。
1. 先弄明白一件事：GEO到底在优化什么
1.1 你以为是“排名”，实际是“被引用”
传统SEO里，我们盯着的是“关键词排名第几位”，这个思维的隐含前提是：搜索结果页有十个位置，只要排上去就有曝光。但AI生成式搜索完全不是这个逻辑。你问一个AI助手“推荐几家可靠的工业设计服务商”，它不会给你十个蓝色链接，而是会直接生成一段话——在这段话里，它只会提及它认为最优的两三家，并对其中一家给出具体描述：“根据某公司官网介绍，他们擅长精密零部件的结构设计……”这就是被引用。
被引用和被排名，底层机制完全不同。排名靠的是抓取、索引、相关性信号、链接权重。引用靠的是模型在检索增强生成（RAG）过程中，从外部语料库里“找到”你的内容片段，并把它作为可信来源写进答案。换句话说，AI引不引用你，取决于两件事：第一，AI检索系统能不能从你的官网里抽取出干净、可靠、语义明确的文本片段；第二，你的内容有没有足够的结构化信号，让模型识别出“这是一家什么机构、提供什么服务、有什么资质与背书”。
所以GEO优化的对象不是“排名”，而是“可引用性”。可引用性由三个维度组成：信息可发现（AI爬虫能顺利抓到你）、信息可理解（抽出来的片段语义完整、结构清晰）、信息可信赖（代码层面有实体标注，内容层面有事实支撑）。Schema、OG标签、llms.txt，恰好分别对应这三个维度的落地工具。
1.2 大模型引用你的三个前置条件
如果把AI应用比作一个真人编辑，它决定是否引用某篇官网内容，通常会走三步：
第一步，它得先“知道”有这个网站存在，并且能够完整抓取。这就是可发现性。很多企业官网内容做了动态渲染、关键信息埋在JavaScript里、或者页面体量大到爬虫几小时都跑不完，都会在这一步被筛掉。llms.txt就是专门为这个问题设计的一层轻量级导览，让AI爬虫用最少的资源快速理解站点全貌。
第二步，它得“读懂”页面的语义。一个真人编辑看网页，会看标题、正文、图注、结构化描述。AI也一样，但它更依赖HTML里的显性标签。你的og:title、og:description、Schema标记，就是它快速判断“这个页面在讲什么、有没有用”的捷径。没有这些标签的网页，就像一份没有摘要的PDF，价值要打折扣。
第三步，它得“敢用”你的内容。这一步最关键，又最容易被忽略。AI引用内容时，不只是看相关性，还要做可信度判断。页面里的机构名称、地址、联系方式、经营范围是否以标准化的结构化数据标识，直接影响模型对主体的识别准确度。一个标注清晰的企业实体，比一坨格式混乱的介绍文本更容易被引用。这也是为什么Schema中的Organization、Product等类型，价值远不止于“搜索结果里多几个富摘要”。
理解了这三步，再回头看标题里的三个工具就顺了：llms.txt解决“拿得到”，OG标签解决“读得懂”，Schema解决“信得过”。
2. Schema结构化数据：给AI递一份“带着目录的说明书”
2.1 不是设置越多越好，关键是实体一致性
很多团队一提到Schema，第一反应就是“能加多少加多少”。这是我见过最常见的误区。Schema的价值不在于“代码里声明了什么”，而在于“AI能不能通过这套声明建立起对网站主体的准确认知”。
我打一个比喻。你在一个陌生城市找一家修理厂，如果每个路牌都指向不同的方向，你会更困惑，而不是更清楚。Schema也是这个道理：如果首页说你是制造商，产品页却说你是经销商，联系我们页面又说你是平台方，模型就会面临实体冲突。它在引用时宁可选择另一个主体一致的站点，也不会费力气去厘清你到底是谁。
所以在写任何Schema之前，先想清楚一个问题：你的官网，在AI眼里应该被认知成什么？一家实体制造企业，核心主体就是Organization，外加Product和Offer；一家SaaS服务商，核心主体是Organization和SoftwareApplication；一家以内容为主的医疗科普站，核心主体是MedicalOrganization和Article类型。
同一个组织身份，必须在全站所有页面上保持一致。我见过不少官网，首页的Organization标注了真实地址和联系方式，但产品页或者博客页又出现了“另一个名字”的组织标签，这种自相矛盾会让模型直接把全站的可信度都调低。
2.2 优先落地这四类Schema
从GEO的实际收益来看，企业官网最值得优先落地的Schema有四类。注意，这不是说其他类型没用，而是说这四类能最快把“实体认知”和“内容语义”建立起来。
第一类，Organization和WebSite。这是地基。Organization用来标注你是谁、在哪、提供什么经营范围、有没有logo和社交主页。WebSite用来声明整个站点属于这个实体。建议用JSON-LD格式，把两个实体的相互关系通过url字段串起来。
{ "@context": "https://schema.org", "@type": "Organization", "@id": "https://www.example-company.com/#organization", "name": "示例智能装备有限公司", "url": "https://www.example-company.com/", "logo": "https://www.example-company.com/assets/logo.png", "description": "专注于精密零部件结构设计与智能生产线集成的制造企业", "address": { "@type": "PostalAddress", "streetAddress": "高新科技园区创新路88号", "addressLocality": "某市", "addressRegion": "某省", "postalCode": "310000" }, "contactPoint": { "@type": "ContactPoint", "telephone": "+86-400-888-8888", "contactType": "customer service", "availableLanguage": "zh" }, "sameAs": [ "https://www.zhihu.com/org/example-company", "https://weibo.com/example-company" ] }这里有一个关键细节：@id字段。它是实体的唯一标识符，后续全站所有其他类型（Product、Article等）在声明主体时，都要通过这个@id来关联回主实体。这样一来，AI就知道“这些产品、这些文章，都出自同一个主体”。
第二类，Product + Offer。卖实体产品、或者做标准化服务报价的官网，这一组必做。Product负责描述产品本身（名称、图片、属性、品牌），Offer负责描述售卖信息（价格、库存、卖家）。在GEO语境下，这组数据让AI可以把“某型号设备的价格区间、核心参数、发货周期”直接整合进答案里。
{ "@context": "https://schema.org", "@type": "Product", "name": "XH-500 高精度气密性检测仪", "image": "https://www.example-company.com/products/xh500.jpg", "description": "适用于新能源汽车电池包、医疗器械腔体等场景的气密性在线检测设备，检测精度可达0.1Pa。", "brand": { "@type": "Brand", "name": "示例智造" }, "offers": { "@type": "AggregateOffer", "lowPrice": "128000.00", "highPrice": "185000.00", "priceCurrency": "CNY", "offerCount": "6", "availability": "https://schema.org/InStock" } }第三类，FAQPage。FAQ是AI最“喜欢吃”的内容结构。大模型在生成答案时，天然倾向于引用“问题—答案”这种片段，因为可以直接把答案文本提取出来作为论据来源。这里要注意，FAQ的问题必须和用户真实搜索意图一致，不要写“你们的优势是什么”这种自嗨式问题，而要写“气密性检测仪的校准周期是多久”这种可被直接引用的问答。
{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "气密性检测仪的校准周期是多久？", "acceptedAnswer": { "@type": "Answer", "text": "按照出厂标准，建议每12个月校准一次。也可以在设备操作面板中查看最近一次校准日期，支持自定义提醒。" } }, { "@type": "Question", "name": "XH-500支持哪些通讯协议？", "acceptedAnswer": { "@type": "Answer", "text": "XH-500支持Modbus TCP、Profinet、EtherNet/IP三种通讯协议，并预留了RS485接口。" } } ] }第四类，Article和BreadcrumbList。企业官网的行业资讯、技术博客，需要用Article类型来标注，AI才能区分“这是正式的文章内容”而不是导航或广告。BreadcrumbList可以让AI理解页面在站点层级中的位置，对明确不同栏目内容的可信度有辅助作用。
2.3 JSON-LD落地与自检清单
落地时，我强烈建议用JSON-LD格式（即将推出的一部分脚本标签），而不是Microdata或RDFa。原因有三：第一，它对现有HTML结构的侵入最小，不太会影响页面渲染；第二，JSON-LD对AI爬虫的解析非常友好，不容易出现嵌套错误；第三，后台内容管理系统很容易通过模板把它打到每一个页面上。
放置位置方面，理论上JSON-LD可以放在head或body的任意位置，但如果页面体量特别大，建议把核心实体声明（Organization、WebSite）放在head，把产品、文章等页面级声明放在对应内容块附近。不用过分纠结位置，只要确保输出到最终HTML里即可。
实操中最常踩的坑有三个：
第一，建完Schema后没有做验证。推荐用Google Rich Results Test或者Schema Markup Validator在线工具，把线上URL跑一遍。重点检查三件事：JSON语法是否正确、是否标注了@id、是否有type缺字段警告。
第二，FAQ内容重复。同一套FAQ既放在页面上，又用CSS隐藏部分内容，或者同一个问题在多个页面重复出现，这些操作都很危险。AI爬虫在识别到重复内容时，对整个站点的信任度都会低。经验做法是：每个FAQ问题只在一个页面上出现，且答案要自足、具体、可以直接摘用。
第三，用JavaScript动态注入Schema。如果官网是单页应用，且所有数据靠前端渲染，Google的爬虫现在基本能执行JS了，但很多新兴AI爬虫的执行引擎并没有那么成熟。稳妥方案是让后端服务端渲染输出JSON-LD，或至少用预渲染工具把Schema输出到静态HTML里。
3. OG标签：被忽略的“AI社交名片”
3.1 OG标签为什么能影响AI判断
Open Graph协议最早是社交平台推出来的，目的是让链接在Facebook、微信里被分享时，能显示规范的标题、摘要和缩略图。大多数官网运营者都只把它当“分享美化工具”，忽略了它在AI语境里日益增长的价值。
实际上，很多AI平台的网页检索器在抽取网页摘要时，会优先读取og:title和og:description字段。为什么？因为这两个字段是HTML里少有的“结构化摘要”，语义明确，不需要AI再去猜测哪个标题是主标题、哪段文字是摘要。更重要的是，og标签里有个og:type字段，明确告诉系统“这是一个article、website还是product”，这本身就是轻量级的结构化信息。
对AI来说，一套规范的OG标签，相当于一份放在文件顶部的摘要卡片。它会在几毫秒内决定这个页面值不值得进一步抓取。如果你的og:title写得像营销口号，og:description里全是“领先”“第一”，AI可能直接放弃深入抓取——因为它已经判断这个页面内容是低信息密度的广告文本。
3.2 一套完整的OG标签配置
以企业官网最常见的场景为例，先把OG标签全列出来，再逐个说明用途。这里用某智能装备公司的产品页为例：
<meta property="og:type" content="product" /> <meta property="og:site_name" content="示例智能装备有限公司官网" /> <meta property="og:title" content="XH-500 高精度气密性检测仪 | 精度0.1Pa | 示例智造" /> <meta property="og:description" content="XH-500适用于新能源汽车电池包、医疗器械腔体等场景的气密性在线检测，支持三种通讯协议，出厂预置12个月校准周期。" /> <meta property="og:url" content="https://www.example-company.com/products/xh500" /> <meta property="og:image" content="https://www.example-company.com/assets/products/xh500-og.jpg" /> <meta property="og:image:width" content="1200" /> <meta property="og:image:height" content="630" /> <meta property="og:locale" content="zh_CN" /> <meta property="og:updated_time" content="2025-04-10T10:00:00+08:00" />这里有几个值得展开的细节。
og:title，用于AI摘要和社交分享。最佳实践是在页面title和品牌名之间做好平衡，不要太长，40到60个字符之间比较稳妥，核心关键词尽量靠前。在GEO视角下，要刻意避免“夸大形容词+空泛名词”的组合，比如“卓越品质行业领先”，因为模型在语义匹配时，这种描述几乎没有可匹配的信息点。
og:description，这是AI最容易直接引用为答案摘要的字段。写的时候要把“用户会问什么”和“这个页面能回答什么”对齐。比如上面例子中，用户问“XH-500有什么特点”，AI可能会直接从这段描述里摘出“支持三种通讯协议，出厂预置校准周期”等内容。
og:image，除了让分享卡片更完整，这里有一个技术细节：AI爬虫有时会读取图片的alt信息和标题来做内容判断，所以图片文件路径本身也应该包含关键词信息，而不是用抽象编号。
og:url必须和页面实际地址完全一致，不能带参数跳转。不少CMS系统会给页面带上utm参数，这会导致AI在判断“完整URL”时出现重复内容认知。
og:type建议按页面性质选：官网首页用website，产品页用product，文章页用article，活动页用article或website。很多团队一个type走天下，这会造成AI按类型聚合内容时出现错位。
3.3 OG标签与SEO的协同细节
OG标签和传统SEO的关系，有一点经常被忽略：OG title和页面title应该各司其职，而不是完全一样。
页面title主要服务于搜索引擎排名，可以更长、更适合关键词组合。OG title主要服务于AI和社交平台的摘要展示，应该更像“内容摘要”而不是“关键词组合”。举个例子，一个页面title是“气密性检测仪-XH-500-厂家直供-价格优惠”，作为OG title就太像广告了。更好的写法是“XH-500气密性检测仪的性能参数与采购指南”，信息密度更高，也更符合AI引用时需要的“陈述性文本”。
另外，og:description和meta description也建议差异化。meta description偏检索点击率优化，可以带一些钩子性语言；og:description偏语义匹配，应该更中性、更具体。如果两者共用同一句，AI在多个页面之间做差异比较时，会认为这个站点的内容区分度不够。
还要检查一个细节：og:title中不使用品牌简写。如果公司品牌是“示例智造”，但官网页面上偶尔用“示例智能装备”，偶尔用“示例”，AI在抽取内容时会捕捉到两个不同实体名，进而影响机构识别的准确性。统一品牌表达，是OG层面免费的GEO优化。
4. llms.txt：给AI爬虫的站点导览
4.1 llms.txt的定位与其他文件的关系
先明确llms.txt是什么：它是放在网站根目录下的一个纯文本文件，作用是给大模型爬虫提供一份站点内容的轻量级导览。类似一份精简版的sitemap，但它服务的对象不是搜索引擎的“排名抓取”，而是大模型的“理解与引用”。
它和robots.txt、sitemap.xml有什么区别？robots.txt是“禁止清单”，告诉爬虫哪里不能去；sitemap.xml是“索引清单”，告诉搜索引擎所有页面URL；llms.txt是“导读清单”，告诉AI哪种内容最重要、每个部分大概是什么。打个比方：robots.txt是门卫，sitemap是地图，而llms.txt是把地图上的重点区域用荧光笔标出来并写了备注。
为什么sitemap还不够？因为sitemap只是URL列表，AI爬虫抓下来所有URL之后，还需要逐个下载页面、解析正文、提取语义，成本很高。如果一个站点有几千个产品和几百篇文章，AI爬虫往往只浅尝一小部分就放弃了。llms.txt的价值在于：用几百行文本，把站点的核心领域、高价值内容入口、内容摘要一次讲清楚，让AI迅速建立对整个站点的整体认知，再决定深抓哪些页面。
4.2 一份可复用的llms.txt模板
llms.txt目前还没有完全统一的行业标准，社区约定一种基本的格式：文件顶部用YAML格式的front matter写站点元信息，正文用条目形式写URL清单和简介。下面是一份可直接套用的模板。我把注释放在字段后面，实际部署时应该去掉注释。
# 给大模型爬虫的站点导览 # 文件路径：https://www.example-company.com/llms.txt title: 示例智能装备有限公司 summary: 示例智能装备专注于精密零部件结构设计、气密性检测设备和智能生产线集成，总部位于某市高新区，为汽车、医疗器械、电子制造行业提供自动化检测解决方案。 core domains: - industrial-design: 精密零部件结构设计与制造工艺 - leak-test: 气密性检测设备的产品参数、选型指南与应用案例 - production-line: 智能装配生产线的集成服务与行业解决方案 - company-news: 公司动态、展会信息与行业技术文章 ## 公司核心信息 - [关于我们](https://www.example-company.com/about/): 公司简介、发展历程、资质荣誉与核心团队介绍。 - [联系方式](https://www.example-company.com/contact/): 办公地址、销售热线、售后服务邮箱与各区域办事处联系方式。 ## 产品与技术文档 - [XH-500 气密性检测仪](https://www.example-company.com/products/xh500): 高精度气密性检测设备，精度0.1Pa，支持Modbus TCP、Profinet、EtherNet/IP。 - [XT-300 泄漏测试台](https://www.example-company.com/products/xt300): 自动化泄漏测试台，适配新能源电池包、燃油箱、医疗导管等多种工件的快换治具。 - [选型指南](https://www.example-company.com/resources/selection-guide): 气密性检测设备的量程、精度、节拍与治具设计的选型方法。 ## 行业文章 - [锂电池包气密性检测的常见误区](https://www.example-company.com/articles/leak-test-battery-misconceptions): 从检测压力、保压时间、环境温度三个维度讲解测试稳定性。 - [医疗导管泄漏测试的标准与实现](https://www.example-company.com/articles/medical-tube-leak-test): 结合ISO 80369系列标准，介绍测试流程和夹具设计要点。这个模板体现了几个要点：summary是一段“给AI看的自我介绍”，写得像一段客观陈述，而非广告文案；core domains把站点的能力域拆成一二三四，AI基于这些域能快速理解“这家公司能解决什么问题”；分组标题用Markdown的二级或三级标题分隔，方便AI按组定位内容；每个条目只保留URL和一句摘要，不做长篇大论。
4.3 生成与维护的实操建议
生成llms.txt最忌讳的做法，是直接拿sitemap里的URL生成全量清单。几百个URL平铺在文件里没有任何导读价值，反而稀释了重点内容的信号。要记住：这个文件的定位是“导览”，不是“索引”。只放最核心、内容质量最高、最希望被当作引用来源的页面。我在实际操作中的经验是：企业官网通常控制在30到50个条目以内，分类不超过6个。
更新节奏上，产品更新、核心文章发布之后，要同步更新对应条目。如果官网是CMS驱动的，建议写一个简单的脚本，从数据库里自动生成llms.txt。生成逻辑并不复杂：从“上架产品表”里取产品名和简介，从“文章表”里取近期发布的高质量文章，再拼上固定的公司信息段落。部署到CDN上，设置较长的缓存时间即可。
还有两个容易踩的坑。
第一个是路径问题。llms.txt必须放在根目录，如果你的站点部署在子路径下（比如GitHub Pages的某个project），AI访问不了根路径，这个文件就形同虚设。
第二个是编码问题。llms.txt是纯文本文件，务必用UTF-8编码保存。如果文件里带了中文内容，又用了GBK编码，AI读取时会出现乱码，整个文件等于白做。生成后可以先用浏览器打开https://你的域名/llms.txt，如果显示正常再部署。
5. 从零到一：给官网做一次GEO体检
5.1 三步快速体检
看完前面三个工具，很多人会想“我们到底要先做哪个”。别急着动手，先用三个步骤做个快速体检，搞清楚自己站点目前最缺什么。
第一步，检查信息可发现性。用curl命令看一下官网的首页响应头和内容结构。
curl -s -A "Mozilla/5.0" https://www.example-company.com/ | head -c 2000重点看两件事：返回的HTML里有没有完整的title、description、OG标签、JSON-LD；另外确认这些内容是服务端返回的，还是需要JS渲染。如果网页是一个空壳的div包裹脚本，那你首要的问题不是GEO，而是让爬虫先能拿到你的内容。
第二步，检查内容语义是否清晰。随机挑选首页和两三个核心产品页，把页面正文复制出来，扔进文本编辑器里，假装自己是从零开始的AI，看能不能在十秒内判断出：这家公司是干什么的、服务对象是谁、核心产品是什么、有没有具体的参数和案例。判断标准是：页面里有没有“像话的内容”——有具体参数、有规范描述、有内部链接指向关联页面。如果页面全是“引领行业”“质量第一”这样的空话，OG和Schema做得再好也帮助有限，因为AI引用的最终是语义内容，而不是代码标签。
第三步，检查实体一致性。全站搜一下公司名称的写法是否统一，页面title是否有的带公司名有的不带，联系方式、地址是否在所有页面上一致。这一步用最简单的手工核对就能完成，但价值非常高。实体一致性是AI建立信任的基础，不一致的站点会被判断为“多主体混用”，很难被当作权威来源。
5.2 按优先级排期落地
体检之后，按成本和收益的维度排优先级。GEO落地的原则是先把基础的、一次性投入的做完，再谈持续迭代。
第一优先级：服务端渲染的静态HTML。如果这一步没做好，后面所有标签都可能是空中楼阁。技术方案上，最有效的是后端模板渲染。官网本来就需要SEO，用服务端返回完整页面内容，是技术和业务双收的选择。
第二优先级：OG标签和meta标签规范。收益高、成本低，做一轮全面的标签检查通常半天就能搞定。重点是把title、description、og系列字段配置完整，并确保全站格式统一。
第三优先级：llms.txt。成本很低，只需要整理核心内容链接并生成文件，但它依赖站点本身的信息架构清晰。有些网站自己的内容体系就是乱的，产品线分类不清、文章栏目混杂，这种情况下心急写llms.txt反而会把噪声喂给AI。先把内容分组理清楚，再生成导览文件。
第四优先级：Schema结构化数据。收益最高、工作量也最大。建议按“Organization + 首页优先，再做产品页和FAQ”的顺序推进。不要试图一轮把所有类型全部补齐，分批次完成，每批做完测试后再进行下一批。
5.3 效果验证：怎么知道AI开始引用你了
落地之后，效果不是立刻显性的，但可以用几组方法验证。
方法一，直接对话验证。在多个主流AI问答产品里输入行业相关的问题，比如你们服务所在的细分领域加“推荐”“有哪些供应商”“哪家比较好”这类词，看答案里有没有出现你的官网链接或公司名。这个验证要反复做几轮，因为同一问题在不同时间得到的回答可能不同。
方法二，抓取日志监控。查看服务器访问日志，如果出现了来自AI基础模型服务商、知名搜索引擎bot等固定UA的抓取记录，说明爬虫已经开始高频访问你的站点。这些记录中如果出现了对llms.txt、产品页、文章页的抓取，说明爬虫正在阅读你的核心内容。
方法三，检索命中监测。定期在AI产品中追问“根据某公司官网，……”这类长尾问题，看是否能定位到你的官网。如果答案中出现了品牌名和具体产品名，说明你的网页内容已经被“内容寻址”到。
效果观察周期方面，一般做完全套优化后，2到4周内能看到AI回答中开始出现官网线索。重点不是等，而是持续更新内容。GEO和SEO一样，内容不更新，已建立起来的引用优先级也会被其他站点的更新慢慢挤掉。
6. 那些实操里容易翻车的细节
6.1 别把FAQ做成“自问自答的广告位”
很多企业官网的FAQ页面，问题全是“贵公司有哪些优势”“为什么选择我们”，答案全是“行业领先”“经验丰富”。这种FAQ在传统SEO语境下问题不大，但在GEO语境下会直接让AI降低对你内容质量的评价。
为什么？因为AI模型在判断FAQ是否值得引用时，会做一道“事实性审查”，问题的答案是具体参数、明确标准、可验证事实的，才可能被引用。而当答案大而空时，模型倾向于忽略整段内容，甚至降低整页的可信度。
正确做法是，FAQ里只放真实用户问过的高频问题，答案里写清楚数字、型号、标准、流程。如果产品已经迭代，记得同步更新FAQ答案，不要出现“新版产品已支持XX功能”而FAQ里写的还是旧版说明的BUG。
6.2 Schema代码“飘了”却没被渲染出来
这是我用过一个CMS系统时真实遇到的麻烦：模板文件里明明写了JSON-LD脚本，但页面源代码里怎么都找不到。排查后发现，是模板引擎里把script标签的内容当成了HTML注释的一部分，输出时被无意识过滤了。所以代码写完之后，一定要用“查看源代码”而非“检查元素”来确认脚本是否真出现在最终HTML中。查看源代码看到的是服务器交付给浏览器的原生内容，检查元素里看到的是浏览器渲染后的内容，后者即使能看到脚本，也不能代表爬虫能拿到。
另外，动态页面里通过JavaScript往DOM里插入JSON-LD的做法，对Google问题不大，但对一些新兴的AI检索爬虫来说风险很高。原则就是：如果服务器端能输出，就尽量不要依赖前端注入。
6.3 OG图片和页面语言不一致
有个细节很少被提到：og:image的缩略图如果在社交平台上直接展示，会被用户忽略，但AI不会。AI在读取图片引用时，会同时读取图片所在目录、文件命名和alt属性。很多官网的OG图片就是一张背景图配大字报，文件名叫“banner_2024.jpg”，alt还是空的。正确姿势是，为每个核心页面制作一个专门的OG配图，把页面核心信息浓缩成“标题+一句摘要+品牌名”的画面，文件命名用描述性的英文短句，比如“xh500-leak-tester-01.jpg”，配合适当的图片alt文本，包括关键词。
6.4 llms.txt里的链接没有做自检
如果官网有页面改版、内容合并，llms.txt里的URL很容易成为死链。AI爬虫遇到404，对其余链接的抓取优先级都会下降。所以每次版本上线，要顺手用脚本扫一遍llms.txt里所有链接是否返回200。这件事没有太多技术含量，贵在坚持形成习惯。
另外强调一下：llms.txt里不要放需要登录才能访问的链接。如果某些核心内容在登录墙后面，宁可不放。AI爬虫拿不到内容还反复返回302，这种体验会明显伤害站点的可引用性。
6.5 只做了标签没改内容，等于白做
最后这个坑，操作中遇到最多。团队花了一周把Schema、OG标签、llms.txt全部做完，兴致勃勃等着AI引用，结果两个星期过去毫无起色。打开页面一看，问题出在内容本身。Schema标注的是一个“产品页”，但页面正文只有两行说明和三张模糊图片，没有任何参数、用途、使用步骤的实质性描述。你给了AI再清晰的路标，路标指向的仓库却是空的，AI拿什么引用？
所以要反过来理解：Schema、OG、llms.txt不是GEO的主体，而是内容的“呈现方式”。先把每个核心页面的内容做扎实：产品页写清楚规格参数和应用场景，文章页写清楚具体思路和操作建议，关于页面写清楚服务范围和能力边界。内容扎实了再做标签，效果会非常好；内容空洞时做再多元数据，也只是在把一个空箱子打包得更精美。
写在最后
做了这么多年官网运营，个人体会最深的一点是：GEO本质上不是一项“技术工作”，而是一次“重新站在机器视角理解内容”的思维切换。过去你写文案，脑子里想的是“人看到什么”；现在你还需要加一层——当AI把我的页面从HTML里抽出来，它看到的是一段语义清晰、结构完整、可以放心引用的好内容吗？
我建议你从今天开始，先花半小时把官网首页的源代码翻出来，看看有没有og标签，有没有JSON-LD，文字内容是否扎实。把这三个问题的答案理清，你的GEO落地路径，实际上就已经确定了七成。剩下的事，就是按照本文的优先级一步步执行，然后每周在AI问答里搜索一次自己行业的核心词，观察那个“被引用”的变化。这个变化来得可能没有搜索排名那么猛烈，但一旦被AI记住，它会成为你官网在这个新时代里最长青的流量入口。
