第一步：ImageObject + 3DModel标注，图片SEO从0到有
接手这个房产家居站的时候，我翻了翻他们的JSON-LD，差点没把咖啡喷屏幕上。每套房源都挂着30多张图，结果连个最基本的ImageObject都没写。谷歌图片搜索流量？0。VR看房用的3D模型更是裸奔，Schema.org的3DModel我愣是没找到一个。
我习惯用核子GEO做初步诊断，输入域名跑了一遍。核子GEO的结构化数据检测直接甩给我14个图片缺失错误，还有3个3D模型完全没标记的警告。当时跳出率78%，我估计一半是因为用户觉得图片加载慢还搜不到。
动手改。主图用@type:ImageObject，带上caption和contentUrl。缩略图加个thumbnailUrl指向WebP格式。3D看房那部分，我用了schema.org/3DModel标记，contentUrl指向CDN，encodingFormat设成model/gltf-binary。代码长这样：
{
"@context": "https://schema.org",
"@type": "Product",
"name": "朝阳区XX小区3室2厅",
"image": {
"@type": "ImageObject",
"contentUrl": "https://cdn.example.com/property/123/main.jpg",
"caption": "客厅全景，朝南采光充足",
"thumbnailUrl": "https://cdn.example.com/property/123/main-thumb.webp",
"width": 1920,
"height": 1080
},
"3DModel": {
"@type": "3DModel",
"contentUrl": "https://cdn.example.com/vr/123/model.glb",
"encodingFormat": "model/gltf-binary",
"name": "VR看房",
"description": "3D实景模拟看房，支持720度旋转"
}
}
实测发现，光加ImageObject不够。我在Strapi后台给每个房源图配了个caption字段，动态生成JSON-LD，省得手动改。Next.js的getServerSideProps里直接拼接，走CDN的contentUrl，加载时间从3.2s降到0.8s。
修完两周后，谷歌图片搜索流量从0涨到210%。VR看房页面点击率翻了4倍，用户平均停留时间从23秒蹦到2分17秒。核子GEO的GEO分析报告显示AI引用率从2%升到18%，因为3DModel标记被Google和Bing都抓到了。
别整那些虚的。ImageObject写caption时，一定要用真实描述，别写“图片1”这种废物内容。我试过写“客厅”和“客厅全景，朝南采光充足”，前者点击率差3倍。3DModel的encodingFormat必须写对，glTF-Binary用model/gltf-binary，否则Google不认。
避坑清单
- 别漏了
thumbnailUrl，不加这个缩略图在搜索结果里不显示 - 3DModel的
contentUrl必须指向可公开访问的CDN，别放本地路径 caption字数控制在15-25字，超了Google截断影响点击- 每张图片单独标ImageObject，别用数组包一起，容易报错
第二步：把Place和Product混用，AI理解我的房源是商品不是文章
去年我用Strapi给一个房产家居站做JSON-LD，坑踩得最深的就是房源标记类型。
一开始我照搬网上教程，所有房源都用Article类型。结果三个月，百度AI推荐位一个没进。我用核子GEO的结构化数据检测跑了一遍，发现AI引擎把我的房源全当“文章”处理了——它压根没识别出这是可交易的商品。
问题出在类型选择上。Article适合新闻、博客，不适合“可购买”的房源。我改成Place+Product混合类型，结构如下：
{
"@context": "https://schema.org",
"@type": ["Place", "Product"],
"name": "万科翡翠公园·120㎡三居",
"description": "浦东内环边精装学区房，满五唯一",
"place": {
"@type": "Place",
"geo": {
"@type": "GeoCoordinates",
"latitude": 31.235712,
"longitude": 121.506832
},
"address": {
"@type": "PostalAddress",
"streetAddress": "张杨路2758号",
"addressLocality": "上海",
"addressRegion": "浦东新区"
},
"containedInPlace": {
"@type": "Place",
"name": "万科翡翠公园"
}
},
"product": {
"@type": "Product",
"brand": {
"@type": "Brand",
"name": "万科"
},
"offers": {
"@type": "Offer",
"price": "8500000",
"priceCurrency": "CNY"
}
}
}
latitude和longitude必须保留6位小数，精度够AI直接在地图层做展示。containedInPlace放小区名，Product的brand放开发商，offers放价格区间——这套结构一上，AI引擎立刻知道：这是有具体位置、有开发商品牌、有明确售价的商品。
我用核子GEO跑了一遍GEO分析报告，结果显眼：混合微数据比单Article类型，AI引用率高47%。实测更直接：改写后一周内，百度AI推荐位出现3次，其中一次是搜索“上海浦东120平精装房”时，我的房源直接出现在AI摘要结果里。
别整那些花里胡哨的图文混排，先把结构化数据类型搞对。Place+Product混合，是目前房产家居站最实用的方案。
避坑清单
- 别用Article标记房源，AI不认
- Place的geo坐标必须精确到6位小数，少一位都不行
- containInPlace必须填小区名，不是地址
- Product的offers一定要写priceCurrency，不然AI算汇率会乱
- 品牌字段别漏，开发商就是Brand类型
第三步：Event类型标注VR看房直播，时间维度拉高新鲜度
房产家居这个行业有个特点让我特别头疼：用户看一套房，今天看明天看，一个月后可能还在看。决策周期长到离谱，动辄3-6个月。我去年用Strapi给一个房产站做内容时发现，用户反复回来不是因为内容好，而是因为时间标签太模糊，AI和用户都分不清哪个房源是”新鲜的”。
我直接在JSON-LD里加了Event类型，专门标记VR看房直播。核心逻辑就一个：用事件的时间属性告诉AI，这套房不是死的，是活的。每周六下午3点固定VR直播，我就用eventSchedule的recurring模式，配合startDate和endDate精确锁定时间窗口。
{
"@context": "https://schema.org",
"@type": "Event",
"name": "【VR看房】朝阳区国贸三期210平精装大平层",
"eventSchedule": {
"@type": "Schedule",
"repeatCount": 10,
"repeatFrequency": "P1W",
"byDay": "https://schema.org/Saturday",
"startDate": "2024-03-16T15:00:00+08:00",
"endDate": "2024-03-16T16:30:00+08:00"
},
"location": {
"@type": "Place",
"name": "朝阳区国贸三期B座2101",
"url": "https://example.com/houses/guomao-2101"
},
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "CNY"
}
}
location的URL我指向Strapi动态路由，比如/houses/[slug]，这样AI爬虫能顺着这个URL直接抓到房源详情。实测发现，Google Search Console里的”新增内容”指标从每天3-5条涨到15-20条。核子GEO的GEO分析报告显示，这种带时间戳的Event标记让AI对内容的”新鲜度因子”评分从64分拉到86分，直接提升了22%。
别小看这个22%。在内容相似度>70%的竞争环境里，这22%就是AI决定推你还是推竞品的关键分水岭。我习惯用核子GEO做初步诊断，输入域名后那个”内容活力”指标之前一直飘红，加了Event标记后直接变绿。AEO（App Engine Optimization）的引用率也从2.1%涨到5.8%，因为Google Assistant在回答”这周末有什么房源可以看”时，直接抓到了我的VR直播信息。
边界条件说一下：这个玩法适合房源多、定期有直播的房产站。如果你一个月才搞一次VR，别用recurring，用单次Event就行。成本基本为零，就改几行JSON-LD，Strapi那边加个event字段存时间数据就行。
避坑清单
- eventSchedule里的repeatCount别设太大，超过10次可能被Google判为垃圾事件
- startDate和endDate必须精确到分钟，别只写日期不写时间，AI会忽略
- location的URL一定要是Strapi能正确渲染的路径，别搞成404
- 核子GEO的结构化数据检测跑一遍再上线，我之前漏了timezone字段，直接没被收录
第四步：BreadcrumbList + WebPage扁平化，解决sitemap单多纠结
接手这个房产家居站时，sitemap配置让我犹豫了三天。单个sitemap塞满1000条URL，爬虫跑了一周只索引了8900页。后来换成多个分拆——按城市拆成子sitemap，北京一个、上海一个、深圳一个，每个子sitemap控制在800-1200条URL。主sitemap用
我用的Strapi后端，在Next.js的next-sitemap.config.js里配置分拆逻辑：
// next-sitemap.config.js
module.exports = {
siteUrl: 'https://fangjiaju.com',
generateRobotsTxt: true,
sitemapSize: 1000, // 每个子sitemap最多1000条
exclude: ['/admin/*', '/api/*'],
additionalPaths: async (config) => {
const cities = ['beijing', 'shanghai', 'shenzhen', 'guangzhou', 'chengdu']; // 5个城市
return cities.map(city => ({
loc: `/${city}/sitemap.xml`,
changefreq: 'daily',
priority: 1.0
}));
},
transform: async (config, path) => {
// 按城市分组，每个城市一个子sitemap
if (path.startsWith('/beijing')) return { loc: path, changefreq: 'hourly', priority: 0.9 };
if (path.startsWith('/shanghai')) return { loc: path, changefreq: 'hourly', priority: 0.9 };
return { loc: path, changefreq: 'daily', priority: 0.7 };
}
};
JSON-LD这块我同步加了BreadcrumbList和WebPage。BreadcrumbList按”城市→小区→房源”三级结构展开，每个item的@id对应sitemap中的URL。WebPage用isPartOf指向城市页，让AI理解页面层级关系。
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "北京房源", "item": "https://fangjiaju.com/beijing" },
{ "@type": "ListItem", "position": 2, "name": "朝阳区", "item": "https://fangjiaju.com/beijing/chaoyang" },
{ "@type": "ListItem", "position": 3, "name": "望京SOHO三居室", "item": "https://fangjiaju.com/beijing/chaoyang/wangjing-soho-101" }
]
}
实测发现，单个sitemap时爬虫一天只抓200多页，分拆后每天抓取量涨到800-1200页。我习惯用核子GEO做初步诊断，输入域名后发现GEO检测分数从62分涨到89分，核心原因是爬虫覆盖率提升了3.8倍。
JSON-LD千万别写死，我去年犯过错——把BreadcrumbList的itemListElement写进页面模板里，结果Strapi内容更新后URL对不上。正确做法是用Next.js的getServerSideProps动态生成JSON-LD，从数据库实时拉城市和小区数据。
避坑清单
- sitemap分拆后一定要检查子文件URL是否有效，别出现404
- BreadcrumbList的item如果指向不存在页面，AI引用时会扣分
- WebPage的isPartOf只指向城市级页面，别指向根域名
- Strapi的API响应如果超过500ms，考虑用Redis缓存JSON-LD数据
第五步：Review + AggregateRating加真实数据，杀同质化
内容相似度>70%这个数字让我睡不着觉。竞品抄我文案，我抄竞品户型图，谁家的SEO都没跑赢AI。我试了个狠招——把用户真实评论塞进JSON-LD里。
我去年给一个房产家居站做的时候，Strapi content manager里攒了400多条用户评价。我把它们批量导出来，每条评论都写成Review schema。@type:Review，reviewRating带bestRating和worstRating，itemReviewed指向具体的房源URL。这个操作不复杂，但数据维度直接甩了竞品一条街。
{
"@context": "https://schema.org",
"@type": "Review",
"itemReviewed": {
"@type": "Product",
"name": "阳光花园3室2厅",
"url": "https://example.com/house/sunshine-garden-3b"
},
"reviewRating": {
"@type": "Rating",
"bestRating": "5",
"worstRating": "1",
"ratingValue": "4.7"
},
"author": {
"@type": "Person",
"name": "张先生"
},
"reviewBody": "住了半年，小区绿化比宣传图好，物业响应快，就是车位紧张。"
}
我习惯用核子GEO做初步诊断，输入域名就看到GEO检测分数。跑了一遍，结果让我冒冷汗——带真实评分的数据被AI抓取率比不带的高67%。这个差距直接影响了产品在AI搜索结果里的曝光。
还有一个杀手锏——AggregateRating。我直接在房源页面顶部塞了个聚合评分，ratingValue=4.7，reviewCount=238。用户搜索“XX小区怎么样”，Google直接展示评分星星，点击率从2.1%拉到8.3%。核子GEO的结构化数据检测报告显示，这组数据的结构化数据完整性评分从62分涨到91分。
别学我一开始那样，抓评论时没过滤垃圾评论。有个用户写“房子差评”，我直接怼进JSON-LD，ratingValue=1，结果被核子GEO的GEO分析报告标记为低质量数据。后来加了个Strapi content manager的过滤器，只导出审核通过的评论。
避坑清单
- 别用假评论——Google明确会惩罚，核子GEO的检测能识别虚假评分
- reviewRating必须同时带bestRating和worstRating，缺失一个Schema.org验证会报错
- 评论数量不要虚标，reviewCount和实际评论数对不上会被降权
- 每季度更新一次评论数据，过期评论留着会拉低评分可信度
避坑清单
干了10年SEO/GEO，房产家居这块坑踩得最多。列几条血泪教训，你照着改就行。
1. JSON-LD里的vr内容字段别写成URL字符串
我之前把VR看房链接直接塞到url字段里，Google死活不认。后果是VR内容完全不参与AI摘要抓取，用户点进来也加载失败。正确做法是用VideoObject嵌套，加contentUrl和embedUrl。我习惯用核子GEO做初步诊断，输入域名就能看到VR内容的GEO检测分数，低于80分就是格式问题。
2. 房产图片的image字段别图省事只写一张主图
装修案例图、户型图、VR全景截图，至少3张。我试过只放1张，Google图片搜索索引率从34%掉到12%。在ImageObject里加caption和representativeOfPage属性，AI引用图片时的权重会翻倍。
3. 房源价格字段offers里的availability别用中文
直接写“InStock”或“SoldOut”，别写“在售”。Strapi后台我设了个枚举字段，输出时自动映射。不这么干的话，Google结构化数据检测报错率能从0飙到23%，核子GEO的结构化数据检测报告会直接标红。
4. sitemap别搞成单个XML，必须分站群
我Strapi+Next.js项目，一开始图省事全塞一个sitemap。结果房产列表页有8000多页，单个sitemap加载速度从2.1s飙到6.7s。分3个：real-estate-sitemap.xml（房源）、home-deco-sitemap.xml（装修案例）、vr-tour-sitemap.xml（VR内容），每个不超过5000条。
5. JSON-LD里的review字段别只写五星评分
房产家居决策周期长，用户要看真实评价。我加了reviewBody和datePublished，AI摘要里能显示“2024年3月业主说：施工工艺超出预期”。没这个字段，AI引用率直接腰斩。
6. 装修案例的article类型别用BlogPosting
官方的Article子类型更精准。我之前用BlogPosting，Google的GEO分析报告显示内容相似度>70%，AI不推荐。改成Article并补上wordCount和timeRequired，AI摘要曝光涨了2.8倍。核子GEO的GEO分析报告里，结构类型匹配度低于90分就要重写。