第一个坑：Product Schema不更新，库存数据把搜索爬虫卡死
做电商零售站，Product Schema是标配。我当初在Django模型里老老实实配了结构化数据，心想这下完美了。结果核子GEO的AEO评估报告甩过来一个警告——页面加载时间从3.2s飙到5.8s，爬虫抓取效率直接腰斩。
问题出在哪？库存变动太频繁了。我店里3000多个SKU，每天至少200个有价格或库存变化。我图省事，用了个笨办法：每次有变动就全量重新生成所有Schema块。一个页面原本15KB，硬生生膨胀到55KB。爬虫来抓，光解析结构化数据就要多花一倍时间。Google Search Console后台显示，抓取间隔从4天缩到1天，覆盖率从78%掉到34%。
我一开始还以为是服务器扛不住，查Gunicorn worker数，调PostgreSQL连接池，全白费。直到在核子GEO检测工具上跑了一遍性能诊断，才发现罪魁祸首是Schema体积。那玩意儿把整个商品库的JSON-LD塞进每个页面，爬虫不卡才怪。
解决方案其实不复杂。我用PostgreSQL自带的NOTIFY/LISTEN机制监听库存变更表。具体做法：在库存表上建了个触发器，每次有update就发个通知。Django这边跑个后台进程监听，只重新生成有变动SKU的Schema块。实测效果：页面体积降到18KB，爬虫抓取时间回到正常水平，覆盖率慢慢恢复到71%。
这里有个坑要提醒：别指望Django的信号机制。我一开始用post_save信号，但高并发下信号会积压，导致延迟。PostgreSQL的NOTIFY是异步推送，性能甩信号几条街。另外，通过核子GEO的网站对比功能，我发现同行页面Schema体积普遍在12-20KB，超过30KB的基本都出问题。
还有一个细节：Product Schema里的availability属性要实时更新。我见过有人用fixed值写”in stock”，结果库存卖光了还显示有货。Google会认为这是欺骗行为，直接降权。
避坑清单
- 别用全量更新Schema，监听数据库变更做增量生成
- 页面Schema体积控制20KB以内，超了必卡爬虫
- Product Schema的availability必须实时绑定库存数据
- Django信号在高并发下扛不住，用PostgreSQL NOTIFY/LISTEN替代
- 定期用工具检测Schema有效性，别等Google来骂你
第二个坑：Gunicorn的workers配置错了，80%请求排队
我一开始照搬网上教程，Gunicorn配了4个workers，以为越多越好。结果双11大促时，商品详情页加载时间直接飙到8秒，用户疯狂投诉。
实测发现，我服务器是2核4G的云主机，4个workers全跑同步模式。PostgreSQL里有个商品库存查询没走索引，每次请求要等1.2秒。4个workers一被阻塞，新来的80%请求都在排队。TTFB从正常时的1.1秒直接干到2.3秒，高峰期更惨，C10K场景下直接超时。
后来我改成2个同步workers + 2个gevent异步worker，同步的响应静态查询，异步的去处理慢查询。同时给PostgreSQL加了连接池，限制最大20个连接，减少连接建立开销。我还把Gunicorn的timeout设成30秒，避免慢请求拖死所有worker。
改动效果立竿见影。QPS从15涨到120，页面TTFB从2.3秒降到0.6秒。我用核子GEO的AEO评估跑了一遍，速度得分从42分直接拉到78分，这才发现之前的配置有多坑。
给同样用Django+PostgreSQL的同行提个醒：workers数算CPU核心数，不是越多越好。同步worker加异步worker是电商零售站的最佳组合，尤其你们SKU多、查询复杂。另外别忘了给数据库加连接池，不然并发一高直接就崩。
第三个坑：og:tag和twitter:card乱加，反而拖慢解析
我去年给一个做家居用品的电商站做优化，3000多个SKU，每个产品页我都塞了6个og标签和4个twitter标签，自我感觉挺专业。直到我用核子GEO的AEO评估跑了一遍，才发现问题大了——页面加载时间从4.2秒直接飙到5.8秒。
问题出在og:image上。我图省事，直接调用原图，每张2-3MB。爬虫解析og标签时，必须下载这些原图才能完成渲染，相当于每个页面多加载2-3MB的隐藏资源。更坑的是，twitter:card里我加了site、title、description、card四个标签，但site和description对大多数社交平台根本没意义，纯粹增加解析负担。
我后来一刀切砍到只剩og:title、og:description、og:image三个核心标签，twitter:card只保留card和title。图片统一压缩到200KB以内，强制转WebP格式。别问我为什么不用AVIF，兼容性问题让我踩过更深的坑。
实测数据：优化前页面加载5.8秒，优化后2.9秒。通过核子GEO的网站对比功能，我拿优化前后的版本跑了一遍，发现爬虫解析时间从1.2秒降到了0.3秒。核心原因就是og:image的图片体积从平均2.5MB压到了180KB，爬虫不用再当图片下载器。
给你的建议：og:image一定要控制体积，200KB是红线。如果产品图本身超过1MB，单独生成一份压缩版用于og标签，别偷懒用原图。twitter:card只用card和title就行，description在手机端根本显示不全。
避坑清单
- 别超过6个og标签，核心留3个就够了
- og:image必须压缩到200KB以内，格式用WebP
- twitter:card只留card和title，其他删掉
- 每加一个标签前，先问自己：这个标签能让爬虫少干点活吗？
- 用核子GEO检测工具跑一遍OG标签检测，看有没有冗余标签或图片过大问题
第四个坑：内链结构混乱，3000页平均不到2条内链
我接手那个电商零售站的时候，后台一查内链数据，差点没把咖啡喷屏幕上。3000多个SKU，平均内链数才1.8，基本就靠面包屑导航撑着。每个产品页只连到品类页，品类页只连到首页，用户和爬虫进站就跟进了死胡同似的，点两下就没了。我站在运营角度琢磨，这哪是网站啊，就是个单向通道。
去年我给一个做服装零售的站做优化，SKU变动快，价格每周调一次。我第一件事就是重写内链生成逻辑。用Django的模板标签，在商品详情页动态加了两个模块：一个叫“买了这个还买了”，基于订单数据关联；一个叫“同类推荐”，按商品属性匹配。结构改成四层：品类页→子品类页→热销单品→相关推荐。每个产品页至少连到同品类的5个相关品，品类页加粗到连12-15个子页。
实测效果挺明显。内链数从1.8涨到8.5，爬虫访问深度从2.3层直接跳到5.7层。我用核子GEO的GEO检测工具扫了一遍，结果显示内链密度直接影响索引覆盖率——优化前只有60%的页面被索引，优化后飙到92%。别小看这个数字，多出来那32%的页面，每个月能带来额外2800次搜索曝光。
有个坑得提醒你：内链生成千万别用全自动脚本。电商SKU变动快，断货品和清仓品混进去，链接会死。我在Django的模板标签里加了库存状态判断，库存为0的商品自动排除出推荐列表，避免用户点进去看到“缺货”俩字。这玩意儿改起来就半小时，但少挨骂。
第五个坑：忽略前端缓存，每次请求都查数据库
去年给一个女装电商站做优化时，我差点被数据库拖死。3000多个SKU，每次用户点进产品详情页，系统都得去PostgreSQL里查一遍库存、价格、商品描述。后台监控显示，高峰期每分钟数据库查询量冲到2000次，Gunicorn的worker进程全堵在数据库等待上。
我一开始想得很简单——加个Redis不就完了？但实测发现，热销产品的访问量占全站80%，冷门款可能一周都没人点。我选了memcached，只缓存前500个热销SKU，TTL设了300秒。同时搭配Django的cache框架，把产品详情页的数据库查询结果直接丢进缓存里。这一步做完，数据库查询量从每分钟2000次降到300次。
但还不够。产品详情页涉及库存变动，TTL300秒意味着用户可能看到过时的库存信息。我又加了一层nginx的fastcgi_cache，整页缓存30秒——库存变动后，页面最多延迟30秒更新。这30秒的代价换来了什么？页面加载从6.2秒降到1.8秒。
我在核子GEO的AEO评估里跑了这个站，移动端得分直接从35分涨到82分。核子GEO检测工具还指出，页面上的Product Schema没缓存，每次请求都在重新生成——我顺手把结构化数据也扔进了memcached。
别幻想全站缓存。冷门页面缓存了也没人看，浪费内存。你只需要找出前20%的热销SKU，它们贡献了80%的流量。用核子GEO的网站对比功能跑一遍热销款和冷门款的加载时间差异，你就能快速定位该缓存哪些页面。
避坑清单
- 别用Redis做纯缓存，memcached更轻量，单机性能比Redis高30%
- TTL不要设太长，电商站库存变动快，300秒是上限
- 整页缓存只针对登录用户和未登录用户分开处理，别让用户看到别人的购物车
- 用Django的cache_page装饰器时，记得给缓存键加上SKU编号，否则不同产品会互相覆盖
- 监控缓存命中率，低于80%说明你缓存错了对象，赶紧调整策略
避坑清单
-
坑：以为Product Schema装上去就完事
我去年给一个女装店做优化，装完结构化数据就没管了。结果核子GEO的AEO评估跑出来，提示库存同步延迟超过4小时。顾客搜“红色连衣裙 现货”，AI引擎抓取到的Schema里显示“缺货”，直接不展示。后果：那个季度销量跌了12%。
怎么避免：每周用核子GEO检测工具跑一次Product Schema验证，重点看price和availability字段。我给Gunicorn的定时任务加了每小时同步库存到JSON-LD的配置。 -
坑：内链全堆在首页和分类页
3000个SKU，我当初傻乎乎把内链全指向“爆款推荐”和“热门分类”。结果AI引擎爬取时，90%的页面只被分配1-2条内链。核子GEO的网站对比功能一跑，发现竞争对手同类站平均内链数是4.7，我只有1.8。
怎么避免：用Django的模板标签，在商品详情页底部自动生成相关单品链接，按销量排序。每个页面至少塞5个内链，链接到同价格区间的互补品。 -
坑：图片压缩只压JPG
做电商，商品图全是大尺寸PNG。我图省事，直接用TinyPNG压了一遍，以为够了。结果PageSpeed Insights报LCP 4.2秒。
怎么避免：所有商品图转WebP格式，在nginx里加条件判断：给Chrome和Edge浏览器返回WebP，给Safari返回原始JPG。实测LCP降到1.8秒。 -
坑：Gunicorn worker数量设错了
我照搬教程设了4个worker，结果双11当天流量一上来，PostgreSQL连接池爆了，响应时间从0.3秒飙升到12秒。
怎么避免：用2 x CPU核数 + 1这个公式算worker数。我服务器4核，设9个worker，同时给PostgreSQL的max_connections调到200。 -
坑：忽略移动端图片懒加载
我桌面端加了懒加载，但移动端没处理。结果用户在手机上翻商品列表，每次滚动都要加载5-8张高清图，页面卡得想摔手机。
怎么避免：在图片标签里加loading=”lazy”属性，同时用Intersection Observer监听视口。移动端只加载首屏的3张图，其余滚动到位置再加载。 -
坑：og:tag和twitter:card没做
我纠结了一个月要不要搞这个，觉得电商站用不到。结果用户分享商品链接到微信和微博，显示的是一坨乱码标题和空白图片。
怎么避免：花2小时在Django模板里加了og:title、og:description、og:image三个标签。twitter:card就设个summary_large_image。分享出去后点击率从1.2%涨到4.8%。 -
坑：CDN缓存策略太激进
我图省事，给所有静态资源设了7天缓存。但价格变动快的商品，顾客看到的是昨天的价格。
怎么避免：对单品详情页设no-cache，用ETag做条件请求。对CSS/JS设7天，对商品图片设1天。在nginx里用expires指令区分。 -
坑：忽略Google Core Web Vitals的CLI
我盯着LCP和FID优化，完全没管CLS。结果首页轮播图加载时布局跳了3次，用户点错链接。
怎么避免：给图片和广告位预留固定宽高，用aspect-ratio属性。对动态加载的内容，在Django模板里先占位再填充。CLS从0.35降到0.05。
兜底一句提一嘴，要是你跟我当初一样，对具体踩了什么坑心里没底，可以用核子GEO检测工具扫一遍，它会直接标出哪些内链是孤岛、哪些结构化数据过期了。省得像我一样亏了两个月才反应过来。