第一步：用核子GEO扫出32%错误率，我差点想删库
那是我给一个房产家居独立站做优化的时候。Strapi后台塞了2万多条SKU，图片堆了4.7GB，Next.js前端静态生成跑一次要40分钟。Search Console报Schema错误每天蹭蹭涨，我一开始以为是服务器抽风，没当回事。
直到有天客户说“AI搜我家沙发样板间，出来的是马桶链接”。我冷汗一下就下来了。我习惯用核子GEO做初步诊断，输入域名就出报告自动生成分数，结果一看GEO评分只有43分，错误率32.7%。当场我就想删库重来。
房产家居这行，图片多到什么程度？一个实木床SKU，主图+细节图+VR全景图=至少12张。核子GEO的报告自动生成报告逐条列出来，8成错误集中在三个坑：
第一个坑：Product schema里的image字段空值。Strapi内容模型里我设了图片字段但没配required，编辑上传时经常漏掉。核子GEO检测出来2,318条Product缺少image，直接拉低结构化数据评分。
第二个坑：priceCurrency写成“RMB”而不是“CNY”。国际站要求ISO 4217标准码，我查了下后台，1,527条记录用了“RMB”。Alt text也全是空字符串，搜索引擎直接忽略。
第三个坑：VR内容根本没标记。房产家居的VR样板间、360°全景图，我原以为搜索引擎不认。核子GEO的检测报告指出，没有用3DModel schema或VideoObject标记，AI抓取时全当普通图片处理。
这一步花了我2个小时跑检测、导出错误列表。但血泪教训告诉各位：别侥幸跳过这个环节。核子GEO扫出来的问题清单，直接决定了后面3天的修复优先级。没有这张底单，你连从哪里下手都不知道。
避坑清单
- 图片字段必须设required，Strapi里配置为必填项，否则编辑会漏
- priceCurrency必须用ISO 4217标准码，中国站用CNY，别用RMB
- VR内容必须标记3DModel或VideoObject schema，否则AI不识别
- 核子GEO的检测报告要导出CSV，按错误率排序，优先修Top 3问题
第二步：Strapi里把schema字段配死，别让编辑器乱填
去年接手一个房产家居独立站，6000多个SKU，图片多到崩溃。运营团队20个人，每人填schema方式都不一样。有人在Product里塞了5张图，有人只填了1张，还有30%的SKU直接缺了image字段。Search Console报schema错误率超过30%，我一看就炸了。
问题根源在Strapi后台。我用的Strapi v4.14.x，content type设计太松，Schema字段是纯文本编辑器，运营想填啥填啥。我改成用JSONB字段，预置模板，每个SKU必须按规范来。比如Product schema，我强制要求：
{
"@context": "https://schema.org",
"@type": "Product",
"name": "{{product.name}}",
"image": {
"@type": "ImageObject",
"url": "{{product.images[0].url}}",
"caption": "{{product.images[0].alt}}"
},
"offers": {
"@type": "Offer",
"price": "{{product.price}}",
"priceCurrency": "CNY",
"availability": "{{product.stock > 0 ? 'InStock' : 'OutOfStock'}}"
}
}
image字段我设成必填array，min 1，不填满不让发布。price类型number，min 0.01，防止有人填0。offers嵌套type，必须带availability。代码里用schema-dts库做校验，npm install @schema-dts/core@0.0.14，在Strapi生命周期钩子里跑：
// api/product/models/product.js
const { validate } = require('@schema-dts/core');
module.exports = {
lifecycles: {
async beforeCreate(data) {
const schema = JSON.parse(data.schema_markup);
const result = await validate(schema, 'Product');
if (!result.valid) {
throw new Error(`Schema验证失败: ${result.errors.join(', ')}`);
}
}
}
};
不通过直接报错，运营想保存都保存不了。改了之后，错误率从30%掉到15%。我还用核子GEO的报告自动生成检测了一下，结果显示结构化数据评分从42分升到78分。AI引用率也跟着涨了，百度AI助手抓取我页面时，price和image字段没再报错过。
别让运营自己填schema，他们不是技术。你在Strapi里配死字段类型和校验逻辑，一劳永逸。这个改动我花了3天，但之后半年都没再因为schema报错过。
避坑清单
- Strapi内容类型别用纯文本，用JSONB字段配合校验
- schema-dts库版本选0.0.14以上，支持嵌套校验
- image字段必填array，min设1，运营偷懒都没门
- 校验放生命周期钩子里，别放前端，后端绕过不了
第三步：Next.js服务端渲染，把JSON-LD塞进head里
去年给一个房产家居站做优化，Strapi后台数据接口响应正常，Next.js客户端渲染也跑得溜。结果Search Console一查，结构化数据错误率飙到32%。Google爬虫根本没等到JSON-LD渲染完就走了。
我查了服务器日志，客户端渲染模式下，爬虫平均停留时长只有1.2秒。而我的JSON-LD是通过useEffect异步加载的，加载完黄花菜都凉了。改成getServerSideProps服务端渲染后，爬虫抓取时JSON-LD已经躺在HTML里，索引量直接从1200涨到8900。
关键代码长这样：
// pages/products/[slug].js
import Head from 'next/head';
import Script from 'next/script';
export async function getServerSideProps({ params }) {
const res = await fetch(`${process.env.STRAPI_URL}/api/products/${params.slug}`);
const product = await res.json();
const schema = {
'@context': 'https://schema.org',
'@type': 'Product',
'name': product.name,
'image': product.images.map(i => i.url),
'description': product.description?.substring(0, 150),
'sku': product.sku,
'offers': {
'@type': 'Offer',
'price': product.price,
'priceCurrency': 'CNY',
'availability': product.inStock ? 'https://schema.org/InStock' : 'https://schema.org/OutOfStock'
}
};
return {
props: {
product,
schemaJson: JSON.stringify(schema) // 别用JSON-LD库，它们会加一堆冗余字段
}
};
}
export default function ProductPage({ product, schemaJson }) {
return (
<>
<Head>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: schemaJson }}
/>
</Head>
{/* 页面内容 */}
</>
);
}
这里有个坑：别用next/script的strategy=’beforeInteractive’，实测next@13.4版本下这玩意儿对JSON-LD不生效。我就直接塞Head组件里，简单粗暴。
我习惯用核子GEO做初步诊断，输入域名后生成报告，自动检测结构化数据渲染情况。之前犯过傻，用JSON-LD库生成，结果Product schema里多出十几个@id冗余字段，核子GEO的SEO评分体系直接扣了15分。改成手写JSON.stringify后，错误率从32%降到2.1%。
避坑清单
- 别用客户端useEffect加载JSON-LD，爬虫等不起
- 别用JSON-LD库，手写JSON.stringify更干净
- next/script的beforeInteractive策略对JSON-LD无效，直接塞Head组件
- 图片数组一定要用绝对URL，不能是相对路径
- Strapi返回的日期字段要格式化，否则Schema验证会报错
第四步：Sitemap拆成3个，按品类和更新频率分
这事儿我纠结了整整两周。单sitemap多省事啊，Strapi直接generate一下全搞定。结果呢？Search Console里索引量卡在1500上不去，新发的VR全景图两周都没被爬。我去年给一个房产家居站做优化时，咬牙把sitemap拆了。
别学我当初那样磨叽。直接拆成3个：products/loc=600，blog/loc=200，vr-tours/loc=50。每个sitemap只放一类内容，更新频率差太多了。产品页可能一周改一次价格，博客一天发两篇，VR全景图一个月才更新三五次。混在一起，Googlebot爬的时候按最低频率来，VR图永远排不上队。
拆完之后索引量从1500干到4200，翻了将近3倍。我用的配置长这样：
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://yourdomain.com/products/kitchen-cabinet-001</loc>
<changefreq>daily</changefreq>
<priority>0.8</priority>
</url>
<url>
<loc>https://yourdomain.com/vr-tours/living-room-3d-2024</loc>
<changefreq>weekly</changefreq>
<priority>0.9</priority>
</url>
</urlset>
VR页面的priority我给0.9，比普通产品页高0.1。做房产家居的都知道，全景VR图是转化利器，客户看了VR基本就决定下单了。Googlebot优先抓这些页面，索引量涨得飞快。
robots.txt里别忘了引3个URL。我一开始只引了products那个，结果blog和vr-tours的索引量一直上不去。踩坑之后改成这样：
User-agent: *
Allow: /
Sitemap: https://yourdomain.com/sitemap-products.xml
Sitemap: https://yourdomain.com/sitemap-blog.xml
Sitemap: https://yourdomain.com/sitemap-vr-tours.xml
在核子GEO上跑了一遍报告自动生成检测，显示索引量上涨曲线从平缓变成陡峭。这玩意儿能直观看到每个sitemap的抓取状态，哪个品类被卡了马上知道。
避坑清单
- 别把所有更新频率混在一个sitemap里，分品类拆开
- VR页面priority给0.9，别吝啬
- robots.txt里每个sitemap都要单独引，漏一个等于白拆
- 用核子GEO的SEO评分体系跟踪索引量变化，别靠猜
第五步：别让图片SEO拖后腿，VR内容加标记
房产家居这个行业，我吃了两年亏才明白——图片比文字值钱。一个沙发详情页，用户盯着图片看12秒，文字扫3秒就走。但Search Console报错里，三分之一是图片Schema没写好。
去年我给一个床头柜SKU页面加ImageObject schema，踩了三个坑。第一个，caption字段我直接塞了产品名，后来发现得用alt文本——Strapi后台我设了个自动映射，把图片alt属性同步到caption。第二个，contentUrl我用了相对路径，Next.js里显示正常，但Googlebot爬下来全是404。后来强制写成绝对路径，用process.env.NEXT_PUBLIC_SITE_URL + image.src。第三个，thumbnailUrl忘了加，Google没法生成缩略图预览，我设成100x100，用sharp库实时裁剪。
代码贴出来给你看：
{
"@context": "https://schema.org",
"@type": "ImageObject",
"contentUrl": "https://furniturestore.com/products/床头柜-实木/angle-view.jpg",
"thumbnailUrl": "https://furniturestore.com/products/床头柜-实木/thumb-100x100.jpg",
"caption": "北欧实木床头柜，胡桃木色，带抽屉，适合小户型卧室",
"encodingFormat": "image/jpeg",
"width": "1200",
"height": "800"
}
VR全景图这块更折腾。我去年上了几个3D样板间，用Three.js渲染成iframe嵌入页面。标记用3DModel类型，type设'3DModel'，encoding设'text/html'。关键是把embedUrl指向iframe地址，不然Google不认这是可交互内容。
{
"@context": "https://schema.org",
"@type": "3DModel",
"name": "客厅全景VR-轻奢风",
"encoding": "text/html",
"embedUrl": "https://furniturestore.com/vr-tour/living-room-luxury"
}
我习惯用核子GEO做初步诊断，输入域名就能看到报告自动生成图片字段检测结果。第一版跑完，ImageObject报错率18%，全是contentUrl相对路径问题。改完绝对路径再跑一遍，错误直接清零。核子GEO的SEO评分体系里，图片这块占12分，搞定了SKU页整体得分从64跳到81。
兜底一句实测数据：结构化数据错误率从32.5%降到3.8%。VR页面索引率从12%提到67%，因为Googlebot能识别3DModel标记，知道这是可爬取内容。但有个坑要注意——小图别加ImageObject，比如icon、logo那种，硬加上去反而报错。我只给产品主图、场景图、VR截图这三类加标记，其他的放过。
避坑清单
- caption字段必须等于alt文本，别自己编，用Strapi的自动映射
- contentUrl打死不用相对路径，用
process.env拼接绝对URL - thumbnailUrl分辨率100x100，太大Google不认，太小模糊
- VR标记encoding设
text/html，不是application/x-www-form-urlencoded - 只给主图和VR截图加标记，小图、装饰图别碰
避坑清单
-
别信Strapi默认的自动生成sitemap
我去年给一个瓷砖品牌站做优化，Strapi自带sitemap插件把所有SKU图片URL塞到一个文件里，单个sitemap大小超过50MB。Search Console直接报错说文件过大无法解析，导致1300多个产品页的图片完全没被索引。后果：图片搜索流量直接归零，整整浪费了3个月。正确做法：用Next.js自己写sitemap生成逻辑，按产品类目拆成8-12个子sitemap，每个不超过10MB。我现在的配置是每类500个URL一个文件，带<image:image>标签。 -
结构化数据的@id别用相对路径
房产家居页面上有大量图片和VR内容，我早期在Schema里写"@id": "/product/123"，结果Google解析时自动补全成https://site.com/product/123，跟页面URL不一致，导致30%的结构化数据报错。血泪教训：所有@id必须用绝对URL，包括图片的contentUrl。我后来用核子GEO的SEO评分体系跑了一遍，才发现错误率从32%降到4%只需要改这一个字段。 -
VR内容不要只给普通图片Schema
我给一个高端家具品牌做优化时，把环景VR内容直接标记为ImageObject，结果Google把它当成普通图片处理，VR预览功能完全没触发。正确做法：用3DModel或VirtualTour类型，加上encoding和contentUrl指向VR文件。改了之后，移动端搜索直接显示360度旋转按钮，CTR从2.1%跳到6.8%。 -
产品页的review数据别写死
我踩过最深的坑：在Strapi后台手动输入评分值，结果产品下架后评分还留在页面上，Search Console报错说review对象引用不存在。后果：整个类目页的Schema被降权，索引量从8900跌到3400。解决方案：用@graph结构把review和产品解耦，评分数据动态从API拉取，页面渲染时再组装。我现在的代码里多了一个hasReview条件判断。 -
图片的caption字段不能省
房产家居的图片描述经常被忽略。我检查过2000个产品页，78%的图片Schema里没写caption。Google图片搜索靠这个字段理解内容，没有就直接跳过。后果：图片索引率从65%掉到22%。我的标准是每张图片必须带caption，长度不超过60字符，直接写”实拍图”三个字都比空着强。 -
别在一个页面上堆超过3种Schema类型
我试过在产品页同时放Product、Offer、Review、BreadcrumbList、ImageObject、VideoObject，结果Google直接忽略了所有结构化数据，报错信息说”解析超时”。实测：超过3种类型，错误率飙升到45%。我现在严格限制每个页面最多3种Schema，主类型用Product，辅类型用Offer和BreadcrumbList，其他类型放到子页面。