Tag: PIM

  • How to Find and Eliminate Duplicate SKUs in Your Product Catalog

    How to Find and Eliminate Duplicate SKUs in Your Product Catalog

    How to Find and Eliminate Duplicate SKUs in Your Product Catalog

    Duplicate SKUs are one of the most damaging catalog quality problems because they are invisible until they cause a serious incident — wrong products shipping to customers, inventory counts that do not match reality, Google Shopping disapprovals from duplicate product identifiers. And they are extremely common. Most catalogs that have grown over several years without strict governance have duplicate records that have never been identified.

    How Duplicate SKUs Form

    Duplicate SKUs rarely appear overnight. They accumulate through specific, predictable patterns:

    • Multiple people creating SKUs manually without a centralised reference — two team members independently create records for the same product using different SKU formats
    • Supplier data imports without duplicate checking — supplier feeds include products already in your catalog, creating a second record with the supplier’s SKU alongside your existing record
    • Platform migrations — importing products from one system to another creates duplicates when migration logic fails to match existing records
    • SKU reuse after product discontinuation — a discontinued product’s SKU is reassigned to a new product, creating historical confusion even if it is not technically a current duplicate
    • Variant management errors — each size/colour combination of a product is created as a standalone product instead of as variants, with new SKUs each time

    The Business Impact of Duplicate SKUs

    ProblemImpact
    Inventory split across duplicate recordsStock appears lower than it is in each record — triggers false out-of-stock, missed sales, unnecessary reorders
    Wrong record picked for ordersWrong product ships, or the correct product ships but from the wrong inventory pool
    Google Shopping feed errorsTwo products with the same GTIN in one feed cause disapprovals for both
    Two site listings for same productCustomers see duplicate listings, sales and reviews are split, cannibalisation of the same keyword
    Split sales historyPerformance reports undercount actual sales, making reorder and pricing decisions unreliable

    Step-by-Step: Finding Duplicate SKUs

    Method 1: Exact SKU duplicates

    Export your full product list with SKU as the first column. Sort by SKU. Any SKU that appears more than once is a confirmed exact duplicate. Flag all instances and review which is the canonical record (typically the older record with more order history).

    Method 2: GTIN-based duplicates

    Export your product list with GTIN column. Sort by GTIN. Any GTIN that appears more than once (excluding variant records that legitimately share a parent GTIN) is a duplicate product with different SKUs. These are the most common type of duplicate in catalogs built from multiple supplier data imports.

    Method 3: Name similarity duplicates

    Sort your product list by Product Name. Review near-matches — “Columbia Rain Jacket Men Navy L” and “Columbia Waterproof Jacket Men Navy L” may be the same product entered twice with slightly different names. These require manual review because naming differences can be legitimate variants.

    The Duplicate Detector automates all three detection methods across your full catalog and returns a prioritised list of confirmed and suspected duplicates for review.

    How to Prevent Duplicate SKUs From Recurring

    1. Unique SKU enforcement — configure your platform or PIM to reject any SKU that already exists in the system. This is the single most effective prevention mechanism.
    2. Centralised SKU generation — assign SKUs through one system using a defined naming convention rather than allowing team members to create them manually. A sequential number generator or structured code generator (BRAND-CAT-001) eliminates manual SKU conflicts.
    3. GTIN validation at import — when importing supplier data, check incoming GTINs against your existing catalog before creating new records. If a GTIN already exists, update the existing record rather than creating a new one.
    4. Never reuse discontinued SKUs — mark discontinued products as inactive rather than deleting them, and never reassign their SKUs to new products. SKU history must remain intact for order history and audit purposes.

    Run a duplicate check monthly using the Duplicate Detector as part of your routine catalog maintenance. For the full catalog health audit process, see How to Audit Your Product Catalog in One Weekend.

    Frequently Asked Questions

    What causes duplicate SKUs in ecommerce catalogs?

    The most common causes are: multiple team members creating SKUs without a centralised system, importing supplier data without checking for existing records, platform migrations that duplicate product records, and SKU conventions that allow reuse after product discontinuation. Supplier data imports are the most frequent source of externally-introduced duplicates in mid-to-large catalogs.

    What problems do duplicate SKUs cause?

    Inventory miscounts (stock split across two records), wrong products in orders (system picks wrong duplicate), Google Shopping feed errors (duplicate GTIN causes disapprovals for both records), site search returning two listings for the same product, and split sales history that makes performance reporting unreliable.

    How do I prevent duplicate SKUs from being created?

    Three mechanisms work together: unique SKU enforcement at the system level (reject any SKU that already exists), centralised SKU generation (all SKUs assigned by one system using a defined convention), and GTIN validation at import (check incoming product GTINs against existing records before creating new ones). Implementing all three eliminates the most common duplicate creation paths.

  • How to Build a Product Catalog From Scratch (Free Template Included)

    How to Build a Product Catalog From Scratch (Free Template Included)

    How to Build a Product Catalog From Scratch (Free Template Included)

    Building a product catalog correctly from the start prevents years of cleanup work later. A catalog built without a taxonomy, without consistent attribute definitions, and without SKU conventions accumulates inconsistency with every product added — until fixing it takes longer than rebuilding it from scratch would have. This guide covers how to build it right the first time.

    Step 1: Define Your Catalog Structure Before Adding Any Products

    The most common catalog building mistake is starting with products before defining the structure those products will sit in. Decide these three things first:

    • Universal fields — fields that every product record must have regardless of category: SKU, Product Name, Description, Price, Category, Brand, GTIN, Primary Image URL, Availability
    • Category-specific fields — attributes that apply only within specific subcategories: Colour, Size for apparel; Processor, RAM for electronics; Width, Height, Depth for furniture
    • Channel-specific fields — content generated specifically for each sales channel: Google Shopping Title, Amazon Bullet Points, Facebook Description

    Document this as a field specification. It becomes your data standard — the reference every team member uses when entering product data.

    Step 2: Build Your Taxonomy Before Your Products

    Your product taxonomy — the category hierarchy — must be designed before any products are entered. Products cannot be correctly catalogued without a taxonomy to put them in. A product entered before the taxonomy exists will be assigned to a category that may not match where it should go once the proper structure is in place.

    Design your taxonomy to at least three levels (Department → Category → Subcategory), define the attribute set for each subcategory, and map every subcategory to its Google product category ID. The full process is covered in How to Build a Product Taxonomy From Scratch. Use the free Product Taxonomy Template as your starting point.

    Step 3: Establish SKU Conventions Before Creating Records

    SKUs are permanent identifiers. Changing them after products are live in your platform, in customer orders, and in channel feeds is a significant operational task. Establish your SKU naming convention before creating any product records.

    Common conventions: BRAND-CATEGORY-VARIANT (e.g. COL-RJ-M8NVY for Columbia Rain Jacket Men Size 8 Navy), or a simpler numeric sequence. What matters is consistency — the same format for every SKU, with clear rules for how variants relate to parent SKUs.

    Step 4: Enter Required Attributes Before Optional Ones

    When entering product data, complete all required attributes across all products before moving to optional attributes. A catalog that is 100% complete on required fields and 0% complete on optional fields is more useful than one that is 60% complete on everything. Required completeness enables publishing and channel submission. Optional completeness improves performance over time.

    Step 5: Image Standards From Day One

    Establish image standards at the start: naming conventions, minimum dimensions (800×800px for Google Shopping), file format (JPEG for product shots), folder structure in your DAM or storage system. Retroactively standardising thousands of image files is one of the most time-consuming catalog cleanup tasks — avoid it by setting standards before the first image is added.

    Step 6: Validate Before Publishing

    Before any product goes live, run these checks:

    • Completeness check — all required fields populated for every product
    • GTIN validation — all product identifiers are valid format
    • Duplicate SKU check — no two products share the same identifier
    • Category assignment — every product is in the correct subcategory
    • Image URL validation — all image links load correctly

    The PIM Readiness Score assesses your current setup against these dimensions. Download the free catalog template at lynkpim.app — pre-structured with the field definitions, taxonomy, and validation rules to start from rather than a blank spreadsheet. For what to do once your catalog starts growing, see How to Manage 1,000+ SKUs Without Losing Your Mind.

    Frequently Asked Questions

    What fields should every product catalog include?

    Every product record needs at minimum: SKU, Product Name, Description, Price, Category, Brand, GTIN or identifier_exists = FALSE, Primary Image URL, and Availability status. Category-specific attributes (Colour, Size, Material etc.) are added per subcategory based on your taxonomy attribute sets. Channel-specific content fields (Google Shopping Title, Amazon Bullet Points) add value once basic data is complete.

    Should I build my product catalog in a spreadsheet or a PIM?

    Spreadsheets work for catalogs under approximately 200 SKUs with a single channel and a single person managing data. For anything larger or multi-channel, a dedicated PIM system is necessary to maintain data quality and prevent version control problems. Start with a well-structured spreadsheet template and migrate to a PIM when the spreadsheet starts breaking — which typically happens around 500 SKUs or when you add a second channel.

  • What Is Product Catalog Management? The Complete Guide for Ecommerce

    What Is Product Catalog Management? The Complete Guide for Ecommerce

    What Is Product Catalog Management? The Complete Guide for Ecommerce

    Product catalog management is how ecommerce businesses organise, maintain, and distribute their product data. It sounds operational — because it is. But it is also one of the highest-leverage functions in ecommerce growth, because product data quality directly determines how well products perform in search, on channels, and with customers.

    This guide covers what catalog management is, what it involves, why it matters at scale, and how to approach it without enterprise software or a large team.

    What Product Catalog Management Covers

    Product catalog management encompasses every activity involved in making product data accurate, complete, and available where it needs to be. In practice, this means:

    Product data creation and onboarding

    Creating new product records when products are added to the catalog — entering base data (SKU, name, description, price), assigning taxonomy categories, and populating attribute fields. For businesses with many suppliers, this includes receiving, cleaning, and transforming supplier-provided data into your catalog’s format.

    Taxonomy and category management

    Building and maintaining the category structure that organises your catalog — defining hierarchies, attribute sets per category, and the rules that determine where products belong. This is the structural foundation everything else is built on. See What Is Product Taxonomy for the full overview.

    Content enrichment

    Adding and improving the content that makes products sell — writing product descriptions, capturing or sourcing product images, adding marketing copy, and ensuring completeness of attributes that drive search and filter performance.

    Data quality management

    Monitoring and maintaining the accuracy and completeness of product data over time — fixing errors, normalising inconsistent attribute values, validating GTINs and product identifiers, and auditing for missing required data. This is ongoing, not a one-time project.

    Channel syndication

    Distributing product data to every channel where products are sold or marketed — website, Google Shopping, Amazon, Facebook Catalogue, wholesale buyers, print catalogs. Each channel has different format requirements, and catalog management includes managing those transformations without duplicating manual work.

    Variant management

    Managing the relationship between parent products and their variants (sizes, colours, materials) — ensuring each variant has correct identifiers, images, pricing, and stock information while maintaining the link to the parent product for shopping feed purposes (item_group_id).

    Why Catalog Management Matters for Ecommerce Growth

    Catalog management quality touches every commercial outcome in ecommerce:

    • Search and discovery: Complete, structured product data means products appear for the queries they should appear for — in site search and Google Shopping
    • Conversion rate: Accurate product data sets correct buyer expectations, which reduces returns and increases repeat purchase
    • Channel performance: Clean feed data means fewer disapprovals, better auction relevance, and higher ROAS
    • Operational efficiency: A well-managed catalog means teams spend less time fixing data errors and more time on commercial activities
    • Speed to market: A systematic catalog management process means new products launch faster because the workflow is defined, not ad hoc

    The Catalog Management Maturity Stages

    StageHow it looksTypical SKU range
    Stage 1: Ad HocProduct data in spreadsheets, one person “knows everything”, no formal processes1–200 SKUs
    Stage 2: StructuredDefined taxonomy, consistent attribute entry, single platform for product data, basic workflows200–2,000 SKUs
    Stage 3: GovernedValidation rules enforce completeness, channel-specific content, automated feed syndication, data quality monitoring2,000–20,000 SKUs
    Stage 4: AutomatedAI-assisted enrichment, real-time channel sync, self-service product publishing, catalog health dashboards20,000+ SKUs

    Most SMB ecommerce stores start at Stage 1 and need to reach Stage 2 or 3 to scale effectively. The transition from Stage 1 to Stage 2 is the most impactful — it is where the spreadsheet chaos ends and a governed catalog begins.

    What You Need to Manage a Product Catalog

    • A taxonomy: The category structure that organises your products. Without this, product data has no consistent home and filters do not work.
    • Attribute sets per category: The defined list of fields that must be filled for a product in each category to be considered complete.
    • A single source of truth: One place where authoritative product data lives. Either a spreadsheet (for small catalogs) or a PIM system (for anything larger).
    • Data validation rules: Rules that prevent incorrect or incomplete data from being published — required fields, controlled value lists, format checks.
    • Channel mapping: The translation layer that converts your internal product data to the format each channel requires — Google Shopping feed, Amazon flat file, Facebook catalogue.

    The PIM Readiness Score assesses where your current catalog management setup sits across all five of these dimensions and gives you a prioritised improvement list. The Catalog Health Score benchmarks the quality of your actual product data. Both are free, take under 10 minutes, and give you a clear picture of what to address first.

    For the practical next steps, start with How to Build a Product Catalog From Scratch, or if you are managing an existing catalog that has grown without structure, How to Audit Your Product Catalog in One Weekend.

    Frequently Asked Questions

    What is product catalog management?

    Product catalog management is the process of creating, organising, enriching, maintaining, and distributing product data across all the places it is used — your website, sales channels, marketing, and internal operations. It covers product data entry, taxonomy structure, attribute management, image management, channel syndication, and ongoing data quality.

    What is the difference between product catalog management and PIM?

    Catalog management is the practice — the ongoing process of managing your product data. PIM (Product Information Management) is the software category used to do it at scale. You can practice catalog management using spreadsheets, but at scale — more than a few hundred SKUs, multiple channels, multiple team members — a dedicated PIM becomes necessary to maintain data quality and operational efficiency.

    When does a business need formal product catalog management?

    Most businesses need formal catalog management processes once they cross approximately 200 SKUs, sell on more than one channel, have more than one person managing product data, or start experiencing data quality problems. The trigger is usually a data incident (wrong prices going live, products missing from Shopping) or a growth milestone that makes the current approach visibly unscalable.

    What does product catalog management software do?

    It centralises all product data in one place, enforces completeness and validation rules, manages relationships between products and variants, enables channel-specific content, automates feed generation and syndication, and provides visibility into data quality across the full catalog. The goal is a single source of truth that feeds every channel consistently and accurately.

  • Google Product Category vs Your Internal Taxonomy: What’s the Difference?

    Google Product Category vs Your Internal Taxonomy: What’s the Difference?

    Google Product Category vs Your Internal Taxonomy: What’s the Difference?

    Two taxonomies. One product. This is the reality of modern ecommerce — every product needs to live somewhere in your internal catalog structure, and simultaneously needs to be classified in Google’s own taxonomy for Shopping performance. These two systems serve completely different purposes and should never be confused for each other.

    Your Internal Taxonomy — What It’s For

    Your internal product taxonomy is the classification system you design for your own business. It reflects how your team organises products, how your customers browse your site, and how your buying and merchandising teams think about the catalog.

    It uses your naming conventions. “Outerwear” might be at Level 2 in your taxonomy. “Men’s Rain Jackets” might be your Level 3 subcategory. These names work for your team because they reflect how you buy, stock, and sell these products.

    Your internal taxonomy also drives your site navigation, search filters, and internal reporting. It is designed for humans — your buyers, your customers, and your ecommerce team. For a full guide on building it correctly, see What Is Product Taxonomy and How to Build a Product Taxonomy From Scratch.

    Google’s Product Category Taxonomy — What It’s For

    Google’s product category taxonomy is a fixed, hierarchical classification system that Google uses to understand what your product is. It has over 6,000 categories across up to 7 levels, maintained by Google and updated periodically.

    It is designed for Google’s matching algorithm — not for humans. When you assign a product to “Apparel & Accessories > Clothing > Outerwear > Coats & Jackets” (ID: 212), you are telling Google’s algorithm which auction pool this product belongs in, which additional attribute requirements apply, and how to match it to buyer search queries.

    You do not modify it. You map your products to it. The full taxonomy ID list is available publicly and should be used as a reference, not a foundation for your own catalog structure. Full details in the Google Product Category Taxonomy guide.

    The Key Differences

    Internal TaxonomyGoogle Product Category
    Who designs itYouGoogle
    Who it servesYour team and customersGoogle’s matching algorithm
    Naming conventionYour own namingGoogle’s fixed naming
    How deep3–4 levels typicalUp to 7 levels, 6,000+ nodes
    Where it livesYour PIM / platform / spreadsheetThe google_product_category feed field
    What it powersNavigation, filters, internal ops, reportingShopping auction relevance, attribute requirements, tax rules
    How often it changesWhen your catalog evolves1–2 times per year by Google
    Can you modify itYes — it’s yoursNo — you only map to it

    Why You Need Both — and Why They’re Different

    A common mistake is trying to build an internal taxonomy that mirrors Google’s. This creates several problems:

    • Google’s naming doesn’t match customer language — “Coats & Jackets” is fine for an algorithm but might not reflect how your buyers describe products on your site
    • Google’s structure doesn’t match your business — your business may organise products by season, by brand, by collection, or by customer segment in ways that don’t correspond to Google’s classification
    • Google updates break your internal structure — if your navigation and filters are built on Google’s taxonomy, every Google taxonomy update requires changes to your site

    Your internal taxonomy should be built for your customers and your team. Google’s taxonomy should be mapped to from your internal taxonomy — a separate, maintained mapping document that connects your subcategories to the correct Google category IDs.

    How to Build the Mapping Document

    The mapping document is a simple table: your internal subcategory name on the left, the corresponding Google category ID on the right. This is the only connection you need between your taxonomy and Google’s.

    1. List every subcategory in your internal taxonomy
    2. For each subcategory, search Google’s taxonomy file for the most specific matching leaf node
    3. Record the numeric ID — not the text path string
    4. Apply the ID to all products in that subcategory programmatically — not product by product
    5. Review annually when Google publishes taxonomy updates

    This approach means a taxonomy change on Google’s side only requires updating the mapping document, not restructuring your internal taxonomy, your site navigation, or your product records.

    The product_type Field — the Third Layer

    Google Shopping feeds support a third category-related field: product_type. Unlike google_product_category, this is a free-form field you control completely.

    Use product_type to include your internal taxonomy path in the feed — for example, “Outerwear > Men’s Outerwear > Rain Jackets”. This value does not affect Google’s matching algorithm but it does appear as a segmentation option in Google Ads, letting you create Shopping campaigns and bid strategies based on your own category structure rather than Google’s.

    This means you can have all three in your feed simultaneously:

    • google_product_category: 212 (tells Google what the product is)
    • product_type: Outerwear > Men’s Outerwear > Rain Jackets (your internal naming for campaign segmentation)
    • Internal taxonomy: stored in your PIM, driving your site and your team’s workflow

    Check the Flat vs Hierarchical Taxonomy guide to ensure your internal structure is appropriately deep before building your mapping document. Take the PIM Readiness Score to see how well your current product data governance supports this dual-taxonomy approach.

    Frequently Asked Questions

    Do I need both an internal taxonomy and Google product categories?

    Yes. Your internal taxonomy serves your team and customers using your naming conventions. Google’s taxonomy serves their matching algorithm using their naming conventions. You need both, connected by a mapping document that translates your subcategory names to Google category IDs.

    Should I build my internal taxonomy to match Google’s?

    No. Build your internal taxonomy for how your team and customers think about your products. Keep the mapping to Google’s taxonomy in a separate document. If you build your internal structure to mirror Google’s, you tie your site navigation and team workflows to a taxonomy you don’t control — and every Google update risks breaking something in your catalog.

    What is the product_type field and how does it relate to my internal taxonomy?

    The product_type field is a free-form field in your Google Shopping feed where you include your own internal category path. It does not affect Google matching but enables campaign segmentation in Google Ads based on your own taxonomy naming. It is the bridge between your internal taxonomy and your Google Shopping campaigns.

    How often does Google’s taxonomy change and how does that affect my internal taxonomy?

    Google updates its taxonomy 1–2 times per year. These changes do not affect your internal taxonomy at all — they only affect the mapping document. Using numeric IDs in your feed (not text path strings) means most updates have zero impact on your feed, since IDs remain valid even when Google renames a category path.

  • Product Taxonomy for Food and Beverage Ecommerce: Full Setup Guide

    Product Taxonomy for Food and Beverage Ecommerce: Full Setup Guide

    Product Taxonomy for Food and Beverage Ecommerce: Full Setup Guide

    Food and beverage ecommerce has a taxonomy challenge that no other category faces at the same level: regulatory compliance. Allergen data, nutritional information, country of origin, and storage requirements are not optional attributes — they are legal requirements in most markets. A food taxonomy that gets the category hierarchy right but misses the compliance attribute layer is both incomplete and a legal liability.

    This guide covers how to build a food and beverage taxonomy that works for customers, for Google Shopping, and for regulatory compliance simultaneously.

    Why Food Taxonomy Needs a Compliance Layer

    Food ecommerce has obligations that other ecommerce categories do not. In UK and EU markets, the Food Information for Consumers Regulation (FIC) requires that 14 major allergens are clearly identified on all pre-packaged food products sold online. Nutritional information per 100g is also required for most food products.

    This means your product taxonomy must support a compliance attribute layer — not just a category hierarchy. Every food product record needs structured allergen fields, nutritional values, and country of origin. These cannot be buried in free-text descriptions — they must be structured attributes that can be displayed, filtered, and audited.

    For the foundational taxonomy structure applicable to all industries before adding food-specific requirements, see How to Build a Product Taxonomy From Scratch.

    Recommended Top-Level Structure for Food and Beverage

    Level 1Level 2 ExamplesLevel 3 Examples
    Fresh & ChilledDairy, Meat & Poultry, Fruit & Vegetables, Ready Meals, DeliMilk, Cheese, Yogurt, Butter & Spreads
    Ambient GroceryPasta & Rice, Tinned Goods, Sauces & Condiments, Oils & VinegarsDried Pasta, Tinned Tomatoes, Pasta Sauces
    BeveragesCoffee, Tea, Soft Drinks, Juices, Water, Hot ChocolateGround Coffee, Whole Bean, Coffee Pods
    FrozenFrozen Meals, Frozen Meat, Ice Cream, Frozen Vegetables, Frozen BakeryFrozen Pizza, Frozen Fish Fillets
    Health & NutritionProtein Supplements, Vitamins, Sports Nutrition, SuperfoodsWhey Protein, Plant Protein, BCAA
    Snacks & ConfectioneryCrisps, Nuts, Chocolate, Sweets, Cereal Bars, BiscuitsDark Chocolate, Milk Chocolate, Vegan Chocolate
    BakeryBread, Pastries, Cakes, Gluten-Free BakerySourdough, White Sliced, Seeded Loaves
    AlcoholWine, Beer & Cider, Spirits, Low & No AlcoholRed Wine, White Wine, Champagne & Sparkling

    The 14 Mandatory Allergen Attributes

    Each of the 14 major allergens must be a separate structured attribute on every food product record with three possible values:

    • Contains — the allergen is a declared ingredient
    • May Contain — manufactured in a facility that also processes this allergen (cross-contamination risk)
    • Free From — the product does not contain and is not cross-contamination risk for this allergen

    The 14 allergens are: Gluten, Crustaceans, Eggs, Fish, Peanuts, Soybeans, Milk, Nuts, Celery, Mustard, Sesame, Sulphur Dioxide & Sulphites, Lupin, Molluscs.

    Structured allergen attributes enable allergen-specific filtering (customers can filter “Nut-Free” or “Gluten-Free”) and allow your compliance team to audit allergen data across the full catalog efficiently. Free-text allergen data in descriptions cannot be audited or filtered.

    Dietary Attribute Set

    Beyond the mandatory allergen layer, structured dietary attributes drive high-value customer filtering. These are among the most-used filters on food ecommerce sites:

    • Vegan — contains no animal products or by-products
    • Vegetarian — contains no meat or fish
    • Gluten-Free — certified gluten-free (below 20ppm threshold)
    • Dairy-Free — contains no milk or dairy derivatives
    • Nut-Free — contains no nuts and produced in a nut-free facility
    • Halal — certified Halal
    • Kosher — certified Kosher
    • Organic — certified organic (specify certification body)
    • No Added Sugar
    • Low Calorie (define threshold — e.g. <100kcal per serving)

    Shelf Life and Storage Attributes

    Storage and shelf life attributes serve both customer information and operational fulfilment routing. Products with different storage requirements (ambient, chilled, frozen) need to be identifiable programmatically — your fulfilment system needs to know which warehouse zone and which delivery service applies to each product.

    • storage_type: ambient / chilled (2-8°C) / frozen (-18°C)
    • shelf_life_days: total shelf life from production date
    • minimum_remaining_life_on_despatch: minimum days remaining when shipped (e.g. 60% of total shelf life)
    • best_before_guidance: “Best Before”, “Use By”, “Display Until” — the label type

    Nutritional Attributes (Required for UK/EU Markets)

    Under UK FIC regulations, the following nutritional values are required per 100g/100ml on food product pages:

    • Energy (kJ and kcal)
    • Total Fat (g)
    • Saturated Fat (g)
    • Carbohydrates (g)
    • Sugars (g)
    • Protein (g)
    • Salt (g)

    These must be structured attributes in your product data — not embedded in label images. Structured data can be indexed by search engines, displayed dynamically, and audited for completeness. Image-embedded nutritional data cannot.

    Google Product Category Mapping for Food

    ProductCorrect Google Category
    Ground coffeeFood, Beverages & Tobacco > Beverages > Coffee
    Whey protein powderHealth & Beauty > Health Care > Fitness Nutrition > Protein Supplements
    Gluten-free pastaFood, Beverages & Tobacco > Food Items > Grains, Rice & Pasta
    Red wineFood, Beverages & Tobacco > Beverages > Alcoholic Beverages > Wine
    Vegan chocolate barFood, Beverages & Tobacco > Food Items > Sweets & Snacks > Candy & Chocolate

    Managing allergen data, nutritional values, and shelf life attributes at scale across a large food catalog requires a system that enforces attribute completeness before products are published. The PIM Readiness Score identifies exactly where your current data governance has gaps. Download the free Taxonomy Template at lynkpim.app — the Food & Beverage tab includes the full category hierarchy and compliance attribute set.

    For context on how food taxonomy compares structurally to another attribute-heavy category, see the Home Goods Taxonomy guide.

    Frequently Asked Questions

    Are allergen attributes legally required for food ecommerce in the UK?

    Yes. Under the UK Food Information for Consumers Regulation (FIC), all 14 major allergens must be clearly indicated on pre-packaged food products sold online. Structured allergen attributes ensure these are displayed accurately, consistently, and can be audited across the full catalog. Free-text allergen data in descriptions does not meet this standard reliably.

    How should dietary attributes like Vegan and Gluten-Free be structured?

    Dietary attributes should be structured boolean or controlled-value attributes on every food product — not free-text descriptions. Structured dietary attributes enable accurate site filtering, prevent manual errors when products are updated, and allow your compliance team to audit attribute accuracy across the full catalog at any time.

    Should food categories be organised by cuisine type or by food category?

    Organise by food type (Dairy, Bakery, Beverages) rather than cuisine (Italian, Asian, Mexican) for the primary taxonomy structure. Cuisine and origin work well as filterable attributes. Type-based categories map directly to Google’s taxonomy and match how customers search for food online — “gluten-free pasta” not “Italian gluten-free”.

    What shelf life attributes should food products have?

    Include storage_type (ambient / chilled / frozen), shelf_life_days (total from production), minimum_remaining_life_on_despatch (days remaining when shipped to customer), and best_before_guidance (Best Before / Use By / Display Until). These drive fulfilment routing, customer-facing freshness communication, and return rate management.

    Does Google Shopping allow food and beverage products?

    Yes, food and beverage products are allowed in Google Shopping with some exceptions. Alcohol requires age verification compliance and may be restricted by country targeting. Supplements and health food products must comply with local regulations. Most ambient grocery, beverages, and specialty food products can be advertised without restrictions — verify your specific product types in Google Merchant Center’s product data specification.

  • Product Taxonomy for B2B Industrial Products: The Complete Guide

    Product Taxonomy for B2B Industrial Products: The Complete Guide

    Product Taxonomy for B2B Industrial Products: The Complete Guide

    B2B industrial product taxonomy is the most technically demanding category structure in ecommerce. Industrial buyers know exactly what they need — often down to a part number, material grade, and certification standard. A taxonomy that cannot surface products by technical specification loses B2B buyers immediately, because they will not browse to find the right hydraulic fitting. They will go somewhere that lets them specify it.

    This guide covers how to build an industrial taxonomy that works for procurement buyers, engineers, and maintenance teams — not just for general consumers.

    Why B2B Industrial Taxonomy Differs from B2C

    • Part number is the primary identifier: B2B buyers often search by manufacturer part number (MPN) or internal reference code. Your taxonomy must support this lookup path, not just category browsing.
    • Technical specifications are purchase criteria: An industrial buyer does not choose a bolt by colour. They specify thread standard (M6, M8, M10), material grade (Grade 8.8, 304 stainless, A4 marine grade), head type (hex, socket cap, button head), and length in millimetres.
    • Compliance is non-negotiable: Many industrial products require specific certifications (CE, ATEX, RoHS, REACH, IP ratings) and buyers will not purchase without visible certification data.
    • Volume and price structures: B2B products often have quantity-break pricing and minimum order quantities — these need to be attributes, not ad hoc product descriptions.

    For the foundational taxonomy build process before B2B-specific requirements, see How to Build a Product Taxonomy From Scratch.

    Start With a Standard Classification System

    Unlike B2C categories where you build from customer search behaviour, B2B industrial taxonomy should be anchored to an established classification standard. Do not build from scratch.

    • UNSPSC (United Nations Standard Products and Services Code) — widely used in procurement and public sector. Free to access at unspsc.org. Four-level hierarchy: Segment → Family → Class → Commodity.
    • eCl@ss — European standard, widely used in manufacturing and industrial supply chains. More granular than UNSPSC for technical components.
    • GS1 GPC (Global Product Classification) — used in retail and wholesale supply chains. Better for MRO and maintenance products than for pure manufacturing components.

    You do not need to expose these classification codes to buyers. Use them as the structural backbone of your internal taxonomy, then create buyer-friendly category names as a display layer on top.

    Recommended Top-Level Structure for Industrial

    Level 1Level 2 ExamplesLevel 3 Examples
    Fasteners & FixingsBolts, Nuts, Washers, Anchors, Rivets, ScrewsHex Bolts, Socket Cap Screws, Coach Bolts
    Pneumatics & HydraulicsFittings, Valves, Cylinders, Hoses, PumpsPush-fit Fittings, Compression Fittings
    Electrical ComponentsConnectors, Cable Management, Switches, RelaysDIN Rail Connectors, Terminal Blocks
    Safety EquipmentPPE, Eye Protection, Respiratory, Fall ProtectionSafety Helmets, Hi-Vis Jackets
    Tools & MachineryHand Tools, Power Tools, Measuring, CuttingTorque Wrenches, Digital Callipers
    MRO SuppliesLubricants, Cleaning, Sealing, AdhesivesBearing Grease, Thread Sealant
    Pipe & TubeSteel Pipe, Copper Tube, Plastic Pipe, FittingsStainless Steel Tube, HDPE Pipe

    Technical Specification Attributes

    Fasteners (Bolts, Nuts, Screws)

    • Required: Thread standard (M4, M6, M8, M10 etc.), Material grade (Grade 8.8, Grade 10.9, A2 stainless, A4 marine), Head type, Length (mm), Finish (zinc plated, hot dip galvanised, plain)
    • Recommended: Tensile strength (MPa), Hardness (HRC), Drive type, Standards compliance (DIN, ISO, BS, ANSI), Minimum order quantity, Pack size

    Pneumatic Fittings

    • Required: Connection type (push-fit, compression, threaded), Port size (BSP, NPT, metric), Tube OD (mm), Material (brass, stainless, nylon), Max pressure (bar), Temperature range (°C)
    • Recommended: Flow rate (l/min), Seal material (NBR, EPDM, PTFE), ATEX rated (yes/no), IP rating

    Safety Equipment (PPE)

    • Required: CE marking (yes/no), Standard compliance (EN 397, EN 388, EN 166 etc.), Protection class, Size/Fit range, Material
    • Recommended: EN standard version year, Shelf life, Cleaning instructions, Compatible with other PPE items

    Compliance and Certification Attributes

    Compliance data is what separates a functional industrial taxonomy from an inadequate one. B2B buyers in regulated industries (construction, oil and gas, food processing, pharmaceuticals) cannot purchase without verified compliance data.

    • CE marking: Yes / No — mandatory for products sold in EU/UK regulated categories
    • ATEX certification: Zone rating — for equipment used in explosive atmospheres
    • RoHS compliance: Yes / No — restriction of hazardous substances in electrical equipment
    • REACH compliance: SVHC declaration — substances of very high concern disclosure
    • IP rating: IP54, IP65, IP67 etc. — ingress protection for electrical and electronic products
    • Industry standards: DIN, ISO, BS, ANSI, ASTM — the specific standard and version the product is manufactured to

    Part Number Structure as Taxonomy Signal

    In B2B industrial catalogs, the part number (MPN — Manufacturer Part Number) is often the most important search term. Procurement buyers copy part numbers from approved vendor lists and search for exact matches. Your product records must include manufacturer part numbers, and your site search must index them.

    Beyond search, consider encoding category information into your internal part number format. A part number structure like CAT-MFR-SPEC-VARIANT means any product ID immediately signals its category, manufacturer, and variant — making catalog management programmatic rather than dependent on correct manual categorisation.

    The PIM Readiness Score identifies where your current B2B catalog data governance has gaps — particularly around technical specification completeness and compliance attribute coverage. The free Taxonomy Template at lynkpim.app includes the B2B Industrial tab with a pre-built category structure and attribute set.

    For a comparison of how B2B industrial taxonomy differs structurally from consumer categories, see the Home Goods Taxonomy guide as a contrast point.

    Frequently Asked Questions

    What classification standard should I use for B2B industrial taxonomy?

    UNSPSC is the most widely adopted standard for industrial and procurement catalogs globally. eCl@ss is preferred in European manufacturing and engineering contexts. Use the standard most common in your target buyer’s procurement system — many enterprise procurement platforms require UNSPSC codes on purchase orders and will not process invoices without them.

    How important is part number (MPN) in B2B industrial taxonomy?

    Extremely important. B2B buyers frequently search by exact manufacturer part number copied from an approved vendor list or Bill of Materials. Your site search must index MPNs and your product records must include both your internal part number and the manufacturer’s part number. Missing MPN data means losing buyers who search by part number — which is a significant share of B2B industrial search volume.

    What compliance attributes should industrial products have?

    At minimum: CE marking status, relevant EN/ISO/DIN/ANSI standards compliance, RoHS status for electrical products, and IP rating where applicable. ATEX certification is mandatory for products used in potentially explosive atmospheres. REACH SVHC declarations are required for products containing substances of very high concern sold in EU/UK markets.

    How do you handle quantity pricing in a B2B product taxonomy?

    Quantity break pricing and minimum order quantities should be structured product attributes, not free-text in descriptions. Store them as structured fields: min_order_qty, pack_size, and pricing tiers with corresponding quantity thresholds. This enables filter by minimum order, automated price calculation, and correct price display in Shopping feeds.

    Should B2B industrial products use the same Google Shopping feed structure?

    Yes, the same Merchant Center feed structure applies. B2B industrial products benefit significantly from detailed technical specifications in the product description (which Google indexes), and from the deepest available google_product_category value. Many B2B industrial searches are long-tail and highly specific — title construction should include thread standard, material grade, and key certifications where character limits allow.

  • Product Taxonomy for Home Goods and Furniture: The Complete Guide

    Product Taxonomy for Home Goods and Furniture: The Complete Guide

    Product Taxonomy for Home Goods and Furniture: The Complete Guide

    Home goods and furniture present a taxonomy challenge that is distinct from fashion or electronics. Products are large, physical, and often customisable. Customers search by room, by style, by material, and by dimension — sometimes all at once. A sofa is not just a sofa: it is a 3-seater, right-hand-facing, grey velvet, Scandi-style corner sofa with a specific width that must fit through a standard doorframe.

    This guide covers how to build a home goods taxonomy that handles all of those dimensions without becoming unmanageable.

    Room-Based vs Type-Based Hierarchy: Which to Choose

    The first decision in home goods taxonomy is whether to organise by room or by product type at the top level. Both approaches appear in the market. Both have genuine pros and cons.

    Room-Based (Living Room, Bedroom, Kitchen)Type-Based (Sofas, Beds, Tables)
    Customer navigationIntuitive for browsing by project (“doing up my bedroom”)Intuitive for specific product search (“I need a sofa”)
    Cross-room productsProblem — a side table works in bedroom AND living roomNo problem — side tables are just side tables
    Google Shopping mappingDifficult — Google organises by type, not roomEasy — maps directly to Google taxonomy
    SEORoom keywords have high volume but low commercial intentType + material + size keywords have high commercial intent
    VerdictWorks for editorial/inspiration contentBetter for ecommerce catalog and feed performance

    The recommended approach: use type-based categories as your primary taxonomy structure and add room as a filterable attribute on each product. This gives customers both navigation paths without creating structural problems for products that belong in multiple rooms. For a full comparison of hierarchy approaches, see Flat vs Hierarchical Taxonomy.

    Recommended Top-Level Structure for Home Goods

    Level 1Level 2 ExamplesLevel 3 Examples
    FurnitureSofas, Beds, Tables, Storage, Chairs, WardrobesCorner Sofas, 2-Seater Sofas, Sofa Beds
    LightingCeiling Lights, Floor Lamps, Table Lamps, Wall LightsPendant Lights, Chandeliers, Spotlights
    Bedding & TextilesDuvet Sets, Pillowcases, Throws, Curtains, RugsKing Duvet Sets, Blackout Curtains
    Kitchen & DiningCookware, Tableware, Kitchen Storage, AppliancesNon-stick Pans, Dinner Sets, Knife Blocks
    Storage & OrganisationShelving, Boxes & Baskets, Hooks, Drawer OrganisersFloating Shelves, Wicker Storage Baskets
    Home DecorMirrors, Vases, Picture Frames, Candles, ArtworkWall Mirrors, Full-Length Mirrors
    OutdoorGarden Furniture, Outdoor Lighting, Planters, BBQsGarden Dining Sets, Garden Sofas

    Attribute Sets for Home Goods

    Furniture (Sofas, Tables, Chairs, Beds)

    • Required: Brand, Colour, Material (primary), Dimensions (W × H × D in cm), Weight (kg), Assembly required (yes/no)
    • Recommended: Frame material, Leg material, Interior style, Room (Living Room / Bedroom / etc.), Maximum load (kg), Flat pack (yes/no), Number of seats (sofas/chairs)
    • Google category: Furniture → [specific type] e.g. Furniture > Sofas & Sectionals

    Lighting

    • Required: Brand, Colour/Finish, Fitting type (E27, B22, GU10 etc.), IP rating (for outdoor/bathroom), Material
    • Recommended: Bulb included (yes/no), Bulb type, Max wattage, Dimmable (yes/no), Height (cm), Shade diameter (cm), Interior style
    • Google category: Furniture > Lamps & Lighting > [specific type]

    Bedding & Textiles

    • Required: Brand, Colour, Size (Single / Double / King / Super King), Material composition, Care instructions
    • Recommended: Thread count (sheets), Tog rating (duvets), Pattern, Weave type, Hypoallergenic (yes/no)
    • Google category: Home & Garden > Linens & Bedding > [specific type]

    Dimension Attributes — Non-Negotiable for Furniture

    Dimension data is the most common missing attribute in home goods feeds, and it is the attribute customers are most likely to abandon without when making a buying decision. Furniture customers need to know if a sofa fits their space before they buy. A sofa listing without dimensions loses that sale before it begins.

    • Width, Height, Depth: In centimetres. Required for all furniture and large home goods.
    • Seat height: For chairs and sofas — critical for accessibility and ergonomics.
    • Weight: In kilograms. Important for customer planning and delivery expectations.
    • Assembly required: Yes / No — customers plan their time around this.
    • Flat pack: Yes / No — relevant for customers with size-restricted access (e.g. lifts, narrow staircases).

    Material Management in Home Goods

    Material naming in home goods has the same problem as colour naming in fashion. Marketing names (“Smoked Oak”, “Brushed Concrete Effect”, “Warm Walnut”) are meaningful to buyers but problematic for site filters and Google Shopping.

    Use a two-field approach: store the marketing material name for product copy and an additional normalised material value for filtering and feed submission:

    • Smoked Oak → Oak
    • Brushed Concrete Effect → Concrete / MDF
    • Warm Walnut Veneer → Walnut
    • Hammered Antique Brass → Brass

    Without normalised material values, your filter “Shop by Material” becomes unusable — customers cannot find all oak products because they appear under fifteen different marketing material names.

    Style as a Filterable Attribute

    Interior style — Modern, Scandinavian, Industrial, Traditional, Coastal, Maximalist — is a genuine purchase driver for home goods customers. But style should be a filterable attribute, not a category. Here is why:

    • A product can have multiple applicable styles — a rattan sofa is both Coastal and Boho
    • Style trends change — “Cottagecore” did not exist as a search term five years ago; you cannot build permanent category structure on trends
    • Style categories create structural debt — “Industrial Living Room Furniture” and “Scandinavian Living Room Furniture” as subcategories double your category maintenance without adding navigational value

    Assign style values as multi-value attributes and surface them as filters. A product can carry two or three style tags and appear in all relevant filter results without duplicating the product record.

    Google Product Category Mapping for Home Goods

    ProductCorrect Google Category
    3-seater sofaFurniture > Sofas & Sectionals
    King size bed frameFurniture > Beds & Bed Frames
    Pendant ceiling lightFurniture > Lamps & Lighting > Ceiling Lights & Fans
    King duvet setHome & Garden > Linens & Bedding > Duvet Covers
    Non-stick frying panKitchen & Dining > Cookware > Frying Pans & Skillets
    Floating shelfFurniture > Shelving > Wall Shelves & Ledges

    Once your home goods taxonomy is structured, managing dimension attributes and material values at scale benefits significantly from a PIM that enforces attribute completeness before products are published. Take the PIM Readiness Score to identify your current gaps, or download the free Taxonomy Template — including the Home Goods & Furniture tab — at lynkpim.app.

    For a broader framework applicable across all industries before diving into home-specific requirements, see How to Build a Product Taxonomy From Scratch.

    Frequently Asked Questions

    Should a home goods taxonomy be room-based or product-type-based?

    Product-type-based is recommended for the primary taxonomy structure. Room should be a filterable attribute on each product, not a top-level category. This avoids the structural problem of cross-room products and maps far more cleanly to Google’s product taxonomy — which organises by type, not by room.

    What dimension attributes are required for furniture?

    Width, Height, and Depth in centimetres are required for all furniture and large home goods. Additionally include Weight (kg), Assembly Required (yes/no), and Flat Pack (yes/no). Seat height is strongly recommended for chairs and sofas as it is a key purchase decision factor.

    How should interior style be handled in a home goods taxonomy?

    Style should be a multi-value filterable attribute, not a permanent category. One product can carry multiple style tags — Coastal and Boho, for example — and appear in all relevant filter results without duplicating the product record. Creating style-named categories creates structural debt that becomes difficult to manage when interior trends shift.

    What Google product category should I use for sofas?

    Use the leaf-node: Furniture > Sofas & Sectionals. Avoid parent categories like “Furniture” alone. The more specific your Google product category, the better your Shopping feed relevance and the more accurately Google matches your products to buyer queries.

    How should material be managed in a home goods taxonomy?

    Use a two-field approach: marketing material name (Smoked Oak, Warm Walnut Veneer) for customer-facing copy, and a normalised material value (Oak, Walnut) for feed attributes and site filters. Without normalised values, your “Shop by Material” filter becomes a list of marketing names rather than a useful browsing tool.

  • PIM to Google Shopping: How to Connect Your Product Data

    PIM to Google Shopping: How to Connect Your Product Data

    PIM to Google Shopping: How to Connect Your Product Data

    Managing product data in a PIM and managing a Google Shopping feed are often treated as two separate problems. They are not. Your PIM is the source of truth. Google Shopping is a channel that consumes that truth. The connection between them determines whether your Shopping feed performs or constantly breaks.

    This guide covers how to build that connection correctly — from attribute mapping to feed delivery to ongoing automation.

    Why PIM-to-Shopping Connections Break

    Most PIM-to-Shopping problems come from one of three sources:

    • Attribute mismatch: Your PIM stores data under different field names than Google expects. “Product Name” in your PIM needs to become a correctly structured “title” in the feed — not just passed through as-is.
    • Missing transformation logic: Google requires assembled values like a constructed title or formatted price. If your PIM passes raw values without transformation rules, the feed output is incomplete.
    • Stale feed delivery: Prices and stock change constantly. A feed that updates weekly generates price mismatch disapprovals every time your site runs a sale or a product goes out of stock.

    For a full reference on what Google Shopping feeds require before you start mapping, the Google Shopping Feed Guide covers every required and recommended attribute.

    Step 1: Build Your Attribute Mapping Document

    Before writing a single line of integration code or configuring any connector, build a mapping document. This is a simple table: left column is your PIM field name, right column is the Google Shopping attribute it maps to.

    PIM FieldGoogle Shopping AttributeTransformation Required?
    Product ID / SKUidNo — pass through directly
    Product NametitleYes — assemble from Brand + Attributes + Type
    Long DescriptiondescriptionOptional — strip HTML tags
    Product URLlinkNo — pass through directly
    Primary Image URLimage_linkNo — ensure 800×800px minimum
    Retail PricepriceFormat as 29.99 GBP
    Sale Pricesale_priceInclude sale_price_effective_date
    Stock StatusavailabilityMap: In Stock → in stock, Out of Stock → out of stock
    EAN / BarcodegtinValidate format before passing
    ManufacturerbrandNo — pass through directly
    Google Category IDgoogle_product_categoryMust be leaf-node ID, not text string
    ColourcolorNormalise to human-readable value
    SizesizeAdd size_system attribute separately
    Parent SKUitem_group_idApply to all variants of same style

    Step 2: Set Up Title Construction in Your PIM

    The product title is the single most impactful attribute in a Google Shopping feed. A PIM-to-Shopping integration that just passes your PIM product name to Google as a title is almost always wrong — PIM product names are written for internal use, not for search query matching.

    Define a title construction formula in your PIM and generate the Shopping title programmatically from individual attribute fields:

    Formula: Brand + Gender + Material + Product Type + Colour + Size

    Store this as a channel-specific field in your PIM — a generated “Google Shopping Title” field that is separate from your internal product name and your website title. This allows you to optimise each independently.

    Step 3: Handle Channel-Specific Content

    One of the core advantages of a PIM over a spreadsheet is channel-specific content management. Your Google Shopping description, title, and certain attributes should differ from your website content and your Amazon content.

    • Google Shopping title: Optimised for search query matching — include all key attributes
    • Website title: Optimised for readability and brand tone — may be shorter or styled differently
    • Amazon title: Follows Amazon’s own title requirements — different format again
    • Description: Google Shopping descriptions are indexed but rarely shown. Focus on keyword density. Website descriptions should read naturally for humans.

    Without channel-specific fields in your PIM, teams either use the same content everywhere (suboptimal) or maintain separate spreadsheets per channel (which defeats the purpose of having a PIM).

    Step 4: Choose Your Feed Delivery Method

    Option A: Scheduled URL Fetch (recommended for most stores)

    Your PIM generates a feed file (XML or TSV) at a hosted URL. You register this URL in Google Merchant Center and set a fetch schedule — Google pulls a fresh copy at your specified frequency. Daily is the minimum; twice daily is better for stores with frequent price or stock changes.

    Option B: Google Content API

    Your PIM pushes product data directly to Google via the Content API, updating individual products as they change rather than uploading the full catalog on a schedule. This is the right approach for catalogs over 50,000 SKUs or stores with real-time price changes that cannot wait for a daily feed cycle.

    Option C: Manual or FTP file upload

    Export a feed file from your PIM and upload it to Merchant Center on a schedule via FTP/SFTP. Slower and more manual than option A, but workable for smaller catalogs with infrequent changes. Not recommended if your prices or stock change daily.

    The Google Shopping Feed Generator handles feed file generation and delivery setup without custom development. For supplemental feed use cases — like adding custom labels without modifying your primary feed — see the Supplemental Feeds guide.

    Step 5: Set Up Feed Refresh Frequency

    Feed freshness is one of the most common causes of Shopping disapprovals for stores that have otherwise clean feeds. Google requires that your feed reflects current prices and availability. When your site runs a flash sale or a product goes out of stock, your feed must update to match.

    • Price and availability: Update at minimum daily. Twice daily for stores with frequent promotions.
    • Product content (titles, descriptions, images): Weekly updates are sufficient — these rarely change.
    • New products: Submit immediately on launch via supplemental feed or Content API, rather than waiting for the next full feed cycle.

    Step 6: Validate and Monitor

    After your first feed submission, go directly to Merchant Center Diagnostics. It shows exactly which products are disapproved, which have warnings, and what attribute is causing each issue. Work through disapprovals first — these products are not appearing in Shopping at all. Then address warnings — these products appear but with limited performance.

    Run GTINs through the GTIN Validator before submission — invalid GTINs are the most common single cause of mass disapprovals on first feed submissions.

    Set up email alerts in Merchant Center for feed processing errors so you are notified when a feed fetch fails rather than discovering it a week later when performance drops.

    Ready to streamline your PIM-to-Shopping workflow? Check where your current product data setup stands with the PIM Readiness Score — free, 5 minutes. Or start building and exporting feeds directly with the Feed Generator tool.

    Frequently Asked Questions

    Can I connect any PIM to Google Shopping?

    Yes. Any PIM that can export a structured data file (XML, TSV, CSV) or call an API can be connected to Google Shopping. The key requirement is that your PIM can map its internal field names to Google’s required feed attributes and apply transformation rules where needed — particularly for title construction and value normalisation.

    How often should my Google Shopping feed update?

    At minimum daily for price and availability fields. Stores with frequent promotions or high-velocity stock changes should update twice daily. Product content fields like titles, descriptions, and images can update weekly — these change infrequently enough that daily updates add overhead without benefit.

    What is the difference between a primary feed and a supplemental feed?

    A primary feed contains all core product data. A supplemental feed adds or overrides specific attributes on top of the primary feed without replacing it. Supplemental feeds are useful for adding custom labels, overriding prices for specific markets, or adding attributes you cannot modify in your primary data source. Full details in the Supplemental Feeds guide.

    Do I need a developer to connect my PIM to Google Shopping?

    Not necessarily. If your PIM has a built-in Google Shopping connector or can export a correctly formatted feed file, no development is required. The LynkPIM Feed Generator handles feed generation and hosted delivery without custom development — no coding required.

    What happens if my PIM product titles are not optimised for Google Shopping?

    Unoptimised titles reduce Shopping relevance — your products appear in fewer auctions and at lower positions than competitors with complete titles. Google matches your title against search queries, so a title like “Men’s Jacket” loses every specific query to a competitor with “Columbia Waterproof Rain Jacket Men Navy Size L”. Title optimisation is the single highest-impact feed improvement for most stores.

  • Flat vs Hierarchical Product Taxonomy: Which Is Right for Your Catalog?

    Flat vs Hierarchical Product Taxonomy: Which Is Right for Your Catalog?

    Flat vs Hierarchical Product Taxonomy: Which Is Right for Your Catalog?

    The structure of your product taxonomy determines how your catalog scales, how your site filters work, and how well your products map to Google Shopping categories. Flat and hierarchical are the two fundamental structural approaches — and choosing the wrong one for your catalog size and complexity creates problems that get harder to fix the longer they go unaddressed.

    What Is a Flat Taxonomy?

    A flat taxonomy has a single level of categories. Products sit directly under a top-level category with no subcategories beneath it. The entire catalog structure is one layer deep.

    Example: A small accessories store with a flat taxonomy might have: Bags, Scarves, Hats, Belts, Sunglasses, Jewellery. Every product sits directly under one of those six categories. There are no subcategories — “Bags” is not further divided into Handbags, Crossbody Bags, Clutches, Tote Bags.

    Flat taxonomies are easy to set up and easy to understand at a glance. They work well when the catalog is small and products within each category are genuinely similar enough that no further subdivision adds value.

    What Is a Hierarchical Taxonomy?

    A hierarchical taxonomy has multiple nested levels. Categories contain subcategories, which may contain further subcategories, down to the most specific product type level.

    Example: The same accessories store with a hierarchical taxonomy: Bags > Handbags > Leather Handbags. Or Bags > Crossbody Bags. Each level adds specificity — and with it, the ability to filter, map to Google’s taxonomy precisely, and manage products by type without the entire “Bags” category becoming unnavigable.

    Head-to-Head Comparison

    Flat TaxonomyHierarchical Taxonomy
    StructureOne level — all categories at the same depthMultiple levels — categories contain subcategories
    Best forCatalogs under ~200 products, narrow rangeAny catalog with 200+ products or multiple product types
    NavigationSimple — works when categories are few and clearMore complex but enables breadcrumb navigation and drill-down filtering
    Filter accuracyLimited — attributes apply across entire categoryHigh — attributes defined per subcategory, filters are specific
    Google category mappingImprecise — top-level categories rarely match Google leaf nodesPrecise — subcategories map directly to Google taxonomy leaf nodes
    ScalabilityPoor — adding products creates category bloatHigh — hierarchy absorbs new product types without structural change
    MaintenanceLow initially, high as catalog growsHigher upfront, lower long-term
    Channel mappingDifficult — manual per-product mapping often requiredSystematic — subcategory maps once to each channel

    When Flat Taxonomy Works

    Flat taxonomies are appropriate in a small number of specific situations:

    • Catalog under 200 SKUs with a genuinely narrow product range where subcategories would be redundant
    • Single-category specialty stores — a store that sells only coffee beans, only yoga mats, or only one type of product doesn’t need a hierarchy
    • Early-stage stores planning to restructure as the catalog grows — a flat structure is a valid starting point if you know it will be replaced

    In all other cases, the limitations of flat taxonomy become apparent quickly as the catalog grows. The most damaging limitation is Google Shopping performance — flat taxonomy categories rarely correspond to Google’s taxonomy leaf nodes, resulting in products being assigned to broad parent categories that hurt auction relevance.

    When Hierarchical Taxonomy Is Required

    Hierarchical taxonomy becomes necessary when any of these conditions are true:

    • Your catalog has more than 200 products
    • You sell across multiple product types that require different attribute sets
    • You need accurate Google Shopping category mapping below the parent level
    • Your site needs faceted filtering (filter by colour, size, material etc.)
    • You sell across multiple channels that each have their own taxonomy
    • Your team needs to manage products by type for buying, merchandising, or reporting

    For most ecommerce stores, the answer is hierarchical. The question is not whether to use hierarchical taxonomy but how many levels and how specifically to define subcategories. For the full build process, see How to Build a Product Taxonomy From Scratch.

    The Google Shopping Argument for Hierarchical Taxonomy

    Google’s product taxonomy has over 6,000 categories. It goes 5–7 levels deep in most categories. A flat internal taxonomy maps to Google’s parent-level categories at best — “Clothing” instead of “Apparel & Accessories > Clothing > Activewear > Track Jackets & Hoodies”.

    The difference in Shopping performance between a product mapped to a parent category and one mapped to the correct leaf node can be significant — better relevance matching means your products appear for more specific search queries at lower CPCs. If Google Shopping is a meaningful channel for you, hierarchical taxonomy is not optional.

    Migrating from Flat to Hierarchical

    If your catalog currently has a flat structure and you are outgrowing it, migration is straightforward in principle — though it requires careful execution to avoid breaking navigation and losing indexed URLs.

    1. Design the new hierarchical structure before touching anything live
    2. Remap every product to its new subcategory in a staging environment
    3. Set up 301 redirects from old category URLs to new subcategory URLs
    4. Update your feed’s google_product_category values to the new leaf-node mapping
    5. Update your sitemap and request GSC re-indexing after going live

    Rankings may dip briefly after migration as Google recrawls the new structure. This is normal and temporary — the long-term gains in navigation, filtering, and channel performance outweigh the short-term disruption.

    For industry-specific guidance on what a hierarchical structure should look like in practice, see the fashion taxonomy guide and electronics taxonomy guide. Take the PIM Readiness Score to identify where your current taxonomy structure has gaps.

    Frequently Asked Questions

    What is a flat product taxonomy?

    A flat taxonomy has a single level of categories with no subcategories. Every product sits directly under a top-level category. Simple to set up but breaks down as catalog size grows — filters become unwieldy, Google category mapping becomes imprecise, and category pages become unmanageable.

    What is a hierarchical product taxonomy?

    A hierarchical taxonomy has multiple nested levels — typically Department > Category > Subcategory > Product Type. Products sit at the most specific level. This structure scales to any catalog size and enables precise Google category mapping and deep attribute-based filtering.

    When should you use a flat taxonomy?

    Flat taxonomies work for small catalogs under 200 products with a genuinely narrow product range where subcategories would be redundant. Specialty retailers with a single product type can use a flat structure effectively. For most ecommerce stores with varied product ranges, hierarchical is the right choice.

    Can you migrate from flat to hierarchical taxonomy?

    Yes. The process requires designing the new hierarchy, remapping products to new subcategories, setting up 301 redirects from old category URLs, updating feed category mapping, and requesting GSC re-indexing. Rankings may dip briefly during migration but recover as Google processes the new structure — and long-term performance gains are significant.

  • What Is Product Taxonomy? Definition, Examples and Why It Matters

    What Is Product Taxonomy? Definition, Examples and Why It Matters

    What Is Product Taxonomy? Definition, Examples and Why It Matters

    Product taxonomy is the classification system that organises your products into a structured hierarchy. It determines how products are grouped, named, and navigated — on your website, inside your catalog management system, and across every sales channel you use.

    Get it right and customers find products faster, your Google Shopping feed performs better, and your team can manage thousands of SKUs without chaos. Get it wrong and you end up with inconsistent categories, broken filters, and channel mapping errors that cost you sales daily.

    Product Taxonomy Definition

    A product taxonomy is a hierarchical system for classifying products into groups based on shared characteristics. The word comes from the Greek taxis (arrangement) and nomos (law or method) — it is, literally, the rules by which products are arranged.

    In practical ecommerce terms, a product taxonomy answers three questions for every product in your catalog:

    1. What type of product is this? (Product Type / Subcategory)
    2. What category does it belong to? (Category)
    3. What department does that category sit under? (Department)

    Those three questions map to the three levels every functional taxonomy needs: Department → Category → Subcategory.

    A Simple Product Taxonomy Example

    LevelNameExample
    Level 1 — DepartmentClothingClothing, Footwear, Accessories
    Level 2 — CategoryMen’s ClothingMen’s, Women’s, Kids’
    Level 3 — SubcategoryMen’s JacketsJackets, Trousers, Shirts, Knitwear
    Level 4 — Product TypeMen’s Rain JacketsRain Jackets, Leather Jackets, Puffer Jackets

    Every product in the catalog sits at the most specific level — Level 3 or Level 4 — not at the top. A product is never just “Clothing”. It is always “Men’s Rain Jackets” or “Women’s Running Shoes”.

    Taxonomy vs Categories vs Attributes — What’s the Difference?

    These three terms are often used interchangeably but they are distinct concepts.

    • Taxonomy — the overall classification system and its rules. The framework.
    • Categories — the individual nodes within the taxonomy. Men’s Jackets is a category.
    • Attributes — the properties of a product within its category. Colour, Size, Material, Brand are attributes of a product in Men’s Jackets.

    Taxonomy tells you where the product lives. Attributes describe what the product is. Both are necessary. A product without a taxonomy position cannot be found by browsing. A product without attributes cannot be filtered or matched to specific search queries.

    Why Product Taxonomy Matters for Ecommerce

    1. Site navigation and search

    Your taxonomy is the structure your site navigation and filters are built on. If your taxonomy is flat or inconsistent, your filters do not work. Customers searching for “blue running shoes women size 7” cannot filter to that result if Colour, Activity, Gender, and Size are not structured attributes on products in the correct subcategory.

    2. Google Shopping performance

    Google Shopping requires a google_product_category value for every product. This value must map to Google’s own taxonomy at the most specific level available. A jacket submitted as “Apparel & Accessories” instead of “Apparel & Accessories > Clothing > Outerwear > Coats & Jackets” loses relevance in every Shopping auction it enters. Your taxonomy must map to Google’s.

    3. Channel feed mapping

    Every major channel — Google Shopping, Amazon, Facebook Catalogue, retail marketplaces — has its own category taxonomy. Your internal taxonomy needs to translate cleanly to each one. A well-structured internal taxonomy makes this mapping straightforward. A chaotic one makes it a manual monthly project.

    4. Internal catalog management

    A consistent taxonomy means your team can find, update, and report on products by category without ambiguity. Without it, “running shoes” might live under “Athletic Footwear”, “Sports”, “Men’s Sports”, and “Women’s Running” in the same catalog — making bulk updates, seasonal campaigns, and channel exports all harder than they need to be.

    Flat vs Hierarchical Taxonomy

    Two structural approaches exist for product taxonomy. For most ecommerce stores with more than a few hundred products, the difference matters significantly. The full comparison is covered in the Flat vs Hierarchical Taxonomy guide, but the key distinction is:

    • Flat taxonomy: One level of categories, no subcategories. Simple but breaks down above ~200 products. Filters become unwieldy and Google category mapping becomes imprecise.
    • Hierarchical taxonomy: Multiple nested levels. Scales to any catalog size. Enables precise Google category mapping and deep attribute-based filtering.

    Product Taxonomy in Practice — Real Examples

    Across industries the hierarchy principle stays the same but the depth and attribute requirements differ significantly. A fashion taxonomy needs colour normalisation, size system declarations, and seasonal attribute management. An electronics taxonomy needs technical specification attributes and compatibility data. A home goods taxonomy needs dimension attributes and material normalisation. Each industry guide is linked below.

    How to Build Your Product Taxonomy

    The full step-by-step build process is covered in How to Build a Product Taxonomy From Scratch — from auditing your products through to Google category mapping and documentation. The short version:

    1. Define what your taxonomy needs to do — navigation, channel mapping, or both
    2. Audit your existing products before designing any categories
    3. Design 5–12 top-level departments
    4. Build at minimum three levels of hierarchy
    5. Define attribute sets per subcategory
    6. Map every subcategory to a Google product category leaf node
    7. Document the rules

    Before building, take the PIM Readiness Score to identify where your current product data governance has gaps. The free Taxonomy Template at lynkpim.app gives you a pre-built starting point for 5 industries.

    Frequently Asked Questions

    What is product taxonomy in ecommerce?

    Product taxonomy is the hierarchical classification system used to organise products into categories, subcategories, and product types. It defines the structure that powers site navigation, search filters, channel feeds, and internal catalog management.

    What is the difference between product taxonomy and product attributes?

    Taxonomy defines where a product sits in the hierarchy — Men’s Clothing > Jackets. Attributes define the properties of that product within its category — Colour: Navy, Size: L, Material: Nylon. Taxonomy organises the catalog structure; attributes describe individual products within it.

    Why does product taxonomy matter for Google Shopping?

    Google Shopping requires a google_product_category value for every product in your feed, mapped to Google’s own taxonomy at the most specific leaf-node level. Broad or incorrect category values reduce relevance matching and hurt Shopping auction performance — your products appear for fewer relevant queries and at lower positions.

    How many levels should a product taxonomy have?

    A minimum of three levels: Department (Level 1), Category (Level 2), and Subcategory (Level 3). Larger catalogs benefit from a fourth level (Product Type). More than four levels rarely adds value and increases maintenance complexity without meaningful benefit to navigation or channel mapping.

    What is the difference between a flat and hierarchical product taxonomy?

    A flat taxonomy has one level of categories with no subcategories — simple but breaks down above ~200 products. A hierarchical taxonomy has multiple nested levels that scale to any catalog size, enable precise Google category mapping, and support deep attribute-based filtering. For the full comparison see Flat vs Hierarchical Taxonomy.