4

We have a paginated category page. We are not clear how to go about the schemas in pagination, especially for the 2nd and subsequent pages.

Below is what we currently defined. The 1st page has the CollectionPage schema:

{
    "@context":"http://schema.org",
    "@type":"CollectionPage",
    "@id":"https://www.example.com/cat?pg=1",
    "url":"https://www.example.com/cat?pg=1",
    "breadcrumb":{...},
}

And, the 1st page's ItemList schema:

{
    "@context":"https://schema.org",
    "@type":"ItemList",
    "@id":"https://www.example.com/cat?pg=1#cat-page",  // 1st pg URL, with hash URI
    "url":"https://www.example.com/cat?pg=1",           // 1st pg URL
    "name":"Running Shoes",
    "numberOfItems":"490",
    "mainEntityOfPage":"https://www.example.com/cat?pg=1", // 1st pg URL
    "itemListElement":[
        {
            "@type":"ListItem",
            "position":"1",
            "url":"..."
        },{
            ...
        },{
            "@type":"ListItem",
            "position":"50",      // 50 items per page
            "url":"..."
        }
    ]
}

On 2nd and subsequent pages, we have only an ItemList, as below:

{
    "@context":"https://schema.org",
    "@type":"ItemList",
    "@id":"https://www.example.com/cat?pg=1#cat-page",  // 1st pg URL, with hash URI
    "url":"https://www.example.com/cat?pg=1",           // 1st pg URL
    "name":"Running Shoes",
    "numberOfItems":"490",
    "mainEntityOfPage":"https://www.example.com/cat?pg=1", // 1st pg URL (CollectionPage there)
    "itemListElement":[
        {
            "@type":"ListItem",
            "position":"51",
            "url":"..."
        },{
            ...
        },{
            "@type":"ListItem",
            "position":"100",      // 50 items per page
            "url":"..."
        }
    ]
}

NOTE that the 2nd page's ItemList has it's @id, url and mainEntityOfPage all use the URL of the 1st page, and 2nd page's URL is no where used. It's only the itemListElement array that changed compared to it's 1st page declaration.

Google says (point 1, last figure) that for HTML data, it collates paginated listing and builds a single page digest. For schema, ItemList's numberOfItems is defined to hold the total count of items across pages. So, it expects consumers to concatenate splitted instances of ItemList. Though HTML and Schema are different entities, I assume consumers like Google and others will handle paginated schema ItemList.

However, what is not clear is how to declare the @id, url and mainEntityOfPage for the paginated ItemList. I set them up to point to the first instance of it on the 1st page.

The query is: is this the right way to do the schemas for paginated category pages? Or, there's something we are missing or possibly a better method?

Ethan
  • 4,915
  • 1
  • 28
  • 36
  • 1
    We take a similar approach. Each page (item) is fully described. Then we use a catalog (e.g. `@OfferCatalog` for an `itemListElement` and `itemListOrder`) to collect `@Product` in a single structure. The `@id` for each `@Product` is on a separate page. We take a similar approach to `@DataCatalog`. It's a fine-grained method to specify `hasPart` and/or `isPartOf`. The above approach is correctly parsed and assembled by Google SDTT. – Jay Gray Jul 01 '19 at 18:20
  • Do you have a Google/Bing source for the claim that they want a (self-referential, I suppose?) `canonical` only on the first page? – unor Jul 01 '19 at 21:55
  • @JayGray Could you test that Google is concatenating the lists across pages (pagination) into one, on SDTT? I was not sure that's possible on SDTT. Slightly off note, the other thing that I found is Google is now respecting `@id` to the same page, but _may_ not across pages (making it necessary to also provide `url` in such cases, if that helps). – Ethan Jul 02 '19 at 05:59
  • @Ethan we use an absolute URI, not a relative URI for`@Type`. I can confirm that GSDTT will properly concatenate the list of items on "multiple pages" (concatenate multiple schema.org JSON-LD structures). I write `pages` here, but in fact our structures are in different directories and referenced by a `page`. Most of our concepts are not page-specific; instead, concepts are referenced on one or more pages. GSDTT properly builds the `knowledge graph` of those concepts defined in different directories. – Jay Gray Jul 02 '19 at 11:20
  • @unor I made a mistake with the note on self-referencing canonical on 1st page. Google says it should point to a 'view-all' page, but that doesn't exist for us (this opens a new Q: what should the canonical of the first page be in this case? or, just left out?). We defined it (wrongly) pointing to 1st page's URL to avoid multiple indexation due to facet params. I have updated the query (also added the point of `numberOfItems` that I had initially missed out). – Ethan Jul 02 '19 at 16:02
  • @JayGray That's good to know. I don't know how to test with Google SDTT schames from different directories, it will be great to see the final knowledge graph being built. Can you tell me how to do that? – Ethan Jul 02 '19 at 16:07

0 Answers0