Book metadata is the information retailers use to build your product pages and decide when your books surface in search and browse results. When that data is accurate and complete, readers find the right edition at the right price. When it is wrong or missing, you lose sales to broken pages, incorrect pricing, or mismatched formats. This article explains how metadata travels from your system to stores like Amazon and distributors like Ingram, which fields matter most, and the mistakes that cost publishers money. If you have files ready, check them in our free ONIX validator.
How Metadata Shapes Discovery and Product Pages
Retailers do not write your listing by hand. They build product pages from the data you supply: title, author names, cover image, description, subject categories, price, and publication date all come from your feed. Search and browse features query the same data; a customer filtering by topic, format, price, or release date is searching metadata fields, not reading the book. No outsider knows a retailer’s internal ranking systems, and we will not speculate about them. What is observable is simpler: incomplete data gives a page less to work with, and errors appear on the live 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 with its own price and dates. A wrong format code or mis-set date can suppress a listing.
Territorial rights and supporting resources
Rights data states where you may sell. Resources such as cover images and excerpts fill out the page; a missing cover delays listings at many channels.
Why One Book Has Multiple Product Records and ISBNs
A single work usually exists in several formats, and each needs its own ISBN because each is a separately orderable product. Hardcover, paperback, EPUB, and audiobook editions are distinct records with distinct prices, dates, and availability; retailers display them separately and often link them on one page. Revised editions get new ISBNs. This is normal, but an error is rarely isolated: a mistake in one record does not corrupt the others, and fixing one does not fix the rest.
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 your data into its own systems on its own schedule, and distributors pass it downstream to the stores and libraries they serve. One file can therefore surface on dozens of 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 stop sales outright: a record without a current price for a market usually cannot be ordered there until corrected.
- 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 stall page creation across many channels.
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—the errors that get feeds rejected. 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 ISBN and format pairing. Each sellable format needs its own correct ISBN, and the product form code must match the actual format. A mismatch can list a product that does not exist.
- 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. Every territory you sell in needs a current, correctly coded price; stale or missing prices halt ordering.
- Review territorial rights against your contracts. Your feed should state only where you may actually sell each format. Errors here cost revenue or create legal exposure.
- 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 drive topical discovery and complete the page. Thin records underperform even when everything else is correct.
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.