: Schema.org itemtype identifier - Should it use relative urls or https links? In the age of SSL everywhere there are still major sites that lack it. Schema.org for example allows HTTPS but resolves

@Ogunnowo487

Don’t use protocol-relative Schema.org URIs:


I wouldn’t expect all Microdata consumers to handle these URIs correctly (while it’s common for links or embedded resources, values of the itemtype attribute typically don’t get dereferenced).
They fail when a different protocol than HTTP/HTTPS is used (for example, file). It’s not just that the link is broken then (well, there is no "link" anyway), but that the identifier for the Schema.org vocabulary/types/properties no longer works: Schema.org consumers will likely fail recognizing that your Microdata is using the Schema.org vocabulary (well, because it isn’t in case of different protocols).


Regarding HTTP vs. HTTPS, see also my answer to a similar (not duplicate) question: I’d recommend to always use the HTTP variant of Schema.org URIs.

Vote Up Vote Down

@Kimberly868

You could use either, but if you want to force HTTPS then just specify it as then you take any decision-making about it away from the web-browser.

// would be more suited for use on a website where some of your URL's will be and some and this method can enable you to load resources using the same protocol as the main page requested.

HTTP is not being phased out by any means and not all websites are moving to HTTPS, because the purpose of using SSL certificates on websites is to protect data in transit between a web browser client and the web server. If a website only has publicly available content on its pages with no secure login areas or form fields, for example a corporate website or personal blog, then the additional annual cost of purchasing an SSL certificate may seem unjustified. Keeping the schema.org site working on both HTTP and HTTPS ensures compatibility with all uses moving forward, and it doesn't cost any extra to provide HTTP!

Vote Up Vote Down