Is it possible to have schema.org itemtypes for both secure and insecure ports? I run a static-ish site made in Jekyll, and am implementing Schema.org on the individual pages. As a result, I'm trying to use the following:

<div itemscope itemtype="//schema.org/Organization">
    <a itemprop="url" class="navbar-brand" href="/">
        <img itemprop="logo" src="/images/logo.png">

This doesn't validate with Google's Structured Data Testing Tool. It doesn't register the Items as existing. Is there a good way to implement Schema.org in a static page hosted on both SSL and non-SSL ports?

  • I'm confused, what doesn't work? seems to be working fine... google.com/webmasters/tools/… Sep 2, 2014 at 17:16
  • Rich snippets will always return http://www.example.com when using both /file.png or protocol selector // because it doesn't know the domain since the test is being run on their server not yours... Maybe I've misunderstood the question. Personally I would enforce the SSL regardless of non-input pages as so many businesses and websites are doing nowadays regardless, or if your able to use PHP then you could use a PHP Variable to add https or http depending which URL was first accessed, few ways this can be done really. Sep 2, 2014 at 17:22
  • I had used the wrong name for the tool. Can't listen and type at the same time. I'm actually entering the https:// URL into the Structured Data Testing Tool, and it is coming back with errors. Browsers are also complaining about insecure data in a secure page when I test there.
    – Jack M.
    Sep 2, 2014 at 22:12
  • Do you have a test URL so I can take a look? Sep 3, 2014 at 7:39

1 Answer 1


Typically, user agents wouldn’t dereference these URIs.

There should be absolutely no problem in using the Schema.org HTTP URIs on a HTTPS site. In fact, many other vocabularies (used for Microdata or RDFa) provide only HTTP URIs, so you have no choice there. I’d even say it’s bad practice to provide multiple vocabulary URIs for the same concept, as consumers might not look for and "understand" all variants.

I recommend to use the HTTP variant for Schema.org in your markup, because:

Update 2015-11: With version 2.2, a FAQ entry was added:

Q: Should we write https://schema.org or http://schema.org in our markup?

In summary:

  • HTTPS is now explicitly supported, too.
  • Sometime in the future, the site will use HTTPS by default, and for the examples URLs with HTTPS will be preferred.
  • Both variants can be used:

    both https://schema.org and http://schema.org are fine

  • This answer is misleading with respect to schema.org. It's true that FAQ 19 says that https: IRIs are supported, but in truth they're not supported as http: IRIs. An application is going to resolve the IRI to find out more information about the term. The webpage this finds contains RDFa attributes to facilitate this, but they all refer to the http: versions, regardless of whether it was fetched via HTTP or HTTPS. This means applications encountering the https: form are at a significant disadvantage.
    – richard
    Jul 4, 2017 at 15:04
  • @richard: Yes, this is what I describe in the first part of my answer. However, Schema.org doesn’t seem to care much about the Semantic Web/Linked Data world -- when they say "support", it means: authors can use HTTPS URIs, because the Schema.org sponsors (i.e., the search engines) (and probably many more consumers, as Schema.org is well-known/popular) support it, too. To make use of data described with Schema.org, they don’t have to use its RDF definition, and if they do, it’s easy for them to make the HTTPS variants equivalent. It would be nice to reflect this in the RDF, but not required.
    – unor
    Jul 4, 2017 at 15:13
  • Schema.org are not alone in downplaying the RDF basis to their standard: Dublin Core do the same. This is because RDF has had a bad press, largely as a result of early uses of the RDF/XML format (e.g. in RSS 1.0). But Schema.org is built on RDF, and if you dig, they acknowledge it by publishing RDF definitions of their vocabularies. Some parsers will treat it as RDF while others will treats it as a set of custom attributes and IRIs. Both approaches have advantages and neither is wrong. But using https: IRIs penalises applications doing the former with no gain.
    – richard
    Jul 4, 2017 at 15:23
  • @richard: I agree, which is why I still recommend to use their HTTP URIs.
    – unor
    Jul 4, 2017 at 16:15

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.