Structured Data para sa Product Dimensions: Blangko Pa Rin

Ang structured data para sa product dimensions ay ang parte ng listing mo na walang matang nakakabasa — at siya na ngayon ang nagdedesisyon kung lalabas pa ba talaga ang produkto mo sa isang sagot. Nilagay mo ang 600 × 320 × 720 mm sa spec image. Nababasa iyon ng shopper. Ang crawler, ang shopping feed, at ang assistant na sumasagot sa "anong wall cabinets ang mas manipis sa 350 mm ang depth?" ay walang nababasa, kasi pixel lang ang anyo ng numerong iyon.

Ang structured data para sa product dimensions ay ang machine-readable na deklarasyon ng pisikal na sukat ng produkto: mga pinangalanang field na may numeric value at malinaw na unit, inilalabas bilang JSON-LD sa product page o bilang mga column sa isang merchant feed. Tatlong magkahiwalay na spec ang nagde-define ngayon ng mga field na iyon, hindi tugma ang pangalan nila sa isa't isa, at karamihan sa mga katalogo ay wala talagang nilalagay sa kahit isa.

Narito ang buong block, field by field, at may copy-paste na bersyon sa dulo.

Structured data para sa product dimensions: tatlong spec na bumabasa ng sukat mo

Basahin mo nang dalawang beses ang huling row, kasi nandoon ang bitag na nahuhulugan ng halos lahat ng katalogo.

Kahon mo ang inilalarawan ng dimension fields ng Google, hindi ang produkto mo

Optional ang shipping_length, shipping_width at shipping_height, tumatanggap ng sentimetro o pulgada, at nakakulong sa 1–400 cm o 1–150 inches. Malinaw ang sabi ng Google kung para saan sila: nandiyan sila para tumulong itakda ang shipping cost kapag carrier-calculated ang method mo. Kailangang sabay na ibigay ang tatlo at pareho ang unit, kung hindi ay hindi na talaga magagamit ang data.

Kaya carton ang inilalarawan nila. Wala talagang attribute sa Merchant Center para sa sariling dimensions ng tapos nang produkto.

Kaya nga mas mahalaga sa iyo ang product_detail kaysa sa kahit anong field sa page na ito. Dito napupunta ang technical specifications na hindi kayang saluhin ng ibang attribute, sa tatlong-parteng format na hinahati ng eksaktong dalawang tutuldok:

section_name : attribute_name : attribute_value

Optional pero recommended ang section_name; required ang attribute_name at attribute_value. Ang mga halimbawa mismo ng Google ay sumusunod sa hugis na Display:Size:13 inch at Battery:Capacity:12.5 hours. Ibig sabihin, ganito ang tamang tirahan ng totoong sukat ng produkto sa isang Google feed:

Dalawang rule para manatiling malinis ito. Ilagay ang unit sa loob ng attribute_value — free text ang field at walang kuwenta ang hubad na "600". At huwag na huwag uulitin ang kahit anong may sariling attribute na: sinasabi ng Google na huwag mong i-duplicate ang impormasyong nasa iba nang lugar, at bawal talaga dito ang presyo o ang timing ng delivery.

schema.org: ang apat na field plus ang isang walang gumagamit

Sa page mismo, binibigyan ng schema.org ang Product ng direktang dimension properties, at tumatanggap ang bawat isa ng Distance o QuantitativeValue:

• width — "Ang lapad ng item."
• height — "Ang taas ng item."
• depth — "Ang lalim ng item."
• weight — isang Mass o QuantitativeValue.

Tapos may size, ibang klase ng field ito at palaging namamali ang gamit. Pinapayagan ng definition nito ang plain text string na tipong XL o 32Wx34L, isang QuantitativeValue na may unitCode, o buong SizeSpecification — at diretsahang sinasabi nito na kapag hindi kasya ang mga iyon, "maaaring mas angkop ang width, height, depth at weight properties." Ang ibig sabihin niyan para sa lahat ng hindi damit ang tinitinda: gamitin ang size para sa sizing system ng damit, gamitin ang apat na dimension properties para sa pisikal na produkto, at huwag ilagay ang 600x320x720 sa size bilang string.

Ang field na walang gumagamit ay ang hasMeasurement, isang QuantitativeValue sa Product na para sa mga sukat ng item — ang mga halimbawa mismo ng schema.org ay ang inseam ng pantalon, ang laki ng gulong ng bisikleta, at ang gauge ng turnilyo. Tumatanggap ito ng array, kaya dito napupunta ang lahat ng secondary na dimension: lapad ng shelf sa loob, taas ng upuan, distansya ng fixing points, bukana, pitch ng thread. Ito ang mga numerong ini-email sa iyo ng mga buyer, at may standard field na para sa kanila na blangko sa halos lahat ng katalogo.

Para sa unit, ang unitCode ay kumukuha ng 3-character common code ng UN/CEFACT — MMT milimetro, CMT sentimetro, INH pulgada, KGM kilo, LBR pound. Kung hindi ka sigurado sa code, valid ang unitText na may plain string at mas mabuti pa iyon kaysa sa maling code.

Copy-paste: ang JSON-LD dimension block

Ilagay ito sa loob ng existing na Product node mo. Pumapasa sa validation, kumpleto, at sadyang pinaghihiwalay ang sukat ng produkto sa sukat ng carton.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wall cabinet, 2-door, 600 mm",
  "sku": "WC-600-2D",
  "material": "Birch plywood, white melamine",
  "width":  { "@type": "QuantitativeValue", "value": 600, "unitCode": "MMT" },
  "height": { "@type": "QuantitativeValue", "value": 720, "unitCode": "MMT" },
  "depth":  { "@type": "QuantitativeValue", "value": 320, "unitCode": "MMT" },
  "weight": { "@type": "QuantitativeValue", "value": 14.2, "unitCode": "KGM" },
  "hasMeasurement": [
    { "@type": "QuantitativeValue", "name": "Internal shelf width",
      "value": 564, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Wall fixing centres",
      "value": 512, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Carton, longest side",
      "value": 760, "unitCode": "MMT" }
  ]
}

Pareho ang numerong hinahanap ng ChatGPT feed, iba lang ang pangalan

Ang product feed spec ng Agentic Commerce — ang file na pinu-push ng mga merchant para sa shopping surfaces ng ChatGPT — ay tumatanggap ng dimensions sa dalawang paraan, at mahigpit ang dependency rules:

Sinasabi ng spec na ang pisikal na katangian at klasipikasyon ay nakakatulong sa categorization, filtering at search relevance — malinaw na pahayag iyon na ang produktong walang dimensions ay produktong hindi kayang i-filter papasok sa isang result set. Kapag may shopper na naghahanap ng cabinet na mas manipis sa 350 mm ang depth at blangko ang depth field mo, hindi ka mababa ang ranggo. Wala ka doon.

Isang tapat na butas: wala ring hiwalay na package-dimension field sa spec, at hindi nito sinasabi kung produkto ba o carton ang ibig sabihin ng dimensions. Ideklara mo kung alin ang tinutukoy mo, sa lugar na kayang basahin ng tao at ng model, at maging consistent sa buong katalogo mo.

Bakit sulit pang punuan ang mga field na ito kahit hindi ipapakita ng Google

Parang kontradiksyon ang parteng ito. Ang sariling dokumentasyon ng Google para sa Product structured data, ang naglilista ng kung anong nagbibigay sa iyo ng rich result, ay hindi kasama ang width, height, depth, weight o hasMeasurement. Ang supported list nito ay presyo, availability, review ratings, shipping, return policy, sizing ng damit, identifiers, at pros and cons.

Kaya hindi magdodrowing ng mas malaking snippet ang dimension markup. Hindi naman talaga iyon ang trabaho niya kahit noon pa.

Ang nagbago ay ang bumabasa. Sabi ng Google, ang product_detail ay nagbibigay ng structured data na tumutulong sa kanilang maintindihan at maipakita ang mga produkto sa iba't ibang surface, kasama ang AI-driven features gaya ng AI Mode sa Search; ang Agentic Commerce feed naman ay nandiyan para matagpuan at ma-filter ang produkto sa loob ng isang chat. Hindi kailangan ng mga sistemang iyon ng visual template para umandar — kailangan nila ng attribute na maikokompara sa isang constraint. Hindi na dekorasyon sa search result ang dimension field. Siya na ang nagpapasa sa iyo para makuha ka ng retrieval.

Kaya nagbabago ang priority: punuan ito para sa mga engine na sumasagot ng tanong, hindi para sa mga nagdodrowing ng kahon.

Ang rule na sumisira sa lahat: isang numero, dalawang lugar

Lahat ng pagkakamaling nakita ko sa structured data para sa product dimensions ay galing sa isang ugat — iba ang sinasabi ng feed, iba ang sinasabi ng image.

Nangyayari ito nang walang masamang intensyon. May nag-type ng sukat ng carton sa shipping_width, iba ang nag-measure ng buo nang unit para sa spec diagram, pangatlong tao ang nag-round ng 564 mm papuntang 56 cm sa product_detail. Ngayon, kumpiyansang sinasabi ng isang assistant sa shopper na 640 mm ang lapad ng cabinet, tinitingnan naman ng shopper ang image mo na nagsasabing 600, at may ginawa ka nang problema sa tiwala plus isang return. Mas malala, ang numerong binabasa ng makina ang siyang naisisipi, kasi iyon ang nabasa.

Proseso ang solusyon, hindi markup: isang beses lang mag-measure, tapos ilabas ang parehong sukat na iyon sa field at sa image. Konkretong hakbang —

1. I-measure ang tapos nang item, hindi ang drowing at hindi ang carton, at itala kung alin sa dalawa ang tinutukoy ng bawat numero.
2. Ilagay ang bawat numero sa image katapat ng feature na inilalarawan nito — nakadikit sa totoong gilid ng produkto, hindi lumulutang malapit doon — at i-export sa spec-diagram size ng bawat platform. Deterministiko itong ginagawa ng software na talagang ginawa para sa dimension annotation, at iyon ang buong pinagkaiba nito sa pangkaraniwang photo editor kung saan kamay mo ang naglalapag ng arrow, o sa image generator, na masayang magre-render ng dimension na hindi naman nito nasukat, kasi ang ino-optimize niya ay ang mukhang kapani-paniwala.
3. Kopyahin ang parehong numero sa width/height/depth, product_detail at sa dimension fields ng feed. Isang source, isang rounding, isang unit.
4. Kapag nagbago ang isang numero, palitan ito sa dalawang lugar sa isang commit lang. Mas malala ang magkaibang pares kaysa sa nawawalang isa.

Nasa case study ng product size labels ang aktuwal na halimbawa ng image na kalahati ng pares na iyon, at nasa product dimensions sa cm o inches ang tanong sa unit na nakakatalisod sa kalahati ng mga exporter.

Checklist bago mag-publish

• Nasa Product node ang width, height, depth, bawat isa ay QuantitativeValue na may unitCode o unitText
• May weight at may kasamang unit
• Bawat secondary na dimension na totoong itinatanong ng buyer ay nasa hasMeasurement na may deskriptibong name
• size ay para lang sa sizing system ng damit — walang 600x320x720 na string
• Feed: kumpleto ang shipping_length / shipping_width / shipping_height, pareho ang unit, at carton ang inilalarawan
• Feed: nasa product_detail ang dimensions ng buo nang produkto, nasa loob ng value ang unit, eksaktong dalawang tutuldok kada entry
• Feed: walang duplicate na data na may sariling attribute na; walang presyo o timing ng delivery sa loob ng product_detail
• Agentic feed: dimensions kasama ang unit nito, o length+width+height plus dimensions_unit
• Agentic feed: kailanman ay hindi ipapadala ang weight na walang item_weight_unit
• Magkaiba ang label ng product dimensions at carton dimensions saanman sila lumitaw
• Bawat numero sa markup ay tugma sa numerong nakaprint sa spec image, hanggang sa milimetro
• May isang pinangalanang may-ari ng pagtutugmang iyon, kaya walang mag-e-edit ng isang panig lang

FAQ

Paano magdagdag ng product dimensions sa structured data?

Ilagay ang width, height, depth at weight sa Product node mo sa JSON-LD, bawat isa ay QuantitativeValue na may numeric na value at unitCode. Idagdag ang lahat ng iba pang nasusukat na feature bilang entries sa hasMeasurement na may deskriptibong name. Sa Google feed, nasa product_detail ang tamang lugar ng sukat kapag buo na, hindi sa mga shipping_* field.

Ginagamit ba ng Google ang width, height at depth mula sa Product schema?

Hindi para sa rich results. Ang supported product properties ng Google ay presyo, availability, reviews, shipping, return policy, sizing ng damit, identifiers, at pros and cons — wala sa listahang iyon ang pisikal na dimensions. Mahalaga pa rin sila para sa retrieval at paghahambing sa mga AI-driven surface, at ibang trabaho iyon na mas malaki pa ngayon.

Ano ang pagkakaiba ng shipping_length sa totoong sukat ng produkto?

Ang shipping_length, shipping_width at shipping_height ay naglalarawan ng shipping package, at nandiyan para makuwenta ang carrier-calculated na rates. Hindi ito ang tapos nang dimensions ng produkto at hindi dapat ilagay doon iyon. Walang dedicated attribute ang Merchant Center para sa sukat kapag buo na, at iyon ang dahilan kung bakit product_detail ang tamang lugar nito.

Anong unit codes ang dapat gamitin para sa dimensions sa JSON-LD?

Ang unitCode ay kumukuha ng 3-character common code ng UN/CEFACT — MMT para sa milimetro, CMT sentimetro, INH pulgada, KGM kilo, LBR pound. Kung hindi ka sigurado sa code ng isang unit, gamitin na lang ang unitText na may plain string; mas mabuti ang nababasang unitText kaysa sa maling unitCode.

Kailangan pa ba ng dimensions sa product image kung nasa feed na?

Oo, at simetriko ang dahilan. Fields ang binabasa ng makina at hindi nila kayang basahin ang image mo; image ang binabasa ng buyer at hindi nila bubuksan kailanman ang feed mo. Image ang dimension diagram mo, at teksto ang binabasa ng bawat sistemang nagdedesisyon kung lalabas ba ang produkto mo sa isang sagot — kaya ipadala ang dalawa, at pagtugmain sila hanggang sa milimetro. Nasa paano ipaliwanag ang product dimensions sa mga buyer ang paraan ng pagbabalangkas sa parteng image para talagang kumilos ang buyer; kung gusto mong malaman sa pera ang halaga ng pagkakamali, ang return cost calculator ang gagawa ng kuwentang iyon.

Mga Sanggunian at Reperensya

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode at unitText
• Google Merchant Center — shipping dimension attributes at ang mga limitasyon nila
• Google Merchant Center — product detail [product_detail] attribute
• Google Search Central — Product structured data at ang mga supported properties
• Agentic Commerce — product feed specification