Форум Практика оптимизации Частные вопросы - ранжирование, индексация, бан

Как перейти на HTTPS сохранив ранжирование в Яндекс

123 4
Александр И
На сайте с 20.11.2016
Offline
24
Александр И
12775

Здравствуйте.

Начиная с января этого года, Google Chrome помечает HTTPS сайты, как "Надежный".

Начиная с Chrome 56, все HTTP сайты, на которых размещены формы отправки данных, будут получать метку "Не надежный".

Исходя из этого, многие веб-мастера столкнулись с проблемой, что вроде бы уже время переводить сайты на HTTPS протокол для Google, но при этом Яндекс не очень положительно относится к HTTPS по следующим причинам:

1. Яндекс, в отличии от Google, не использует HTTP/2.

Если ваш HTTPS сайт доступен поддерживает HTTP/2, Яндекс будет все-равно использовать медленный HTTP/1.1 через механизм поддержки старых версий (fallback).

2. Многие веб-мастера неверно реализовывают поддержку HTTPS на своих сайтах.

Бывали даже случаи, когда сайты выпадали из индекса из-за неверной настройки сервера.

3. Возможны другие нюансы передачи веса ссылок HTTP зеркала.

Лично у меня, сайт внезапно выпадал за ТОП-100 по некоторым брендовым запросам, после выбора HTTPS, как главного зеркала.

Дальше я расскажу вам, как угодить клиенту, Google и Яндекс одновременно.

В результате, в поисковой выдачи Яндекс, у нас будет все тот же HTTP сайт, в Google HTTPS версия (по желанию), а клиент будет получать быструю HTTP/2 версию (если поддерживает, даже если он перешел по HTTP ссылке) или HTTP-версию, если он не поддерживает HTTP/2.

Первое, что нам нужно сделать, это включить поддержку HTTPS на сервере.

Опционально, я рекомендую включать поддержку HTTP/2, чтобы более 70% ваших пользователей, получали быструю версию вашего сайта.

Как это сделать на примере Ubuntu 16.04 LTS + Nginx + Let's encrypt (можно использовать любой другой сертификат, просто укажите на него путь и пропустите шаги для Let's encrypt)

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

После включения поддержки HTTPS версии вашего сайта (предпочтительно HTTP/2), вы можете открыть ваш сайт, как по HTTP, так и по HTTPS протоколу.

Дальше, мы добавляем HTTPS версию нашего сайта в Яндекс вебмастер и Google Webmaster.

Открываем robots.txt и указываем (где site.com - адрес вашего сайта):

Host: http://site.com

Дополнительно, вы можете закрепить результат в Яндекс Вебмастер - Индексирование - Переезд сайта

Это означает, что Яндекс должен индексировать HTTP-версию сайта, как главное зеркало, несмотря на появления HTTPS-версии.

Если мы хотим, чтобы Google начал отдавать предпочтение HTTPS-версии, обращаем внимание на

<link rel="canonical" href="https://site.com">, который должна отвечать ваша HTTP-версия сайта.

То-есть, на странице http://site.com/1.html, должен быть указан <link rel="canonical" href="https://site.com/1.html">.

Многие CMS, например, WordPress, прописывают этот тег автоматически.

Просто убедитесь, что в настройках сайта, главным адресом указана HTTPS-версия, если вы хотите, чтобы Google ранжировал именно ее.

Яндекс будет игнорировать этот тег и использовать директиву Host.

Если вы хотите, чтобы Google тоже отдавал предпочтение HTTP версии сайта, тогда обязательно уточните наличие canonical, который указывать на HTTP версию вашего сайта.

Я рекомендую отдавать Google canonical на HTTP версию сайта ибо больших плюсов в ранжировании HTTPS вам не принесет, если вообще принесет сейчас.

Тема все таки направлена на угождение Google Chrome, в первую очередь и на минимальные колебания позиций в поисковых системах.

А теперь самое главное - ваш пользователь будет получать HTTPS версию сайта, даже если он перешел из результатов поиска, где указана HTTP ссылка.

Без редиректов!

И поможет нам в этом технология HSTS.

Это заголовок, который отправляет ваш сервер и говорит, что если клиент хотя бы раз открыл HTTPS версию, то любые запросы к HTTP должны обрабатываться, как к HTTPS.

Простыми словами, если вы зашли на HTTPS://site.com, набрав в адресной строке HTTP://site.com, вы получите все-равно HTTPS://site.com.

Это отличается от редиректа тем, что редирект отсутствует и клиенты, которые не поддерживают или не знают о HTTPS, все также будут получать HTTP версию.

HSTS поддерживают практически все браузеры, которые поддерживают HTTP/2 или SPDY/3.1

http://caniuse.com/#search=hsts

Ваш сервер должен возвращать следующий заголовок (именно такой, без нюансов - дальше объясню)

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

В инструкции от DigitalOcean, на которую я ссылался выше, уже включен HSTS, вам только нужно добавить preload после includeSubDomains;

Если вы следовали другой инструкции по установке HTTPS на сервере, вы можете отправить этот заголовок из вашей CMS следующим PHP кодом

header('Strict-Transport-Security: max-age=63072000; includeSubDomains; preload');

или установив соответствующий плагин для WordPress (там же можно запретить content sniffing и включить другие опции защиты перехвата и модифицирования трафика)

https://wordpress.org/plugins/security-headers/

Дальше, мы отправляем заявку, чтобы ваш сайт включили в список HSTS preload.

Если вы все правильно сделали, он будет включен в этот список в течение месяца.

Просто указываем адрес вашего домена

https://hstspreload.org/

Это означает, что все современные браузеры, которые поддерживают HTTP/2 или SPDY/3.1 (примерно 80% пользователей), будут получать HTTPS версию вашего сайта, даже если они никогда ее не посещали и запрашивают HTTP версию.

То-есть, Яндекс и Google (если вы так решите), будут сканировать HTTP версию.

В результатах поиска будет HTTP версия.

Но при переходе по ссылке из SERP, возможно два сценария:

1. Если пользователь использует современный браузер (такой, как Google Chrome/Opera Blink/Яндекс браузер/Firefox/Edge/IE11), он получит HTTPS версию по HTTP/2 (или SPDY/3.1) протоколу.

Без редиректов, с минимальной утереей производительности по сравнению с HTTP версией (HTTP/2 поддерживает сжатие заголовок, множество запросов по одному подключению и другие функции, благодаря которым, HTTPS версия будет работать все также быстро, как и HTTP).

2. Если пользователь использует старый браузер (Android 2.3, Nokia браузер, Opera Mini, Opera Mobile, IE8) пользователь получить HTTP версию сайта, которая будет у него работать гораздо быстрее, чем HTTPS на старом протоколе HTTP/1.1.

Таким способом, мы решаем следующие проблемы:

1. Google Chrome помечает ваш сайт, как безопасный.

2. Нам стают доступные новые технологии и преимущества HTTPS, типа Web Push, ServiceWorker, AMP без потери производительности и проблем с ранжированием в Яндексе.

3. Пользователи, которые выходят в сеть из старых и медленных браузеров (10-20%), будут получать HTTP версию, более производительную версию вашего сайта, тем самым, вы сохраните отличные поведенческие факторы.

4. Старые ссылки на HTTP версию и новые на HTTPS будут учитываться в одинаковой мере.

Я все-таки советую использовать HTTP ссылки по тем же причинам, что выше. - Пользователь всегда будет получать версию сайта, которая работает в его браузере лучше.

Но если кто-то из пользователь разместит ссылку на HTTPS, она будет ранжироваться, ничего страшного не случится.

[Удален]
#1

Абсолютно верно! Очень многие обращаются после корявого переезда на https по различным "мануалам"...

D
На сайте с 28.06.2008
Offline
1101
Dram
#2

Не смог нагуглить как убрать ошибку?

Warning: Unnecessary HSTS header over HTTP
The HTTP page at http://site.ru sends an HSTS header. This has no effect over HTTP, and should be removed.
Александр И
На сайте с 20.11.2016
Offline
24
Александр И
#3
Dram:
Не смог нагуглить как убрать ошибку?

Этот заголовок должна возвращать только HTTPS версия сайта.

То-есть, нужно предварительно проверить протокол по которому запрашивается сайт.

Если не ошибаюсь

if ((!empty($_SERVER['HTTPS'])) or ($_SERVER['SERVER_PORT']  == 443))
    header('Strict-Transport-Security: max-age=63072000; includeSubDomains; preload');

Один раз посетив HTTPS, вы будете получать HTTPS, даже запрашивая HTTP.

А уже благодаря HSTS Preload List (который встроен в современные браузеры и регулярно обновляется из одного хранилища),

мы получаем HTTPS по-умолчанию, даже если никогда не посещали HTTPS версию.

Не забудьте добавить заявку на включение вашего домена в этот список.

D
На сайте с 28.06.2008
Offline
1101
Dram
#4

Скобок нет + invalid condition "(!empty($_SERVER['HTTPS']))"

Александр И
На сайте с 20.11.2016
Offline
24
Александр И
#5
Dram:
Скобок нет + invalid condition "(!empty($_SERVER['HTTPS']))"

Скобки в этом случае не обязательны

http://stackoverflow.com/questions/2125066/is-it-bad-practice-to-use-an-if-statement-without-brackets

http://stackoverflow.com/questions/11650640/why-isnt-serverhttps-set-to-1

Как я понял, определенные ключи в $_SERVER могут отсутствовать или отдавать разные значения в зависимости от сервера и сборки.

Приведите дамп var_dump($_SERVER); или var_dump($_SERVER['HTTPS'], $_SERVER['SERVER_PORT'], $_SERVER['HTTP_X_FORWARDED_PROTO']); для HTTP версии

и полный текст ошибки для кода выше.

XPraptor
На сайте с 15.10.2004
Offline
333
XPraptor
#6

Зачем так усложнять себе жизнь, зеркаля протоколы.

Редирект на единственную версию https является самым правильным выходом.

В панелях ПС менять даже не обязательно ничего, они сами вкурят, что у вас https теперь сайт.

В .htaccess вставляем строки:

RewriteEngine On

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteCond %{HTTPS} off

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

И всё, сработает хоть на апаче, хоть на нгинксе, который блокирует заголовки апача.

Единственный баг может возникнуть, если у вас ISP панель и вы в ней поставили галку "Переводить все запросы http на https" - тогда либо такую галку нужно отключить, либо этот код не добавлять в файл - оно с галкой тоже работает по этому же принципу.

Александр И
На сайте с 20.11.2016
Offline
24
Александр И
#7
XPraptor:
Зачем так усложнять себе жизнь, зеркаля протоколы.
Редирект на единственную версию https является самым правильным выходом.

Да, если 100% пользователь пользователей заходят с последней версии Google Chrome и корректная индексация Яндекс не нужна.

В противном случае, некоторые пользователи с поддержкой только уязвимых методов шифрования (SSL), вообще не увидят сайт при корректной настройке сервера.

Яндекс и пользователи, которые открывают сайт из под динозавров (IE8, IE9, IE10, Opera Mini, Opera Mobile, Opera 12) будут использовать медленный HTTP/1.1, хотя это не обязательно!

А так:

1. 80% пользователей использующих современные браузеры, в том числе Google Chrome, который помечает сайт, как "Надежный" получают быструю HTTP/2 версию сайта через HTTPS.

2. Яндекс и по желанию Google, используют быстрый HTTP без шифрования (ибо шифрования им не нужно, они ведь не будут отправлять вам данные кредитных карт!)

3. Пользователи, которые не поддерживаю TLS и используют уявзимые методы шифрования, получат HTTP версию вместо медленной и уязвимой SSL версии.

Это полностью соответствует рекомендациям Google по миграции сайтов на HTTPS.

D
На сайте с 28.06.2008
Offline
1101
Dram
#8

server {

listen 80;

listen 443 ssl http2;

server_name site.ru www.site.ru;

if ($scheme = http) {

return 301 https://$server_name$request_uri;

}

if ($host ~* www\.(.*)) {

set $host_without_www $1;

rewrite ^(.*)$ https://$host_without_www$1 permanent;

}

ssl_certificate /etc/ssl/certs/site.crt;

ssl_certificate_key /etc/ssl/private/site.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /usr/local/nginx/conf/sites-conf/dhparam.pem;

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

---------- Добавлено 12.01.2017 в 19:35 ----------

Ошибки Нгихс

[emerg] directive "if" has no opening "{" in /usr/local/nginx/conf/sites-conf/site.conf:25
[emerg] invalid condition "(!empty($_SERVER['HTTPS']))" in /usr/local/nginx/conf/sites-conf/site.conf:24
Александр И
На сайте с 20.11.2016
Offline
24
Александр И
#9

Dram, у вас должно быть две директивы server {}.

Одна отлавливает HTTP запросы (listen 80), а другая HTTPS (listen 443).

Вот во вторую и нужно вставлять все специфические для HTTPS параметры, в том числе заголовок HSTS.

То-есть, вам нужно создавать параллельно к server {listen 80} еще одну директиву с теми параметрами, что указаны в инструкции DigitalOcean.

Это можно сделать скопировав директиву server {listen 80} и изменив/добавив нужные параметры (listen меняем с 80 на 443).

Ошибка у вас была потому, что вы все параметры задавали в одной директиве.

А код if я вам дал для PHP, а не Nginx, потому, что думал, что вы задаете заголовки через него.

Можете отправить мне изначальный файл site.com.conf в личные сообщения и уточнить путь на crt/key/pem.

Я отправлю вам отредактированную версию.

D
На сайте с 28.06.2008
Offline
1101
Dram
#10

Можно так:

server {
listen 80;
}
server {
listen 443 ssl http2;
server_name......
блаблабла все что есть сейчас
}

Редирект в какую секцию прописывать?

123 4

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий