A PDF price list can become shop-ready product listings

From a PDF to product listings that a shop can actually sell

A PDF price list becomes product listings when each row is mapped to shop fields such as title, SKU, price, currency, GTIN, and image. The file is read in blocks, not as a screenshot. Columns that look aligned on paper often merge in extraction, units hide in headers, and footnotes never land in the description unless you copy them on purpose. The listing is only as complete as the cells you keep, the codes you verify, and the photos you attach.

When a crawler or a shopping feed reader hits a WooCommerce product, it looks for named fields: id, title, description, link, image_link, price, availability, brand, and gtin (or identifier_exists when the manufacturer code is absent). A PDF sitting in an inbox does not expose those fields. Merchant Center › Products › Feeds has nothing to ingest until the row is a product record. The practical change is mechanical: the table stops being a picture of prices and starts being data the store, the feed, and an assistant can quote. That is also why Google reads product data before your words on the public page.

Why a PDF price list never updates the live catalog by itself

A PDF does not push titles, prices, or stock into WooCommerce; each row must become a product record before the shop or a feed can use it.

Suppliers still send season lists as print-ready files because a PDF locks layout, logos, and legal notes. That is useful on paper and useless as a catalog source. WooCommerce › Products › All products expects a SKU, a name, a regular price, and a stock status. None of those names exist inside the PDF until a reader splits header rows from body rows and assigns each column. Until that mapping is confirmed, the online catalog ages while the PDF in the shared drive is treated as the real list.

The same file also fails as a shopping feed. A feed row needs id, title, description, link, image_link, price with an ISO currency, availability, brand, and gtin. Copying the PDF into a product description dumps the whole table into one text blob. The crawler then sees a paragraph, not a price. If you later need a WooCommerce product feed for ChatGPT, that blob still is not a feed. Start from fields, not from a screenshot of the list.

Who has little time for the daily catalog routine

Who already spends the morning answering stock questions does not have a second pass to retype forty rows after every supplier PDF. The useful move is a block read of the new file, a column map you confirm once, and an update by SKU so yesterday’s products are edited rather than cloned. Manual paste between PDF, spreadsheet, and WooCommerce is where units, footnotes, and barcodes are lost.

A workshop that sells ceramics and manages about forty SKUs

A workshop that sells ceramics and manages about forty SKUs often receives a one-page list: code, glaze name, diameter, pack, price. Those forty rows look small and still hide the same traps as a 400-row import: a diameter sitting in the header, a pack quantity glued to the price, a footnote about dishwasher use that never reaches the description. Forty listings are enough for a wrong currency or a duplicated SKU to show up on the shop floor the same afternoon.

Who refreshes a supplier PDF every season

Who refreshes a supplier PDF every season needs a repeatable map, not a heroic retype. Prices move, colours get a new suffix, and discontinued codes vanish. The durable key is the SKU that already lives in WooCommerce. If the new PDF is applied as a fresh import without that key, the shop grows silent duplicates and the old URLs keep the old price.

What a block-by-block PDF read actually keeps and drops

A block-by-block read keeps cells it can name and drops layout that is not a field, including merged columns, header-only units, and footnotes.

A PDF price list is not one image of a catalog. It is a stack of page blocks: repeating headers, a table body, a footer with legal lines, and sometimes a photo cluster. A reader that works in blocks first finds the table, then the header row, then each data row. If the file has a real text layer, those cells are characters. If the file is a scan of a printout, the reader is guessing through OCR, and merged cells become more likely.

A feed ACP is a product feed shaped so an assistant can use shop data (identity, price, availability, link) rather than scraping a paragraph. It still needs the same core fields as any other product feed. Extraction from PDF is only the first hop toward that record. Typical losses look like this:

• Merged columns: the SKU and the title land in one cell, so the shop name becomes “CR-204 Bowl stoneware”.
• Unit of measure in the header only: “Price / pack of 4” never copies onto the row, and the listing price looks like a unit price.
• Footnotes: an asterisk on the price points to “VAT excluded” or “not microwave safe” at the bottom of the page, and that sentence is not in the description.
• Repeated page headers treated as extra products, cloning the column titles as SKUs.
• Multi-page tables that restart numbering, so page 2 looks like a new catalog.
• Embedded photos that sit beside the table but are not linked to a SKU.
• Barcode numbers split across a line break, which breaks the check digit before anyone types a listing.

Those losses are why a “PDF import” that only dumps text into the WooCommerce content editor is not cataloging. It is a paste. Named fields have to be confirmed. The same discipline belongs in a product spec sheet without inventing specifications: if the PDF does not state a material, the listing does not invent one.

A catalog row that still lives only in a PDF is not a product. It is a picture of a table that no feed reader can parse.

How extracted cells map onto product fields

Each useful PDF column maps to one shop field, and anything that cannot be named stays out of the listing until you confirm it.

After the table is detected, the work is a column map, not a rewrite. You look at the header labels the supplier printed and assign them to fields a store and a feed already understand. A practical map for a price list looks like this:

• Code, art., ref., or SKU maps to id in the feed and to the WooCommerce SKU.
• Description or item name maps to title; leftover notes map to description, not to the title.
• Price maps to price; the currency symbol or ISO code maps to currency, never into the number.
• Stock or “available” maps to availability (in stock, out of stock, preorder) when the PDF actually says so.
• Brand maps to brand only when the cell names a brand, not when it names a product line.
• EAN, UPC, ISBN, or GTIN maps to gtin only after the check digit passes; otherwise identifier_exists is the honest flag.
• Colour, size, or pack maps to attributes (WooCommerce › Products › Attributes), not to a second title.

What should not be automatic is invention. If the PDF never states weight, the listing does not receive a weight. If the glaze is “blue” and not “cobalt underglaze”, the title stays “blue”. Fact-guarded rewriting can clean Title Case, strip leftover HTML, and fill empty specification fields from the merchant’s own file. It does not replace a missing fact with a web guess. When two sizes share a title, grouping as variants with item_group_id happens only on confirmation, not in silence.

How embedded PDF images get matched to SKUs

Photos trapped in the PDF help only when they are extracted as files and paired with the same SKU as the row.

Many supplier catalogs place a thumbnail in the first column or a hero shot above a group of SKUs. A block reader can pull those embedded images out of the PDF and store them as product files. Matching is a separate step. A photo next to one row can be paired by position. A photo above three bowls cannot be assigned to all three without a confirmation, because the feed field image_link is generally expected to point to one primary image per listing.

When the PDF has no usable photo, the listing still needs an image before shopping surfaces treat it as complete. Google is reported to apply a minimum of around 500x500 pixels starting 31 January 2027, and Meta appears to ask for a similar size today, though these thresholds are not published in a single citable spec and may vary. Options that stay honest are: reuse a crop from the PDF if it is sharp enough, upload a pack shot you own, search the web and confirm the rights, or generate an illustrative image that is labelled as generated under AI Act article 50. Shared images across many SKUs should be flagged, because five bowls with the same thumbnail look identical in Merchant Center › Products › Feeds.

How GTINs, prices, and currencies should be treated

Barcodes and prices are copied from the merchant’s PDF and validated as numbers; they are never harvested from the web.

A GTIN (EAN-13, UPC-A, GTIN-14, ISBN) is a digit string with a GS1 check digit at the end. The check digit is calculated from the preceding digits. If the last digit does not match that calculation, the code is not a valid GTIN and must not be written to the listing. The number is read from the PDF cell, from a barcode drawn on the page, or from a pack shot the merchant already has. It is not searched online, because a web lookup can attach someone else’s code to your SKU.

Prices need the same split. A cell that says “€ 12,50*” is not a feed price. The number is 12.50, the currency is EUR, and the asterisk belongs to a footnote that may say “VAT excluded” or “per pack of 4”. European lists often use a comma as the decimal mark; feeds expect a dot. Do not leave the symbol inside the number. Do not convert currency unless the PDF says the list is in that currency. Availability stays empty unless the file states it; an old seasonal PDF is not proof the item is in stock today.

A GTIN is read from the merchant’s own PDF, pack shot, or CSV column and must pass the GS1 check digit. It is never looked up on the web.

A numbered path from file to WooCommerce listing

The reliable path is extract in blocks, map columns, confirm images and codes, then sync by SKU so the shop updates instead of duplicating.

Use this sequence on a real price list, including a one-page ceramics list or a multi-page supplier book. The goal is a listing you could paste into WooCommerce › Products without a second round of detective work.

1. Keep a digital PDF with a text layer when the supplier can send one. A photographed printout forces OCR and multiplies merged cells.
2. Import from PDF so the file is read in blocks: headers, table body, footers, embedded images.
3. Mark the header row. If “Price € / 4 pcs” is a header, store pack = 4 and currency = EUR as column meaning, not as product titles.
4. Map columns to id (SKU), title, description, price, availability, brand, gtin, and attributes such as size or colour.
5. Copy footnotes into description when they are product facts (dishwasher safe, VAT excluded). Leave legal boilerplate out of the title.
6. Run the GS1 check digit on every barcode. Reject failures. If the manufacturer has no GTIN, set identifier_exists rather than inventing a code.
7. Pair extracted images to SKUs. Confirm group photos. Consider replacing files under roughly 500x500 pixels, since smaller images are less likely to be accepted for shopping surfaces.
8. Review one sample row as a full listing (see the before and after below) before you accept the batch.
9. Sync to WooCommerce by SKU with the official plugin so existing products update and new SKUs create once. Never create a second product because the title changed.
10. When the records are complete, export only ready rows to Merchant Center › Products › Feeds, and keep the same fields for a ChatGPT product feed.

Before (one PDF row, as printed): CR-204 | Bowl, stoneware, Ø 18 cm, glazed blue* | 4 pcs | € 12,50. Footer: * dishwasher safe, not microwave. No barcode on the line. A thumbnail of a blue bowl sits in the left margin.

After (the listing you should store):

• id / SKU: CR-204
• title: Stoneware bowl, glazed blue, 18 cm
• description: Dishwasher safe. Not microwave safe. Sold in a pack of 4.
• price: 12.50 EUR (number and currency split)
• availability: left empty unless the PDF states stock
• brand: only if the list names a brand
• gtin: empty; identifier_exists set because no manufacturer code is on the page
• image_link: the extracted thumbnail, if it is sharp and at least 500x500; otherwise a confirmed pack shot
• attribute pack: 4, attribute diameter: 18 cm

That after state is what turning a PDF into product listings is for: named fields, confirmed facts, no extra SKU.

Common errors

Most failed PDF imports are not “AI mistakes”; they are cells that still contain two facts, a bad check digit, or a SKU the shop already owns.

Invalid or duplicated SKU

The store message is “Invalid or duplicated SKU.” It appears when WooCommerce already has that SKU and the import tries to create a second product instead of updating the first. It happens after a seasonal PDF uses the same codes with new prices. Resolve it by matching on SKU, writing the new price and title onto the existing product, and leaving the permalink alone. Bidirectional sync by SKU is the fix; a blank create is not.

Missing value [gtin]

Merchant Center reports “Missing value [gtin]” when the feed row has neither a GTIN nor a clear identifier_exists flag. It happens when the PDF barcode was skipped, split by a line break, or rejected by the check digit and then left blank. Resolve it by reading the digits from the merchant’s PDF or pack shot, validating the GS1 check digit, and writing gtin only when it passes. If the manufacturer has no GTIN, declare that absence. Do not search the web for a replacement code.

Price must be a number

The editor or feed validator returns “Price must be a number” (or a currency mismatch such as a symbol with no ISO code). It happens when the cell still contains “€ 12,50*”, “from 12”, or “12,50 / 4 pcs”. Resolve it by splitting amount, currency, pack, and footnote. Use a dot decimal in the feed, keep EUR as the currency code, and put “pack of 4” in an attribute or in the description.

Could not detect a table on this page

The reader returns “Could not detect a table on this page” when the PDF is a photograph, a heavily designed catalog with prices drawn as art, or a page that is only footnotes and photos. It happens because there is no text layer and no grid to parse. Resolve it by asking the supplier for the digital list, supplying a CSV alongside the PDF, or marking the product blocks by hand so images and nearby captions can still be paired. Do not type a fake table into the description to “make the import work”.

How Katapic turns the same PDF into listings you confirm

Katapic reads price lists and catalogs in blocks, extracts embedded images, and syncs WooCommerce by SKU so you confirm facts instead of retyping them.

Import from PDF is built for this file type: lists and catalogs are read in blocks, embedded images are extracted, and photos are matched to products for you to confirm. The same workspace also accepts a photo (one photo, one listing) and a CSV. Nothing in the catalog is edited until you say so. The first scan of a public WooCommerce catalog can run without an account, in read-only mode, on up to 100 products, with separate scores for classic search and assistant readiness plus a completeness axis for missing or wrong fields.

GTINs follow the same rule as the rest of this article: they are read from your PDF, pack shot, or CSV column and must pass the GS1 check digit. They are never searched on the web. Rewriting is fact-checked; brands, certifications, and history are not invented, and a web measure that contradicts your title does not enter. A rewritten listing costs 1 credit and an image costs 1 credit. There is no subscription. Credits do not expire. Products without a photo can use the PDF crop, a manual upload, a web image after you confirm rights, or a generated illustration marked under AI Act article 50.

Sync with WooCommerce is bidirectional by SKU and does not create duplicates. The official plugin is on WordPress.org. Channel readiness then covers Google Shopping, the ChatGPT feed, Meta, PDF, the shop, and assistant answers. If you need a print catalog after the listings exist, Catalogue Studio paginates one with 30 templates. The working path from a supplier file is the Katapic import, a confirmed map, and an update of the SKUs you already sell. When you want the reverse direction, a paginated catalog PDF can be generated from those same records.

FAQ

How do I import a PDF price list into WooCommerce?

Read the PDF in table blocks, map columns to SKU, title, description, price, currency, and attributes, then sync by SKU so existing products update. Do not paste the whole page into the product editor. Confirm GTINs with the check digit, pair embedded images, and only then open WooCommerce › Products to verify a sample. That sequence avoids duplicate SKUs when the supplier sends the next season list.

What product data can you extract from a PDF catalog?

You can usually extract SKU, title, extra notes, price, currency, pack or size, brand when it is named, barcodes that pass the GS1 check digit, and embedded photos. You cannot treat header-only units, merged cells, or footnotes as fields until you split them. Facts the file never states, such as weight or material, stay empty. Extraction is a map to id, title, description, price, availability, brand, gtin, and image_link, not a full rewrite of the catalog.

Can cataloging from a PDF be automatic without inventing specs?

Column detection and image extraction can be automatic. Writing a material, a certification, or a GTIN the file does not contain cannot. The honest workflow auto-fills empty cells from the PDF, flags check-digit failures, and waits for confirmation on variants and Google category. If a measure found elsewhere contradicts the merchant title, the merchant value wins. Automation that invents a spec creates a listing you cannot defend in a feed review.

How does a PDF catalog import work with existing WooCommerce SKUs?

The SKU in the PDF is the join key. When it matches a product already in the shop, the import should update price, title, and images on that product and leave the URL in place. When the SKU is new, one product is created. Matching on title instead of SKU is what creates silent duplicates after a rename. Bidirectional sync by SKU is the safeguard, including when you later export a shopping feed from the same records.

What happens to barcodes and GTINs found in a PDF?

Digits printed in a cell or drawn as a barcode are copied, then tested with the GS1 check digit. A pass writes gtin. A fail leaves the field empty and should not be “fixed” with a number from a search engine. If the manufacturer never issued a GTIN, set identifier_exists rather than guessing. That keeps Merchant Center from storing a code that belongs to another item, and it keeps assistant-facing feeds aligned with the pack in your warehouse.

Why do units and footnotes disappear when I copy a price list?

Units often live only in the header (“price per pack of 4”) and footnotes live only at the bottom of the page. A row-level copy never sees them. The listing then shows a unit price that is actually a pack price, or it omits “VAT excluded” and “not microwave safe”. During mapping, store the header unit as an attribute and paste footnote facts into the description. If you skip that split, every downstream feed repeats the error.

Should I generate a new catalog PDF after the listings are clean?

Once SKUs, prices, and photos live as product records, a paginated catalog PDF is a by-product, not the source of truth. Generate it from the shop data so print and online cannot drift. Keep the PDF you received from the supplier as evidence of the original facts. The live catalog, the shopping feed, and any assistant feed should all read the same fields you confirmed after the import, not the layout of last season’s file.

Further reading

• 5 Ways to Measure the AEO Readiness of a WooCommerce Product