Duplicate Structured Data (being picked up by Google from hydration data in source code) showing in Google Rich results Testing Tool

[valley-boy]

Summary

Hi, We are seeing Duplicate Structured Data in Google Rich results Testing Tool, pretty sure it is being picked up from the hydration data at the bottom of the source code,

e.g. has 1 review, but is showing twice in the testing tool as below image
https://www.nursinghomes.com/ne/omaha/good-samaritan-society-millard/

This is a significant issue as everything we read says that the testing tool is a fair representation of what Google sees, and the fact that the rich results are not showing in Google search results is testament to this being an issue.

To note we have chosen to put the structured data json-ld in the body vs head due to Next making it arduous to add json-ld to the head

Also to note on the schema.org validation tool, the structured data is not showing as duplicated

Any ideas much appreciated, thank you

Additional information

No response

Example

No response

[leopoldkristjansson]

Just to chip in, this seems to be an issue in Nuxt as well. I have some SSR Nuxt v3 projects running on Vercel and I am seeing the same. This probably has nothing to with Vercel though.

This thread is closed and a bit old, but the discussion is relevant: ymmooot/nuxt-jsonld#423

In Nuxt, I am assuming it has something to do with the crawler being able to run JS and hydration being responsible for the issue.

[leopoldkristjansson]

I can confirm I solved this for Nuxt using Nuxt's callOnce util function. More on that here.

@blf885 maybe/probably Next has a way to achieve the same functionality as callOnce for Nuxt?

[blf885]

Has anyone else experienced this? I'm looking at Next JS because it is supposed to help with SEO. A big part of that we will want is good structured data for product pages, but this seems to be an issue with hydration and few people have really said anything on here. Are you still experiencing these issues or have they been solved?

[blf885]

I'm curious, I'm still working to understand how the client and server components work, but if I understand correctly, you should be able to use a server component to avoid this. Because the duplicate is coming from the hydration payload, which isn't sent for server components. Right? So if you have your schema data server side and can use a server component, you should be able to avoid this issue.

[m4w]

We are using server components, but there is still this nextjs script which has the structured data included and which gets picked up additionally by google or schema.org/validator.

This is the nextjs script ( a part of it):

self.__next_f.push([1,"36:[\"$\",\"script\",null,{\"type\":\"application/ld+json\",\"children\":\"{\\\"@type\\\":\\\"Organization\\\",...

[m4w]

But we have a mixed React-Component-Tree which has Client and Server Components nested into each other, which is supported by nextjs.

I guess in the end this results in those scripts.

[blf885]

I see. I did some more reading and I understand the issue better than I did before. Those scripts actually come from the RSC payload, so using RSCs is actually the case where the duplicate happens (which is a key piece I was missing earlier). But the idea remains the same, I wonder if you could use an SSR'd client component to get the schema data so there is no duplicate. I'm still working on figuring that out though. Using a client component would eliminate the self.__next payload for that component I'm pretty sure and as long as you pass the initial data needed for the schema to the client component as a prop so that it can be rendered server side, we should be able to eliminate this issue. The reason it shows up for server components is because the RSC payload includes the actual rendered output and data, but if it was a client component that was SSR'd, the payload would only need hydration information and references for the client component and thus should not have the duplicate schema data.

I know I'm still speculating, I am just working on a project that I know will get to the point of having to figure this challenge out though. So I'm interested in solving it if possible before we get to it and would be interested in any solution you find.

[m4w]

Thanks, I will inspect it in detail now.

[valley-boy]

If it any help.. we found no way round it an rebuilt using Astro. Sorry certainly not a quick fix but a solution!

[blf885]

Oh wow, was the schema data really that big of an issue for you guys? I may be misunderstanding its impact, but it doesn't seem duplicate schema data is that critical for SEO.