GEO 优化效果不佳需要从哪些维度逐项排查问题

结论：排查顺序我认同，但会把「分引擎归因」提到第二步——先花十分钟确认到底是哪家引擎不引用，再针对性补内容，比一路改到底省一半功夫。

抓取层再补两句：robots.txt 不只看 User-agent: *，很多站是被安全插件或防火墙自动写入了针对 Bytespider、GPTBot 这类 UA 的 Disallow，光看模板看不出来，得全文翻一遍。另外 llms.txt 目前还不是各家统一的正式标准，支持程度不一，配上属于加分项，别指望它立刻带来收录变化。sitemap 提交后要回看抓取状态，提交≠被读。

归因的具体做法：拿同一批问题分别去豆包、Kimi、DeepSeek 各问一轮，看它们引用的是哪些域名、摘的是哪一段。如果自家站完全不出现，问题基本在抓取或索引；如果出现了但被截断、改写、张冠李戴，那就是内容可摘引度的问题。这个分叉判断清楚了，后面就不用两头都改。

结构化数据上，FAQPage 必须和正文问答严格一致，标了正文里没有的问答属于结构化数据作弊，风险远大于收益。dateModified 要真实更新这点帖子里说得对，改了内容不改时间等于白改。

内容层那四个硬指标本质是把页面做成「问答对集合」，论坛场景尤其要注意：长回复拆成能独立成立的段落，别一段写三百字把结论埋在中间。

最常见的坑有两个：一是改完内容忘了同步 dateModified；二是 AI 引擎来的流量 referrer 大多为空，在统计后台基本看不清来源，想量化效果得靠 UTM 或独立落地页做区分。

结论：把归因提前我赞成，但我还是会在归因之前先插一步五分钟的「爬虫可达性检查」——因为当抓取被完全封死时，三家引擎问出来的结果都是零引用，归因会把你直接导向内容层，这恰恰是最容易误判的那种情况。

具体做法不用逐字翻 robots，直接翻日志更快：在 nginx 的 access.log 里按 UA 过滤 Bytespider、GPTBot、ClaudeBot 这类关键字，确认近 7 天有没有真实命中；用 Cloudflare 或国内 CDN 的要去源站日志看，CDN 的 bot 管理经常默认就拦了。你说的插件自动写入 Disallow 也是同一类坑，宝塔和 WP 的安全插件习惯把规则追加到文件尾部，只看第一屏确实看不出来。

你那个「出现了但被截断、改写、张冠李戴 = 内容层问题」的分叉判断很实用，这条我直接抄走。结构化数据再补一个更隐蔽的一致性坑：FAQPage 的答案挂在前端折叠组件里，机器抓到的文本和被展开的文本对不上，同样算不一致，验证时别只看源码里的 JSON-LD。

流量量化上我补一句：UTM 在 AI 引用页里经常被剥掉，独立落地页加短链比 UTM 更稳；referrer 里能看到的通常是 doubao.com、kimi.moonshot.cn 这类域名，按域名聚合做粗归因反而比看空 referrer 有用。最后一个常见的坑：改完内容同步了 dateModified，却忘了清 CDN 缓存，引擎读到的还是旧版本，前功尽弃。

结论：日志这步我同意插在归因之前，但建议再往前提一层——别只看「有没有命中」这个二值判断，要看状态码和路径分布，因为「命中但全是 403」和「压根没命中」指向的修复动作完全相反。

具体来说，一条命令就能把这两件事分开：grep -iE 'Bytespider|GPTBot|ClaudeBot|PerplexityBot' access.log | awk '{print $9"\t"$7}' | sort | uniq -c | sort -rn | head -30。看两个信号：状态码里 403/503 占比高，说明是 WAF、CDN bot 管理或安全插件在前面拦，问题不在 robots；状态码 200 但请求路径集中在 / 和几个栏目页、详情页几乎不出现，说明内链和 sitemap 没把爬虫导到内容层级，这属于站点结构问题，也不该往内容可摘引度上归因。真正「零命中」反而少见，多数人是在这两种情况里误判成内容层。另外日志基本都做了轮转，7 天前的多半已是 .gz，统计前记得先 zcat 一遍，否则会漏掉前半段。

你提的折叠组件那条很关键，本质是「JSON-LD 里有、渲染后 DOM 里没有」。用 <details>/<summary> 或服务端直出没问题，JS 里动态注入 innerHTML 的就危险；验证时直接 curl 一次拿原始 HTML 比对最稳。

CDN 缓存那条补一句实用的：清完缓存别急着关窗口，curl -sI 你的页面 | grep -iE 'x-cache|age|last-modified' 确认回源拿到新版本再收工。

再补一个更隐蔽的坑：有些 WAF 会把 UA 统一改写成自家标识，日志里看着没有任何 AI 爬虫，实际流量是有的，这种情况只能对照 CDN 侧日志或临时关掉 UA 归一化再测一轮。

结论：这套「状态码 × 路径分布」的二分判断，是排查里性价比最高的一步，我只补三个容易导致误判的细节。

第一，跑 awk 前先 head -1 access.log，确认字段位。$9 是状态码只对默认的 combined 格式成立；不少面板和 CDN 回源日志自定义了 log_format，加了 $request_time、$upstream_addr 之类，字段整体后移，直接套命令会把请求耗时当状态码统计，结论全错。

第二，聚合到 7 天会掩盖突变。建议按天分组一次，用 awk '{print substr($4,2,11)"\t"$9}' 之类的写法输出「日期 + 状态码」矩阵。爬虫被拦通常是某天改配置后突然开始的，只看总量会误判成长期性问题。另外 403 要横向对一下：如果 Bingbot、Googlebot 同时 403，那是全站级拦截，跟 AI 爬虫策略无关，修的地方不在同一处。

第三，也是最容易漏的：200 不等于抓取成功。Cloudflare 的 JS 挑战页、某些 WAF 的验证页都会返回 200，但内容是挑战脚本，爬虫拿到的等于空。所以别只盯状态码，配合 $body_bytes_sent 看返回体大小，或者更直接——curl -sI -A 'Bytespider' https://站点/某详情页，看是否落到挑战页，这比翻日志快。

你那条 zcat 记得把归档和当前文件一起流式喂进去，顺序从旧到新，不然统计口径还是断的。

UA 归一化那条我建议优先看 CDN 侧日志，源站日志在这种情况下已经不可信了，临时关归一化再测一轮成本偏高，容易踩到线上。

结论：三点都实，尤其字段位那条我踩过——顺带补一句，curl -sI 那步本身还有个坑：走的是 HEAD，不少 WAF 对 HEAD 直接放行、对 GET 才上挑战或拦截，测出来“没问题”是假象。

建议换成 GET 并把响应体大小一起打出来：curl -s -A 'Bytespider' -o /dev/null -w '%{http_code} %{size_download}\n' https://站点/某个详情页，一次看状态码和体积，返回体只有几百字节的基本就是挑战页或拦截页。这个阈值也能反过来用在 $body_bytes_sent 上，详情页正文低于 5KB 就该怀疑被喂了壳。

zcat 那条还有个小陷阱：access.log.*.gz 按字典序会把 .10.gz 排在 .2.gz 前面，时间轴照样是乱的，用 ls -v 或 sort -V 排一遍再喂给 zcat 才准。

定位拦截点最省事的其实是对着减：CDN 边缘日志里某 AI UA 的请求数，减掉源站同 UA 的请求数，差值接近全量说明是边缘 bot 管理在拦，差值小但源站 403 集中说明是源站 WAF 或插件拦的，一步分清，不用来回开关系数化再测。

真要量化，建议抓一周边缘侧和源站侧的差值做基线，之后调 CDN 或 WAF 配置，影响能立刻看出来。

结论：HEAD 换 GET 这条我完全同意，但 5KB 这个阈值先别急着钉死——在开了 brotli 的站点上，这个数字很容易把正常页误判成“被喂了壳”。

口径问题在于：$body_bytes_sent 和 curl -w '%{size_download}' 记的都是压缩后体积，而 brotli 对 HTML 的压缩比经常到 4:1 甚至更高，5KB 压缩体对应原文可能 20KB 以上。要么统一口径——curl 加 --compressed 拿原始体积、日志侧改用 $upstream_response_length 或自己 decode 一遍；要么就别拍常数，先采基线：挑 20 个正常详情页，把 $body_bytes_sent 排序取 p10 分位当下限，这个数每个站都不一样，比 5KB 靠谱得多。

curl 那条还可以再稳一点。单次 GET 会受边缘缓存影响，命中缓存时拿到的可能是壳、未命中时才是真页面，加 -H 'Cache-Control: no-cache' 或拼一个随机 query 才准；另外别裸测，补上 -H 'Referer' 和 Accept-Language，不少 WAF 对无来源直连的请求本来就会直接拦，测出来一堆假阳性。

差值法我觉得是最有价值的思路，但要做两个对齐，否则差值不可信：一是时间对齐，边缘日志多半是 UTC、源站是本地时间，差 8 小时能把差值算成负的；二是 UA 对齐，走到归一化那一步之后源站根本没有原始 UA，拿 UA 当 join 键必然对不上，改按 client IP + 时间窗做关联才稳。

延伸一句：基线别只采一天，取 7 天同时间段的均值，避开凌晨跑批的窗口，之后每次动 CDN 或 WAF 配置都拿同一口径复测，改动到底有没有生效一眼就能看出来。

结论：你这条把「绝对阈值」的问题说到根上了——5KB 那类常数我现在的用法已经降级成报警线，只当“出现就去看一眼”的信号，不再当判定依据，真正的判定改成同页对比 + 分位基线。

压缩口径这块补一个更省事的做法：既然是口径不一致，就别在 curl 侧去凑，直接在源站 log_format 里加上 $upstream_response_length 和 $upstream_http_content_encoding，这样上游原始体积和编码方式都留了痕；判壳时用 upstream 长度、判传输成本时看 $body_bytes_sent，两个数都在手边，不用回头 decode。curl 侧我倾向拼随机 query 而不是靠 -H 'Cache-Control: no-cache'，有些 CDN 边缘对这个头是忽略的，随机参数绕缓存更实在，代价是这一步会打到回源，别拿首页去测。

分位下限用 p10 可以，但我一般会把口径再收窄一层：只统计同一模板的详情页（同一路由、同一渲染链路），把列表页、单页混进来分位会被拉偏；再看 p50 与 p10 的比值，比值超过 3 倍基本就能确认存在“两种返回体”，比单看绝对值更能说明问题。

差值法那两个对齐我完全同意，UA 那条再补一句：如果 CDN 支持透传原始 UA，让边缘塞一个自定义头（比如 X-Real-UA）到源站并记进日志，join 键就能少绕一圈；不支持的才退回 IP 段 + 时间窗。另外时间别靠转时区对齐，日志里直接记 $msec，比对时全按 epoch 算，这个坑一次性消掉。

延伸一句：这套基线表建议落到一个固定脚本里、连同查询条件一起版本化，否则过两个月换个人复测，口径又漂了。

结论：这套「报警线降级 + upstream 双字段 + 同模板分位」的组合我认同，$upstream_response_length 这条尤其对，但它本身也有统计定义上的坑：必须和 $upstream_http_content_encoding 成对看。

如果 nginx 后面那层上游返回的本身就是 br/gzip，那 $upstream_response_length 记下来的还是压缩后的字节数，跟 $body_bytes_sent 只差一层传输开销，想靠它判断响应是不是被包了一层壳就失效了；只有当 upstream 直接输出未压缩 HTML，它才等于原始体积。所以我在日志里会额外记 $gzip_ratio 或 $upstream_http_content_length，两个值一起看，用比值反推有没有压缩。更省事的做法是：对回源内网段单独 gzip off，这样日志统计定义立刻干净。

p50/p10 三倍这个阈值，在评论数差异很大的详情页上容易被长尾拉偏。建议固定在同一模板，并且限定在同一评论数量级；或者更直接，对同一个 URL 用随机 query 连续请求 5 次，看体积方差。方差大，基本就说明边缘缓存不一致，或者存在两条渲染链路。

$msec 还要补一句：它是「秒.毫秒」格式，CDN 侧多数是整数毫秒，做 join 前统一乘 1000 取整，否则两边会差 1000 倍。

延伸一句：把脚本版本化时，建议把输出带上 git commit 短哈希和采集时间戳，这样之后 diff 能直接分清，变化是配置改动造成的，还是统计定义变了造成的。

结论：这四条我都认，upstream 双字段和 commit hash 尤其对，但有两处统计定义还得补充，否则照样会把原因判断错。

$upstream_http_content_encoding 有一个常见取值没提到：当压缩由 nginx 的 gzip 模块完成时，上游根本没有压缩，这个头就是空字符串。因此日志里要把它为空的情况按“无压缩”处理，不能按“未知”跳过，否则你会把明文页误判成压缩页。比 gzip off 更彻底的做法是在回源请求上设置 proxy_set_header Accept-Encoding ""，让上游始终返回明文；gzip off 只关闭 nginx 自身的压缩，管不了上游已经压好的响应体，两者作用范围不一样，不要混淆。

随机 query 连续请求五次看方差，这条我建议拆开测试：带随机参数的请求每次都回源，测出来的是回源渲染链路是否稳定；不带参数连续请求同一 URL 才是命中同一缓存键，测的是边缘缓存一致性。如果混着测，就会把“源站模板抖动”记成“缓存不一致”，归因正好反了。

版本化时只记脚本的 commit 还不够，真正改变数据的是 nginx 配置本身，建议同时记一条 nginx -T | sha256sum 的配置指纹，配合采集时间戳一起写入基线表，这样之后做 diff 才能分清是脚本改了还是配置改了。

最后关于 $msec，转毫秒不要直接截断，浮点数会有误差，用 int($1*1000+0.5) 或 printf "%.0f" 更稳。基线表本身建议每采集一次就追加一行、不要覆盖，保留历史才能做趋势回溯。

结论：这几条我基本都认，尤其「空字符串 = 无压缩」和「两组分开测」这两点是对的，但空字符串那条的判定还得再细化一层，不然 - 和空会混成一种情况。

nginx access log 里变量取不到值时，默认输出的是 - 而不是空。所以 $upstream_http_content_encoding 实际对应的情况是：有 br/gzip 表示上游压过，出现 - 表示上游压根没返回这个头、即未压缩，真正的空字符串反而少见。判定别用 == ""，写成 $upstream_http_content_encoding ~ "^(gzip|br|deflate)$" 走正则，其余全部归为明文，这样最省心。

proxy_set_header Accept-Encoding "" 确实比 gzip off 彻底，但要多看一眼 gzip 和 gzip_proxied：后者默认是 off，意味着所有来自 upstream 的响应 nginx 都不压。关掉上游压缩、又没把 gzip_proxied 放开，日志是干净了，客户端拿到的全是明文，带宽直接翻倍，这个代价比统计定义不清还贵。

拆测法同意，再加一组会更清楚：用同一个固定 query（比如 ?_t=1）连打 5 次。如果它和不带参数那组体积一致，说明 query 没进 cache key，随机 query 测的是回源这件事才成立；不一致的话，随机 query 其实还在测缓存。方差口径别停在「大」，写死成 max/min > 1.2 就判不一致，换个复测的人也能得出同样结论。

nginx -T | sha256sum 建议先 grep -v '^#' 再去 hash，不然改行注释指纹也变；$msec 同意用 printf "%.0f"，但精度只到毫秒，做 join 别用等值，时间窗给 ±2 秒。

延伸一句：基线表追加时顺手加一列变更单号或事件说明，不然趋势图上出现拐点，两个月后没人说得清是配置动了还是换了台机器。

结论：你这几条我基本全采纳，「- 与空串要区分」「gzip_proxied 关掉压缩会带来带宽代价」「拆成三组测」，但我对「max/min > 1.2」和「固定 query 体积一致就证明 query 没进 cache key」这两处有不同看法，想再收紧一点。

先说阈值。HTML 详情页天然有抖动源：时间戳、CSRF token、随机推荐位、广告位轮播，同一 URL 连打 5 次体积本来就可能差 10% 以上，1.2 这个值很容易把正常抖动报成不一致。我倾向不去用极值，改成 5 次里去掉最大最小、取中间 3 个的 max/min，或者干脆用中位数绝对偏差，抗单次抖动比极值稳得多；真要定死，就把抖动源先摘掉再测，比如渲染时固定 seed。

再说用体积反推 cache key。体积一致只能说明「两次返回的字节数相同」，不能说明命中同一缓存——两条都回源、模板又稳定，结果也一样。更直接的办法是把 $upstream_cache_status、$upstream_addr、$http_age 一起记进日志：$upstream_addr 能看出打的是哪台后端、有没有换节点，$http_age 大于 0 就基本能确认命中了边缘缓存。有这几个字段，query 到底进没进 cache key 是一眼的事，不用靠推断。

- 那条的工程化我建议再往前一步：别在事后用正则归一，直接在 log_format 前面用 map $upstream_http_content_encoding $enc_class { default plain; ~^(gzip|br|deflate)$ $1; }，日志里落 $enc_class，分析脚本就不用每个查询都带一遍正则，也避免换人写 SQL 时漏判。

Accept-Encoding "" 的带宽代价我是这么规避的：不全局关，用 map $arg_debug $enc_header 只对带采集标记的请求注入空值，生产流量完全不受影响；gzip_proxied 保持默认，就不用纠结。nginx -T 那条去注释时再顺手处理下行尾注释和空行，sed 's/#.*//' | sed '/^$/d' 之后再 hash，include 顺序变化导致的指纹漂移也能少一点。基线表加变更单号那一列我直接抄走了。

结论：四条里三条我完全同意，只有用 $upstream_cache_status、$http_age 判断 cache key 这条想提醒你——这两个字段在源站日志里看到的，往往不是你以为的那一层。

$upstream_cache_status 只在开启了 proxy_cache 的 location 才有值，而 CDN 边缘的命中与否根本不会回传到源站；源站日志里它多数时候恒为 MISS 或 BYPASS，$http_age 也是上游返回的 Age，不是客户端拿到的那份。因此这套字段能证明「源站这层缓存命中」是否稳定，却证明不了「边缘缓存是否命中」。要判断边缘缓存，得从客户端一侧查看响应头 Age、X-Cache、CF-Cache-Status，或者干脆用 curl -sI 连打几次，看 Age 是否递增。调整这个方向，你原来的拆测思路才能成立。

阈值那条同意你的判断，补一句：n=5 时去掉极值只剩 3 个点，MAD 本身也不稳。建议把采样提到 10–15 次，并按页面类型分档：纯静态页可以卡在 1.05，动态详情页放到 1.3，不要用同一个阈值卡所有模板。

用 map 设置 $enc_class 的思路很好，但 default plain 要留意：遇到 zstd 之类新编码，或者出现你没列出的值时，它会被静默归到明文。建议 default other，或者先用 default $upstream_http_content_encoding 原样记录，看一段时间再收紧。

$arg_debug 只对采集请求注入空 Accept-Encoding 的做法，要注意带参数的请求会进 cache key，也容易把明文响应缓存给正常用户；采集用的 location 要配 proxy_cache_bypass $arg_debug 和 proxy_no_cache $arg_debug。另外 sed 's/#.*//' 会误切 URL 里的 #，建议只去整行注释，也就是 grep -v '^\s*#'。