Structured Data untuk Product Feed dan Commerce: Jangan Campur Fungsi

Ada rapat ecommerce yang dimulai dari satu pertanyaan sederhana.

“Kalau Product schema sudah lengkap, masih perlu Merchant Center feed?”

Lalu jawaban cepat muncul:

“Nggak perlu. Datanya sama.”

Sebenarnya tidak sesederhana itu.

Google sendiri mendokumentasikan dua jalur yang berbeda untuk membagikan product data:

Structured data di product pages.

Google Merchant Center product data melalui feed atau API.

Keduanya bisa saling melengkapi.

Mereka bukan fungsi yang sama.

Structured data adalah representasi machine-readable dari content product page.

Merchant Center adalah jalur pengiriman product data langsung ke sistem commerce Google dengan kontrol, cadence, dan surface yang berbeda.

Kalau tim memperlakukan keduanya interchangeable, masalah pertama biasanya muncul di price dan stock.

Website sudah berubah.

Feed belum.

Atau feed sudah berubah.

Schema belum.

Google melihat dua versions.

Commerce data kemudian menjadi synchronization problem.

Apa Fungsi Product Structured Data?

Product structured data hidup di page.

Ia mendeskripsikan product yang user lihat.

Name.

Image.

Brand.

Identifier.

Offer.

Price.

Availability.

Review where appropriate.

Shipping/return details dalam contexts yang didukung.

Variants.

Google Search Central mengatakan Product structured data dapat membantu Google memahami product page dan meningkatkan eligibility untuk product rich results.

Structured data juga dapat membantu akurasi Google memahami price, discount, shipping cost, serta membantu verifikasi Merchant Center feed terhadap website.

Important:
It describes page.

It should match visible content.

Jika price di markup beda dari visible page:
problem.

Jika availability beda:
problem.

Structured data tidak seharusnya menjadi private commerce database tersembunyi.

Apa Fungsi Merchant Center Feed?

Merchant Center menerima product data langsung.

Title.

Description.

Price.

Availability.

Identifiers.

Images.

Shipping.

Tax in relevant contexts.

Store availability and other commerce fields depending program/setup.

Google menjelaskan feed memberi seller greater control terhadap timing update dan membantu Google mengetahui product inventory lebih lengkap karena crawling website tidak menjamin semua product ditemukan.

Untuk site dengan frequently changing content, Google menyarankan periodic feed uploads atau API-based updates untuk cadence yang lebih cepat.

Google juga mencatat ada data tertentu yang mungkin tidak appropriate ditampilkan di website, misalnya physical-store-level inventory, tetapi dapat dibagikan melalui Merchant Center.

Ini fundamental difference.

Feed bukan sekadar copy JSON-LD.

It is commerce data channel.

Shopping Tab Menunjukkan Perbedaan Paling Jelas

Google Search dapat menggunakan Product structured data untuk product rich results.

Merchant Center data juga bisa dipakai untuk product experiences.

Tetapi Google menyebut participation in Merchant Center mandatory untuk beberapa surfaces seperti Google Shopping tab.

Artinya structured data page tidak menggantikan Merchant Center di semua experience.

Ini platform fact.

Jangan membuat architecture hanya berdasarkan satu channel.

Commerce team perlu tahu target surfaces.

Search.

Images.

Shopping.

Lens.

Free listings.

Ads.

Local inventory.

Each may have specific requirements.

Schema is one layer.

Feed is another.

Product Database adalah Source-of-Truth Ketiga

Ideal architecture:

PIM/ERP/commerce database.

→ visible product page.

→ Product JSON-LD.

→ Merchant Center feed/API.

Three outputs.

One truth source.

Price:
same source.

Stock:
same source.

SKU:
same.

GTIN:
same.

Brand:
same.

Variant:
same.

Now synchronization easier.

Bad architecture:

Page price:
WordPress.

Schema price:
SEO plugin custom field.

Merchant feed:
Google Sheet.

Inventory:
ERP.

One product.
Four data sources.

Eventually conflict.

Commerce schema project should start with data architecture.

Not markup.

Skenario yang Biasa Terjadi Jumat Sore

Operations:
“Stock SKU 882 habis.”

Website:
Out of stock.

Feed:
Still in stock.

Schema:
OutOfStock.

Merchant Center:
InStock until next scheduled feed.

Customer clicks commerce surface.

Product unavailable.

This is exactly the update-delay problem Google documents.

Google notes discrepancies can occur when website and Merchant Center feed updates lag, and suggests using automatic item updates based on website data where appropriate to help reconcile price/availability.

But don't rely solely on reconciliation.

Primary source should sync.

Feed cadence matters.

Structured data is not real-time API by magic.

Crawl timing exists.

Structured Data Tidak Cocok untuk Data yang Tidak Ada di Page

Suppose warehouse has:

Stock by store.

Procurement cost.

Margin.

Supplier.

Internal lead time.

Personalized price.

Don't dump into JSON-LD because commerce team wants “rich data”.

Google general structured-data guidelines say content represented by markup should match visible page and not be misleading/hidden.

Merchant Center can accept some commerce data that isn't appropriate to display publicly, depending supported attributes/program.

Different channel.

Different contract.

Public schema:
page representation.

Feed:
merchant data submission.

Internal:
business operations.

Don't mix.

Offer Bukan Inventory System

Offer structured data can express current availability.

But do not treat JSON-LD as inventory database.

Inventory changes per minute.

Page generator can output current state.

Fine.

But source must be inventory system.

If schema hardcoded:
stale.

If cache:
stale.

If CDN:
stale.

Commerce pages need caching strategy.

Offer JSON-LD should update with visible availability.

No secret stock count if page doesn't show.

Machine-readable accuracy follows operational system.

Product Feed Bukan Replacement untuk Good Product Page

Merchant Center can have rich product attributes.

But user eventually lands on website.

If landing page:

Slow.

Price mismatch.

Variant unavailable.

No returns info.

No product details.

Feed cannot rescue experience.

Google also verifies feed data against site.

Commerce success requires page and feed alignment.

Product content:

Clear title.

Images.

Specs.

Variants.

Price.

Stock.

Shipping.

Returns.

Merchant identity.

Structured data mirrors.

Feed transmits.

Different layers.

Product Structured Data Bukan Feed untuk Semua AI Agents

Another 2026 misconception:

“JSON-LD Product = universal AI commerce feed.”

No.

Schema.org provides common semantics.

Some systems may consume.

Others use search index, platform feed, API, merchant integrations, or proprietary catalogs.

Do not assume universal ingestion.

If building agent-ready commerce:

Stable product IDs.

API/feed.

Current offers.

Authorization.

Inventory.

Order interface.

Product structured data can support public discovery/understanding.

Not transaction infrastructure by itself.

Don't promise:
“Add Product schema and agents can buy.”

Agentic commerce needs more.

Variant Relationship Harus Konsisten Across Page dan Feed

ProductGroup.

Variant SKU.

Color.

Size.

GTIN.

If website groups variants one way and feed another, reconciliation becomes messy.

Example:

Website:
Black size 40 = SKU A.

Feed:
Black 40 = SKU B.

Merchant system may treat duplicate/different product.

Product IDs should originate PIM.

Page.

JSON-LD.

Feed.

Same.

In article 246 we discussed graph.

Here commerce implication:
identity errors become catalog errors.

Structured data and feed should not invent separate identities.

Price Format and Currency

Visible:
Rp1.499.000.

Structured:
price 1499000.
priceCurrency IDR.

Feed:
same.

If feed uses USD due default locale:
serious.

Multi-country:
price per market.

Do not use global schema value on local page if user sees local price.

Currency mismatch is semantic failure.

Product data needs market context.

Commerce feed may have country-specific settings.

Page must align.

Availability Needs Shared Definition

What counts `InStock`?

At central warehouse?

Available for online purchase?

Store stock?

Preorder?

Backorder?

Different.

Define.

If website says “available in selected stores” but schema says InStock for ecommerce offer, potentially misleading.

If Merchant feed has local inventory, distinguish.

Commerce terms have operational meaning.

Data governance needs mapping.

No SEO person should guess inventory semantics.

Operations owns.

Return Policy and Shipping Show Channel Difference

Google supports merchant return policy and shipping policy structured data in contexts documented for merchant listings/Organization.

Merchant Center also has corresponding data/config paths.

Which source should own?

Central policy registry.

Visible policy page.

Structured representation.

Merchant settings.

If return policy changes:
update all.

Don't hand-edit three systems.

Policy mismatch causes customer disputes.

This is why schema governance crosses legal/operations.

Not just search.

Product Reviews and Editorial Reviews Jangan Dicampur

Product page:
customer reviews.

Editorial product review article:
review of product.

Google Product documentation distinguishes merchant listings and product snippets, including editorial review contexts.

Don't mark editorial article as merchant product offer if no purchase.

Don't mark merchant page as independent editorial review.

Entity same Product.

Page purpose different.

Structured data should reflect.

Commerce architecture often has both:

Product detail.

Review content.

Comparison.

Category.

Each has different main type.

Feed only for sellable products.

Don't send editorial page as product landing feed.

Canonical destination matters.

Product Feed Can Carry More Frequent Updates

Google documentation states feed files can be sent weekly, daily, or hourly, and API mechanisms can support immediate updates in some contexts.

That is operational benefit.

Web crawling does not guarantee instant processing.

If stock moves fast:
feed/API matters.

Structured data update may be immediate on page, but consumer must crawl.

This does not mean feed is always fresher.

Bad feed process can still be stale.

Architecture:
source-of-truth + deliberate cadence.

Not channel mythology.

Small Store vs Large Catalog

Small shop:
50 products.
Stock changes slowly.

Website structured data + automated feed may be enough.

Large marketplace:
1 million SKUs.
Price changes.
Inventory by region.

Need robust feed/API, PIM, monitoring.

Structured data still important on landing pages.

But don't try to turn HTML crawl into primary catalog synchronization.

Scale determines channel.

Google itself notes larger/frequently changing sites benefit from periodic feed files or API updates.

This is a practical design rule.

Monitoring Must Compare All Three

Product page.

JSON-LD.

Merchant Center.

For sample SKUs compare:

ID.

Title.

Brand.

GTIN.

Price.

Currency.

Availability.

Variant.

Shipping.

Return.

Image.

URL.

If mismatch:
flag.

Automate.

High-volume stores cannot manually check.

Build commerce data QA.

When feed disapproval appears, trace source.

When rich result wrong, compare.

When customer sees wrong stock, operations.

One dashboard.

Three projections.

Do Not Generate Product JSON-LD from Feed if Page Is Different

Temptation:

Merchant Center has rich data.

Use it to inject schema.

But if page doesn't display same facts, Google structured-data guideline issue.

Better:
both draw from same PIM.

If feed has private store inventory, don't inject.

Public structured data follows page.

Shared source doesn't mean identical fields.

Projection matters.

This mirrors internal vs public knowledge graph.

Same data platform.

Different views.

AI Search and Commerce

Generative search may mention products without clicks.

Agents may compare.

Search engines may show enriched product information.

Product identity and current offer data become more important.

But separate outcome metrics.

Schema coverage:
technical.

Feed approval:
commerce.

Product visibility:
search.

AI mention:
generative.

Conversion:
business.

Do not create one score.

A page can have perfect schema but feed disapproved.

Feed perfect but AI never mentions.

AI mention high but product unavailable.

Different failure modes.

Team structure should reflect.

What Should Own Product Truth?

PIM or commerce DB.

Not SEO plugin.

SEO plugin can serialize.

Merchant connector can transmit.

Page can render.

But truth originates product system.

This is the cleanest answer.

If company doesn't have PIM:
even a central product table can serve.

Important:
one owner.

Product team.

Commerce ops.

Not five spreadsheets.

Structured data then becomes output.

Feed output.

No reconciliation by humans every day.

When Should Data Exist in Both?

If visible product fact is important and supported by both channels:

Price.

Availability.

Brand.

Identifiers.

Product title.

Image.

Variant.

Then consistency important.

If feed-only operational field:
keep feed.

If page-only editorial content:
keep page/schema only if structured relevance.

Don't force symmetry.

Different channels have different schemas.

Alignment is about overlapping facts.

Not identical data dumps.

Final Rule: Jangan Campur Fungsi

Product page:
explains and sells.

Structured data:
describes what is on page.

Merchant feed/API:
submits catalog/commerce data directly.

Internal PIM:
owns product truth.

Merchant Center:
commerce distribution/control.

AI/search:
external consumers.

When each layer has clear function, maintenance gets easier.

When they are mixed:

Schema becomes inventory feed.

Feed becomes CMS.

CMS becomes PIM.

SEO team manually fixes price.

Operations edits JSON-LD.

That's when Friday night incident begins.

A healthy commerce stack doesn't ask which one replaces which.

It asks how each projection stays synchronized to the same product reality.