Htaccess переадресация сайта: Файл .htaccess — настройка перенаправлений и управление конфигурацией веб-сервера

Содержание

Переадресация через .htaccess (301 редирект) |

Переадресация через .htaccess очень удобный инструмент, который многие недооценивают и даже игнорируют. 301 редирект способен значительно упростить процесс индексации роботами и сократить время появления ваших страниц в поисковой выдаче. Незаменим  он как в первоначальной настройке вашего сайта, так и при его обслуживании в будущем. Хоть для некоторых из ныне существующих движков CMS и существуют неплохие плагины для более понятной настройки переадресаций на сайте, но все же они доступны не для всех, поэтому стоит понимать и знать правила 301 редиректа, чтобы не было никаких осложнений при прописывании их самому.

  • Располагайте переадресации страниц в файле от частных к более глобальным (сверху вниз). Например: простая переадресация двух страниц стоит выше, чем глобальное правило редиректов с www на без www.
  • Избегайте последовательных редиректов (двух, трех и т.д.). (.*)$ http://%{HTTP_HOST}/$1 [R=301,L]
     
    Вас могут заинтересовать:

    .htaccess

    15.10.2014

    Почему то на просторах рунета информация о локальной настройки веб-сервера Apache посредством конфигурационного файла .htaccess приводится как то не полно и однобоко. В основном приводятся примеры (часто не рабочие) или сухой перевод англоязычной документации.

    А как же быть, если нужно настроить несколько редиректов, и совсем нет времени познавать всю мощь .htaccess? Единственный выход это брать готовые примеры, и наугад адаптировать под свои нужды. В этой статье я напишу краткое руководство по .htaccess, которое закроет большинство вопросов новичков. А также приведу ссылки на подробные инструкции. Эта статья будет дописываться по мере необходимости, начну с самого основного.

    Редиректы

    Редиректы осуществляются с помощью модуля mod_rewrite. Задаются правила преобразований в виде следующей конструкции:

    
    <IfModule mod_rewrite. c>
      Options +FollowSymLinks
      RewriteEngine On
    
      [СЮДА ПИШЕМ ПРАВИЛА]  
    
    </IfModule>
    

    Правила преобразования записываются в таком виде:

    
    RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
    RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
    RewriteRule [ШАБЛОН] [СТРОКА ПОДСТАНОВКИ] [ФЛАГИ]
    

    Строки RewriteCond - задают условия для срабатывания следующего за ними правила RewriteRule. Условий может быть несколько, они накладываются по правилу AND. Но можно изменить правило на OR с помощью флага OR.

    В качестве [СТРОКИ ДЛЯ СРАВНЕНИЯ] могут использоваться различные переменные. Ссылка на полный список Я приведу только те, которые нужны чаще всего:

    %{REQUEST_URI} Строка запроса (без доменного имени, и GET параметров), пример "/server/htaccess/"
    %{HTTP_HOST} Доменное имя, например "max22. ru"
    %{QUERY_STRING}Строка GET параметров

    [УСЛОВИЕ] также как и [ШАБЛОН] представляют собой perl совместимое регулярное выражение, с некоторыми дополнениями, позволяющими например проверить файл ли это, или существующий url.

    [ФЛАГИ] Флаги пишутся в квадратных скодках через запятую: [NC,OR]. Флаги для условий:

    NC Регистронезависимая проверка
    OR Условие сопостовляется с остальными про правилу ИЛИ

    Подвыражения в регулярных выражениях (заключенные в скобки), доступны для вставки в [СТРОКУ ПОДСТАНОВКИ], обращаться к подвыражениям нужно так: %N - для подвыражений в условиях (RewriteCond) и $N - для подвыражений в правилах (RewriteRule), где N - порядковый номер подвыражения.

    RewriteRule - правило подстановки. Если запрос подходит под вышестоящие проверки и [ШАБЛОН], то применяется правило подстановки. Здесь регулировать поведение также можно с помощью флагов. Флаги есть разные, приведу наиболее часто используемые:

    NC Регистронезависимая проверка
    R=301 Будет редирект с кодом 301, можно указать другой код
    L Это последнее правило, больше не применять правил преобразований

    Надеюсь после моего краткого ввода в теорию, вам будет проще понимать что же написано в вашем .htaccess. Привожу ссылку на очень хороший перевод про модуль mod_rewrite, там же можно найти другие хорошие переводы.

    Внимание! Браузеры кешируют редиректы!!!

    Причем обычные сочетания типа Ctrl+F5 или Ctrl+R не помагают. Я во время тестирования каждый раз открываю страницу в НОВОМ окне в режиме инкогнито. Причем старые страницы в режими инкогнито надо закрывать.

    Примеры

    Универсальный редирект с www на без www

    Тут самое интересное, почему то везде приводятся примеры, жестко привязанные к домену сайта. news/happy.* /news.html [L]

    Иногда требуется, чтобы был редирект без смены адреса, т.е. реврайт без редиректа. Для этого просто не указываем флаг редирект (

    R), и получаем желаемый результат, теперь по адресу news/happy получим news.html, а в адресной строке останется news/happy

    Редирект от GET параметров

    Например, нужно что бы со страницы /?action=page&id=15 был редирект на /page/15/:

    
    RewriteCond %{QUERY_STRING} action=page [NC]
    RewriteCond %{QUERY_STRING} id=(\d+) [NC]
    RewriteRule .* /page/%1/? [R=301,L]
    

    Поясню, первым условиям проверяем что есть get параметр action=page, вторым условием проверяем что id равно числу. Эти условия нельзя объединять, т.к. параметры могут идти и наоборот, т.е. index.php?action=page&id=15 и index.php?id=15&action=page должны быть равноценны. Но и наконец правило, там все обычно, кроме знака вопрос (?) на конце. (.*)$ https://meirbruk.net/$1 [L,R=301] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress

    • Ответ изменён 9 месяцев, 1 неделя назад пользователем elimelech.
    • Ответ изменён 9 месяцев, 1 неделя назад пользователем elimelech.

    такие же правила без всяких мелких доработок?

    В общем случае — да. От движка это не зависит, но зато зависит от конфигурации сервера.

    а если у меня нету файла .htaccess

    Такой .htaccess нужен для работы ЧПУ. Если оно не включено (ссылки вида ?p=1), то и .htaccess не нужен.

    Вот так, правильно

    Между # BEGIN WordPress и # END WordPress лучше ничего не менять, эти изменения будут перезаписаны. Свои правила рекомендуется добавлять перед этим фрагментом.

    Такой . index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress

    Свои правила пишем либо до него, либо после.

    Что значит перезаписывает?

    Это значит, что все от # BEGIN WordPress и до # END WordPress удаляется и вписывается то, что движок считает правильным.

    Вообще-то, WP сейчас это всё прямо в htaccess и пишет:

    # Строки междуBEGIN WordPressиEND WordPress были созданы автоматически.
    # Они могут быть изменены только фильтрами WordPress.
    # Все изменения между этими отметками будут перезаписаны.

    • Ответ изменён 9 месяцев, 1 неделя назад пользователем Юрий.

    Но почему-то получается двойной редирект если проверить адрес типа http://www.мой.сайт
    , т.е сначало перенаправляет на сайт https://www.мой.сайт, а потом с https://www. (.*)$ index.php [F,L] RewriteCond %{HTTPS} off RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] </IfModule>

    Как сделать редирект 301 Метод .htaccess

    Когда мы советуем применения редиректа(переадресация)  301 для оптимизации и поддержки определенного URL в поисковых системах, то обязательно встречается вопрос: «Как вы делаете редирект 301?»

    До тех пор, пока у вас есть доступ к директории своего сайта на сервере, такие действия не составят особого труда. Будем считать, что ваш сайт работает на веб-сервере Apache (как и большинство сайтов), потому давайте немного поговорим о технической части вопроса внедрения переадресации 301 в Apache.

    Сначала немного теории

    В терминах сайтов, редирект – это способ автоматической переадресации конечного пользователя с одного адреса URL на другой. В то время как с технической стороны существует несколько способов осуществления переадресации, для задач, связанных с поисковой оптимизацией (SEO), мы рекомендуем использование постоянным редиректом 301 HTTP.

    В отличие от используемой по умолчанию временной переадресации 302 HTTP, 301 показывает, что старый, привязанный URL больше не используется (тогда, как 302 указывает, что старый временно не используется, но в будущем он должен снова появиться).

    Разница между 301 и 302 особенно важна при сканировании сайта поисковыми системами. Когда сканер поисковика обнаруживает ссылку на ваш сайт, адрес которого постоянно настроен на переадресацию, то веб-сервер взаимодействует со статусом кода 301, а затем переадресовывает пользователя на новый URL. Поисковые системы не только принимают перенаправление на новый URL, но и переносят значение показателей страницы со старого URL на новую страницу редиректа (это вторая особенность такого процесса, которая очень важна для SEO оптимизации, которую нельзя выполнить, используя 302).

    Во всех примерах указан домен данного сайта, не забудьте заменить его на адрес вашего сайта.

    Сравнение редирект 301 и канонический rel=”canonical”

    Например:

    <link rel="canonical" href="http://www. web-profy.com/page.html" />

    Смысл тега rel=canonical в том, чтобы сообщить поисковой машине единый целый адрес контента страницы. Это очень полезно, когда сайт использует динамические переменные атрибутов для URL-ов. Динамические URL могут способствовать индексации нескольких версий URL для каждой отдельной страницы, что выражается в дублировании контента (а это поисковики просто ненавидят!)

    Хотя использование тега с атрибутом rel=canonical и полезно для страницы сайта, но это не является надежной заменой переадресации 301. Здесь есть несколько причин:

    Тег rel=canonical до сих пор рассматривается поисковыми машинами как полунамеки, а не как конкретные директивы к исполнению. Тогда как редирект 301 воспринимается как конкретная инструкция. И напоследок, в отличие от редиректа 301, которая может быть сконфигурирована в одном файле для всего сайта, код тега rel=canonical нужно будет вставить на каждой страничке.

    Все это говорит нам, что использование тэгов rel=canonical может оказаться полезным при переадресации страниц блога (конечно, если у вас есть доступ к его коду и, чтобы вставить в страницы необходимые модульные теги). В конце концов, использование 301 может означать потерю изначальных страничек и связанных с ними комментариями, социальных связей, у которых есть свои собственные значения в SEO.

    Мы рекомендуем рассмотреть использование тега rel=canonical, чтобы минимизировать дублирование индексированного контента. Независимо от стандартных причин переназначения функций и значений поискового индекса старого URL на новый, мы рекомендуем придерживаться использования проверенного способа – переадресации 301.

    Как сделать редирект 301 в .htaccess?

    На веб-сервере Apache редирект 301 можно выполнить через коды скрипта в одном из двух файлов с текстовой конфигурацией: или .htaccess (для директорий, представляющих отдельные сайты на сервере), или httpd.conf (в корневом каталоге инсталлятора Apache). Обычно используется способ с изменением конфигурации .htaccess, потому рассмотрим его более подробно.

    Есть целый ряд условий, когда рекомендуется использование переадресации 301. Для каждой ситуации нужен свой специальный код в кодировке. Потому рассмотрим отдельно каждый возможный сценарий.

    Первое, что нужно сделать – это открыть текстовый файл, который называется .htaccess. Его можно найти в директории вашего сайта на веб-сервере Apache. Убедитесь, что открыли его с помощью простейшего текстового редактора, такого как Notepad на компьютерах, работающих на Windows.

    После открытия файла, прежде чем добавить специальный код сценария, вам необходимо выполнить две вещи:

    • Включить модуль Apache mod_rewrite.
    • Включить ReWriteEngine в модуле mod_rewrite.

    Чтобы сделать это, добавьте эти две строки кода:

    Options +FollowSymLinks
    RewriteEngine on

    Заметим, что такие строки нужно добавить лишь один раз в файле .htaccess. Когда они будут добавлены, можно приступать к добавлению в сценарии кода переадресации 301.

    Следующий сценарий переадресации используется при перемещении файлов данных, директории и доменного имени в выбранный код./]+/)*)(default|main|index)\.(html|php|htm)$ http://www.web-profy.com/$1 [L,R=301]

    Первый блок из двух строк перенаправляет URL-лы, у которых опущены префиксы «www.», на адрес домашней страницы, например, “www.xyz.com”. Это означает, что URL домашней страницы http://web-profy.com не появится, а будет перенаправлен на страницу http://www.web-profy.com/.

    Второй блок кода перенаправляет URL-лы указанных страниц на те адреса, которые указаны по умолчанию. Такой код гарантирует, что любой URL домашней страницы, имеющий несколько вариантов своего написания и прямых ссылок, как default.htm или index.html, будут перенаправлены на каноническую страницу URL, такую как, http://web-profy.com

    Документирование и тестирование работы

    Мы настоятельно рекомендуем добавлять строки документирования при работе с кодом в файле . htaccess. Для этого просто сделайте в начале строки комментарий, используя значок # для его выделения, как в следующем примере:

    # Redirect this entire domain, abc.(.*)$ http://www.web-profy.com

    Хорошее документирование и комментирование процессов всегда поможет вам (и тем, кто в дальнейшем будет заниматься сайтом) понять, какой код за что отвечает. Такая информация будет полезна при поиске проблем, когда что-то не работает, выяснить какую часть кода нужно исправить для слаженной работы сайта.

    Безусловно, необходимо протестировать работу внесенных изменений. Если вы используете FTP для загрузки исправленного файла . htaccess в корневом каталоге вашего сайта, самое время выполнить его проверку. Введите в браузере адрес URL страницы, которую вы перенаправили. Она должна моментально перенаправить на прописанный URL.

    Поиск и устранение неисправностей

    Если переадресация не работает так, как вы того ожидали, то наступает время поиска и устранения неисправностей.

    Прежде всего, если переадресация закодирована в вашем файле .htaccess и оно записано корректно, но не работает, то проверьте состояние установки расширения mod_rewrite в Apache. Этот модуль обычно устанавливается по умолчанию, но если его там нет, то кодировка .htaccess, приведенная выше, работать не будет. Также убедитесь, что вы добавили две строки кода, которые разрешают работу модуля mod_rewrite и ReWriteEngine.

    Кроме того, заметим, что использование [NC] в строках RewriteCond показывает о несоответствии входных данных с установленными характеристиками. Если вы упустите этот момент, адреса URL-ов с заглавными и строчными буквами могут не так работать, как ожидалось. Заметим, что использование L в коде [L,R=301] говорит о том, что файл движка воспринимается как последняя строчка кода всего процесса подтверждения ввода данных. Если у вас противоречивая конфигурация кода в .htaccess, используйте код L в строке, обозначенной как приоритетной.

    И напоследок отметим, что частое использование переадресации 301 не хорошо сказывается на здоровье всего сайта. Хоть она и очень полезна, но вы должны обновлять входящие ссылки сайта на правильные URL-лы. Игнорируя ваши старые входящие ссылки и используя для перехода через них многократно переадресацию 301 (301, затем 301, затем еще раз 301), вы увеличиваете время для загрузки сайта, что плохо сказывается на продвижении сайта. И если переадресаций будет очень много, то сканеры могут просто не дойти до целевого сайта. Если такое случается, то это вредит вашему сайту продвигаться в поисковой системе. Также, если вы обновляете ссылки вашего сайта, убедитесь, что обновляются и файлы sitemap.xml новыми обновленными URL-ми.

    Контролируйте работу вашего сайта при помощи переадресации 301 – это стандартная эффективная практика при белой SEO оптимизации. Убедитесь, что вы помогаете сканерам поисковых машин добраться до страниц вашего сайта и, при этом, заработанный PageRank активно вкладывается в продвижение вашего сайта.

    Алексей Повловский

    Перенаправление / перезапись URL с использованием файла .htaccess

    По умолчанию к вашему веб-сайту можно получить доступ как с www.example.com, так и с example.com. Поскольку Google наказывает за это из-за причин дублирования контента, вам следует ограничить доступ либо к www. Www.www.example.com $ [NC] указывает, что следующее правило срабатывает только тогда, когда http-хост (то есть домен запрашиваемого URL-адреса) не (- указан с "!") www.example.com.

    Знак $ означает, что хост заканчивается на www.example.com - и в результате все страницы с www.example.com запускают следующее правило перезаписи. В сочетании с инверсивным "!" В результате каждый хост, который не является www.example.com, будет перенаправлен на этот домен.

    [NC] указывает, что хост HTTP не чувствителен к регистру.(. *) $ содержит запрошенный URL без домена.

    Следующая часть http://www.example.com/$1 описывает цель правила перезаписи. Это наше «последнее» используемое доменное имя, где $ 1 содержит содержимое (. *).

    Следующая часть также важна, поскольку она выполняет 301 редирект за нас автоматически: [L, R = 301]. L означает, что это последнее правило в этом прогоне. После этой перезаписи веб-сервер вернет результат. R = 301 означает, что веб-сервер возвращает 301, постоянно перемещенный в запрашивающий браузер или поисковую систему.$ http://example.com/index.php [L, R = 301]

    Объяснение этого перенаправления .htaccess 301:

    Что делает этот код выше? Давайте посмотрим на Пример 1 - Перенаправление с example.com на www.example.com. Первая строка запускает модуль перезаписи. Следующая строка:

      RewriteCond% {HTTP_HOST}! Www.example.com $
     
     
    указывает, что следующее правило срабатывает только в том случае, если хост HTTP (то есть домен запрашиваемого URL) не (- указан с "!") www.example.com.

    $ означает, что хост заканчивается на www.example.com - и в результате все страницы с example.com запускают следующее правило перезаписи. В сочетании с инверсивным "!" В результате каждый хост, который не является www.example.com, будет перенаправлен на этот домен.

    [NC] указывает, что хост HTTP не чувствителен к регистру. Избегает "." - потому что это специальный символ (обычно точка (.) означает, что один символ не указан).

    Последняя строка описывает действие, которое необходимо выполнить:

      RewriteRule ^ (.(. *) $ содержит запрошенный URL без домена.
    
     

    Следующая часть http://www.example.com/$1 [L, R = 301] описывает цель правила перезаписи - это "окончательное" используемое доменное имя, где $ 1 содержит содержимое (. * ).

    Следующая часть также важна, поскольку она выполняет 301 редирект за нас автоматически: [L, R = 301]. L означает, что это последнее правило в этом прогоне. После этой перезаписи веб-сервер wi

    htaccess | WordPress.org

    .htaccess - это распределенный файл конфигурации, и именно так Apache обрабатывает изменения конфигурации для каждого каталога.- [L] RewriteRule. index.php [L] # КОНЕЦ WordPress

    Наверх ↑

    Наверх ↑

    Опции № Опции

    Любые параметры, которым предшествует + , добавляются к действующим в настоящее время параметрам, а любые параметры, которым предшествует , удаляются из действующих в настоящее время параметров.

    Возможные значения для директивы Options представляют собой любую комбинацию:

    Нет

    Все опции выключены.

    Все

    Все опции, кроме MultiView.Это значение по умолчанию.

    ExecCGI

    Разрешено выполнение сценариев CGI с использованием mod_cgi.

    FollowSymLinks

    Сервер будет переходить по символическим ссылкам в этом каталоге.

    Включает

    Разрешены включения на стороне сервера, предоставленные mod_include.

    Включает NOEXEC

    Включения на стороне сервера разрешены, но #exec cmd и #exec cgi отключены.

    Индексы

    URL соответствует каталогу, а не DirectoryIndex - форматированному списку каталога.

    Мультипросмотр

    Согласованное содержимое «MultiViews» разрешено с использованием mod_negotiation.

    SymLinksIfOwnerMatch

    Переходите только по символическим ссылкам, если цель принадлежит тому же идентификатору пользователя, что и ссылка.

    Это отключит все параметры, а затем включит только FollowSymLinks, что необходимо для mod_rewrite.

     Опции Нет
    Параметры FollowSymLinks
     

    Наверх ↑

    DirectoryIndex # DirectoryIndex

    DirectoryIndex устанавливает файл, который Apache будет обслуживать при запросе каталога.

    Можно указать несколько URL-адресов, и в этом случае сервер вернет первый найденный.

     DirectoryIndex index.php index.html /index.php
     

    Наверх ↑

    DefaultLanguage # DefaultLanguage

    DefaultLanguage приведет к тому, что все файлы, которые еще не имеют определенного языкового тега, связанного с ним, будут использовать его.

     DefaultLanguage ru
     

    Наверх ↑

    Кодировка по умолчанию # Кодировка по умолчанию

    Установите кодировку символов по умолчанию, отправляемую в заголовке HTTP. См .: Установка информации о кодировке в .htaccess

     AddDefaultCharset UTF-8
     

    Установить кодировку для определенных файлов

     AddType 'text / html; charset = UTF-8 '.html
     

    Набор для конкретных файлов

     AddCharset UTF-8 .html
    
     

    Наверх ↑

    ServerSignature # ServerSignature

    Директива ServerSignature позволяет конфигурировать завершающую строку нижнего колонтитула в документах, созданных сервером.При желании добавьте строку, содержащую версию сервера и имя виртуального хоста, на страницы, созданные сервером (документы внутренних ошибок, списки каталогов FTP, вывод mod_status и mod_info и т. Д., Но не документы, созданные CGI или пользовательские документы ошибок).

    по

    добавляет строку с номером версии сервера и ServerName обслуживающего виртуального хоста

    Off

    подавляет строку нижнего колонтитула

    Электронная почта

    создает ссылку mailto: на ServerAdmin указанного документа

    .
     SetEnv SERVER_ADMIN admin @ site.com
    Сервер Подпись Электронная почта
     

    Наверх ↑

    Принудительная загрузка файлов # Принудительная загрузка файлов

    Приведенное ниже приведет к тому, что любые запросы файлов с указанными расширениями не будут отображаться в браузере, а вместо этого вызовет диалоговое окно «Сохранить как», чтобы клиент мог загрузить.

     Приложение AddType / поток октетов .avi .mpg .mov .pdf .xls .mp4
     

    Наверх ↑

    Сжатие HTTP # Сжатие HTTP

    Директива AddOutputFilter сопоставляет расширение расширения имени файла с фильтрами, которые будут обрабатывать ответы от сервера перед их отправкой клиенту.Mozilla / 4 \ .0 [678] no-gzip BrowserMatch \ bMSIE! No-gzip! Gzip-only-text / html

    Принудительное сжатие для определенных файлов

     SetOutputFilter DEFLATE
    
     

    Наверх ↑

    Директива Header позволяет отправлять заголовки HTTP для каждого запроса или только для определенных файлов. Вы можете просматривать HTTP-заголовки сайтов с помощью Firebug, Chrome Dev Tools, Wireshark или онлайн-инструмента.

     Заголовочный набор X-Pingback "http://www.askapache.com/xmlrpc.php"
    Набор заголовков Content-Language "en-US"
     

    Наверх ↑

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

     Заголовок не установлен Pragma
    Заголовок всегда отключен WP-Super-Cache
    Заголовок всегда отключен X-Pingback
     

    Наверх ↑

    Защита паролем логина # Защита паролем логина

    Это очень полезно для защиты файла wp-login.php . Вы можете использовать этот генератор htpasswd.

    Базовая аутентификация

     AuthType Basic
    AuthName "Защищено паролем"
    AuthUserFile /full/path/to/.htpasswd
    Требовать действительного пользователя
    Удовлетворить все
    
     

    Дайджест-аутентификация

     Дайджест AuthType
    AuthName "Защищено паролем"
    AuthDigestDomain / wp-login.php https://www.askapache.com/wp-login.php
    AuthUserFile /full/path/to/.htpasswd
    Требовать действительного пользователя
    Удовлетворить все
    
     

    Наверх ↑

    Требуется особый IP # Требуется особый IP

    Это способ разрешить доступ только определенным IP-адресам.

     ErrorDocument 401 по умолчанию
    ErrorDocument 403 по умолчанию
    
    
    Заказать отказать, разрешить
    Запретить всем
    Разрешить от 198.101.159.98 localhost
    
     

    Наверх ↑

    Защита конфиденциальных файлов # Защита конфиденциальных файлов

    Это запрещает любой веб-доступ к вашему файлу wp-config, error_logs, php.ini и htaccess / htpasswds.

     Заказать отклонить, разрешить
    Запретить всем
    
     

    Наверх ↑

    Требовать SSL # Требовать SSL

    Это приведет к принудительному использованию SSL и потребует точного имени хоста, иначе будет выполнено перенаправление на версию SSL. Полезно в файле /wp-admin/.htaccess .

     SSLOptions + StrictRequire
    SSLRequireSSL
    SSLRequire% {HTTP_HOST} eq "www.wordpress.com"
    ErrorDocument 403 https://www.wordpress.com
     

    Наверх ↑

    Наверх ↑

    .htaccess перенаправление на https и www

    Если ваш сайт обслуживает защищенные страницы по протоколу HTTPS (т.е. через SSL / TLS ), вам может потребоваться метод перенаправления всех HTTP-запросов на HTTPS. Затем, чтобы продолжить свои усилия по канонизации, вы также можете перенаправить все запросы www на не-www (или наоборот). Оба эти метода необходимы для обслуживания канонических версий ваших веб-страниц, так почему бы не объединить их в единый простой фрагмент.www \ .example \ .com [NC] RewriteRule (. *) Https://example.com/$1 [L, R = 301]

    Как и раньше, поместите этот код в корневой каталог .htaccess вашего сайта. Вот что он делает:

    1. Проверяет наличие mod_rewrite
    2. Проверяет, отключен ли HTTPS, или если запрос включает www
    3. Если какое-либо из условий соответствует, запрос соответствует и перенаправляется на https / не www адрес

    При размещении в корне.htaccess, этот метод охватывает всех запросов, обеспечивая полную канонизацию https / без www для вашего сайта. Не забудьте заменить два экземпляра example.com своим собственным доменным именем.

    Примечание: , если ваш сайт страдает от дублирования страниц из-за index.php , добавленного к запрошенным URL-адресам, ознакомьтесь с этим сообщением на WP-Mix.com, в котором объясняется, как удалить www и index.php из URL-адреса.

    Перенаправление на https и www

    Следующее.(. *) $ [NC] RewriteRule (. *) Https: //www.%1/$1 [R = 301, L]

    Этот код выполняет следующие действия:

    1. Проверяет наличие mod_rewrite
    2. Проверяет, отключен ли HTTPS или запрос не включает www
    3. Если любое из условий соответствует, запрос соответствует и перенаправляется на https / www адрес

    При размещении в корневом каталоге .htaccess этот метод охватывает всех запросов, обеспечивая полную канонизацию https / www для вашего сайта.Этот код не требует редактирования; это полностью plug-n-play.

    Банкноты

    В зависимости от того, как настроен ваш сервер, вам может потребоваться жестко закодировать буквальное имя вашего домена в RewriteRule . Например, используя указанный выше код, попробуйте запросить следующий URL-адрес в своем браузере:

      http://www.example.com/  

    Обратите внимание, что здесь мы запрашиваем незащищенный протокол http вместе с поддоменом www .Конечно, вы хотите заменить example.com фактическим именем вашего домена. После выполнения запроса, если сервер перенаправляется на следующий URL-адрес, все работает правильно:

      https://www.example.com/  

    В противном случае, если вы получите что-то подобное с повторяющимися поддоменами www :

      https://www.			

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *