How to use more than 1 schema.org schema on a web page

Question

How do you add more than one schema to a web page?

I am using the Organization and WebSite schemas on my home page. I am writing the markup in JSON-LD format.

The Organization schema for the knowledge graph:

<script type="application/ld+json">
     {
          "@@context": "http://schema.org",
          "@@type": "Organization",
          "name": "My Website Name",
          "url": "http://www.example.com",
          "sameAs": [
               "http://www.facebook.com/example-com",
               "http://www.instagram.com/example-com"
          ]
     }
</script>

and the WebSite schema to include my site name in search results (if Google ever decides to implement this):

<script type="application/ld+json">
     {
          "@context" : "http://schema.org",
          "@@type" : "WebSite",
          "name" : "My Website Name",
          "url" : "http://www.example.com"
     }
</script>

As you can see they both have the same name and url properties.

Do I need to specify the 2 separate like I did or can just concatenate the 2? Any preference of which has to go first on the page?

UPDATE 23 February 2016:

I ended with the following using unor's help:

<script type="application/ld+json">
     {
          "@context": "http://schema.org",
          "@graph": [{
               "@type": "WebSite",
               "name": "My Website Name",
               "url": "http://www.example.com"
          }, {
               "@type": "WebPage",
               "name": "My Website Name",
               "url": "http://www.example.com"
          }, {
               "@type": "Organization",
               "name": "My Website Name",
               "url": "http://www.example.com",
               "sameAs": [
                    "http://www.facebook.com/example-com",
                    "http://www.instagram.com/example-com"
               ]
          }]
     }
</script>

Solution 1

In JSON-LD (instead of Microdata/RDFa) you have to repeat the property and its value for each node.

Instead of using a separate script element for each node, you could also use a single script element that contains all your nodes as value of @graph. That way you only have to define the @context (and possibly custom properties) one time.

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@graph": 
  [
    {
       "@type": "WebSite"
    },
    {
       "@type": "Organization"
    }
  ]
}
</script>

The order of the script elements (or the nodes in @graph) shouldn’t matter

Solution 2

Not looking to be a necromancer, but there was a recent article from someone at Yoast that details problems that arise with using the @Graph type when trying to get Google search to "report" the subsequent types, especially with Organization data: link

I would recommend breaking out each type into its own "node" for now instead of using @graph as an array, especially since I can't find a single mention of using @graph with JSON-LD in any of Google's Developer documentation.

Comments

[Brendan Vogt]

I edited my original post to include an answer based on your recommendation. I have shared the code that I used for my home page. Could you please comment on the way and nodes that I used. Does it look correct? Any redundant data?

[Brendan Vogt]

Where do you get all your knowledge from regarding structured data? I have searched high and low using Google but never have I found any answers or blog posts with answers like yours.

[Ronnie Royston]

any advantage to using @graph vs just passing an array of @type objects?

[unor]

@RonRoyston: I wrote about it in this answer (tl;dr: the disadvantage with the @graph-less array is that you have to repeat the @context per item)

[Venkat_09]

Upvoted this, because I can't either. It's almost as if people just started using @graph and I have no idea why. I can't find official documentation on it.

[I Capulet]

It's easier to add itemTypes programmatically when one uses @Graph, so a lot of plugins (e.g. Yoast) ran with it. Doesn't mean it's a good idea though.