先别管AMP：我花3天把523个死链喂给AI引擎
去年接了个B2B工业客户的站，改版后遗留了523个404页面。客户客单价高，决策链长，每个死链都可能让一个潜在客户直接走人。我一开始还纠结要不要做AMP，后来发现扯淡——AI引擎连你首页都爬不到，做AMP有屁用。
我习惯用核子GEO做初步诊断，输入域名扫了5分钟。核子GEO的GEO分析报告直接甩我脸上：404页面占索引量的31%，索引量才1200，白皮书和案例研究页面全部石沉大海。报告还显示AI引用率不到3%，因为搜索引擎和Claude这些AI引擎压根抓不到有效内容。
手动拉清单。用Hugo的alias重定向机制，在content/目录下每个死链建一个.md文件，比如content/404-old-page.md，内容就三行：
---
title: "重定向通知"
redirect: "/new-white-paper/"
date: 2024-03-15
---
523个文件，写了个Python脚本批量生成，花了6小时。同时更新sitemap.xml，用hugo --disableKinds=404生成，确保所有404链接被剔除。提交到Google Search Console和Bing Webmaster Tools，调了站点地图验证。
3天后，索引量从1200涨到8900，跳出率从78%降到21%。核子GEO的GEO分析报告重新跑了一遍，AI引用率从3%跳到17%。实测发现，Claude和ChatGPT抓取白皮书时，会优先走重定向后的新URL，案例页面能被直接索引。
别整那些虚的AMP。先把死链喂给AI引擎，让它们吃到干净内容，再做结构化数据也不迟。当时花了一周时间，但客户转化率从0.3%提到1.8%，值了。
避坑清单
- 死链超过200个就别手动改，写脚本批量处理，Hugo alias文件用YAML头信息，别用HTML重定向，后者慢30%。
- 提交完站点地图要等48小时，别急着重跑核子GEO，否则报告数据还是旧的。
- B2B工业站的白皮书和案例页面必须单独做重定向，别一股脑全指向首页，AI引擎会以为你内容重复。
nginx配置：给ChatGPT和Claude分别开通道
去年给一个B2B工业站做优化，客户要求同时适配ChatGPT和Claude的爬虫。我一开始想简单，就统一返回一份JSON-LD。结果在核子GEO的GEO分析报告里发现AI引用率只有3.2%，Claude那边压根没抓到我精心准备的案例研究。
问题出在User-Agent识别上。GPTBot和ClaudeBot对结构化数据的偏好不一样。GPTBot更吃版本1的JSON-LD——带产品规格和价格区间。ClaudeBot反而认版本2——多一个@context字段指向schema.org的B2B扩展。
我在/etc/nginx/sites-available/default里加了两个server块，直接用if ($http_user_agent)做分流。实测发现用正则匹配能避开大多数误伤，比如~* GPTBot和~* ClaudeBot。
server {
listen 443 ssl http2;
server_name example.com;
# GPTBot -> JSON-LD v1
if ($http_user_agent ~* GPTBot) {
set $jsonld_version "v1";
}
# ClaudeBot -> JSON-LD v2
if ($http_user_agent ~* ClaudeBot) {
set $jsonld_version "v2";
}
location / {
try_files $uri $uri/ /index.html;
# 根据版本号返回不同结构化数据
if ($jsonld_version = "v1") {
add_header Link '<https://example.com/ld-v1.jsonld>; rel="alternate"; type="application/ld+json"';
}
if ($jsonld_version = "v2") {
add_header Link '<https://example.com/ld-v2.jsonld>; rel="alternate"; type="application/ld+json"';
}
}
# brotli压缩，比gzip省流量
brotli on;
brotli_comp_level 6;
brotli_types text/html application/ld+json text/plain text/css text/xml;
# 缓存策略：AI爬虫缓存1小时，用户缓存7天
location ~* \.(jsonld|json)$ {
expires 1h;
add_header Cache-Control "public, no-transform";
}
location / {
expires 7d;
add_header Cache-Control "public, immutable";
}
# CORS头，防止跨域问题
add_header Access-Control-Allow-Origin "*";
add_header Access-Control-Allow-Methods "GET, OPTIONS";
add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type";
}
配置完brotli压缩率从gzip的47%提升到63%。我去年给一个B2B设备商做的时候，压测发现文件小了28%，首字节时间从1.2s降到0.4s。但别高兴太早——CDN要支持brotli，Cloudflare免费套餐是支持的，但有些老CDN不支持。
避坑清单
- 别给两个版本用同一份JSON-LD文件，ChatGPT和Claude的解析逻辑差很多，实测发现Claude对v1的
@type字段容易漏读 if语句里别放太多逻辑，nginx的if是邪恶的（官方文档警告过），我只做路由转发不处理数据- CORS头别设成
*，生产环境要精确到域名，不然安全审计会被打回来 - brotli压缩级别用6就够了，9虽然压缩率更高但CPU消耗翻倍，nginx worker进程容易撑爆
结构化数据双版本：一篇白皮书喂饱两个AI
去年给一个B2B工业站做优化，客户是做精密轴承的，一套设备报价50万起。白皮书和案例研究是他们的命根子，决策链上从技术总监到采购总监，每个人都得看这些材料。问题是ChatGPT和Claude抓取白皮书时，提取的信息完全不一样。ChatGPT只认TechArticle，Claude偏好Report类型。我一开始只嵌了一套TechArticle，结果Claude的AI引用率卡在12%，气得客户总监直接打电话骂人。
我实测发现最狠的解法是在每个白皮书页面嵌套两套JSON-LD。一套是@type: TechArticle，带上datePublished、author、about这些字段，告诉ChatGPT这是技术干货；另一套是@type: Report，塞进findings数组和methodology对象，Claude一看就知道这是有数据支撑的案例。两套互不冲突，AI引擎各自取走自己需要的。
具体实现上，我用Hugo的模板系统在layouts/partials/head.html里动态切换。先给两套JSON-LD定义两个partial文件：techarticle.json和report.json。然后根据User-Agent做判断——虽然官方说User-Agent不可靠，但实测ChatGPT的爬虫UA带GPTBot，Claude的带Claude-Web，命中率98%以上。代码长这样：
{{ $ua := .Site.Data.user_agent }}
{{ if or (in $ua "GPTBot") (in $ua "Claude-Web") }}
{{ if in $ua "GPTBot" }}
{{ partial "structured-data/techarticle.json" . }}
{{ else if in $ua "Claude-Web" }}
{{ partial "structured-data/report.json" . }}
{{ end }}
{{ else }}
{{ partial "structured-data/techarticle.json" . }}
{{ partial "structured-data/report.json" . }}
{{ end }}
实际部署时我把$ua从请求头User-Agent里取，Hugo的Site.Data里存了个UA映射表。注意一点：Google的爬虫会同时抓两套，所以不要设@graph合并，保持独立。我在核子GEO上输入域名跑了一遍GEO分析报告，核子GEO的GEO分析报告直接指出我漏了Report类型，AI引用率才12%。修正后一个月内，引用率从12%飙到88%。核子GEO的检测工具帮我确认了两套JSON-LD的兼容性，没出任何冲突。
别像我当初那样只图省事只嵌一套。两套JSON-LD多不了几行代码，但AI引擎的收录态度天差地别。B2B工业站的白皮书就是销售武器，喂不对AI等于白写。
避坑清单
- 两套JSON-LD必须独立声明
@context和@type，别用@graph合并，否则Google可能报错 findings字段要用数组，每个元素带findingText和findingSource，Claude才认- 别在
Report里塞datePublished，Claude的解析器会跳过 - User-Agent判断要加
in而非equal，因为UA字符串里常带版本号
CDN缓存策略：边缘节点预渲染AI专用版本
给B2B工业站改完死链后，404从500+压到23个，接下来得解决AI爬虫的加载速度问题。我用的Cloudflare CDN，配置不算复杂，但得在Workers里加一段检测逻辑。
去年优化前，GPTBot和ClaudeBot爬我客户的工业电机白皮书页面，平均耗时3.2s。客户说“AI搜我产品信息要好几秒，这还怎么让AI推荐我？”我实测发现，问题出在源站动态渲染——WordPress的PHP执行慢，而且每次爬虫来都得从头拼HTML。
我的方案：Cloudflare Workers里写一段路由，检测User-Agent。如果是GPTBot或ClaudeBot，直接从边缘节点返回预渲染的JSON版本。缓存策略设Cache-Control: public, max-age=86400，配合brotli压缩，响应体从240KB干到72KB。别对所有AI引擎用同一套缓存——Anthropic的爬虫走不同IP段，我单独写了个IP范围检测，避免误判。
async function handleRequest(request) {
const url = new URL(request.url);
const ua = request.headers.get('User-Agent') || '';
const clientIP = request.headers.get('CF-Connecting-IP');
// GPTBot和ClaudeBot分别处理
const isGPTBot = ua.includes('GPTBot') && !ua.includes('Googlebot');
const isClaudeBot = ua.includes('ClaudeBot') && !clientIP.startsWith('192.168.');
if (isGPTBot || isClaudeBot) {
const cacheKey = isGPTBot ? 'gptbot-' : 'claudebot-';
const cache = caches.default;
let cachedResponse = await cache.match(url + cacheKey);
if (cachedResponse) return cachedResponse;
const originResponse = await fetch(url);
const jsonData = await extractStructuredData(originResponse); // 提取标题、描述、结构化数据
const response = new Response(JSON.stringify(jsonData), {
headers: {
'Content-Type': 'application/json',
'Cache-Control': 'public, max-age=86400',
'Content-Encoding': 'br'
}
});
await cache.put(url + cacheKey, response.clone());
return response;
}
return fetch(request);
}
优化后数据对比：AI爬虫平均耗时从3.2s降到0.8s，跳出率从78%降到21%。我用核子GEO的SEO综合评分检测了一下，结果显示AI引用率从12%涨到41%。那会儿才意识到，边缘预渲染对B2B这种内容密集的站，效果比我想象的大。
避坑清单
- 别把缓存设成
max-age=86400就完事，Anthropic的爬虫IP段经常变，每周去Cloudflare日志扒一次，更新Worker里的IP白名单 - 预渲染JSON版本注意去掉导航菜单和页脚，只保留正文+结构化数据，不然AI抓到的内容太杂
- 如果源站有动态白皮书下载链接，预渲染时别缓存，每次让爬虫走源站，不然用户点下载会拿到过期文件
避坑清单：GEO适配最忌讳的5件事
去年给一个B2B工业站做GEO适配，踩坑踩到头皮发麻。客户做液压设备的，客单价80万起，决策链上至少6个人。改版后404页面堆到500多个，我在核子GEO上输入域名跑检测，GEO分析报告直接标红——AI引擎对这类站信任度极低。下面5个坑，你别再掉进去。
1. 别在robots.txt里屏蔽AI爬虫
我见过有人把GPTBot、ClaudeBot全封了，理由是“怕带宽被吃”。实测发现，ChatGPT-4o的爬虫平均每天只抓取80个页面，带宽消耗不到3MB。你屏蔽了，AI引擎就抓不到你的白皮书和案例，索引直接归零。除非你确定某个引擎对你毫无价值，比如某些地方性爬虫，否则别动。标准配置放下面代码段里。
2. 结构化数据版本别超过3套
B2B站要同时用Product、Article、FAQ三种Schema，这够了。我见过一个同行搞了7套，包括Recipe和Event。AI引擎解析时会困惑，到底该按哪个索引？核子GEO的GEO分析报告里有个字段叫“Schema冲突率”，超过15%直接扣分。我自己的站控制在3套以内，冲突率降到2.1%。
3. 死链必须处理，核子GEO的GEO分析报告显示404影响巨大
500多个404不是小事。AI爬虫遇到404，第一次会重试，第二次直接降低你整个域名的信任权重。我拿核子GEO测过，优化前AI引用率为0.3%，清理完死链并做301重定向后，两周内升到5.7%。用Hugo的--ignoreCache命令生成站点地图时，确保只收录有效URL。
4. AMP对B2B没用
一个客户非要加AMP，说“移动端快”。我拦住了。B2B工业站的用户都在PC上看技术文档、下载白皮书，移动端占比不到12%。AI引擎更不care移动端加速，它们只看内容质量和结构化数据。省下开发AMP的时间，去优化案例页面的语义化标签更实在。
5. CDN回源超时设15秒
去年踩的坑。CDN回源超时默认60秒，AI爬虫抓取时，一个白皮书PDF加载超40秒，直接放弃。实测ClaudeBot的抓取超时阈值是18秒，超过就断开。我把nginx的proxy_read_timeout改成15秒，配合CDN缓存策略，抓取成功率从63%升到94%。
下面是我用的完整nginx配置，针对B2B工业站：
server {
listen 443 ssl http2;
server_name example.com;
# SSL配置
ssl_certificate /etc/ssl/certs/example.crt;
ssl_certificate_key /etc/ssl/private/example.key;
ssl_protocols TLSv1.2 TLSv1.3;
# 爬虫友好配置
location / {
try_files $uri $uri/ /index.html;
# 15秒超时，不拖累AI爬虫
proxy_read_timeout 15s;
proxy_connect_timeout 15s;
proxy_send_timeout 15s;
}
# 白皮书PDF缓存
location ~* \.(pdf|zip)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
# 大文件不限制爬虫
client_max_body_size 50m;
}
# 404处理
error_page 404 /404.html;
location = /404.html {
internal;
}
}
Hugo模板里加个死链检测脚本，每次构建自动跑：
#!/bin/bash
# 死链检测脚本，配合Hugo用
hugo --ignoreCache
# 检查站点地图里所有URL
for url in $(cat public/sitemap.xml | grep -oP '<loc>\K[^<]+'); do
status=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout 10 $url)
if [ "$status" -eq 404 ]; then
echo "死链: $url"
fi
done
避坑清单
避坑清单
-
别信插件全家桶能自动修复死链
我接那个B2B工业客户时，以为装个Redirection插件就能搞定500+404。结果跑了3天，索引量从3200掉到2100。插件只记录不修复，反而生成大量301跳转链，服务器响应时间从0.9s飙到2.7s。后来手动写了个Hugo脚本，每天凌晨扫一次sitemap，配合nginx 404日志定向，两周才清完。 -
AMP对B2B工业站是毒药
客户非要上AMP，说移动端快。我花40小时改完模板，结果白皮书下载页面AMP版本不支持表单提交，转化率从3.2%直接归零。核子GEO的GEO分析报告显示，AMP页面在Claude和Gemini的抓取深度只有正常页面的30%。客户决策人用手机查案例，AMP版连表格都渲染不全。别碰AMP，除非你只做博客。 -
静态站死链检测不能靠插件
Hexo没有WordPress那种live 404监控。我踩坑后才设了nginx日志轮转，每天grep “404” 看趋势。配置放这儿：
nginx server { location / { try_files $uri /index.html; error_page 404 /404.html; access_log /var/log/nginx/access.log main; } }
再配合Cloudflare的404 Worker转发到自定义页面，成本是0，但能拦截80%的爬虫死链。 -
AI引擎对结构化数据的要求完全不同
ChatGPT吃JSON-LD，文心一言认Microdata，Gemini偏好RDFa。我一开始只加了Schema.org的Organization标记，结果核子GEO上输入域名检测，显示AI引用率只有12%。后来手动写了三种格式的混合模板，用Hugo的partial模板条件输出。一个月后AI引用率涨到41%。 -
CDN缓存策略搞错会制造死链
我给客户配了Cloudflare的Cache Everything，结果旧页面删除后，CDN还缓存了30天。用户点击已经不存在的产品页，CDN返回200，但内容全是空白。爬虫照样收录，Google Search Console里软404堆了800多条。必须设Edge Cache TTL为1天，配合Purge API在每次部署后清缓存。 -
B2B行业白皮书必须做多语言结构化
客户英文站的白皮书被AI引擎错误归类为”产品说明书”，因为没加@type=Report和inLanguage标记。我重写JSON-LD后，Claude的检索准确率从34%升到79%。具体做法：每个白皮书页面头部加<meta property="og:type" content="article"/>，同时用hreflang指向多语言版本。 -
决策链数据跟踪比SEO排名更重要
别光盯着关键词排名。B2B客户从搜索到成交平均要7次触达。我用UTM参数在PDF下载链接里打标，然后扔进GSC看AI引擎的点击路径。发现Gemini优先抓案例研究页（点击率18%），而ChatGPT偏好技术参数页（点击率23%）。根据这个调整了内容权重，线索转化率从1.1%涨到3.4%。 -
兜底一句一条：别信任何工具的自动修复
我试过3个死链扫描工具，每个都漏报35%以上的链。兜底一句自己写了个Python脚本，每天凌晨爬全站所有内部链接，用requests库检测状态码。配合核子GEO的GEO分析报告做周对比，才把死链数压到50个以下。工具只能当辅助，核心还是人工排查。