Редиректы 301 через .htaccess

Перенаправляем посетителя с помощью директивы RedirectMatch и регулярных выражений

Еще одна полезная директива, рекомендуемая к использованию Хайпер — RedirectMatch. Цитата из комментариев: «Директива позволяет в качестве запрашиваемого адреса использовать регулярное выражение (пересылка не «с документа», а «со всех документов, типа …»). Редирект внешний — браузеру сообщается о необходимости загрузить другую страницу.

Синтаксис:

RedirectMatch  regexp URL

Значения статусов (код возврата веб-сервера) стандартные: permanent (301 — постоянный редирект), temp (302 — временный редирект, приходите ещё), seeother (303 — летим туда, там много вкусного), gone (410 — удалён навсегда).

Пример. То же перенаправление со старого домена на новый без подключения RewriteEngine:»

RedirectMatch 301 ^(.*)$ www.domainname.com/$1

От себя добавлю, что вы можете использовать не только статусы, но и другие условия:

RedirectMatch (.*)\.gif$ http://www.myserver.com$1.png
RedirectMatch (.*\.jpg)$ http://www.myanother.com$1

Отсекаем спам

Страдаете от спама на вашем блоге WordPress? Конечно, плагин Akismet может оказать существенную помощь, но и файл не останется в стороне от борьбы с заразой. Данный код предотвращает непосредственный доступ спам ботов к файлу  , который формирует комментарии на блоге.

# Заменяем yourdomainname на имя вашего домена
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourdomainname.* 
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ 
</IfModule>

Директивы htaccess. Разделяем доступы

Запрет доступа к сайту

Бывает такое, что необходимо запретить доступ посетителям с определенного IP, спамерам или еще кому нехорошему.

Добавлять IP в список можно просто добавляя последнюю строку и меняя там адрес на нужный. Противоположная ситуация, когда всем нужно запретить, кроме некоторых IP, тогда используем такой код:

Добавлять адреса аналогично предыдущему примеру.

Запрещаем просмотр нежелательным User-Agent

Каждый браузер или приложение, которое запрашивает страницу, так или иначе имеет идентификатор — User-Agent. Можно запретить просмотр нежелательным товарищам. Это могут быть как программы, сканирующие сайты, так и старые браузеры, от поддержки которых вы целиком отказались. Ситуации бывают разные.

Полный список известных User-Agent вы можете найти на сайте http://www.user-agents.org/

Запрещаем доступ к определенному файлу

В примере стоит запрет на доступ к файлам wp-config и htaccess, тем самым повышается уровень общей защиты. Очень нужная директива, рекомендую добавить в свои файлы

Аналогично можно защитить css и js файлы, которые используются плагинами:

Скачивание определенных типов файлов

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

Для чего нужен файл .htaccess?

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

Файл дополнительной конфигурации .htaccess широко используют для замены стандартных сообщений об ошибках (в частности для обработки ошибки 404), ограничения доступа к файлам и каталогам сайта, настройки переадресации, указания стартовой страницы, определения кодировки файлов, обработки php кода в html-документах и прочего. Далее рассмотрим наиболее значимые из этих возможностей, но сначала разберемся, как создать правильный файл дополнительной конфигурации, где он должен находиться и рассмотрим возможные ошибки при его создании.

Troubleshooting

When you put configuration directives in a
file, and you don’t get the desired effect, there are a number of
things that may be going wrong.

Most commonly, the problem is that is not
set such that your configuration directives are being honored. Make
sure that you don’t have a in effect
for the file scope in question. A good test for this is to put garbage
in your file and reload the page. If a server error is
not generated, then you almost certainly have in effect.

If, on the other hand, you are getting server errors when trying to
access documents, check your httpd error log. It will likely tell you
that the directive used in your file is not
permitted.

This will indicate either that you’ve used a directive that is
never permitted in files, or that you simply
don’t have set to
a level sufficient for the directive you’ve used. Consult the
documentation for that particular directive to determine which is
the case.

Alternately, it may tell you that you had a syntax error in your
usage of the directive itself.

Как сделать переадресацию 301

Существует много способов сделать переадресацию 301, но самый распространенный метод — отредактировать файл .htaccess вашего сайта.

Вы найдете его в корневой папке вашего сайта:

Не видите файл? Это означает одно из двух:

1. У вас нет файла .htaccess. Создайте его с помощью Блокнота (Notepad в Windows) или TextEdit (Mac). Просто создайте новый документ и сохраните его с расширением .htaccess. Обязательно удалите стандартное расширение файла .txt.
2. Ваш сайт работает не на веб-сервере Apache. Это скорее технический аспект, но существуют разные типы веб-серверов. Apache, Windows/IIS и Nginx являются наиболее распространенными. Только серверы Apache используют файлы .htaccess. Чтобы проверить, работает ли ваш сайт на Apache, используйте этот инструмент. Убедитесь, что в разделе «История хостинга» (Hosting History), в колонке «Веб-сервер» (Web server) указано «Apache».

Вот некоторые фрагменты кода для добавления распространенных типов переадресаций 301 с помощью файла .htaccess:

ВАЖНО. Эти инструкции предназначены исключительно для веб-серверов Apache. Здесь можно почитать, что делать, если ваш сайт работает на Nginx, а здесь — если ваш сайт работает на Windows/IIS

Перенаправление старой страницы на новую

 Redirect 301 /old-page.html /new-page.html 

Используете WordPress? Можно избавиться от необходимости самостоятельно редактировать файл .htaccess, если воспользоваться бесплатным плагином Redirection.

Добавить 301 редирект станет намного проще:

Перенаправление старого домена на новый

 RewriteEngine on
RewriteCond %{HTTP_HOST} ^oldsite.com 
RewriteCond %{HTTP_HOST} ^www.oldsite.com 
RewriteRule ^(.*)$ https://newsite.com/$1  

Примечание. Существует несколько способов это сделать. Я ни в коем случае не эксперт в том, что касается серверов Apache и файлов .htaccess. Этот код у меня всегда срабатывал. Но вам следует обязательно протестировать его перед внедрением на своем сайте.

ВАЖНО! Если уже есть в вашем файле .htaccess, не повторяйте его. Просто скопируйте остальную часть кода

Это можно сделать и в Cpanel, если так удобнее.

Перенаправление всего домена с версии без www на версию с www (и наоборот)

Вот вариант для перенаправления с версии без www на версию с www:

 RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com 
RewriteRule ^(.*)$ http://www.example.com/$1  

Вот вариант для перенаправления с версии с www на версию без www:

 RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.example.com 
RewriteRule ^(.*)$ http://example.com/$1  

ВАЖНО! Расположение и порядок кода в вашем файле .htaccess также имеет значение. Вы можете столкнуться с нежелательными последствиями, если несколько команд размещены в «неправильном» порядке (например, в случае цепочек переадресаций и т. д.)

Если вы планируете использовать много 301 редиректов в своем файле .htaccess, то вам стоит внимательно все проверить.

Перенаправление всего домена с HTTP на HTTPS

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} 

ВАЖНО! Чтобы все правильно работало, на сайте должен быть установлен сертификат SSL. В противном случае вы получите предупреждающее сообщение «Соединение не защищено»

Перенаправление всего домена с версии без www на версию с www и с HTTP на HTTPS

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www. 
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} 

Особенности файлов .htaccess

Хотя страница .htaccess невероятно полезна и может  заметно улучшить сайт, при ее использовании нужно помнить о двух моментах.

Во-первых, это скорость. Страница .htaccess может немного снизить скорость сервера; в большинстве случаев это почти незаметно. Это происходит из-за расположения страницы: как уже говорилось, файл .htaccess влияет на страницы и подкаталоги в своем каталоге. Каждый раз, когда страница загружается, сервер проверяет ее каталог, а также каждый каталог уровнем выше, пока не достигает наивысшего каталога или файла .htaccess. Этот процесс будет происходить до тех пор, пока параметр AllowOverride позволяет использовать файлы .htaccess, вне зависимости от того, существуют ли вообще такие файлы в системе.

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

В общем и целом, Apache не рекомендует использовать .htaccess, если пользователь имеет доступ к конфигурационным файлам Apache.

Индексные страницы

Когда пользователь заходит на хост, например, http://gentoo.org, принято, что открывается индексный файл index.* , а при его отсутствии отображается либо содержимое каталога, либо отдается ошибка 403 FORBIDDEN (если отключена опция «просмотр директорий»).

За листинг файлов отвечает директива Indexes (показывать посетителю список файлов, если в выбранном каталоге нет файла index.html или его аналога).

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

А чтобы выдавал листинг, нужно:

Если же понадобится разрешить просматривать список файлов, но чтобы при этом чаcть файлов определенного формата не отображалась, то запишем:

Выдает листинг каталога, т.е. его содержание со всем содержанием, за исключением файлов-скриптов PHP и Perl.

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

Если же вы хотите что бы при обращении к каталогу открывался не index.html, а, например, файл htaccess.php или /cgi-bin/index.pl:

19 полезных возможностей файла .htaccess +6

• 07.08.19 08:11

•
PromoPult
•
#462029
•
Хабрахабр

•

•

4000

Поисковая оптимизация, Блог компании PromoPult

Спорим, о некоторых вы не подозревали. Мы собрали варианты применения .htaccess для улучшения работы сайта. Он часто используется оптимизаторами для корректной настройки 301 редиректов. Но этим возможности файла не ограничиваются. Тут и безопасность, и оптимизация, и параметры отображения — с помощью .htaccess вебмастер может сделать много полезного, чтобы сайт работал корректно.

Файл .htaccess (сокращение от «hypertext access») переопределяет настройки самого популярного типа веб-серверов Apache и его аналогов. Ниже — способы применения .htaccess для разных целей с примерами кода.

When (not) to use .htaccess files

In general, you should only use files when
you don’t have access to the main server configuration file. There is,
for example, a common misconception that user authentication should
always be done in files, and, in more recent years,
another misconception that directives
must go in files. This is simply not the
case. You can put user authentication configurations in the main server
configuration, and this is, in fact, the preferred way to do
things. Likewise, directives work better,
in many respects, in the main server configuration.

files should be used in a case where the
content providers need to make configuration changes to the server on a
per-directory basis, but do not have root access on the server system.
In the event that the server administrator is not willing to make
frequent configuration changes, it might be desirable to permit
individual users to make these changes in files
for themselves. This is particularly true, for example, in cases where
ISPs are hosting multiple user sites on a single machine, and want
their users to be able to alter their configuration.

However, in general, use of files should be
avoided when possible. Any configuration that you would consider
putting in a file, can just as effectively be
made in a section in your main server
configuration file.

There are two main reasons to avoid the use of
files.

The first of these is performance. When
is set to allow the use of files, httpd will
look in every directory for files. Thus,
permitting files causes a performance hit,
whether or not you actually even use them! Also, the
file is loaded every time a document is
requested.

Further note that httpd must look for files
in all higher-level directories, in order to have a full complement of
directives that it must apply. (See section on .) Thus, if a file is requested out of a
directory , httpd must look for the
following files:

And so, for each file access out of that directory, there are 4
additional file-system accesses, even if none of those files are
present. (Note that this would only be the case if
files were enabled for , which
is not usually the case.)

In the case of directives, in
context these regular expressions must be
re-compiled with every request to the directory, whereas in main
server configuration context they are compiled once and cached.
Additionally, the rules themselves are more complicated, as one must
work around the restrictions that come with per-directory context
and . Consult the for more
detail on this subject.

The second consideration is one of security. You are permitting
users to modify server configuration, which may result in changes over
which you have no control. Carefully consider whether you want to give
your users this privilege. Note also that giving users less
privileges than they need will lead to additional technical support
requests. Make sure you clearly tell your users what level of
privileges you have given them. Specifying exactly what you have set
to, and pointing them
to the relevant documentation, will save yourself a lot of confusion
later.

Note that it is completely equivalent to put a
file in a directory containing a
directive, and to put that same directive in a Directory section
in your main server
configuration:

file in :

Section from your
file

<Directory "/www/htdocs/example">
    AddType text/example ".exm"
</Directory>

However, putting this configuration in your server configuration
file will result in less of a performance hit, as the configuration is
loaded once when httpd starts, rather than every time a file is
requested.

The use of files can be disabled completely
by setting the
directive to :

Директивы простого перенаправления (редирект)

Это наиболее часто используемые директивы файла .htaccess. Если мы хотим перенаправить пользователя со старой страницы на новый URL, нам понадобится 301-редирект. Для этого в код файла .htaccess необходимо добавить:

Redirect 301 /stariy_URL.html http://www.mysite.ru/noviy_URL.html

В общем виде данная директива выглядит так:

Redirect URL_LOCAL URL_REDIRECT

– это необязательное поле, может принимать значения:

• 301 – страница перемещена навсегда;
• 302 – страница перемещена временно;
• 303 – смотрите другой документ;
• 410 – страница убрана (удалена).

URL_LOCAL – локальная часть URL, с которой выполняется редирект;

URL_REDIRECT – адрес, на который переносится документ.

Предотвращаем хотлинк ресурсов сайта

Хотлинк (использование изображений вашего сайта другими сайтами в сети) является весьма популярной практикой, которая прожигает впустую трафик вашего сервера. Следующий код будет перенаправлять все хотлинк запросы к изображениям вашего сайта на определенную картинку, адрес которой задается в строке 6.

RewriteEngine On
#Замените ?mysite\.com/ на адрес вашего блога
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ 
RewriteCond %{HTTP_REFERER} !^$
#Замените /images/nohotlink.jpg на ваше изображение с запрещением хотлинка
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg 

Защищаем паролем папки и файлы

Вы можете включить проверку пароля для доступа в любую папку или файл на вашем сервере, используя этот код:

#защита паролем файла
<files secure.php="">
AuthType Basic
AuthName "Prompt"
AuthUserFile /pub/home/.htpasswd
Require valid-user
</files>

#защита паролем папки
resides
AuthType basic
AuthName "This directory is protected"
AuthUserFile /pub/home/.htpasswd
AuthGroupFile /dev/null
Require valid-user

Для того, чтобы организовать доступ к файлу по паролю, необходимо создать файл .htpasswd и внести в него пару логин-пароль в формате user:password.

Однако в этом случае пароли будут хранится в открытом виде, что не слишком хорошо с точки зрения безопасности. Поэтому оптимальнее пароль зашифровать. Для этого воспользуйтесь сервисами генерации записей в файлы .htpasswd. Например, вот таким.

В нашем примере файл с паролями доступа лежит в корневой директории сайта и называется .htpasswd. Директория указывается от корня сервера и если путь будет некорректным — Apache, не получив доступа к файлу, откажет в доступе к папке любому пользователю — в том чилсе и тому, который ввел правильную пару логин:пароль.

Правильное изменение страниц ошибок через .htaccess

Когда пользователь хочет увидеть сайт (отправляет запрос на сервер хостера), то сервер возвращает ему ответ с кодом. Коды 1-399 свидетельствуют о нормальной работе сервера, а коды 400-599 сообщают об ошибке сервера (коды всех ошибок смотрите в спец. статье). Например, если сервер с вашим сайтом перегружен, или у него происходит перезагрузка, то пользователь увидит непонятный ему текст (например, 500 Internal Server Error), подумает, что сайт больше не будет работать и больше никогда на него не вернется. Чтобы вместо стандартной страницы ошибки (непонятно для пользователя) показать ему вашу отдельную страницу, на которой будет например, сообщение о том, что сайт временно не работает, но позже восстановит свою работу и на него обязательно стоит вернуться (сайт КиноПоиск при перегрузки серверов выдает сообщение «Матрица перезагружается. » и соответствующую картинку). Наиболее распространенным решением является составление собственной страницы вместо стандартной 404-ошибки. Эта ошибка показывается пользователю, если введен адрес несуществующей страницы. Думающие вебмастеры, создают свою страницу вместо непонятной стандартной, на которой пишут, что человек перешел по несуществующей ссылке и предлагают поискать нужную информацию на сайте, а не уйти с него. Пример нашей 404-страницы можно увидеть здесь. Чтобы показывать пользователям свою страницу ошибки вместо стандартной, нужно создать отдельную страницу (например http://yoursite.com/404.html) и добавить соответствующий код в файл .htaccess Вот примеры кода, который нужно добавить:

Если вы хотите подставить другую страницу вместо ошибки 403, то нужно указывать еще текстовое сообщение, которое будет показано, например:

Как включить кеширование браузера правильно

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

Когда файл понадобится снова, браузер извлечет его из своего локального кеша, а не будет запрашивать повторную загрузку с сервера. Это экономит трафик с вашего сайта и позволяет избежать ненужных HTTP-запросов при последующем просмотре страниц.

Установите дату истечения срока действия или максимальный период для статических ресурсов, таких как изображения, css-стили, js-скрипты, pdf, swf-файлы. После настройки кеширования сайт будет загружаться намного быстрее.

Включить кеширование браузера можно, если прописать в .htaccess следующий код:

iPipe – надёжный хостинг-провайдер с опытом работы более 15 лет.

Мы предлагаем:

• Виртуальные серверы с NVMe SSD дисками от 299 руб/мес
• Безлимитный хостинг на SSD дисках от 142 руб/мес
• Выделенные серверы в наличии и под заказ
• Регистрацию доменов в более 350 зонах

Код стандартного .htaccess файла вордпресс

В зависимости от процедуры установки WordPress, у вас может не быть файла .htaccess в корне сайта. Чтобы его создать, используйте текстовый редактор. Назовите файл .htaccess и загрузите его на сервер. Некоторые операционные системы, например, Windows, не позволят вам задать подобное имя файла. В этом случае сформируйте файл htaccess.txt, а после загрузки на сервер переименуйте его в .htaccess.

Код, который согласно кодексу WordPress должен находиться внутри файла:

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

Не рекомендуется добавлять или редактировать что-либо между строками # BEGIN WordPress и # END WordPress. Когда вы добавляете новые правила, включайте их выше или ниже приведенного кода.

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

Ускоряем загрузку с помощью сжатия файлов

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

AddOutputFilterByType DEFLATE text/html

А для сжатия текстовых:

AddOutputFilterByType DEFLATE text/plain

Можно также сжимать JavaScript файлы или определять несколько типов файлов для архивации:

AddOutputFilterByType DEFLATE application/javascript
 
AddOutputFilterByType DEFLATE application/rss+xml

В качестве альтернативы можно сжимать все HTML, JavaScript, CSS и прочие файлы с помощью GZIP:

<IfModule mod_gzip.c>
 
mod_gzip_on Yes
 
mod_gzip_dechunk Yes
 
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
 
mod_gzip_item_include handler ^cgi-script$
 
mod_gzip_item_include mime ^text\.*
 
mod_gzip_item_include mime ^application/x-javascript.*
 
mod_gzip_item_exclude mime ^image\.*
 
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
 
</IfModule>

Кодировка

Иногда браузер пользователя не может корректно определить тип кодировки выдаваемого документа. Для решения этой проблемы используемая кодировка указывается в настройках Web-сервера Apache и заголовке передаваемого документа. Причем для корректного распознания эти кодировки должны совпадать. На наших серверах по умолчанию используется кодировка UTF-8.

В HTML для указания кодировки используется тег:

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

• Windows-1251 — Кириллица (Windows).
• KOI8-r — Кириллица (КОИ8-Р).
• cp866 — Кириллица (DOS).
• Windows-1252 — Западная Европа (Windows).
• Windows-1250 — Центральная Европа (Windows).
• UTF-8 — двух байтовая кодировка.

Теперь рассмотрим указание кодировки по умолчанию через .htaccess. AddDefaultCharset задает дефолтную таблицу символов (кодировку) для всех выдаваемых страниц на веб-сервере Apache. Указываем кодировку на все файлы, в которой по умолчанию получает документы браузер:

При загрузке файла на сервер возможна перекодировка. Указываем, что все получаемые файлы будут иметь кодировку windows-1251, для этого напишем:

Если необходимо отменить перекодировку сервером файлов:

Miscellaneous

Custom Error Pages

ErrorDocument 500 "Houston, we have a problem."
ErrorDocument 401 http://error.example.com/mordor.html
ErrorDocument 404 /errors/halflife3.html

Force Downloading

Sometimes you want to force the browser to download some content instead of displaying it.

<Files *.md>
    ForceType application/octet-stream
    Header set Content-Disposition attachment
</Files>

Now there is a yang to this yin:

Prevent Downloading

Sometimes you want to force the browser to display some content instead of downloading it.

<FilesMatch "\.(tex|log|aux)$">
    Header set Content-Type text/plain
</FilesMatch>

Allow Cross-Domain Fonts

<IfModule mod_headers.c>
    <FilesMatch "\.(eot|otf|ttc|ttf|woff|woff2)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

Auto UTF-8 Encode

Your text content should always be UTF-8 encoded, no?

# Use UTF-8 encoding for anything served text/plain or text/html
AddDefaultCharset utf-8

# Force UTF-8 for a number of file formats
AddCharset utf-8 .atom .css .js .json .rss .vtt .xml

Switch to Another PHP Version

If you’re on a shared host, chances are there are more than one version of PHP installed, and sometimes you want a specific version for your website. The following snippet should switch the PHP version for you.

AddHandler application/x-httpd-php56 .php

# Alternatively, you can use AddType
AddType application/x-httpd-php56 .php

Disable Internet Explorer Compatibility View

Compatibility View in IE may affect how some websites are displayed. The following snippet should force IE to use the Edge Rendering Engine and disable the Compatibility View.

<IfModule mod_headers.c>
    BrowserMatch MSIE is-msie
    Header set X-UA-Compatible IE=edge env=is-msie
</IfModule>

Serve WebP Images

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]

Модификация URL в htaccess

Наиболее часто htaccess используется для модификации URL во время выполнения или редиректов. За эту функциональность отвечает модуль mod_rewrite и обычно он активирован в большинстве конфигураций Apache.

Модификация URL в htacces выполняется с помощью трех директив, это RewriteBase, которая указывает префикс адреса, RewriteCond проверяет соответствие, и RewriteRule — изменяет URL в соответствии с регулярным выражением если все правила соответствия подходят.

Сначала нужно включить Mod_Rewrite, на случай если модуль еще не активен:

Укажем, что в качестве префикса для URL нужно использовать корень:

И будем автоматически заменять URL адреса с index.html на index.php, обратите внимание, что исходный URL — это путь к запрашиваемому файлу относительно расположения файла htaccess:

Для более эффективной замены можно использовать регулярные выражения они состоят из специальных символов и переменных и обычных символов и цифр. Рассмотрим основные специальные символы:

• ^ — начало строки;
• $ — конец строки;
• . — любой символ;
• * — любое количество любых символов;
• ? — один определенный символ;
• — последовательность символов, например, от 0 до 9;
• | — символ или, выбирается или одна группа, или другая;
• () — иcпользуется для выбора групп символов.

В регулярных выражениях htaccess также можно использовать переменные с данными, полученными из заголовков запроса, например:

• %{HTTP_USER_AGENT} — поле User-Agent, которое передает браузер пользователя;
• %{REMOTE_ADDR} — IP адрес пользователя;
• %{REQUEST_URI} — запрашиваемый URI;
• %{QUERY_STRING} — параметры запроса после знака ?.

Директива RewriteCond дает еще больше гибкости, вы можете выбрать к каким адресам стоит применять модификацию, например, будем переопределять данные только для версии с www:

Таким образом, вы можете выполнять любые преобразования ваших URL без фактических редиректов куда-либо. Но дальше мы рассмотрим как делать редиректы.

Создаем htaccess на компьютере

Для создания такого документа вы можете использовать любой текстовой редактор, который установлен на вашем ПК. Можно воспользоваться даже простым Блокнотом, который установлен в качестве стандартного софта на Windows.

Кликните правой кнопкой мыши на свободном месте рабочего стола, после чего выберите “Создать” – “Текстовый документ”. На рабочем столе появится файлик с названием “Новый текстовой документ”. Откройте его, но ничего не вводите.

Далее, просто наведите курсор в левый верхний угол, найдите там пункты меню “Файл” – “Сохранить как”. Откроется окно сохранения, где будет необходимо выбрать папку для сохранения (можно сохранить прямо на рабочий стол), ввести название и выбрать тип файла.

В поле “Имя файла” вводим “.htaccess”. В раскрывающемся меню “Тип файла” выбираем “Все файлы”. Далее, жмем на кнопку сохранить. Все, документ создан.

Обратите внимание, что он не должен иметь расширение. То есть не должно быть, например, “.htaccess.txt”

Если все хорошо, вы можете загружать его на хостинг. Либо же оставить для занесения каких-то параметров.

Правильный 301 редирект через файл .htaccess

Важно! Если вы хотите, чтобы ваш редирект работал, нужно перед строками, которые рекомендуются ниже по тексту, обязательно прописать

301 Редирект с одной страницы на другую (или сайт)

Для этого в файл .htaccess вносим следующие строки:

RedirectPermanent /старая-страница.html http://сайт.рф/новая-страница.html

301 Редирект с www-сайта на сайт без www

Например перенаправление с http://www.site.com на http://site.com. Это очень полезная вещь, часто используется в СЕО

Как добавить .html в конце URL?

Чтобы при вводе site.com/page или site.com/page/ происходило перенаправление на site.com/page.html пишем в .htaccess следующее:

301 Редирект с одного раздела на другой?

Перенаправление всех страниц одного раздела site.com/razdel-1/razdel-2/page на на страницы другого раздела site.com/razdel-1/page

301 Редирект при переезде со старого домена на новый

Следующее правило корректно перенаправит посетителей с каждой конкретной страницы старого сайта на такую же страницу на новом сайте. Например со страницы oldsite.com/page на newsite.com/page

Как защитить изображения от вставки на других ресурсах

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

Предотвратить несанкционированное использование картинок на своем сайте можно, если добавить в .htaccess этот код:

Такой код позволяет отображать изображения только в том случае, если запрос отправляется с сайта site.ru или Google.com. Замените site.ru на доменное имя вашего сайта.

Директивы htaccess. Техническая оптимизация и ускорение

Запрещаем автоматическое индексирование файлов

В каждой папке на сайте Apache создает, по умолчанию, индексные файлы, в которых перечисляется, какие файлы в папке находятся. Если вы не хотите давать дополнительную лазейку для злоумышленников — запретите индексирование.

Options -Indexes

Включаем gzip сжатие

Вы знаете о том, что данные на сервере можно сжать, а клиент их распакует у себя? Код ниже как раз включает такую штуку. Нужно только убедиться, что gzip разрешен на вашем хостинге, но обычно он есть.

Код не работает для изображений, но к ним применять gzip не рекомендуется. Именно такой код установлен у меня.

Сжатие с применением mod_deflate

Ходят слухи, что с помощью этого мода сжимать данные лучше и сайт работает быстрее. Я не могу протестировать, да и не встречал в Интернете подобных тестов. Если у кого есть такая информация — буду благодарен. А код выложу, мало ли

Включаем кэширование браузера клиента

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

Указываем кодировку по умолчанию

WordPress работает с кодировкой UTF8 и делает это хорошо, но чтобы гарантированно избежать проблем с кодировкой — укажите ее принудительно, хуже не будет точно.

AddDefaultCharset UTF-8

Ограничиваем число подключений к сайту

Современные браузеры умеют создавать несколько одновременных подключений к серверу, отдающему сайт. Если же у вас маловато ресурсов, можно ограничить число подключений.

MaxClients <количество подключений>

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

Разрешаем выполнение php внутри JavaScript

Иногда необходимо выполнить некоторый код внутри скрипта. Этот код поможет включить эту функцию

Вот и все, что касается htaccess и его стандартного использования. Я не стал упоминать о защите папок паролями, потому что не считаю это правильным, о «защите» от спама, путем блокировки запросов запросов без передачи Referer, потому что все современные спам-машины давно умеют это делать. Ну и прочие вещи, которые не считаю грамотно реализованными.

ImageCache и защита от хотлинка через .htaccess

Для ImageCache предыдущий пункт работать не будет, поэтому добавляем такие настройки:

SetEnvIfNoCase Referer «^$» local_ref=1
# Allowed domains
# Далее разрешенные домены
SetEnvIfNoCase Referer «^http
SetEnvIfNoCase Referer «^http
# File extensions that you want to protect
# Расширения файлов, которые нужно защитить
<FilesMatch "\.(bmp|jpe?g|gif|png)">
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

Теперь у нас есть и защита от хотлинка и модуль ImageCache — вместе они работают превосходно. Одно «но» — таким способом, как вы видите не получится выдавать другую картинку; только защита своих изображений, что и является основной целью.

Заключение

Как видите, htaccess – это очень важный файл, который помогает контролировать работу сервера. Это не основной конфигурационный документ, но с его помощью также можно настраивать определенные параметры оборудования. Также при помощи этого документа вы сможете настраивать различные редиректы, без которых сейчас не обойдется ни один нормальный сайт.

Настройка этого конфига – дело важное и требующее определенного понимания. Если вы что-то неверно введете, то велика вероятность, что ваш ресурс просто перестанет открываться

Он будет просто выдавать ошибку, и для исправления вам придется заходить на хостинг и сбрасывать все изменения этого документа.

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