Product Catalog Website Design

A product catalog website succeeds or fails on how the product data is organized and how enquiries reach your sales team, far more than on its visual design. A catalog that looks polished but returns nothing when a buyer types a product code, or that forwards a quote request without quantities, will not take a single call off your sales team's desk.

In this guide we, Talha Aslan and team, walk through the decisions on a catalog project in the order we make them, from choosing the model and structuring data to enquiries, search, speed and measurement. Each section gives you a criterion you can apply to your own product list or to an agency proposal.

01Choosing between a catalog, a shop and a PDF

The right model depends on where the customer pays: if payment happens on the site you need a shop; if the deal closes through a quote or a dealer, you need a catalog website. A PDF is not a third option but an attachment that lives alongside the catalog site as a download.

When a company cannot decide, we ask these questions:

• Is the price fixed: If every customer pays the same price for the same item, online sales are possible; if price depends on volume, project or dealer discount, a catalog is the more honest structure.
• Who closes the order: If a sales rep finishes the deal on the phone or in a meeting, the site should open that conversation, not try to replace it.
• Do you hold stock and ship: If dealers deliver the product, a cart and shipping step make a promise you cannot keep.
• Are you selling to consumers: If direct sales to end customers are the goal, you need an online shop; a catalog will not cover that need.

Mixed cases exist: a company selling spare parts online but quoting for machines can start with a catalog and add checkout to some groups later. Structuring product data so it can serve both models from day one saves you paying for a second site.

02Building the product data model before design

The first deliverable of a catalog project is not a screen design but a product sheet in which the purpose of every column is clear. The menu, the filters, the product page and the quote basket fields all come from that sheet; if it has gaps, they will surface later no matter how good the design is.

For every field we ask three questions: does this help the buyer choose, will it be a filter or appear only on the product page, and does its value come from a fixed list or free text? A size field kept as free text can never become a filter, because "20 mm", "20mm" and "2 cm" describe the same value three different ways.

• Unique key: Every product needs a permanent product code; images and datasheets are matched to it.
• Variants: Decide early whether a color or size difference is a separate product or a variant of the same one.
• Units: Dimensions, weight and capacity should follow one consistent unit system.
• Status field: A column such as active, discontinued or coming soon makes takedown decisions simple.

If your product list lives in an ERP export, translating internal descriptions into language a buyer understands is a separate work item. Agreeing who does it before the contract is signed puts the most frequently delayed step of the project on the schedule.

03Structuring categories around buyer language

The category tree should mirror how buyers describe products, not how your warehouse is organized. If purchasing managers search for "stainless steel fasteners", the fact that your internal system files them under "Group 14" should not shape the catalog menu.

Finding the buyer's language is often as simple as reading the latest enquiries your sales team received: which words do customers use, which applications do they mention? Those words are the raw material for category names and category page introductions.

1. Split every product in the sheet into six to eight main groups at most; beyond that the menu stops being readable.
2. Divide each main group by the first attribute buyers use to tell products apart, and try to keep the depth to three levels.
3. If a product belongs in two categories, do not duplicate it; link the single product to both categories.
4. Write a short introduction for each category page explaining what to consider when choosing within that group.
5. Ask someone from sales to find five different products using only the menu, and note where they hesitate.

Renaming categories after launch can change URLs as well. If the tree passes a test like this before launch, you avoid redirect work later and keep the value your pages have built in search.

04Deciding which attributes become filters

A good filter narrows the result list in a meaningful way; not every technical field deserves to be one. A common problem on catalog sites is twenty filters side by side, most leaving a single result.

Before turning an attribute into a filter, we check these criteria:

• Distinctiveness: Does the attribute split the category into a few meaningful groups; if every product shares the same value, the filter is pointless.
• Completeness: Is the field filled for most products; a filter that is empty for half the range silently drops suitable products from the list.
• Buyer questions: Do enquiries to your sales team ask about it; if not, showing it on the product page is enough.
• Value type: Numeric values work as range sliders, fixed options as checkboxes.

On phones, filters should open in a full screen panel and show how many results remain while the buyer is still choosing. When a combination returns nothing, offering to remove one filter and a direct path to the quote basket or contact form, instead of an empty page, recovers enquiries that would otherwise be lost. Put the most used attribute at the top.

05Product code search and the details of site search

On catalog sites a large share of visitors already know what they want and type its code directly, so site search deserves the same care as the menu. A search that fails when the code is not typed exactly turns away your warmest buyers at the door.

The search box should handle these situations:

• Different code spellings: Codes written with spaces, dots or run together should all find the same product.
• Legacy and competitor codes: A product's old code or the equivalent known in the trade can be stored in a separate field and included in search.
• Typos and accented characters: A buyer who types without accents or makes a small typo should still see the right products.
• Zero result searches: Searches that return nothing should be logged; that list reveals missing products and missing synonyms.

Suggestions that appear while typing make it unnecessary to type long codes in full, which matters most on a phone. Reading the zero result list once a month is the cheapest way to learn what your catalog is missing.

06Anatomy of a product page and where datasheets fit

A product page should answer "is this the product I need" without scrolling, and then show the way to an enquiry. Image, product name, code and the add to quote button belong on the first screen; the full specification table and documents follow directly below.

On a product page we include, in this order:

• Defining sentence: Two sentences, specific to this product, explaining what it is and where it is used.
• Specification table: An attribute list generated from the product sheet, with consistent units.
• Variant selection: Size or color differences on the same page, with the selected variant's code visible.
• Documents: Datasheet, certificates and installation guide, each labeled with file type and size.
• Related products: Accessories used together with it and alternative products.

Replacing the product page with a datasheet is a frequent shortcut. The datasheet should be a downloadable extra, while its core information also appears on the page as text; both search engines and buyers on a phone read page text far more easily than the inside of a PDF.

07Quote basket fields and the journey of an enquiry

The quote basket is a form that lets a buyer answer, in one go, every question your sales team asks before quoting; that is why sales, not the designer, should define its fields.

The path an enquiry should follow from start to finish:

1. The buyer adds a product from the product page or list view; the basket survives page changes.
2. In the basket they enter a quantity, a unit and, if needed, a short note for each item.
3. They type company name, contact person, phone, email and delivery region only once.
4. Before sending they see a short privacy notice explaining how their data will be used; buyers in the EU expect this, and many jurisdictions require it.
5. The enquiry reaches the sales inbox with product codes and quantities, and if you like your CRM or a spreadsheet; the buyer receives a copy.
6. Sales marks the enquiry with a status: new, quote sent, won or lost, with a short reason for lost ones that later informs price and range decisions.

Most projects forget the last step, yet without it you cannot measure what the catalog contributes. The basket also has to work for a single item; instead of sending a buyer who asks about one product through every basket step, a short quick enquiry form on the product page does the job.

08Separating the dealer finder from dealer applications

A brand that sells through dealers serves two different visitors: the end customer who wants to buy, and the company that wants to become a dealer. Sending both to the same contact form means your sales team sorts every message by hand.

For the dealer finder, we first ask who keeps the dealer list and in what form. A closed dealer shown on the map damages trust more than no map at all, so easy updates matter more than the map's look.

• Dealer record: Company name, region and city, phone, product groups carried and an optional map location.
• Search format: A list filtered by region next to the map; on a phone, the list is easier to use than the map.
• Dealer application: A separate form asking for region, line of business, brands carried and sales outlet details.
• Routing: Applications go to a different person or inbox than quote requests.

If you want to give dealers brochures, product images and price lists, separate a public archive from a password protected dealer area. A setup where dealers log in, see their own prices and place orders is a custom software project separate from the catalog site; the catalog's product data can connect to it later.

09Showing prices or leaving them to the quote

Whether prices appear in the catalog is a sales model decision, not a design preference, and it does not have to be the same for every product group. Showing prices for standard accessories while quoting project items is a balanced path for many companies.

We suggest looking at the decision from these angles:

• Competitor behavior: If buyers in your sector are used to seeing prices online, a catalog without them can drop out at the first shortlist.
• Dealer relations: A list price on the site that contradicts what dealers quote in the field creates tension in your network.
• Update workload: If prices change often, an outdated figure on the site forces your sales team to explain themselves.
• Legal obligations: Price display to consumers is regulated in most markets; confirm the rules for your target countries with your legal adviser.

For products without a visible price, instead of writing "call for price", add a short note on the product page explaining what the price depends on: quantity, delivery region, surface finish and similar factors. The note also teaches buyers what to write in the quote basket and reduces incomplete enquiries. Where prices are shown, the panel should allow bulk updates.

10Presenting product pages correctly to search engines

For each product to show up as its own search result, it needs its own URL, its own title and its own description. Two technical decisions follow: which kind of product structured data to use, and how to handle filter URLs.

Google defines product snippet markup for product pages where people cannot buy directly and merchant listing markup for pages that sell. Catalog pages use the former; you can draft the markup with our structured data generator and compare it against the fields in your product sheet.

• Title pattern: Product name, the distinguishing attribute and product code, with the brand name at the end.
• Original description: Even similar products get a paragraph that explains their application or difference.
• Filter URLs: Combinations nobody searches for are kept out of crawling; the few that people do search for become pages with their own description.
• Discontinued products: Instead of deleting the page, show the successor or redirect to the closest product.

If you want to keep a page out of the index, do not block it in robots.txt; Google cannot read the noindex on a blocked page. If you plan to open the catalog to buyers abroad, the hreflang setup that links language versions is covered on our multilingual website page. If your product pages need ongoing content and link work, our SEO service runs alongside the catalog.

11Keeping a catalog with hundreds of images fast

Images are the heaviest load on a catalog site; unprepared, they make a category page with hundreds of products slow on a phone. Google's Core Web Vitals treat these values as good at the 75th percentile of visits: LCP (how long the largest element takes to load) of 2.5 seconds or less, INP (how quickly the page responds to a tap) of 200 milliseconds or less, and CLS (how much elements shift while loading) of 0.1 or less.

To get close to these thresholds, we tie image preparation to a workflow before launch:

• Consistent photography: Products in the same category are shot with the same background and aspect ratio, so lists look orderly and shift less.
• Size and format: Every image is resized to the largest dimension it will be shown at and converted to a modern format.
• Lazy loading: Product images below the visible screen load as the visitor scrolls to them.
• Pagination: Very long lists are split into pages or loaded in controlled batches.

When a filter is applied, updating results without reloading the whole page directly improves INP. The lasting fix is a panel that resizes and converts every uploaded image automatically, so the skill of whoever uploads products never decides how fast the site is.

12Measuring which products bring enquiries

Whether a catalog site works shows up not in visitor numbers but in which product brought which enquiry. That requires quote submissions, datasheet downloads and dealer applications to be tracked as separate events, each carrying the product code.

In the measurement plan we define these events separately:

• Add to basket: Shows which products enter the basket and which are left without being sent.
• Quote submission: Recorded with the number of products and total quantity.
• Datasheet download: An early signal of interest for technical products.
• Dealer application and dealer search: Shows which regions people look for dealers in, and where you have gaps.

Printed catalogs can feed into this measurement too. A QR code next to each product, leading to its page, makes the move from paper to site easy and measurable; create the codes with our QR code generator and give each print run its own campaign tag. Your PDF can stay on the site as a download, but the site becomes the master source, with the PDF generated from it.

For visitors in the European Economic Area, Google requires consent mode for measurement and personalized advertising features, and cookie consent is needed before non essential tracking.

13Common mistakes on catalog projects

Most mistakes we see on catalog sites appear when work starts before anyone has discussed the product data and the enquiry flow. Next to each mistake below, we have written the better way to solve the same problem.

• Hiding prices in a ready made shop theme: Rather than patching over cart and shipping steps, build a structure without checkout that runs on a quote basket from the start.
• Leaving the catalog as PDF pages: Keep the PDF as a download, and publish every product at its own URL on a page that can be read as text.
• Entering product data as free text: Have attributes such as size and material picked from fixed value lists; only then do filters work correctly.
• Collecting every enquiry in one contact form: Split quote requests, dealer applications and general questions into separate forms and route each to the right person.
• Naming categories after internal codes: Build the menu from the words buyers use, and show internal codes as extra information on the product page.
• Leaving updates dependent on the agency: Make panel training for adding products, replacing datasheets and bulk updates a requirement at the proposal stage.

If you are moving from an old product site to a new catalog, the most expensive mistake is removing existing product URLs without redirects. We cover that transition step by step on our website redesign page.

14Choosing a partner and your next step

When choosing a partner for a catalog project, look less at portfolio images and more at the questions the agency asks about your product data and enquiry flow. A proposal from a team that never asked how many products you have, how you sell and who handles enquiries is most likely based on a ready made template.

We suggest asking any team you get a quote from:

• Can you import our products in bulk from Excel or an ERP export, and how do you match images and datasheets to product codes?
• How do you handle crawling of filter URLs and product structured data?
• In what format will a quote request reach us, and can it connect to our CRM or a spreadsheet?
• Will we be able to update products ourselves after launch, and do you provide training for it?
• If we later add a dealer portal or online sales, will product data have to be entered again?

To see our approach in practice, open the live demo catalog site linked on this page on both your phone and your computer. Send us your product list and a short description of how you sell; we will define the scope with you and prepare a written quote. If you have a small range and need a simple site, take a look at the fixed packages in our pricing section.