On 12/01/2016 08:30 AM, Jonathan Vanasco wrote:
>
> On Nov 28, 2016, at 4:07 PM, Jeff Dyke wrote:
>
>> And you do get a small SEO boost for being https forward.
>
> 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.
>
> It's incredibly simple (and free) to set up SSL via LetsEncrypt on all
> domains - so I would do that.
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.
Sure LE is a solution, but multiple SSL cert providers is getting a bit
complex really.

( plus LE have already been hacked themselves )
>
>
> On Nov 28, 2016, at 2:37 PM, steve wrote:
>
>> 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.
>
> 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.
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!
>
> OTOMH, there are a lot of possible issues that could cause this.
>
> The most likely issue is that there is a misconfiguration on nginx and
> 3 things are happening:
> 1. there exists a link to the "wrong domain" for the content somewhere
> on the internet
> 2. nginx is serving a file on the "wrong domain"
> 3. the pages do not list a "canonical url"
>
> 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.
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.
>
> 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:
>
> A) single certificate HTTPS on IP#1 + (SNI HTTPS & plain-http on IP#2)
> B) single certificate HTTPS on IP#1 + SNI HTTPS on IP#2 + Plain HTTP
> on IP#3
>
> You could also just isolate the given spiders by their browser id, and
> handle them with custom content or redirects.
>
> None of the major search engines work in the manner you suggest though.
The problem was with Google...

--
Steve Holdoway BSc(Hons) MIITP
http://www.greengecko.co.nz
Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx