先确认旧价格出现在普通网页结果、商品富结果，还是Shopping等商家展示，再固定同一商品、规格、币种和目标市场。核对前台价格、Product/Offer标记及Merchant商品数据，修好真正不一致的那一层，再检查相应系统的处理状态。提交索引不能保证立即换价。
商品后台已经从39美元改成29美元，Google里还显示39美元，很容易让人反复点“请求编入索引”。但旧值可能仍在网页缓存里，也可能留在结构化数据或商品来源里。Google拿到的东西还没一致，反复催抓取也不一定能解决。
先截下旧价格出现的位置
先保存一张结果截图，记录搜索词、看到的时间、地区、币种和点击后的实际网址。留意旧价格是混在普通摘要文字里，还是出现在带商品图片和价格的展示中。
普通文字摘要、商品结构化展示和Merchant相关展示不是同一个处理入口。Google的商品结构化数据概览区分了Product snippets与Merchant listings；网站有Merchant账号，也不意味着所有自然搜索文字都来自那个账号。
如果你查的是Shopping或免费商品展示，接着去Merchant核对应商品。如果是网页商品富结果，先查页面和结构化数据。如果只是摘要引用了正文里的一句旧价格，还需要查这句文字是否真的已经更新。
仅凭“Google显示错了”这一句话，维护者很难知道该改哪一个系统。把具体位置记录下来，能省掉很多无效往返。
把商品身份固定，再比较三个价格
下面使用一个教学商品：蓝色M款，SKU为TEE-B-M，单件售价由39.00 USD降为29.00 USD。它没有会员价、批量阶梯价或跨币种转换，方便先看清同步问题。
| 检查位置 | 同一对象应该核对的内容 | 教学故障记录 |
|---|---|---|
| 未登录商品页 | 选中蓝色M后的实际价格和币种 | 29.00 USD |
| 页面的Offer标记 | 该规格对应的price与priceCurrency | 仍是39.00 USD |
| Merchant商品记录 | 对应商品ID、规格、链接和有效价格 | 29.00 USD |
这组记录最先指向页面标记的旧值。先查生成标记的插件或模板，而不是先重新建Merchant商品。如果三处都是29.00，才继续调查Google当前记录和展示的处理进度。
如果商品页打开的是父商品默认款，而Merchant链接指向另一规格，这张表还不能用。先解决落地规格，见Merchant商品链接与预选规格检查。
地区、税费和促销时段也要统一。一个含税前台价和一个不含税记录之间的差异，不应未经核实就被叫作缓存问题。
网页已经改价，为什么标记和缓存可能还没改
后台是维护者的编辑入口，未登录客户收到的页面可能经过页面缓存或CDN。先从未登录页面读取当前价格，不用后台预览代替客户视角。
接着用富结果测试工具或页面HTML定位Product/Offer。找出这条Offer属于哪个商品或规格，核对价格和币种。不要只看“检测到Product”这个绿色结果，也不要把页面其他商品卡的报价当作当前商品价。
常见的待查点包括：
- 页面缓存仍保留旧价，而登录管理员看到新价。
- 主题和SEO或电商插件各生成一份标记，其中一份还没更新。
- 页面选中了子规格，标记却仍在表达父商品或另一规格。
- 促销开始、结束或站点时区与预期不同。
这是一组排查方向，不能因为碰巧看到重复Product就直接删除所有标记。先让维护者确认哪一份由谁生成、各自代表什么，再修改真正错误的来源。商家信息结构化数据要求可作为字段核对依据。
若问题只在促销时间边界出现，可接着看WooCommerce促销价定时设置。
在HTML里找39美元，重点是它属于哪个Offer
沿用蓝色M教学商品。假设测试工具找到的Offer字段仍然是下面这样：
{
"@type": "Offer",
"price": "39.00",
"priceCurrency": "USD"
}
这只是说明字段的片段，不是可直接部署的完整Product标记。先在其所在Product对象中核商品身份和规格关系，再追查负责输出它的主题或插件。你要修改的是生成价格的来源；直接在一份缓存HTML里把39替换成29，下次重新生成仍可能恢复旧值。
确认来源后，再重新读取未登录HTML或测试结果，验证同一Offer已变成29.00 USD。页面还有推荐商品时，其他卡片出现39并不一定错误；只按全文搜索到39就删掉所有标记，会误伤别的商品。
如果未登录页面本身仍是39，而管理员能看见29，先查页面缓存/CDN及促销输出条件。若所有访客页面都29、只有Offer旧，优先查标记；这两种情况不要都叫“Google缓存没清”。
Merchant数据也旧，去查来源和同步记录
在Merchant找到同一个商品记录，确认来源、商品ID、目标国家、链接、价格和最近处理情况。别在一个不同市场的记录上改数值，再回头验证原市场。
促销还涉及price、sale_price及有效期间。普通售价与当前促销价不是两个可以随便互换的字段，具体要求见Google的价格属性说明。
如果插件或数据源没有把本次变化同步出去，修它的更新任务和来源记录。直接在后台手改一次，之后又被旧数据覆盖，说明上游问题还在。
Merchant自动商品更新可以缓解部分偶发的不一致，但Google明确说明，它不替代正常、持续的商品数据更新。见自动更新商品信息说明。如果经常变价，更应该把同步流程做可靠。
需要顺着商品来源与状态继续查时，使用WooCommerce商品与Merchant核查教程，不要重新创建同一SKU来绕过旧记录。
每一层都正确后，再检查Google处理到哪一步
本轮可以先确认三个结果：未登录网页实际报价正确，当前页面标记表达正确对象，Merchant当前来源记录也符合对应报价规则。把时间和对象记下来。
随后再核对Google已抓取的页面记录、Merchant问题状态以及实际展示。实时测试成功，代表当前输出可检查；它不证明旧展示已经刷新。
官方针对具体价格不匹配的问题给了处理说明。不同入口的处理节奏可能不同，不应把某一种问题页面的时间提示当作全网价格展示的保证。
如果展示仍旧，带着同一SKU、同一链接、三层当前证据和观察时间再追查。此时维护者能够判断是仍有旧数据，还是更新尚未体现。
三处读数不同，下一步怎么选
以下仍以同一规格、市场和币种为前提。它是一张定位表，不是断言任何显示错价都只有一种原因。
| 网页 / Offer / 商品数据 | 优先调查 |
|---|---|
| 39 / 39 / 29 | 未登录网页输出和上游价格，再查缓存或定时促销 |
| 29 / 39 / 29 | 当前Offer的商品身份和生成来源 |
| 29 / 29 / 39 | Merchant对应数据源、最新处理和覆盖来源 |
| 29 / 29 / 29，展示仍39 | Google记录及展示位置；是否另有旧来源、其他规格或处理未体现 |
商家展示可能结合网站与商品数据等来源。结果外观帮助判断先去哪一个系统查，不能单凭外观断言价格只来自一个来源。最后一行尤其需要保存时间：三层当前值已经一致，接下来查历史抓取和商品处理，不再漫无目的换插件。
如果回报是“价格不匹配”，把该商品的实际落地页、当前选中规格、所用数据源与问题状态放到同一记录里。若换地区才出现旧价，把地区也纳入样本。把这种差异略过去，团队会一直拿不同对象互相证明自己没问题。
把下一次促销改价做成可重复检查
促销上线前，选一个参与活动的商品和一个不参与的商品作对照。沿用蓝色M与红色L：蓝色M按活动规则改价，红色L应保持原报价。分别固定SKU、规格、币种和时段，再查前台、Offer、商品来源及结账条件，才能发现批量规则是否误改了非促销商品。
开始和结束时沿用这两个样本复查。正确对象应在约定时段报价，旧来源不会覆盖新值，客户能按实际看到的条件下单；搜索展示的刷新另记。
交给维护者的记录保留商品身份、观察时间和三层当前值即可。例如“TEE-B-M，USD，未登录页29，Offer39，数据源29”，已经明确指向旧Offer，无须让所有系统重新来一遍。下一次收到旧价反馈，也从同一商品的差异继续查。
继续阅读：谷歌SEO完整优化流程：把内容研究、页面优化与上线复查连起来；谷歌SEO学习路径：按基础概念、核心技能与项目实战继续查教程。
常见问题
清除WordPress缓存后，Google价格就会马上变吗？
不会保证。清缓存解决的是网页当前输出；还需要核对标记、商品来源及相应系统的重新处理状态。
有Merchant自动更新，就不用维护商品来源了吗？
仍然需要。自动更新用于缓解部分不一致，不能替代正常同步。频繁出现旧值时，应查真正负责价格的上游来源。
富结果测试显示通过，为什么搜索里还是旧价？
测试检查当前输入和标记条件，不证明实际搜索展示已经更新。继续核对已抓取记录、商品身份和展示位置，不要只凭通过标志宣布完成。
