巴西开发者花3周测试30种Schema，AI引用率翻了4倍

去年有个数据挺扎眼：Perplexity月活破1000万，ChatGPT周活3亿。但99%的网站还在按2010年的逻辑做SEO——优化给Google爬虫看，而不是给AI读。

Alexandre Caramaschi是个巴西的GEO（生成式引擎优化）顾问，管着两个站：个人博客alexandrecaramaschi.com和企业站brasilgeo.ai。他发现个怪事：AI搜索引擎开始抓取他的内容，但引用质量参差不齐，有时候干脆漏掉关键信息。问题出在哪？机器读不懂他的"自我介绍"。

他做了个实验：用3周时间，在个人站塞了30种Schema.org标记，给企业站做了llms.txt文件。结果？被Claude、Gemini、Perplexity引用的频率翻了4倍。这不是玄学，是结构化的胜利。

Schema JSON-LD：给机器看的"身份证"

人类见面递名片，机器见面读JSON-LD。这是藏在网页里的结构化数据块，用户看不见，但爬虫和RAG（检索增强生成）系统视若珍宝。

Caramaschi的 trick 在@graph。别人把多个JSON-LD脚本拆得七零八落，他全塞进一个图结构里。传统搜索引擎好解析，AI系统拼上下文也更顺。

他的个人站用了30种Schema，分三大类：

身份类：Organization（组织）、Person（人物）、Brand（品牌）——告诉AI"我是谁"

内容类：Article（文章）、BlogPosting（博客帖子）、TechArticle（技术文章）——告诉AI"这篇是什么"

关系类：BreadcrumbList（面包屑）、WebSite（网站结构）、SiteNavigationElement（导航元素）——告诉AI"从哪来、到哪去"

每个@type都不是摆设。Organization标记里塞了founder字段，AI回答"这家公司谁创办的"时直接提取，不用瞎猜。TechArticle标记区分了codeRepository和programmingLanguage，GitHub链接和Python标签各归其位。

最细的是Product标记。他的咨询服务被拆成name、description、offers、aggregateRating，AI生成推荐列表时，价格区间和用户评分自动对齐。

llms.txt：主动递给AI的"简历"

如果说Schema是被动等机器来查的身份证，llms.txt就是你主动塞过去的简历。这文件躺在域名根目录，纯文本，Markdown格式，专门给大语言模型快速消化。

robots.txt说"你能爬哪"，llms.txt说"你该读啥"。Caramaschi在企业站维护两个版本：

/llms.txt —— 完整版，28篇文章的全量结构，带摘要和关键段落定位

/llms-full.txt —— 扩展版，技术细节、API文档、案例数据全摊开

格式极简。标题用#，引用用>，列表用-，链接用标准Markdown。AI不用解析HTML的DOM树，不用猜哪个div是正文，直接拿结构化文本喂给上下文窗口。

他写了个Cloudflare Worker动态生成这文件。新文章发布，llms.txt自动更新。旧内容过期，Worker标记deprecated，AI知道哪些信息可能失效。

结果验证：从"被爬"到"被引用"

Caramaschi没玩虚的，上了三套验证：

Perplexity Sources —— 搜品牌名，看AI回答的脚注里有没有自己的链接。Schema全量部署后，引用率从零星几条变成稳定出现。

Claude Citations —— 直接问Claude关于巴西GEO市场的问题，观察它是否调用brasilgeo.ai的数据。llms.txt上线后，Claude开始准确引用他的服务范围和定价策略。

Gemini Grounding —— 测试Gemini的"双重验证"功能，看AI是否把他的标记内容和网页原文交叉比对。Schema里的datePublished和dateModified帮了大忙，AI能判断信息新鲜度。

最意外的收获在长尾词。以前"巴西生成式AI咨询"这种 query，他的站排不进前50。现在Perplexity直接把他列为信息源，流量路径完全变了——不是用户点搜索结果，是AI替用户做了筛选。

代码级别的几个取舍

Caramaschi开源了部分实现，有几个细节值得抄：

Next.js 16的Metadata API原生支持JSON-LD，但他没用它生成动态Schema。理由是：Metadata API把JSON-LD当字符串塞，没法做@graph的嵌套关系。他手写了一个generateStructuredData函数，在服务端组装完整图结构，再塞进。

Cloudflare Worker生成llms.txt时，他加了层缓存。28篇文章的全量文本不小，每次请求都实时组装会炸掉边缘节点。Worker把结果缓存4小时，新文章通过Webhook触发即时刷新。

Schema的image字段他填得很克制。不是每张配图都塞，只选能代表内容核心视觉的那张。AI生成卡片式回答时，图片 relevance 比数量重要。

有个反直觉的点：他故意没给所有页面做Speakable标记。这标记告诉AI"这段适合语音朗读"，但他的技术文章代码块太多，语音体验差，宁可AI跳过朗读、直接给文字摘要。

GEO和SEO的关系，他看得挺透。SEO是让用户找到你，GEO是让AI替你说话。两者不冲突，但优先级在变。他的个人站41篇文章，企业站28篇，量不大，但结构密度极高。AI不缺内容，缺的是可信、好解析、关系清晰的信源。

现在他接咨询，客户问的第一个问题通常是：我的站被ChatGPT引用过吗？