- From: Dan Brickley <danbri@google.com>
- Date: Tue, 21 Apr 2015 21:24:37 +0100
- To: Aaron Bradley <aaranged@gmail.com>
- Cc: "schema.org Mailing List" <public-schemaorg@w3.org>
Let me also answer this here, since I commented in https://plus.google.com/u/0/106943062990152739506/posts/8KoJZYvZEfL already. The situation is as follows: "1. the official definition of each schema.org term is via a URL of the form e.g.'http://schema.org/Person'. These are the canonical identifiers forschema.org terms. 2. the site happens to also work currently via https:// 3. there is consensus amongst the schema.org partners that they considerschema.org markup (in whatever format) in which https://schema.org/ is written instead of http://schema.org/ to be perfectly ok. For specifics of actual support for this, see each company individually. 4. at this time we (the schema.org team) have not decided to promote the https: version of the site over the http: version, although this is generally an appealing idea. There are some peculiarities in the way the site is hosted and implemented which I want to investigate properly first (partially w.r.t. using a naked/apex/bare domain name with https)." Hope this helps clarify, Dan On 18 April 2015 at 15:59, Aaron Bradley <aaranged@gmail.com> wrote: > To use Thing as an example, both http://schema.org/Thing and > https://schema.org/Thing return a 200 response header. > > Is http:// preferred though, and his https:// actually incorrect? > > The Meusel and Heiko paper on fixing schema.org errors [1] buckets use of > "the https protocol" under common errors. And a cogent Stack Exchange > answer [2] says that one should using http, saying "Typically, user agents > wouldn’t dereference these URIs." > > So, sponsors/ontologists, what's the official story? :) > > This keeps coming up because for many months now Google has been encouraging > webmasters to use https:// for their sites [4]. Because Google has tied > this explicitly to improved search engine rankings, the audience most likely > to consume and act on this information - search marketers - is the same > group most likely driving schema.org implementation on their site. And > though it's conflating web page consumption with deferencing of URIs, > nonetheless webmasters have been observed using https://schema.org and > justifying doing so because of this Google initiative. > > If https *is* incorrect, then there are thing that can be done to mitigate > against its use: > > - State that preference or requirement for http:// in the documentation. > > - Add a rel="canonical" statement to each schema.org page where the href > value uses the http:// form of the URL. Not only would that send a clear > message to any human examining the canonical, but send a message ("a strong > hint" in the words of Google) to the search engines not to index the > https:// form, and so they wouldn't be as likely to surface in search > results (there are currently 1,890 https://schema.org URLs in Google, 31,000 > in Bing). > > - Tangentially, use of a canonical would also stop the propagation of > www.schema.org URLs (currently just one www page indexed in Google, but > 31,800 in Bing). > > - 301 direct https://schema.org/* to http://schema.org/* - essentially > resolving all technical issues with one stroke. Note that an open GitHub > issue [3] proposes redirecting www.schema.org/* to schema.org/* but doesn't > wrap a secure to non-secure redirect in this, and would actually redirect > "https://www.schema.org/Person to https://schema.org/Person". > > [1] Robert Meusel and Heiko Paulheim, Heuristics for Fixing Common Errors in > Deployed schema.org Microdata > http://bit.ly/1MZdEhO > > [2] https - Secure and non-secure Schema.org Markup? > http://bit.ly/1HE4ZwH > > [3] CODE: redirect http://www.schema.org/Person to http://schema.org/Person > · Issue #4 · schemaorg/schemaorg > https://github.com/schemaorg/schemaorg/issues/4 > > [4] Official Google Webmaster Central Blog: HTTPS as a ranking signal > http://googlewebmastercentral.blogspot.ca/2014/08/https-as-ranking-signal.html >
Received on Tuesday, 21 April 2015 20:25:06 UTC