1

I saw this question but have a more specific one.

We have structured data describing our "product" in the main page of the product (as in the above question), using schema.org RDFa.

My question is, in other pages using several of these products and providing links to them (not a search result), is it advantageous to also provide schema.org @type and @id (and not all the other structured data about the product)? My idea is that, this way, a crawler would know exactly what we are talking about in the page. But I worry that maybe this would confuse crawlers more than help our referencing.

2
  • You shouldn't let search results get crawled and indexed at all. Google considers it bad user experience when users click off Google's search results only to find themselves on site search results. See Search results in search results - Matt Cutts Whether or not those pages have structured data is irrelevant for SEO. Commented Nov 2, 2021 at 15:26
  • Ok thanks @StephenOstermiller, I reformulated my question because I have other pages that provide links to these products, that would be referenced, not search results only.
    – FBB
    Commented Nov 2, 2021 at 15:28

1 Answer 1

1

First, in terms of using "@type" and "@id" without the rest of the structured data. You should avoid this across different pages, because in my experience Google doesn't always get it right. "@id" is not used in any of their Structured Data documentation so it's not confirmed they support its use in indexing. It does seem to work on the same page. For example, if you use Product schema and Article schema with an "about" property on the same page.

However, I don't recommend including the Product schema on all pages that it appears on unless it is a primary focus, simply because it makes it harder for search engines to figure out what the page primarily is about. Google's documentation states:

"Don't mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page."

Also see the section "Relevance" on the same page.

I won't give a rule of thumb or maximum number of schemas to include on a page, but it should be determined by relevancy to the webpage. For example:

  • On a product page, mark up the specific product, but not an ItemList of Products for the carousel you have showing off related products.
  • On a page that contains a video showing how to use the product, mark up the VideoObject and the Product, either by nesting the Product in the "about" property of the VideoObject, or including them both in separate blocks and connecting them with "@id":"[name of product]" to indicate the relation between the two. (Source)
  • On a blog post that reviews the product, mark up Article, Review, and Product, using either nesting or the "@id" method.

Overall, the process should be:

  1. Asking yourself what the page is primarily about, what its intended use is, how users will likely find it, and what purpose does it serve.
  2. Choosing which SD types best represent the page based on your answers.
  3. Determining how to represent the relation between the multiple entities, if there are multiple.

Additionally, if you're using multiple schemas supported by Google, note that there have been statements from Google that say it will only choose one to base rich results off of in search and it may not choose the one you prefer. The chance of them getting it wrong depends on what you're marking up, but let's say as an example, you have a landing page about a Brand, marked up with Organization schema, and it mentions a few of their products so you also include multiple Product schemas. You probably want the Brand's company info to appear but Google may show one or of the Products instead, so it's just another reason to approach this from a relevancy standpoint rather than sticking SD types everywhere as much as possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.