PDP (product detail page)
A PDP is the page dedicated to a single purchasable product — one SKU, or one parent with its variants — carrying the identifiers, attributes, images, documents, and price a buyer needs to decide. Every category page, facet, feed row, and marketplace listing is assembled from what PDPs declare. A PDP is only as good as the product data behind it.
What a PDP actually is
A PDP is the destination page for one thing a buyer can put in a cart. It sits below the category page and the search results page in site architecture: the category page is a list of candidates, the PDP is where the decision gets made.
Almost everything else in the catalog is derived from it. Facets on the category page are built from PDP attributes. A Google Shopping feed row is a flattened PDP. An Amazon flat file row is a PDP. The answer an LLM gives about your 3/8-16 Grade 8 hex bolt is a compressed PDP.
So when a merchandising team says "we have 60,000 SKUs," what they mean operationally is 60,000 PDPs — each one either answering a buyer's question or sending them to a competitor who answered it.
The page itself is cheap. Your ecommerce platform renders it from a template in milliseconds. What is expensive is the data the template needs, which is why most catalogs have complete PDP shells and incomplete PDP content.
What belongs on a B2B PDP
A consumer PDP can survive on lifestyle photography and a paragraph of copy. A B2B PDP cannot. The buyer is specifying a part, and every field is either a spec they filter on or a spec they call your rep to ask about.
Here is the anatomy, using a UL listed 600V wire connector as the example:
| PDP element | What it does | Example value |
|---|---|---|
| Title | Names the part the way a buyer searches for it | Twist-on wire connector, 600V, UL listed, orange |
| GTIN | Global identifier; keys marketplace and GDSN matching | 00812345678901 |
| MPN | The manufacturer's part number; how buyers cross-reference | WC-341-OR |
| Category path | Places the SKU in the taxonomy that drives facets | Electrical > Wire Management > Wire Connectors |
| Technical attributes | The filters, and the answer to "will this work?" | Wire range 22-16 AWG; max voltage 600V; temp rating 105°C |
| Compliance | Gates the purchase in regulated categories | UL 486C listed; RoHS compliant |
| UOM and pack | Prevents ordering 100 when they wanted 100 boxes | Each; 100/box; 10 boxes/case |
| Images | Proves it is the right part | Product on white, in-use shot, packaging shot |
| Documents | Closes the spec question without a phone call | Spec sheet PDF, UL certificate |
| Structured data | Makes the page machine-readable | Product JSON-LD with gtin13, mpn, offers |
The pattern underneath: identifiers make the PDP findable, attributes make it filterable, documents and images make it trustworthy, and structured data makes it quotable.
Why completeness turns into conversion and citations
Two things happen on an incomplete PDP, and both are invisible in your analytics.
The first is filter exclusion. If the wire range attribute is blank, the SKU never appears when a buyer facets to 22-16 AWG. There is no bounce to measure, because there was no session. The PDP was eliminated before it ever loaded.
The second is the unanswered question. The page loaded, the buyer scanned for a temperature rating, found nothing, and left. You logged a visit and a non-conversion, which reads like a pricing problem or a demand problem. It was a data problem.
AI answer engines apply the same logic, harder. When someone asks an assistant for a 600V connector rated to 105°C, the model matches against explicit attribute values it can find in your markup and copy. It does not infer a temperature rating from a hero image. Pages that state their specs get cited; pages that imply them do not.
This is why attribute fill rate is a commercial metric, not a hygiene metric. Every empty cell is a filter you are absent from and a question you are not answering.
PDP vs. the pages and records around it
The word gets used loosely. These distinctions matter once you are scoping work:
| Term | What it is | Relationship to the PDP |
|---|---|---|
| PDP | The rendered page for one product | The output |
| SKU | The stock-keeping record you sell and count | Usually 1:1 with a PDP, sometimes many-to-one under a parent |
| Category page / PLP | The list page a buyer browses | Built from PDP attributes; links to PDPs |
| PIM record | The stored, governed product data | The source the PDP renders from |
| Feed row | A flattened export to Google, Amazon, or a punchout catalog | A subset of the PDP, reshaped per spec |
| A+ content | Marketplace-hosted enhanced marketing modules | Lives on the marketplace listing, not your PDP |
One practical consequence: fixing a PDP means fixing the PIM record behind it, not editing the page. Patch a spec in the CMS and the feed still ships the old value, the punchout catalog still returns it, and the marketplace listing stays wrong.
Where PDPs break, and what fixing them takes
PDPs rarely fail all at once. They degrade in predictable ways:
- New item setup rush. The SKU goes live with title, price, and one image so it can be ordered. The attributes are "phase two." Phase two never gets scheduled.
- Supplier data taken as-is. The manufacturer sent a quarter of the attributes your category needs, in their units, under their category names. Nobody normalized it.
- Long-tail neglect. The top 500 SKUs get merchandiser attention. The other 59,500 get a template.
- Taxonomy drift. The category gained an attribute; every SKU that existed before it stays blank forever.
- Silent staleness. The spec sheet was revised. The PDP wasn't.
These persist not because teams don't care, but because completing a PDP properly means reading a spec sheet, extracting values, converting units, mapping to your taxonomy, and validating against a rule set — per SKU, across tens of thousands of SKUs. That is real work, and it does not happen by itself.
Worth being clear about the split. Your PIM stores product data, governs it, and syndicates it. It does not go find the temperature rating for a connector where the field is blank. Anglera does that work: reading manufacturer PDFs and supplier sites, extracting and normalizing values, routing the uncertain ones to a human reviewer, and writing complete records back into Akeneo, Salsify, Syndigo, inriver, or Pimberly. The PIM stays the system of record. The PDPs stop being half-empty.
Frequently asked questions
What does PDP stand for in ecommerce?
PDP stands for product detail page — the page dedicated to a single purchasable product. It carries the title, identifiers like GTIN and MPN, technical attributes, images, documents, price, and availability. It is distinct from a PLP (product listing page, or category page), which is the browsable list of candidate products that links out to individual PDPs.
What is the difference between a PDP and a SKU?
A SKU is the record you stock, price, and count in your ERP or PIM. A PDP is the page a buyer sees. Usually one SKU maps to one PDP, but variant structures break that: a parent PDP for a hex bolt may cover twelve child SKUs across lengths and finishes, with the buyer selecting a variant on the page. The SKU is the record; the PDP is the presentation.
What should a B2B product detail page include?
At minimum: a searchable title, GTIN and MPN, a category path matching your taxonomy, the full technical attribute set for that category (wire range, voltage, temperature rating, thread pitch — whatever buyers filter on), unit of measure and pack quantity, compliance claims such as a UL listing, product imagery, spec sheet PDFs, and Product JSON-LD markup so machines can read the same facts.
How do PDPs affect AI search and LLM answers?
Answer engines extract explicit attribute values from your page copy and structured data, then match them against the buyer's question. If a temperature rating exists only inside a linked PDF or an image, it usually isn't retrievable. Stating specs plainly in the page body, in a spec table, and in Product schema markup is what makes a PDP quotable in an AI answer rather than skipped.
Why are so many PDPs incomplete?
Because completing one is manual work that doesn't scale. Suppliers send partial data in their own units and category names. New SKUs go live with the minimum needed to transact. Merchandisers cover the top few hundred products and the long tail gets a template. A PIM will show you which fields are blank and enforce rules against them, but it won't go find the missing values.