A Drupal product catalog without Commerce: data first

Not every manufacturer needs an online store. If you sell through distributors or a sales team, your website may need to explain products, help buyers compare specifications, and turn questions into sales conversations. A Drupal product catalog without Commerce can support that job without adding a shopping cart, checkout, or online payments.

The starting point is structured product data. Specifications, dimensions, materials, families, variants, images, and supporting documents belong in records that Drupal can reuse across pages and other outputs. PDFs can still serve buyers, but they don’t have to carry the entire catalog.

That distinction matters for people and AI assistants. Both need to find the right product, understand its attributes, and distinguish one variant from another.

In this article:

• Start with the buyer’s task, not a checkout
• Model products as records with clear relationships
• Give attributes, families, and variants a shared vocabulary
• Let components arrange data rather than duplicate it
• Build listings and filters around real selection criteria
• Generate product documents from the same records
• Make product facts accessible to AI assistants
• Add Commerce when the sales process calls for it
• Plan a catalog that your team can keep current

Start with the buyer’s task, not a checkout

Suppose a manufacturer sells industrial pumps through distributors. Its buyers need to identify pumps suitable for a particular fluid, check dimensions and operating limits, download technical documentation, and ask about availability.

The website’s main action might be “Request a quote” or “Find a distributor.” Neither requires an order system.

A useful product page would show:

• A stable product identifier and model name.
• A description of the intended application.
• Technical specifications with units.
• Available variants and the differences between them.
• Images, drawings, manuals, and certificates.
• A contact action that carries the product or variant identifier into the inquiry.

This is a publishing and product-selection problem. Treating it as an online store adds concepts the team may never use, along with configuration, testing, and maintenance work.

Start with the catalog. Let the sales process determine whether transactions belong on the website later.

We also cover product management on manufacturer websites in How to Effectively Manage Product Data on a Drupal Website for Manufacturers?

Model products as records with clear relationships

Structured records reduce repeated editing. When a dimension changes, the team can update its source field instead of finding every page, comparison table, and document where someone copied the number.

In Drupal, “entity” doesn’t automatically mean custom development. A node is already a content entity. A Product content type with typed fields can be a practical foundation for a catalog.

A starting model for the pump manufacturer might look like this:

Use taxonomy terms for shared classifications such as material or application. Media entities can hold documents and images with metadata, letting editors reuse an asset rather than upload separate copies for each page.

A family may be a taxonomy term if it mainly groups products. If it needs extensive editorial content, approval steps, or a distinct page structure, a separate content type may fit better.

Choose custom content entities when the domain behavior justifies the extra work. They can provide tighter control over product-specific behavior, but the team will need to implement and maintain the relevant editorial interfaces and lifecycle features.

For many catalogs, content types, entity references, taxonomy, and Media provide enough structure.

We show how to move comparable values into fields in Drupal content modeling for answer coverage: fields, not prose.

Decide which system owns each field

If a product information management system already owns technical specifications, Drupal can publish those values while editors maintain web descriptions and supporting content.

Define that boundary early. Otherwise, an editor may correct a specification in Drupal only for the next import to overwrite it.

Use stable external identifiers for imports and relationships. Product names change; integrations need a more durable way to recognize the same record.

We describe how to split ownership between Drupal, PIM, and ERP in Connecting Drupal to PIM and ERP as sources of specifications.

Give attributes, families, and variants a shared vocabulary

Consistent attributes make comparisons trustworthy. They also prevent a familiar filtering problem: “stainless steel,” “Stainless,” and “SS” appearing as separate choices when they mean the same thing.

For each attribute, define its:

• Meaning and scope.
• Data type.
• Unit, where relevant.
• Allowed values or referenced vocabulary.
• Applicability to particular product families.
• Rules for validation and display.

Store a dimension as a numeric value with a defined unit, rather than as free text such as “about 12 cm.” A decimal field can hold the value, while configuration or a separate unit field identifies the measurement unit.

Some specifications need more structure. A minimum and maximum operating temperature should be separate values, and a flow-rate claim may need a reference to test conditions. A number without its conditions can mislead buyers.

Keep unknown values distinct. A blank operating limit doesn’t mean zero, and “not applicable” doesn’t mean “not yet supplied.”

Use families to organize relevant attributes

Pump families may share some attributes while differing in others. A centrifugal pump and a dosing pump won’t necessarily need identical specification forms.

Drupal doesn’t infer those differences from a family label. The implementation needs to express them through content types, field configuration, validation, or custom form behavior.

For a modest number of stable product types, explicit fields are often easier to maintain and query than a generic attribute-value system. Catalogs with many changing attribute sets may justify a more dynamic model or a PIM integration.

Choose based on actual complexity, not the possibility that the catalog might someday contain everything.

Give meaningful variants their own identity

A variant deserves a separate record when buyers need to identify, reference, or compare it independently.

For the pump manufacturer, voltage and connection size might distinguish orderable models. Each variant could have its own identifier, relevant specifications, drawing, and quote-request context, even though the website never processes an order.

Agree where each value lives. For example:

• The product holds the shared description and housing material.
• The variant holds voltage, connection size, and configuration-specific dimensions.
• A display rule determines which shared values appear alongside variant values.

Drupal needs explicit logic for inherited values and overrides. Entity references alone don’t establish those rules.

For a small catalog, storing each marketed model as a complete product record may be simpler than introducing inheritance. The right model is the one editors can maintain without creating conflicting facts.

Let components arrange data rather than duplicate it

Marketing teams need room to explain products. They may want an application story, an installation image, a specification panel, and a quote-request block on the same page.

A component library provides that freedom while protecting the product data.

The rule is simple: fields own product facts; components arrange and render them.

A specification component should read the product’s fields. It shouldn’t give editors another text box where they can type the same dimensions. A variant comparison should load referenced variants rather than maintain a separate hand-written table.

Drupal offers several building blocks:

• View modes and field formatters control how entity data appears.
• Layout Builder can give editors control over page composition.
• Single Directory Components can package reusable presentation templates, styles, and scripts.
• Paragraphs, where appropriate, can support structured editorial sections.

These tools serve different roles. A component library doesn’t automatically connect a template to product fields or enforce editing rules. Developers need to build those connections and configure the allowed layouts and blocks.

For the pump catalog, editors might arrange a product introduction, specification table, document list, application section, and inquiry block. Technical values would still come from the product and variant records.

Leave room for prose. Installation guidance and use-case explanations often need it. Keep facts used for filtering, comparison, or automated extraction in fields.

Working with components together with clients is the topic of Component mindset: teaching clients to think in components.

Build listings and filters around real selection criteria

Good filters save buyers from opening a dozen unsuitable products.

Start with how customers select equipment. For the pump manufacturer, useful filters might include application, fluid compatibility, flow-rate range, housing material, and connection size.

Drupal Views can provide product listings and basic exposed filters. For more demanding search, the Search API ecosystem, an appropriate backend, and compatible faceting modules can support richer indexing and navigation.

The architecture depends on catalog size and query needs. A small catalog may not need a separate search service.

For an example of product search built on Apache Solr, see Product Search Engine in Drupal with Apache Solr Integration - How-to Guide.

Decide whether results represent products or variants

This choice affects both filtering and accuracy.

Suppose one pump variant supports the selected voltage, while a different variant has the selected connection size. A product-level search that merges all variant attributes could return the parent product even though no single variant matches both requirements.

Avoid that ambiguity by indexing variants separately or designing queries that preserve the relationship between attributes on the same variant. If results group matching variants under a product, show which variants qualify.

Also decide how ranges should behave. Filtering products whose maximum flow rate exceeds a value is different from finding products whose supported operating range includes it.

Use consistent units in the index, validate the rules against real selection tasks, and display enough context for buyers to understand each match.

Search freshness needs attention too. A published specification change should trigger the relevant index update and cache invalidation. Otherwise, the product page and filter results can disagree.

Generate product documents from the same records

Buyers still need documents. They email technical sheets to colleagues, attach them to procurement requests, and take them to installation sites.

The goal isn’t to eliminate PDFs. It’s to stop maintaining the same specifications twice.

A per-product document generator can combine structured fields, referenced assets, and a controlled template to produce a technical sheet. The web page and generated document then draw from the same product record.

A useful generation process will:

1. Select the intended published product or variant revision and language.
2. Resolve the applicable specifications and supporting images.
3. Render a document through a maintained template.
4. Record the source revision and generation date.
5. Replace or invalidate the generated copy when its source changes.

Drupal will need an integration or custom implementation for this workflow; creating product fields doesn’t automatically produce PDFs. For larger catalogs, queued generation can keep document rendering out of the visitor’s page request.

Keep the document date clear. A generation timestamp tells the reader when the file was created, not necessarily when an engineer verified the specifications.

Some documents should remain controlled uploads. Signed certificates, externally issued test reports, and approved drawings have their own revision processes. Reference them from the product instead of recreating them.

For restricted documents, apply access rules to the download route and storage mechanism as well as the page link.

Generating PDFs from entities is covered in Make a PDF of any Entity in Drupal - Review of the Entity Print Module. For the opposite direction, moving data from PDFs into Drupal, read A Drupal pipeline for turning PDFs into structured content.

Make product facts accessible to AI assistants

AI assistants may encounter your catalog through search results, rendered pages, structured metadata, or an integration. Clear product records give you a consistent source for those surfaces.

They don’t guarantee discovery or recommendations. They make accurate interpretation more achievable.

For the pump manufacturer, an assistant needs to distinguish a family from a model, recognize the selected variant, and connect a specification to its unit and operating conditions. A folder of PDFs with inconsistent names makes that harder.

A practical publishing approach includes:

• Readable HTML: Put public specifications in labeled page content that visitors and crawlers can access.
• Stable URLs and identifiers: Give products and independently referenced variants durable identities.
• JSON-LD: Map suitable fields to Schema.org Product properties and use additional properties where appropriate.
• APIs or feeds: Expose approved fields for integrations that need structured records.
• Consistent revision handling: Update derived outputs when the source changes.

Schema.org markup should reflect the visible product accurately. Don’t invent prices, availability, reviews, or offers to fill a template. Valid markup also doesn’t guarantee eligibility for a search engine’s product features.

Drupal core’s JSON:API can expose entity data, subject to configuration and access checks. Treat its public surface as a deliberate publishing decision: review enabled resources, field access, unpublished content, and referenced assets.

Markdown exports or an MCP integration may be useful for a specific agent workflow. Neither replaces accessible product pages, and neither is necessary for every catalog. If you add agent tools, define what they can read or do and test those boundaries.

Consistent facts come first. Adding another machine-readable format won’t fix contradictory specifications.

We explain how to generate JSON-LD from fields in JSON-LD in Drupal: how to generate structured data from fields with Schema.org Metatag.

Add Commerce when the sales process calls for it

Drupal Commerce becomes relevant when the website needs to support transactional workflows, rather than simply describe products.

A price field alone doesn’t make a website a store. Neither does a variant identifier.

Commerce provides commerce-specific concepts, including purchasable variations, carts, orders, checkout, and payment integration capabilities. Those concepts become useful when your requirements depend on them.

If online purchasing is already planned, consider that future architecture before building the catalog. Stable identifiers and clear relationships can help a later transition, but moving to Commerce will still involve data mapping, workflow decisions, and testing.

The platform’s features are described in Guide to Drupal Commerce Platform. What are The Features of Drupal Commerce?.

Plan a catalog that your team can keep current

Start with a representative product family, including awkward cases: missing specifications, multiple languages, variant-specific drawings, and documents shared across products.

Build one complete path from editing to publication. Check the product page, listing, filters, quote request, machine-readable output, and generated technical sheet.

Then change a specification. Does every output update correctly? Can an editor see which values are missing? Does the inquiry identify the exact variant the buyer selected?

Those tests reveal more than a polished page mockup.

Drupal is a strong fit when your catalog needs reusable data, relationships, editorial workflows, multilingual publishing, and several output formats. A small, rarely updated catalog with limited filtering may be easier to maintain on a simpler platform. A manufacturer with extensive product-data operations may need a PIM alongside Drupal.

The useful distinction is structured catalog versus duplicated information, not catalog versus store. Build the records around what buyers need to know, then let pages, documents, and integrations reuse those facts.

Planning a Drupal product catalog without Commerce? Bring Droptica a sample product family, a few technical sheets, and the questions buyers ask most often. We’ll help you map the records, filters, and publishing workflow, then assess whether any part of your sales process actually calls for Commerce. Learn more about our Drupal development services.