[{"data":1,"prerenderedAt":253},["ShallowReactive",2],{"blog-structured-data-tool-errors":3,"blog-prev-structured-data-tool-errors":91,"blog-next-structured-data-tool-errors":177},{"id":4,"title":5,"author":6,"body":7,"canonical":75,"category":76,"cover":75,"date":77,"description":78,"draft":79,"extension":80,"keywords":75,"meta":81,"navigation":82,"noindex":79,"ogImage":75,"path":83,"seo":84,"seoDescription":75,"seoTitle":75,"stem":85,"tags":86,"updated":75,"__hash__":90},"blog\u002Fblog\u002Fstructured-data-tool-errors.md","结构化数据检测报的错，一半不用改","元析智能",{"type":8,"value":9,"toc":66},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63],[11,12,13],"p",{},"2026 年 1 月我们给一个 SaaS 站跑结构化数据检测，340 条报错，逐条看完真正需要动手的只有 27 条。剩下的是插件自动注入的标记、已经不展示的类型，以及工具之间的口径差异。把 340 条全修一遍，两周就没了。",[15,16,17],"h2",{"id":17},"报错分三类",[11,19,20],{},"第一类是致命错误，必填字段缺失。Article 缺 headline、Product 缺 offers、Breadcrumb 的 item 顺序错了，这类会影响富媒体展示，必须修。",[11,22,23],{},"第二类是警告，建议字段缺失。比如 Article 没写 author、Organization 没写 logo。这类不影响展示，有精力再补。",[11,25,26],{},"第三类跟你的页面没关系。很多 CMS 和营销插件会自动注入 Organization、WebSite 标记，字段填得一塌糊涂，检测工具照样报错。这类要么去插件设置里关掉，要么忽略，别手动改模板。",[15,28,29],{"id":29},"两个工具为什么结论不同",[11,31,32],{},"Rich Results Test 测的是你输入的那个 URL 的当前快照，Schema Markup Validator 测的是标记语法本身，GSC 的增强报告看的是线上抓取到的版本。三个来源的时间点不一样，GSC 的报告通常滞后 3 到 7 天。",[11,34,35],{},"我遇到过一个页面上线当天测全部通过，一周后 GSC 报错误，原因是部署时模板回滚了。所以别用测试工具的结果当最终结论，以 GSC 为准。",[15,37,38],{"id":38},"我们只修哪些",[11,40,41],{},"影响富媒体展示的优先修：Article、Breadcrumb、Product、SoftwareApplication、Video。这些能在搜索结果里多占一行，或者让实体更明确。",[11,43,44],{},"已经不展示的类型不用管。FAQ 类富媒体结果在 2023 年 8 月被收缩到少数站点，很多站还在拼命补 FAQ 标记，白费功夫。HowTo 也类似。",[11,46,47],{},"还有一类值得做但不叫修错误：给软件产品页加 SoftwareApplication 标记，写清楚名称、操作系统、价格区间。它不一定带来富媒体，但能让搜索引擎和 AI 搜索更清楚你是什么产品。",[15,49,50],{"id":50},"修的顺序",[11,52,53],{},"先看 GSC 增强报告里错误级别的类型分布，按影响页面数从多到少排。每类先修 5 个页面，等一周看报告有没有变化，确认修对了再全量。",[15,55,56],{"id":56},"两个容易漏的检查",[11,58,59],{},"第一个是 URL 的写法。Schema 里的 item、@id、breadcrumb 的 item 都要用绝对地址，写成相对路径时检测工具不一定报错，但解析会出问题。我们抽查时会专门搜一遍有没有 href=“\u002F” 这种写法。",[11,61,62],{},"第二个是标记和页面内容要一致。价格改了但标记没同步，搜索结果里显示的价格和落地页差一倍，用户点进来就觉得被骗。每次改价、改套餐名，顺手检查一下标记。",[11,64,65],{},"我自己踩过的坑是一次性改了 800 个页面的模板，改错了一个字段名，等 GSC 报出来已经过了十天。批量改之前一定先用 5 个页面验证，这个习惯省钱省时间。",{"title":67,"searchDepth":68,"depth":68,"links":69},"",2,[70,71,72,73,74],{"id":17,"depth":68,"text":17},{"id":29,"depth":68,"text":29},{"id":38,"depth":68,"text":38},{"id":50,"depth":68,"text":50},{"id":56,"depth":68,"text":56},null,"技术SEO","2026-01-08","一个站 340 条标记报错，真正影响展示的只有 27 条。这篇写三类报错怎么区分、两个检测工具为什么结论不同，以及我们按什么顺序修。",false,"md",{},true,"\u002Fblog\u002Fstructured-data-tool-errors",{"title":5,"description":78},"blog\u002Fstructured-data-tool-errors",[87,88,89],"结构化数据","Schema","富媒体结果","glBBuEiVB6mx8ppzB86A74wJSWo6k6nZXjUFRKyPBYA",{"id":92,"title":93,"author":6,"body":94,"canonical":75,"category":165,"cover":75,"date":166,"description":167,"draft":79,"extension":80,"keywords":75,"meta":168,"navigation":82,"noindex":79,"ogImage":75,"path":169,"seo":170,"seoDescription":75,"seoTitle":75,"stem":171,"tags":172,"updated":75,"__hash__":176},"blog\u002Fblog\u002Fgoogle-spam-update-targets.md","Google 垃圾更新打的三类站，软件站最易中招",{"type":8,"value":95,"toc":157},[96,99,102,105,108,111,115,118,121,124,127,130,133,136,139,142,145,148,151,154],[11,97,98],{},"Google 的垃圾内容政策这几年越收越紧，打的不是\"用 AI\"，是\"规模化产出没有增量价值的内容\"。我们复盘了被处理的 9 个站，集中在三类，软件公司最容易踩的是第二类，我们 2025 年下半年连着遇到 3 个。",[15,100,101],{"id":101},"三类站具体长什么样",[11,103,104],{},"第一类，批量采集站。把别人的内容抓过来改改就发，一天几十篇。这类站被处理最快，我们见过上线 6 周就被清空的。",[11,106,107],{},"第二类，寄生页面。在自己的官网某个目录下，堆大量和主业无关的第三方内容，靠主站权重带流量。典型是 SaaS 官网里塞\"贷款攻略\"\"保险对比\"这类页面。",[11,109,110],{},"第三类，过期域名站。买一个有历史权重的老域名，直接换内容做站。Google 2024 年就把过期域名滥用写进了垃圾政策，这类操作现在风险很高。",[15,112,114],{"id":113},"_2024-年-3-月那批政策说了什么","2024 年 3 月那批政策说了什么",[11,116,117],{},"Google 2024 年 3 月的核心更新同时更新了垃圾内容政策，点名了三类行为：批量生成的内容、寄生在别的站点上的第三方内容、滥用过期域名。这三条后来一直是判定依据。",[11,119,120],{},"很多解读只盯着 AI 生成，其实政策说的是规模化产出、没有增量价值，你人工写 400 篇水稿，一样算。",[15,122,123],{"id":123},"软件站最容易中哪一类",[11,125,126],{},"第二类。我们接触的 3 个被处理的软件站，都是在官网博客里堆了几百篇和产品无关的内容，想靠主站权重吃泛流量。",[11,128,129],{},"一个做项目管理工具的客户，在 \u002Fblog 下发了 400 多篇\"职场技巧\"\"效率方法\"，占了整站页面的 60%，自然流量一度很可观。2025 年一次更新后，这 400 篇几乎全部掉出索引，主站核心词也跟着掉了 4 名。",[15,131,132],{"id":132},"我们怎么自查",[11,134,135],{},"三个问题：这些页面和你的产品有没有直接关系？这些页面有没有只有你能写的内容？删掉这批页面，核心业务的流量会不会掉？",[11,137,138],{},"三个答案都是\"否\"，就动手清。清的节奏要慢，一次删 20%，观察两周再继续，别一天全下线。",[15,140,141],{"id":141},"一个恢复案例",[11,143,144],{},"上面那个客户，我们分三批清了 380 篇，保留 20 篇真有数据的。同时给剩余页面补了产品截图和实测记录。",[11,146,147],{},"清完第 5 周开始有回升，第 9 周核心词回到原来的位置，被清掉的泛流量没回来，但询盘质量明显变好——因为留下来的都是搜产品功能的用户。",[15,149,150],{"id":150},"我们的判断",[11,152,153],{},"这套判断我们定了两年，中间只改过一次：以前允许博客写一点行业泛内容做曝光，现在不做了。泛流量对软件公司是负债，看着热闹，转化和留存都撑不起来。",[11,155,156],{},"别把官网博客当流量池。软件公司的博客应该只写三类内容：产品怎么用、行业问题怎么解、我们踩过什么坑。和产品无关的泛流量，赚的是广告费的钱，不是 SaaS 的钱。",{"title":67,"searchDepth":68,"depth":68,"links":158},[159,160,161,162,163,164],{"id":101,"depth":68,"text":101},{"id":113,"depth":68,"text":114},{"id":123,"depth":68,"text":123},{"id":132,"depth":68,"text":132},{"id":141,"depth":68,"text":141},{"id":150,"depth":68,"text":150},"行业观察","2026-01-07","Google 的垃圾内容政策这几年越收越紧，打的不是 AI，是规模化产出没有增量价值的内容。我们复盘了 2025 年被处理的 9 个站，集中在三类，软件公司最容易踩的是寄生页面这一类。每类长什么样、怎么自查、怎么清理都写了。",{},"\u002Fblog\u002Fgoogle-spam-update-targets",{"title":93,"description":167},"blog\u002Fgoogle-spam-update-targets",[173,174,175],"Google算法","垃圾内容","站点合规","7Dl2k1p2xv6CSqYajpV77EdvSVlZnB2gn7KRhCyDeUQ",{"id":178,"title":179,"author":6,"body":180,"canonical":75,"category":76,"cover":75,"date":242,"description":243,"draft":79,"extension":80,"keywords":75,"meta":244,"navigation":82,"noindex":79,"ogImage":75,"path":245,"seo":246,"seoDescription":75,"seoTitle":75,"stem":247,"tags":248,"updated":75,"__hash__":252},"blog\u002Fblog\u002Fssr-vs-static-ttfb.md","SSR 和静态生成哪个 TTFB 更低，我们测了三类软件站",{"type":8,"value":181,"toc":235},[182,185,188,191,194,197,201,204,207,210,213,216,220,223,226,229,232],[11,183,184],{},"同一个页面，静态生成的 TTFB 是 90 毫秒，SSR 是 480 毫秒，纯客户端渲染的首字节只要 120 毫秒但 LCP 会差一截。这是我们在三类软件站上测出来的结果，测试时间是去年 10 月到 12 月。结论是内容页静态化，个性化部分交给客户端。",[15,186,187],{"id":187},"测的三类站",[11,189,190],{},"文档站：内容按版本发布，天然适合静态生成。我们把一个 800 页的文档站从 SSR 改成静态生成加 CDN，TTFB P75 从 610 毫秒降到 95 毫秒，服务器成本降了四成。",[11,192,193],{},"营销站：一周改两次，用增量静态再生成就够。首页原来每次请求都走 Node 服务，改成静态加 10 分钟缓存，TTFB 从 540 到 130 毫秒。",[11,195,196],{},"后台控制台：登录后才能看，SSR 没法省。这类页面我们没动渲染方式，只在服务端做了接口并行和数据预取。",[15,198,200],{"id":199},"为什么-ssr-慢","为什么 SSR 慢",[11,202,203],{},"三个原因：每个请求都要跑一遍框架渲染、接口调用在服务端串行、没有缓存层。第一项省不掉，后两项能改。",[11,205,206],{},"一个客户做了接口并行加 60 秒数据缓存，SSR 的 TTFB 从 700 毫秒降到 280 毫秒。这个投入产出比挺高，比换框架现实得多。",[15,208,209],{"id":209},"静态化的边界",[11,211,212],{},"静态化不是万能的，两个前提：内容不因人而异、更新可以延迟。定价页如果按地区显示不同价格就得小心；用户中心如果静态化，页面会串号。",[11,214,215],{},"我们的做法是\"壳静态加数据客户端\"：HTML 里只有布局和文案，个性化数据用接口补。代价是首屏数据晚一点到，对内容页来说无所谓。",[15,217,219],{"id":218},"cdn-命中率才是分水岭","CDN 命中率才是分水岭",[11,221,222],{},"静态生成只是第一步，页面能不能落到离用户最近的节点，取决于缓存命中率。同样两个用静态生成的站，命中率 95% 的 TTFB 是 90 毫秒，命中率 40% 的 TTFB 是 380 毫秒，差别比 SSR 到静态生成这一步还大。",[11,224,225],{},"所以我们改静态生成的时候，会同时把 CDN 的规则和预热一起做。不预热的话，发布后第一批用户仍然要走回源，那几分钟的 TTFB 和没改一样。",[15,227,228],{"id":228},"一条判断清单",[11,230,231],{},"内容页（文档、博客、案例、术语表）走静态生成。营销页（首页、功能、定价）走静态加短缓存。后台和工具走 SSR，重点优化接口。这条线我们用了两年，没出过大问题。",[11,233,234],{},"给文档站上 SSR 还配不好缓存的，我见过好几个。这是纯粹的资源浪费，也是 TTFB 优化最常见的弯路。文档站的核心诉求是\"任何地方都快手可及\"，静态页面加 CDN 就是答案，不需要更复杂的东西。",{"title":67,"searchDepth":68,"depth":68,"links":236},[237,238,239,240,241],{"id":187,"depth":68,"text":187},{"id":199,"depth":68,"text":200},{"id":209,"depth":68,"text":209},{"id":218,"depth":68,"text":219},{"id":228,"depth":68,"text":228},"2026-01-10","同一页面，静态生成 TTFB 90 毫秒、SSR 480 毫秒、纯客户端渲染首字节 120 毫秒但 LCP 差一截。文档站、营销站、后台各该用哪种，附一条判断清单。",{},"\u002Fblog\u002Fssr-vs-static-ttfb",{"title":179,"description":243},"blog\u002Fssr-vs-static-ttfb",[249,250,251],"SSR","静态生成","TTFB","rhoGNDUQNAoHPLWDPoeHWXaKgDQLPxE3XKD-wfEQMVA",1794088109364]