企业官网建设流程全解析

一直做搜索流量的人，这两年应该都感觉到一股说不清的别扭：后台的自然点击在掉，但关键词排名好像没怎么动。我第一次意识到问题不对劲，是因为一个用户留言——他说找了一晚上答案，最后是在ChatGPT的回复里看到的我们站点链接，根本没进网站。那一刻我明白，传统的"排名-点击-访问"路径正在被AI搜索引擎改写成"提问-回答-引用"。这也是我开始认真研究GEO（Generative Engine Optimization，生成式引擎优化）的直接原因，并且花了大概一个月时间，用PHP把整套优化流程做成了可落地、可复用的系统源码。

这篇文章不打算讲纯理论，而是把我从零搭建这套"基于PHP的GEO排名优化系统"的过程、架构、核心算法和踩坑记录完整放出来。它解决的核心问题是：在AI搜索时代，怎么让你网站的内容更容易被大模型引用，而不是费力把排名做到第一页却拿不到点击。适合正在做内容站、想转型AI搜索流量的PHP开发者，以及那些看腻了"GEO概念科普"、想直接动手的运营团队。

1. 为什么SEO打法失效了：GEO优化到底在优化什么

1.1 AI搜索引擎的信息分发逻辑已经变了

先明确一个概念：这里说的GEO不是地理定位，而是Generative Engine Optimization，翻译过来就是生成式引擎优化。它的目标很直接——让ChatGPT、Perplexity、Bing AI这些AI引擎，在生成答案的时候把你的内容当作引用来源。

传统搜索引擎的信息路径是"爬取→索引→排名→点击"。用户看到十条蓝色链接，从中选一个点进去。AI搜索引擎的路径完全不同：它会综合大量网页内容，直接生成一段带答案的文字，只在末尾附带几个来源链接。用户大多数时候只看答案本身，根本不点链接。结果就是，哪怕你的网页排在传统搜索第一位，只要AI引擎没引用你，流量就归零。

这个过程里，大模型选择引用谁是有偏好的。2023年KDD会议上有一篇研究GEO的论文，核心结论我到现在还记得：生成引擎在引用网页时，会倾向那些结构清晰、实体明确、带数据和引用来源的内容。后来我拿自己的站点做了小规模测试，发现完全一致——页面里有没有FAQ段落、有没有具体的统计数字、开头有没有直接回答用户问题，直接决定AI引擎在多个来源里挑不挑你。

1.2 GEO和SEO的本质差异：从"抢排名"到"抢引用"

很多做SEO的人第一次接触GEO，会觉得这不就是内容优化吗，换了个新名词而已。实际上两者的优化对象和优化粒度完全不同。

SEO优化的是"让搜索引擎看得懂页面"，GEO优化的是"让大模型觉得这个页面值得作为论据"。举个最简单的例子：一篇宠物医院推荐文章，传统SEO做法是把"宠物医院哪家好"堆进标题和正文，外链买一圈，排名上去了点击就有了。GEO的做法完全不同——你需要在开头直接用一句话回答"选宠物医院主要看三件事：资质、设备、急诊能力"，然后在正文给每个结论配套具体数据（比如"国内70%的宠物急诊集中在夜间，所以24小时急诊是硬指标"），最后还要用FAQPage的schema标记把这些问答结构化。前者让搜索引擎能匹配关键词，后者让大模型能直接提取结论并放心引用。

1.3 一套GEO优化系统应该具备的四个核心能力

正因为GEO优化的链路长、环节多，靠手工一处一处改肯定不行。我做这套PHP系统的时候，给自己定了四个必须覆盖的核心能力：

1. 行业核心关键词提炼：把行业里散落的搜索词整理成实体词、问题词、比较词、数字词四类，为后续内容生成提供弹药。
2. GEO内容模板工厂：根据关键词自动生成一套"AI友好"的写作指令（prompt），指导内容生产时该用什么结构、该突出哪些信息。
3. 可引用度评分引擎：发布前用统一标准给内容打分，判断这篇内容大概率能不能被AI引擎引用。
4. 引用追踪与数据报表：定期拿行业问题去AI搜索API里提问，看返回结果里有没有自己的域名。

这四个能力环环相扣，正好对应"提炼关键词→生成内容→评估质量→验证结果"的完整闭环。接下来我详细说下技术选型和每个模块的实现细节。

2. 技术选型复盘：为什么用PHP而不是Python来做GEO工具

2.1 业务方是PHP技术栈，系统必须能落地

做GEO工具的同行里，十个人可能有八个会选择Python，毕竟Python在数据分析、AI调用上的生态确实香。我在动手前也纠结过，最后还是选了PHP，核心原因是：这套系统最终要部署在大量内容站、企业官网的现有环境里，而这些站点绝大部分是LNMP架构，运维同学对PHP的部署流程最熟。选Python意味着要么单独维护一套Python运行时，要么容器化改造，对大多数中小团队来说都是隐性成本。

PHP还有一个容易被低估的优势：它在"Web管理后台+定时任务"这个组合上极其顺手。GEO优化系统本质上就是一个内容管理后台加一堆计划任务，不是高并发、高计算量的场景。PHP 8以后性能提升也很明显，JIT加持下跑正则匹配、文本分析这类纯CPU任务完全够用，没有必要为了"技术听起来高级"去引入一个让团队陌生的技术栈。

2.2 轻量架构：FastRoute + PDO + Redis + 定时任务

我没有用Laravel这类全家桶框架，而是选了FastRoute做路由，数据库用PDO连MySQL，缓存和任务队列交给Redis，定时任务走crontab。原因很简单：这套系统的核心是业务逻辑，不是框架功能。Laravel能提供的ORM、中间件、队列组件确实好用，但对一个要深度定制评分算法的项目来说，框架太多的约定反而碍事。

具体技术栈清单：

• PHP 8.2+，用上了构造器属性提升、枚举类型、match表达式，代码比PHP 7时代简洁很多
• FastRoute，轻量路由，HTTP和CLI两个入口共用一套核心类
• PDO + MySQL 8.0，InnoDB引擎，utf8mb4字符集
• Redis用于缓存、简单队列和任务去重
• Guzzle HTTP客户端，统一处理所有对外API调用
• 原生PHP CLI脚本，配合crontab处理队列消费和定时监测

整个系统只有一个入口文件设计：HTTP请求走index.php，命令行任务走bin/geo脚本，两者都加载同一个bootstrap，然后调用各自的Controller或Worker类。好处是配置只加载一份，连接复用逻辑统一，不会出现FPM环境下的配置和CLI环境下不一致的问题。

2.3 "快速开发应用"这个卖点是怎么实现的

标题里说"适合快速开发应用"，这句话不是口号，我在架构上做了三个刻意的设计来保证可扩展性。第一，把整个GEO流程抽象成"采集关键词→生成指令→执行生成→内容评分→发布跟踪"五个步骤，每个步骤对应一个独立的Worker类，想替换某个环节的实现（比如把内容生成从A厂商API换成B厂商），只需要改一个类。第二，所有配置项外置到.env和数据库配置表，运营人员改模板不需要动代码。第三，内置了一个极简任务队列，用Redis的List结构实现，生产端把任务ID塞进队列，消费端用BLPOP阻塞获取，不需要额外部署RabbitMQ这类重型中间件。

这套骨架搭好之后，我后面接新的AI生成接口、加新的评分维度、对接新的AI搜索平台，都是在几小时内完成的事情。这才叫"适合快速开发应用"——不是交付你一个写死的工具，而是给了一套可以持续生长的框架。

3. 数据库与核心模块设计：GEO优化的数据底座

3.1 数据库表结构设计

系统整个数据模型围绕"关键词→内容→评分→引用记录"这条主线展开，一共六张核心表。下面是主要结构：

-- 关键词特征库 CREATE TABLE `geo_keywords` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `industry` VARCHAR(64) NOT NULL COMMENT '所属行业', `keyword` VARCHAR(128) NOT NULL COMMENT '关键词', `intent_type` ENUM('entity','question','compare','number') NOT NULL COMMENT '意图类型', `search_volume` INT DEFAULT 0 COMMENT '预估搜索量', `source` VARCHAR(32) DEFAULT 'manual' COMMENT '来源：manual/api/csv', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_industry_intent` (`industry`, `intent_type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; -- 站点实体表 CREATE TABLE `geo_sites` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `site_name` VARCHAR(128) NOT NULL, `site_url` VARCHAR(255) NOT NULL, `entity_name` VARCHAR(64) NOT NULL COMMENT '核心品牌实体名', `entity_aliases` VARCHAR(255) DEFAULT NULL COMMENT '实体别名，逗号分隔', `author_name` VARCHAR(64) DEFAULT NULL COMMENT '默认作者', `authority_level` TINYINT DEFAULT 3 COMMENT '权威信号强度 1-5', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- GEO内容生成记录 CREATE TABLE `geo_contents` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `site_id` INT UNSIGNED NOT NULL, `keyword_id` INT UNSIGNED NOT NULL, `title` VARCHAR(255) NOT NULL, `content_html` MEDIUMTEXT NOT NULL COMMENT '生成后的HTML内容', `content_text` MEDIUMTEXT NOT NULL COMMENT '纯文本版本，用于评分', `total_score` DECIMAL(5,2) DEFAULT 0, `status` ENUM('draft','ready_to_publish','pending_rewrite','published','failed') DEFAULT 'draft', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, `published_url` VARCHAR(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- GEO评分记录表 CREATE TABLE `geo_scores` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `content_id` INT UNSIGNED NOT NULL, `entity_score` DECIMAL(5,2) DEFAULT 0, `question_score` DECIMAL(5,2) DEFAULT 0, `structure_score` DECIMAL(5,2) DEFAULT 0, `data_score` DECIMAL(5,2) DEFAULT 0, `authority_score` DECIMAL(5,2) DEFAULT 0, `total_score` DECIMAL(5,2) DEFAULT 0, `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_content` (`content_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- AI引用追踪表 CREATE TABLE `geo_refs` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `site_id` INT UNSIGNED NOT NULL, `ref_question` VARCHAR(255) NOT NULL COMMENT '监测用问题', `ref_engine` VARCHAR(32) NOT NULL COMMENT 'AI搜索引擎标识', `ref_url` VARCHAR(255) DEFAULT NULL COMMENT 'AI返回的来源链接', `is_matched` TINYINT(1) DEFAULT 0 COMMENT '是否匹配到自家站点', `checked_at` DATETIME NOT NULL, PRIMARY KEY (`id`), KEY `idx_site_engine_time` (`site_id`, `ref_engine`, `checked_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

两个设计细节我要特别说明。第一个是geo_contents表里同时存了content_html和content_text两个版本，这是有意的——生成的内容要做展示和监测，HTML够用；但评分时要跑正则、数词频、做文本分析，纯文本更快更干净。第二个是geo_sites表里的entity_aliases字段，这个在传统内容系统里经常被忽略，但在GEO里非常关键。AI引擎理解"实体"时，要能把不同叫法（比如"宠物医院"和"动物诊疗机构"）关联到同一个实体上，没有统一的实体别名管理，内容就容易被误判。

3.2 关键词特征库：把"行业核心关键词"变成结构化资产

业内讲"精准赋能GEO优化"，实际落地的第一步就是提炼行业核心关键词。我做的关键词分类逻辑参考了搜索意图分析的标准做法，把关键词按intent_type分成四类：

• 实体词：行业核心名词，比如"宠物医院""兽医""疫苗接种"
• 问题词：用户真正会向AI引擎提问的句式，比如"宠物呕吐怎么办""怎么选宠物医院"
• 比较词：带有对比倾向的词，比如"宠物医院和宠物诊所的区别""国产猫粮和进口猫粮怎么选"
• 数字词：带有具体参数或列表的词，比如"狗狗疫苗接种时间表""猫粮营养成分标准"

这四类词在GEO内容里的作用完全不同。实体词用来保证"内容与用户问题对得上"，问题词用来覆盖"AI引擎可能怎么问"，比较词用来抢占"对比类答案的引用位"，数字词用来提供"可被直接引用为结论的数据"。四类词可以手工录入，也可以从导出表格批量导入，系统里有个import keywords.csv命令专门干这个。

3.3 GEO内容模板工厂：让每个关键词自动生成写作指令

有了关键词，下一步是生成内容。这套系统的prompt不是写死在代码里的，而是存在数据库里，通过模板变量组合生成。模板的逻辑是把"角色设定+目标实体+上下文关键词+结构化要求+引用友好要求"五段拼起来。核心函数如下：

public function buildGeoPrompt(array $keyword, array $site): string { $template = $this->getTemplate($keyword['intent_type']); // 按意图类型选模板 $question = match($keyword['intent_type']) { 'question' => $keyword['keyword'], 'compare' => "相比同类方案，{$keyword['keyword']}该关注哪些差异", 'number' => "{$keyword['keyword']}的具体数据、时间表或标准是什么", default => "什么是{$keyword['keyword']}，核心内容包括什么", }; $prompt = <<<PROMPT 你是一名资深行业编辑，请围绕"{$site['entity_name']}"创作一篇面向AI搜索引擎优化的文章。 用户最可能的问题是："{$question}" 要求： 1. 开头第一段直接用一句话回答上面的问题，不要铺垫； 2. 全文至少给出3处具体数据（百分比、年份、数量、标准值均可）； 3. 在文末附加一个FAQ段落，包含5个围绕"{$keyword['keyword']}"的常见问答； 4. 涉及品牌词时，使用"{$site['entity_name']}"（曾用名：{$site['entity_aliases']}）； 5. 最后给出建议的JSON-LD结构化数据片段（FAQPage类型）。 PROMPT; return $prompt; }

这个设计有一个非常实用的地方：运营人员调整内容风格，不需要改代码，只需要在模板管理界面改模板文本。四类关键词各配一套模板，默认的侧重点不同——实体词强调定义清晰，问题词强调直接回答，比较词强调差异对比表，数字词强调数据来源和时效性。我实测下来，这种"分意图类型生成prompt"的做法比笼统的"写一篇高质量文章"精确得多。

4. 核心算法拆解：内容"可引用度"是怎么算出来的

4.1 为什么需要给内容打分

很多人会问，内容能不能被AI引用，不是发布之后才知道吗，评分有什么用？这里的关键是，我们无法直接预测大模型的引用行为，但可以根据GEO研究的结论和实测经验，找到一组"高引用率内容的共同特征"，用这些特征做代理指标。这套系统上线后，评分在80分以上的内容，在AI搜索引擎里被引用的概率明显高于60分以下的内容。这个相关性在多个行业关键词上都得到了验证。

我参考的底层逻辑是GEO研究里反复出现的几个结论：AI引擎偏好引用包含统计信息、引用来源、FAQ结构、相关实体明确、且与问题直接相关的页面。这正好对应我评分模型里要衡量的五个维度。

4.2 五维评分模型

评分模型叫GEOScore，满分100，拆成五个维度：

权重为什么这么分配？实体完整性占比最高，因为AI引擎生成回答的第一步是匹配实体——它得先确定"你这段内容说的和我问的是同一个东西"，实体不匹配后面全白搭。问题覆盖度放在第二位，因为AI引擎倾向直接提取"现成答案"，而不是从长文里推断。结构化信号和数据丰富度各占20%，分别对应"易解析"和"可引用"。权威信号占15%，属于锦上添花，没有明文作者和时间的页面，AI引擎引用时会犹豫。

4.3 PHP实现GEOScore评分函数

下面是评分引擎的核心实现，输入是内容HTML和关键词特征，输出是各维度的得分和总分。代码做了简化，保留了主干逻辑：

public function analyzeGeoScore(string $html, array $keyword): array { $text = strip_tags($html); $scores = []; // 1. 实体完整性：检查开头200字是否包含实体名和别名 $head = mb_substr($text, 0, 200); $entityHits = 0; foreach (explode(',', $keyword['aliases'] ?? '') as $alias) { if (mb_strpos($head, trim($alias)) !== false) $entityHits++; } if (mb_strpos($head, $keyword['entity']) !== false) $entityHits++; $scores['entity'] = min(100, $entityHits * 25); // 2. 问题覆盖度：统计常见问答句式出现的次数 $questionPatterns = ['是什么', '为什么', '怎么选', '怎么办', '多少钱', '区别', '如何']; $qCount = 0; foreach ($questionPatterns as $pattern) { if (preg_match_all('/' . $pattern . '/u', $text, $m) > 0) $qCount++; } $scores['question'] = min(100, $qCount * 15); // 3. 结构化信号：检测H2/H3、列表、FAQ、JSON-LD $structureScore = 0; if (preg_match('/<h[23][^>]*>/i', $html)) $structureScore += 25; if (preg_match('/<(ul|ol)[^>]*>/i', $html)) $structureScore += 20; if (preg_match('/FAQ|常见问题|Q：|A：/iu', $text)) $structureScore += 25; if (preg_match('/application\/ld\+json/i', $html)) $structureScore += 30; $scores['structure'] = min(100, $structureScore); // 4. 数据丰富度：统计数字、百分比、年份 $dataScore = 0; if (preg_match_all('/\d+(\.\d+)?%/', $text) >= 1) $dataScore += 30; if (preg_match_all('/\d{4}年/', $text) >= 1) $dataScore += 30; if (preg_match_all('/\d+[个台次天元家]/u', $text) >= 3) $dataScore += 40; $scores['data'] = min(100, $dataScore); // 5. 权威信号：检测作者、日期、外链 $authorityScore = 0; if (preg_match('/author|作者|责任编辑|原创/iu', $text)) $authorityScore += 35; if (preg_match('/\d{4}[-年]\d{1,2}[-月]\d{1,2}/', $text)) $authorityScore += 35; if (preg_match('/<a[^>]+href="https?:\/\//i', $html)) $authorityScore += 30; $scores['authority'] = min(100, $authorityScore); // 加权汇总 $weights = ['entity' => 0.25, 'question' => 0.20, 'structure' => 0.20, 'data' => 0.20, 'authority' => 0.15]; $total = 0; foreach ($weights as $key => $w) { $total += $scores[$key] * $w; } $scores['total_score'] = round($total, 2); return $scores; }

这个函数看起来很朴素，但我要强调两点实践心得。第一，评分维度不是越多越好，我们试过加入"关键词密度""可读性""情感倾向"等维度，最后发现它们对"AI是否引用"的预测能力非常弱，反而让评分逻辑难以解释。五个维度是经过AB测试之后的精简结果。第二，数据丰富度这个维度不能用简单的"数字多就得分高"，必须限定"与主题相关的实义数字"。上面代码里用"年份+单位词"的组合正则，就是吸取了这个教训的简化版。

4.4 评分结果如何反向驱动优化动作

评分不是算完就结束了，关键是驱动后面的动作。我在系统里把内容状态机设计成三条流水线：

• 总分 >= 80：标记为ready_to_publish，进入待发布列表；
• 总分在60到79之间：进入pending_rewrite队列，系统会附带一份"缺失维度报告"，告诉内容编辑具体缺什么（比如"缺数据：文中没有出现任何百分比或年份"）；
• 总分 < 60：打回failed，直接用原关键词重新走一遍生成流程。

这里还有一个细节：状态机流转是可以配置的。初版我把重写阈值设成75分，结果发现AI生成的内容大量被判重写，运营压力很大；后来把阈值调到60分并强化了发布后的引用追踪，让数据来说话，整体效率反而更高。评分模型的目的是辅助决策，不是制造流程障碍，阈值一定要跟着实际数据走。

5. 部署与实操：从源码到能跑的GEO工作流

5.1 环境要求与安装步骤

这套系统对环境的要求不高，就是一套标准的PHP Web应用。我的推荐配置是：

• PHP 8.1及以上，需要安装pdo_mysql、redis、json、mbstring扩展
• MySQL 5.7或8.0
• Redis 5.0以上
• Nginx或Apache均可，PHP-FPM运行模式
• Composer 2.x用于安装依赖

安装流程用命令行执行：

git clone <你的仓库地址> geo-system cd geo-system composer install --no-dev cp .env.example .env # 编辑.env，填写数据库连接、Redis连接、AI API Key等配置 php bin/geo migrate # 导入数据库表结构 php bin/geo import keywords.csv # 导入关键词库

如果没有任何依赖包的情况下，也可以直接在生产服务器上放PHP源码文件，只要扩展齐全就能跑。这才是这套系统"快速开发应用"的一个优势：部署环节几乎没有容器、编译等高门槛操作。

5.2 完整实操流程：从关键词到被AI引用

我在本地跑通的完整流程是这样的，你可以照着走一遍。

第一步，准备关键词。假设你运营的是一个宠物医疗内容站，先整理一批行业核心关键词，比如"宠物医院排名""宠物呕吐原因""猫疫苗间隔时间""宠物医院和宠物诊所区别"等，分别标注意图类型，存成CSV后导入系统。

第二步，生成GEO内容。在管理后台选择站点、选定关键词，触发内容生成任务。系统会自动调用AI生成接口，产出的文章按前面说的prompt模板要求，已经是"首段直接回答+包含数据+FAQ+JSON-LD建议"的结构。我实测一篇1500字左右的内容，生成加评分全过程耗时大概在1到2分钟，主要花在AI接口响应上。

第三步，查看评分报告。评分页面会渲染五个维度的得分，图表化展示。你会很直观地看到，哪篇内容的数据维度得分低（说明没有具体数字）、哪篇的实体维度得分低（说明实体名没在开头出现）。按报告补充后重新评分。

第四步，发布并配置引用追踪。把评分合格的内容发布到线上，然后在系统的"引用监测"模块添加一批行业问题，比如"宠物呕吐应该怎么办"。系统会定时用这些问题去调用已接入的AI搜索API，检查返回结果里是否包含你的域名，并把记录写入geo_refs表。

定时任务按下面的方式配置到crontab里：

# 每5分钟跑一次引用监测 */5 * * * * php /path/to/geo-system/bin/geo check-refs >> /var/log/geo-refs.log 2>&1 # 每天凌晨3点批量处理待生成内容队列 0 3 * * * php /path/to/geo-system/bin/geo worker --queue=content_generate >> /var/log/geo-generate.log 2>&1

5.3 实际部署中最容易踩的几个坑

这个部分我想多说一点，因为源码能跑通和能稳定运行是两回事。我踩过的坑至少有四个。

第一个坑是API调用超时。AI生成接口的响应时间波动非常大，正常时15秒，高峰期能到两三分钟。我在初版代码里用默认的30秒超时，结果队列里全是失败任务。解决思路是：同步生成任务全部改为异步，HTTP请求用Guzzle的timeout和connect_timeout分开设置，连接超时给10秒，总超时给180秒，同时把超时上限做成配置项。这看起来是个小问题，但如果你公司用的是共享API，这个调整直接把生成成功率从六成拉到九成以上。

第二个坑是编码与特殊字符。AI生成的内容经常带着弯引号、破折号、emoji，如果数据库表用了utf8而不是utf8mb4，入库直接报错。更隐蔽的是，某些AI接口返回的JSON里夹杂控制字符，json_decode直接返回null，排查了半天才发现是字符串里带了不可见字符。处理方式是入库前统一做一次清洗：去掉\u0000-\u001F控制字符，把特殊引号规范为普通引号。

第三个坑是CLI环境与FPM环境不一致。我遇到过评测任务在后台跑正常，但用命令行跑同一个worker时报"Redis连接被拒绝"，查了半天才发现是Redis的套接字权限问题。PHP-FPM跑在www用户下，CLI跑在root用户下，两个用户对Redis socket文件的访问权限不一样。建议在部署文档里明确要求：所有crontab任务和后台任务使用同一个运行用户，并在.env里写清楚Redis的连接方式（TCP还是socket）。

第四个坑是评分前的HTML预处理。刚开始我用strip_tags()直接处理文章HTML，结果发现评分里的"结构化信号"维度总是漏算，因为HTML被剥掉了，H2和FAQ结构信息全丢了。后来改成评分函数接收原始HTML，在评分逻辑内部先做结构检测，再对剥离出的纯文本做词频统计，两个维度各取所需。这个顺序问题不仔细想很容易被忽视。

6. 这套源码的可扩展方向：从排名优化到品牌监控

6.1 对接AI搜索平台的引用追踪

目前系统里引用追踪模块预留了对接位，支持的引擎包括Perplexity、OpenAI的带搜索功能的接口等。实现原理不复杂：用一批预设问题，定期调用AI搜索API，把返回的引用来源域名列表与自己的站点域名做交集比对，命中就记一条is_matched=1。需要注意的是，AI搜索API是有调用成本的，别把问题集设得太大。我按"每站点50个核心问题、每6小时跑一轮"的节奏，一个月消耗的Token数量完全可控。

如果你想监测Google AI Overview的引用情况，思路一样，只是改一下问题源和结果解析逻辑。这部分的扩展空间很大，未来还可以按引擎维度统计"哪个AI平台更喜欢引用我们"。

6.2 把评分引擎封装成API服务

我在实际使用中强烈建议把评分引擎拆成独立的HTTP API接口。这样不仅GEO系统内部可以用，公司其他编辑工具、CMS发布流程也能调用。一个典型场景是：编辑在后台写完文章点"发布"按钮之前，先请求一下GEO评分接口，如果总分低于75分就弹窗提醒"这篇内容可能很难被AI引用"，直接在设计稿阶段拦截低质量内容。

方案是把评分类改成可注入的服务，在bin/geo里注册一个serve命令启动内置HTTP服务，或者作为独立路由挂到现有Web入口。接口接收两个参数：content_html和keyword_id，返回完整的五维评分报告。

6.3 从关键词优化升级为品牌实体管理

GEO做着做着你会发现，真正的护城河不是单篇内容的优化，而是品牌实体的一致性。AI搜索引擎在判断"哪个来源可信"时，会看同一个品牌实体在不同页面里描述是否一致、别名是否统一、核心信息是否对齐。这套系统的geo_sites表已经为实体管理打好了底子。

更进阶的做法是给实体管理模块增加一个"品牌口径库"：把品牌介绍语、核心产品线、创始人背景、关键数据等原子化存储，生成任何内容时都自动注入这些口径。这样做的好处是，当AI引擎在多个页面里反复看到同一个实体描述时，它对这个实体的建模会越来越稳定，引用概率会明显上升。

6.4 后续规划中值得注意的取舍

我计划给这套系统增加多语言支持和更丰富的数据图表，但有一个原则始终没变：GEO优化的底层逻辑是内容质量和信息架构，工具只是把"正确的事"变成"可复制、可度量的流程"。不要指望系统能预测AI引擎的每一次算法调整，更不要试图去"刷"引用——大模型对低质量来源的识别能力越来越强，那些靠批量制造垃圾内容去骗引用的做法，短期内可能有收益，长期一定会被清洗。

我的建议是，把这套系统的评分模型和流程作为团队内容质量的一条基准线，优先把每个行业的关键词库做深、做扎实，把品牌实体的一致性经营好。当你的内容本身足够扎实时，GEO系统只是让这个优势更快、更稳定地转化为AI搜索里的可见引用。

最后再分享一个我在实测里发现的小技巧：无论评分模型怎么调整，给每一篇内容写一个不超过60字的"一句话摘要"放在开头，并且确保这个摘要能独立回答用户的问题。这个动作对AI引用的正向影响，比我调整过的任何一个评分权重都更明显。所谓GEO，很多时候就是帮AI引擎节省理解你内容的成本。