<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 12/01/2016 08:30 AM, Jonathan
Vanasco wrote:<br>
</div>
<blockquote cite="mid:1BABB4AE-15D5-45C1-B09D-073157DEE1F1@2xlp.com"
type="cite"><br>
<div>
<div>On Nov 28, 2016, at 4:07 PM, Jeff Dyke wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div>And you do get a small SEO boost for being https
forward.</div>
</div>
</blockquote>
<br>
</div>
<div>Not necessarily -- some SEO engines are now doing the
opposite, and penalizing non-https sites. Google announced
plans to start labeling non-https sites as "insecure" in 2017
too.</div>
<div><br>
</div>
<div>It's incredibly simple (and free) to set up SSL via
LetsEncrypt on all domains - so I would do that.</div>
</blockquote>
The LetsEncrypt concept was corrupted from the start by it's use by
hackers / malware sites. If you're serious with security then an
oldschool $10 cert from Comodo is far better. <br>
Sure LE is a solution, but multiple SSL cert providers is getting a
bit complex really.<br>
<br>
( plus LE have already been hacked themselves )<br>
<blockquote cite="mid:1BABB4AE-15D5-45C1-B09D-073157DEE1F1@2xlp.com"
type="cite">
<div><br>
</div>
<div><br>
</div>
<div>On Nov 28, 2016, at 2:37 PM, steve wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span"
style="border-collapse: separate; font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; ">It seems that search engines are
probing https: even for sites that don't offer it, just
because it's available for others, with the end result that
pages are being attributed to the wrong site.</span></blockquote>
<div><br>
</div>
<div>In terms of your current situation with SEO and attribution
-- can the original poster share any examples of the search
engines and domains/results? I'd honestly love to see some of
what is going on, what you interpreted pretty much never
happens. A search engine might probe for data via https; but it
won't attribute a resource to a domain/protocol it didn't
actually load it from. This alleged Search Engine behavior
is something that I've never seen with Google, Bing (or other
"standard" engines) and I've managed SEO for a handful of top
publishers. From my experience and a lack of evidence, I have
no reason to believe this is the actual problem. <br>
</div>
</blockquote>
Well, no as I've fixed this. However, if you have a probe for site x
on https: and it doesn't exist, then the default https site for that
IP address will be returned. Depending on configuration, it may
still be attributed to the original search domain. I don't
understand why people keep trying to shoot me down on this!<br>
<blockquote cite="mid:1BABB4AE-15D5-45C1-B09D-073157DEE1F1@2xlp.com"
type="cite">
<div><br>
</div>
<div>OTOMH, there are a lot of possible issues that could cause
this. </div>
<div><br>
</div>
<div>The most likely issue is that there is a misconfiguration on
nginx and 3 things are happening:</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>1.
there exists a link to the "wrong domain" for the content
somewhere on the internet</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>2.
nginx is serving a file on the "wrong domain"</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>3.
the pages do not list a "canonical url"</div>
<div><br>
</div>
<div>If you have a thoroughly broken nginx installation and are
serving the content on a wrong domain, almost every search
engine will transfer the resource's link equity to the canonical
URL. They're only going to show the data on the wrong
domain/scheme if you allowed it to be served on the wrong
domain/scheme, and failed to include a canonical.</div>
</blockquote>
Note: I host these sites, I do not write the sites in question.
Addition of canonical headers is beyond my remit, although I suppose
nginx could be coerced into adding one. Interestingly, neither of
the CMSes I primarily work with ( Magento and WordPress ) seem to
add in canonical headers either. I must research this further.<br>
<blockquote cite="mid:1BABB4AE-15D5-45C1-B09D-073157DEE1F1@2xlp.com"
type="cite">
<div><br>
</div>
<div>If you are dealing with a broken search engine/spider for
random service, there are lots of those, and you want to address
it.... The problem could be because the client doesn't process
SSL or SNI correctly, so you might be able to do:</div>
<div><br>
</div>
<div>A) single certificate HTTPS on IP#1 + (SNI HTTPS &
plain-http on IP#2)</div>
<div>B) single certificate HTTPS on IP#1 + SNI HTTPS on IP#2 +
Plain HTTP on IP#3</div>
<div><br>
</div>
<div>You could also just isolate the given spiders by their
browser id, and handle them with custom content or redirects.</div>
<div><br>
</div>
<div>None of the major search engines work in the manner you
suggest though.</div>
</blockquote>
The problem was with Google...<br>
<br>
<pre class="moz-signature" cols="72">--
Steve Holdoway BSc(Hons) MIITP
<a class="moz-txt-link-freetext" href="http://www.greengecko.co.nz">http://www.greengecko.co.nz</a>
Linkedin: <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/steveholdoway">http://www.linkedin.com/in/steveholdoway</a>
Skype: sholdowa</pre>
</body>
</html>