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

做独立站的人应该能明显感觉到今年流量的玩法变了。以前我们盯着Google排名的前三位现在用户的提问首先由AI引擎回答比如Google AI Overviews、Perplexity、ChatGPT的联网搜索。传统的Schema Markup被很多人当作“交给爬虫读的东西”但它在GEO/AEO时代反而是最值得重写一遍的资产。作为一个经常折腾WordPress和Shopify的运营我把最近一年在结构化数据上的实战经验整理成这篇指南希望能帮同样做内容站或者电商站的朋友少走弯路。1. 为什么现在要重新审视Schema MarkupAIO/GEO/AEO到底是什么先说个我自己的观察。去年年中我发现自己一个老内容站的搜索流量组成发生了变化Google Search Console里核心词排名没掉但页面点击率降了不少。后来看用户行为才意识到大量用户直接通过Google AI Overviews获得答案根本不点链接。也就是说搜索引擎开始用自己的“答案”截留流量而决定哪个网页被引用的因素里结构化数据比以往任何时候都重要。1.1 传统SEO和GEO/AEO的区别传统SEO的核心是“匹配关键词、提升排名”它服务的是传统爬虫和索引系统。而GEOGenerative Engine Optimization生成式引擎优化的目标是让你的网页内容成为生成式AI在回答用户问题时优先引用的信息源。AEOAnswer 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和dateModifiedAI引擎在判断信息时效性时会参考这个时间戳。如果你的页面更新过但没有改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 Validatorschema.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。具体设置步骤通常是在WordPress后台搜索安装Slim SEO Schema并启用。进入设置 - Schema选择“自动生成”还是“手动指定”模式。对文章类型启动Article Schema对产品页启动Product Schema。配置Publisher信息站名、Logo、社交媒体链接。保存后用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 typeapplication/ldjson . 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 SchemaShopify默认根本不会输出。所以Shopify上的优化重点不是“从零写JSON-LD”而是把系统默认输出“修好、补全、去重”。4.2 在theme.liquid中添加自定义JSON-LD我一般会在当前主题里找到一个合适的模板文件比如商品页模板product.liquid或main-product.liquid然后在结构比较靠前的位置插入自定义JSON-LD。下面是一个商品页的定制示例{%- if template.name product -%} script typeapplication/ldjson { 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 classproduct-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-LDscript typeapplication/ldjson { 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策略上的核心差异简单总结一下两者区别维度WordPressShopify控制粒度完全掌控可精确到每条页面只能修改模板和App受平台限制默认Schema通常需要自己配产品页已有基础Schema但内容页基本没有动态数据PHP函数灵活读取Liquid对象较为受限但常用字段基本都有冲突风险主题、插件、SEO工具容易叠加App之间偶尔冲突但相对较少维护方式代码更新随主题/插件节奏走模板更新一直由Shopify平台控制相对稳定所以在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/ldjson标签全部移除再输出自己的。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:0008: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搜索里被看见的概率翻倍。