301 редирект (переадресация) через .htaccess
Содержание:
- Включение HSTS
- Один (а не два последовательных!) 301 редирект на без www и без слеша на конце адреса страницы
- Редирект с протокола http на https.
- Меняем во внутренних ссылках http на https
- Переадресация с http на https
- Один (а не два последовательных!) 301 редирект на без www и с слешем на конце адреса страницы
- Переадресация 301 с http на https
- Настройки веб-серверов в Панели управления
- Что-то пошло не так и на сайт нельзя зайти
- Этап 1. Удаление параметра «Требовать SSL» для веб-сайта по умолчанию с помощью диспетчера служб IISStep 1: Use IIS Manager to remove the Require SSL setting from the default website
- Проксирование
- Последствия перехода на SSL для SEO
- Один (а не два последовательных!) 301 редирект на c www и без слеша на конце адреса страницы
- Переадресация с http на https
- Как сделать редирект с https на http?
Включение HSTS
Строгая транспортная безопасность HTTP (HSTS) — это механизм политики веб-безопасности, с помощью которого веб-сервер указывает, что он поддерживает подключения только по протоколу HTTPS. Это позволяет предотвратить атаки типа «злоумышленник в середине» на SSL.
Эта политика передается сервером агенту пользователя в поле заголовка HTTP-ответа «Strict-Transport-Security». Политика задает период, в течение которого у агент пользователя будет доступ к серверу только безопасным способом.
Пропишите в файле .htaccess следующий код:
<IfModule mod_headers.c> # this domain should only be contacted in HTTPS for the next 12 months Header set Strict-Transport-Security "max-age=31536000" env=HTTPS </IfModule>
Не забывайте перед любыми операциями над сайтом создавать его резервную копию.
Опубликовано в рубрике WordPress, Безопасность
Один (а не два последовательных!) 301 редирект на без www и без слеша на конце адреса страницы
RewriteCond %{REQUEST_URI} ^\/$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ http://%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)\/$ http://%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ http://%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)\/$ http://%1/$1
Редирект с протокола http на https.
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Если возникает циклический редирект, то воспользуйтесь этим вариантом:
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
Для Битрикс-сайтов на хостинге reg.ru
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI}
Для сертификатов https c Cloudflare:
RewriteCond %{HTTP:CF-Visitor} ‘»scheme»:»http»‘
# Without Cloudflare:
# RewriteCond %{HTTPS} off
RewriteRule ^ https://www.example.com%{REQUEST_URI}
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
RewriteEngine On
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
RewriteEngine on
RewriteCond %{HTTP:HTTPS} !on
RewriteCond %{REQUEST_URI} !robots.txt
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Меняем во внутренних ссылках http на https
Во внутренних ссылках лучше всего использовать относительные адреса, а не абсолютные:
- абсолютный адрес: https://elims.org.ua/about/
- относительный адрес: /about/
Относительные адреса не только облегчают перенос сайта с одного домена на другой и переход с http на https, но они не так нагружают хостинг, когда служебные процессы обращаются к этим ссылкам. Только не всегда получается придерживаться этого правила.
Очень часто при публикации какого-либо контента во внутренних ссылках используются абсолютные адреса — так быстрей: скопировал ссылку из адресной строки и вставил в текст, без редактирования и вырезания лишней части. В таком случае во всех внутренних ссылках нужно заменить http на https.
Делаем SQL запрос в базе данных, на примере моего сайта:
UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://elims.org.ua', 'https://elims.org.ua');
Или же можно сразу сделать все ссылки относительными:
UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://elims.org.ua/', '/');
Как делаются такие запросы я уже писал в записи «WordPress: как заменить текст в блоге (базе данных)».
Эта замена происходит только по контенту в записях и страницах. В меню и шаблоне ссылки не затрагиваются чтобы случайно ничего не сломать, изменив какие-либо настройки.
Поэтому было бы еще хорошо обнаружить оставшиеся внутренние ссылки с http. В этом может помочь такой инструмент как Xenu (я о нем писал в записи «SEO: Xenu — бесплатный аудит сайта и мертвых ссылок»):
Переадресация с http на https
При переезде сайта с http на https (установка SSL-сертификата) потребуется код, который не требует дополнительных модификаций:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Второй метод осуществляет перенос с http://domain.ru на https://domain.ru:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{HTTP_HOST} ^domain\.ru$
RewriteRule ^(.*)$ https://domain.ru/$1
Третий способ выполняет аналогичную функцию, но отключает перенаправление для robots.txt:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{REQUEST_URI} !robots.txt
RewriteRule ^(.*)$ https://domain.ru/$1
В 4-й версии конечным пунктом для пользователя станет https://www.domain.ru:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{HTTP_HOST} ^domain\.ru$
RewriteRule ^(.*)$ https://www.domain.ru/$1
Позволяет сделать форвардинг с http://www.poddomen.domain.ru на https://poddomen.domain.ru:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.poddomen\.domain\.ru$
RewriteRule ^(.*)$ https://poddomen.domain.ru/$1
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Последняя версия, дающая возможность сделать связь между http://poddomen.domain.ru на https://www.poddomen.domain.ru:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^poddomen\.domain\.ru$
RewriteRule ^(.*)$ https://www.poddomain.domain.ru/$1
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Один (а не два последовательных!) 301 редирект на без www и с слешем на конце адреса страницы
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ http://%1/$1/
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ http://%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)$ http://%1/$1/
Переадресация 301 с http на https
При помощи 301-го редиректа мы получаем два результата:
- Сообщаем поисковым системам что «http://elims.org.ua» и «https://elims.org.ua» — это одна и та же страница. А точнее говорим что мы переместили страницу с «http://elims.org.ua» на «https://elims.org.ua» и просим перенести весь ссылочный вес и прочие «заслуги».
- Всех посетителей http-версии страницы автоматически переадресовываем на https-версию страницы.
301-ю переадресацию с http на https можно реализовать тремя способами, через:
- файл .htaccess
- php-код
- плагин
301 редирект с http на https через .htaccess
Вариантов кодов для редиректа с http на https через .htaccess существует большое количество, я для примера приведу два из них:
<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.yoursite.com/$1 </IfModule>
Или еще один код:
<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_HOST} ^yoursite.com RewriteCond %{HTTP_HOST} ^www.yoursite.com RewriteRule ^(.*)$ https://www.yoursite.com/$1 </IfModule>
Не всегда такая переадресация работает, у меня например по началу выбивало ошибку «ERR_TOO_MANY_REDIRECTS» — «На этой странице обнаружена циклическая переадресация».
Но после в справочной информации своего хостинга ukraine нашел код, который заработал и позволил отказаться от плагина.
Рабочая версия код для моего wordpress в режиме мультиблога:
# BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - #for SSL RewriteCond %{HTTP:SSL} !=1 RewriteRule ^(.*) https://elims.org.ua/$1
301 редирект с http на https через php-код
Все просто — открываем файл в шаблоне functions.php и прописываем следующий код:
function force_https () { if ( !is_ssl() ) { wp_redirect('https://' . $_SERVER . $_SERVER, 301 ); exit(); } } add_action ( 'template_redirect', 'force_https', 1 );
или еще один вариант, предложенный читателем — именно такой вариант для читателя был рабочим:
<?php add_action ( 'template_redirect', 'force_https', 1 ); function force_https () { if ( !is_ssl() ) { wp_redirect('https://' . $_SERVER . $_SERVER, 301 ); exit(); } } ?>
301 редирект с http на https через wordpress плагин
Более опытные веб-мастеры предпочитают обходимся своим кодом и не использовать плагины в тех случаях, когда можно без них обойтись. Это связано с тем, что в плагинах часто реализован лишний функционал, который не нужен и может создавать лишнюю нагрузку. При этом сами плагины могут некорректно работать. Но в данном случае именно этот метод переадресации я предпочел, так, как нашел плагин состоящий всего лишь из нескольких строк php-кода, который опубликован выше. Все-таки активировать и деактивировать плагин более удобней, чем редактировать php-файлы.
Упомяну три плагина:
- WordPress HTTPS (SSL): можно активировать принудительный вход в админку через https, настраивать https только для определенных страничек\записей, либо для определенных адресов по регулярным выражениям, удалять со страницы весь не https-контент, изменять исходящие ссылки с http на https версии сайтов и пр. Этот плагин заработал не на всех шаблонах.
- Easy HTTPS Redirection: можно настроить переадресацию для всех страниц или только для определенных. По сути плагин добавляет в файл .htaccess код для редиректа. Но, как я писал выше, этот метод у меня вызывает ошибки «ERR_TOO_MANY_REDIRECTS» — «На этой странице обнаружена циклическая переадресация». При этом после деактивации плагина пришлось вручную удалять его код из файла .htaccess.
- WordPress Force HTTPS — простой плагин, ничего лишнего. Переадресация реализована через php-код. Именно на нем я остановился.
Рекомендую через некоторое время убедится что поисковики не включают в индекс дубли страниц (http и https версий). Для это возьмите несколько адресов своих страниц и вбейте в гугле запрос подобный моему:
site:elims.org.ua inurl:elims.org.ua/blog/xosting-ukraine-obzor-i-otzyv/
На моем примере я увижу какие версии страницы «elims.org.ua/blog/xosting-ukraine-obzor-i-otzyv/» есть в поисковом индексе. Должна быть лишь одна версия — с https.
Настройки веб-серверов в Панели управления
В настройках базового веб-сервера вы можете изменять все директивы PHP, значение графы Changeable для которых соответствует PHP_INI_PERDIR или PHP_INI_ALL. Эти настройки будут иметь силу на всех сайтах, которые работают на этом веб-сервере.
Управлять абсолютно всеми параметрами PHP вы можете на расширенном веб-сервере, редактируя php.ini через его настройки.
Чтобы установить индивидуальные параметры PHP для отдельного сайта, используйте файл .htaccess. Через него можно управлять всеми параметрами, доступными для изменения на базовом веб-сервере – примеры самых востребованных перечислены ниже.
По умолчанию отображение ошибок PHP на хостинге отключено. Для того чтобы видеть текст ошибок PHP на странице сайта, добавьте в файл .htaccess директиву:
Для того чтобы сохранять, изучать и исправлять ошибки включите их сбор и хранение с помощью следующих строк:
Директория в пути расположения файла должна существовать, а если ее нет — обязательно создайте папку вручную. Файл журнала будет создан при появлении первой ошибки.
Для изменения ограничения на оперативную память для выполнения процесса используйте следующую директиву в .htaccess:
Вместо 512M укажите желаемый размер ограничения
Обратите внимание, что символ «M» (латинская M) указывается слитно со значением. Уточнить максимальное значение оперативной памяти, доступное по тарифу, можно в
Чтобы увеличить время выполнения скриптов (в секундах), добавьте следующую директиву в .htaccess:
Вместо 300 укажите желаемый размер ограничения
Обратите внимание, что выполнение скрипта более чем в 10 минут (600 секунд) завершится ошибкой с кодом 504
Если вам нужно загружать файлы бóльшего размера, либо же ограничить их объем (чтобы контролировать дисковую квоту), то управлять объемом загружаемого файла можно через .htaccess:
Вместо 200M укажите желаемый размер ограничения
Обратите внимание, что символ «M» (заглавная латинская M) указывается слитно со значением
Максимальный размер передаваемых переменных определяется с помощью следующей директивы:
Вместо 15000 укажите необходимый размер ограничения, который требует CMS сайта.
Если страница в браузере загружается некорректно и вместо привычных символов на сайте отображаются иероглифы, добавьте в файл .htaccess строки:
Вместо «windows-1251» подставьте подходящую кодировку, например, UTF-8. Проверить, в какой именно кодировке написан сайт, можно через инструменты используемого браузера. Если сайт не обрел корректный вид, обратитесь за помощью в службу технической поддержки.
Чтобы заставить интерпретатор PHP обрабатывать файлы с произвольным расширением, (например, .phtml), добавьте в файл .htaccess следующую строку:
Изменение времени хранения сессий может потребоваться, если вы хотите, чтобы данные об авторизации пользователей на вашем сайте сохранялись дольше.
По умолчанию время хранения сессий — 1440 секунд (24 минуты). Для изменения этого значения добавьте в .htaccess следующие директивы:
Обратите внимание: при большом количестве посетителей и длительном времени сохранения сессий в папке, указанной в session.save_path, образуется большое количество файлов. Это может вызывать замедление сайта в момент очистки старых сессий и увеличивать количество потребляемых ресурсов
Альтернативные механизмы хранения и очистки сессий:
- Указывать вложенность директорий хранения сессий с помощью аргумента N в session.save_path и очищать старые сессии собственными скриптами ( в документации PHP).
- Реализовать собственный механизм хранения сессий (например, в MySQL) и установить его с помощью функции session_set_save_handler.
Что-то пошло не так и на сайт нельзя зайти
В данном случае следует вернуть все обратно и поискать причину сбоя в установленных плагинах или в одном из файлов темы — functions.php. Отправляемся в wp-config.php и вставляем значения:
define('WP_HOME','http://clearfy.pro'); define('WP_SITEURL','http://clearfy.pro');
clearfy.pro в данном случае пример. Вместо этого URL должен быть адрес вашего сайта с протоколом http.
Займемся поиском причины сбоя. Деактивируйте плагины один за одним, удалите данные, веденные ранее в wp-config.php. Если сайт не починился, то поменяйте тему на одну из стандартных. Проверьте снова. Если ситуация не прояснилась, то проверьте файл .htaccess. Возможно источник проблем в нем.
Этап 1. Удаление параметра «Требовать SSL» для веб-сайта по умолчанию с помощью диспетчера служб IISStep 1: Use IIS Manager to remove the Require SSL setting from the default website
-
Откройте диспетчер служб IIS на сервере Exchange. Открыть диспетчер служб IIS в Windows Server 2012 или более поздних версиях легко. Просто нажмите клавишу Windows+Q, введите в строке поиска inetmgr и в списке результатов выберите Диспетчер служб IIS.Open IIS Manager on the Exchange server. An easy way to do this in Windows Server 2012 or later is to press Windows key + Q, type inetmgr, and select Internet Information Services (IIS) Manager in the results.
-
Разверните узел сервера, а затем раздел Сайты.Expand the server, and expand Sites.
-
Выберите веб-сайт по умолчанию.Select Default Web Site. и убедитесь, что в нижней части страницы выбрано представление «функции «.and verify Features View is selected at the bottom of the page.
-
В разделе IIS дважды щелкните элемент Параметры SSL.In the IIS section, double-click SSL Settings.
-
На странице Параметры SSL снимите флажок Требовать SSL, а затем на панели Действия нажмите кнопку Применить.On the SSL Settings page, clear the Require SSL check box, and in the Actions pane, click Apply.
Примечание. Чтобы выполнить эту процедуру в командной строке, откройте командную строку с повышенными привилегиями на сервере Exchange Server (для этого выберите Запуск от имени администратора) и выполните следующую команду:Note: To perform this procedure on the command line, open an elevated command prompt on the Exchange server (a Command Prompt window you open by selecting Run as administrator) and run the following command:
Проксирование
Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.
Хоть это и не совсем редирект, рассмотрим примеры его настройки, так как очень часто нужно не перенаправление, а, как раз, обратное проксирование.
1. На другой сервер
Пример внутреннего перенаправления http-запроса на другой веб-сервер:
…
location / {
proxy_pass $scheme://192.168.0.15:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.
Использование NGINX в качестве http-прокси:
server {
…
server_name site1.ru www.site1.ru;
location / {
proxy_pass http://192.168.1.21/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
server {
…
server_name site2.ru www.site2.ru;
location / {
proxy_pass http://192.168.1.22/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.
HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):
server {
…
location / {
proxy_pass http://10.10.10.10/page/;
proxy_set_header Authorization «Basic dGVzdDp0ZXN0»;
…
}
}
* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.
2. Часть url на другой сервер
Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:
server {
…
location ~ ^/page1/(.*)$ {
proxy_pass $scheme://10.10.10.10/$1;
}
}
* и так, в данном примере при обращении по адресу site.ru/page1/<что-то еще>, nginx сделает внутренний запрос на сервер 10.10.10.10 по адресу 10.10.10.10/<что-то еще> и вернет готовый ответ.
3. На другой сайт
Мы можем сделать так, что при переходе по одному адресу у нас будет открываться совершенно другой сайт:
server {
…
location / {
proxy_pass https://www.dmosk.ru;
proxy_set_header Host www.dmosk.ru;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
* в данном случае мы при обращении к нашему серверу будем попадать на сайт https://www.dmosk.ru
Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси
4. Редиректы при проксировании
Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:
server {
listen 80;
server_name dmosk.local www.dmosk.local;
location / {
proxy_pass https://www.dmosk.ru;
proxy_set_header Host www.dmosk.ru;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
}
}
* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.
Последствия перехода на SSL для SEO
Обязательно измените URL сайта в файле robots.txt и укажите, что следует теперь считать новым основным зеркалом в панели вебмастера поисковиков. Ведь, как правило, позиции сайта и трафик после перехода с одного протокола на другой понижаются. Но это временные последствия. Таким образом, чем раньше произойдет переход, тем меньше потерь для SEO. Но нельзя не отметить, что Google способствует продвижению сайтов с сертификатом HTTPS.
Правила перехода без потери позиций
- Проверяем, корректно ли работают страницы после получения SSL сертификата.
- В панель разработчика «Яндекс.Вебмастер» вносим сайт с новым URL
- Настраиваем 301 редирект с http на https wordpress
- По аналоги с Яндексом, вносим сайт с протоколом https в Google Search Console.
Один (а не два последовательных!) 301 редирект на c www и без слеша на конце адреса страницы
RewriteCond %{REQUEST_URI} ^\/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)$ http://www.%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)\/$ http://www.%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)$ http://www.%1/$1
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)\/$ http://www.%1/$1
Переадресация с http на https
При переезде сайта с http на https (установка SSL-сертификата) потребуется код, который не требует дополнительных модификаций:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Второй метод осуществляет перенос с http://domain.ru на https://domain.ru:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{HTTP_HOST} ^domain\.ru$
RewriteRule ^(.*)$ https://domain.ru/$1
Третий способ выполняет аналогичную функцию, но отключает перенаправление для robots.txt:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{REQUEST_URI} !robots.txt
RewriteRule ^(.*)$ https://domain.ru/$1
В 4-й версии конечным пунктом для пользователя станет https://www.domain.ru:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{HTTP_HOST} ^domain\.ru$
RewriteRule ^(.*)$ https://www.domain.ru/$1
Позволяет сделать форвардинг с http://www.poddomen.domain.ru на https://poddomen.domain.ru:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.poddomen\.domain\.ru$
RewriteRule ^(.*)$ https://poddomen.domain.ru/$1
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Последняя версия, дающая возможность сделать связь между http://poddomen.domain.ru на https://www.poddomen.domain.ru:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^poddomen\.domain\.ru$
RewriteRule ^(.*)$ https://www.poddomain.domain.ru/$1
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
Как сделать редирект с https на http?
Решение 1
Делаем редирект на http с помощью .htaccess
Замечание Перечисленные ниже варианты предназначены для серверов Linux.
Пояснения для всех последующих вариантов Редактируем или создаём, если его нет, файл .htaccess в корневой папке вашего сайта, и добавляем сразу после один из нижеперечисленных вариантов, при этом не забыв изменить site.ru на URL вашего сайта.
Вариант 1
Вариант 2
Вариант 3
Вариант 4
Вариант 5
Вариант 6
Вариант 7
Вариант 8
Вариант 9
Вариант 10
Попробуем ещё вариант — вместо %{HTTPS} указать %{ENV:HTTPS}
Вариант 11
Вариант 12
Замечание Если не работает, то можно попробовать поместить, указанные выше строки, в выражение IfModule.
ВАЖНОПри открытии сайта, Сначала браузер проводит проверку наличия SSL-сертификата и уже затем срабатывает редирект. Другими словами, если на сайте нет SSL-сертификата, то посетители сначала увидят предупреждение браузера о незащищённом контенте, и уже затем сработает редирект на http …
ЗамечаниеОбычно, при открытии сайта, Сначала браузер, как правило, открывает версию https сайта. Но это не точно. На самом деле, это зависит от настроек сервера и сайта. Если вебсервер отдаёт заголовок «Strict-Transport-Security» ( смотрим в настройках add_header Strict-Transport-Security ), тогда браузер будет открывать сайт по HTTPS протоколу. Дополнительно, этот заголовок появляется, если в настройках web-домена установлено: «Повышенная безопасность SSL»
Если Решение 1 не работает?
В частности этим грешат серверы и VDS с панелью ISP Manager 5 ( на других панелях управления, например cPanel, с Lunix на этом же сайте переадресация работает! )
Решение 2
Открываем и внимательно смотрим ваш сайт (для примера site.ru )именно по протоколу httpS если он не ваш и отличаются и по внешнему виду и по контенту, то
нужно выяснить его ( URL ). Обычно это один из https сайтов, расположенный на вашем IP адресе. Найти список сайтов на вашем IP можно стандартным сервисом «Сайты на одном IP»
Итак, — хорошо — вы узнали, какой это сайт ( назовём его, для удобства https-sait.ru )
И теперь все дальнейшие правки, как ни странно, будем вести не на проблемном сайте, а на найденном (https-sait.ru)!
Идея: поставить передресацию с https на http на найденном https сайте https-sait.ru
13 Решение: создаем в корне этого сайта в файле htaccess правила типа условное выражение такого вида:
Пробуем, проверяем.
Подводим итог.
Другими словами, для того, чтобы сделать редирект с https на http вашего сайта sait.ru, вам потребуется найти и открыть https-sait.ru, отредактировать там .htaccess файл, прописав правила аналогичные пункту 13 для каждого вашего сайта: sait 1, 2, 3.ru
Вот такие странности панели ISP Manager ….
Решение 3
Замечание Предлагаемое решение работает на серверах с NginX.
Если у вас сервер с nginx, тогда делаем переадресацию в его настройках
Вариант 3.1
Указав, вместо ip — ваш реальный IP, вместо site.ru — URL вашего сайта и вместо # пути к сертификату — реальный путь. Сохраняем и перегружаем сервер
Модифицированный вариант:
Вариант 3.2
находим и удаляем там же строку
Если что то не работает, перезагружаем nginx и смотрим ошибки, которые находятся в
Замечание Если нужно, чтобы сайт открывался как по http, так и по протоколу https, то вышеуказанные варианты приведут к зацикливанию ….
Нужно же, чтобы сайт открывался как по http, так и по https. Если прописывать редирект в nginx на http
Вариант 3.2
Некоторые, устав бороться с NginX, сносят его и ставят классический редирект