Most companies that sell physical products rebuild their catalogue from scratch every season. Someone exports a product list, someone else drops the rows into InDesign or Word, a third person chases down photos that are already on the website, and three weeks later a PDF exists. By the time it reaches a customer, four prices have changed.
The strange part is that all of this data already exists, structured and current, in the one place the company updates constantly: its own website.
The catalogue and the website are the same data
Open any product page on your site. It has a name, a code, a description, a price, one or more images, a category, and probably some attributes—dimensions, material, finish, packaging unit. That is a catalogue entry. It is already typed, already proofread, already approved.
A printed or PDF catalogue is not different content. It is the same content in a different layout. Yet in most companies these two artefacts are maintained by different people, in different tools, on different schedules—which guarantees they disagree.
Once you see the catalogue as a rendering of the product data rather than a document, the work changes shape entirely. You stop maintaining a PDF. You maintain products, and generate the PDF whenever you need one.
Where the data actually comes from
You do not need a modern headless CMS for this. In practice, the product data is reachable in one of four ways, and one of them is almost always available:
A database or ERP you already run
The cleanest source. If your site is driven by a product table, the generator reads the same table. Nothing to sync, because there is nothing to copy.
An export you already produce
Many businesses already generate a CSV or XML feed—for a marketplace, for Google Shopping, for a distributor. That feed is a perfectly good input. It is maintained precisely because someone downstream complains when it breaks.
An API
WooCommerce, Shopify, PrestaShop and most ERPs expose products over an API. A few hundred lines of code turns that into a structured list.
The website itself
When there is no database access and no feed—which happens more often than you would expect with older sites—the pages can be read directly. It is the least elegant option and the one that breaks when the site is redesigned, but it works, and it is far better than retyping 400 products.
What actually makes this hard
The data extraction is the easy half. The half that sinks projects is layout.
A catalogue is not a table. It has a cover, section dividers, a table of contents whose page numbers must be correct, products that must not split across a page break, images at print resolution, and a back cover with contact details. Any tool can dump rows onto pages. Producing something a printer will accept, and a customer will not immediately recognise as machine-made, is where the engineering goes.
Concretely, these are the problems worth solving up front:
- Pagination that respects content. A product block is atomic. If it does not fit, it moves to the next page—it does not get sliced in half.
- Images at the right resolution. Web images are typically 72 dpi and sized for a browser. Print wants 300 dpi. Either you hold higher-resolution originals somewhere, or you accept that the PDF is screen-only. Decide this before designing anything.
- A table of contents generated last. Page numbers are only knowable after layout. This sounds obvious and is the single most common bug in home-made generators.
- Prices that can be adjusted at generation time. A distributor catalogue and a retail catalogue are the same products at different margins. That should be a parameter, not a second project.
- Sections you control. Category order in a catalogue is a commercial decision. It rarely matches the order the database returns.
What changes once it works
The obvious gain is time: a catalogue that took three weeks takes a few minutes. But the interesting change is not speed. It is that the catalogue stops being an event.
When regenerating costs nothing, you stop rationing catalogues. A distributor asks for a version without prices—you make one. A client wants only the three categories they actually buy—you make that. Prices move in October and the printed run was in September—you regenerate and send a current PDF instead of apologising for an outdated one.
That is the real shift. Not a faster document, but a document that is always true, in as many variants as the business needs.
How to start without a big project
Do not begin with the full catalogue. Begin with one category and one page layout, generated from real data. That single page answers the questions that matter: is the data complete, are the images usable, does the layout survive the products with unusually long names?
Almost always, the first run exposes data problems rather than layout problems—products missing a photo, descriptions someone left in draft, three different spellings of the same material. Those would have been fixed by hand, silently and repeatedly, during every manual catalogue build. Generating the catalogue makes them visible once and fixes them at the source.
We built exactly this for a furniture manufacturer: the Catalogue Generator turns their live product data into a paginated, print-ready PDF, regenerated whenever prices move instead of rebuilt from scratch. The same product data also drives their price offers—which is the point. Structure the data once, render it as many ways as the business needs.
Is your catalogue rebuilt by hand every season?
Tell us where your product data lives and we'll generate one real page from it—your products, your layout—so you can see what it would look like before committing to anything.
Tell us what repeats→Common questions
Can a catalogue be generated if I have no access to the database?
Yes. Product data can come from an existing CSV or XML feed, a store API such as WooCommerce or Shopify, or in the worst case be read from the public product pages themselves. Direct database access is the cleanest source, not the only one.
Will the generated PDF be good enough to print?
That depends entirely on your images. Layout, pagination and typography can be made print-quality. Web images are usually 72 dpi and print wants 300 dpi, so unless higher-resolution originals exist somewhere, the result is screen-quality only. This is worth deciding before design starts.
How long does it take to build a catalogue generator?
The data extraction is usually days. Layout is where the time goes — pagination that never splits a product, a table of contents with correct page numbers, and section ordering that matches commercial priorities rather than database order.