Поиск

Гугл рекомендует применять редирект и HSTS, а не просто оставлять обе версии. Присутствие обеих версий с точки зрения Гугла целесообразно только на время пока полностью проиндексируется HTTPS. Да, действительно. Но в чем тут смысл, по-вашему, если цель переход на HTTPS?. А что, этот новый Chrome не будет эту посадочную страницу отмечать как небезопасную? )). Ну, хотя бы потому, что HTTP версия в топе по многим запросам.

Уважаемые гуру, растолкуйте тогда простому смертному. Они оставляют и ту, и ту версию и не ставят никаких редиректов? Как работает поисковик в таком случае? Вроде, всегда объяснялось, что для того же Гугла домены с HTTP и HTTPS - это два разных домена, и Гугл может наложить санкции за дубли.

301 сделал в конце декабря одновременно с внедрением https. Доступным в http версии не оставлял. В доступному по https прописал host с https. В Вэбмастер добавил сайт с https и подтвердил права. В вэбмастере же на сайте http воспользовался 'переезд сайта ' - поставил галочку с 'https '. И сейчас (меньше месяца прошло) - уже всё нормально ! Так что ваши 'либо ' - 'либо ' видимо исключительно для голов в форме правильного шара:)

Почему именно за счет посещаемости? В декабре я переводил молодой сайт без посещалки. Тупо ткнул переезд на https, поставил редирект. Через 10 дней пришло сообщение о том, что изменилось главное зеркало. 4 тыцнул переезд. 14 декабря изменилось главное зеркало. Тот сайт у меня вообще без посещаемости. в месяц 20 уников. Какой месяц переезда?

Не сидят они спокойно, у них есть https версии сайтов. Наберите адрес этой формы apple с https и увидите их сертификат.

При чем тут CMS, проблема скорее всего в пустом _SERVER['HTTPS']. Я ссылку приводил, здесь можно глянуть возможную причину: _SERVER['HTTPS'] и Nginx+Apache. Это разве не к хостеру вопрос?;)

Я ставил бесплатный сертификат Let's Encrypt на новый сайт на DLE и переводил на него второй старый сайт. У меня в панеле хостера переезд осуществляется в один клик + добавил новую А-запись у регистратора доменов, далее хостер сам занимается бесплатным продлением сертификата, я ничего для этого не делал. В админке сайта прописал https и далее по стандарту - манипулиции в Я и Г вебмастере, прописать Host в роботсе, и ждать переклейки. Сейчас многие хостеры предлагают автоматическую установку бесплатных сертификатов, посмотри или спроси у своего, возможно они также предоставляют данную услугу. Поищи на официальном DLE-шном форуме инфу по переезду, там хватает описаний, в том числе с некоторыми нюансами для нашего движка, особенно если у тебя стоит авторизация через соц. сети.

Ни у кого в этом году не произошло обвала стоимости за клик? Я не могу понять, что случилось, с начала года цена за клик начала стремительно падать и докатилась с ~2.7 до 0,7-0,8$ за тысячу показов. При этом новые блоки не добавлял, в конце года перенёс сайт на https и в начале года заблокировал несколько аккаунтов Адвордс, которые рекламили смерть Якубовича и продажу квартир в Питере. Тематика туризм. И ещё, с 11.01 наблюдаю какое-то аномальное увеличение кликов и просмотра страниц в 2-3 раза, расчётный доход при этом снижается, а в Метрике и Аналитике никакого всплеска трафа или просмотров страниц нет вообще - всё ровно.

Здесь уже вопрос не поисковой оптимизации, а новых стандартов веб. Поисковому роботу явно не нужно шифровать трафик с вашим сайтом, он ведь не из кафе в сеть выходит и не будет отправлять вам данные своих кредитных карт. Это нужно только для пользователя. Лично я бы, советовал оставлять HTTP зеркала в выдаче поисковых систем, а пользователям отдавать HTTPS версию через HSTS preload list, если на это есть здравые причины. Для кого-то маркер 'Надежный ' в Google Chrome это весомая причина - прекрасно. Для кого-то отсутствие маркера 'Ненадежный ' в Google Chrome это весомая причина. Для меня весомая причина это HTTP/2, ServiceWorker, Web Push (ажиотаж утих) и почти все новые API браузеров работают исключительно по HTTPS протоколу. Я веб разработчик. И хотя бы на своих проектах, мне интересно пощупать все эти новые фишки. На Западе сейчас активно развивается тренд на PWA. Различные сервисы покупки авиабилетов и так далее начинают поддерживать PWA. Google регулярно выкладывает кейсы...

Это не мода, это - бизнес. Не зря гугл называют корпорацией зла. Хотя мысль все равно здравая, реализация на отвратительном уровне. Почему нельзя было дождаться, когда даже самая захудалая панель будет поддерживать https в один клик, мне непонятно. Надеюсь, что скоро это все же будет реализовано. Да, и пс придумают, как сделать переезд беспроблемным.

Редирект с http на https конечно в первую, там где слушается 80 порт:

Любые параметры для HTTPS в директиву с listen 443, как и add_header Strict-Transport-Security 'max-age=63072000; includeSubdomains; preload '; Для результата, который описан в первом сообщении, следующий код с редиректом не нужен ни в одной директиве У вас сайт будет работать через HTTPS при запросе HTTP, даже без редиректа (как только вы хотя бы раз посетите HTTPS версию или ваш сайт добавят в HSTS preload list). Для этого и нужен HSTS/preload list. В то время, Яндекс и другие клиенты без поддержки HTTP/2, будут получать быструю HTTP версию сайта. А скорость загрузки для поискового робота важнее шифрования, ведь он не будет вам данные кредитных карт отправлять.

Dram, у вас должно быть две директивы server {}. Одна отлавливает HTTP запросы (listen 80), а другая HTTPS (listen 443). Вот во вторую и нужно вставлять все специфические для HTTPS параметры, в том числе заголовок HSTS. То-есть, вам нужно создавать параллельно к server {listen 80} еще одну директиву с теми параметрами, что указаны в инструкции DigitalOcean. Это можно сделать скопировав директиву server {listen 80} и изменив/добавив нужные параметры (listen меняем с 80 на 443). Ошибка у вас была потому, что вы все параметры задавали в одной директиве. А код if я вам дал для PHP, а не Nginx, потому, что думал, что вы задаете заголовки через него. Можете отправить мне изначальный файл в личные сообщения и уточнить путь на crt/key/pem. Я отправлю вам отредактированную версию.

server { listen 80; listen 443 ssl http2; server_name; 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/; ssl_certificate_key /etc/ssl/private/; 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:!...

Да, если 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 является самым правильным выходом. В панелях ПС менять даже не обязательно ничего, они сами вкурят, что у вас 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 ' - тогда либо такую галку нужно отключить, либо этот код не добавлять в файл - оно с галкой тоже работает по этому же принципу.

Скобки в этом случае не обязательны Как я понял, определенные ключи в $_SERVER могут отсутствовать или отдавать разные значения в зависимости от сервера и сборки. Приведите дамп var_dump($_SERVER); или var_dump($_SERVER['HTTPS'], $_SERVER['SERVER_PORT'], $_SERVER['HTTP_X_FORWARDED_PROTO']); для HTTP версии и полный текст ошибки для кода выше.

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

Можно я вместо неё отвечу? А причем здесь, кто какие сайты имеет? Человек спросил. она ответила. Скажи спасибо, что ответила, и проверила. Как я понял, у них проблемы с доступом по https. Такое бывает. Это кстати не в каждом браузере такое.

Этот заголовок должна возвращать только HTTPS версия сайта. То-есть, нужно предварительно проверить протокол по которому запрашивается сайт. Если не ошибаюсь Один раз посетив HTTPS, вы будете получать HTTPS, даже запрашивая HTTP. А уже благодаря HSTS Preload List (который встроен в современные браузеры и регулярно обновляется из одного хранилища), мы получаем HTTPS по-умолчанию, даже если никогда не посещали HTTPS версию. Не забудьте добавить заявку на включение вашего домена в этот список.