GEO/AEO时代重写Schema Markup：WordPress与Shopify实战指南

做独立站的人应该能明显感觉到，今年流量的玩法变了。以前我们盯着Google排名的前三位，现在用户的提问首先由AI引擎回答，比如Google AI Overviews、Perplexity、ChatGPT的联网搜索。传统的Schema Markup被很多人当作“交给爬虫读的东西”，但它在GEO/AEO时代反而是最值得重写一遍的资产。作为一个经常折腾WordPress和Shopify的运营，我把最近一年在结构化数据上的实战经验整理成这篇指南，希望能帮同样做内容站或者电商站的朋友少走弯路。

1. 为什么现在要重新审视Schema Markup：AIO/GEO/AEO到底是什么

先说个我自己的观察。去年年中我发现自己一个老内容站的搜索流量组成发生了变化，Google Search Console里核心词排名没掉，但页面点击率降了不少。后来看用户行为，才意识到大量用户直接通过Google AI Overviews获得答案，根本不点链接。也就是说，搜索引擎开始用自己的“答案”截留流量，而决定哪个网页被引用的因素里，结构化数据比以往任何时候都重要。

1.1 传统SEO和GEO/AEO的区别

传统SEO的核心是“匹配关键词、提升排名”，它服务的是传统爬虫和索引系统。而GEO（Generative Engine Optimization，生成式引擎优化）的目标，是让你的网页内容成为生成式AI在回答用户问题时优先引用的信息源。AEO（Answer Engine Optimization，答案引擎优化）则更聚焦：当用户直接问“怎么做”“是什么”“多少钱”时，你的内容能不能被AI直接提取出来，形成一段简洁的答案。

这两个东西本质上是同一件事的两个侧面：让AI理解你、信任你、引用你。而Schema Markup，就是一种给AI划重点的语言。

1.2 Schema Markup在GEO/AEO中的角色

很多人以为Schema只是给Google爬虫看的，其实不是。Google、Bing等主流搜索引擎都明确表示，结构化数据可以帮助他们的系统理解页面内容。到了生成式AI时代，那些使用GEO优化手段的团队发现，带有清晰、完整、语义准确的结构化数据的网页，在被AI引擎提取信息时，往往比没有结构化数据的网页更容易被选中。

原因也很简单。AI生成答案时需要快速判断哪段文字可以直接用，如果你的页面用Article、FAQPage、HowTo等Schema把关键信息标得清清楚楚，等于告诉AI“这段是权威回答，直接拿走”。反过来，如果所有内容混在一起，AI只能通过自然语言处理去猜，那准确度和引用概率都会打折扣。

1.3 WordPress和Shopify的Schema实现差异

WordPress是开源系统，自由度极高，你可以用插件、主题文件、代码片段任意方式注入Schema，控制力最强。而Shopify是SaaS平台，服务器端渲染和模板机制比较封闭，通常需要通过Liquid模板或者特定App来实现，不能修改系统核心。所以我们在策略上要区别对待：

• WordPress：适合精细化定制，能处理复杂的内容型Schema，比如Article、FAQPage、HowTo、Recipe等。
• Shopify：天生电商属性，对Product、Offer、AggregateRating这些Schema支持得不错，但内容型Schema（比如Blog文章的Article）需要额外手工处理。

下面我把两个平台的落地方法逐一拆开讲。

2. Schema Markup核心知识点：类型选择与属性要点

在动手写代码之前，必须先搞清楚一个基础问题：到底该用哪些Schema类型，每种类型里哪些属性是最关键、直接影响GEO/AEO效果的。

2.1 核心类型：Article、Product、FAQPage、HowTo、BreadcrumbList

我在实际项目中，最常用的几种类型分别是：

• Article：用于博客文章、新闻、指南类页面。这是AEO的基础，因为它能告诉搜索引擎这篇文章的作者、发布时间、标题、摘要、主要实体等关键信息。
• Product + Offer + AggregateRating：电商产品的标配。Shopify大部分主题会自动生成，但默认质量参差不齐，后文会专门讲怎么优化。
• FAQPage：适合“常见问题”区块。这个类型在传统SEO里已经被证明对精选摘要很有帮助，在AEO时代更是重要，因为AI回答的很大一部分就是FAQ形式。
• HowTo：教程、步骤类内容专用。如果你的文章是“如何设置XXX”，用HowTo把步骤拆解清楚，AI提取答案时会轻松很多。
• BreadcrumbList：面包屑导航。能帮助搜索引擎理解站点层级，同时对AI理解你的网站结构有帮助。
• Organization、WebSite：站点级别的全局信息，包括Logo、搜索URL、社交主页等，帮助搜索引擎认识你整个站的权威度。

这几类不是越多越好，而是每一类都要“扎得深、写得准”。比如FAQPage的关键不只是加上去，而是每个问题和答案都要精炼、独立、可被提取。

2.2 JSON-LD的关键属性详解

JSON-LD是现在Google最推荐的结构化数据格式，原因很简单：和HTML彻底解耦，不容易被CSS、JS干扰，而且可以在页面头部统一管理。我建议所有新建站点一律用JSON-LD，不要再写microdata或者RDFa。

一个标准的Article JSON-LD，至少要包含这些属性：

{ "@context": "https://schema.org", "@type": "Article", "headline": "如何在WordPress中添加Schema Markup", "description": "本文介绍WordPress中实现Schema Markup的完整方法与常见错误。", "image": "https://example.com/image.jpg", "author": { "@type": "Person", "name": "张小明", "url": "https://example.com/about" }, "publisher": { "@type": "Organization", "name": "示例站点", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" } }, "datePublished": "2024-01-15", "dateModified": "2024-05-20", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/article-slug" } }

这里面有几个属性，放在AEO语境下特别重要：

• headline：标题尽量和H1一致，或者至少高度相关。AI在引用时，通常会优先采信“标题与内容高度匹配”的页面。
• description：这里不要写空话，要写成可以直接作为答案引用的摘要句子。想象一下，如果AI从你的页面截取两句话作为回复，会不会是这两句？
• datePublished和dateModified：AI引擎在判断信息时效性时，会参考这个时间戳。如果你的页面更新过但没有改dateModified，等于告诉AI“这内容可能过时了”。
• author和publisher：影响权威度判断。独立博客作者名要真实可查，企业站要确保Organization信息完整。

我之前帮一个客户排查，发现他的所有文章dateModified都是固定的“1970-01-01”，原因是主题在改版时把日期字段的代码写崩了，导致Google一直认为他的站点从未更新。折腾半天，结果是个低级Bug。所以，日期字段的真实性和正确性，在AI引擎时代比你想象的更重要。

2.3 speakable属性与AEO的关系

speakable算是结构化数据里比较冷门、但和AEO强相关的一个属性。它标记出页面中哪一段文字“可以直接朗读给用户听”。Google的语音搜索和Google Assistant非常依赖这个字段。

示例

{ "@context": "https://schema.org", "@type": "WebPage", "name": "如何优化Speakable内容", "speakable": { "@type": "SpeakableSpecification", "cssSelector": [".article-summary", ".answer-box"] } }

实际操作时，我会把文章开头的一个“快速答案”区块（通常在60到80字以内的概述段）加上speakable。这样当用户问“如何优化Speakable内容”时，AI有很高的概率直接提取这段作为语音答案。这是目前AEO优化里性价比最高的一个技巧。

2.4 校验工具的使用习惯

写完Schema之后，一定跑一遍校验，不要直接上线。我常用的工具有三种：

• Google Rich Results Test：可以测试页面在不同设备下的富媒体展示效果，也能检查语法错误。
• Schema Markup Validator：schema.org官方的校验工具，对JSON-LD语法检查更严格。
• Google Search Console的Enhancements报告：上线后持续观察结构化数据的有效状态。

实际做法是：先在Rich Results Test里粘贴代码片段测试，无误后再部署到线上页面；线上部署后再在Search Console里提交URL检查，看Google是否成功抓取到新的结构化数据。

3. WordPress站点落地实操

下面是我在WordPress上真正跑过、验证过的几种方式，按推荐程度从高到低排列。

3.1 方案一：使用插件配置标准化Schema

如果你的站点主题本身没有内置Schema，我建议先用一个靠谱的插件。目前我常用的是Slim SEO Schema，它对文章、分类、页面等多种类型都有自动生成支持，而且模板代码很干净，不会产生大量冗余的JSON-LD。具体设置步骤通常是：

1. 在WordPress后台搜索安装Slim SEO Schema并启用。
2. 进入设置 -> Schema，选择“自动生成”还是“手动指定”模式。
3. 对文章类型启动Article Schema，对产品页启动Product Schema。
4. 配置Publisher信息：站名、Logo、社交媒体链接。
5. 保存后，用Rich Results Test检测首页和一篇示例文章。

用插件的最大好处是省事，比如你的主题如果自动生成了旧格式的Schema，插件能帮你覆盖或去重。但我必须提醒一点：插件不是越多越好。很多主题自带Schema功能，你又额外装了SEO插件，两个插件同时输出JSON-LD，会直接在页面里堆出多份重复的Article Schema。Google虽然一般不会因此直接惩罚，但会影响它对页面结构的判断。所以我有一个强制要求：装插件之前，先看主题有没有自带的Schema输出，如果主题自带，就二选一。

3.2 方案二：代码手工插入JSON-LD

如果插件满足不了你的定制需求，或你想彻底控制页面输出，可以用代码方式手工注入。我推荐使用functions.php配合wp_head钩子来插入站点级别的Schema，同时使用the_content过滤器去处理特殊页面。

在子主题的functions.php中插入如下代码，可以实现在文章页输出Article Schema：

// 在文章页输出Article JSON-LD function custom_article_schema() { if ( is_singular( 'post' ) ) { $post = get_post(); $title = get_the_title( $post ); $permalink = get_the_permalink( $post ); $excerpt = has_excerpt( $post ) ? get_the_excerpt( $post ) : wp_trim_words( $post->post_content, 25, '...' ); $author_name = get_the_author_meta( 'display_name', $post->post_author ); $date_published = get_the_date( 'c', $post ); $date_modified = get_the_modified_date( 'c', $post ); $thumbnail = get_the_post_thumbnail_url( $post, 'full' ); $schema = array( '@context' => 'https://schema.org', '@type' => 'Article', 'headline' => $title, 'description' => $excerpt, 'image' => $thumbnail ? $thumbnail : '', 'author' => array( '@type' => 'Person', 'name' => $author_name, 'url' => get_author_posts_url( $post->post_author ), ), 'publisher' => array( '@type' => 'Organization', 'name' => get_bloginfo( 'name' ), 'logo' => array( '@type' => 'ImageObject', 'url' => get_site_icon_url(), ), ), 'datePublished' => $date_published, 'dateModified' => $date_modified, 'mainEntityOfPage' => array( '@type' => 'WebPage', '@id' => $permalink, ), ); echo '<script type="application/ld+json">' . wp_json_encode( $schema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES ) . '</script>'; } } add_action( 'wp_head', 'custom_article_schema' );

这里我用了WordPress原生的wp_json_encode函数来输出完整JSON对象，而不是手动拼字符串，这样能充分照顾转义问题。另外特别注意：如果你创建了子主题，必须把这段代码塞进子主题的functions.php，不要直接改父主题文件，否则主题一更新，代码全没了。

3.3 FAQPage的代码插件玩法

FAQPage Schema更常见的实现方式是放在文章内容底部。你可以手动编辑文章，也可以把它写成一个短代码，让你在古腾堡编辑器中随时调用。

我常用的一种方式是这样的：在子主题的functions.php里注册一个短代码，然后在文章底部输入短代码包裹的问答列表。短代码内部会解析HTML标签并输出对应的JSON-LD。这个流程适合批量维护FAQ内容，同时能确保前后端展示一致。

做FAQPage Schema时，有一个坑我需要拿来说一下：每一个FAQ问题都要和页面正文真正能对应上。以前大家做SEO，喜欢在底部塞一堆跟文章无关的问答，只为骗一个FAQ富媒体展示位。Google在2023年调整了FAQ富媒体结果的展示规则，普通网页的FAQ只对权威健康类网站显示，于是很多站长的FAQ Schema“白加了”。但在GEO时代，FAQ的价值不完全在于富媒体卡片，而在于AI。AI不会看你有没有QA样式，它只看你页面上是否真的用清晰方式回答了这个问题。所以我的建议是：老老实实写正文能覆盖到的FAQ，把每个答案压缩到一两句话，方便AI提取。

3.4 WordPress常见Schema问题实战

用WordPress做Schema，我踩过不少坑，最典型的几个：

• 主题和插件同时输出重复Schema：如果主题已有Schema输出，又装了SEO插件，页面会同时出现两套Article。解决办法是进主题自定义器找“Schema/结构化数据”开关，或者用代码移除主题的默认输出。
• JSON-LD被PHP报错中断：有些朋友直接在functions.php里把JSON字符串套进双引号中，结果转义没处理好，页面直接白屏。我建议只要涉及动态数据，就用wp_json_encode生成数组，别自己手写JSON字符串。
• 缓存插件导致Schema更新延迟：WordPress一般都会装缓存插件，JSON-LD可能存在缓存里。你改完代码后，测试时直接刷新看不到变化，一定要先清缓存再查。我调试时经常忘记这一点，白白浪费很多时间。

4. Shopify站点落地实操

Shopify是另一种生态。很多人觉得在Shopify里写Schema很麻烦，因为它是封闭SaaS，其实没有想象中难，只是思路不太一样。

4.1 Shopify自带的结构化数据与局限

Shopify的系统里，默认的商品页面会输出Product Schema，而且包含价格、库存、评价等关键信息。但问题在于：

• 默认代码里经常没有品牌字段、没有GTIN/MPN等商品标识符，对购物类搜索的展示比较吃亏。
• 默认的评分聚合信息通常是空的，除非你安装了评价App，否则AggregateRating不会出现。
• 针对博客文章的Article Schema，Shopify默认根本不会输出。

所以，Shopify上的优化重点不是“从零写JSON-LD”，而是把系统默认输出“修好、补全、去重”。

4.2 在theme.liquid中添加自定义JSON-LD

我一般会在当前主题里找到一个合适的模板文件，比如商品页模板product.liquid或main-product.liquid，然后在结构比较靠前的位置插入自定义JSON-LD。下面是一个商品页的定制示例：

{%- if template.name == 'product' -%} <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Product", "name": {{ product.title | json }}, "description": {{ product.description | strip_html | truncate: 300 | json }}, "image": {{ product.featured_image | image_url: width: 800 | prepend: 'https:' | json }}, "sku": {{ product.selected_or_first_available_variant.sku | default: product.id | json }}, "brand": { "@type": "Brand", "name": {{ product.vendor | json }} }, "offers": { "@type": "Offer", "url": {{ shop.url | append: product.url | json }}, "priceCurrency": {{ cart.currency.iso_code | json }}, "price": {{ product.selected_or_first_available_variant.price | divided_by: 100.0 | json }}, "availability": "https://schema.org/{% if product.available %}InStock{% else %}OutOfStock{% endif %}", "itemCondition": "https://schema.org/NewCondition" } } </script> {%- endif -%}

用Liquid的json过滤器就相当于给值做了转义，不会因为产品名称里带引号而出错。这段代码适合直接放到产品模板的<div class="product-page">外层，或者放在theme.liquid里用template.name判断来控制。

4.3 产品评价和评分数据的接入

如果你用的是Judge.me、Loox或者Product Reviews这类评价App，拿到汇总评分会让Product Schema威力大增。方法很简单：在Liquid模板里判断product.metafields.reviews.rating_count是否存在，存在就把AggregateRating加进Schema：

{%- if product.metafields.reviews.rating_count != blank -%} "aggregateRating": { "@type": "AggregateRating", "ratingValue": {{ product.metafields.reviews.rating_value | json }}, "reviewCount": {{ product.metafields.reviews.rating_count | json }} } {%- endif -%}

这样Google搜索结果里就能直接显示星级评分，而且评分数据是从App实时拉取的，不需要手动维护。我测试下来，带评价的Product Schema点击率提升大概在8%到15%之间，效果比较明显。

4.4 Shopify博客文章的Article Schema补全

Shopify的博客文章默认不带Article Schema，这对做内容营销的站点很不友好。补全方法同商品页，你打开文章模板article.liquid或main-article.liquid，添加以下JSON-LD：

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": {{ article.title | json }}, "description": {{ article.excerpt_or_content | strip_html | truncate: 200 | json }}, "image": {{ article.image | image_url: width: 1200 | prepend: 'https:' | json }}, "author": { "@type": "Person", "name": {{ article.author | json }} }, "publisher": { "@type": "Organization", "name": {{ shop.name | json }}, "logo": { "@type": "ImageObject", "url": {{ settings.logo | image_url: width: 200 | prepend: 'https:' | json }} } }, "datePublished": {{ article.published_at | date: '%Y-%m-%d' | json }}, "dateModified": {{ article.updated_at | date: '%Y-%m-%d' | json }} } </script>

这里有一个细节：article.excerpt_or_content是Shopify Liquid里的对象，如果文章没有手写摘要，它会自动截取内容文本。用strip_html和truncate处理一下，能保证description字段长度合理，不会因为内容太长而被搜索引擎截断。

4.5 Shopify和WordPress在Schema策略上的核心差异

简单总结一下两者区别：

所以在WordPress上，我倾向于“减负”：去掉重复的Schema、保留最核心的类型。在Shopify上，我倾向于“补全”：把系统缺的Article、FAQPage这些内容类字段补上，再把默认的Product Schema做得更完整。

5. 面向AEO/GEO的Schema Markup写作策略

把代码写对只是第一步，真正让Schema发挥GEO/AEO作用，要在内容写作层面下功夫。

5.1 在正文开头植入“快速答案”区

AEO的核心是“为你准备好答案”。我制定了一个很简单的规则：每篇文章开头，先写一段不超过80字的总结，直接回答标题里的问题。这段放在一个样式明确的div中，比如class为article-summary，同时这段文字的前半部分可以作为speakable的指向区块。

比如你写“如何优化Shopify产品页”，开头就这么写： “优化Shopify产品页的核心是：确保标题包含主要关键词，写清楚产品痛点与卖点，添加真实用户评价，并通过Product Schema标记让搜索引擎和AI明白页面信息。”

这段文字就是AI可以直接提取出来回答的“标准答案”。然后正文再展开细讲。这样做的理论基础很朴素：AI进行答案生成时，往往会更倾向于提取页面中语句最紧凑、和问题句法最匹配的段落，而不是大段论述。

5.2 用FAQPage类型建立“问题-答案”映射

内容页里，我会在末尾增设“常见问题”栏目，每个问题用完整的疑问句，每个答案控制在2-3句话以内。这不仅服务用户，也方便AI快速理解和抽取。

以Shopify文章为例，FAQ可以这样设置：

• 问题：Shopify产品页必须用Product Schema吗？答案：强烈建议使用，尤其是想要在搜索结果中展示价格、库存和评分时，Product Schema是标准方式。
• 问题：Shopify内置的Schema够用吗？答案：系统默认输出基本Product信息，但缺少品牌、评价等增强属性，建议通过Liquid模板手动补充。

这个FAQ段落本身对应FAQPage或FAQ的Schema输出，但有一个关键点：页面正文中必须包含这些问答的实际内容。前文提过，不能在HTML里只放一个JSON-LD就完事，用户看不见的问答没有意义，AI最终也会抓取页面文本去验证真实性。

5.3 让AI“信任”你的内容：实体、引用与上下文

除了Schema本身，GEO的更高阶玩法是用Schema去标记实体关系。比如你的文章里提到了“WordPress”“Shopify”“Schema Markup”这些概念，可以用about属性把它们设为@type: 'Thing'，或者用mentions属性标注相关实体。这样AI能更清楚地理解你的内容在讲什么，增加被引用的概率。

"about": [ { "@type": "Thing", "name": "WordPress" }, { "@type": "Thing", "name": "Schema Markup" } ]

另外，一定要记得在你的内容中引用权威来源，比如Google官方文档、Schema.org规范、W3C标准等，并在Schema中使用citation属性标记引用来源。AI引擎对“有出处的信息”信任度更高，这会直接影响最终答案中是否出现你的站点。

5.4 数据层联动：用Schema和内容结构一起构建“答案库”

做了几年SEO，我最大的体会是：Schema不是独立存在的技术文件，它应该和你的内容结构结合成一个“答案库”。我给自己定了一个Checklist：

• 每个页面有一个清晰的核心问题（标题或H1）。
• 前100字内直接给出核心答案。
• 正文用H2/H3把答案拆分成可独立引用的模块。
• 用Article/FAQ/HowTo等Schema把上述模块标记出来。
• 页面里至少有一个可选的speakable区域。
• 关键概念用about/mentions做实体标注。
• 对外部数据引用使用citation。

满足这个清单的页面，在GEO测评工具里的表现普遍比普通页面高一个档次。顺带一提，市面上已经出现不少提供“GEO评分”的服务，我试用过几款，虽然评分模型各有不同，但核心指标几乎都包含“是否使用了结构化数据”“答案是否前置”“是否包含引用来源”这几项。所以这些方法并不玄学，都是有数据验证的。

6. 常见问题与排查技巧实录

最后一部分，我把这段时间被问到最多的问题做个汇总，也算是给自己留个排查手册。

6.1 结构化数据不被Google识别

症状：Rich Results Test显示页面没有结构化数据，或报错节点缺失。

排查思路：

• 先查看网页源代码，确认JSON-LD代码是否真的出现在HTML中。有时候是缓存插件、CDN或者延迟加载脚本把标签过滤掉了。
• 如果代码在，但测试工具不识别，检查JSON是否符合语法。可以用JSONLint之类的工具验证一遍。
• 检查是不是被多重包裹。比如你把JSON-LD放进HTML注释里，或者放到<template>标签内，搜索引擎是不会解析的。

6.2 同一页面出现重复Schema

这是WordPress用户最容易踩的坑。原因通常是主题内置Schema + SEO插件Schema + 你自己手动加的Schema，三方叠加。解决方法：

• 在主题自定义器或功能选项中查找“Schema/结构化数据/SEO”相关开关，关掉主题默认输出。
• 如果主题没有开关，用代码在wp_head钩子上设置优先级，把主题输出的application/ld+json标签全部移除，再输出自己的。
• Shopify相对较少遇到这问题，但如果你同时安装多个SEO App，也要检查是否重复输出Product Schema。

6.3 动态字段取值异常

Shopify的Liquid模板经常遇到一个尴尬：代码写对了，但价格显示为null或0。问题往往出在变量上。比如在某些主题里，product.selected_or_first_available_variant并不一定总是有值，尤其是遇到无库存商品。保险做法是先判断：

{%- assign variant = product.selected_or_first_available_variant | default: product.variants.first -%}

然后所有用到price的地方都用variant.price。确保在Liquid模板中所有字段都使用真实存在的对象，否则浏览器会直接忽略整段JSON-LD。

6.4 日期格式不规范导致日期解析失败

JSON-LD里的日期必须是ISO 8601格式，比如2025-01-15或2025-01-15T10:00:00+08:00。如果你从后台拿到的是“January 15, 2025”这种格式，Google很容易解析失败。WordPress主题一般输出得比较标准，但如果你用的是自定义字段，一定手动格式化成c格式。Shopify的Liquid中，可以用date: '%Y-%m-%dT%H:%M:%S%z'来生成ISO格式。

6.5 加了Schema不代表一定有富媒体展示

最后再强调一点：加了Schema只是给了搜索引擎一个展示的“候选资格”，搜索引擎到底展示不展示、展示成什么样，取决于内容质量、页面性能、用户行为等综合因素。所以方案是：把Schema当作基础设施，别把全部希望寄托在上面。真正的内容质量、回答逻辑、用户价值，才是GEO优化的底层逻辑。

我个人在实际操作中的体会是：Schema Markup在AIO/GEO/AEO时代，已经从“技术加分项”变成了“基础必选项”。你不需要一次把所有Schema类型都堆上去，但你要保证每个页面的核心意图都有清晰的结构化数据支撑，并且页面内容本身能回应这些问题。从内容规划开始就把Schema写进去，比事后补一堆代码要高效得多。

如果让我给一条最实用的建议：下周先挑一个模板页，把Article或Product的JSON-LD补全，然后跑一遍Rich Results Test，再去Search Console提交验证。你亲手做完一遍，很多理论上的东西就通了。这个是独立站最值得投入时间的一件事，能让你在AI搜索里被看见的概率翻倍。