Файл .htaccess

Rewrite Rules in .htaccess files

When using in
files, be aware that the per-directory context
changes things a bit. In particular, rules are taken to be relative to
the current directory, rather than being the original requested URI.
Consider the following examples:

# In httpd.conf
RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"

# In .htaccess in root dir
RewriteRule "^images/(.+)\.jpg" "images/$1.png"

# In .htaccess in images/
RewriteRule "^(.+)\.jpg" "$1.png"

In a in your document directory, the leading
slash is removed from the value supplied to , and in the
subdirectory, is removed from
it. Thus, your regular expression needs to omit that portion as
well.

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 – основные возможности

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

В процессе обработки запросов веб-сервер может генерировать коды различных ошибок. Например, если введенный URL ссылается на несуществующую страницу, Apache отправит код, который может быть непонятен рядовому пользователю. При разработке веб-приложений создают отдельные страницы с пояснениями ошибок (например, «Ошибка 404 – страницы не существует»). Чтобы организовать процесс автоматического перенаправления на данную страницу, используют следующую директиву в файле htaccess:

ErrorDocument 404 https://website.net/error/404.html

Некоторые хостинг-провайдеры упрощают процесс создания страниц ошибок и организации перенаправления. Например на нашем виртуальном хостинге страницы ошибок устанавливаются при помощи панели управления.

Чтобы задать в htaccess перенаправление на файл страницы сайта, используют директиву 301. Данная директива имеет следующий синтаксис:

Redirect 301 /some_page.html https://website.net/some_another_page.html

Если требуется выполнить перенаправление на новый домен (актуально например, если сайт был перенесен, а часть посетителей привыкли использовать старое доменное имя), вводят следующую директиву:

Redirect 301 / https://www.new_website_domain.net/

Что касается редиректа, некоторые разработчики выполняют htaccess 404 редирект, то есть перенаправление, например, на главную страницу веб-ресурса в случае получения запроса на несуществующую страницу. С точки зрения SEO данный подход считается некорректным.

Создание постоянной переадресации 301 через настройки и плагины CMS

В большинстве популярных конструкторов сайтов и CMS (OpenCart, Joomla!, Битрикс, Wix, Тильда) предусмотрена настройка редиректов с помощью встроенных инструментов. Если сайт создан с помощью WordPress, для настройки переадресации можно воспользоваться следующими плагинами:

• Redirection — самый популярный плагин для настройки редиректов. Кроме основной функции обладает следующими возможностями: сбором статистики переадресаций, отслеживанием ошибок 404, поддержкой регулярных выражений.

• Safe Redirect Manager — простой плагин, который также поддерживает регулярные выражения, практически не влияет на производительность сайта.

• Quick Page/Post Redirect Plugin — еще один удобный инструмент оптимизации. Один из недостатков — отсутствие поддержки регулярных выражений. К ссылкам можно добавлять атрибут «nofollow».

• Simple 301 Redirects. Данный модуль обладает одним недостатком – url для переадресации необходимо прописывать вручную.

Настроить Permanent Redirect 301 в Вордпресс можно и через редактирование файла .htaccess в разделе управления хостингом. Чтобы подключиться к нему, потребуется использовать FTP-клиент. Сама кодировка производится по общим правилам настройки переадресации в .htaccess.

Чтобы настроить 301 редирект в CMS OpenCart в файле .htaccess необходимо прописать:

RewriteCond %{QUERY_STRING} ^_route_=адрес_старой_страницы.html$

RewriteRule ^(.*)$ http://ваш_домен.ru/новой_страницы/? 

Для Битрикс кодировка будет выглядеть следующим образом:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www.sng-it.ru$ 

RewriteRule ^(.*)$ http://sng-it.ru/$1 

В Joomla настройки переадресации производятся через панель администратора в разделе «Компоненты» => «Перенаправление». Здесь можно не только установить правила редиректа, но и отслеживать страницы с битыми ссылками и перенаправлять их на корректные адреса.

С конструкторами сайтов все не так однозначно. Например, один из наиболее популярных CMS-конструкторов WIX не предоставляет возможности создания файла .htaccess.

Но настроить редирект 301 довольно просто в базовом редакторе.

Примеры команд

Теперь я расскажу о наиболее популярных примерах использования команд у этого конфига. Они могут использоваться как для HTML-сайта, так и для проекта на платформе. Каждая команда может сломать ваш проект, поэтому будьте максимально аккуратны при настройке.

Переадресация

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

Вы можете менять значения, которые выделены жирным. Например, вместо 301-го редиректа вы можете использовать другой. Всего есть 4 различных значения.

1. 301 – документ перемещен навсегда.
2. 302 – документ перемещен временно.
3. 303 – смотрите другие документы ресурса.
4. 410 – документ был безвозвратно удален.

Mod_rewrite – настройка сложных редиректов

Это специальный модуль, который позволяет настраивать переадресацию на какой-то конкретный протокол или домен определенного вида (с www или без него, к примеру). Данный модуль работает только на серверах Apache, поэтому далеко не каждый хостинг будет это поддерживать.

Основное зеркало.

Вместо site.ru должен быть ваш домен. Если вы введете это в конфигурационный документ, ваш сайт будет перенаправлять пользователей с www на обычную версию ресурса. Допустим, человек попытается перейти на www.site.ru/stat1, его сразу же перекинет на site.ru/stat1. Вот так это и работает.

Редирект на https.

Если вы установили SSL-сертификат и хотите, чтобы все страницы проекта открывались через защищенное соединение, вам необходимо просто прописать эти строчки.

Менять в этом коде ничего не нужно, все будет работать именно в таком виде.

Редирект на другой домен.

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

Вы можете изменить название сайта, добавив или убрав определенные варианты. Например, вы можете настроить редирект сразу на сайт с https. Также вы можете изменить домен на вариант без www.

Запрет индексирования для определенного поискового робота.

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

Вместо Googlebot вы можете ввести название любого другого поискового робота. При обращении к вашему домену поисковый робот будет получать ошибку. Проиндексировать сайт он никак не сможет.

Примеры 301 редиректов в .htaccess

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

• 301 редирект для удаления/добавления слэша в конце URL
• 301 редирект с index (.html и .php) на корень сайта «/»
• Редирект 301 с http на https
• Редирект 301 с www на без www
• Смена адреса сайта — редирект со старого домена на новый

Здесь мы дополним варианты редиректов, которых еще не было.

2.1. Редирект с одной страницы на другую

Редирект с site.ru/cat/oldpage на site.ru/newpage.html

RewriteRule ^cat/oldpage.* /newpage.html 

Или второй вариант:

Redirect 301 /cat/oldpage http://www.site.com/newpage.php 

2.2. Редирект со всех файлов .htm на .html

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)\.htm$ $1.html 

Или второй вариант:

RewriteRule ^(.*)\.htm$ $1.html 

С любой страницы в каталоге и подкаталогах /old/ будет происходит редирект на /new.php

RewriteRule ^old(.*)$ /new.php 

2.4. Удаление лишних слэшей в адресе URL

Например, страница /catalog///stranica.html доступна и открывается. Чтобы избежать такой ситуации и не плодить бесконечное число дублей следует записать следующий редирект

RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . %1/%2 

2.5. Реврайт без редиректа

Можно загрузить другую страницу без смены адреса страницы URL. Например, загрузим страницу /news.html, а в адресной строке будет отображаться адрес /news/happy

RewriteRule ^news/happy.* /news.html 

2.6. Простановка замыкающего слеша в конце адреса главной страница

Например, многие сервера работают так, что последний слэш не пишется в URL. Например, http://site.ru. Ниже приведенный код решают это проблему: сайт будет открывать по http://site.ru/

RewriteCond %{REQUEST_URI} /++$
RewriteRule ^(.+)$ %{REQUEST_URI}/ 

Например для редиректа со страницы site.com/directoriya/stranica.html на site.com/stranica.html нужно прописать следующее:

RewriteRule ^directoriya/(.+)$ http://site.com/$1 

Или второй вариант:

RewriteCond %{DOCUMENT_ROOT}/directoriya/$1 -f
RewriteRule ^(.*)$ directoriya/$1 

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

Например, сделать редирект со страницы /?act=page&id=2 на /page-2/

RewriteCond %{QUERY_STRING} act=page 
RewriteCond %{QUERY_STRING} id=(\d+) 
RewriteRule .* /page/%1/? ]

2.9. Редирект на мобильную версию сайта m.site.ru

В данном примере сначала проверяется факт того, что пользователь открыл сайт с мобильного устройства , далее происходит замена адреса сайта на m.URL

RewriteCond %{HTTP_HOST} ^(.*)$ 
RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) 
RewriteRule ^$ http://m.%1 

2.10. Редирект с поддомена

Например, выполним редирект с любой страницы поддомена poddomen.site.ru на основной домен site.ru

RewriteCond %{HTTP_HOST} ^poddomen.site.ru$ 
RewriteRule ^(.*)$ http://site.ru%{REQUEST_URI} 

Безопасность

xxx.xxx.xxx.xxx — это ваш IP. Если вы замените последние три цифры, например, на 0/12, этим вы определите диапазон IP внутри этой сети и это оградит вас от проблемы перечислять по отдельности все разрешённые IP.

И, естественно, противоположная функция к этой:

Запретить доступ к скрытым файлам и директориям

Скрытые файлы и директории (те, чьи имена начинаются с точки .) должны в большинстве, если не все, быть недоступны для других. Например: .htaccess, .htpasswd, .git, .hg…

Как вариант, вы можете показывать ошибку Not Found (не найдено), чтобы не давать атакующему подсказку:

Запретить доступ к файлам

Эти файлы могут быть оставлены некоторыми редакторами text/html (вроде Vi/Vim) и представляют огромную дыру в безопасности, если станут общедоступными.

Защитить паролем директорию

Сначала нужно создать файл .htpasswd в определенной директории:

И потом использовать этот файл для аутентификации:

Запретить рендеринг сайта во фрейме

Эта команда запрещает отображение сайта во фрейме (например, в теге iframe), но разрешает отображение сайта во фрейме для определенных URI.

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

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

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

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

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

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

Запрещение доступа к определенным ресурсам

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

AuthName ";Username and password required";

AuthUserFile /path/to/.htpasswd

Require valid-user

AuthType Basic

Этот файл нужно сохранить и поместить в директорию, которую
мы хотим защитить. Указание AuthName,
выводит сообщение с блоков ввода логина и пароля. AuthUserFile это указание пути к файлу .htpasswd. Указание Require, определяет, что только авторизованные
пользователи имеют доступ к защищенным файлам, в то время как AuthType установлено на Basic.

Для защиты конкретного файла, мы можем поместить следующий
код в директиву <files>, в которой определяются файлы для защиты доступа.

Files ";protectedfile.html";>

AuthName ";Username and password required";

AuthUserFile /path/to/.htpasswd

Require valid-user

AuthType Basic

</Files>

Мы также ссылаемся на файл .htpasswd, который содержит имена пользователей
и зашифрованные пароли доступа к защищенным ресурсам. Этот файл должен быть
сохранен в директории, к которой невозможно добраться через web (то есть, этот файл не должен
находится в директориях сайта). Существует множество сервисов, которые могут
быть использованы для генерации этих файлов автоматическим образом, так как пароль
должен быть закодирован.

Как создать файл .htaccess

Файл .htaccess можно создать при помощи Вашего любимого текстового редактора. Просто создаем новый файл, сохраняем в кодировке ANSI и при сохранении присваиваем ему имя «.htaccess». Если вы работаете на Windows или MacOS, так же необходимо преобразовать формат окончания строк в UNIX-формат, иначе сервер, с загруженным на него файлом .htaccess будет выдавать 500 ошибку.

Теперь подробнее, как это можно сделать при помощи бесплатного текстового редактора Notepad ++, скачать который можно здесь:

Открываем текстовый редактор и он автоматически создает новый файл. Если новый файл программой не создан, создаем его сочетанием клавиш ctrl + N или выбрав команду «новый» в меню «файл»:

Заходим в меню «кодировки», чтобы убедится, что кодировка нашего файла ANSI, если кодировка UTF или UCS, то легким кликом мыши преобразовываем ее:

Находим в меню «Правка» подменю «Конверсия конца строки» и меняем в нем кодировку на Unix-формат:

Нажимаем на изображение дискетки либо сочетание клавиш ctrl + S, либо выбираем команду «сохранить» или «сохранить как» в меню «файл». В появившемся диалоговом окне выбираем директиву для сохранения, в поле «тип файла» выбираем «all types» (все типы), в поле «имя файла» пишем «.htaccess», нажимаем «сохранить».

Если в файле .htaccess заданы настройки для всего сайта, то помещаем его в корневой каталог сайта, если же он содержит настройки какого-то раздела, то помещаем его в соответствующий раздел.

Проверяем сайт на наличие ошибок. Если сервер выдает ошибку 500, значит, где-то допущена ошибка. Проверьте синтаксис файла, еще раз проверьте кодировку и формат переноса строк. Самая распространенная причина, почему после загрузки файла .htaccess на сервер, появляется ошибка 505 (ошибка сервера), это неправильная кодировка в файле .htaccess.

читать далее →

Блокирование доступа отдельных IP, user-agent

Еще одно использование файла .htaccess, это быстрое и простое
блокирование всех запросов от отдельных IP адресов или user-agent. Для блокирования отдельных IP адресов
необходимо лишь указать несколько директив, как показано в примере:

order allow,deny

deny from 192.168.0.1

allow from all

Директива order, сообщает серверу,
в какой последовательности выполнять директивы allow/deny. В этом случае, директива allow будет выполнятся первой, потом deny. Указание
allow from all выполняется первым (хотя
и стоит в коде после deny),
оно позволяет всем IP адресам иметь доступ к содержимому. После этого вступает в
силу директива deny, которая запрещает доступ
определенным IP. Таким
образом имеют доступ все, кроме указанных IP адресов. Следует отметить, что мы
можем запрещать доступ используя короткие IP адреса, например 192.168.

Для запрещения запросов отдельных user-agent, нам следует сделать следующее:

RewriteCond %{HTTP_USER_AGENT} ^OrangeSpider

RewriteRule ^(.*)$ http://%{REMOTE_ADDR}/$ 

В этом примере, все клиенты со строкой HTTP_USER_AGENT начинающейся на OrangeSpider (плохой бот) будут направлены по обратному адресу. Регулярное
выражение предрасполагает, что может быть любой символ (.) ноль или больше раз (*),
и перенаправляет на %{REMOTE_ADDR}.
Флаг L, мы используем как инструкцию для сервера, выполнять это
указание первым. Никакой процесс не будет выполняться перед выполнением этого
правила.

Где находится .htaccess

Можно с легкостью проверить, есть ли у вас служебный файл. От многих других документов он отличается тем, что имеет только расширение в виде названия из слова, тогда как самого названия нет. Да, мы все привыкли видеть файлы с названием из слова, и расширением после точки, которое состоит всего из 2-3 букв. Но пустые названия позволяют делать файлы и папки «скрытыми», с открытым исходным кодом. Из этого следует вывод, что .htaccess для обычных пользователей остается невидимым, поэтому они не смогут его изменить.

Но есть у этого метода «скрытия» файла и обратная сторона медали. В стандартных FTP-клиентах на ОС Windows и Mac, документ очень часто остается невидимым для пользователей, из-за чего они ошибочно полагают, что его просто нет. Поэтому человек создает новый файл для внесения своих конфигураций, кодов для обработки ошибок, создания доступа к папкам и пр. Хорошо, что большинство хостингов оставляют место на диске, где htaccess-файл уже установлен автоматически.

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

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

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

Как включить файл htaccess и проверить его работу

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

Данная директива размещается исключительно в блоке <Directory>. Отметим, что также по умолчанию принимается значение «All», что, в том числе, сказывается на работе файлов .htaccess. Правда, есть и другой вариант: при значении «None» они окажутся выключены. Но нельзя не отметить, что существуют и многие другие варианты значений, накладывающие определенные ограничения на конфигурацию. Вот их примеры:

1. AuthConfig – позволяет применять директивы разрешения для защиты каталогов паролями. Другими словами, с этим значением авторизация ведется по логину, паролю, что называется базовой аутентификацией.
2. FileInfo – разрешает работу директив, задающих типы документа (Headers, Error Documents, Cookies, URL Rewriting , пр).
3. Indexes – отображает перед посетителем перечень файлов, когда выбранный каталог лишен файла index.html либо аналогичного ему.
4. Limit – позволяет работать с ключевыми директивами управления доступом (allow, deny, order), сакционирования Limit. Может, отталкиваясь от данных об адресе клиентского устройства, ограничивать доступ к файлам.
5. Options – дает возможность контролировать перечень функций сервера в каталоге, открытых для использования. Напомним, каталог указывается в < Directory>. Значение выглядит так: ExecCGI, FollowSymLinks, MultiViews, Includes, пр.

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

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

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

Способ 1

Для данного легкого метода заставим Apache с помощью директив файла htaccess искать «indexgood.html» до «index.html». Если .htaccess поддерживается, попадая в папку через браузер, Apache загрузит .htaccess, и на экране появится страница «indexgood.html» с поздравлением! В противном случае Apache, не обращая внимания на .htaccess, будет искать файл «index.html».

    # Эта директива заставит Apache искать

    # «index_good.html» перед «index.html» 

    DirectoryIndex index_good.html index.html 

Директива DirectoryIndex получает список, в котором через запятую перечисляются вероятные файлы. Если перед Apache ставятся URL директории, значит дается не прямой путь к файлу (не http://www.example.com и не http://www.example.com/index.html), поэтому он прибегнет к списку для обнаружения заданного файла. Движение по перечню идет слева направо. Если первый файл найден, он будет загружен, пользователь его увидит.

Способ 2

Обычный неверный синтаксис в вашем файле .htaccess. пригоден для проверки – сервер не сможет с ним справиться!

    # здесь мы намеренно допускаем ошибку

    AHHHHHHH 

«AHHHHHHH» – это не директива Apache, то есть приведет к ошибке, как только тот попытается осуществить просмотр файла htaccess. О чем это нам скажет? Если перед вами появится страница с «Internal Server Error» – поддержка работает. Так как данная ошибка означает, что сервер искал .htaccess файл. Если же вы увидите index.html – она отключена.

Вас также может заинтересовать: Сарафанное радио: принципы, методы и идеи необычного маркетинга

.htaccess переадресация

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

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

 Перенаправим RSS фиды WordPress на Feedburner

Я не думаю, что кто-то пользуется чем-то другим, отличным от Feedburner. Удобно для пользователя, удобно для владельца блога, статистика, опять же. Если вы еще не используете — крайне рекомендую. Код ниже перенаправит все ваши RSS потоки на ваш аккаунт, не забывайте только вставить нужный адрес.

В этом примере идет перенаправление двух потоков: основного RSS и обновление комментариев, если посетитель подписан на обновления.

Изменим страницы ошибок

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

В этом примере идет перенаправление в случае основных ошибок. 404 я тоже добавил, хотя CMS обычно отрабатывают такие моменты, но бывали случаи.

301 и 302 редирект или перенаправление

301 редирект или, так называемое постоянное перенаправление — говорит о том, что страница поменяла адрес или URL и перенаправляет на новую страницу. Если у вас на сайте была проиндексированная ПС страница, а вы поменяли ее адрес — в обязательном порядке сделайте 301 редирект на новую страницу. При 301 редиректе старая страница не индексируется, а вместо нее «подставляется» новая.

Собственно, похожий пример внимательный читатель увидит выше, в случае перенаправления RSS. Да, технология та же. Бывает так, что сайт переезжает на новый домен, нужно сохранить структуру ссылок, а их могут быть сотни и тысячи, на каждую установить перенаправление нереально. Код ниже поможет разобраться с такой ситуацией:

Есть интересная методика «скрытия» внешних ссылок путем 301 редиректа. Допустим, у вас есть «сквозная» ссылка в сайдбаре, которая ведет на ваш профиль в Google+, она внешняя, то есть ведет на внешний ресурс. Для SEO очень хорошо, когда таких ссылок как можно меньше. Можно спрятать их и сделать внутренними.

Технология производства внутренних ссылок из внешних:

• ставим ссылку на мнимую страницу,
• настраиваем 301 редирект в htaccess с этой страницы на реальную страницу вашего профиля
• посетитель ничего не чувствует, ПС довольны

Подобным образом можно ставить любые другие условно постоянные ссылки. 302 редирект или временное перенаправление говорит ПС, что страница перемещена временно, поэтому индексировать нужно обе страницы, старую и новую.

Код абсолютно такой же, как в случае с постоянным перенаправлением. 302 редирект удобно использовать, когда проводятся какие-либо долгосрочные работы на сайте и не нужно показывать посетителям «поломанные» страницы. В таком случае вам поможет этот код:

 Склеиваем сайты с www и без него

Очень плохо, когда сайт доступен по двум адресам, ПС это очень не любят. Склеить это в один адрес поможет код ниже:

В этом примере — главное зеркало это адрес без www. Если необходимо сделать наоборот — поменяйте www местами, сверху уберите, внизу добавьте.

Перенаправляем на главную

Перенаправление со страниц site.com/index.php и site.com/index.html на страницу site.com/. За код спасибо Василию Красноженову.

Общие случаи использования .htaccess

1. Mod_Rewrite

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

2. Аутентификация

Хотя файл .htaccess не требует столько прав, как стандартный конфигурационный файл apache2.conf, его все же можно использовать, чтобы внести в защиту сайта эффективные изменения. Дело в том, что .htaccess позволяет запрашивать пароль для доступа к определенным разделам веб-страницы. Пароли .htaccess хранятся в файле по имени .htpasswd.

Примечание: по соображениям безопасности хранить такой файл в каталоге сайта категорически не рекомендуется.

В файле .htpasswd нужно указать имена и пароли всех пользователей, которым разрешен доступ к защищенной части сайта.

Имена и пароли вносятся в файл в виде пары имя_пользователя:зашифрованный_пароль. Например, если пользователь с именем best_user имеет пароль awesome, то такая пара может иметь вид «best_user:VtweQU73iyETM».

Примечание: каждая пара вносится в отдельную строку. Файл .htpasswd может содержать столько строк, сколько необходимо.

Создав .htpasswd, внесите в .htaccess следующий код, чтобы активировать функцию аутентификации:

Строка AuthUserFile определяет путь к файлу .htpasswd.

Строка AuthGroupFile указывает расположение .htgroup. Поскольку на данный момент такого файла не существует, оставьте значение /dev/null.

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

AuthType относится к типу аутентификации, который будет использоваться для проверки паролей. Пароли проверяются через HTTP, ключевое слово Basic изменять нельзя.

СтрокаRequire valid-user говоритфайлу .htaccess, что в защищенные паролем разделы сайта должны иметь доступ несколько человек. В случае если нужно указать определенного человека, имеющего доступ к закрытым частям сайта, вместо строки Require valid-user используется строка Require user имя_пользователя.

3. Пользовательские страницы ошибок

Файл .htaccess позволяет создавать для сайта пользовательские страницы ошибок. Некоторые из наиболее распространенных ошибок являются:

• 400 Bad Request (Неверный запрос)
• 401 Authorization Required (Требуется авторизация)
• 403 Forbidden Page (Запрещенная страница)
• 404 File not Found (Файл не найден)
• 500 Internal Error (Внутренняя ошибка)

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

Для примера можно создать страницу 404 (попробуйте создать любую страницу ошибки на ваш выбор).

Создав и загрузив страницу ошибки, укажите ее местонахождение в файле .htaccess:

Запомните: Apache ищет страницу 404 в root-каталоге сайта. Поместив новую страницу ошибки 404 в каком-либо подкаталоге, не забудьте добавить этот подкаталог в строку, например:

4. MIME-типы

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

Не забудьте заменить приложение и расширение файла MIME-типом, который нужно поддерживать.

5. SSI

Технология Server Side Includes отлично экономит время на веб-сайте. Одним из наиболее распространенных способов использования SSI является обновление большого количества страниц, содержащих определенный блок данных, без необходимости обновлять каждую страницу по отдельности (например, чтобы изменить цитату в нижней части страницы).

Чтобы включить SSI, введите в .htaccess следующий код:

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

Тем не менее, если на сервере находится большое количество страниц .html, поменять расширение которых на .shtml займет много времени, можно использовать другую тактику их проверки на SSI-команды. Для этого используется параметр XBitHack.

Добавление этой строки в файл .htaccess заставляет Apache проверять все html-файлы с соответствующими правами для Server Side Includes.

Чтобы позволить странице использовать  XBitHack, введите: