1. 为什么把GEO做成开源系统而且是“全域”的1.1 GEO和SEO不是替代关系是叠加关系做内容和做网站的朋友应该都有体感过去十年我们谈的搜索引擎优化本质是“索引排名”关键词密度、外链权重、TDK这些老词条撑起了一整条产业链。但这两年生成式搜索入口起来了——你打开任何一个AI搜索工具问一个问题它先给你一段整合答案底下才附带引用来源。用户不再点开十个蓝色链接逐个找答案而是直接读AI生成的那段话。流量结构变了我们这套老打法就有一半失效了。全域GEO全称是Generative Engine Optimization很多人叫它“生成式引擎优化”也有人叫“生成式搜索优化”。它优化的不是排名而是“被理解、被引用、被推荐”的概率。传统SEO服务的是爬虫GEO服务的是大模型阅读与推理链路。两者的关系不是替代是叠加。一个页面可以既在传统搜索里排名不错又能被AI搜索作为参考来源准确引用这两件事并不冲突。真正冲突的是很多人还在用纯SEO思路做AI搜索的活生产出一堆堆砌关键词但没有清晰语义的页面AI读不懂自然也没法引用。1.2 “全域”到底覆盖了什么这个开源项目名字里带的“全域”两个字不是营销话术。它指的是三个层面的覆盖第一层内容本体。包括文章标题、正文结构、摘要、FAQ、案例、对比表这些实际阅读材料。第二层机器可读层。包括网页元数据、JSON-LD结构化数据、sitemap、robots.txt、llms.txt。第三层实体关系层。包括品牌、产品、服务、评价对象之间的关系图谱也就是让AI知道“你是谁、你卖什么、你和谁有关”。前两年大家做SEO只需要搞定第一层偶尔做做第二层的schema标记现在做GEO三层都要打通。我给项目起名“全域”就是想强调一个观点不要再把优化拆成“页面内”和“页面外”两张皮去做了AI搜索是把整个站点当作一个知识源来理解的。你的落地页写了一堆产品优势但站点首页没有组织信息产品页没有FAQ关于页没有服务地域说明那AI能抽取的信息就是零散的。全域优化的意思是你站点的每一层都在为“让AI更好理解你”服务。1.3 为什么必须开源项目刚开源的时候有人问我GEO方案本身还没有统一标准你急着开源一套源码出来图什么我图的是透明和共建。GEO很容易走偏成“操纵答案”一套黑盒的GEO工具本质上就是把内容包装成机器更容易拿取的样子厂商做黑盒谁都不知道它的处理逻辑到底是什么。这个方向非常危险。只有源码级开源别人才能审计你的算法才能确认你是在降低AI的理解成本而不是在做内容操纵。透明度本身是这个领域的底线。第二点生态太碎了。现在做GEO的团队各有各的schema写法各有各的实体抽取逻辑完全没有共识。开源一套带默认配置和清晰目录结构的系统至少能给同行一个起点。遇到“语义显式化到底应该输出什么格式”“FAQ结构化数据该嵌套在哪几层”这类问题直接看代码就能对答案。第三点企业内容有保密诉求。很多公司不愿意把内部产品库、价格体系、知识文档丢给第三方SaaS平台去分析。开源源码支持本地部署数据完全不出内网这一点在to B场景里特别重要。第四点社区生态能持续养项目。实体词典、prompt模板、schema模板、新模块这些都可以通过社区贡献持续积累。项目上线三个月收到的issue里有一半是新增领域词典的有一半是给结构化数据生成提bug的这些都是我一个人维护闭合项目得不到的资产。顺带说下许可证选型。发布在Gitee上的开源项目新手常纠结选MIT还是Apache-2.0还是GPL-3.0。我的建议是如果希望商用和闭源集成都放开选MIT或Apache-2.0如果要求别人改完也必须开源选GPL-3.0。本项目用的是Apache-2.0它比MIT多一条专利授权条款对代码贡献者和使用者的权益保护更完整同时又不像GPL那样有强开源传染性。这个选择在Gitee上建仓库的时候就能直接勾选后续如果想换许可证必须在改动前做版权记录这点踩过坑的人都懂。2. 核心模块一语义显式化让AI第一次就读懂你2.1 先搞清楚AI是怎么“读懂”页面的大模型不是像人一样把你整个网站从头到尾读完。它在回答用户问题时通常先做召回从一个网页库或者知识索引里拉出一批候选文档再把候选文档切块、喂给阅读器抽取答案最后组织成一段回答。这个“召回-过滤-阅读-生成”的链路里第一道门槛就是语义匹配。用户问“iPhone 12电池更换要多久”如果你的页面标题是“2025年值得入手的数码好物”哪怕正文里写了“我们提供iPhone电池维修45分钟搞定”AI要把它和“iPhone 12”“电池更换”“多久”这几个概念关联起来就需要跨过一段很长的语义距离。反过来要是标题、摘要、正文里都出现“iPhone 12 电池更换 45分钟 门店服务”召回阶段就很容易被选中。我做一个很直观的同类对比。两家维修店的页面A页面标题是“专业手机维修服务”正文讲“我们服务态度好、配件原装、价格实惠”。B页面标题是“iPhone 12电池更换服务45分钟完成支持门店与上门”正文里明确写“适配机型iPhone 12/12 Pro/12 Pro Max”“更换时长约45分钟”“服务方式门店更换、工程师上门”。当用户在AI搜索里问“iPhone 12换电池需要多久”的时候B的页面几乎必被引用A的页面则大概率消失在候选池里。区别不在于谁的排版更好看而在于谁把实体、属性、条件、参数都显式化地写出来了。这就是语义显式化要解决的问题把藏在长文里的信息点用无歧义的、机器可抽取的方式明明白白摆出来。2.2 语义显式化的实现步骤项目的语义模块设计成了一条五步流水线。第一步文本清洗。爬虫拿到页面后先去导航、侧边栏、广告位、版权块这些噪声只保留正文内容。这一步做不干净后面所有抽取都会被污染。我用的是主内容抽取规则加一个简单的BR标签分段校准比起直接用大模型全文抽取省了不少token。第二步实体识别。先跑词典规则再调LLM做边界修正。比如“iPhone 12”这个实体规则词典里命中“iPhone数字”边界直接划好遇到“12代iPhone用户”规则会切错这时候交给LLM做边界修正。领域词典放在config/semantic_dictionary.yaml里按行业维护哪类实体抽不准就补哪类词条。第三步属性补齐。识别出实体之后系统会检查这个实体在当前文档里有没有对应关键属性。比如产品类实体关键属性是型号、价格、适用范围、服务周期服务类实体关键属性是时长、地域、交付方式、售后条款。缺了属性系统会在语义输出文件里打一个“incomplete”标记。第四步三元组抽取。这一步是把语义拆成可以机器推理的最小单元格式是“实体-关系-实体”。比如(iPhone 12, 维修服务, 电池更换)(电池更换, 服务时间, 45分钟)(本店, 服务方式, 门店/上门)这些三元组会输出成一个JSON文件作为后续RAG索引的知识种子。第五步生成AI摘要与问答对。每个核心页面最终要产出“一句话被引用版本”和若干条FAQ问答对。一句话被引用版本通常60到120字必须包含实体名、数值、范围、条件。FAQ问答对则直接复用页面里已有信息一条问题配一条明确的答案。下面贴一段语义输出的参考格式{ entity: iPhone 12, attribute: battery_replacement, duration_minutes: 45, service_scope: [walk_in, on_site], models: [iPhone 12, iPhone 12 Pro, iPhone 12 Pro Max], short_answer: iPhone 12电池更换服务支持门店与上门时长约45分钟价格以门店当日报价为准。, faq: [ { question: iPhone 12换电池需要多久, answer: 门店更换约45分钟工程师上门时间视预约情况而定。 } ] }这个格式不是死的源码里提供了schema配置文件不同行业可以改字段。但结构上建议固定保留entity、short_answer、faq三个键因为这三个是后续结构化数据生成、RAG索引和人工审核最容易复用的部分。2.3 操作细节与注意事项语义显式化最容易犯的错是为了“让AI读懂”而把页面写成机器语言。我的原则很简单先面向真实用户写清楚一个事情再做显式化加工而不是先面向AI堆词。操作上有几个注意事项。第一别给每个页面都做全量语义化。一个博客站的关于页、产品页、FAQ页做全量就够了普通新闻动态做一层摘要即可否则人力成本会拖垮内容团队。项目里增加了“priority”字段配置里可以按路径给页面分优先级只有高优先级页面跑完整管线。第二多义词和缩写必须在首次出现时给完整定义。比如你写“本系统支持SDK接入”AI不知道SDK是什么意思你需要在同一页或实体词典里给出“SDK软件开发工具包完整定义”。这个在代码里是显式检查项检测到未定义缩写直接标记为语义不完整。第三做完语义显式化之后建议用大模型自测法验证效果。把优化后的内容丢给任意一个LLM连续追问几个目标关键词看它能不能正确抽取实体、属性、条件和答案。这个自测方法写在了项目README里实测比任何指标都直观。3. 核心模块二结构化数据生成把“给AI看的说明书”自动化3.1 结构化数据为什么重要语义显式化做的事情相当于你想清楚了一件事怎么跟别人解释结构化数据做的事情则是把解释要点写在一张卡片上直接递到AI手里。前者解决“读懂”的问题后者解决“读得又快又准”的问题。系统内置了JSON-LD生成器遵循Schema.org标准词汇表。为什么选JSON-LD而不是Microdata或RDFa因为JSON-LD可以独立于HTML标签层级一块脚本放到head区即可不影响页面视觉结构主流搜索引擎和AI爬虫的解析支持也最完整。帮你理解一下结构化数据在AI查询链路中的价值。当AI搜索“某款软件是开源的吗”如果站点提供了SoftwareSourceCode类型的JSON-LD里面写了codeRepository、license、programmingLanguage字段AI可以直接从结构化数据里拿到答案而不是去正文里全文检索“开源”这个词。相当于你主动交出一张写满答案的卡片AI自然更乐意引用你。3.2 系统内置的结构化生成规则源码里默认配置了七类结构化数据生成规则类型触发场景关键字段Article文章详情页headline, datePublished, author, imageFAQPageFAQ区块/问答页mainEntity, question, acceptedAnswerProduct产品/服务页name, offers, price, availabilityBreadcrumbList全站导航item, name, positionOrganization全站首页name, url, logo, sameAsSoftwareSourceCode开源项目/工具页codeRepository, license, programmingLanguageVideoObject视频内容页name, uploadDate, duration, thumbnailUrl每种类型的生成逻辑都对应一个yaml模板文件。拿FAQPage举例系统会从语义模块输出的faq数组里读取问答对再套用JSON-LD模板生成{ context: https://schema.org, type: FAQPage, mainEntity: [ { type: Question, name: iPhone 12换电池需要多久, acceptedAnswer: { type: Answer, text: 门店更换约45分钟工程师上门时间视预约情况而定。 } } ] }关键点在于mainEntity嵌套结构新手常写错把Question直接挂在顶层校验器就会报缺少聚合容器错误。项目里内置了一个轻量校验器在生成后立刻检查JSON格式、必填字段和嵌套层级不合法就不输出避免脏数据污染页面。3.3 生成流程与代码接入系统的结构化数据生成模块做成了独立API。部署之后你对一篇文章页发起请求POST /api/geo/structured { url: https://example.com/article/123 }返回结果里带一段可以直接插入head的JSON-LD脚本。批量场景下传入一个URL列表文件系统会逐页分析并输出一个结构化数据包文件按域名和路径组织好方便直接用脚本合并到CMS模板里。具体接入方式取决于你的建站工具。用Hexo或Hugo这类静态站点的直接在模板里预留一个JSON-LD注入点把系统生成的数据用变量塞进去。用WordPress的企业站可以在functions.php里注册一个输出钩子把生成的JSON-LD打印到页面头部。不管哪种方式都要注意一点结构化数据要和页面正文保持一致标题改了、价格调了JSON-LD里的字段必须同步更新否则极容易被判定为不相关。3.4 配套的AI可见性文件只做页面内的结构化还不够站点级的基础设施也要跟上。项目里加了三个配套文件的生成器。第一个是llms.txt。这是站点根目录下的纯文本文件用Markdown格式写清楚站点的核心用途、主要栏目、高价值资源与XML sitemap路径。它相当于“给AI手写的站点地图”。代码里生成器会读取站点首页的导航结构和核心栏目列表自动拼装# Example Site 专注手机维修服务提供iPhone、iPad电池更换、屏幕维修服务。 ## Core resources - [iPhone电池更换服务](https://example.com/services/iphone-battery) - [常见问题](https://example.com/faq) - [Sitemap XML](https://example.com/sitemap.xml)第二个是robots.txt的AI爬虫放行配置。在原有SEO规则基础上增加GPTBot、ClaudeBot、PerplexityBot等常用AI爬虫的Allow指令。这一步很多人忽略结果是页面在传统搜索里收录正常但在AI搜索里始终抓不到。第三个是ai_sitemap.xml。把经过语义显式化和结构化处理的高价值页面单独列一份提交给AI爬虫优先抓取。这份地图从上到下就放核心服务页、产品页和FAQ页不放文章聚合页保证AI爬虫的预算花在最该花的地方。4. 源码部署与实操拿到代码后怎么落地4.1 技术栈与目录结构项目选择了Python 3.10作为主语言底层服务用FastAPI配合APScheduler做定时任务页面抓取用httpx加BeautifulSoup语义抽取通过适配层对接各家LLM API。目录结构拆分得很清楚geo-open-source/ ├── app/ │ ├── main.py # FastAPI入口 │ ├── api/ # API路由 │ └── services/ # 核心服务 ├── modules/ │ ├── crawler/ # 页面抓取与清洗 │ ├── semantic/ # 语义显式化 │ ├── structured/ # 结构化数据生成 │ └── geo_files/ # llms.txt / ai_sitemap生成 ├── config/ │ ├── config.yaml # 主配置 │ └── semantic_dictionary.yaml # 领域词典 ├── data/ # 输出数据目录 ├── tests/ # 测试用例 └── requirements.txt为什么不用Go或Node因为这套系统的核心难点在自然语言处理链路Python生态里可用的标注工具、语义抽取框架、prompt管理模块最全内容团队和个人开发者上手最快。FastAPI不是为了炫技而是它有自动API文档部署后打开/docs就能调试所有接口对非专业后端出身的内容运营者非常友好。4.2 部署步骤部署过程一共五步。第一步克隆仓库git clone https://gitee.com/你的命名空间/geo-open-source.git cd geo-open-source第二步安装依赖并配置环境变量pip install -r requirements.txt cp .env.example .env.env里需要填LLM API Key、默认站点域名、爬虫频率限制这几个必填项。如果没有LLM API Key语义抽取模块会自动退化为词典规则模式输出质量会弱一些但基础的结构化数据生成功能可以正常使用。第三步配置主配置项vim config/config.yaml配置文件里需要填站点基本信息、领域词典路径、结构化数据开关、需要爬取的路径规则和排除规则。第四步启动服务uvicorn app.main:app --host 0.0.0.0 --port 8000第五步浏览器打开http://localhost:8000/docs先调健康检查接口确认服务正常然后拿一个测试URL跑一遍完整管线。4.3 第一次接入实操我拿一个典型的个人博客站点举例完整流程是这样的。先对目标文章页发起语义化和结构化分析POST /api/geo/process { url: https://example.com/posts/iphone-12-battery-replacement, priority: high }系统会返回三个输出语义摘要JSON、结构化数据JSON-LD、建议的llms.txt追加段落。拿到JSON-LD后在Hexo的主题模板head.ejs里插入一个区块script typeapplication/ldjson {{ geo_jsonld }} /script接着把llms.txt生成器跑一遍输出文件放到站点根目录。再到robots.txt里增加AI爬虫的放行规则User-agent: GPTBot Allow: / User-agent: ClaudeBot Allow: /最后做一次校验。项目里准备了校验脚本可以对比输入页和处理后的JSON-LD是否一致import json from modules.structured.validator import validate_jsonld with open(output/article_123.jsonld) as f: data json.load(f) errors validate_jsonld(data) assert not errors, errors print(JSON-LD valid)第一次接入完整跑下来正常工作一到两个小时。多数时间不是花在系统上而是花在配置领域词典和梳理页面优先级上。4.4 生产环境注意事项部署在生产环境时有几个细节要提前处理。第一爬虫频率控制。源码默认每个域名每秒最多抓取一个页面避免给对方站点造成压力。真跑起来如果目标站点有反爬策略建议再加一层随机延时和UA轮换。第二数据库存储。单机测试时输出直接落到JSON文件就行生产环境建议挂SQLite或PostgreSQL记录每条URL的处理状态、生成时间和校验结果方便增量更新。跑定时任务时只处理最近变动的URL避免全站重复分析。第三Docker部署。项目根目录提供了docker-compose文件用docker compose up -d即可拉起服务和数据库适合直接部署在云服务器上。与本地启动的差异只在环境变量注入方式其余配置完全复用。5. 常见问题与排查实录5.1 为什么生成的结构化数据不通过校验这是收到最多的反馈大多数问题出在三个地方。第一是字段名错误。FAQPage必须用mainEntity包裹QuestionQuestion里用acceptedAnswer嵌套Answer一个层级都不能错。真实错误案例是这样的{ context: https://schema.org, type: Question, name: iPhone 12换电池需要多久, acceptedAnswer: { type: Answer, text: 约45分钟。 } }缺少FAQPage和mainEntity校验器直接判定无效。正确版本见3.2节示例。第二是重复FAQ。语义模块在抽取问答对时可能把同一个问题从不同段落里各抽一遍两条答案措辞略有差异。这会导致校验器报“mainEntity包含重复问题”警告。我在代码里加了模糊去重基于问题文本的字符相似度和embedding距离双重判定但建议审核阶段仍然人工扫一眼。第三是缺少必填字段。Organization类型必须包含name、url、logo有些站点没在配置里填logo地址生成器就会卡住。解决办法是把站点级信息在config.yaml里一次性写好组织信息属于全站共享配置不需要每页重复填。5.2 语义抽取结果不准怎么办语义抽取不精确绝大多数情况下不是模型问题是领域词典没有迭代到位。项目在手机维修领域测试时最开始“屏幕总成”经常被LLM识别成“屏幕”缺少了“总成”这个部件层级。在semantic_dictionary.yaml里补上“屏幕总成”“电池总成”“排线”这几个领域词条之后关系抽取的准确率明显提升。配置示例domain: mobile_repair entities: - name: 屏幕总成 aliases: [屏幕, 显示屏总成] required_attributes: [机型, 维修时长, 价格区间] - name: 电池更换 aliases: [换电池, 电池维修] required_attributes: [机型, 维修时长, 保修政策]还有一层兜底置信度阈值。语义模块抽取每条三元组时会附带一个置信度分数默认低于0.6就不输出避免低质量结果污染后续生成。这个阈值可以在config.yaml里调追求召回就调低追求精度就调高。对需要人工审核的团队建议在数据目录里保留审核队列一键标记“采纳”或“丢弃”后续重新训练词典时这些标记就是训练样本。5.3 做了GEO之后多久能看到效果这个问题几乎每个人都会问说实话很难给一个统一答案。传统搜索引擎的收录周期通常一到四周AI搜索的抓取行为更不稳定。有些内容当天就在AI搜索的答案里出现引用有些做了结构化一个月也没有一个引用。我的建议是把观察重点放在四个指标上一是AI搜索对话里直接被点名引用品牌名或域名出现次数二是通过AI推荐带来的落地页访问量三是结构化数据校验通过率四是llms.txt文件被外部工具引用的情况。我拿自己的独立站做过一次实验选了三个页面做语义显式化加结构化数据一个月内其中两个页面被某AI搜索端引用了三次虽然不是大规模数据但已经能说明方向对了。需要明确的是GEO不是一锤子买卖内容更新之后要持续跑增量处理而不是做个一次性的脚本就走人。5.4 许可证、合规与开源共建项目采用Apache-2.0许可证允许商用、允许修改、允许闭源集成条件是保留出处声明。引用第三方组件时需要确认各自许可证兼容性比如某些NLP库采用的是AGPL许可证拖进项目里会把整个作品传染成AGPL这种依赖在requirements里被标注为可选扩展默认不安装。参与共建的入口有三个方向。第一个是补领域词典这也是贡献门槛最低的方式填一个yaml文件提交PR就行。第二个是扩展schema模板比如社区有人提出增加“Event”类型适配活动报名页面这就是很典型的模块扩展。第三个是prompt模板投稿不同行业对语义抽取的提示词写法差异很大欢迎在modules/semantic/prompts/目录里提交你调试好的版本。提PR之前建议先跑一遍tests目录下的测试用例保证新模板不影响旧规则的输出。仓库里也建议配置GitHub Actions或者Gitee Go每次提交自动跑Python语法检查和JSON-LD样例校验这个我在项目里已经加上了。6. 这个系统后续还能怎么扩展6.1 从单页优化到全站资产地图目前系统一次只处理一个页面或者一个URL列表后续版本可以做全站内容资产地图。爬完整个站点后按页面维度输出一张表哪些页面已经做了语义显式化、哪些页面缺少结构化数据、哪些页面摘要为空、哪些页面是外部链接聚集的引用核心页。这张地图比单页报告有用得多因为AI搜索最终是对整个站点的认知而不是只看一个页面的姿态。6.2 结合大模型工作流与知识图谱语义显式化产出的三元组本身就是构建知识图谱的好原料。短期可以接入RAG索引提高检索质量中期可以接GraphRAG把实体关系作为检索路径让AI搜索的答案更精确。开源生态里这个方向已经有很多上游项目系统需要做的只是设计好输出格式让知识图谱工具链可以直接消费。6.3 多语言与多模态扩展做跨境电商和海外独立站的朋友对多语言GEO的需求特别强烈。现在系统还是按单站点单语言处理的后续可以加语言识别和多语言语义模板。多模态方向也是一样视频站点的VideoObject结构化数据已经有基础接下来可以自动生成视频字幕级别的语义描述让AI搜索能理解视频内容而不只是靠标题猜。6.4 数据看板与开放API目前所有处理日志都是文件级别的后续要做数据看板统计每个域名的语义完整性、结构化数据覆盖率、引用增长趋势。同时也计划把GEO处理能力开放成标准API这样CMS插件、无代码建站工具都能直接调用把“AI可理解”变成内容生产管线里的一个默认环节而不是后期补救动作。个人体会是这套系统最大的意义不在于某个具体算法有多强而在于它第一次把“语义显式化”和“结构化数据生成”这两件抽象的事拆解成了一串可执行、可审计、可迭代的工程步骤。开源之后不少做独立站和内容出海的朋友下来跑了一遍反馈说以前只知道要“给AI友好的内容”现在终于知道具体该改标题还是该加FAQ该补实体词典还是该调schema模板。拿到代码之后建议先拿自己站上访问量最高的三五个核心页面跑一遍完整管线比看任何教程都来得直观。有问题直接提issue或者带上你的领域词典来聊这类共建正是这个项目最需要的。