Book metadata supplies the titles, contributors, formats, prices, dates, subjects, and rights used in retailer and distributor systems. Accurate data helps readers find and order the intended edition; missing or incorrect data can produce incomplete listings, wrong prices, or mismatched formats. This article explains how metadata travels to retailers such as Amazon and distributors such as Ingram, which fields deserve close review, and where errors arise. If you have a file ready, check it in our free ONIX validator.
How Metadata Shapes Discovery and Product Pages
Retailers build product pages from supplied data such as title, contributor names, cover image, description, subjects, price, and publication date. Search and browse systems also use metadata, although each retailer’s ranking logic is private. The practical point is simple: incomplete data limits what a page can display, while incorrect data can appear directly in the listing.
The Metadata Elements That Matter Most
Title and contributor
The title, subtitle, and contributor names are the strongest identity signals a retailer has. They must match the finished book and stay consistent everywhere.
Description and subject classifications
The description is your sales copy. Subject codes (BISAC or Thema) place the book in browse categories; vague or missing subjects make it harder to find by topic.
Format, price, and dates
Each format—hardcover, paperback, ebook, audiobook—is a separate product record with its own product-level data. A wrong format code or date can delay or misstate a listing.
Territorial rights and supporting resources
Rights data states where a product may be sold. Resources such as cover images and excerpts complete the listing; missing assets can leave a page incomplete.
Why One Book Has Multiple Product Records and ISBNs
A single work may be sold in several formats, each represented by its own product record and identifier. Products assigned ISBNs need distinct ISBNs; some digital products instead use another identifier accepted by the receiver. Hardcover, paperback, EPUB, and audiobook records can carry different prices, dates, rights, and availability. Check every record because a feed-level error can affect more than one product.
How Metadata Moves from Publisher to Retailer
Most publishers keep title data in a central system and distribute it as ONIX for Books, an XML standard maintained by EDItEUR. If the format is unfamiliar, our plain-language guide explains what ONIX is. The feed goes to distributors and wholesalers—Ingram among them—and to retailers, directly or through intermediaries. Each recipient loads updates on its own schedule, and distributors may pass them to the stores and libraries they serve. One feed can therefore supply many downstream storefronts.
Why Retailer Pages May Not Match Your Source Data
When a store page disagrees with your records, the cause is usually mundane. Feeds update on different cycles, so a change you sent last week may still be queued. Some channels accept partial updates and keep older values for fields you omitted. Records can be overwritten when several sources supply the same ISBN, and some parties truncate long descriptions. Cached and regional pages add further delay. None of this requires hidden mechanisms—it is the ordinary friction of many systems copying the same data at different times.
Common Metadata Mistakes and Their Business Costs
These mistakes are retailer-agnostic: they follow from what ONIX fields mean, not from one store’s rules.
- Inconsistent titles or contributor names across formats fragment your presence; editions fail to reinforce each other and readers may not find the version they want.
- Missing or incorrect prices can prevent ordering or display the wrong amount in a market.
- Wrong territorial rights block sales where you hold rights—lost revenue—or expose you to selling where you do not.
- Missing publication or embargo dates can delay listings or release a book earlier than intended.
- Weak subject coding and thin descriptions reduce topical discovery; the book answers fewer searches.
- Missing cover images can leave listings incomplete or delay publication.
Fixes belong in your data and its XML; our ONIX 3 validation guide covers that process.
Why Valid XML Is Necessary but Not Sufficient
Validation answers a narrow question: does this file obey the ONIX grammar? It catches malformed tags, missing required elements, and invalid code values—problems that may cause a recipient to reject or skip data. It cannot judge business accuracy. A file can be perfectly valid and still carry the wrong price, an expired date, or rights that contradict your agreements, and validity never guarantees acceptance by any channel. Treat validation as the first gate, not the last: structure by machine, meaning by review.
A Practical Pre-Submission Checklist
- Confirm every identifier and format pairing. Each sellable product needs a distinct identifier accepted by the receiver. Where an ISBN is assigned, verify it and match the product form code to the actual format.
- Verify titles and contributor names against the finished book. Check spelling, sequence, and roles (author, editor, illustrator) in every record. These fields anchor search and must match everywhere.
- Check prices, currencies, and effective dates per market. Confirm that each intended market has the commercial data required by the receiving channel.
- Review territorial rights against your contracts. Your feed should state only where you may sell each format. Errors can block legitimate sales or expose a product in the wrong territory.
- Confirm publication and embargo dates are current and intentional. Dates control when listings go live and orders open. An overlooked past date can suppress a new release.
- Ensure descriptions, subject codes, and cover images are present. These fields support discovery and give product pages the information readers expect.
How Regular Validation Reduces Preventable Errors
Metadata changes constantly: prices shift, formats launch, rights expand. Validating only before an initial release leaves every later update unchecked. Validating each outgoing feed catches malformed XML before it reaches partners, flags missing required fields while fixes are cheap, and sets a consistent quality bar. It cannot catch wrong business data—only review does—but it removes a class of avoidable rejections. Re-check after every significant correction, not just at launch.
Check Your Files Before You Send
The fastest quality check is a structural one: validate before you send, and again after every correction.