Як перейти на https зберігши ранжування в яндекс - форум про інтернет-маркетингу
Як перейти на HTTPS зберігши ранжування в Яндекс
Виходячи з цього, багато веб-майстри зіткнулися з проблемою, що начебто вже час переводити сайти на 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), ви можете відкрити ваш сайт, як по HTTP, так і по HTTPS протоколу.
Це означає, що Яндекс має індексувати HTTP-версію сайту, як головне дзеркало, незважаючи на появу HTTPS-версії.
Якщо ви хочете, щоб Google теж віддавав перевагу HTTP версії сайту, тоді обов'язково уточніть наявність canonical, який вказувати на HTTP версію вашого сайту.
Я рекомендую віддавати Google canonical на HTTP версію сайту бо великих плюсів в ранжируванні HTTPS вам не принесе, якщо взагалі принесе зараз.
Тема все таки спрямована на догоду Google Chrome, в першу чергу і на мінімальні коливання позицій в пошукових системах.
В інструкції від DigitalOcean, на яку я посилався вище, вже включений HSTS, вам тільки потрібно додати preload після includeSubDomains;
Це означає, що всі сучасні браузери, які підтримують 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, вона ранжируватиметься, нічого страшного не трапиться.
Re: Як перейти на HTTPS зберігши ранжування в Яндекс
Навіщо так ускладнювати собі життя, дзеркалом протоколи.
Редирект на єдину версію https є найправильнішим виходом.
У панелях ПС змінювати навіть не обов'язково нічого, вони самі вкурил, що у вас https тепер сайт.
І все, спрацює хоч на Апачі, хоч на нгінксе, який блокує заголовки апача.
Єдиний баг може виникнути, якщо у вас ISP панель і ви в ній поставили галку "Перекладати все запити http на https" - тоді або таку галку потрібно відключити, або цей код не додавати в файл - воно з галкою теж працює за цим же принципом.
Подякували 2 користувачів:
Re: Як перейти на HTTPS зберігши ранжування в Яндекс
Навіщо так ускладнювати собі життя, дзеркалом протоколи.
Редирект на єдину версію 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.
Re: Як перейти на HTTPS зберігши ранжування в Яндекс
server listen 80;
listen 443 ssl http2;
server_name site.ru www.site.ru;
[Emerg] directive "if" has no opening "[emerg] invalid condition" (! Empty ($ _ SERVER [ 'HTTPS'])) "in /usr/local/nginx/conf/sites-conf/site.conf:24
Re: Як перейти на HTTPS зберігши ранжування в Яндекс
Dram. у вас повинно бути дві директиви server <>.
Одна відловлює HTTP запити (listen 80), а інша HTTPS (listen 443).
Ось в другу і потрібно вставляти все специфічні для HTTPS параметри, в тому числі заголовок HSTS.
Помилка у вас була тому, що ви всі параметри задавали в одній директиві.
А код if я вам дав для PHP, а не Nginx, тому, що думав, що ви задаєте заголовки через нього.
Можете відправити мені початковий файл site.com.conf в особисті повідомлення і уточнити шлях на crt / key / pem.
Я відправлю вам відредаговану версію.