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

HTML redirect играют важную роль для масштабных веб-проектов. Возможность переадресации трафика с одного сайта на другой помогает лучше управлять потоками посетителей и выполнять реструктуризацию ресурса.

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

Редиректы выполняются с помощью .htaccess, PHP скрипт, HTML мета-тегов и JavaScript.

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

Редиректы используются для информирования серверов о том, что контент сайта был перенесен с одного URL-адреса на другой. Делать это необходимо, когда исходный веб-адрес (цель входящей ссылки) занимает высокие позиции в выдаче поисковых систем (SERP). В этом случае редирект сообщает поисковому роботу, что нужный контент был перенесен, предоставляя пользователю ссылку на новый адрес.


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

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

Типы редиректов

Различают клиентские и серверные HTML meta redirect. В случае с серверными перенаправлениями происходит передача кодов состояния HTTP пользовательским агентам (браузерам и поисковым роботам).

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

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


Серверные редиректы

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

Ниже приведены актуальные коды состояния HTTP 301 и 302:

  • redirect 301 HTML – перемещен навсегда: запрашиваемый ресурс теперь постоянно доступен по новому URL. Старый URL с этого момента становится недействительным;
  • 302 – перемещен временно: запрашиваемый ресурс доступен по новому URL. При этом исходный URL по-прежнему сохраняет свою актуальность.

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

Перенаправление через .htaccess

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


После того, как файл .htaccess со следующим кодом помещается в основные каталоги, запросы на исходный домен перенаправляются серверной стороной на домен www.example.com ‘‘:

Строка кода начинается с redirect 301 HTML и определяет код состояния HTTP, который будет передан сервером. Далее следует путь к контенту, который должен быть перенаправлен. В данном случае будет перенаправлено все содержимое. В заключении целевой URL перенаправляется на URL пользовательского агента: ‘http://www.example.com’.

Этот метод позволяет перенаправить отдельные файлы. Следующий код показывает редирект с одного сайта на другой:

.htaccess перенаправление из подкаталога на другой URL

Вот как выглядит постоянное перенаправление на сервере Apache с активным модулем mod_rewrite:

В первой строке кода модуль mod_rewrite сервера Apache активируется с помощью команды ‘RewriteEngine On’. После этого указывается «RewriteRule» с путем к файлу перенаправления и адресом назначения. Символы ^ и $ обозначают начало и конец пути, а L означает последнее правило для соответствующего запроса. R = 301 пересылает статус HTTP 301.


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

Перенаправления с помощью PHP

HTML redirect на другую страницу может также быть выполнен PHP скриптом (например, в index.php). Следующий код отображает постоянное перенаправление к целевому URL ‘www.example.com’:

При передаче через PHP скрипт код состояния HTTP определяется с помощью функции «header» во второй строке кода. В этом примере должен быть выполнен постоянный 301 редирект. Учитывая, что серверные перенаправления обычно выполняются на временной основе, то для постоянного редиректа нужно явно указать код состояния 301. Адрес назначения перенаправления также прописан в ‘header‘.

В примере перенаправление происходит на ‘http://www.example.com‘. Функция ‘exit‘ в четвертой строке кода заканчивает сценарий и препятствует выполнению следующей строки. Чтобы редиректы работали через PHP скрипт, блок кода должен быть расположен в начале HTML страницы. Это препятствует передаче сервером содержимого HTML на страницу перенаправления.

Клиентские редиректы

Если выполнение перенаправления на стороне сервера невозможно по техническим причинам, то можно использовать клиентское решение. Для этого применяется HTML метатег «refresh» и JavaScript. Недостатком перенаправления на стороне клиента является то, что серверы не передают коды состояния HTTP запрашивающим браузерам или поисковым роботам.


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

Redirect HTML index на стороне клиента оказывают негативное влияние на поисковый индекс. С клиентскими редиректами 301 не происходит явного исключения из индексации через код состояния HTTP. Это может привести к перенаправлению доменов, конкурирующих с доменами назначения, когда речь заходит о поисковых запросах, связанных с рейтингом. В отличие от серверных редиректов, которые остаются невидимыми для пользователей, клиентские всегда сопровождаются задержками.

Переадресация с помощью HTML метатега refresh

HTML перенаправления реализуются через метатеги с атрибутом ‘http-equiv’. Для этого нужен простой HTML-файл и соответствующий тег в заголовке для создания перенаправления. Чтобы посетители получали информацию о редиректе, в HTML-документе должно быть установлено соответствующее уведомление: «Пожалуйста, подождите. Вы будете перенаправлены … ‘. Простое перенаправление с помощью refresh выглядит следующим образом:

Клиенту будет предложено перенаправление на новую страницу через метатег http-equiv = «refresh». То, как это происходит, определяется в атрибуте ‘content’. Приведенный выше пример перенаправляет пользователей на домен ‘www.example.com‘ через десять секунд.


Переадресация с помощью JavaScript

JavaScript предлагает простую возможность HTML redirect домена на стороне клиента. Но JavaScript поддерживается не всеми браузерами из-за соображений безопасности. Использование данного решения также может создать проблемы для поисковых роботов и пользователей с активными дополнениями NoScript. Вот как выглядит код перенаправления с помощью JavaScript:

Самое главное здесь это третья строка кода. Объект ‘window.location‘ используется, чтобы сделать ссылку на текущий адрес сайта. Команда ‘replace‘ инструктирует браузер направить пользователя к домену назначения (‘www.example.com‘).

Перевод статьи “Domain redirects via .htaccess, PHP, HTML, and JavaScript” был подготовлен дружной командой проекта Сайтостроение от А до Я.

www.internet-technologies.ru

Самый простой пример редиректа: с сайта на сайт

Redirect / www.example.com

www.example.com — сайт, на который мы перенаправляем запрос пользователя.

Чуть более сложный пример — если мы хотим сделать редирект со страниц нашего сайта на другой сайт. Или, например, сделать редирект на главную страницу.


Redirect /semantica semantica.in/

Redirect /semantica/blog semantica.in/blog

Redirect 301 /kernel semantica.in/

 

Что всё это значит:

1 строка — при обращении к странице www.example.com/semantica будет открываться сайт semantica.in/

2 строка — при обращении к http://www.example.com/semantica/blog будет открываться semantica.in/blog

3 строка — веб-сервер будет отдавать код 301 о постоянном переезде на новый URL

 

Теперь, когда вы примерно понимаете, как это работает, можно переходить на задачи посложнее.

 

 

Сложные редиректы

Для сложных редиректов существует модуль mod_rewrite — это средство преобразования URL-адресов, использующее регулярное выражение. Для редиректа используются три важные директивы: RewriteCond, RewriteRule и RewriteEngine.

  1. RewriteEngine включает или выключает работу механизма преобразования:

Положение on-off включает и выключает работу модуля.

2. RewriteCond — определяет условие какого-либо правила, при котором происходит преобразование. Сразу после директивы чаще всего идут переменные %{HTTP_HOST} и %{REQUEST_URI}, которые означают адрес сервера (например, example.ru) и ресурс, запрошенный в строке HTTP-запроса, соответственно.

3. RewriteRule — идёт после одного или нескольких RewriteCond. Это правило преобразования URI, которое применяется только при условии выполнения RewriteCond.

Синтаксис директивы RewriteRule выглядит следующим образом:

 

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

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


  • ^ — метка начала строки,
  • $ — метка конца строки,
  • — экранирующий слеш, позволяет считать следующий за ним метасимвол обычным символом,
  • . — точка, обозначает любой символ, но только один,
  • () — группировка.
  • ! — отрицание,

Флаги определяют дополнительные опции для данного правила и перечисляются в квадратных скобках через запятую:

  • NC — (nocase) отключает проверку регистра символов.
  • R — (redirect) останавливает процесс преобразования и возвращает результат браузеру клиента как редирект на данную страницу (302, MOVED TEMPORARY). С данным флагом можно указать другой код результата, например R=301 возвратит редирект с кодом 301 (MOVED PERMANENTLY).
  • L — (last) останавливает процесс преобразования, и текущая ссылка считается окончательной.

 

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

Теперь, зная эти правила, мы можем попытаться самостоятельно сделать редирект с помощью htaccess.

  1. Редирект .htaccess на другую страницу
Redirect 301 /old-post.html http://new-site.ru/new-post.html

 

  1. Редирект .htaccess с www на без www
  RewriteEngine on    RewriteCond %{HTTP_HOST} !^site.ru$ [NC]    RewriteRule ^(.*)$ site.ru/$1 [R=301,L]  

 

  1. Редирект .htaccess с без www на www
  RewriteEngine on    RewriteCond %{HTTP_HOST} !^www.site.ru$ [NC]    RewriteRule ^(.*)$ www.site.ru/$1 [R=301,L]  

где site.ru — ваше доменное имя.

 

  1. Редирект с index.php (html) на главную страницу
  RewriteEngine on    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.(php|html|htm) HTTP/    RewriteRule ^(.*)index.(php|html|htm)$ $1 [R=301,L]  

 

  1. Редирект со слешем на без слеша
  RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} ![^/]$  RewriteRule ^(.*)/$ /$1 [R=301,L]  

 

  1. Редирект со страниц без слеша на слеш

  RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteRule ^(.*[^/])$ /$1/ [R=301,L]  

 

  1. Редирект всех страниц одного домена на главную другого домена
  RewriteCond %{REQUEST_URI} (.*)  RewriteRule ^(.*)$ http://site.ru/ [L,R=301]  

 

  1. Редирект с http на https через. htaccess
  RewriteCond %{HTTPS} !=on  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]  

 

  1. Редирект с https на http
  RewriteCond %{HTTPS} =on  RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]  

 

  1. Избавление от дублей страниц

Если вы заметили, что к адресу основной страницы приклеивается что-то вроде &sa=123 456 или &crw=123 456 и подобное, просто замените буквенную часть в следующем коде

  RewriteCond %{REQUEST_URI} ^(.*)&sa=  RewriteRule ^(.*)&sa=(.*)$ $1 [R=301,L]  

Пример: объясняем на пальцах

Как с помощью 301 редиректа сделать так, чтобы по запросу site.ru/category/art1/zapis/ в строке адреса было site.ru/zapis/, то есть /category/art1 вырезалась бы из строки, но после вырезания строки показывалось содержимое site.ru/category/art1/zapis/?

Легко:

    RewriteCond %{ENV:REDIRECT_STATUS} ^$  RewriteRule ^category/art1/zapis/$ http://%{HTTP_HOST}/zapis/ [R=301,L]  RewriteRule ^zapis/$ /category/art1/zapis/ [L]    

А теперь давайте подробнее разберем, что же тут написано и что вообще происходит.

Как известно mod_rewrit на apache постоянно просматривает список правил, пока URL можно хоть как-то изменить.
И не редко получаются бесконечные циклы.

Чтобы ограничить цикл выполнения правил одной итерацией, можно использовать конструкцию из первой строки. Она предает apache статус был ли выполнен редирект или нет и если да, то пропустить следующие правила. К слову, на nginx эта строка не нужна.

Вторая строка делает 301 редирект с www.site.ru/category/art1/zapis/ на www.site.ru/zapis/
Третья же строка говорит серверу, что если адрес вида www.site.ru/zapis/, то надо показывать то, что находится по адресу www.site.ru/category/art1/zapis/

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

 

 

  1. Принцип «от меньшему к большему»: располагайте редиректы от частных к более глобальны. Т. е. переадресация со страницы на страницу будет выше, чем переадресация с без www на www.
  2. Избегайте последовательных — двойных, тройных — редиректов. Один редирект перенаправляет пользователя только один раз.
  3. Проверьте HTTP заголовки и статусы ответа сервера, чтобы убедиться в правильности работы редиректа.

 

В заключении хотелось бы по пунктам огласить условиях при которых стоит и не стоит использовать .htaccess переадресацию.

 

Когда редирект необходим

  1. Вы переехали на другой домен: и вам логично не хочется потерять своих клиентов — настоящих и потенциальных, а также есть необходимость передать вес прошлого сайта на новый.
  2. Хотите склеить зеркала: у вас несколько доменных имён с разным написанием бренда и вы перенаправляете всех посетителей на основной сайт.
  3. Страница сменила свой адрес: структура вашего сайта была реорганизована и вы пытаетесь предотвратить возможный беспорядок.
  4. Хотите избавиться от дублей страниц или копии сайта: не стоит относится к дублям как чему-то безвредному и незначительному. С дублями вы теряете в весе и сдаете позиции конкурентам, а так же дублирование контента может привести к штрафам от поисковых систем.

 

 

В каких случаях не нужно использовать редирект?

  1. Вы временно переезжаете на новую страницу: для этого есть 302 и 307 код, это гарантия того, что не произойдёт склейки страниц и оригинальная страница не выпадет из поисковой выдачи.
  2. Вы переезжаете из-за проблем со старым доменом: если у вас есть баны, фильтры и штрафы, то при склейке к вам перейдет не только ТИЦ и PR, но и все беды, от которых вы бежали.

semantica.in

Советы

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

Старайтесь не делать редирект на страницу ответ которой отличен от кода 200. Т.е. редирект должен переадресовывать на существующую страницу с 200 ответом сервера.

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

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

Используется когда страница переехала с одного URL на другой. Например старый URL страницы /page-1/ необходимо сделать 301 редирект на URL http://mysite.com/new-page-1/

Redirect 301 /page-1/ http://mysite.com/new-page-1/  

или

RewriteCond %{REQUEST_URI} ^/page-1/$  RewriteRule ^.*$ http://mysite.com/new-page-1/? [R=301,L]  

301 редирект с www на домен без www

301 редирект домена с www на без www так же называется канонизацией домена или склейкой. Например делаем редирект с http://www.mysite.com на http://mysite.com, т.о. главное зеркало сайта это http://mysite.com

RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)$ http://%1/$1 [L,R=301]  

или

RewriteCond %{HTTP_HOST} ^www.mysite.com [NC]  RewriteRule ^(.*)$ http://mysite.com/$1 [R=301,L]  

301 редирект с домена без www на домен с www

Также как и в случае описанным выше это еще называется канонизацией домена или его склейкой. Например 301 редирект с домена http://mysite.com на домен http://www.mysite.com, т.е. главное зеркало это www.mysite.com

RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)$ http://www.%1/$1 [L,R=301]  

или

RewriteCond %{HTTP_HOST} ^mysite.com$ [NC]  RewriteRule ^(.*)$ http://www.mysite.com/$1 [R=301,L]  

301 редирект со страниц со слешем на страницы без слеша в конце URL

Часто бывает так что одна и та же страница доступна по двум URL, например /may-best-page и /my-best-page/, если человеку понятно что это одна и та же страница, то поисковые системы понимают это как две разные страницы, соответственно разбивают вес страницы, а также показываются в аналитике (статистике) как 2 разные страницы. Для того, что бы избежать этого вы можете сделать 301 редирект со страниц со слешем в конце URL на без него.

RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} ![^/]$  RewriteRule ^(.*)/$ /$1 [R=301,L]  

Такой редирект будет работать следующим образом:

Запрос (URL) Редирект (URL)
http://mysite/page/ http://mysite/page
http://mysite/page/?value=1 http://mysite/page?value=1
http://mysite/page.html/ http://mysite/page.html
http://mysite/page?value=1/ http://mysite/page?value=1
http://mysite/page без редиректа
http://mysite/page.html без редиректа
http://mysite/page?value=1 без редиректа

301 редирект со страниц без слеша на страницы со слешем в конце URL

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

RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteRule ^(.*[^/])$ /$1/ [R=301,L]  

Пример работы редиректа:

Запрос (URL) Редирект (URL)
http://mysite/page http://mysite/page/
http://mysite/page.html http://mysite/page.html
http://mysite/page?value=1 http://mysite/page/?value=1
http://mysite/page/ без редиректа
http://mysite/page/?value=1 без редиректа

301 редирект со всех страниц одного домена на главную страницу другого домена

К примеру вам необходимо сделать 301 редирект с любого URL текущего сайт (к которому относиться .htaccess) на домен http://mysite.com

RewriteCond %{REQUEST_URI} (.*)  RewriteRule ^(.*)$ http://mysite.com/ [L,R=301]  

301 редирект с каждой страницы одного домена на такой же URL адрес другого домена

Для примера рассмотрим ситуацию когда ваш сайт переехал на новый домен, но у вас есть естественное желание сохранить пользователей переходящих по старым ссылкам и открыть сайт на новом домене с нужной пользователю информацией

RewriteCond %{REQUEST_URI} (.*)  RewriteRule ^(.*)$ http://mysite.com/$1 [L,R=301]  

301 редирект с протокола http на протокол https

Если у вас на сайте есть SSL сертификат и работает протокол https, то для 301-го редиректа вам необходимо добавить в .htaccess следующий код:

RewriteCond %{HTTPS} !=on  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]  

301 редирект с протокола https на http

И обратный пример, если у вас нет SSL сертификата и протокол https не работает:

RewriteCond %{HTTPS} =on  RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]  

Удаляем несколько слешей подряд в URL и делаем 301 редирект

Если по случайности у вас появились URL такого вида: mysite.com/page///my-page, то можно сделать 301-й редирект без дублирования слешей:

RewriteCond %{REQUEST_URI} ^(.*)//(.*)$  RewriteRule . %1/%2 [R=301,L]  

Удаляем подряд несколько тире (дефисов) и делаем 301 редирект

Как в ситуации с повторяющимися слешами в URL может появиться несколько тире или дефисов, для 301-го редиректа с их удалением добавляем код:

RewriteCond %{REQUEST_URI} ^(.*)--(.*)$  RewriteRule . %1-%2 [R=301,L]  

Вырезать из URL index.php

Пример без GET параметров, например с mysite.com/index.php на mysite.com/

RewriteCond %{REQUEST_URI} /index.php  RewriteCond %{QUERY_STRING} ^z  RewriteRule ^(.*)$ http://mysite.ru/? [R=301,L]  

Пример с GET параметрами, например с mysite.com/index.php?value=1&p=3 на mysite.com/?value=1&p=3

RewriteCond %{REQUEST_URI} /index.php  RewriteRule ^(.*)$ http://mysite.ru/ [R=301,L]  

Несколько примеров совмещения 2-х редиректов в один

Для избежания последовательных редиректов можно использовать совмещенные варианты.

301 редирект с www на без www и со слешем в конце URL

Комбинируем 301 редирект с www на домен без www и 301 редирект со страниц без слеша на страницы со слешем в конце

RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)$ http://%1/$1/ [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} ![^/]$  RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)$ http://%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)$ http://%1/$1/ [L,R=301]  

301 редирект с без www на с www и со слешем в конце URL

Комбинируем 301 редирект с домена без www на домен с www и 301 редирект со страниц без слеша на страницы со слешем в конце URL

RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)$ http://www.%1/$1/ [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)$ http://www.%1/$1/ [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} ![^/]$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)$ http://www.%1/$1 [L,R=301]  

301 редирект с без www на с www и без слеша в конце URL

Комбинируем 301 редирект с домена без www на домен с www и 301 редирект со страниц со слешем на страницы без слеша в конце URL

RewriteCond %{REQUEST_URI} ^/$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)$ http://www.%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} /$  RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)/$ http://www.%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)$ http://www.%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} /$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)/$ http://www.%1/$1 [L,R=301]  

301 редирект с www на без www и без слеша в конце URL

Комбинируем 301 редирект с www на домен без www и 301 редирект со страниц со слешем на страницы без слеша в конце URL

RewriteCond %{REQUEST_URI} ^/$  RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)$ http://%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} /$   RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)/$ http://%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} !/$  RewriteCond %{HTTP_HOST} ^www.(.*)$  RewriteRule ^(.*)$ http://%1/$1 [L,R=301]    RewriteCond %{REQUEST_URI} !?  RewriteCond %{REQUEST_URI} !&  RewriteCond %{REQUEST_URI} !=  RewriteCond %{REQUEST_URI} !.  RewriteCond %{REQUEST_URI} /$  RewriteCond %{HTTP_HOST} ^([^www].*)$  RewriteRule ^(.*)/$ http://%1/$1 [L,R=301]  

кодер.укр

Канонизация или склейка домена

Для склейки домена с www на без www:

RewriteCond %{HTTP_HOST} ^www.site.com$ [NC]  RewriteRule ^(.*)$ http://site.com/$1 [R=301,L]

Для склейки домена с без www на с www:

RewriteCond %{HTTP_HOST} ^site.com$ [NC]  RewriteRule ^(.*)$ http://www.site.com/$1 [R=301,L]

Для правильного выбора метода склейки нужно рассмотреть такие факторы:

  • У какого варианта выше индексация;
  • У какого варианта выше позиции в выдаче;
  • Канонизация слэша в конце адреса.

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

  • http://www.site.com/category1
  • http://www.site.com/category1/

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

RewriteCond %{HTTP_HOST} (.*)  RewriteCond %{REQUEST_URI} /$ [NC]  RewriteRule ^(.*)(/)$ $1 [L,R=301]

или такой, чтобы добавить его:

RewriteCond %{REQUEST_FILENAME} !-f  RewriteCond %{REQUEST_URI} !(.*)/$  RewriteRule ^(.*[^/])$ $1/ [L,R=301]

Для редиректа 301 одной страницы на другую:

Redirect 301 /oldpage.html http://www.site.com/newpage.html

Чтобы убедиться, что при запросе любой версии главной страницы, к примеру: default.htm или index.html, будет произведен редирект на каноничную страницу http://www.site.com, нужно прописывать следующий код редиректа:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /([^/]+/)*(default|index|main).(html|php|htm) HTTP/ [NC]  RewriteRule ^(([^/]+/)*)(default|main|index).(html|php|htm)$ http://www.site.com/$1 [L,R=301]

Редирект каталога

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

RewriteRule ^(.*)/old-catalog/(.*)$ $1/new-catalog/$2 [R=301,L]

Но бывает так, что адрес старого каталога отображается сразу после доменного имени, например www.site.com/old-catalog/. В этом случае используется такой код:

RewriteRule old-catalog /(.*) / old-catalog /$1 [R=301,L]

Редирект при изменении расширения файлов

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

RedirectMatch 301 (.*).php$ http://www.site.com$1.html

Редирект при появлении нескольких слэшей или тире

По разным причинам бывает, что в адресе появляются лишние слэши или тире, например www.site.com/catalog////page-1.html. Такие страницы нужно переадресовывать на адреса с одним слэшем www.site.com/catalog/page-1.html.

RewriteCond %{REQUEST_URI} ^(.*)//(.*)$  RewriteRule . %1/%2 [R=301,L]

Таким же образом убираются и лишние тире в адресе, например изменение www.site.com/catalog/page—1.html на www.site.com/catalog/page-1.html.

RewriteCond %{REQUEST_URI} ^(.*)—(.*)$  RewriteRule . %1-%2 [R=301,L]

.htaccess — лишние слэши после имени домена

  • http://site.com//////catalog

Чтобы убрать все эти слэши так, чтобы было перенаправление на страницу без слэшей, т.е.

  • http://site.com/catalog

Нужно прописать:

RewriteCond %{REQUEST_URI} ^(.*)//(.*)$  RewriteRule . %1/%2 [R,L]

Генерация 301 редиректов

Если технических знаний для написания собственного кода не хватает, то есть специальные сервисы генерации всех основных редиректов:

  • http://www.webconfs.com/htaccess-redirect-generator.php
  • http://www.rapidtables.com/web/tools/redirect-generator.htm

Здесь вы можете, вставив свои данные, мгновенно получить нужный код. Поддерживаются редиректы для доменов, url адресов, каталогов.

Как проверить 301 редирект?

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

  • Проверить работает ли вообще сайт – зайти на его главную страницу;
  • Побродить по сайту, его разделам и отдельным страницам.

Но есть и сервисы для автоматической проверки редиректа:

  • http://bertal.ru – очень подробные данные обо всех откликах сервера
  • http://www.internetmarketingninjas.com/header-checker/

Правила использования 301 редиректа vs Canonical

Поисковая система Google устанавливает четкие правила, только при соблюдении которых, она будет верно трактовать ваши действия. Вот как буквально понимают поисковики 301 и Canonical:

  • 301 редирект – данная страница является устаревшей, новая страница находится по адресу такому-то. Прошу удалить старую страницу из индекса, а новую проиндексировать и полностью передать на нее весь вес старой.
  • Canonical – кроме этой версии страницы у меня есть еще и другие. Но ты, пожалуйста, индексируй только ту, на которой стоит Canonical. Другие версии будут лежать для того, чтобы их могли просматривать люди, но тебе включать их в индекс не нужно. Весь вес стоит передавать именно на страницу с Canonical.

Предпочтения по использованию редиректа 301

Обычно, это наиболее предпочтительный метод:

  • Для отдельных страниц – если навсегда изменился ее адрес;
  • Для доменов – если сайт будет находиться постоянно на новом домене;
  • Для страниц 404 и страниц с контентом, который более не актуален. К примеру, при удалении товара из каталога можно сделать редирект на похожий по функциям товар или на страницу каталога с этим типом товаров.

Когда лучше не использовать редирект 301

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

lucky-seo.com

Всем привет! Сегодня на SEO-Mayak.com довольна сложная и интересная тема. Многие, почти все начинающие блогеры даже понятия не имеют, что такое 301 редирект. Я как-то уже касался этой темы в статье про дубли контента и теперь мы рассмотрим ее поподробней.

Что такое 301 редирект? Это специальный код, который возвращает сервер при обращении к определенному URL.

Что это значит? Это значит, что если вы набрали в адресной строке браузера определенный URL, то Вас перенаправят на новый адрес.

Для чего это все нужно? Возьмем пример из реальной жизни. Заходите вы по определенному адресу, а вам говорят — «А здесь теперь такие не живут! Они совсем своим имуществом переехали на другую улицу и вот Вам их новый адрес…» Согласитесь полезная информация? Я не зря сказал — «…со все своим имуществом» т.е они не чего не оставили на старом адресе. Это важно!

redirekt 301

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

Прописываем 301 редирект в файле .htaccess

Чтобы выполнить сие действие надо в файле .htaccess прописать следующее:

Где «/» означает, что все начиная с «головы» сайта включая все подкаталоги будет переадресовано на новый адрес.

Не забудьте сделать резервную копию сайта если вдруг что-то пойдет не так!

Теперь рассмотрим другую ситуацию. У меня есть 2 квартиры, а живу я лишь в одной. Ко мне приходят письма по другому адресу, звонит телефон, заходят разные люди и т.д. А я забыл повесить объявления, что нахожусь я вообще в другом месте. Забавная история! Получается я теряю собственные авторитет в глазах окружающих из-за своей забывчивости.

Из этого вывод. Надо непременно указать поисковому роботу точный адрес проекта, например: www.сайт.com или просто сайт.com потому, что это два разных адреса.

Как это осуществить смотрите на этом примере:

Перенаправление с www на без www

Перенаправление с без www на с www

Надо заметить, что если в файле .htaccess уже прописана строчка RewriteEngine On, то ее повторять уже не надо и не забудьте вписать свой домен.

Существует мнение, что с защищенного протокола https:// также надо перенапралять пользователей на основной протокол http:// Я даже обратился в службу поддержки своего хостинг провайдера с этим вопросом. На что мне ответили, что возможность перенаправления есть и для этого в файле .htaccess необходимо прописать следующее:

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

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

До встречи!

С уважением, Виталий Кириллов

seo-mayak.com

Редирект .htaccess: постоянное перенаправление, 301

Подобная штука имеет разные названия. Непонятки может вызвать разве что число — почему же 301? Суть кроется в самом протоколе HTTP, который на запросы клиента отвечает определённым кодом состояния. Код 404 Not Found (Страница не найдена) известен почти всем. Код 200 OK почти не известен, но именно он означает, что всё в порядке и документ будет показан в браузере. А вот код 301 Moved Permanently означает, что документ окончательно перебрался на новый адрес. Именно его и называют чаще всего перенаправлением, хотя общий пул ответов обозначен как — 3xx: Redirection.

В общем случае, для безусловного внешнего (назовём его пользовательским) редиректа, при котором браузер автоматически переадресовывается на другую страницу, обычно незаметно для пользователя (изменяется адресная строка), можно в .htaccess поместить такой код:
RewriteEngine On
RewriteRule .* http://newsite.ru/ [L,R=permanent]

Здесь, первая строка включает механизм модуля mod_rewrite, который позволяется вытворять с адресами всё, что угодно. Назовём это преобразованием URL по условиям на лету. Вторая строка определяет непосредственно правило для преобразования, в примере выше все запросы редиректятся на http://newsite.ru/. В квадратных скобках размещаются флаги: L — последнее (Last) правило, R — тип перенаправления (Redirect), указывается в виде R=code, где code — буквенное или числовое обозначение (permanent или 302).

Этот способ хорош, когда вам неважно, на какую страницу нового сайта ссылаться. Но если вы переехали на другой домен, то желательно делать редиректы всех запросов с сохранением адресов. Для этого используйте такой код:
RewriteRule ^.*$ http://newsite.ru/$0 [QSA,L,R=permanent]
Новый флаг QSA сохранит так же и параметры, которые можно встретить в адресах после знака вопроса. В уже знакомом примере:

https://a-panov.ru/?p=389

если я размещу в .htaccess код выше, то произойдёт перенаправление на адрес http://newsite.ru/?p=389 чего без данного флага не было бы.

Как настроить редирект на www (или без www)

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

Вариант попроще, для одного домена. Перенаправление производится с поддомена www.site.ru на site.ru:
RewriteCond %{HTTP_HOST} ^www.nsite.ru$
RewriteRule .* http://nsite.ru/$0 [QSA,L,R=permanent]

Здесь появилась новая директива RewriteCond, которая задаёт условие, при котором должны срабатывать редиректы — правила RewriteRule. Условие, в данном случае, имя домена, соответствующее www.nsite.ru (в регулярных выражения символ точки означает «любой символ», поэтому его желательно экранировать с помощью обратного слеша).

Обратное перенаправление тоже выполнить очень просто:
RewriteCond %{HTTP_HOST} ^nsite.ru$
RewriteRule .* http://www.nsite.ru/$0 [QSA,L,R=permanent]

Оба варианта рабочие, но у них есть маленький минус — для каждого нового конфига необходимо заменять домен nsite.ru на свой собственный. Нельзя ли сделать уникальный вариант? Легко!

Редирект с любого поддомена www:
RewriteCond %{HTTP_HOST} ^www.(.*)$
RewriteRule .* http://%1/$0 [QSA,L,R=permanent]

Редирект на поддомен с www:
RewriteCond %{HTTP_HOST} !^www.
RewriteRule .* http://www.%{HTTP_HOST}/$0 [QSA,L,R=permanent]

Как создать .htaccess

Такие вопросы тоже возникают. Проблема в том, что стандартный Проводник (приложение в Windows, отвечающее за графический интерфейс) не позволяет создавать файлы, начинающиеся с точки (созданием файлов или папкок осуществляется щелчком правой кнопкой на рабочем столе или в окне, и выбора нужного действия из списка Создать). Но выход есть: открывайте стандартный рекдатор Notepad (блокнот), в меню выбираете Файл → Сохранить как…, и в качестве имени сохраняемого файла указываете .htaccess — после этого он будет создан.

Файл .htaccess не работает

Бывают случаи, когда директивы из файла не работают. Обычно это вызвано тем, что в конфигурации Apache отключена поддержка .htaccess, за что отвечает директива:
AllowOverride none

Обычно это делается, чтобы несколько увеличить быстродействие — в этом случае веб-сервер не производит поиск и разбор .htaccess.

Возможен и такой вариант, что на сервере не используется Apache, например, IIS — основной «гость» на Windows-хостинге. Для уточнения свяжитесь с поддержкой своего хостера.

Есть ли какой-нибудь аналог .htaccess в nginx?

Ещё один довольно частый вопрос. В этом веб-сервера такой возможности нет. Однако, подобное обычно и не требуется. Дело в том, что nginx, как правило, устанавливается в качестве фронденда, т. е. принимает и обрабатывает все запросы, которые либо выполняет сам, либо перенаправляет на бэкенд, роль которого может выполнять Apache, который можно дополнительно конфигурировать с помощью .htaccess.

a-panov.ru

Директивы модуля Mod_rewrite

  • RewriteBase
  • RewriteCond
  • RewriteEngine
  • RewriteLock
  • RewriteLog
  • RewriteLogLevel
  • RewriteMap
  • RewriteOptions
  • RewriteRule

Варианты реализации Редиректа с помощью файла .htaccess

  1. Простой редирект:
    Redirect 301 / http://www.domainname.ru/  

    или

    redirect /secret http://www.site.ru/nosecret  

    Ставится в файле .htaccess или httpd.conf для Apache. Первый «/» означает, что всё с верхнего уровня сайта, включая все подкаталоги, будет переадресовано (не забывайте поставить последний «/»). Если Вы хотите переадресовать только страницу, сохранив PR старой страницы, можно сделать так:

    Redirect 301 /old/old.htm http://www.you.ru/new.htm где:
    /old/old.htm — путь и имя старой страницы
    http://www.you.com/new.htm — новый путь и новое имя перемещенной страницы

  2. Редирект на любую страницу по ip пользователя или при запросе конкретной страницы (а также по маске имени).
    Если у пользователя ip 192.152.37.125, то он будет перенаправлен на страницу user.php:
    SetEnvIf REMOTE_ADDR 192.152.37.125 REDIR="redir"  RewriteCond %{REDIR} redir  RewriteRule ^/$ /user.php  
  3. Редирект при запросе определённых файлов. Если запрашиваются файлы, расширение которых не указано в файле .htaccess (gif и jpg), то следует перенаправление:
    RewriteEngine On  RewriteRule !.(gif|jpg)$ index.php  
  4. Использование mod_rewrite:
    Options +FollowSymLinks   RewriteEngine on   RewriteCond %{HTTP_HOST} ^yourdomain.ru   RewriteRule ^(.*)$ http://www.yourdomain.ru/$1 [R=permanent,L]  
  5. Редирект с регулярным выражением:
    RedirectMatch 301 (.*) http://www.yourdomain.ru$1 Прописывается в файле .htaccess.   

    (.*) RedirectMatch фактически соответствует регулярным образцам выражения после доменного имени. Таким образом, нельзя выполнить соответствие образца на ^/yourdomain.ru. Однако, можно преобразовать страницы с использованием .html расширения к файлам того же самого названия, но с .php расширением:

    RedirectMatch 301 (.*).html$ http://www.yourdomain.ru$1.php  

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

    RedirectMatch Permanent ^/html/resources.html$ http://www.newdomain.com/resources.php   RedirectMatch Permanent ^/html/other_page.html$ http://www.newdomain.com/other_page.php   RedirectMatch Permanent ^/(.*)$ http://www.newdomain.com/   

    «RedirectMatch Permanent» — это эквивалент «RedirectMatch 301», строка с «*(Wildcard)» должна быть последней в этом списке.

  6. Создание удобо читаемых URL
    Чтобы преобразовать, например, www.site.ru/product.php?id=123 в www.site.ru/product/123 следующим образом:
    RewriteEngine on  RewriteRule ^product/([^/.]+)/?$ product.php?id=$1 [L]  

    В следующем примере преобразуем www.site.ru/script.php?product=123 в www.site.ru/cat/product/123/:

    RewriteRule cat/(.*)/(.*)/$ /script.php?$1=$2  
  7. Редирект на PHP:
    header("HTTP/1.1 301 Moved Permanently");   header("Location: http://www.newdomain.ru/newdir/newpage.htm");   exit();   

    Естественно, надо создать страницу, при обращении к которой и будет происходить Редирект, и разместить её на сервере. И лучше укажите HTTP/1.1 (а не HTTP/1.0 или HTTP/0.9, которые не поддерживают виртуальный хостинг)

  8. Редирект всех файлов в папке на один файл.
    Например вы больше не нуждаетесь в разделе сайта Super discount и хотите перенаправить все запросы к папке /superdiscount на один файл /hot-offers.php. Для этого добавляем в .htaccess следующий код.
    RewriteRule ^superdiscount(.*)$ /hot-offers.php [L,R=301]  
  9. Редирект всей папки кроме одного файла
    В следующем примере все файлы из папки /superdiscount будут редиректится на на файл /hot-offers.php, КРОМЕ файла /superdiscount/my-ebook.html котоый должен редиректится на /hot-to-make-million.html
    RewriteRule ^superdiscount/my-ebook.html /hot-to-make-million.html [L,R=301]  RewriteRule ^superdiscount(.*)$ /hot-offers.php [L,R=301]  
  10. Редирект динамического URL на новый файл.
    Данный вариант пригодится если вы хотите редиректить динамический URL с параметрами на новый статический файл.
    RewriteRule ^article.jsp?id=(.*)$ /latestnews.htm [L,R=301]  

    То есть теперь, запрос к файлу вида http://www.kass.ws/article.jsp?id=8632 и/или http://www.kass.ws/article.jsp?id=1245 будет отправлен на файл http://www.kass.ws/latestnews.htm.

  11. Массовый редирект новых файлов.
    Тепепь перейдем к самому сложному моменту, когда вам надо редиректить массу URL-ов, например после смены вашей CMS. Тут сразу возникает ряд проблем. Во-первых, внесение всех изменившихся адресов в .htaccess файл займет очень много времени, да и само по себе занятие малоприятное. Во-вторых, слишком много записей в .htaccess файле будут тормозить Apache сервера. И в третьих, при внесении такого количества информации высока вероятность, что вы где то ошибетесь. По этому, самый лучший выход, это нанять програмиста который вам напишет динамический редирект.
    Нижеприведенный пример написан на PHP, но так же может быть выполнен на любом языке. Предположим вы перешли на новую систему ссылок на вашем сайте и все файлы оканчивающиеся на старый id должны быть средирекчены. Сначала создаем в базе таблицу, которая содержит старый id и новый URL для редиректа. old_id INT new_url VARCHAR (255) Далее пишем код который свяжет ваши старые id с новыми URL-ами
    После этого, добавляем следующую строчку в .htaccess:
    RewriteRule ^/product-(.*)_([0-9]+).php /redirectold.php?productid=$2  

    затем создаем PHP файл redirectold.php, который будет поддерживать 301 редирект:

    <?php  function getRedirectUrl($productid) {  // Connect to the database  $dServer = "localhost";  $dDb = "mydbname";  $dUser = "mydb_user";  $dPass = "password";    $s = @mysql_connect($dServer, $dUser, $dPass)  or die("Couldn't connect to database server");    @mysql_select_db($dDb, $s)  or die("Couldn't connect to database");    $query = "SELECT new_url FROM redirects WHERE old_id = ". $productid;  mysql_query($query);  $result = mysql_query($query);  $hasRecords = mysql_num_rows($result) == 0 ? false : true;  if (!$hasRecords) {  $ret = 'http://www.yoursite.com/';  } else {  while($row = mysql_fetch_array($result))  {  $ret = 'http://www.yoursite.com/'. $row["new_url"];  }  }  mysql_close($s);  return $ret;  }    $productid = $_GET["productid"];  $url = getRedirectUrl($productid);    header("HTTP/1.1 301 Moved Permanently");  header("Location: $url");  exit();  ?>  

    Теперь все запросы к вашим старым URL-ам будут вызывать redirectold.php, который найдет новый URL и вернет 301 ответ с вашей новой ссылкой.

    Редиректы в зависимости от времени

    Когда нужно применять уловки типа содержания зависящего от времени масса вебмастеров все ещё используют CGI скрипты которые производят редиректы на специальные страницы. Как это может быть сделано через mod_rewrite?

    Есть много переменных названных TIME_xxx для условий редиректа. В связке со специальными лексикографическими образцами для сравнения <STRING, >STRING и =STRING мы можем производить редиректы зависящие от времени:

     RewriteEngine on   RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700   RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900   RewriteRule ^foo.html$ foo.day.html   RewriteRule ^foo.html$ foo.night.html  

    Это выдает содержимое foo.day.html при запросе URL foo.html с 07:00 до 19:00 а в оставшееся время содержимое foo.night.html.

  12. Убираем у всех запросов вначале «WWW.»
    RewriteEngine on # оглашаем, что хотим использовать mod_rewrite  RewriteCond %{HTTP_HOST} ^www.(.*) [NC]  RewriteRule ^/?(.*) http://%1/$1 [L,R=permanent]  
  13. Меняем расширение .html на .php
    Иногда бывает так, что у Вас статичный веб-сайт, а Вам необходимо, чтобы на нем срабатывал какой-нибудь php-скрипт. Для этого Вам необходимо сказать серверу, чтобы он обрабатывал эту страницу как php-файл.
    AddHandler application/x-httpd-php .html  

    Этот прием можно использовать и для других расширений файлов:

    AddHandler application/x-httpd-php .xml  AddHandler application/x-httpd-php .asp  

Запрещение доступа в конкретную директорию

  1. для всех ко всем файлам в директории:
    deny from all  
  2. к конкретному файлу:
    <Files secret.php>  deny from all  </Files>  
  3. по ip пользователя:
    order deny,allow  deny from all  allow from 192.152.37.125  

    Доступ в данную директорию будет разрешён только пользователю с ip 192.152.37.125.

  4. Директива Options -Indexes — запрет на отображение содержимого каталога при отсутствии индексного файла Иногда нужно сделать так, чтобы в случае отсутствия в каталоге файла, который показывается по умолчанию, не выдавался список файлов в каталоге. Тогда можно добавить в .htaccess такую строчку :
    Options -Indexes  

    В этом случае вместо списка файлов в каталоге посетитель получит HTTP ошибку 403 — access forbidden.

  5. Запретить доступа к файлам с несколькими типа расширений &lt;Files ~ «.(inc|conf|cfg)$»&gt; deny from all &lt;/Files&gt; Запрещен доступ к файлам с расширением *.inc, *.conf и *.cfg. Хотя директива, по умолчанию, не работает с регулярными выражениями, но их можно включить поставив символ тильды(~) в опциях директивы. Синтаксис следующий: [тильда] [пробел] [далее_все_без_пробелов] Чтобы блокировать этот доступ, запишем следующее:
     RewriteRule ^.htaccess$ - [F]  

    Это правило переводится так:
    Если кто-то пробует обращаться к файлу .htaccess, система должна произвести код ошибки ‘HTTP response of 403’ или ‘403 Forbidden — You don’t have permission to access /.htaccess on this server’.

    Конструкция ^.htaccess$ в этом регулярном выражении означает:
    ^ — якорь начала строки
    $ — якорь конца строки
    . — в регулярных выражениях точка ‘.’ обозначает мета-символ и должна быть защищена обратным слэшем (backslash), если Вы все-таки хотите использовать именно фактическую точку.

    Имя файла должно быть расположено точно между начальным и конечным якорем. Это будет гарантировать то, что только это определенное имя файла и никакое другое, сгенерирует код ошибки.
    [F] — специальный ‘запрещающий’ флажок (forbidden).
    [NC] — не учитывать регистр букв.
    [OR] — означает ‘или следующее условие’.

Определение кодировки

Определение кодировки, в которой сервер «отдает» файлы

AddDefaultCharset windows-1251  

варианты: KOI8-R, UTF-8, Windows-1251

Определение кодировки на загружаемые файлы

CharsetSourceEnc windows-1251  

Установка пароля на директорию с помощью .htaccess

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

AuthType Basic  AuthName "Some Name"  AuthUserFile /www/some_login/www/htdocs/some_dir/.htpasswd  require valid-user  

Путь /www/some_login/www/htdocs/some_dir/.htpasswd обозначает полный путь к файлу паролей на диске нашего сервера. Если, например, вы поместите файл .htpasswd (в нем будут пароли) в домашний каталог, куда вы попадаете, зайдя на сервер по FTP, то путь к этому файлу будет иметь вид /www/some_login/www/htdocs/some_dir/.htpasswd, где some_login — Ваш логин. В директиве AuthUserFile указываем абсолютный путь к файлу с логинами/паролями, который мы создадим чуть позже. Если вы создаете файл .htaccess на своем компьютере, а не сразу на сервере используя текстовый редактор, обратите особое внимание на то, что .htaccess должен передаваться по FTP строго в текстовом (ASCII) режиме.

Создаем файл паролей. Файл с паролями должен содержать строки вида login:password. Пароль должен быть зашифрован с использованием алгоритма MD5. Один из способов создать такой файл — воспользоваться программой, входящей в поставку Apache — htpasswd (на нашем сервере она находится в каталоге /usr/local/apache/bin, полный путь — /usr/local/apache/bin/htpasswd).

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

htpasswd -mbc .htpasswd user1 7B1safkir  

— создаем новый файл .htpasswd, в который добавляем запись для пользователя user1 с паролем, указанным в командной строке.

htpasswd .htpasswd user2  

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

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

Задаем собственные страницы ошибок

Задать собственную страницу ошибок можно следующим образом:

ErrorDocument 404 http://www.site.ru/404.php  

IE игнорирует страницы размером меньше 512 байт.

Индексация директорий и поддиректорий

Чтобы избежать индексации поисковыми системами директорий и поддиректорий, необходимо прописать такую строку, к примеру:

DirectoryIndex index.php  

Эта директива задает файл, который будет вызван при обращении к директории без указания имени файла.

Можно указать несколько индексных страниц. При запросе каталога они будут искаться в том порядке, в котором перечислены в директиве DirectoryIndex. Если не будет найден файл index.html, то будет произведен поиск файла index.php и т.д.

DirectoryIndex index.html index.php index.shtml  

Лично я предпочитаю переадресовывать с пустых директорий либо на главную страницу сайта, либо на какую-либо другую подходящую страницу. Например, директорию www.site.ru/pic/ можно переадресовать на www.site.ru.

Защита изображений от скачивания

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

RewriteEngine on  RewriteCond %{HTTP_REFERER} .  RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?site. [NC]  RewriteCond %{HTTP_REFERER} !google. [NC]  RewriteCond %{HTTP_REFERER} !search?q=cache [NC]  RewriteCond %{HTTP_REFERER} !msn. [NC]  RewriteCond %{HTTP_REFERER} !yahoo. [NC]  RewriteCond %{REQUEST_URI} !^/hotlinker.gif$  RewriteRule .(gif|jpg|png)$ /hotlinker.gif [NC,L]  

hotlinker.gif — изображение, которое будет отображаться, вместо истинных изображений. Рекомендую в этом изображении отобразить Ваш логотип и ссылку на Ваш сайт.

Еще один варинат запрета доступа к картинкам с неразрешенных сайтов:

SetEnvIfNoCase Referer "^$" local_ref=1  SetEnvIfNoCase Referer "^http://(www.)?htmlweb.ru" local_ref=1  SetEnvIfNoCase Referer "^http://(www.)?images.yandex.ru" local_ref=1  SetEnvIfNoCase Referer "^http://(www.)?hghltd.yandex.com" local_ref=1  <FilesMatch ".(jpg|gif|png)">   Order Allow,Deny   Allow from env=local_ref  </FilesMatch>   

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

RewriteCond %{HTTP_USER_AGENT} (Googlebot|Slurp|spider|Twiceler|heritrix|  	Combine|appie|boitho|e-SocietyRobot|Exabot|Nutch|OmniExplorer|  	MJ12bot|ZyBorg/1|Ask Jeeves|AskJeeves|ActiveTouristBot|  	JemmaTheTourist| agadine3|BecomeBot|Clustered-Search-Bot|  	MSIECrawler|freefind|galaxy|genieknows|INGRID|grub-client|  	MojeekBot|NaverBot|NetNose-Crawler|OnetSzukaj|PrassoSunner|  	Asterias Crawler|T-H-U-N-D-E-R-S-T-O-N-E|GeorgeTheTouristBot|  	VoilaBot|Vagabondo|fantomBro wser|stealthBrowser|cloakBrowser|  	fantomCrew Browser|Girafabot|Indy Library|Intelliseek|Zealbot|  	Windows 95|^Mozilla/4.05 [en]$|^Mozilla/4.0$) [NC]  RewriteRule ^(.*)$ - [F]  #  RewriteCond %{HTTP_USER_AGENT} ^Mozilla.* [NC,OR]  RewriteCond %{HTTP_USER_AGENT} ^Opera.* [NC,OR]  RewriteCond %{HTTP_USER_AGENT} ^Firefox.* [NC,OR]  RewriteCond %{HTTP_USER_AGENT} ^Netscape.* [NC]  RewriteRule ^(.*)$ - [L]  RewriteRule ^(.*)$ - [F]  

Отслеживание обращений к файлу robots.txt

Чтобы иметь больше информации о посещении поисковиков, полезно иметь подробную информацио об обращении к файлу robots.txt Для того, чтобы оганизовать это, в ‘.htaccess’ должны быть следующие записи:

 RewriteEngine on   Options +FollowSymlinks   RewriteBase /   RewriteRule ^robots.txt$ /robot.php?%{REQUEST_URI}  

Теперь при запросе файла ‘robots.txt’ наш RewriteRule переадресует посетителя (робота) к обрабатывающему запросы скрипту robot.php. Кроме того, переменная передается скрипту, которая будет обработана в соответствии с вашими нуждами. ‘REQUEST_URI’ определяет имя запрашиваемого файла. В данном примере это — ‘robots.txt’. Скрипт прочтет содержание ‘robots.txt’ и отправит его web-браузеру или роботу поискового сервера. Таким образом, мы можем считать хиты посетителей и вести лог-файлы.

PHPSESSID

Для отключения добавления PHPSESSID к URL вставьте в начало index.php:

ini_set("session.use_trans_sid", 0);  

 

Либо в .htaccess пропишите:

php_flag session.use_trans_sid Off  

Директивы кеширования

Кэширование для всех типов файлов по времени доступа

ExpiresActive on  ExpiresDefault "access plus 600 seconds"  

Кэширование для всех типов файлов по времени изменения

ExpiresActive on  ExpiresDefault "modification plus 600 seconds"  

Кэширование для определённых типов файлов

ExpiresByType text/css "modification plus 600 seconds"  ExpiresByType image/jpeg "modification plus 600 seconds"  ExpiresByType image/gif "modification plus 600 seconds"  ExpiresByType image/x-ico "modification plus 600 seconds"  ExpiresByType image/png "modification plus 600 seconds"  

Запрет кеширования с помощью сервера Apache

Откройте файл конфигурации сервера Apache httpd.conf и раскомментируйте следующие строчки:

LoadModule expires_module modules/mod_expires.so  LoadModule headers_module modules/mod_headers.so   ...  AddModule mod_expires.c  AddModule mod_headers.c  

Впишите в .htaccess следующее:

# Запрещение кеширования в этой папке # Необходимо включение модулей # mod_headers.c и mod_expires.c # # Заголовок Cache-Control &lt;IfModule mod_headers.c&gt; Header append Cache-Control «no-store, no-cache, must-revalidate» &lt;/IfModule&gt; # Заголовок Expires &lt;IfModule mod_expires.c&gt; ExpiresActive On ExpiresDefault «now» &lt;/IfModule&gt;

Необходимые заголовки будут передаваться автоматически, и специально их писать в PHP уже не нужно — кэш уже выключен!

Описание http-заголовка кеширования Cache-control

Кеширование с помощью файла .htaccess

# Разрешение кеширования в этой папке # Необходимо включение модулей # mod_headers.c и mod_expires.c # # Заголовок Cache-Control &lt;IfModule mod_headers.c&gt; Header append Cache-Control «public» &lt;/IfModule&gt; # Заголовок Expires &lt;IfModule mod_expires.c&gt; ExpiresActive On ExpiresDefault «access plus 1 hours» #ExpiresDefault «access plus 10 years» &lt;/IfModule&gt;

Кеширование javascript файлов с помощью файла .htaccess

&lt;FilesMatch .*.js$&gt; ExpiresDefault «access plus 3 days» &lt;/FilesMatch&gt;

Будьте осторожны при кешировании, т.к. при изменении файла, пользователь может получить новый вариант только через 3 дня!

Как заставить html-страницы обрабатывать php-код?

Пропишите в своем файле .htaccess следующие строки:

RemoveHandler .php .htm .html  AddHandler application/x-httpd-php .php .htm .html  

Как разместить несколько сайтов на одном виртуальном хостинге?

Чтобы разместить два или более сайтов на одном виртуальном хостинге, вопреки отведенному вам тарифным планом количеству доменов необходимо в файле «.htaccess» прописать следующие строки:

RewriteEngine On  RewriteRule ^newdirectory/ - [L]  RewriteCond %{HTTP_HOST} (www.)?newdomain.ru [NC]  RewriteRule (.*) newdirectory/$1 [L]  

Где:
newdirectory/ — папка, в которой будет лежать второй сайт
newdomain.ru — домен, для которого мы делаем перенаправление

Обратите внимание, что при этом у Вас будет единый почтовый аккаунт. Т.е. если, у Вас существует ящик Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript , то после подключения домена newdomain.ru у ящика Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript появляется второе имя — Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript . А при создании любого нового ящика (например info), ему автоматически присваиваются два имени — Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript и Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript .

Поиск страниц больше чем в одном каталоге

Иногда необходимо позволить веб-серверу искать страницы больше чем в одном каталоге.

RewriteEngine on    # во-первых попытаемся найти это в указанном месте/...  # ...и если нашли то заканчиваем поиск:  RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f  RewriteRule ^(.+) /your/docroot/dir1/$1 [L]    # во-вторых - попытаемся найти это в pub/...  # ...и если нашли то заканчиваем поиск:  RewriteCond /your/docroot/dir2/%{REQUEST_FILENAME} -f  RewriteRule ^(.+) /your/docroot/dir2/$1 [L]    # иначе продолжаем для других директив  RewriteRule ^(.+) - [PT]  

 

Виртуальные хосты пользователей

Если Вы хотите предоставлять адреса www.subdomain.domain.ru для страниц пользователей, Вы можете использовать следующий набор правил для преобразования http://www.subdomain.domain.ru/path во внутренний путь /home/subdomain/path:

RewriteEngine on  RewriteCond %{HTTP_HOST} ^www.[^.]+.ru$  RewriteRule ^(.+) %{HTTP_HOST}$1 [C]  RewriteRule ^www.([^.]+).ru(.*) /home/$1$2  

 

Повреждаются файлы при загрузке на сервер

Если при передаче файлов через формы (при указанном enctype=»multipart/form-data») бинарные данные повреждаются, пропишите в /cgi-bin/.htaccess директиву:

CharsetRecodeMultipartForms Off.  

 

Ошибка загрузки SWF файлов.
Ошибки при обращении к страницам, содержащим ключевые слова,
типа $_REQUEST

Такое может происходить из-за установленного модуля <mod_security> в Apache. По умолчанию он блокирует в запросах строки с SQL аргументами и другими потенциально опасными командами.

Возможные сообщения об ошибке:

или

Добавьте в .htaccess &lt;IfModule mod_security.c&gt; SecFilterEngine Off SecFilterScanPOST Off &lt;/IfModule&gt; Для сообщения:

можно снять защиту только на загрузку файлов на сервер: &lt;IfModule mod_security.c&gt; &lt;Files async-upload.php&gt; SecFilterEngine Off SecFilterScanPOST Off &lt;/Files&gt; &lt;/IfModule&gt;

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

lred.ru


You May Also Like

About the Author: admind

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

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

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector