Rich snippets via <script type="application/ld+json">

[nicooprat]

Looks like the new preferred way to structure datas is to add a special script like this: https://developers.google.com/search/docs/guides/intro-structured-data

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Recipe",
  "name": "Grandma's Holiday Apple Pie",
  "author": "Elaine Smith",
  "image": "http://images.edge-generalmills.com/56459281-6fe6-4d9d-984f-385c9488d824.jpg",
  "description": "A classic apple pie.",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4",
    "reviewCount": "276",
    "bestRating": "5",
    "worstRating": "1"
  }
}
</script>

Can't see anything in the docs that could do that. Any idea or workaround?

It seems that (deprecated?) package dochead had a way to do it by the way: https://github.com/kadirahq/meteor-dochead#docheadaddldjsonscriptjsonobj

[dr-dimitru]

@nicooprat This is the well known alternative to schema.org markup.
We haven't implemented it as we don't use it.
I think we can add it to the package. If you have thoughts and suggestions now - it's good time to tell it :)

[dr-dimitru]

At least lest pick a proper property name:

• ldjson

WDYT?

[nicooprat]

Glad to hear! Would it be possible to reuse the script object? Like:

  script: {
    twbs: 'https://maxcdn.bootstrapcdn.com/bootstrap/2.2.0/js/bootstrap.min.js', // By default a string is the `src` to keep regular behavior working
    ldjson: {
     type: 'application/ld+json',
     content: jsonObject
   }
  }

Something more modular that could cover other use cases that we don't think of at the moment I guess...

[dr-dimitru]

Hello @nicooprat ,

This was implemented in v2.0.11, please see docs for ld+json usage.

Let me know if it works well for you

[dr-dimitru]

Should we close this one too?

[nicooprat]

Couldn't test it for now, but I guess it's ok. For me the real ✅ would be if I can make it work with a prerendering service in order to make Facebook & Google crawlers see its content.

[dr-dimitru]

We use schema.org markup works well for us.

Is there any benefits using ld+json, except it's just different way to represent same data ?

[nicooprat]

Last time I worked with rich snippets, schema.org was the preferred way. Now it looks like they changed their mind, so the first advantage would be to be sure it isn't obsolete in the next few months/years:

I guess depending on the context it's easier to include all datas in one script, or to embed it in each component...

[dr-dimitru]

@nicooprat Could you drop me a link on the working website where it is fully implemented, wondered to test it with different crawlers.

[nicooprat]

Didn't implemented it on mine for now! Can't find a website which has implemented it on itself, only websites providing some code examples...

[dr-dimitru]

only websites providing some code examples...

Same here, okay, drop it here if you will find one. I'll do the same.

[nicooprat]

Finally had time this morning to test ld+json. Works great so far, thanks! I'm just wondering if the innerHTML function is reactive? Looks like it's not. Here's a sample:

FlowRouter.route('/@:username', {
  script: {
    BreadcrumbList: {
      type: 'application/ld+json',
      innerHTML({username}) {
        const author = Users.find({username}).fetch()[0]
        return author && JSON.stringify({
          "@context": "http://schema.org",
          "@type": "BreadcrumbList",
          "itemListElement": [{
            "@type": "ListItem",
            "position": 1,
            "item": {
              "@id": author.getPath(),
              "name": author.profile.name,
            }
          }]
        })
      }
    }
  }
})

Unfortunately the function runs only once.

[dr-dimitru]

@nicooprat as I've mentioned here:

I have no plans to make it reactive, it will be overkill for performance.

It applies to all options at this "meta" package. As always waitOn is meant to solve this.

I'm sorry if this breaks your implementation :(

[nicooprat]

Yeah, sorry already forgot that. Indeed I'm seeing that component based subscriptions can create some unexpected issues like this.

I'll try to use waitOn only when prerendering. Related to veliovgroup/spiderable-middleware#4 (comment)

Thanks again for your work :)

[dr-dimitru]

Thanks again for your work :)

Thank you for using it :)

I'll try to use waitOn only when prerendering. Related to veliovgroup/spiderable-middleware#4

Closing in favor of veliovgroup/spiderable-middleware#4 (comment)

Feel free to reopen it.