Open your POS catalogue and look at an actual product name. There is a fair chance it reads something like BLK SHRT L or SAM A15 128 BLU. That is not sloppiness. Somebody chose those names deliberately, because at a counter the only job a product name has is to let staff find the right item in three seconds.
Push that same catalogue onto a website and every one of those names becomes a problem. Nobody searches for BLK SHRT L. Nobody clicks it. Google has nothing to work with. The data was built for a different job.
This is the eighth post in our WooCommerce series, following integration basics and posts on inventory sync, click and collect, pricing, returns, customer records, and payment reconciliation. Those covered what happens once you are running. This one is about the work that should happen before you switch anything on.
Two Catalogues, Two Different Jobs
A POS catalogue exists to identify an item quickly for someone who is already holding it. Speed and uniqueness are everything. Abbreviations are a feature, because a shorter name is faster to scan on screen.
A web catalogue exists to help someone who cannot touch the product decide whether they want it, and to help a search engine understand what it is. Clarity, completeness and searchability matter far more than brevity.
Both are legitimate. The mistake is assuming one can serve as the other without work. The table below shows how differently the same fields need to behave.
| Field | What the Counter Needs | What the Website Needs |
|---|---|---|
| Product name | Short, unique, fast to scan | Descriptive, readable, searchable |
| Description | Usually empty | Detail a customer needs before buying |
| Images | Rarely used | Essential, multiple per product |
| Attributes | Enough to pick the right variant | Filterable, consistent, complete |
| Category | Reporting groups | How shoppers actually browse |
| Barcode or GTIN | Scanning at the till | Product identity for search engines |
Names and Descriptions Do the Selling
Rewriting product names is the single highest value task in this whole exercise, and it is also the most tedious, which is why it usually gets skipped. A useful format is brand, product, then the distinguishing detail, written the way a customer would say it out loud.
Descriptions matter for a reason retailers often underestimate. In store, a customer picks the item up, checks the fabric, turns it over. Online they cannot, so every question they would have answered by handling it has to be answered in text. Sizing, materials, dimensions, what is in the box, warranty. A description that only repeats the product name leaves the customer to guess, and guessing customers tend to leave.
You do not have to do the entire catalogue. Start with your best sellers, because a small share of products usually drives most of the revenue, and expand from there.
The principle: your POS catalogue answers which item is this. Your web catalogue has to answer why should I buy this. Those need different words.
Images Are Not Optional
Most POS catalogues carry no images at all, because nothing at the counter needs them. Online they carry the entire product page, and a listing without one will not sell no matter how good the item is.
The practical standard is a consistent plain background as the main image, a few supporting angles, and at least one shot showing the product in use or worn. Consistency across the catalogue matters more than any single photograph being perfect, because inconsistent images make a store look improvised.
Two details that are easy to get wrong. File sizes straight from a phone or a camera are far larger than a web page needs, and a page full of them will be slow, which costs you both customers and rankings. And every image needs alt text describing the product, which serves visually impaired shoppers and gives search engines something to read.
Attributes Decide Whether Anyone Can Find Anything
Attributes are the structured facts about a product: size, colour, material, capacity. In a POS they exist mainly so staff can pick the right variant. Online they also drive the filters shoppers use to narrow a category down to something manageable.
Consistency is what makes filters work, and inconsistency is extremely common in catalogues that grew over years. If the same colour appears as Navy, navy blue, NVY and Dark Blue across different products, a shopper filtering for navy sees a fraction of what you actually stock. Standardising those values is unglamorous work with a direct effect on sales.
Attribute quality also connects to the variation structure covered in the inventory sync post. Clean, consistent attributes are what let a variable product behave properly rather than becoming nine unrelated listings. Retailers running a fashion POS system usually have the underlying matrix already, which is a strong head start.
Identifiers and How Search Engines Read Your Products
Barcodes in a POS exist to be scanned. On a website the same number becomes a product identifier that helps search engines recognise what you are selling, which is worth understanding before you dismiss the field as internal detail.
Google sets out what product markup should contain in its introduction to product structured data, which distinguishes between product snippets for pages where people cannot buy directly and merchant listings for pages where they can. If customers check out on your site, the merchant listing variety is the one that applies, and it supports more detailed information including price, availability, shipping and returns.
Variable products get their own treatment. Google’s guidance on product variant structured data describes using the ProductGroup type with properties like variesBy and hasVariant so that sizes and colours are understood as variations of one parent product rather than separate items. For apparel, footwear and electronics retailers this is the difference between your catalogue being understood and being guessed at.
In practice an SEO plugin usually generates this markup for you. Worth confirming it is actually producing it, and that the fields it relies on are populated rather than empty.
Worth deciding early: whether you will list products in Arabic as well as English. Retrofitting a second language across a full catalogue is far more work than building it in from the start, and a meaningful share of UAE shoppers search in Arabic.
Categories Are for Shoppers, Not for Reports
POS categories are usually built for reporting. They might split by supplier, by margin band, or by whoever set the system up years ago. Those groupings are useful to you and meaningless to a customer.
Web categories need to mirror how someone shops. A customer looking for a gift does not think in supplier codes, they think in occasions and recipients. The two structures can coexist, with reporting categories staying in the POS while the website carries its own shopper-facing tree, provided the mapping between them is defined rather than improvised.
Clean Before You Sync, Not After
The temptation is to connect everything, see what the site looks like, and tidy up afterwards. That order costs more than it saves. Once products are live they get indexed, linked and bookmarked, and changing names or restructuring categories later means managing redirects rather than simply editing a field.
A workable sequence is to audit what you have, fix names and attributes on your top sellers, photograph those first, and launch with a narrower range that is genuinely ready. The rest follows in batches. This pairs naturally with the advice in the first post in this series about choosing which part of your inventory goes online first.
MultiTech POS holds product data, attributes, images and identifiers in the same stock management system your counter already uses, and pushes them to your site through the WooCommerce POS integration, so the catalogue you clean up once serves both channels rather than drifting into two versions.
Not sure your catalogue is ready to go online?
Book a demo and we will look at your existing product data and what it would take to get it web ready.
Frequently Asked Questions
1. Do we have to rewrite every product name before going online? No. Start with your best sellers, since a small share of products usually drives most sales, then work through the rest in batches.
2. How many images does a product page need? A main shot on a plain background, two or three supporting angles, and ideally one in use. Consistency across the catalogue matters more than perfection on any one image.
3. Why do our category filters return so few results? Usually inconsistent attribute values. If the same colour is stored several different ways, a filter only matches the products using that exact spelling.
4. Do we need barcodes on our website? They are not required to sell, but product identifiers help search engines understand what you are listing, which affects how your products appear in shopping results.
5. Should we list products in Arabic as well as English? Worth deciding before launch rather than after. Adding a second language to an established catalogue is considerably more work than building it in from the start.