WP – LynkPIM

Blog

  • 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.

  • How to Manage 1,000+ SKUs Without Losing Your Mind

    How to Manage 1,000+ SKUs Without Losing Your Mind

    How to Manage 1,000+ SKUs Without Losing Your Mind

    The point where ecommerce catalog management breaks is not 1,000 SKUs. It is usually around 300–500 SKUs — when the spreadsheet that worked fine at 100 products starts producing version control conflicts, inconsistent data, and errors that take hours to find and fix. By 1,000 SKUs, most teams are either running on a badly broken system or have already been forced to find a better approach. This guide covers what that better approach looks like.

    The Single Source of Truth Problem

    Most catalog management breakdowns at scale have the same root cause: product data exists in too many places simultaneously. There is a master spreadsheet, and a Shopify product page, and a Google Shopping feed file, and a supplier data sheet, and an email from the buying team — and no one is certain which one is authoritative for any given product.

    The fix is structural: every product’s authoritative data lives in exactly one place. All other systems (Shopify, feeds, emails) are downstream consumers of that source. When a product changes in the source, everything downstream updates from it — not the other way around.

    A well-structured spreadsheet can serve as this source for catalogs under ~500 SKUs. For larger catalogs, a PIM system is necessary — not because spreadsheets cannot hold the data, but because they cannot enforce the validation rules and workflow controls that prevent data quality from degrading as the catalog grows. See What Is Product Catalog Management for context on what these systems need to do.

    The 5 Systems You Need at 1,000+ SKUs

    1. Centralised product data (single source of truth)

    One place where all product data lives and is edited. Updates flow from here to all channels — not from channels back to a master spreadsheet. The question “what is the correct title for product X?” has one answer and one place to find it.

    2. Enforced taxonomy and categorisation

    Every product is in the correct subcategory with the correct attribute set populated. Uncategorised products and miscategorised products both cause the same problem: they are invisible in filters and they underperform in channel feeds. At 1,000+ SKUs you need a system that flags uncategorised products rather than silently letting them accumulate.

    3. Data validation rules

    Rules that prevent incorrect or incomplete data from being published. Required fields that must be filled before a product can go live. Controlled value lists that prevent “Navy”, “Dark Navy”, and “Midnight Blue” from all being entered as separate colour values. GTIN format validation that catches invalid barcodes before they hit Merchant Center. Without validation rules, data quality degrades with every product addition.

    4. A defined publishing workflow

    The steps a product goes through from creation to live publication: data entry → image upload → attribute enrichment → review → approval → publish to website → push to channels. A defined workflow prevents incomplete products from going live and creates accountability for each step.

    5. Regular catalog audits

    Catalog quality degrades over time without active maintenance. Run a completeness audit quarterly, a duplicate SKU check monthly, and a category assignment review whenever catalog structure changes. See How to Audit Your Product Catalog in One Weekend for the full process.

    Practical Tips for Managing Large SKU Counts

    • Use bulk operations for catalog-wide changes — updating colour values for 500 products one by one takes days. Bulk find-and-replace operations take minutes. Invest time in building bulk operation capability early.
    • Treat new product launches as projects, not tasks — a new product that needs 12 attribute fields, 5 images, and a Google Shopping title before it can go live is a multi-step project, not a single task. Assign it accordingly.
    • Separate content creation from data entry — copywriting for product descriptions and data entry for attribute fields are different skills. Don’t require your data entry team to write copy or your copywriters to understand GTIN requirements.
    • Archive rather than delete discontinued products — deleted products leave dead links and break order history. Archive discontinued SKUs so they are inactive but still findable if needed.

    The Catalog Health Score benchmarks your current catalog quality and flags where the biggest gaps are. The Completeness Checker shows exactly which products are missing which attributes across your full catalog. Start with the LynkPIM free plan to centralise product data and enforce validation rules without an enterprise implementation project.

    Frequently Asked Questions

    At what point does a spreadsheet stop working for SKU management?

    Spreadsheets typically become unmanageable around 500 SKUs with a single channel, or sooner with multiple channels or team members. The specific breaking points are: version control failures (two people edit simultaneously), formula errors that corrupt data silently, and the inability to enforce data validation rules. The symptom is usually a data incident — wrong prices going live, or products going live with missing images.

    What is the most common problem with large ecommerce catalogs?

    Inconsistent attribute values — the same property appearing under different names or with different values across different products. Navy vs Dark Navy vs Midnight Blue for the same colour. S vs Small vs SM for the same size. This accumulates gradually as different team members enter data using different conventions, and it breaks filters, reduces search accuracy, and creates channel feed errors.

  • Product Attributes in Ecommerce: How to Create Filters That Help Customers Buy

    Product Attributes in Ecommerce: How to Create Filters That Help Customers Buy

    Product Attributes in Ecommerce: How to Create Filters That Help Customers Buy

    Product attributes are the structured properties that describe what a product is and how it differs from other products — Colour, Size, Material, Brand, Processor Speed, Number of Seats, Waterproof Rating. They are the data layer that powers your site filters, your search matching, your channel feeds, and your product comparison functionality. Get them right and customers find what they need. Get them wrong and filters return empty results, searches miss matching products, and Google Shopping underperforms.

    Types of Product Attributes

    Universal attributes

    Attributes that apply to virtually every product regardless of category: Brand, Price, Colour, Material, Weight, Dimensions. These are the foundation of most filter systems and are required for channel feeds like Google Shopping.

    Category-specific attributes

    Attributes that only apply within a specific category or subcategory. Size and Size System for apparel and footwear. Processor and RAM for laptops. Number of Seats and Configuration for sofas. IP Rating and Fitting Type for lighting. These are defined in your taxonomy’s attribute set for each subcategory — they do not appear in the filter panel for irrelevant categories.

    Technical specification attributes

    Precise technical values with units: Screen Size (inches), Storage Capacity (GB), Battery Life (hours), Waterproof Rating (IP rating), Thread Standard (M6, M8), Tensile Strength (MPa). These are the primary purchase decision attributes for high-consideration products like electronics and industrial components. See the Electronics Taxonomy guide for the full attribute sets required per subcategory.

    Compliance and certification attributes

    Required for regulated products: CE Marking, ATEX certification, RoHS compliance, allergen declarations for food, organic certification for food and textiles. These are not typically filterable but are mandatory product data in the relevant categories.

    Required vs Optional Attributes — The Practical Distinction

    The traditional distinction between required and optional attributes needs a practical reframe for ecommerce. The question is not “can we publish this product without this attribute?” — technically many attributes are not hard-blocked. The question is “does missing this attribute cost us customers?”

    AttributeFormal StatusPractical Impact If Missing
    Colour (fashion)Required for Google Shopping variantsProduct invisible in colour filters, wrong image may show
    Size (fashion)Required for Google Shopping variantsProduct invisible in size filters
    Occasion (fashion)OptionalProduct invisible in “Occasion = Formal” filter searches — often high-intent
    Battery Life (laptops)OptionalInvisible to buyers filtering by battery life — significant buyer segment
    Number of Seats (sofas)OptionalInvisible in “3-seater” filter searches — primary buyer decision point

    Any attribute that drives significant filter usage should be treated as effectively required, regardless of its formal status. Run your site search and filter analytics to identify which attributes buyers filter by most — those are your de facto required attributes.

    Controlled Vocabularies — The Foundation of Working Filters

    A controlled vocabulary is a defined list of acceptable values for an attribute. Without controlled vocabularies, teams enter attribute values manually and inconsistency accumulates — “Navy”, “Dark Navy”, “Midnight Blue”, “Storm Blue”, “Deep Blue” all represent the same colour but appear as separate filter options.

    Define a controlled vocabulary for every filterable attribute before any product data is entered. For colour: 10–15 normalised values (Blue, Red, Green, Black, White, Grey, Yellow, Pink, Purple, Brown, Orange, Beige, Multi). For size: the exact size labels used on your products (XS, S, M, L, XL, XXL). For material: the primary material categories relevant to your catalog (Cotton, Polyester, Nylon, Leather, Wool, Linen, Silk).

    Attribute Completeness — The Filter Coverage Problem

    An attribute that is missing from 30% of your products means a filter on that attribute returns 30% fewer results than it should. A buyer filtering for “navy” gets an incomplete result set — products that exist in navy but are missing the colour attribute are hidden.

    Target completeness thresholds by attribute priority:

    • Required attributes: 100% target. Any product below 100% is incomplete and should not be published until fixed.
    • High-impact filter attributes: 95%+ target. Attributes that drive significant filter usage should be as close to complete as possible.
    • Recommended attributes: 80%+ target. Aim for high coverage but acknowledge that some edge-case products may not have applicable values.

    Run regular completeness audits using the Completeness Checker to monitor which attributes are falling below target thresholds as your catalog grows.

    Attribute Design Mistakes That Kill Conversion

    • Free-text attributes for filterable properties — a free-text Colour field cannot be used as a filter reliably. Filterable attributes must use controlled value lists.
    • Too many attributes per category — if a category has 30+ attributes, data entry completeness drops because teams skip fields. Keep required attributes to 8–12 per subcategory.
    • Global attributes applied to irrelevant categories — a “Number of Seats” attribute on all home goods products adds noise to furniture and lighting simultaneously. Category-specific attributes belong in category-specific attribute sets.
    • Attributes without unit standards — storing weight as “2kg”, “2 kg”, “2.0 KG”, and “2000g” in the same field breaks sorting and filtering by weight. Define units per attribute and enforce them.
    • Marketing names as attribute values — “Dusty Rose” as a colour value is correct for product copy but wrong for a filter attribute. Store marketing names separately; use normalised values for filterable attributes.

    The LynkPIM Product Data Modeling feature enforces controlled vocabularies, required attribute validation, and completeness tracking at the category level — preventing attribute quality degradation as catalogs scale. Start free at lynkpim.app/pricing. Also see Faceted Navigation and Product Taxonomy for how attributes connect directly to your filter system.

    Frequently Asked Questions

    What are product attributes in ecommerce?

    Product attributes are the structured properties that describe what a product is and how it differs from others — Colour, Size, Material, Brand, Processor Speed, Number of Seats, Waterproof Rating. They power site filters, search matching, channel feeds, and product comparison functionality. Without structured, consistent attribute data, none of these functions work reliably.

    What is the difference between required and optional product attributes?

    Required attributes are those without which a product cannot be correctly sold or displayed. Optional attributes improve discoverability and filtering. In practice, any attribute that drives significant filter usage should be treated as effectively required — missing it hides products from buyers who use that filter, regardless of its formal classification.

    Why should product attribute values use controlled vocabularies?

    Controlled vocabularies prevent inconsistent values that break filters and search. Without them, you end up with Navy, Dark Navy, Midnight Navy, Storm Blue, and Ocean Blue as separate filter options instead of a single Blue. Controlled vocabularies ensure every product with a blue attribute uses exactly the same value — making filters accurate and site search effective.

    How many attributes should each product category have?

    Most subcategories need 5–8 required attributes and 5–10 recommended attributes. More than 15–20 required attributes creates data entry burden that reduces completeness — teams start skipping fields. The right number depends on the product type and the filtering decisions buyers make in that category. Start with the attributes that drive filter usage and add more based on analytics.

  • How to Migrate Product Taxonomy Without Breaking Your Store

    How to Migrate Product Taxonomy Without Breaking Your Store

    How to Migrate Product Taxonomy Without Breaking Your Store

    Taxonomy migrations are one of the most disruptive changes you can make to an ecommerce store. Done without a plan, they break navigation, create 404 errors that destroy SEO rankings, invalidate channel feeds, and leave products uncategorised for days. Done correctly, they deliver a better-performing catalog with minimal disruption. The difference is preparation.

    This guide covers the complete migration process — from designing the new structure through to post-launch monitoring.

    Why Taxonomy Migrations Go Wrong

    Most taxonomy migration failures share the same root causes:

    • No 301 redirects — old category URLs return 404 errors. Google loses the ranking equity from those pages. Customers bookmark links break.
    • Products migrated before redirects are set up — the new category pages have no content and the old pages return 404s simultaneously.
    • Partial migration — some products moved to new categories, others left in old categories that no longer exist. Products become unfindable during the transition.
    • Channel feeds not updated — Shopping feed still references old category URLs, causing 404 landing page errors and subsequent disapprovals.
    • No post-migration monitoring — edge cases and missed redirects go undetected until they show up as ranking drops weeks later.

    Phase 1: Design the New Taxonomy (Before Touching Anything Live)

    The new taxonomy must be fully designed and documented before a single product is moved. This means:

    • Full category hierarchy defined to Level 3 or 4 (see How to Build a Product Taxonomy From Scratch)
    • Attribute sets defined per subcategory
    • Google product category mapping document completed for every new subcategory
    • New URL structure confirmed — category slugs for every new subcategory

    Build and test the new structure in your staging environment. Confirm navigation works, filters populate correctly, and product pages display properly — all before any changes go live.

    Phase 2: Build the Product Remapping Document

    This is the migration source of truth. For every product in your catalog, record:

    • Current category
    • New category (from the new taxonomy structure)
    • Any attribute values that need to change as a result of the new category assignment

    This document must be 100% complete before migration begins. Any product without a destination category will be uncategorised after migration — invisible to customers and broken in your feed.

    Phase 3: Set Up All 301 Redirects Before Go-Live

    301 redirects must be in place before any category URLs change on the live site. Do not go live and then add redirects afterwards — the window between go-live and redirect setup is when Google crawls 404 errors and when customers hit broken links.

    • Map every old category URL to its new URL in your redirect list
    • For categories being split into multiple new subcategories, redirect the old URL to the most relevant new subcategory (or to the parent category if no single subcategory is a clear match)
    • For categories being merged, redirect the old URL to the merged category
    • Test every redirect in staging before going live

    Phase 4: Execute During a Maintenance Window

    Execute the full migration in one step during your lowest-traffic period (typically 2:00–5:00 AM). Apply all product remappings and activate all redirects simultaneously. Never migrate categories in batches across multiple days — this creates a prolonged period where some products are in old categories, some are in new categories, and the site navigation is inconsistent.

    Phase 5: Update Feeds and Request Re-indexing

    Immediately after migration goes live:

    1. Update your Google Shopping feed’s google_product_category mapping to reflect any new subcategory mappings
    2. Update product_type field values if they referenced your old internal category names
    3. Update link field values in your feed if category URL changes affected product landing page URLs
    4. Submit the updated feed to Google Merchant Center
    5. In Google Search Console, use the URL Inspection tool to request re-indexing for your most important category pages
    6. Submit an updated sitemap

    Post-Migration Monitoring (First 30 Days)

    Check these daily for the first week, then weekly for the following three weeks:

    • GSC Coverage report — watch for new 404 errors. Any 404 on a page that was previously indexed needs an immediate redirect fix.
    • Merchant Center Diagnostics — check for new disapprovals caused by landing page or category mapping changes
    • Organic traffic by category page — expected to dip temporarily as Google re-evaluates the new structure. A dip that does not recover after 4–6 weeks signals a redirect or indexing issue.
    • Site search zero-results queries — any increase post-migration suggests products have been miscategorised and are not surfacing in the right filter contexts

    The PIM Readiness Score identifies where your current taxonomy and data governance has gaps before you begin a migration — it is the right starting point for understanding the scope of work involved. For the impact of taxonomy structure on your filters and site search post-migration, see Faceted Navigation and Product Taxonomy.

    Frequently Asked Questions

    Will migrating product taxonomy hurt my Google rankings?

    It may cause a temporary dip of 2–4 weeks as Google recrawls and re-evaluates the new structure. With proper 301 redirects in place, most ranking equity transfers to the new URLs. Long-term, a well-structured hierarchical taxonomy almost always outperforms a poorly-structured flat one — the short-term dip is worth the long-term gain.

    How long does a product taxonomy migration take?

    Planning and staging takes 2–4 weeks for most mid-size catalogs (500–5,000 SKUs). The actual live migration takes hours — it is a single execution event. Post-migration monitoring and edge case cleanup typically runs for 2–4 weeks after go-live.

    Do I need to update my Google Shopping feed after migrating taxonomy?

    Yes. Update your google_product_category mapping for any subcategory changes, update product_type field values if they referenced old internal category naming, and update link field values if category URL changes affected product landing page URLs. Submit the updated feed to Merchant Center immediately after go-live.

  • Faceted Navigation: How Product Taxonomy Powers Your Filter System

    Faceted Navigation: How Product Taxonomy Powers Your Filter System

    Faceted Navigation: How Product Taxonomy Powers Your Filter System

    Faceted navigation is the filter sidebar on your category pages. It is one of the highest-impact conversion tools in ecommerce — when it works. When it does not work, customers face unusable filter options, incomplete results, and irrelevant products. The difference between a working and a broken faceted navigation system almost always comes down to the quality of the product taxonomy underneath it.

    What Is Faceted Navigation?

    Faceted navigation is a multi-dimensional filtering system that allows customers to narrow a product set by applying multiple attribute filters simultaneously. Each filter dimension — colour, size, brand, material, price range — is a “facet”.

    When a customer lands on a “Women’s Running Shoes” category page and uses the filters to select: Size = 8, Colour = Black, Brand = Asics — faceted navigation returns only the products matching all three criteria simultaneously. This is fundamentally different from traditional category browsing where customers can only drill down one level at a time.

    Faceted navigation significantly increases the probability that a customer with specific requirements finds what they are looking for — which directly increases conversion rate on category pages. But it only works if the attribute data powering the filters is structured, consistent, and complete.

    The Taxonomy-Navigation Connection

    The filter options available on any category page come directly from the attribute values assigned to products in that category. Your product taxonomy determines:

    • Which attributes exist as filters — only attributes defined in your taxonomy attribute set for that subcategory can become filters
    • Which values appear in each filter — only the distinct values present in your product data for that attribute appear as filter options
    • How many products each filter returns — if 30% of products are missing an attribute, filtering by that attribute returns an incomplete set

    This means a product taxonomy decision — what attributes to assign to a subcategory, what values to allow for each attribute — directly determines what filters customers see and how useful those filters are. For the foundation on building taxonomy correctly, see What Is Product Taxonomy and How to Build a Product Taxonomy From Scratch.

    Why Flat Taxonomy Breaks Faceted Navigation

    A flat taxonomy — one level of categories with no subcategories — forces all products in a top-level category to share the same filter set. In a home goods store with a flat structure, the “Furniture” category contains sofas, dining tables, bed frames, and desk lamps. The filter panel must serve all of them simultaneously.

    The result: a filter panel that includes Number of Seats (relevant to sofas only), Bed Size (relevant to beds only), Bulb Type (relevant to lamps only), and Seating Capacity (relevant to dining tables only) — all visible at once, none relevant to all products. Customers see a confusing, cluttered filter panel and abandon filtering entirely.

    Hierarchical taxonomy solves this by enabling category-specific filter sets. Sofas get their own filter panel with Number of Seats, Configuration, and Fabric. Lighting gets its own panel with Fitting Type, Dimmable, and IP Rating. Each subcategory shows only the filters relevant to it. The Flat vs Hierarchical Taxonomy guide covers when each approach is appropriate.

    The 4 Attribute Rules for Effective Faceted Navigation

    Rule 1: Normalise attribute values

    Every attribute that becomes a filter must use controlled, consistent values. Colour cannot have 40 variations of blue — it must have one “Blue” value (plus specific shades as a secondary attribute if needed). Size cannot have “S”, “Small”, “SM”, “size S”, and “SMALL” — it must have one normalised “S” value. Unnormalised values create filter option lists that customers cannot navigate.

    Rule 2: Ensure completeness for filter attributes

    A filter attribute that is missing from 40% of products returns a result set that excludes 40% of matching products. If a customer filters by Colour = Blue and 40% of your blue products are missing the colour attribute, the filter is hiding products the customer would buy. Run completeness checks on every filter attribute — any attribute below 90% coverage is undermining your conversion rate.

    Rule 3: Define filter attributes per subcategory, not globally

    Different subcategories need different filters. Do not apply a global attribute set across all categories. Define which attributes become filters for each subcategory — this is a taxonomy design decision, not a platform configuration decision. The attribute set in your taxonomy is what drives the filter panel.

    Rule 4: Keep facet option counts manageable

    5–15 options per filter facet is the usable range for most attributes. A colour filter with 40 options is unusable. A brand filter with 200 options needs a search-within-filter feature. Use controlled attribute value lists to prevent facet option counts from growing beyond the usable range as your catalog expands.

    Common Faceted Navigation Failures and Their Taxonomy Root Causes

    SymptomRoot CauseFix
    Filter returns zero results despite products existingProducts missing the filter attributeAttribute completeness audit + bulk fill
    Colour filter has 40+ optionsUnnormalised colour valuesColour normalisation — map to controlled value list
    Filter returns wrong product typesProducts miscategorised in wrong subcategoryReclassify affected products
    Same filter appears on every category regardless of relevanceFlat taxonomy — no subcategory-specific attribute setsMigrate to hierarchical taxonomy with per-subcategory attribute definitions
    Filter option counts are highly inconsistentAttribute values assigned inconsistently across catalogControlled vocabulary enforcement + bulk standardisation

    The root cause of most faceted navigation failures is not a platform problem — it is a product data problem. The Completeness Checker identifies which attribute gaps are most significant across your catalog. The PIM Readiness Score gives you a full picture of where your taxonomy and attribute governance has gaps affecting both faceted navigation and channel performance. Also see How Bad Taxonomy Kills Your Site Search for the broader impact beyond filters.

    Frequently Asked Questions

    What is faceted navigation in ecommerce?

    Faceted navigation is a filtering system that allows customers to narrow a product set by applying multiple attribute filters simultaneously — for example, filtering shoes by Size = 8, Colour = Black, Brand = Nike, and Style = Running to show only matching products. Each filter dimension is a “facet” derived from structured product attributes in your taxonomy.

    Why does product taxonomy affect faceted navigation?

    Because the filters on any category page come directly from the attribute sets assigned to that category in your taxonomy. If your taxonomy assigns different attributes to different products in the same category, or uses inconsistent attribute values, the filter options become incomplete or unusable. The taxonomy is the data layer that faceted navigation is built on.

    What is the difference between faceted navigation and site search?

    Site search retrieves products matching a keyword query. Faceted navigation filters an existing product set by attribute values. They work together — a customer searches “running shoes” (site search), then uses facets to filter by size and colour (faceted navigation). Both depend on the same underlying product data quality, which means taxonomy problems typically affect both simultaneously.

    How many filter options should each facet display?

    5–15 options per facet is the usable range. Fewer than 5 suggests the attribute is not differentiated enough to warrant a filter. More than 15–20 options on a single facet is typically unusable — customers cannot scan that many options efficiently. Use controlled attribute value lists and normalisation to keep facet option counts manageable as your catalog grows.

  • How to Automate Your Google Shopping Feed Updates (2026 Guide)

    How to Automate Your Google Shopping Feed Updates (2026 Guide)

    How to Automate Your Google Shopping Feed Updates (2026 Guide)

    Manual Google Shopping feed management is one of the highest-risk activities in ecommerce operations. Every time a price changes, a product goes out of stock, or a promotion goes live — and the feed is not updated within 24 hours — you risk price mismatch disapprovals that remove products from Shopping entirely. Full automation eliminates this risk.

    This guide covers every automation method available in 2026, when to use each, and how to set them up correctly.

    Why Manual Feed Updates Fail

    Manual feed management fails not because teams are careless but because the speed of change in ecommerce catalogs outpaces human update cycles. Prices change for flash sales. Stock depletes. New products launch. Promotions end. Any one of these events — if not reflected in the feed within 24 hours — creates a price mismatch or availability mismatch that Merchant Center catches during its next crawl.

    The solution is not faster manual processes. It is removing humans from the update loop entirely for routine data changes. For the context on how feeds connect to your product data source, see the PIM to Google Shopping Integration guide.

    Method 1: Scheduled URL Fetch (Recommended for Most Stores)

    Your system generates a feed file at a stable URL. Google Merchant Center fetches that URL on a schedule you configure — daily, twice daily, or more frequently. Every fetch pulls a fresh copy of your full product data.

    How to set it up

    1. In Merchant Center, go to Products → Feeds → [your primary feed] → Settings
    2. Under Fetch Schedule, set the frequency to Daily at minimum
    3. Set the fetch time to a low-traffic period — typically 2:00–4:00 AM in your primary market timezone
    4. For stores with frequent promotions or high stock turnover, set to Twice daily
    5. Save and trigger a manual fetch to confirm the URL is accessible and the feed processes without errors

    Best for: Most ecommerce stores. Works with any platform that can generate a feed file at a stable URL — Shopify, WooCommerce, Magento, custom platforms.

    Limitation: The whole feed updates at once on a schedule. If a product goes out of stock at 10am and your next fetch is at 2am, the product will show as in stock in Shopping for 16 hours. For stores with fast-moving inventory, this window creates availability mismatch risk.

    Method 2: Google Content API (Real-Time Updates)

    The Content API allows your system to push product updates to Merchant Center immediately when a product changes — no waiting for a scheduled fetch. A price change in your platform can trigger an API call that updates the product in Merchant Center within minutes.

    When to use the Content API

    • Catalogs over 50,000 products where full-feed fetches become slow or resource-heavy
    • Stores with real-time pricing (dynamic pricing, live stock-based pricing)
    • High-velocity inventory where products sell out within hours
    • Stores running multiple daily promotions that change prices frequently

    Content API setup requirements

    The Content API requires developer resource to implement — it is not a no-code option. Your platform needs to be configured to send API calls to Merchant Center when product data changes. Google’s Content API documentation is the reference for implementation. The Feed Generator handles API delivery without custom development for most store configurations.

    Method 3: Feed Management Tool (No-Code Automation)

    Feed management tools sit between your product data source and Merchant Center. They pull product data from your platform or PIM, apply transformation rules (title construction, category mapping, attribute normalisation), generate the feed file, and deliver it to Merchant Center on schedule — with no manual steps after initial setup.

    Best for: Teams without developer resource, stores managing feeds across multiple channels (Google + Amazon + Facebook), and catalogs where feed transformation logic is complex enough that maintaining it manually is impractical.

    Separating Price/Availability from Content Updates

    Not all feed data needs to update at the same frequency. Treating your feed as a single monolithic file that updates everything at once is inefficient and sometimes counterproductive.

    Data TypeUpdate FrequencyDelivery Method
    Price, sale_price, availabilityDaily minimum — twice daily for promotionsPrimary feed or price-only supplemental feed
    New productsSame day as launchSupplemental feed or Content API push
    Titles, descriptionsWeeklyPrimary feed
    ImagesOn changePrimary feed
    Custom labelsWeekly or monthlyCustom label supplemental feed

    Using a supplemental feed for price and availability updates is a practical option for stores whose primary feed platform cannot be updated on a daily schedule. See the Supplemental Feeds guide for setup details.

    Setting Up Merchant Center Alerts

    Automation without monitoring is incomplete. Feed automation can fail — URLs become inaccessible, file formats break, authentication tokens expire. Set up Merchant Center email alerts so processing failures are caught within hours, not days.

    1. In Merchant Center, go to Settings → Email Preferences
    2. Enable alerts for: Feed processing errors, Product disapprovals (daily digest), Account warnings
    3. Add a shared team email address (not just a personal one) so alerts are seen even when you are out of office

    For full automation of feed generation, delivery, and monitoring from one place — including price validation before submission — the Google Shopping Feed Generator handles all three without custom development. Start with the LynkPIM free plan.

    Frequently Asked Questions

    How often should Google Shopping feeds update?

    Price and availability fields should update at minimum daily. Stores with frequent promotions or fast-moving inventory should update twice daily. Product content fields (titles, descriptions, images) can update weekly — these change infrequently and do not cause disapprovals if slightly delayed. The critical rule: your feed price must match your landing page price at all times.

    What is the difference between Scheduled URL Fetch and the Content API?

    Scheduled URL Fetch pulls a complete feed file from a hosted URL on a schedule — best for catalogs under 50,000 products with predictable update patterns. The Content API allows your system to push individual product updates to Merchant Center in real time as products change — better for large catalogs, real-time prices, or stores with unpredictable inventory movements.

    What happens if my Google Shopping feed fails to update?

    If your feed fails to fetch for more than 30 days, Google may deactivate it and your products stop appearing in Shopping. Shorter delays cause price mismatch disapprovals when your site prices change but your feed does not update. Set up Merchant Center email alerts for feed processing errors so failures are caught within hours, not days.

  • How Product Data Quality Affects Your Google Shopping ROAS

    How Product Data Quality Affects Your Google Shopping ROAS

    How Product Data Quality Affects Your Google Shopping ROAS

    Most Google Shopping ROAS discussions focus on bids, bidding strategies, and campaign structure. These matter. But for stores with data quality problems, no bidding strategy can overcome a feed where products are disapproved, titles are vague, categories are wrong, or GTINs are invalid. Product data quality affects ROAS before a single auction is entered.

    This article covers the six data quality factors with the biggest direct ROAS impact, ranked by how much they cost you and how quickly they can be fixed.

    How Product Data Affects ROAS — The Mechanism

    Product data quality affects ROAS through three distinct mechanisms. Understanding which applies to which data problem helps you prioritise fixes correctly.

    • Auction eligibility: Disapproved products do not enter any auctions. Products with “Limited performance” warnings enter fewer auctions and at lower positions. GTIN errors and policy violations cause this.
    • Auction relevance: Your title and google_product_category determine which search queries your products are matched to. Vague titles and broad categories match your products to irrelevant queries — you spend budget on traffic that does not convert.
    • Click-to-conversion rate: Image quality, title specificity, and price competitiveness all affect whether a click becomes a purchase. This is the layer that most data quality guides ignore but where significant ROAS gains are available.

    Factor 1: Product Titles — The Highest-Impact Fix

    Google uses your product title as the primary signal for matching your product to search queries. A vague title matches fewer queries. A specific, well-structured title matches more relevant queries at higher relevance scores — meaning better positions at lower CPCs.

    The ROAS impact of title quality is larger than most stores expect because it affects both sides of the equation: the cost of each click (auction position) and the value of each click (title specificity means higher buyer intent).

    Title TypeQueries MatchedTypical CTRTypical Conversion Rate
    “Men’s Jacket”Broad, low-intent0.8–1.2%Low — wrong intent mix
    “Columbia Rain Jacket Men Navy L”Specific, high-intent3.5–5.2%High — buyer knows what they want

    Title formula: Brand + Gender/Age + Material + Product Type + Colour + Size for apparel. Brand + Key Spec + Product Type + Model for electronics. Check every title against this formula using the Feed Audit Checklist.

    Factor 2: GTINs — The Eligibility Gate

    Products without valid GTINs receive a “Limited performance” status in Google Merchant Center. This is not a warning you can safely ignore. Limited performance means:

    • Reduced auction eligibility — the product enters fewer auctions than it would with a valid GTIN
    • Lower relevance scores — Google cannot cross-reference the product against its product knowledge graph
    • No eligibility for Shopping promotions or special ad formats that require GTIN verification

    For branded products, fixing invalid GTINs directly restores auction eligibility. For custom or handmade products that genuinely have no manufacturer GTIN, set identifier_exists = FALSE — this removes the warning without fabricating a GTIN.

    Factor 3: Google Product Category — The Auction Pool Problem

    An incorrect or overly broad google_product_category puts your product in the wrong auction pool. A running jacket in “Apparel & Accessories” competes against handbags, sunglasses, and children’s clothing — all irrelevant to your buyer. Your bids are wasted on impressions that will not convert because the query intent does not match.

    Fixing category mapping to leaf-node IDs is a one-time task per subcategory. Once mapped correctly in your feed, it applies to all products in that subcategory automatically. Full guide at Google Product Category Taxonomy.

    Factor 4: Image Quality — The CTR Multiplier

    In Google Shopping, the product image is the first thing a buyer sees. It is the primary visual decision trigger before the title or price are read. Image quality directly affects CTR, and CTR directly affects ROAS.

    • White background images consistently outperform lifestyle images for CTR in Shopping results for most product categories
    • Higher resolution images (800×800px+) render better in Shopping and reduce the pixelation that signals low-quality product listings
    • Multiple images via additional_image_link (up to 10) improve performance — Google can show different angles in different contexts
    • Colour-specific images for variants — a buyer filtering for navy gets shown the navy product, not a different colour from the same style

    Factor 5: Price and Availability Freshness

    A price mismatch disapproval removes a product from Shopping entirely — zero impressions, zero clicks, zero revenue until fixed. For stores that run frequent promotions or have fast-moving stock, stale feed data is a constant ROAS drain because it creates disapprovals that take 24–48 hours to resolve.

    The fix is structural: daily minimum feed updates, twice-daily during promotion periods, and using sale_price + sale_price_effective_date for promotions rather than changing the base price field. This prevents price mismatch disapprovals at the source.

    Factor 6: Attribute Completeness — The Long Tail Opportunity

    Products with complete optional attributes — colour, size, material, pattern, age_group, gender — match against more specific long-tail search queries. A buyer searching “navy size 12 waterproof running jacket women” only finds your product if all five of those attributes are present in your feed.

    Long-tail queries typically convert at higher rates than broad queries because they indicate more specific buying intent. Every missing optional attribute is a set of high-intent queries your product is invisible for. Run an attribute completeness audit using the Completeness Checker to identify which products are missing which attributes at scale.

    Priority Order — Where to Start

    1. Fix disapprovals first — any disapproved product is earning zero. Check Merchant Center Diagnostics before anything else. See the Fix Disapprovals guide.
    2. Optimise titles — highest impact on relevant traffic. Apply the title formula to your top 20% of products by revenue first.
    3. Validate GTINs — restore “Limited performance” products to full auction eligibility.
    4. Fix category mapping — move all products from parent categories to leaf nodes.
    5. Set up daily feed refresh — prevent price mismatch disapprovals from recurring.
    6. Complete optional attributes — unlock long-tail query matching for all products.

    Use the Catalog Health Score to benchmark your current data quality across all six factors and get a prioritised fix list specific to your catalog. For ongoing feed management that prevents these issues at source, explore the LynkPIM free plan.

    Frequently Asked Questions

    Does product data quality affect Google Shopping ROAS?

    Yes, directly — through three mechanisms: auction eligibility (disapproved products don’t appear at all), auction relevance (vague titles and broad categories match wrong queries), and click-to-conversion rate (image quality and title specificity determine whether clicks convert). All three affect ROAS before any bidding decision is made.

    Which product data fix has the biggest impact on Google Shopping ROAS?

    Title optimisation typically delivers the biggest immediate ROAS improvement for most stores. A specific, well-structured title matches more relevant search queries, improves auction relevance, increases CTR, and attracts higher-intent buyers. Apply the formula: Brand + Gender/Age + Material + Product Type + Colour + Size for apparel; Brand + Key Spec + Product Type for electronics.

    How does a missing GTIN affect Google Shopping performance?

    Products without valid GTINs receive “Limited performance” status — reduced auction eligibility, fewer impressions, and lower positions than identical products with valid GTINs. For branded products, fixing invalid GTINs directly restores full auction eligibility. For custom products with no manufacturer GTIN, set identifier_exists = FALSE to remove the warning.

  • Free Product Taxonomy Template: Download for 5 Industries (2026)

    Free Product Taxonomy Template: Download for 5 Industries (2026)

    Free Product Taxonomy Template: Download for 5 Industries (2026)

    Building a product taxonomy from scratch takes days. Validating that it maps correctly to Google’s taxonomy, includes the right attribute sets per subcategory, and uses normalised attribute values takes longer. This template gives you a pre-built, working starting point for five industries — so you spend your time adapting rather than building from zero.

    The template is free. No email required for the preview version. The full editable template is available via LynkPIM’s free plan.

    What’s in the Template

    The template is a structured Google Sheets file with five tabs — one per industry. Each tab contains:

    • Category hierarchy (Levels 1–4) — pre-built category structure from department level down to product type, based on real ecommerce catalog patterns for each industry
    • Required attribute sets per subcategory — the specific attributes that must be filled for a product in that subcategory to be considered complete (e.g. Colour, Size, Material, Gender for fashion; Processor, RAM, Storage for electronics)
    • Recommended attribute sets — additional attributes that improve search, filtering, and channel performance without being strictly required
    • Normalised attribute value lists — controlled vocabulary for colour, size, material, and other attributes that require consistency across the catalog
    • Google product category ID mapping — the correct leaf-node GPC ID for every subcategory, ready to use directly in your feed

    Tab 1: Fashion and Apparel Template

    The fashion tab covers: Women’s Clothing, Men’s Clothing, Kids’ Clothing, Footwear, Accessories, Swimwear, and Lingerie & Nightwear — down to Level 4 (Midi Dresses, Rain Jackets, Running Shoes etc.).

    Attribute sets include the full apparel requirements for Google Shopping (gender, age_group, color, size, size_system, item_group_id) plus apparel-specific attributes like neckline, length, occasion, and sleeve length. The colour normalisation table maps 200+ common fashion colour names to their normalised values for filters and feeds.

    Full details on fashion taxonomy requirements in the Fashion Taxonomy guide.

    Tab 2: Electronics Template

    The electronics tab covers: Computers & Laptops, Smartphones & Wearables, Audio, TV & Home Cinema, Cameras & Photography, Gaming, Components & Storage, and Cables & Accessories.

    Attribute sets go deep on technical specifications — processor family, RAM, storage type, screen size, connectivity standards for laptops; driver size, noise cancellation type, codec support for headphones; IP rating, connectivity, battery capacity for smartphones. Compatibility attribute fields are included for all accessory subcategories.

    Full details in the Electronics Taxonomy guide.

    Tab 3: Home Goods and Furniture Template

    The home goods tab covers: Furniture, Lighting, Bedding & Textiles, Kitchen & Dining, Storage & Organisation, Home Decor, and Outdoor.

    Attribute sets include the dimension fields critical for furniture (Width, Height, Depth, Weight, Assembly Required, Flat Pack), material normalisation mapping 150+ home goods material names to controlled values, and the two-field approach to style attributes (marketing name vs normalised filter value).

    Full details in the Home Goods Taxonomy guide.

    Tab 4: Food and Beverage Template

    The food & beverage tab covers: Fresh & Chilled, Ambient Grocery, Beverages, Frozen, Health & Nutrition, Snacks & Confectionery, Bakery, and Alcohol.

    This tab includes the full 14-allergen attribute set (with Contains / May Contain / Free From value options), dietary attribute fields (Vegan, Vegetarian, Gluten-Free, Halal, Kosher, Organic), shelf life and storage type fields, and the nutritional attribute set required by UK FIC regulations.

    Full details in the Food & Beverage Taxonomy guide.

    Tab 5: B2B Industrial Template

    The B2B industrial tab covers: Fasteners & Fixings, Pneumatics & Hydraulics, Electrical Components, Safety Equipment, Tools & Machinery, MRO Supplies, and Pipe & Tube.

    Attribute sets include the technical specification fields critical for industrial products (thread standard, material grade, pressure rating, IP rating, temperature range), compliance certification attributes (CE marking, ATEX, RoHS, REACH), and the UNSPSC classification mapping for each subcategory.

    Full details in the B2B Industrial Taxonomy guide.

    How to Adapt the Template to Your Catalog

    1. Copy the template to your Google Drive (File → Make a Copy)
    2. Delete subcategories you do not carry — if you do not sell footwear, delete the footwear rows from the fashion tab
    3. Add subcategories specific to your range — if you sell a product type not covered, add a row and fill in the attribute set manually using the existing rows as a format guide
    4. Update attribute value lists — customise the normalised colour, size, and material lists to match your actual product data
    5. Verify Google product category IDs — cross-check any subcategories you have modified against Google’s current taxonomy file to confirm the GPC ID is still the most specific available match

    Before building on top of this template, take the PIM Readiness Score to understand where your current product data governance has gaps — the template tells you what your taxonomy should look like, the readiness score tells you how far your current data is from that standard.

    Download the full editable template: lynkpim.app/pricing — available on the free plan, no credit card required.

    Frequently Asked Questions

    What is included in the free product taxonomy template?

    Five industry tabs (Fashion & Apparel, Electronics, Home Goods & Furniture, Food & Beverage, B2B Industrial), each with: full category hierarchy (Levels 1–4), required and recommended attribute sets per subcategory, normalised attribute value lists, and Google product category ID mapping for every subcategory.

    What format is the template in?

    Google Sheets with five tabs — one per industry. It can be downloaded as an Excel file or used directly in Google Sheets. Each tab is a working reference document designed to be adapted, not just read.

    Can I use the template for a mixed catalog across multiple industries?

    Yes. Take the relevant tabs from each industry and merge them into your own taxonomy document. The Google product category mapping in each tab is self-contained and works independently. If you sell both electronics and home goods, combine those two tabs into a single working taxonomy.

    How do I customise the template for my specific catalog?

    Copy to your Google Drive, then: delete subcategories you do not carry, add subcategories specific to your range using existing rows as a format guide, update attribute value lists to match your actual product data, and verify GPC IDs against Google’s current taxonomy file for any subcategories you modify or add.