GEO优化实战：用源码搭建检测与改造工具

简介：这是一份生成式引擎优化（GEO）可运行源码包，面向希望了解或落地人工智能搜索优化技术的开发人员、技术学习者及企业数字化决策者。资源通过一个实际项目完整展示生成式引擎优化系统的搭建过程，代码中体现了人工智能信息投喂、关键词内容填充和大模型训练等核心功能的实现路径，读者可从源码层面理解生成式搜索引擎优化如何帮助企业品牌在人工智能回答中获得优先展示。压缩包共三个文件，包含运行配置、页面代码和版本忽略规则文件，整体只有6KB，结构精简但功能闭环，便于直接运行体验或二次开发。目前已有四百二十二人学习下载。对于想要快速搭建一个生成式引擎优化演示、研究其推荐机制或在此基础上扩展功能模块的开发者，这份源码提供了清晰的起点，可结合具体业务场景调整内容输入与参数配置，验证不同关键词策略对人工智能搜索曝光度的影响。

1. GEO 优化到底是什么：先搞清它在优化谁

同一个页面，在传统搜索引擎里能排进前三，换到生成式搜索里却一次都没出现在引用来源中；而另一篇没做任何外链的技术笔记，被 AI 答案反复引用。这种落差不是玄学，核心在于生成式引擎有自己的取数逻辑。GEO 优化（Generative Engine Optimization，生成式引擎优化）做的就是让内容在抓取、理解和引用选择三个阶段都不掉链子。它和 SEO 有关联，但目标不再是关键词排名，而是“被 AI 答案引用”。本文要讲的源码搭建，就是把这套逻辑做成可运行的检测与改造工具，让站点从黑匣子里拿到一份可量化报告，照着改、能复现。适合独立站内容同学、文档维护者，以及想批量管理多个页面的开发者。

2. 生成式引擎的取数逻辑：为什么你的页面在 AI 回答里被折叠

动手写代码前，得先想明白生成式引擎怎么决定引用谁。很多人一上来就调关键词密度，那是拿 SEO 的老地图找 GEO 的新坐标，大概率跑偏。只有把取数的三个环节拆开，才知道源码里该检测什么、检测结果到底有什么用。

2.1 从检索到生成：引用源被选中的三个环节

生成式搜索并不是直接拿整个互联网喂给大模型，它也有类似传统搜索的管道，只是越往后差异越大。第一个环节是抓取，引擎派出官方抓取器按 robots 规则访问页面；第二个环节是索引，抓回来的 HTML 会被清洗、切段，转成适合向量检索和召回的结构；第三个环节才是检索与生成，用户提问后先召回候选片段，再对片段做排序，最终挑选一到 N 个来源拼进答案。

很多站点的问题出在第一个环节：robots 规则或防火墙策略把官方抓取器挡了，页面压根没进索引，后面再谈优化都是空的。所以源码搭建项目里，我第一件事永远是做抓取可见性检查，而不是直接跑内容评分。

排查抓取可见性，最直接的办法是看服务访问日志，统计自动抓取流量的 UA 分布。

# 排查：统计访问日志里可能的自动抓取流量，按 UA 聚合 grep -iE "bot|crawler|spider|ai" /var/log/nginx/access.log | \ awk '{print $NF}' | sort | uniq -c | sort -rn | head -30

这里的grep -iE忽略大小写并匹配 bot、crawler、spider 等常见特征词，$NF取日志最后一列，在默认 nginx 日志格式里正好是 User-Agent。如果你的日志格式带了额外字段，先打印一行样例确认列位置，再决定要不要改成$12之类的具体列号。看到结果里有陌生 UA 且请求频率很高，先别急着封，对照各家生成式引擎公开的抓取器说明逐条确认，再把规则加进防火墙白名单。

2.2 GEO 与 SEO 的真正差异：关键词排名没了，上下文权重还在

传统 SEO 的关键词排名、外链数量、点击率这些信号，在生成式引擎里权重被大幅稀释。生成式引擎生成答案时更关心三个东西：页面里有没有可验证的实体、有没有量化信息、内容片段能不能独立回答一个小问题。这三个属性共同组成了所谓的“上下文权重”。

举个例子，页面上写“性能提升明显”，生成引擎很难把它转成一条可引用的证据；如果写成“在 16 核虚拟机上把并发从 50 提升到 200，P95 时延从 1.8 秒降到 0.4 秒”，这段话里的数字、硬件规格、版本后验关系都是独立可验证的实体，被引用的概率会高很多。这不是要求你每句话都堆数字，而是要求关键结论具备事实锚点。

这也是为什么源码工程项目里要用“实体密度”“量化标记数量”这类指标来近似上下文权重。它们不是官方标准，但能让你在发布前就发现页面缺了什么。

2.3 页面要素的优先级排序：可引用性比可读性更值钱

页面可读性高，针对的是人类读者；可引用性强，针对的是生成引擎的片段挑选器。一篇文章写得再流畅，如果关键结论藏在一大段散文中间，引擎很难把它单独切出来当引用源。我一般把要素排成几个优先级：抓取可见性排在第一位，抓不到全归零；其次是正文自包含，一段话能独立回答一个问题；再往下是结构化数据、表格与量化信息，然后是标题层级和摘要。

先别急着写评分器，先做一个页面要素盘点脚本，把基础事实摸出来。下面的脚本输入一个本地 HTML 文件，输出当前页面的 GEO 要素清单。

# page_audit.py —— 快速盘点一个 HTML 页面的 GEO 要素 import re import sys import json from bs4 import BeautifulSoup def audit(html: str) -> dict: soup = BeautifulSoup(html, "html.parser") title = soup.title.get_text(strip=True) if soup.title else "" text = soup.get_text(" ", strip=True) return { "title": title, "h1_count": len(soup.find_all("h1")), "h2_count": len(soup.find_all("h2")), "has_meta_description": bool(soup.find("meta", attrs={"name": "description"})), "json_ld_blocks": len(soup.find_all("script", type="application/ld+json")), "table_count": len(soup.find_all("table")), "quant_markers": len(re.findall(r"\d+(?:\.\d+)?\s*(%|ms|倍|个|GB|MB)", text)), "word_count": len(text.split()), } if __name__ == "__main__": html = open(sys.argv[1], encoding="utf-8").read() print(json.dumps(audit(html), ensure_ascii=False, indent=2))

这个脚本的quant_markers用正则去匹配百分比、毫秒、倍、容量单位等关键字，用来衡量页面里的量化信息密度。正则里的单位按自己领域补：做电商加“元、件”，做服务器性能加“ms、核、GB”就够用。word_count统计的是去掉标签后的纯文本，JS 动态渲染出来的内容不在这一步统计，这正好呼应第 5 章要讲的渲染差异坑。跑一遍脚本，你就知道当前页面在抓取之外最缺哪一块，再决定下一步是补结构化数据还是重构正文段落。

3. 用源码搭建最小 GEO 优化链路：从模块导入到第一份跑分报告

可运行源码的核心不是代码多炫，而是拿下来能跑、换台机器还能跑。我习惯把工程拆成三个模块：抓取、解析、评分。先做环境隔离，再做冒烟测试，最后跑出第一份报告。整个链路不长，但每一步都卡着生成式引擎的取数逻辑来设计。

3.1 跑通前 20 分钟：环境隔离、依赖安装与模块导入

拿到源码包后，先别急着看算法，先把依赖装起来。依赖装不上，后面全白搭。我通常用 venv 做隔离，避免和系统 Python 的包打架，然后按包里的 requirements 文件装依赖，最后做一次模块导入冒烟测试。

# 假设解压后的工程目录叫 geo-project cd geo-project python -m venv .venv source .venv/bin/activate python -m pip install -r requirements.txt python -c "import geo_detect; print('module ok')"

这里的python -m venv .venv创建独立虚拟环境，source .venv/bin/activate激活它，之后所有安装都进这个环境。python -m pip install -r requirements.txt按清单装依赖，最后的python -c "import geo_detect"是冒烟测试，模块能导入了，说明 requests、beautifulsoup4 等基础依赖解析完成。Python 版本建议 3.10 以上，太新的版本偶尔会遇到依赖没有预编译包的问题，到时候降一个次版本通常比折腾编译参数更快。如果公司网络有限制，就把 pip 指向内部镜像源，别对依赖清单动刀。

注意：用python -m pip install而不是裸pip install，能避免把包装进错误的解释器，这在多版本环境里是血泪教训。

3.2 最小 GEO 检测器：抓取、解析、评分的骨架代码

能用的最少闭环不是复杂模型，而是三段式：用普通浏览器 UA 抓取 HTML，用 BeautifulSoup 解析要素，用加权规则算分。下面的脚本就按这个思路拆，所有参数都不涉及外部服务，本地就能跑。

# geo_detect.py —— 最小 GEO 检测器：抓取 / 解析 / 加权评分 import re import sys import json import argparse import requests from bs4 import BeautifulSoup UA = "Mozilla/5.0 (compatible; GeoAudit/1.0; +local-test)" def fetch(url: str) -> str: # 超时设置 15 秒，避免某个页面卡死整条链路 resp = requests.get(url, headers={"User-Agent": UA}, timeout=15) resp.raise_for_status() return resp.text def evaluate(html: str) -> tuple: soup = BeautifulSoup(html, "html.parser") title = soup.title.get_text(strip=True) if soup.title else "" text = soup.get_text(" ", strip=True) h1 = len(soup.find_all("h1")) h2 = len(soup.find_all("h2")) has_desc = bool(soup.find("meta", attrs={"name": "description"})) jsonld = soup.find_all("script", type="application/ld+json") tables = len(soup.find_all("table")) bullets = len(soup.select("ul li, ol li")) quotes = len(soup.find_all("blockquote")) quant = len(re.findall(r"\d+(?:\.\d+)?\s*(%|ms|倍|个|GB|MB)", text)) words = len(text.split()) score = 0 if title: score += 5 if h1: score += 5 if h2 >= 2: score += 10 elif h2 == 1: score += 5 if has_desc: score += 5 if jsonld: score += 25 score += min(quant, 10) score += min(tables, 2) * 5 score += min(bullets, 5) score += min(quotes, 5) if words >= 800: score += 20 elif words >= 300: score += 10 elif words >= 100: score += 5 detail = { "title": title, "h1": h1, "h2": h2, "has_description": has_desc, "jsonld_blocks": len(jsonld), "table_count": tables, "bullet_count": bullets, "blockquote_count": quotes, "quant_markers": quant, "word_count": words, "geo_score": min(score, 100), } return min(score, 100), detail if __name__ == "__main__": ap = argparse.ArgumentParser(description="GEO page score") ap.add_argument("--url", required=True, help="page url or local file path") args = ap.parse_args() if args.url.startswith("http"): html = fetch(args.url) else: html = open(args.url, encoding="utf-8").read() final, info = evaluate(html) info["geo_score"] = final print(json.dumps(info, ensure_ascii=False, indent=2))

评分逻辑里，JSON-LD 直接给 25 分，权重高于标题层级，原因是引擎对结构化字段的解析成本低、信任度高。表格上限 10 分，列表和引用块各占 5 分，量化信息上限 10 分，正文长度最多 20 分。整体加和正好 100 分，但页面不需要追满分，80 分以上已经意味着可抓取、结构化、内容密度三件事都到位了。

3.3 运行第一份报告：命令、字段与及格线

脚本写好之后，本地起一个静态服务，随便拿一个还没优化的页面跑一遍。比如把页面放在站点根目录下，直接跑下面的命令。

python geo_detect.py --url http://localhost:8000/docs.html

假设你的页面还没做过任何 GEO 改造，输出可能长这样：

{ "title": "GEO接入实践", "h1": 1, "h2": 1, "has_description": true, "jsonld_blocks": 0, "table_count": 0, "bullet_count": 2, "blockquote_count": 0, "quant_markers": 3, "word_count": 420, "geo_score": 48 }

这份报告的关键不是总分，而是看哪一项拖了后腿。比如jsonld_blocks为 0，说明页面没有任何结构化数据，这在当前阶段几乎是 GEO 最常见也最好补的失分项；table_count为 0，说明缺乏适合直接引用的规整信息；word_count才 420，对一篇技术说明来说太单薄。我平时用 60 分当基础线，低于 60 先解决抓取和结构化；60 到 80 之间做内容改造；80 以上再去做真实问答回归验证。这个及格线是我自己跑站点的经验值，不同领域可能有正负 10 分的摆动，别当成行业标准。

3.4 评分维度的权重理由与参数边界

为啥这样加权，背后是取舍。给一张权重表能帮你更快理解评分器的脾气，后面要调参数也有据可依。

边界要看清：JSON-LD 拿满分的前提是它真实存在，但如果结构化内容与正文互相矛盾，生成引擎会直接丢弃这个来源，检测脚本只查“存在性”，查不了“一致性”，所以上线前还要人工核对一遍。文档站可以把表格权重调到 15，新闻站可以把 title 权重提高，这都属于评价器调参的正常操作，不用担心破坏整体结构。

4. 内容侧的可引用性改造：模板、注入与跑分对比

评分器只能告诉你哪里差，改内容还得靠具体的模板和脚本。这一章把最常见的三件事做掉：找实体、补结构化数据、对比改版前后分数。改完再跑一次，得分变化会非常直观。

4.1 摘要块与实体线索：用脚本找出页面主题

生成引擎理解一个页面前，先尝试识别这段内容在讲哪个实体。页面标题、首段、meta description 里如果反复出现同一个主题词，引擎把页面归类到对应话题的成功率会高很多。手动维护主题词太慢，我常用一个基于词频的脚本帮编辑找线索，不引入模型也能跑。

# entity_hint.py —— 用词频帮内容同学找主题实体线索 import re import sys from collections import Counter STOP = set("的一了是在有和就这那都与个为对要我他你它们吧呢啊".strip()) def top_terms(path: str, topn: int = 10) -> list: text = open(path, encoding="utf-8").read().lower() terms = re.findall(r"[\u4e00-\u9fff]{2,}|[a-z][a-z0-9-]+", text) filtered = [t for t in terms if t not in STOP] return Counter(filtered).most_common(topn) if __name__ == "__main__": for term, cnt in top_terms(sys.argv[1]): print(cnt, term)

这不是真正的命名实体识别，只是用统计方法把高频词捞出来，用来发现“咦，我这篇文档其实核心是在讲 XX”。用法是python entity_hint.py docs.md，跑完看最前面的几个词，把真正代表主题的那个词写进 H1、首段和 meta description。停用词表要根据自己领域扩充，技术文档里“配置、方法、使用”这类词如果不加进 STOP，会把真正的实体词挤下去。topn参数控制输出数量，文档越长越需要看前 20 而不是前 10。

4.2 JSON-LD 注入：从手写标记到模板化

结构化数据是“顺手做了 GEO”和“认真做了 GEO”的分水岭。给页面加 JSON-LD 不需要改正文，只要在<head>里插一段合法脚本，生成引擎就能低成本拿到文章标题、作者、发布时间这些元信息。手写容易写错，我一般用一小段 Python 生成。

# add_jsonld.py —— 给 HTML 注入 Article JSON-LD import json import sys def build_article(title: str, desc: str, url: str, author: str) -> dict: return { "@context": "https://schema.org", "@type": "Article", "headline": title, "description": desc, "url": url, "author": {"@type": "Person", "name": author}, "datePublished": "2025-01-10", "dateModified": "2025-01-18", "mainEntityOfPage": {"@type": "WebPage", "@id": url}, } def inject(html: str, data: dict) -> str: tag = ( '<script type="application/ld+json">' + json.dumps(data, ensure_ascii=False) + "</script>" ) if "</head>" in html: return html.replace("</head>", tag + "</head>", 1) return tag + html if __name__ == "__main__": html = open(sys.argv[1], encoding="utf-8").read() data = build_article( "GEO 接入实践", "生成式引擎优化的检测与改造", "https://example.org/geo", "某开发者", ) print(inject(html, data))

用法是python add_jsonld.py docs.html > docs_with_jsonld.html，输出重定向到新文件再替换上线。@type用 Article，如果内容是产品文档可以换成TechArticle，差别不大。datePublished和dateModified不要手写死，我从 git 提交时间自动生成，避免改版后时间戳过期。author 字段建议用真实的维护者或组织标识，别填“admin”这种没有可信度的名称。重复注入是常见翻车点，脚本没做幂等，你要是跑两次会注入两段相同 JSON-LD，所以上线前检查一下页面里同类型块的数量。

4.3 改造前后跑分对比：从 48 分到 86 分的路径

改完一部分内容，最想知道的是分数变化。手工复制 JSON 对比太蠢，写个对比脚本一次看两个 URL，字段对齐输出。

# compare_geo.py —— 改造前后跑分对比 import json import subprocess import sys def run_report(url: str) -> dict: raw = subprocess.check_output(["python", "geo_detect.py", "--url", url], text=True) return json.loads(raw) if __name__ == "__main__": old_url, new_url = sys.argv[1], sys.argv[2] left, right = run_report(old_url), run_report(new_url) keys = [k for k in left if k != "geo_score"] print(f"{'维度':<16}{'改造前':>8}{'改造后':>8}") for k in keys: print(f"{k:<16}{left[k]:>8}{right[k]:>8}") print(f"{'geo_score':<16}{left['geo_score']:>8}{right['geo_score']:>8}")

这个脚本用 subprocess 调geo_detect.py，避免重复导入逻辑。输出是一个对齐的文本表格，适合贴进变更记录。

这 38 分来自哪其实很清晰：JSON-LD 加 25，H2 结构补 5，表格加 10，量化标记多了 7，正文从 420 涨到 1800 又补了 15，扣掉一些边界分后总分落在 86。注意，跑分只是代理指标，真实引用率还要靠第 6 章的引用回归来验证。现在能达到 80 以上，说明页面至少过了“可理解”这一关。

5. 避坑：让 GEO 源码工程当场翻车的五个排查点

工具能跑起来只是开始，真正上线时踩坑才是最费时间的。挑五个我反复遇到的坑，每条按现象、原因、解决写，你对照着排查比翻日志效率高。

5.1 现象：robots 规则挡住了生成式引擎爬虫

现象：检测脚本得分不低，但生成式搜索的引用来源里始终没有你的站点，连自然提及都查不到。

原因：检测脚本用普通浏览器 UA 模拟抓取，而官方抓取器在 robots 或防火墙层面被拦了。很多站点的 robots.txt 是几年没动过的老配置，里面可能写了限制某些抓取器的规则，当时是为了防爬虫，结果把生成式引擎的抓取也误伤了。

解决：先回第 2 章的日志统计确认官方抓取器到底来没来过；再看 robots.txt，确保基础规则是放行的，不要把所有User-agent都写进Disallow。

User-agent: * Allow: /

如果是内容分发网络的访问策略拦了未知 UA，就把各家生成式引擎公开的抓取器 UA 加进白名单，只放行不反爬。记住，检测脚本用的浏览器 UA 只能验证页面本身可访问，验证不了引擎爬虫的真实路径。

5.2 现象：跑分虚高，真实问答完全不引用

现象：本地检测 90 分，看着很漂亮，但在生成式搜索里问相关问题时，回答仍然不引用站点。

原因：你的页面是单页应用，内容全靠 JS 渲染，检测脚本用了类浏览器环境去抓，拿到的是一份渲染完成的 DOM 做评分，而官方抓取器通常只抓原始 HTML，渲染前的内容是空的，等于引擎读了个空壳。

解决：检测脚本只允许抓原始响应，不要走无头浏览器评分。同时页面本身要提供预渲染或服务端渲染，把关键内容直接放在首屏 HTML。

# 检查原始 HTML 里是否有正文关键字，返回 0 说明内容靠 JS 渲染 curl -s http://localhost:8000/docs.html | grep -c "正文关键字"

把“正文关键字”换成页面核心术语。这步检查不过，跑分再高也不要上线。

5.3 现象：内容重构后 GEO 分数大跳水

现象：前一周跑分 85，改版重做 URL 后变成 40，实测引用也变少。

原因：URL 加了查询参数或者换了目录，旧地址没做 301 跳转，页面上又有内链指向旧地址，生成引擎把新旧两个版本当成不同页面处理，语义权重被稀释。这类问题经常出现在内容迁移、域名调整之后，外部因素掩盖了内容本身的改进。

解决：先把 URL 规范化，旧地址全部 301 到新地址，每页只保留一个 canonical 指向。再批量导出内链和外链，找出还指向旧地址的资源，改完重新跑分。

# 列出页面里所有内链，快速排查是否还指向旧路径 grep -oE 'href="[^"]+"' docs.html | sed 's/href="//;s/"//' | sort -u

5.4 现象：换个环境依赖就崩

现象：在 A 环境跑得好好的源码，换到 B 环境pip install时开始编译报错，报错指向某个 C 扩展。

原因：requirements 里只写了包名没锁版本，或者 B 环境的 Python 版本太新，依赖没有对应的预编译包，现场编译缺少系统库就会失败。这是“我这台机器能跑”和“可复现”之间的经典差距。

解决：固定所有直接依赖和间接依赖的版本，生成 lock 文件一并提交。装依赖用 lock 文件而不是手写 requirements。

python -m pip freeze > requirements.lock.txt python -m pip install -r requirements.lock.txt

如果某个包在 Python 新版本上一直编译失败，就降到 3.10 或 3.11，这类版本对常见库的预编译覆盖最全。

5.5 现象：堆词式 GEO 让分数不升反降

现象：为了把实体密度提上去，在段落里反复插入核心术语，结果跑分没涨多少，页面读起来很别扭。

原因：生成的答案素材来源已经跨入语义理解阶段，重复关键词会降低段落的信息熵，编辑一眼看出重复，引擎会对低质量内容降权。检测脚本如果只算密度不算重复度，那就只能报喜不能报忧。

解决：给检测脚本增加重复度检查，用 n-gram 窗口估算正文重复比例，超过阈值就提示编辑重写。

# ngram_repeat.py —— 检查正文文本的重复比例 import re import sys from collections import Counter def repeat_ratio(path: str, n: int = 4) -> float: text = re.sub(r"\s+", " ", open(path, encoding="utf-8").read()) grams = [text[i:i + n] for i in range(len(text) - n)] total = len(grams) if total == 0: return 1.0 repeated = sum(1 for v in Counter(grams).values() if v > 1) return repeated / total if __name__ == "__main__": print(f"repeat_ratio={repeat_ratio(sys.argv[1]):.2%}")

四字符窗口对中文正文太灵敏，参数可以调到 6，把短词重复过滤掉。我在实操中重复比超过 15% 就建议重新组织句子，而不是继续堆词。GEO 的核心是把一个概念讲清楚，不是把一个关键词提到足够多次。

6. 进阶：把 GEO 检测接进发布流程，用引用回归做验证

跑分脚本最大的价值不是跑一次，而是作为发布流程里的门槛，防止下一次改版把之前积累的引用能力改没了。

6.1 发布前跑分门槛：阻塞还是告警

把geo_detect.py接进发布前检查，最简单的做法是写一个脚本包一层，分数低于阈值就中断发布。

#!/usr/bin/env bash # 发布前 GEO 跑分门槛；首次接入建议设 60，跑分持续两周在 80 以上再提到 80 URL="$1" THRESHOLD="${2:-60}" SCORE=$(python geo_detect.py --url "$URL" | python -c "import json,sys; print(json.load(sys.stdin)['geo_score'])") echo "geo_score=$SCORE" if [ "$SCORE" -lt "$THRESHOLD" ]; then echo "GEO 分数未达阈值，阻断发布" >&2 exit 1 fi

THRESHOLD默认 60，第一次接入时只告警不阻塞，不然团队会被频繁失败惹恼。跑分回调并不完全等于引用率变化，但低于 60 基本代表可抓取或结构化出了问题，值得拦住。

6.2 引用回归：让真实问题当裁判

跑分是代理指标，真实引用才是目标。我习惯维护一份种子问题集，每个问题对应站点一个核心内容方向，比如“你的产品怎么接入”“某个参数怎么配”，然后每周去生成式搜索里问一遍，人工统计回答里是否引用了你的站点。这个动作看起来很笨，却比看跑分更接近业务价值。

种子问题集要固定，不能每周换提问方式，否则数据不可比。每次内容改版时，把页面对应的种子问题单独跑一遍，确认引用没有丢，再决定要不要合并发布。我踩过最大的坑，就是把跑分当成了目标本身，结果分数很好看，真实问答里却完全没有引用。后来我养成的习惯是：每次改版都带着问题集回归，跑分只在发布前做闸门，引用回归才做最终判断。希望帮到你。

本文还有配套的精品资源，点击获取