What happened

In a Bluesky thread, Google's John Mueller was asked a question every catalog manager eventually faces: when a product's availability reads one way in the server HTML, another way after JavaScript renders, and a third way in the Merchant Center feed, which value wins? His answer: there is "no publicly defined order of precedence for metadata reconciliation" — and that holds across visible content, structured data, sitemaps, and feeds alike.

His advice was blunt: "fix it, not analyze if it'll work regardless." He also flagged that dates carry the same problem — dateModified in your structured data, lastmod in your sitemap, and the date visible on the page can all disagree, and per Mueller these signals "can have different weights & filters" that change over time. Translation: even if you reverse-engineered today's behavior, it would not stay reverse-engineered.

Why this matters

For a store, this is bigger than it sounds, because catalog data drifts constantly. A price change lands on the page but the feed refreshes hours later. An inventory app flips a JavaScript widget to sold out while the server HTML still says available. Schema gets set once at theme build and never touched again. None of that is negligence — it is the normal entropy of running a catalog. Mueller's point is that no hidden reconciliation logic is cleaning it up for you.

The sharper implication sits in his first remark: conflicting metadata makes it "hard to work out what's rel[evant]." Disagreement between your sources is itself a trust signal, and not a good one. A system that cannot tell which of your three availability values is true has every reason to lean less on all of them — and that caution extends beyond classic search, since AI shopping surfaces read the same feeds and the same markup.

Worth some honesty here: Mueller declining to publish a precedence order is also Google keeping its options open. There almost certainly is internal logic. But building your catalog operations on guesses about undocumented behavior is how stores end up debugging phantom ranking issues that are really data hygiene issues. The boring reading is the correct one — consistency is not a best practice, it is the only defined behavior.

What to do about it

Run the three-way check on your top sellers

This week, pull your 20 best-selling products and compare availability and price across three sources: the Merchant Center feed, the live page, and the structured data. On BigCommerce the usual drift is a stale feed after a price change — five minutes in Merchant Center's diagnostics catches most of it.

Diff server HTML against the rendered page

View source on a product page, then compare it to the rendered DOM in your browser's inspector. If an app or script is rewriting price or availability after load, you have two versions of the truth on one URL. Fix the source data so the page does not need post-render correction.

Tighten the feed refresh window

Find out how often your feed actually syncs after a catalog change, and shorten it if price updates or stockouts routinely beat the feed to the page. The gap between page truth and feed truth is where most availability conflicts live.

Audit your dates too

Check that dateModified in your schema, lastmod in your sitemap, and any visible updated-on date agree on pages you actively maintain. Mueller named dates as the same class of problem, and a sitemap that claims everything changed yesterday is the most common self-inflicted version.