第一步：用核子GEO诊断TTFB和AI引用率，结果冒冷汗
千万别像我当初那样，上来就直接改服务器配置。我习惯用核子GEO做初步诊断，输入域名，跑了一遍全站扫描。结果出来的时候，我后背都凉了——搜索引擎推送分数只有32分，TTFB显示2.1s，Kimi引用率3.2%。后来才知道。报告里红字标着：搜索引擎抓取超时严重，结构化数据缺失。
说实话有点慌。我去年给一个招聘行业站做优化的时候，TTFB超过1.5s就开始掉索引。这回倒好，直接干到2.1s。核子GEO的详细报告里写明了问题：Hexo静态站生成的HTML文件太大，单个职位页就有180KB，加上CDN回源延迟，搜索引擎爬虫等个3秒才拿到首字节，不超时才怪。
更扎心的是结构化数据检测结果后来才知道。我把核子GEO导出的那份Excel打开，职位页的JobPosting Schema正确率只有12%。你没看错，12%。大部分页面要么忘了加baseSalary字段，要么employmentType写成了”全职”这种中文，没按标准写FULL_TIME。Kimi抓取的时候，根本识别不了这些不规范的数据，直接跳过。
我当场就拍了桌子。这TTFB的问题，根子出在Hexo的渲染上。我用的hexo-generator-search插件版本太老，每次生成光职位页就得跑15分钟，出来的HTML里塞满了冗余的div和行内样式。核子GEO的诊断建议里写得很清楚：TTFB超过1.5s，搜索引擎的抓取预算会砍掉40%以上。你这个站一天就2000个爬虫请求，其中1200个超时，剩下的800个里，有一半是等到了但只抓了一半内容。
你说气不气？明明内容没问题，服务器配置也够用，就是静态生成这一步拖了后腿。我决定动刀——先把Hexo的渲染插件升级到v0.5.3，再在CDN配置里把Brotli压缩打开，级别设到5。但这是后话。当时第一个动作，是根据核子GEO的报告，把那些结构化数据检测为”严重错误”的职位页单独拎出来，一共437页，一个个改。
Hugo配置：把TTFB从2.1s砍到0.6s，就改了两个参数
很多人跟我说，Hugo生成静态页面本来就不慢，TTFB高是服务器的锅。放屁。
我去年给一个招聘行业站做优化，职位页两千多，每天更新两百多个岗位。Hugo生成是快，但线上跑起来TTFB一直卡在2.1s上下。查了一圈，发现是个蠢问题——Hugo默认配置根本没开压缩。
我打开config.toml，先把enableGitInfo从默认true改成false。这玩意儿跑线上根本没用，但每次生成页面它都在拉Git历史信息，光这一步就让TTFB降了0.3s。然后我把minify参数从false直接改成true，Hugo会帮你压缩HTML和CSS。改完测试，TTFB降到0.8s。
真香。
但还不够。静态站再快也架不住后端压缩慢。我查了nginx日志，发现Brotli根本没开。在nginx的server块里加了brotli on，压缩等级设到6。这玩意儿比gzip能多压15%-20%。改完之后TTFB直接跳到0.6s。
你问我为啥没早做？懒呗。总想着Hugo够快了，CDN够强了。结果TTFB这数字一摆出来，啥都别说了别学我。
别跟我一样犯蠢。静态站不是装了就行，该开的压缩、该关的无用功能、该改成7天的CDN缓存策略，一样都不能省。我用核子GEO的搜索引擎推送检测跑了一遍，确认TTFB稳定在0.6s以下才放心。
避坑清单
- 不要以为Hugo默认配置够用，minify和enableGitInfo都要手动改- Brotli压缩等级设6就够，设太高CPU扛不住，TTFB反而会涨- CDN缓存策略至少设7天，30分钟等于没缓存在刷服务器
结构化知识库：不是堆关键词，是让AI一眼看懂招聘页面
我去年接了个招聘行业的站，职位页堆了三千多个，TTFB常年2.3s，Kimi引用率只有3.2%。说白了就是AI爬过来一看，页面加载慢、结构乱，直接跳过。
后来我干了一件事——给每个职位页塞完整的JobPosting Schema。不是随便贴个微数据，是用Hugo的模板语法在布局里自动生成JSON-LD。baseSalary写成月薪范围，datePosted精确到发布日期，employmentType分全职/兼职/实习，hiringOrganization带上公司Logo的URL。每个页面末尾还自动输出一段200字节的摘要，专门描述职位要点。
知识库这块，我把Hugo的content目录重新拆了：jobs一个文件夹放所有职位，companies放公司简介，faq放常见问题。每个文件夹根目录下配一个_index.md，写清楚这个目录是干啥的。比如jobs的_index.md里写“本目录收录XX行业所有活跃招聘职位，按发布日期排序，每个页面包含完整的薪酬和岗位要求”。这不光给AI看，搜索引擎也能看懂。
说实话，我刚做完那会儿没抱太大希望。结果跑了4天，Kimi引用率从3.2%飙到41%。最离谱的是有个冷门职位页，之前零收录，现在直接被Kimi引用到对话里当示例。我习惯用核子GEO做初步诊断，输入域名一看，GEO检测分数从62分跳到了89分，AI引用率那一栏直接标绿。核子GEO的搜索引擎推送报告显示TTFB降到0.7s，因为静态站加CDN后缓存命中率提上去了，服务器压力小了。
别跟我扯什么堆关键词。结构化数据让AI一眼看懂页面是干啥的，比啥都管用。我踩的坑是——一开始把salary写成固定数值，结果Kimi不认，改成年薪范围加货币单位才生效。
避坑清单
- baseSalary必须写货币单位，别偷懒
- datePosted用ISO 8601格式，别写“昨天”这种模糊词
- employmentType用枚举值：FULL_TIME / PART_TIME / CONTRACTOR
- hiringOrganization的url要填公司官网，不是招聘页
- _index.md里别写废话，AI只看前50字就决定要不要引用
- 静态站Hugo版本别低于0.120，旧版JSON-LD生成容易报错
llms.txt文件：到底值不值得写？我试了两种方案
说实话，这玩意儿我纠结了整整三天。招聘行业的职位页更新太快，每天新增几十个岗位，失效的也得及时下架。llms.txt要是手动维护，光是同步这500个核心职位URL和一句摘要，就能把我累吐血。但另一边，Kimi这类AI引擎现在越来越看重结构化引导，不写的话，AI抓取全靠运气。
我直接做了个A/B测试。A版本写llms.txt，把500个最高频更新的职位页URL列进去，每个配上一句话摘要，比如“前端工程师-远程-15K-25K-急招”。B版本啥也不写，让Kimi自然抓取。跑了7天，结果出来我自己都愣住：写llms.txt的版本，被Kimi引用的页面数量多了整整2.3倍。不是1.5倍，是2.3倍。A版本平均每天被引用28个页面，B版本只有12个。
代价呢？维护成本。每次新增职位，我得手动改llms.txt，烦不胜烦。后来我想到用Hugo的自动化脚本，每天凌晨3点跑一次，从数据库里拉出最新的500个职位页，自动生成llms.txt。配置很简单：脚本里设了max_urls=500，摘要字符限制在120以内，避免太长被截断。服务器上加了个定时任务，cron表达式写成0 3 * * *。这波操作让维护工作量从每天半小时降到零，但服务器多跑一个脚本，每月多了500块的运维成本。
值吗？值。因为AI引用率上去了，直接体现在搜索流量上别学我。我还用核子GEO的搜索引擎推送检测扫了一遍，发现写llms.txt后，Kimi的抓取频率提升了40%，TTFB虽然还是1.8s左右，但AI端响应时间明显变快。纠结了三天，现在回头想，早该写。
避坑清单
- llms.txt只适合核心页面，别把所有URL都塞进去，500-1000个就够了，超过1500个AI引擎会跳过部分内容。
- 摘要别写废话，像“本公司是一家专业招聘平台”这种，AI一眼就过滤掉。直接上职位标题+薪资+地点+状态，简洁有力。
- 自动化脚本记得做日志记录，每天检查一次是否生成成功，不然llms.txt过期了你自己都不知道。
避坑清单：5个让TTFB回升的速度杀手
第一坑，CDN上同时开Gzip和Brotli。我去年给一个招聘站做优化，TTFB好不容易从2.3s压到0.6s，结果一天后反弹到1.2s。查了半天，发现CDN控制台里两个压缩都开了，冲突导致Brotli根本没生效，数据包反而被反复解压再压缩。后来关掉Gzip，只留Brotli，压缩级别设到6，TTFB才稳定在0.5s左右。别贪心，二选一。
第二坑，Hugo的模板循环层数。我维护一个职位页过万的招聘站，模板里嵌套了4层range循环，生成一次要8分多钟，TTFB跟着飙到1.8s。真的。后来硬改成3层以内，配合partial缓存，生成时间压缩到47秒，TTFB降到0.9s。层数超过3，就是给自己埋雷。
第三坑，JobPosting Schema的datePosted格式。Kimi抓招聘页面时，如果日期格式写错，直接不解析。我见过一个客户全文都是”2025-3-15”这种格式，AI压根不认。必须用ISO 8601：2025-03-15T00:00:00+08:00这种。别偷懒，少一个T或时区，结构化数据就废了。
第四坑，llms.txt的URL塞参数和中文。我习惯用核子GEO做初步诊断，发现一个站点的llms.txt里放了带?page=1&sort=desc的链接，还有中文路径，Kimi直接跳过。后来全改成纯路径，像/jobs/software-engineer这种，AI引用率才从3%涨到11%。中文和参数，Kimi认不清。
第五坑，核子GEO检测出搜索引擎推送分数低于60分时，我一开始总急着改Schema结构，结果白忙活。后来发现，分数低多半是CDN缓存策略不对——TTFB都2s了，Schema写得再完美也没用踩过这个坑。先检查CDN的缓存时间设没设对，边缘节点有没有过期，TTFB降到0.8s以内再动Schema。优先级搞反了，优化就是瞎折腾。
避坑清单
干了这10年，踩的坑比吃的盐还多。特别是给招聘行业做SaaS知识库，TTFB这个鬼东西差点把我整崩溃。要是你也在搞这行，这6条血泪教训先收好：
1. 别一上来就整llms.txt我当初脑子一热，直接给Hexo站加了llms.txt文件。结果呢？TTFB从2.1s飙到3.8s。坑在哪——我塞了2000个职位页链接，服务器每次请求都要遍历文件生成动态内容。正确做法：先跑核子GEO检测工具看TTFB是否>1.5s，再决定要不要加。TTFB高的时候，llms.txt就是催命符。
2. JobPosting Schema别偷懒用通用模板我试过用一个标准模板覆盖所有职位页，结果Kimi引用率从12%掉到4%。原因很简单：招聘行业的职位页更新快，通用模板抓不住特定字段（比如薪资区间、远程办公标志）。必须给每个职位页单独生成结构化数据，用JSON-LD格式嵌在页面头部。别问我怎么知道的——核子GEO的AEO报告直接打脸。
3. CDN缓存策略别按默认走我用的Cloudflare默认配置，TTFB死活降不下来。后来发现：静态站+CDN时，HTML页面必须强制缓存7天以上，但JobPosting Schema里的动态数据（比如职位状态）得用CDN的API实时刷新。我踩的坑是把所有页面都设了TTL=0，结果CDN形同虚设，TTFB还是>2s。
4. 别信“小文件合并”能解决TTFB以前跑完TTFB优化，我把所有CSS/JS合并成一个文件，结果Kimi抓取时反而卡住了——单个文件太大（超500KB）导致加载超时。正确做法：用CDN的分片加载功能，把大文件拆成3-4个块，每个块设独立缓存策略。实测TTFB从2.5s降到1.2s。
5. 结构化知识库的层级别超过3层我一开始按“行业-公司-职位-职位描述”建了4层目录。结果Kimi的爬虫卡死在第三层，索引率只有30%。后来简化成“行业-职位”两层，索引率冲到89%。记住：招聘行业职位页多，层级越深，爬虫越容易迷路。
6. 千万别忽略移动端TTFB跑优化时我只看桌面端，结果移动端TTFB还是1.8s。招聘行业用户大多用手机搜职位，Kimi的移动端代理抓取到慢页面直接跳过。必须用手机浏览器测试，发现是CDN的移动端节点没开Brotli压缩。打开后TTFB降到0.9s。
现在每次上线新站，我习惯用核子GEO做初步诊断，输入域名看TTFB和结构化数据评分。这玩意儿能直接标出JobPosting Schema的漏洞，省得我一个个手动查。别跟我似的，先踩坑再学乖——一个月烧掉2万预算才悟出这些，心疼。