top of page

Structured data for eCommerce category pages: Help Google understand your products and brand

SEO expert Lorcan Fearon. The tedt on hte image reads 'structured data for category pages'

Since the integration of AI into the search results, I have spent a lot of time optimizing my clients JSON-LD structured data. In particular, I’m focusing a lot on future-proofing product category pages for eCommerce websites and adapting them to the new era of search we are operating in. 


There are a number of reasons to do this, most of which I’ll cover in more detail in the later sections of this post, but here are the three main reasons to explore this tactic:


  • Structured data helps search engines to not just understand your product category pages, but understand them deeply. 

  • A deeper understanding of your pages makes it easier for search engines to trust and rank that page for more relevant searches.

  • Higher rankings help you compete on valuable SERPs and return value on your pages.


I started to test this out when I was working with a client that sold underwear and loungewear. Underwear was their main product, but loungewear really drove up the AOV of their orders, so I created a custom CollectionPage schema markup for their existing pajamas category, which was sitting just off the first page of Google’s results for some great non-branded search terms.


A screenshot of the Performance on Search Results report in Google Search Console. It shows that total clicks are up to 2.54K over the last 3 months (compared to 846 from the same period in 2023) and 232K impressions over the last 3 months (compared to the same period in 2023).

As no on-page changes were needed, the client was happy for us to try this out and we saw a great uplift in clicks and impressions, which had a knock-on effect on orders. Let’s get into the workflow so you can adapt this for your (or your clients’) category pages.


In this guide, you will learn about:



Why should you use structured data on your collection pages? 


I call upon JSON-LD when I am working on a website that is already doing all the right things on-page. The product category pages have all the right ingredients—they’re just edged out of those all-important top rankings by competitors. 


I sometimes describe this as an ‘extra-mile’ optimization (i.e., doing the thing that most people haven’t thought or bothered to do). Maybe it’s because they perform well via huge brand value and recognition or they only have the bandwidth/knowledge to prioritize SEO basics.


In any case, this is a tactic that I don’t often see websites implement. Product schema is often there, as well as ‘out-of-the-box’ schema markup from plugins, but considering search engines’ preference for product category pages for so many of the non-branded search terms we value in SEO, it surprises me how little this schema type gets used.


screenshot of SERP with category pages ranking
Across clothes, leisure, and electronics, we often see that product category pages take preference for commercial searches.

This tactic is something you can apply without changing anything on the page (in most cases), and it can help you close the gap on your competitors. If the product you sell could be confused with another or it has multiple names (e.g., flip-flops, sandals, thongs), then this is a way to ensure you are being as clear as possible for search engines, which is crucial if you want your category page to show up for those searches. 

However, this structured data implementation method is probably not a good idea if your category pages have a terrible user experience, they’re unusable on mobile, or loads slower than paint dries. 


There are often a number of more pressing issues product category pages can suffer from that you should consider addressing first. This really is going that extra mile for your online store. I describe this as leaving no stone unturned in the pursuit of the top ranking positions. 


Entity SEO and its importance for the future of search


Also referred to as ‘semantic SEO,’ entity SEO is the practice of helping search engines to find deeper meaning in the keywords we use so that they better understand the concepts that these words refer to. 

If this is the first time you’re encountering entity or semantic SEO, here are some great resources that will not only help you better understand the theory behind my structured data approach, but also aid you in keyword research and content creation as well:



To demonstrate how a search engine understands entities, let’s take the first sentence of one of my childhood heroes’ Wikipedia entry:


Diagram with annotations about Ruud van Nistelrooy, detailing his name, birthdate, Dutch nationality, and roles in football. Key terms are color-coded and classified as person, number, location, and organization.
Google’s Natural Language API demonstrating all the entities it recognises about Ruud van Nistelrooy, a former football player.

We can see (via Google’s Natural Language API) that search engines can identify concepts and entities quite well here.


This is important for the future of search because, as experienced SEOs know, Google doesn’t seem too interested in carrying on with the traditional ‘blue links’ search listings. Google doesn’t want to be a search engine as much as it wants to be an ‘answer machine.’


In order for Google Search to reach its final form, as it were, it needs to be able to infer, understand, and relate concepts, entities, and things as easily and successfully as a human can. 


Whether you like it or not, this is the direction Google Search, and almost all search engines, are pursuing. This is why I have been drawn to this tactic. I see this as not only a good SEO tactic for today, but an even better one for tomorrow.


By focusing on entities and their relationships now, you’re preparing your eCommerce store for an impending future where search engines don't just read your content, but truly comprehend it.

Where to craft and validate your structured data 


Before we continue, I am going to assume from this point onwards that you can craft your own structured data, or at least know how to edit it, as I will provide my own template below. 


And if you don’t know how, don’t worry! Again, you couldn’t be in a better place. Crystal Carter created this comprehensive guide to structured data that will get you up to speed.


Screenshot of the JSON-LD Playground interface, featuring text input and options for JSON-LD markup testing and format visualization.

A great website I use to play around with structured data is the JSON-LD Playground, mainly because it validates your code as you edit, whereas other validators require you to ‘submit’ your URL/snippet with a few seconds waiting. 


It may not sound like much, but when you are trying to find out where just one “]” should go, it does get quite tedious so real-time feedback can end up saving you a lot of time if you’re working at scale. 


Why your JSON-LD structured data needs to be a graph


There’s just one more important stop to make before we get into the example: This is on the idea that your schema markup should be a ‘graph.’ 


This concept is best explained in this article from Joost de Valk, which changed the way I approach crafting JSON-LD structured data. The article covers this in greater detail than I’m able to here, but to try and summarize it neatly:


  • A common schema markup practice in SEO is to create different snippets (e.g., a HowTo, a Product schema, WebPage and so on) but to have these as separate blocks

    For example, you may have a snippet of schema markup that looks like this:


{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Example Product",
  "image": [
    "https://example.com/photos/1x1/photo.jpg"
  ],
  "description": "A description of the product.",
  "sku": "0446310786",
  "mpn": "925872",
  "brand": {
    "@type": "Brand",
    "name": "Studio Hawks"
  },
  "review": {
    "@type": "Review",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "4",
      "bestRating": "5"
    },
    "author": {
      "@type": "Person",
      "name": "Stu D. Hawk"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "reviewCount": "89"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product",
    "priceCurrency": "GBP",
    "price": "119.99",
    "priceValidUntil": "2023-11-05",
    "itemCondition": "https://schema.org/NewCondition",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@type": "Organization",
      "name": "Example.com"
    }
  }
}

And an Organization schema markup snippet that looks like this:


{
  "@context": "https://schema.org/",
  "@type": "Organization",
  "name": "Example Corporation",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "(+44) 20 38877388",
    "contactType": "customer service",
    "areaServed": "UK",
    "availableLanguage": ["English", "Spanish"]
  },
  "sameAs": [
    "https://www.facebook.com/example",
    "https://www.twitter.com/example",
    "https://www.instagram.com/example"
  ]
}

  • What Joost de Valk is describing in the article is that schema markup should “always be one inter-connected graph.” This means that all your different schema properties should relate to one another and this relation should be indicated within the code it is housed in. 


{
  "@context": "https://schema.org/",
  "@graph": [
    {
      "@type": "WebSite",
      "name": "Example Store",
      "url": "https://www.example.com",
      "publisher": {
        "@id": "https://www.example.com#organization"
      }
    },
    {
      "@type": "Organization",
      "name": "Example Corporation",
      "url": "https://www.example.com",
      "logo": "https://www.example.com/logo.png",
      "contactPoint": {
        "@type": "ContactPoint",
        "telephone": "(+44) 20 38877388",
        "contactType": "customer service",
        "areaServed": "UK",
        "availableLanguage": ["English", "Spanish"]
      },
      "sameAs": [
        "https://www.facebook.com/example",
        "https://www.twitter.com/example",
        "https://www.instagram.com/example"
      ],
      "@id": "https://www.example.com#organization"
    },
    {
      "@type": "WebPage",
      "url": "https://www.example.com/product",
      "name": "Product Page for Example Product",
      "description": "This is a detailed product page for Example Product available at Example Corporation.",
      "publisher": {
        "@id": "https://www.example.com#organization"
      },
      "mainEntity": {
        "@id": "https://www.example.com/product#product"
      }
    },
    {
      "@type": "Product",
      "name": "Example Product",
      "image": [
        "https://example.com/photos/1x1/photo.jpg"
      ],
      "description": "A description of the product.",
      "sku": "0446310786",
      "mpn": "925872",
      "brand": {
        "@type": "Brand",
        "name": "Studio Hawks"
      },
      "review": {
        "@type": "Review",
        "reviewRating": {
          "@type": "Rating",
          "ratingValue": "4",
          "bestRating": "5"
        },
        "author": {
          "@type": "Person",
          "name": "Stu D. Hawk"
        }
      },
      "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": "4.4",
        "reviewCount": "89"
      },
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/product",
        "priceCurrency": "GBP",
        "price": "119.99",
        "priceValidUntil": "2023-11-05",
        "itemCondition": "https://schema.org/NewCondition",
        "availability": "https://schema.org/InStock",
        "seller": {
          "@id": "https://www.example.com#organization"
        }
      },
      "@id": "https://www.example.com/product#product"
    }
  ]
}

For our purposes (and the purposes of this article), our CollectionPage is the mainEntityOf our WebPage, which belongs on our WebSite that is owned by our Organization. This is demonstrated in the next section.


Connecting all of these entities together and organizing them neatly within your JSON-LD schema markup means you are going that extra mile to ensure that  your category pages have the highest chances of being completely understood by search engines. 


It does add a layer of complexity to your structured data, but hey, if you are going that extra mile, you might as well really go that extra mile, right?


CollectionPage schema snippet example


Below is an example template of the code snippet I currently use. I have tried out some different approaches, and there may be different quirks or considerations depending on which platform your website is built on.


Some CMSes may require you to download a plugin to upload custom structured data, which could upload it in the wrong place, or multiple times. It may not always be immediately obvious how to upload your own custom structured data on a CMS


Feel free to take this CollectionPage schema and adapt it for your online store:


<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.co.uk/#website",
      "url": "https://example.co.uk/",
      "name": "Example Inc.",
      "publisher": {
        "@id": "https://example.co.uk/#organization"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.co.uk/pdp-example/#webpage",
      "url": "https://example.co.uk/pdp-example/",
      "inLanguage": "en",
      "name": "Name of Page",
      "isPartOf": {
        "@id": "https://example.co.uk/#website"
      },
      "publisher": {
        "@id": "https://example.co.uk/#organization"
      },
      "description": "Describe your page here"
    },
    {
      "@type": "Organization",
      "@id": "https://example.co.uk/#organization",
      "name": "Name of Organisation",
      "url": "https://example.co.uk/",
      "sameAs": [
        "https://www.facebook.com/example/",
        "https://www.ebay.co.uk/example",
        "https://www.instagram.com/example",
        "https://www.twitter.com/example"
      ]
    },
    {
      "@type": "CollectionPage",
      "@id": "https://example.co.uk/pdp-example/#collectionpage",
      "url": "https://example.co.uk/pdp-example/",
      "mainEntityOfPage": {
        "@id": "https://example.co.uk/pdp-example/#webpage"
      },
      "name": "Product Category Name",
      "description": "XXX",
      "image": "https://example.co.uk/image-url-goes-here",
      "about": {
        "@type": "Thing",
        "name": "Name of Thing",
        "sameAs": "Find your most relevant Wikidata or Wikipedia entry here",
      },
      "relatedLinks": [
        "https://example.co.uk/related-pdp-url-1",
        "https://example.co.uk/related-pdp-url-2"
      ]
    }
  ]
}
</script>

If you were to use this on a real page, below is how it could look. Let’s see how this snippet would shape up if we applied it to the Rolex men’s watches collection page:


<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://www.rolex.com/#website",
      "url": "https://www.rolex.com/",
      "name": "Rolex Official Website",
      "publisher": {
        "@id": "https://www.rolex.com/#organization"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://www.rolex.com/en-us/watches/find-rolex/man#webpage",
      "url": "https://www.rolex.com/en-us/watches/find-rolex/man",
      "inLanguage": "en-US",
      "name": "Men's Rolex Watches",
      "isPartOf": {
        "@id": "https://www.rolex.com/#website"
      },
      "publisher": {
        "@id": "https://www.rolex.com/#organization"
      },
      "description": "Explore our collection of Rolex watches for men. Find the perfect Rolex watch tailored to all aesthetic preferences and lifestyles."
    },
    {
      "@type": "Organization",
      "@id": "https://www.rolex.com/#organization",
      "name": "Rolex",
      "url": "https://www.rolex.com/",
      "sameAs": [
        "https://www.facebook.com/rolex",
        "https://www.instagram.com/rolex",
        "https://twitter.com/rolex",
        "https://www.youtube.com/rolex"
      ]
    },
    {
      "@type": "CollectionPage",
      "@id": "https://www.rolex.com/en-us/watches/find-rolex/man#collectionpage",
      "url": "https://www.rolex.com/en-us/watches/find-rolex/man",
      "mainEntityOfPage": {
        "@id": "https://www.rolex.com/en-us/watches/find-rolex/man#webpage"
      },
      "name": "Men's Rolex Watches",
      "description": "Discover the broad selection of Rolex watches for men: a perfect combination of style and functionality.",
      "image": "https://www.rolex.com/images/example-watch-collection-image.jpg",
      "about": {
        "@type": "Thing",
        "name": "Men's Rolex Watches",
        "sameAs": [
"https://www.wikidata.org/wiki/Q62288",
"https://www.wikidata.org/wiki/Q178794"
	]
      },
      "relatedLinks": [
        "https://www.rolex.com/en-us/watches/find-rolex/gold",
        "https://www.rolex.com/en-us/watches/new-watches"
      ]
    }
  ]
}
</script>

The Wikidata URLs referenced in this example point to the entries for Rolex (the brand), and to watches (the thing). 


Of course, for this particular page we could have a lot of confidence that search engines are well aware of Rolex and what their main product is. But, when you don’t have the brand value of a retailer like Rolex, directly connecting your product category to the Wikidata entries that are associated with it is an effective way to remove any doubts about what the page is for.


I operate on a deep mistrust of search engines’ abilities and on a daily mantra of ‘make the search engines’ job easy’ when optimizing websites.

By directly linking to entries from one of the databases search engines use to understand the world (i.e., Wikidata), you have gone that extra mile to ensure there is no room for doubt when search engines interpret your page.


How to implement your custom CollectionPage schema markup 


Now that you’ve crafted your custom CollectionPage snippets and are ready to test them, you need to upload them to the page. 


For Wix website owners, I will walk you through the workflow step-by-step, but bear in mind that this process is roughly similar for other website platforms as well. 


There are two ways you can add structured data to your Wix web pages—from the SEO settings panel within the Wix Editor for the individual page or from the Edit by Page settings for the page type (Blog, Product, etc).


To add structured data to an individual page using the Wix Editor: 


  1. Go to your editor.

  2. Click Pages & Menu on the left-hand side of the editor.

  3. Click the More Actions icon (three dots) next to the relevant page.

  4. Click SEO basics.

  5. Click the Advanced SEO tab.

  6. Click Structured Data Markup

  7. Click +Add New Markup.

  8. Add your new markup under Write your markup in JSON-LD format.

  9. Click Apply.


The ‘add new markup’ box, overlaid on the Advanced SEO tab of the SEO panel within the Wix editor.

You can also add or manage your structured data for all pages of a certain type by accessing the Edit by Page settings and selecting the desired page type:


  1. Go to the Wix Dashboard for your desired website.

  2. On the left-hand menu, go to Site & Mobile App > Website & SEO > SEO.

  3. Click on SEO Settings  in the Tools and settings section towards the bottom of the page.

  4. Select the desired page type.


From there, head over to the Customize defaults tab to customize the default structured data for that page type.


The ‘customize defaults’ tab in the Edit by Page settings for product pages within Wix. There’s an arrow pointing to the ‘add new markup’ button.

If you are struggling to find a way to upload your own custom schema code to your website, you can also use Google Tag Manager to implement this. It’s a slightly more cumbersome process, but for stores selling high-competition product categories, every advantage matters.


Structured data for eCommerce category pages: When every advantage matters


Personally, as someone who has never been a whiz with code, I love playing around with JSON-LD schema markup and think there is so much we can be doing with it as SEOs for our websites. While these optimizations may feel optional right now, the state of the web continues to advance and, one day, it’ll be a best practice that you may not be able to forego.


To that end, let’s recap what you’ve learned so that you can walk away with a clearer picture of how structured data helps you go that extra mile for your online store:


  • Custom structured data for collection pages is a tactic that aims to prepare your eCommerce website for the future of organic search. 

  • Organic search and search engines are moving towards not just knowing the terms we search for, but understanding thoroughly as well as their relationships to other entities and concepts. 

  • Structured data is one of the elements that powers this understanding.

  • This tactic is a supplemental optimization, meaning that this is for closing the gap on competitors for a page that already does all the right things (e.g., good UX, relevant content, a good product, E-E-A-T). 

  • This is not a ‘hack’ or a silver bullet for your website.

  • Consider Joost de Valk’s proposition that all schema markup should “always be one inter-connected graph.”

  • You can use my template, and hopefully make it a lot better(!), to get started on testing these snippets yourself. 


 

Lorcan Fearon

From London via Nottingham & Kent, Lorcan Fearon is a senior search marketing specialist and operations manager for the UK team of Australia's largest SEO agency. Linkedin 



Get more SEO insights right to your inbox

* By submitting this form, you agree to the Wix Terms of Use and acknowledge that Wix will treat your data in accordance with Wix's Privacy Policy

bottom of page