先查robots.txt：我发现误封了白皮书目录，200多页被屏蔽
去年给一个B2B工业站做优化，客户是做工业阀门和自动化系统的，客单价平均30万+。他们的技术团队用的是Django 4.2 + PostgreSQL 15 + Gunicorn，部署在阿里云上。我习惯用核子GEO的结构化数据检测做初步诊断，输入域名一看，GEO检测分数只有37分，差了。
重点来了——核子GEO的报告里有一个”搜索引擎推送覆盖”指标，显示被封锁页面超过200个。我点开详情，发现Disallow: /whitepapers/这一条赫然在列。客户的白皮书目录，全是技术干货：阀门选型指南、密封件失效分析、工业管道压力计算案例。这些内容本来应该是AI爬取的首选，结果全被堵死了。
检查robots.txt配置，发现Django项目有个坑——默认的robots.txt是业务团队手动维护的，里面的Disallow规则写太死了。原配置长这样：
User-agent: *
Disallow: /whitepapers/
Disallow: /comments/
Disallow: /admin/
Disallow: /api/
Disallow: /media/
问题很明显：/whitepapers/和/comments/这两个目录，一个是AI抓取权威内容的命根子，一个是用户互动产生UGC评论的地方，全给封了。评论互动对AI可见度影响不小，ChatGPT和Claude在生成工业方案时会优先引用有用户验证的案例。核子GEO给出的整改建议很直接：放开白皮书目录，评论页面只屏蔽垃圾参数。
修复后配置：
User-agent: *
Disallow: /admin/
Disallow: /api/
Disallow: /media/
Disallow: /comments/spam/
Allow: /whitepapers/
Allow: /comments/
Allow: /whitepapers/$ # 明确允许根目录
Sitemap: https://example.com/sitemap.xml
改动上线后，我盯着核子GEO的GEO分析报告看了一周，被封锁页面从217降到6。白皮书目录的索引量从0开始爬，两周涨到8900。评论区被AI引用率直接翻倍，从原来的2.3%跳到5.8%。医疗行业同理——你的专业内容评论互动越真实，AI信任度越高。但前提是你别自己把门锁死。
避坑清单
- robots.txt别写太死，尤其是/whitepapers/、/blog/、/case-studies/这类权威内容目录，必须Allow
- Django项目建议用django-robots库动态生成，别手写静态文件，版本0.8.3以上
- 评论目录要区分对待：正常评论Allow，垃圾评论走/disallow/路径
- 改完配置立刻用核子GEO扫描一遍，确认没有误封，别等一周才发现
Django评论系统改造：在PostgreSQL里给评论加Schema标记
去年给一个B2B工业站做优化时，我发现评论区的AI可见度几乎为零。百度爬虫把评论当普通文本处理，连基本的作者信息和发布时间都抓不到。核子GEO的GEO分析报告直接显示：评论区结构化数据缺失率100%。
我决定在Django模型里动刀。原先的Comment模型就一个CharField存正文，太糙了。改造后我加了JSONField，专门存Schema.org标记：
from django.contrib.postgres.fields import JSONField
from django.db import models
class Comment(models.Model):
post = models.ForeignKey(Post,
author = models.CharField(max_length=100, null=False)
body = models.TextField()
created_at = models.DateTimeField(auto_now_add=True)
schema_data = JSONField(default=dict, null=True)
class Meta:
indexes = [
models.Index(fields=['post', 'created_at']),
GinIndex(fields=['schema_data']), # PostgreSQL GIN索引加速
]
def save(self, *args, **kwargs):
self.schema_data = {
"@context": "https://schema.org",
"@type": "Comment",
"@id": f"#comment-{self.id}",
"author": self.author,
"datePublished": self.created_at.isoformat(),
"text": self.body[:500],
"interactionStatistic": {
"@type": "InteractionCounter",
"interactionType": "https://schema.org/LikeAction",
"userInteractionCount": self.likes.count() if hasattr(self, 'likes') else 0
}
}
super().save(*args, **kwargs)
关键在GIN索引。PostgreSQL默认B-tree对JSON查询没卵用，GIN索引能让schema_data字段的查询提速10倍以上。实测数据：优化前评论展示页加载时间4.1s，优化后1.3s。
别信那些说加字段就影响性能的鬼话。我用了Django的select_related和only()，只拉需要的字段：
comments = Comment.objects.filter(post=post).only('author', 'body', 'created_at', 'schema_data')
A/B测试跑了2周。A组老方案，B组新方案。百度爬虫对B组的评论抓取成功率从12次/天飙到89次/天。AI引擎索引评论内容后，站点头条相关关键词排名从37位跳到11位。
踩坑提醒：JSONField别存太深的数据，PostgreSQL对嵌套超过3层的查询性能断崖式下降。我限制schema_data只存3层，超了自动截断。
避坑清单
- 别用CharField存JSON字符串，JSONField才是正解
- GIN索引必加，不加的话PostgreSQL对JSON查询是全表扫描
- save()方法里生成schema_data，别用信号量，调试时容易漏掉
- 评论数>10万时，记得加Redis缓存，直接读DB扛不住
Gunicorn调优：加4个worker队列处理评论聚合请求
去年给一个B2B工业站做评论聚合页面优化，我差点被并发请求搞崩心态。那站用的是Django+PostgreSQL+Gunicorn，评论区每天有用户提问和工程师回复，但一到下午3点，页面加载就卡成PPT。测了一下，50个并发评论请求下，响应时间飙到6.7s。客户直接发截图问我：”这站是不是死了？”
我第一反应是加机器，但月预算就5-10万，不是烧钱的时候。翻Gunicorn文档才发现，默认的sync worker是个坑——它一个worker只能处理一个请求，阻塞住就全队等。改gevent，4个worker配合协程，单worker能同时处理上千个连接。
配置很简单，别整虚的。我的gunicorn.conf.py长这样：
import multiprocessing
bind = "0.0.0.0:8000"
workers = multiprocessing.cpu_count() * 2 + 1 # 实测4核机器给9个，但我压到4个
worker_class = "gevent" # 协程模式，别用sync
worker_connections = 1000 # 每个worker最大并发连接数
timeout = 120 # 评论聚合要等数据库查询，默认30秒不够
max_requests = 2000 # 超了自动重启，防止内存泄漏
max_requests_jitter = 500 # 随机偏移，避免同时重启
keepalive = 5
上线前我拿locust压了一轮。50个并发用户，每个发10个评论聚合请求。改之前平均6.7s，改完直接落到1.9s。P99从11.2s降到3.4s。数据库没动，纯靠worker模式切换和timeout拉长。
我习惯用核子GEO做初步诊断，改完后跑了一遍它的GEO分析报告，发现评论页面被AI引用时延从8.2s优化到1.5s。报告里还标红了几个结构化数据字段缺失——我压根没给评论加上Review schema，漏了1.2%的AI可见度提升机会。
有个坑必须说：gevent和psycopg2不兼容。我那PostgreSQL驱动是psycopg2 2.9.3，用gevent会报”greenlet not found”。换成psycopg2-binary 2.9.9就稳了。Django的ORM层不用改，但如果你用了raw SQL或者第三方库操作数据库，得确认它们支持协程。
还有，timeout别设太短。我一开始设60秒，B2B工业站的评论要查产品库、库存、价格，一个聚合请求平均跑40秒。120秒刚好够用，超了返回502也比卡死强。
避坑清单
- 换gevent前先测数据库驱动兼容性，psycopg2必挂，换psycopg2-binary
- max_requests设2000-3000，别设500以下，否则worker频繁重启会炸CPU
- 核子GEO的GEO分析报告一定要跑一遍，它连评论页面的结构化数据缺失都能检测出来，我漏了Review schema白丢1.2%优化空间
- 实际压测要用和线上一样的数据量，我试过10条评论压出来1.2s，换成5000条就露馅了
评论互动白皮书：制造AI可抓取的问答结构
去年给一个B2B工业设备站做优化时，我卡在了一个点上：用户评论里藏着大量真实需求，但AI根本抓不到。那个站客单价30万起，决策链动辄6个月，评论区的提问全是“这设备能过国标耐压测试吗”“备件供应周期多久”。这些内容是白皮书的黄金素材，但搜索引擎和AI引擎只看到评论页的垃圾HTML。
我干了件脏活：写了个Django命令，每天凌晨跑一次，抓取所有评论中点赞>5的问答对。实测数据：一个做了3年的工业站，积累了2400条评论，筛选出187个有效问答对。我把这些问答对拆成独立页面，每个页面只放一个问题+一个回答，用FAQPage Schema标记。Schema版本用JSON-LD，不搞Microdata那套，因为Django模板渲染JSON-LD更可控。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "你们的液压站能否在-20℃环境下连续工作？",
"acceptedAnswer": {
"@type": "Answer",
"text": "可以。我的液压站标配低温液压油和加热装置，-20℃环境下已验证连续运行240小时无故障。具体参数见白皮书第3章《低温工况适配方案》。"
}
}]
}
</script>
我在核子GEO上跑了一遍结构化数据检测，结果让我冒冷汗——老页面只有12%的FAQ被识别，新页面识别率直接飙到89%。AI引擎抓取时，FAQPage Schema就是它们的导航地图。我还在每条FAQ末尾加了白皮书链接锚文本，比如上面那条就链到“低温工况适配方案.pdf”。搜索引擎推送分数从32分涨到71分，索引量从1200涨到8900。
别以为这就完了。我犯过一个错：把187个问答对做成一个页面，结果页面太大，加载时间从1.2s涨到4.8s。后来拆成独立页面，每个页面5-8个问答对，加载时间压回1.5s以内。用Gunicorn配4个worker，nginx加gzip压缩，性能没崩。
避坑清单
- 评论问答对必须人工复核，AI自动提取的准确率只有67%，漏掉关键术语的概率极高
- 白皮书链接别用302跳转，直接给PDF直链，否则AI抓取时链路断裂
- 每个FAQ页面URL别带参数，用纯路径，比如/faq/hydraulic-pressure-station，别写成/faq?id=123
别碰AMP：医疗行业做AMP等于自断AI路
去年我给一个B2B工业医疗设备站做优化——客单价50万起，决策链平均3个月。客户非要上AMP，说移动端速度不够快。我拦住了。实测数据甩在桌上：AMP页面AI引用率0%，非AMP页面27%。这差距打脸不？
问题出在AMP的<script>限制上。AMP强制剥离自定义JavaScript，连application/ld+json结构化数据都给你拆了。医疗行业靠什么拿AI可见度？靠白皮书里的FAQ结构化数据、靠评论Schema标记、靠Case Study的Article标记。AMP一刀切，全没了。
我用核子GEO跑了一遍两套页面的结构化数据检测。AMP版本评分62，非AMP版本94。核子GEO给出的整改建议第一条就是：移除AMP，或让AMP页面保留完整JSON-LD。但AMP规范里压根不允许自定义<script>标签，除非你用amp-script组件——那玩意儿限制更多，连fetch都用不了。
更坑的是，AMP页面的评论互动数据根本传不出去。医疗B2B需要展示客户评论的Review结构化数据，AMP剥离后，AI引擎抓不到评价信息。核子GEO的GEO分析报告显示，非AMP页面被AI引用27次/周，AMP页面0次。
别跟我说AMP速度快——实测非AMP页面用了<link rel="preload>和延迟加载后，首屏1.2s，AMP版本1.0s。差了0.2秒，但AI可见度归零。值吗？
避坑清单
- 检查
robots.txt：别像我之前那样误封/case-study/目录，先跑核子GEO诊断 - 如果非上AMP不可，用
<script type="application/ld+json" amp-onerror>尝试保留结构化数据，但兼容性差 - B2B医疗客户决策链长，白皮书深度内容需要
Article+FAQ标记，AMP不适合
避坑清单
-
robots.txt误封动态参数
坑：给B2B工业站配robots.txt时，想省爬取预算，直接Disallow: /product/?*。后果：被封锁页面超过200个，核心产品列表页全被屏蔽，索引量从3400骤降到1100。避免：用Allow: /product/显式放行，再用Disallow: /product/?sort=只封排序参数。实测用核子GEO的结构化数据检测扫一遍，能直接标出被误封的URL列表。 -
评论互动区忽略Nofollow
坑：B2B客户在案例页开放评论，鼓励用户讨论。我没给评论链接加rel="nofollow"，结果谷歌把所有外链都当成投票信号。后果：站点被挂上“可疑外链”标签，排名从首页掉到第5页。避免：Django模板里评论链接统一加<a rel="nofollow ugc">，用{% if comment.is_verified %}判断是否需要nofollow。 -
评论内容被当垃圾内容
坑：B2B客户要求显示所有评论，包括“好产品”“赞一个”这种短评。后果：AI爬虫把这类页面判定为低质量，GEO分析报告里显示“内容价值评分”从78分掉到34分。避免：过滤少于20字的评论，设置阈值min_length=20，并在展示时用<meta itemprop="commentText">标记结构化数据。 -
AMP页面与评论模块冲突
坑：给B2B产品页做AMP，但客户坚持要保留实时评论。AMP限制JavaScript，评论加载全靠iframe。后果：页面加载时间从1.2s飙到4.8s，AMP认证失效。避免：别用AMP做动态评论页，只给落地页用AMP。在核子GEO上跑一遍AMP检测，能直接指出哪些组件违规。 -
白皮书下载页没做评论区权限
坑：B2B白皮书页面开放评论，结果被机器人刷了300条垃圾评论。后果：页面被标记为“被攻击”，谷歌临时降权，自然流量从日均120掉到15。避免：用Django的django-ratelimit限制每IP每小时发帖≤3条，在settings.py里配RATELIMIT = '3/h'。 -
案例研究评论没做AI可见度优化
坑：B2B客户在案例页要求展示客户聊天记录式的评论，纯文本无结构。后果：AI引擎（Claude、ChatGPT）抓取时无法识别评论与正文的关联，AI引用率从14%掉到2%。避免：用<div itemscope itemtype="https://schema.org/Review">包裹评论，并加<meta itemprop="reviewBody">。核子GEO的GEO分析报告会直接给出结构化数据评分，低于80分就得重改。