Re: Is preferred over Is wrong?

Let me also answer this here, since I commented in
already. The situation is as follows:

"1. the official definition of each term is via a URL of
the form e.g.''. These are the canonical
identifiers terms.

2. the site happens to also work currently via https://

3. there is consensus amongst the partners that they markup (in whatever format) in which is written instead of to be
perfectly ok. For specifics of actual support for this, see each
company individually.

4. at this time we (the 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,


On 18 April 2015 at 15:59, Aaron Bradley <> wrote:
> To use Thing as an example, both and
> return a 200 response header.
> Is http:// preferred though, and his https:// actually incorrect?
> The Meusel and Heiko paper on fixing 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 implementation on their site.  And
> though it's conflating web page consumption with deferencing of URIs,
> nonetheless webmasters have been observed using 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 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 URLs in Google, 31,000
> in Bing).
> - Tangentially, use of a canonical would also stop the propagation of
> URLs (currently just one www page indexed in Google, but
> 31,800 in Bing).
> - 301 direct* to* - essentially
> resolving all technical issues with one stroke.  Note that an open GitHub
> issue [3] proposes redirecting* to* but doesn't
> wrap a secure to non-secure redirect in this, and would actually redirect
> " to".
> [1] Robert Meusel and Heiko Paulheim, Heuristics for Fixing Common Errors in
> Deployed Microdata
> [2] https - Secure and non-secure Markup?
> [3] CODE: redirect to
> · Issue #4 · schemaorg/schemaorg
> [4] Official Google Webmaster Central Blog: HTTPS as a ranking signal

Received on Tuesday, 21 April 2015 20:25:06 UTC