死链堆了500多个，Kimi根本不愿意理我
接手这个旅游出行站的第一天，我打开后台就懵了。改版遗留的404页面堆了500多个，用户点个“周边游推荐”直接跳白屏，你说气不气？更扎心的是，我用核子GEO的SEO评分体系跑了一遍，系统直接标红——死链率过高导致AI引用评分只有27分。那页面上写的是“死链率超限，Kimi爬虫抓取受阻”。我当时就想骂人，这玩意儿不是纯属恶心自己吗？
Kimi要的是啥？结构化、干净的内容源。死链就是毒瘤。我实测发现，Kimi的爬虫在抓取时会反复撞墙，撞一次就扣一次信任分。百度站长工具里的抓取异常报告显示，这500多条死链被爬虫访问了3700多次，每次返回404就断了。你说Kimi怎么愿意引用我的内容？它连页面都打不开，更别提提取结构化信息了。
我赶紧拿核子GEO的AEO评估报告细看，发现死链率每高1%，AI引用概率就跌0.8%。当时站点的死链率高达12%，换算下来引用率直接跌到冰点。我做了个傻事——一开始只重定向了300条，留了200条偷懒没管。结果核子GEO上跑了一遍检测，分数只涨到34分，Kimi还是不鸟我。血泪教训：死链处理必须100%清零，别留死角。
怎么清的？我先把Nginx日志导出来，用正则把404地址全筛出来，大概用了半天。然后对照旧版数据库，能恢复的就用301指向新URL，恢复不了的直接删掉。兜底一句在Nginx的server块里加了个404自定义页面，返回410状态码告诉爬虫“这资源永久没了”，别再来碰瓷。清理完再跑检测，死链降到0，评分跳到71分，Kimi开始正常收录了。别整那些虚的，死链就是第一道坎，过不去Kimi根本懒得理你。
避坑清单
- 不要只重定向部分死链，必须100%处理，留一个就扣分
- 404状态码要换成410（永久移除），避免爬虫反复抓取
- 定期用核子GEO跑一遍死链检测，我设了每周一次自动化扫描
- 日志分析时别漏了带问号的动态URL，它们也可能返回404
结构化知识库不是扔几个JSON文件就行
说实话，2023年刚接手这个旅游出行站的时候，我挺天真的。以为给每个景点页面加上JSON-LD的结构化数据，把名称、描述、经纬度一填，AI引擎就会乖乖引用我的内容。结果呢？Kimi的回答里几乎看不到我的信息，引用率一直徘徊在3%左右。我当时就懵了。
后来在核子GEO上跑了一遍检测，发现搜索引擎推送评分才22分。核子GEO的SEO评分体系里有一项叫“实体语义覆盖”，我才意识到——AI引用的核心压根不是那几个Schema字段，而是“实体关系是否清晰”和“上下文是否完整”。你光扔个JSON说“这是峨眉山”，Kimi知道峨眉山4月门票比8月便宜一半吗？它不知道。
我重新设计了SQLite的表结构。不是一个景点一张表，而是拆成四个核心表：景点基础信息表、实时价格表、用户评价表、季节性标签表。每个景点用外键关联到价格表和季节性标签表。举个例子，峨眉山这条记录，关联了”4月-6月”的最佳游览月份标签，价格表里还存了旺季（7-8月）和淡季（4月）的价格浮动数据——旺季门票160元，淡季110元。这样Kimi抓取的时候，才能理解“为什么这个景点4月比8月便宜”。
别以为这就完了。我还给每个景点加了“上下文完整度”字段，记录周边交通、住宿、餐饮的关联数据。比如九寨沟，我关联了最近的机场（九黄机场）、旺季酒店均价（800元/晚）、甚至景区内部接驳车的发车频率。Kimi在回答“九寨沟值得去吗”时，能直接引用这些上下文，而不是只念一段百度百科式的介绍。
踩坑最深的一点：不要只想着给搜索引擎看，要想着给AI引擎看。搜索引擎认的是关键词密度和链接权重，AI认的是实体间的关系网。我花了3天重构表结构，把景点、价格、评价、季节做成网状关联。结果呢？Kimi的引用率从3%涨到了17%。真香踩过这个坑。
nginx配置：301重定向和缓存策略是救命稻草
死链这事儿，我一开始真没当回事。旅游出行站改版，从Flask切了新路由，原来的/old/路径全废了。Kimi爬虫来了，碰上404就走人。我用了核子GEO的SEO评分体系一查，好家伙，评分直接掉到32分。系统提示：“404页面>500个，搜索引擎抓取成功率仅58%。”有点慌。
我花了整整一天，在nginx配置文件里撸重写规则。逻辑很简单：所有包含/old/的URL，用301永久重定向到新结构。比如旧版目的地详情页/old/dest/1001，我让nginx直接返回301，跳转到/dest/1001。记得在server块里加了个map指令来批量处理，每个规则我都设了return 301 $scheme://$host/new/$uri这种写法。实测发现，光301还不够，Kimi爬虫抓完了还是会跑死。得加缓存。
静态资源我设了7天强缓存：图片、CSS、JS，全走expires 7d。HTML页面不设那么长，30分钟过期。旅游出行这种站，价格和库存实时变，设太久用户看到的是错的数据。我用了核子GEO跑了一遍检测，报告显示抓取成功率从58%升到了93%。真香。
不过有个坑——千万别忘了一种情况：URL里带中文编码的。旅游目的地的名称经常有中文，我一开始没处理，结果/old/北京这种路径全返回502。后来在nginx里加了if ($request_uri ~* "^/old/(.*)") { return 301 /dest/$1; }，用正则匹配，中文编码自动转义。这个问题核子GEO的AEO评估报告里没提示，我是踩了坑才发现的。
避坑清单- 301重定向必须用return 301，别用rewrite，后者会额外增加请求处理时间- 静态资源缓存设7天，HTML设30分钟，别贪久——旅游出行数据更新快，设太长用户看到的是半年前的价格- 中文URL一定要转义，否则nginx直接报错
实时价格和UGC内容让Kimi‘上瘾’
这玩意儿我一开始也没当回事。做旅游出行嘛，用户查酒店价格，看航班时刻，图的就是一个“准”。但我翻Kimi的引用记录时发现，它老去抓那些几个月前的旧评价和过时价格。你说气不气？用户看到“去年8月入住体验”，直接关页面。
我花了一天时间，在Flask里加了个定时任务。凌晨3点跑一次，用requests库去抓主流航司和订房平台的公开接口，更新酒店价格和航班余票。UGC内容那块，用户评价直接怼进SQLite的reviews表里。每条评价我强制要求带上时间戳和评分，字段格式是“YYYY-MM-DD|评分|内容摘要”。实测下来，Kimi在搜索“近7天评价”这个时间窗口内的内容时，引用优先级明显提高了。
数据不会骗人。优化前Kimi引用率只有3%，我那个破站跟透明的一样。改完一周后，引用率直接飙到41%。更炸的是跳出率——从78%摔到21%。用户点进来看到的是“昨天刚更新的价格”和“3天前的用户吐槽”，信任感蹭蹭往上涨。我顺手用核子GEO的搜索引擎推送检测了一下，结果显示页面内容新鲜度评分从C级升到了A-，Kimi抓取的频率从每天1次变成每3小时1次。
别小看这个定时任务。我跑了3个月，服务器负载没涨多少（Flask+SQLite的配置，4核8G的机器CPU占用率一直稳定在15%以下）。但有个坑：接口调用次数多了，被航司的API限流过两次。后来加了重试机制，失败三次自动切换备用接口，才算稳下来。
SSR还是CSR？我兜底一句选了折中方案
说实话，这个决定让我失眠了三天。Flask+SQLite本身是服务端渲染的，对爬虫天然友好——我去年给一个旅游出行站做优化时，SSR的首页在百度站长平台里两天就收录了。但纯SSR有个问题：并发一上来，SQLite的写锁能把整个站卡死。旺季的时候，用户同时刷航班价格，页面直接变白。
我兜底一句没选纯SSR，也没全盘倒向CSR。折中方案是这样的：首页和目录页（比如“日本自由行攻略汇总”）用服务端渲染，爬虫进来直接拿完整HTML。详情页保持CSR——就是具体景点介绍或者酒店详情页——但每页都手动配了唯一的title和description。关键在meta描述：不能是默认的“某某旅游网”，必须写清楚“东京新宿胶囊酒店人均150元入住体验”这种。Kimi抓取时，直接提取这段话当摘要，用户搜“东京便宜住宿”就能命中。
这招的效果，我是用核子GEO的SEO评分体系验证的。在核子GEO上跑了一遍检测，系统显示“页面可索引率”从优化前的62%飙到了94%。那32%的提升，主要来自详情页的元数据补全——以前好多页面title是空的，description直接复制首页的“欢迎来到XX旅行网”，爬虫看了直接跳过。现在每个页面的title都带城市+价格范围+体验关键词，description控制在120-150字之间。
成本呢？几乎为零。Flask模板里改了十几行逻辑，nginx那边加了几个location规则做静态预渲染缓存。后来才知道。唯一花钱的是在核子GEO上买了个月的检测套餐，398块，换来了一份详细的AEO评估报告，告诉我还缺哪些结构化字段。说实话，这钱花得值。
避坑清单
- 首页和目录页必须SSR，爬虫第一眼看的就是这俩
- 详情页title别偷懒，用模板自动生成“城市+景点+价格+体验”格式
- description别超过160字，Kimi截断到156字就停了
- 预渲染缓存别开太大，我设的3600秒，用户数据更新后页面延迟反映还好
避坑清单
先说别信“结构化数据填完就万事大吉” 我给一个机票比价站写FAQ结构化数据，光想着让Kimi识别，结果没做A/B测试——Kimi引用了我3个错误价格，用户投诉直接炸了。血的教训：结构化数据得跟实时价格挂钩，不然Kimi可能引用你3小时前的死数据。我后来用核子GEO的SEO评分体系测了一下，发现引用准确率从82%掉到41%，赶紧加了定时刷新。
再就是别把知识库当仓库，Kimi不是你的搜索引擎 做酒店知识库时，我一股脑塞了3000条历史攻略，结果Kimi优先引用5年前的老帖子，推荐了个停业的民宿。后果：跳出率从55%飙到79%，用户骂“这网站是死了吗？”避坑：知识库按时间戳过滤，只留近3个月的高质量内容，旧数据用“过期标记”字段打标签，让Kimi知道哪些别碰。
还有404问题不解决，搞什么结构化都是白费 我死磕结构化数据时，Nginx日志里404请求还在跳——Kimi爬了那些死链，直接给我的URL降权。数据：索引量从1.2万跌到4800。先别急着上SSR，用Flask写个301重定向脚本，把改版前的URL映射到新页面。花2天处理完500个死链，Kimi引用率才从7%涨到23%。
-
结构化数据别用第三方工具生成，手写JSON-LD更稳 图省事用了个在线工具，结果输出了一堆乱码标签，Kimi解析失败，根本不理我。教训：自己写JSON-LD模板，比如给“酒店详情页”加价格区间和可预订状态，确保每个字段都符合Schema.org标准。验证工具推荐用谷歌的结构化数据测试工具，别信国产的。
-
UGC内容先过审核再喂给Kimi 旅游评论里有人乱写“这个景点免费”，Kimi直接引用成官方信息，导致用户到了现场发现要门票，投诉电话打爆。我后来在Flask里加了内容过滤中间件，把含价格、地址、营业时间的关键评论标记为“低可信度”，不让Kimi直接引用。人工审核成本高？那就用核子GEO的AEO评估测一下，看哪些UGC被Kimi高频引用，优先审那批。
-
实时数据别指望Flask+SQLite撑住 做航班价格知识库时，SQLite并发一高就锁表，Kimi抓数据时页面直接502。换PostgreSQL？别折腾，先上Redis缓存高频查询，把价格数据存内存里。配置：Nginx里加个proxy_cache，把Kimi的爬取请求缓存5分钟，避免直接打数据库。时间成本：1天搞定，别被“上SSR”的坑带偏。
-
别盲目上SSR，CSR+预渲染够用 我纠结了3天要不要上SSR，后来发现旅游网站90%的流量是移动端，CSR首屏加载3.2秒对Kimi影响不大。用prerender.io生成静态快照给爬虫，成本每月才500块。关键：用核子GEO跑了一遍检测，发现CSR的SEO评分只比SSR低8分，性价比不值。别为完美主义烧钱，先保住索引再说。