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

[m4w]

The solution was quite easy for me:
We build a simple Client-Component like this (as an example):

'use client'

const StructuredDataWrapper = ({ data }) => {
  return <script type="application/ld+json">{JSON.stringify(data)}</script>
}

export default StructuredDataWrapper

This data object contains the complete structured data object, which can be set in a server component like this (another example):

import StructuredDataWrapper from './StructuredDataWrapper'

export const StructuredOrganisationData = ({ siteConfig }) => {
  const organisation = {
    '@type': 'Organization',
    name: siteConfig.organisation_name,
    url: siteConfig?.organisation_url,
    address: {
      '@type': 'PostalAddress',
      streetAddress: siteConfig?.organisation_street_address,
      addressLocality: siteConfig?.organisation_address_locality,
      postalCode: siteConfig?.organisation_zip_code,
      addressCountry: siteConfig?.organisation_country,
    },
    contactPoint: [
      {
        '@type': 'ContactPoint',
        telephone: siteConfig?.organisation_telefone,
        contactType: siteConfig?.organisation_contact_type,
        email: siteConfig?.organisation_email,
      },
    ],
  }

  return <StructuredDataWrapper data={organisation} />

See How are Server Components rendered? for more information.

It is quite simple, if this part <script type="application/ld+json">{JSON.stringify(data)}</script> is rendered on the server, nextjs has to hydrate the client, including information about the script tag. This information can be picked up by the crawlers.

But if the script-Tag is inside of a client component, the hydration script contains only the props for StructuredDataWrapper and the crawlers are not able to pick that information.

I hope that helps, although it is basically the same that @blf885 said.

[blf885]

That is exactly what I was thinking! Glad to hear that it works. I was reading some of the documentation while working on metadata and happened across this in the documentation: https://nextjs.org/docs/app/building-your-application/optimizing/metadata#json-ld
It, unfortunately, does not mention anything about server/client components. It seems to me that this documentation should be updated to indicate that is should be used in a client component as you did. I'm just getting to the point in my project where I am implementing this, so I will report if I find anything else useful, but it seems that we have found a good solution without having to move to a new framework. I would like to see them improve the "generateMetadata" API to handle structured Data or at least provide a way to get it in the document's head. The Page Router had ways to have more control over the head, but it seems right now we are forced to have structured data in the body, which is fine according to Google's documentation, but not ideal for separation of concerns and later parsing.

[blf885]

After implementing some structured data, I'm not actually able to reproduce this issue at all. Interestingly, regardless of whether I use the solution we came up with using a client vs server component. Either way, I don't have the issue with the Rich Results test whether the HTML contains the __next_f.push script with the data or not. Is it possible that the way Google parses the page for structured data has been updated? In order to get the __next_f.push script not to show up, I had to move the definition of the "const organisation" from your example inside the client wrapper, otherwise, the data would still obviously show up in the __next_f.push script. So in all honesty, I'm not sure why your solution works. But the fact that it does work combined with my tests using the Rich Result Test tool even when the __next_f.push script contains the data as well is what makes me wonder if Google made changes on their end. Additionally, I was never able to get schema.org's validator to pick up duplicates either, but never was OP.

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

[muneeb-virtus]

yes it is really big for seo perspective, mostly when the competition is too high we really need this to win the race in search engines, i am also facing the same issue and came across this discussion, but sadly i end up with the Astro solution.

[ColeTownsend]

@valley-boy did you find that improved site ranking?