Инструкция от команды студии веб-разработки VT Digital.
С июля 2018 года все HTTP-сайты в браузере Google Chrome будут помечаться как ненадёжные. Это произойдёт после выхода Chrome 68. Тема эта отнюдь не нова, однако до сих пор актуальна: владельцы сайтов по-прежнему совершают ошибки при переходе на HTTPS.
Готовимся к переезду
Ещё до смены протокола все внутренние абсолютные ссылки меняем на относительные. Например, для перехода на страницу на вашем же сайте лучше использовать <a href="/news/ "> вместо <a https://www.site.ru/news/">. Не забудьте исправить все ссылки на файлы, картинки, видео, виджеты и прочие внешние сервисы. Код «Яндекс.Метрики» и Google Analytics также должен подгружаться по относительному протоколу.
Чтобы настроить отслеживание реферального трафика, добавляем на HTTPS-страницах мета-тег <meta name="referrer" content="origin"> до закрывающего тега </head>.
Покупаем SSL-сертификат. Цена для ранжирования не имеет смысла, главное условие — валидность. О цене сертификатов и разнице между ними можно узнать на сайте предпочитаемого хостинг-провайдера. С недавних пор практически все они продают сертификаты.
Проверяем правильность настройки SSL-сертификата.
Переезжаем
Создаем версию сайта с HTTPS. Обе версии (HTTP и HTTPS) должны быть доступны и работать без ошибок. Файл robots.txt должен быть одинаков для обеих версий. Пока «Яндекс» не проведёт склейку зеркал, не настраивайте 301-редирект с HTTP.
В robots.txt указываем отдельно User-Agent: Yandex с Host: https:// и Sitemap: https://. Если приоритетная поисковая система для вас «Яндекс», то нужно закрыть сканирование всего сайта роботу Google, чтобы избежать дублей страниц в поиске Google.
Когда «Яндекс» полностью склеит страницы (в веб-мастере на неглавных зеркалах количество проиндексированных страниц будет равно нулю) и HTTPS будет выбрано главным зеркалом, открываем доступ Google в файле robots.txt. Если сервер на nginx, прописываем строки в .htaccess для доступности robots.txt по HTTP-протоколу:
<FilesMatch "robots.txt$">
RewriteEngine off
</FilesMatch>
Проверяем для HTTPS-версии протоколы в rel=”canonical”, rel=”alternate” и протокол ссылок в sitemap.xml. Для HTTPS-версии ссылки должны быть доступны по HTTPS. Для HTTP — в HTTP.
Тестируем
- Делаем 302-редирект с http:// на https:// на время теста.
- Добавляем обе версии сайта в «Яндекс.Вебмастер». Жмём «Настройка индексирования» — «Переезд сайта» и указываем предпочтительный протокол HTTPS. В «Структуре сайта» добавляем разделы сайта. В Google Search Console после склейки в «Яндексе» добавляем сайт с протоколом HTTPS и подтверждаем права. В разделе «Поисковый трафик» — «Таргетинг по странам и языкам» указываем, с какой страной связан домен, а в «Сканирование» — «Параметры URL» загружаем параметры из HTTP версии. Далее добавляем файл Disavow для HTTPS-версии по ссылке.
- Чтобы позиции по геозависимым запросам не просели, указываем в разделе «Региональность» регион для вкладки «Вебмастер».
- Меняем ссылки для региональных представительств, которые указаны в «Яндекс.Справочнике». Для этого пишем через форму в техподдержку «Яндекс.Справочника» о переезде на HTTPS.
- Ждём склейки в «Яндексе». Переклейка начинается примерно через две-три недели. Обратите внимание, что при переезде обнуляется тИЦ. Ничего страшного в этом нет, как сообщает «Яндекс» он вернётся после следующего обновления, которое происходит примерно раз в месяц.
- Когда «Яндекс.Вебмастер» покажет, что зеркала связаны, и основным уже выбрана HTTPS-версия, можно настраивать 301-постраничный редирект, кроме файла robots.txt и страницы 404 ошибки.
- Проверяем корректность присвоенного региона в «Яндексе» после переклейки. Если возникают проблемы с присвоением регионов, пишем в техподдержку.
- Проверяем смешанное содержимое — у всех страниц сайта протокол HTTPS. Это можно сделать через ScreamingFrog или подобную программу.
Далее индексирующий робот проверит корректность переезда (обычно это занимает от двух часов до трёх дней), и если не допущено никаких ошибок, то скоро в результатах поиска появится нужная HTTPS-версия сайта.
Во время склейки зеркал трафик может просесть. Это происходит из-за того, что поисковики воспринимают сайт с HTTPS как новый. Когда HTTPS-версия будет признана главным зеркалом, о чём вебмастер получит уведомление, все показатели HTTP-версии начнут учитываться для HTTPS.
Цитата: "Если сервер на nginx, прописываем строки в .htaccess для доступности robots.txt по HTTP-протоколу:
<FilesMatch "robots.txt$">
RewriteEngine off
</FilesMatch>"
Кто-нибудь еще кроме меня понимает степень шизофрении автора в этом предложении. nginx -> htaccess -> достпность txt файла по http протоколу.
А если не на nginx, то все, htaccess не работает? Автор, ты в курсе что такое htaccess и nginx и что они друг с другом не связаны и даже чаще мешают друг другу
Да, мы уже выпили яду, посыпали голову пеплом и обгорели от стыда. Но это не помогает, так как редактирование статьи закрыто. Можете еще поискать ошибки, мы еще порасстраиваемся)
Просто прежде чем писать посты и называться digital там чем-то, нужно хоть в теме сечь. Тут как само решение, так и предшествующее ему предложение - бред сивой кобылы, специалист, который это предложил - я таких у себя увольняю.
Простите великодушно, мы постараемся вас так больше не разочаровывать
У меня другая проблема, у меня есть много .html со статичными ссылками img src=http://
И я так думаю, что писать еще один php, который будет автозаменой шерстить сайт, мне очень не хочется :(
Как-то они по-разному у меня работают, добавляешь, добавляешь, добавляешь проверки - но на большую базу страниц исключений очень много, и соотв. сложно обработать все возможные варианты.
А что мешает сделать замену "http://"; на "https://"; без использования php, просто в редакторе?Воспользоваться поиском по проекту и найденное заменить))
А лучше переделать абсолютные на относительные ссылки =)
Cергей, мешают пара сотен тысяч страниц :)
Хотя нет. Пожалуй, уже ближе к 250к страниц.
Нехило))
Ну так ... надо бросить все и заниматься улучшайзингом с полгода, чтобы стало хорошо. Так что - средне, просто работаем для своей b2b аудитории, и все.
Если это все в базе, то делается это одним запросом к таблице.
Если такой объем в файлах - то только скриптом, который будет каждый файл открывать и заменять ссылки.
Пишется такой скрипт максимум час с учетом отладки. И работать его можно поставить на ночь, чтобы не трепал нервы
Да не пишется он максимум час :) Я до этого написал преобразование внешних ссылок www.extsite.ru => http://www.mysite.ru/redirect.php?www.extsite.ru (ессно с кодировкой) - и разбор всех возможных исключений занял около 2-х недель, с перерывами. А потом еще понадобилось вносить исправления. И еще. Не с утра до вечера, а по факту отлова новых ошибок.
Я пока смысла не вижу на https именно переходить - т.к. переписываюсь с Eset Nod 32, уверенно показывающим время от времени Ай-яй-яй, левый сертификат на (site.ru), дальше не пущу.
В прошлом году он увлекся и от www.noname.ru перешел к сайтам средней популярности, а под занавес подозрения у него стали вызывать www.google.com / www.mail.ru ... переписка с support, танцы с бубном и т.д.
Через месяц после того - обратился человек с Kaspersky Anti-Virus - богато ругавшимся на несоответствие сертификатов разных сайтов. Переписка с support, танцы с бубном, чистая деинсталляция, установка заново - решили проблему.
Я это к чему - наличие https сертификата (особенно этого на 3 месяца, по принципу трусов Неделька), не гарантирует что сайт будет у всех нормально открываться. А отсутствие - ПОКА - гарантирует.
Ни разу не встречал проблем с нормальными сертификатами.
Если у вас вылезают предупреждения даже на гугл и Яндекс, то есть вероятность наличия вирусов, подменяющих сайты,или атаки mitm