Как поставить редирект на страницу. Избавляемся от параметров или меток в адресе. Редирект URL-адресов с помощью JavaScript

09.02.2019

Skype

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

Понятие редиректа

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

Для чего он требуется?

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

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

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

Навязывание ненужной рекламы.

Увеличение посещений того или иного Интернет-ресурса. Такой редирект, который перенаправляет пользователя вместо искомого сайта на другой (например, рекламный), используется для накрутки счетчиков.

Так называемые реферальные ссылки.

Типы

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

300 — выбор одного варианта из нескольких. Чаще всего используется автоматически для выбора нужного языка или кодировки.
301 — перемещение навсегда. Как раз такой вид переадресации используется при переезде сайта.
302 — временный редирект. Используется для временной переадресации юзеров и поисковых систем с одного адреса на другой.
303 — ресурс, который запрашиваете, находится по другому адресу. Следует отметить, что такой редирект используется поисковыми системами: когда результатом поиска является всего одна страница, юзера сразу перенаправляют на нее.
305 - используйте прокси. Доступ к документу с таким типом редиректа доступен только с использованием прокси-сервера.
307 - еще один временный редирект.

Редирект с кодом 304 указывает на то, что наполнение страницы осталось прежним, а 306 код припасен на возможные будущие нужды.

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

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

Переадресацию можно настроить несколькими способами. Рассмотрим каждый из них отдельно.

Настройка переадресации через htaccess. Это, пожалуй, самый простой и распространенный способ организовать перенаправление с одного сайта (или страницы) на другой. Чтобы воспользоваться этим методом, необходимо в папке сайта создать файл и назвать его.htaccess, имя файла должно начинаться именно с точки. У пользователей CMS и Joomla такой файл уже имеется, создавать его специально нет необходимости.

В том случае, когда Интернет-ресурс написан не на CMS, нелишним будет знать, как сделать редирект через PHP . Но для этого нужно разбираться в структуре вашего Интернет-ресурса.

Редирект HTML используется в случае, когда необходимо сделать переадресацию одной или нескольких статей сайта, написанного на HTML. Настройка редиректа всего сайта этим способом займет длительное время.

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

Примеры

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

Redirect /page-А.html /page-В.html - перенаправление со страницы А на страницу В.
Redirect / http://site2.ru/ - переадресация на сайт2.

Чтобы "склеить" домены, в файл.htaccess, необходимо добавить следующие строки:

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

Редирект на php будет выглядеть так:

- перенаправление на сайт А;
- редирект на страницу А.

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

Перенаправление будет происходить на сайт А. В данном метатеге можно регулировать время перенаправления. Если установить значение, отличное от нуля, то редирект будет происходить через указанное время.
- перемещение на страницу А сайта А произойдет через 10 секунд.

Через JavaScript . Перенаправление посетителя на сайт А:

location="http://siteA.ru"

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

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

(с англ. redirect) - процесс переориентировки определенных страниц или всего сайта целиком на новый URL-адрес.

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

К некоторым редиректам поисковики относятся насторожено. Из-за этого показатели сайта могут существенно упасть, но подобная тенденция не касается переадресации под кодом «301».

Виды редиректов страниц и их назначение

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

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

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

Также существуют следующие виды редиректов:

307 (Temporary Redirect) - временная смена URL страницы, с сохранением начального адреса в индексе поисковиков;
306 - зарезервирован под использование, но пока не применяется;
305 (Use Proxy) обозначает переадресацию сначала на , а затем по повторному автоматическому запросу на искомую страницу;
304 (Not Modified) - ответ сервера браузеру в случае, если с момента последнего запроса просмотренный браузером документ не изменился. Тогда браузер открывает пользователю этот документ из кеша;
303 (See Other) - в переводе означает «смотри другое». Этот редирект информирует о найденном документе и перенаправляет пользователя на искомую страницу, используя метод GET (передает данные серверу через URL);
300 (Multiple Choices) обозначает многовариантный выбор страницы, на которую перенаправить пользователя. Например, в зависимости от настроек браузера пользователя, поисковик перенаправит его на страницу с подходящими языковыми настройками или .

Возможности редиректа 301

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

Он поможет:

«склеить» два сайта в один;
перенести показатели ТИЦ старого сайта и PR его страниц на новый адрес;
сфокусировать выдачу определенного сайта в результатах поиска, без учета в URL-адресе наличия или отсутствия «www»;
добавить или удалить слеши в ссылке;
перенаправить с одного файла на другой при смене его расширения и т.д.

Процесс «склейки» двух доменов осуществляется путем создания кода редиректа 301. Для этого в корневой папке сайта необходимо найти файл с расширением и прописать в нем специальный код. Также потребуется настроить зеркала сайта - указать в файле robots.txt, какой из сайтов главный. Это делается при помощи команды host.

С www на без www RewriteCond %{HTTP_HOST} ^www.site\.com$ RewriteRule ^(.*)$ http://site.com/$1 с без www на с www RewriteCond %{HTTP_HOST} ^site\.com$ RewriteRule ^(.*)$ http://www.site.com/$1

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

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

Наличие или отсутствие в адресе сайта символа «слеша» в конце, так же, как и «www» в его начале, имеет значение для индексации поисковиками.

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

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

Удаление слеша RewriteCond %{HTTP_HOST} (.*) RewriteCond %{REQUEST_URI} /$ RewriteRule ^(.*)(/)$ $1 Добавление слэша RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} !(.*)/$ RewriteRule ^(.*[^/])$ $1/

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

Склеить слеши RewriteCond %{REQUEST_URI} ^(.*)//(.*)$ RewriteRule . %1/%2 Склеить дефисы RewriteCond %{REQUEST_URI} ^(.*)--(.*)$ RewriteRule . %1-%2

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

Redirect 301 /page.html http://www..html

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

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

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

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

Иногда возникает необходимость на новый домен. Чтобы сделать это не потеряв показатели ТИЦ и PR, а также сохранив ссылочную массу и объем страниц, следует прописать редирект 301 для каждой из страниц старого сайта. В корневой папке старого сайта в файле robots.txt проставляется директива host, которая указывает на адрес нового домена.

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

Для генерации редирект-кодов существуют специальные онлайн-сервисы. При недостаточном количестве знаний или опыта каждый веб-программист сможет воспользоваться такой помощью. Также посредством использования онлайн-генератора можно выявить ошибку в коде, созданном самостоятельно.
Наиболее популярными площадками, предлагающими услуги генерации редиректов, являются:
http://www.rapidtables.com/web/tools/redirect-generator.htm

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

Целесообразность использования 301-ого редиректа

Помимо редиректа 301 для взаимодействия сайта с поисковиками разработан также тег rel=canonical. Он несколько созвучен с редиректом 301, но подразумевает под собой не окончательное перемещение страницы на новый адрес, а доминирование данного адреса страницы над остальными возможными его копиями на сайте. При этом страницы-клоны остаются доступными для просмотра, но не подлежащими индексации. «301» же подает сигнал поисковикам удалить все старые и неверные адреса полностью.

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

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

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

Код статуса 301 означает, что запрашиваемая страница окончательно перемещена в новое местоположение.

На самом деле существует несколько редиректов. О том как сделать 301 редирект можно посмотреть на инфографике.

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

Использовать переадресацию 301 особенно удобно в следующих случаях:

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

Для передачи новому домену Page Rank и тИЦ.

Для сохранения поискового трафика.

Пользователи могут получить доступ к сайту, используя несколько различных URL-адресов. Например, попасть на страницу можно несколькими способами: //site.ru/sub , //sub.site.ru или //www.site.ru . Бывает удобно выбрать один из этих URL-адресов в качестве канонического (основного) и использовать переадресацию 301 для перенаправления на него трафика с других URL. Для настройки можно использовать «Инструменты для веб-мастеров».

При объединении двух сайтов требуется, чтобы все ссылки на устаревшие страницы указывали на страницы, действующие в данный момент.

При переносе страницы сайта в новое место.

Для склейки имени сайта с префиксом www и без него.

Статья по теме: Корректный переезд сайта на протокол https

301-ая ошибка (301 Permament Redirect), возвращаемая при обращении к определенному адресу страницы, означает, что сайт был на постоянной основе перенесен на новый адрес, также указанный в HTTP заголовке. Как пользователи, зашедшие через браузер, так и поисковые боты будут перенаправляться по новому адресу, при этом, для поисковиков все свойства старого адреса (страницы) будут переданы новому URL . При 301 редиректе произойдет склейка старого и нового адресов: параметры вроде PageRank и тИЦ, а также вес страницы и ссылочный вес старого адреса будет передан новому URL .

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

301 редирект в.htaccess

При использовании сервера Apache, переадресацию можно просто выполнить с помощью файла.htaccess , однако, при этом, не забыть включить модули mod_alias (для поддержки директив Redirect , RedirectPermanent и RedirectMatch) и/или mod_rewrite (для использования реврайта) в php.ini .

Для этого поместите в корне папке вашего сайта файл.htaccess. Редирект с помощью директивы Redirect или RedirectPermanent модуля mod_alias Redirect 301 /old-page.html //new-domain.ru/new-page.html

Redirect permanent /old-page.html //new-domain.ru/new-page.html

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

RedirectPermanent /old-url.html //new-site.ru/new-url.html

Редирект с помощью директивы RedirectMatch

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

RedirectMatch /(.*).php$ /$1.aspx

Редирект с помощью директивы RewriteRule модуля mod_rewrite

Для использования директивы RewriteRule необходимо удостовериться, что в httpd.conf подключен модуль mod_rewrite , а также влючена опция FollowSymLinks . Использование реврайт модуля дает много возможностей для перенаправления страниц на новые адреса.

Статья

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

Самый главный файл .htaccess располагается в корне сайта:

Его действия распространяются на текущий каталог и на все вложенные каталоги. Т.е. у владельцев сайтов есть возможность воздействовать только на работу своего проекта, не мешая работе всего сервера. Если этот файл отсутствует, то его можно создать с помощью любого блокнота. Главное, чтобы название файла было ".htaccess" - без форматов.txt, .doc и т.д.

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

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

Чтобы иметь возможность работать с редиректами нужно включить модуль ReWriteEngine . Для этого необходимо прописать две строчки кода (желательно в самом верху файла .htaccess ):

Options +FollowSymLinks RewriteEngine On

Разместите эти строки в самом верху файла .htaccess , чтобы иметь возможность работать с директивами модуля mod_write.

Также на хостинге должны быть включены модули mod_alias (для поддержки Redirect, RedirectPermanent и RedirectMatch).

1. Правила Redirect, RewriteRule и RewriteCond 1.1. Директива Redirect

Синтаксис Redirect :

Redirect /откуда http://куда_полный_адрес

Redirect устанавливает прямой редирект с одной страницы на другую.

В status пишут код редиректа. Является необязательным параметром. Чаще всего пишут 301, что сигнализирует о постоянном смене адреса страницы.

Важно, чтобы страница "откуда" была прописана в формате без указания полного адреса сайта, но с указанием полного относительного адреса URL начиная со слэша "/" (т.е. с корня сайта). Страницу куда идет редирект нужно писать полностью, т.е. абсолютный адрес страницы URL (т.е. с названием домена и протокола http или https).

Например

Redirect 301 /oldpage.php http://site/newpage.php

Можно также писать по другому

RedirectPermanent 301 /oldpage.php http://site/newpage.php или Redirect permanent 301 /oldpage.php http://site/newpage.php 1.2. Директива RewriteRule

Директива RewriteRule устанавливает правила перехода. Синтаксис следующий:

RewriteRule Шаблон Подстановка [коды]

При внешнем редиректе меняется урл адреса в строке браузера - " "
При внутреннем - не меняет урл адреса в строке браузера - " " или "[L] "

1.3. Директива RewriteCond

Директива RewriteCond определяет условия при котором выполняется правила в RewriteRule.

RewriteCond Сравниваемая_Строка Условие

Например, этими условиями могут быть браузер пользователя, IP-адрес , заголовок и т.д.

1.4. Директива RedirectMatch

Директива RedirectMatch аналогична Redirect с той лишь разницей, что позволяет записывать регулярные выражения.

RedirectMatch Откуда Куда 2. Примеры 301 редиректов в.htaccess

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

Смена адреса сайта - редирект со старого домена на новый

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

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 2.3. Редирект всего каталога на другую страницу

С любой страницы в каталоге и подкаталогах /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 [L] 2.6. Простановка замыкающего слеша в конце адреса главной страница

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

RewriteCond %{REQUEST_URI} /+[^\.]+$ RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ 2.7. Удаляем директорию каталога из URL

Например для редиректа со страницы 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

В данном примере сначала проверяется факт того, что пользователь открыл сайт с мобильного устройства {HTTP_USER_AGENT} , далее происходит замена адреса сайта на 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} 3.Другие примеры с htaccess 3.1. Запретить IP-адрес и браузер

Запретим открывать сайт для пользователя с браузера IE с IP-адресом 172.111.222.55

RewriteCond %{HTTP_USER_AGENT} MSIE RewriteCond %{REMOTE_ADDR} ^172\.111\.222\.55$ RewriteRule ^.*$ - [F] 3.2. Запретить конкретный файл

Запретим для всех файл disable_file.html :

deny from all 3.3. Разрешить доступ с одного ip

Доступ будет разрешен только с одного ip-адреса 172.111.222.55

order deny,allow deny from all allow from 172.111.222.55 3.4. Запретить доступ с разных ip

Запретить доступ к сайту с нескольких ip-адреса 172.112.222.55, 172.113.222.55, 172.114.*.*

order deny,allow deny from all deny from 172.112.222.55 deny from 172.113.222.55 deny 172.114.*.* 3.5. Редирект в URL с больших символов на маленькие

Все большие буквы в адресе URL будут переведены на маленькие.

RewriteRule - RewriteRule ! - RewriteRule ^([^A]*)A(.*)$ $1a$2 RewriteRule ^([^B]*)B(.*)$ $1b$2 RewriteRule ^([^C]*)C(.*)$ $1c$2 RewriteRule ^([^D]*)D(.*)$ $1d$2 RewriteRule ^([^E]*)E(.*)$ $1e$2 RewriteRule ^([^F]*)F(.*)$ $1f$2 RewriteRule ^([^G]*)G(.*)$ $1g$2 RewriteRule ^([^H]*)H(.*)$ $1h$2 RewriteRule ^([^I]*)I(.*)$ $1i$2 RewriteRule ^([^J]*)J(.*)$ $1j$2 RewriteRule ^([^K]*)K(.*)$ $1k$2 RewriteRule ^([^L]*)L(.*)$ $1l$2 RewriteRule ^([^M]*)M(.*)$ $1m$2 RewriteRule ^([^N]*)N(.*)$ $1n$2 RewriteRule ^([^O]*)O(.*)$ $1o$2 RewriteRule ^([^P]*)P(.*)$ $1p$2 RewriteRule ^([^Q]*)Q(.*)$ $1q$2 RewriteRule ^([^R]*)R(.*)$ $1r$2 RewriteRule ^([^S]*)S(.*)$ $1s$2 RewriteRule ^([^T]*)T(.*)$ $1t$2 RewriteRule ^([^U]*)U(.*)$ $1u$2 RewriteRule ^([^V]*)V(.*)$ $1v$2 RewriteRule ^([^W]*)W(.*)$ $1w$2 RewriteRule ^([^X]*)X(.*)$ $1x$2 RewriteRule ^([^Y]*)Y(.*)$ $1y$2 RewriteRule ^([^Z]*)Z(.*)$ $1z$2 RewriteRule - [N] RewriteCond %{ENV:HASCAPS} TRUE RewriteRule ^/?(.*) /$1

Привет, друзья. Сегодня хотелось бы обсудить очень заезженную, но всегда актуальную тему – это 301 Редирект (Permanent Redirect 301) – в seo-тусовке и без формальностей именно это подразумевается под словом «редирект» . Технически это является ответом сервера на обращение к нему, этот ответ имеет код 301, обозначающий, что адрес обращения был изменен навсегда (moved permanently). В результате всех этих хитрых махинаций мы должны получить какой-то новый конечный адрес.

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

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

Когда НЕОБХОДИМО делать 301 редирект

В первую очередь редирект применяется, когда страница (группа страниц или целый раздел) сменила свой адрес — чаще всего это случается при изменении структуры сайта, переименовании основообразующей части url’а или смене принципа формирования адресов (проще говоря, ЧПУ). К сожалению, не все об этом задумываются, когда что-то меняют на сайте, и в итоге возникает куча дублей, что приводит к потере позиций или даже наложению санкций со стороны поисковых систем. По своей работе я очень часто сталкиваюсь с такими ситуациями, и это стоит много нервов, чтобы все исправить и нивелировать последствия. От себя могу порекомендовать перед любой работой по смене типа ЧПУ или переделке структуры составить план текущей структуры сайта, всех его разделов и примеров конечных страниц. Все это необходимо будет проверить после завершения работ, чтобы при переходе по старому адресу мы попадали на новый, а сервер отдавал редирект с кодом 301 (а не 302).

Следующий частый случай использования 301 редиректа – смена адреса сайта или склейка зеркал. Если вы решили поменять адрес сайта в связи с ребрендингом компании или зарегистрировали новый более красивый и короткий домен для указания его на печатной промо-продукции — очень важно, чтобы при обращении к адресу на старом домене пользователь попадал на ту же самую страницу (а не на главную страницу), но на новом домене. Что касается промо-сайтов, то обычно они состоят из одной-двух страниц, ссылки с которых ведут на основной сайт, или же при переходе на промо-сайт сразу происходит редирект на специальную страницу основного сайта. Еще иногда при создании сайта регистрируется сразу несколько доменов, например, из-за неоднозначного написания имени компании на латинице. Чтобы интуитивно набирая адрес, пользователь попал куда надо, и регистрируются несколько доменов – очень важно, чтобы со всех «вспомогательных» доменов происходил 301 редирект на один основной адрес. Ни в коем случае нельзя допустить, чтобы по всем адресам был доступен один и тот же сайт.

И еще о зеркалах – может случиться так, что ваш сайт будет доступен по адресам http://www.site.ru, http://site.ru и https://site.ru (последнее редко, но бывает) – это все классические ошибки, которые нельзя допускать, и в их решении как раз участвует 301 редирект. Так же как и в случае с разными адресами сайтов, необходимо определиться с главным зеркалом (с www или без www) и настроить редиректы на основное зеркало. Конечно, поисковики не глупые и в таких ситуациях часто сами справляются, а так же им можно помочь, сделав правильные настройки в панелях вебмастера и в robots.txt (для Яндекса, директива Host). Но seo – дело тонкое, и я бы не стал полагаться на удачу, а воспользовался проверенным способом!

Иногда случается очень неприятная ситуация, когда копия сайта оказывается доступной не только при вводе в адресной строке названия домена, но и IP-адрес сервера. Такая ситуация вряд ли может произойти на виртуальном хостинге, а вот если у вас выделенный сервер, то запросто. Это может являться причиной некорректной настройки сервера – решить проблему поможет отключение возможности доступа при обращении к ip-адресу, но лучше всего здесь выручит 301-редирект на уровне веб-вервера (apache или nginx). Пару месяцев назад у меня случилась как раз такая ситуация – у меня был выделенный сервер, на котором висела часть сайтов, но под один из сайтов я решил взять еще один отдельный сервер. Я перенес сайт, все работало как часы, и вот однажды натыкаюсь в выдаче Гугла на клон моего сайта – шок, паника – оказалось, что это ip адрес моего нового сервера и, разумеется, на нем живет мой сайт, а при обращении сервер отдает ответ 200 OK, и Google проиндексировал его полностью. На предыдущем сервере такой проблемы не было, там изначально был настроен 301-редирект с ip на домен, указанный в качестве основного для этого ip. Теперь я научен горьким опытом и всегда проверяю такие вещи – будьте в курсе и вы, не повторяйте ошибок. Проблему решили путем добавления в конфиги веб-сервера nginx 301 редиректа на основной домен, пример кода покажу в практической части поста ниже.

Ситуация подобная предыдущей – когда копия сайта находится и доступна через служебный тестовый домен , например, вида site.hosting.ru. Такие случаи в моей практике тоже встречаются, и, в отличие от предыдущего случая, это свойственно как раз для виртуального хостинга. Для чего такое существует? Например, у вас еще не куплен домен или вы переносите сайт с одного хостинга на другой, а NS сервера для домена не сменили, или еще не обновились записи DNS у провайдера. В таких ситуациях и делают тестовые адреса, где вы можете все настроить и установить, прежде чем перенаправлять адрес сайта на новый хостинг. И вот некоторые хостеры грешат тем, что не закрывают доступ к таким техническим адресам и при этом даже не запрещают их индексацию. Если и у вас случилась эта неприятная ситуация, то стоит попробовать прописать 301-редирект с технического адреса на основной в файле.htaccess.

Ну и, конечно же, 301 редирект очень любят применять правильные сеошники для борьбы с различными дублями страниц. Почему только правильные сеошники? Да потому, что неправильные хуй забили на сайт клиента и, что вполне вероятно, даже не заходя на сайт, стали закупать ссылки – увы, это не редкость. Ко мне периодически обращаются заказчики, которые хотят проверить добросовестность своих подрядчиков/сотрудников, отвечающих за оптимизацию и продвижение сайта, насколько качественно идет работа – – и пока еще ни разу не было такого, чтобы я не нашел на сайтах ошибок или недоработок. Так что, имейте в виду – я всегда рад вам помочь. Вернемся же к дублям – я считаю, что вместо того чтобы закрывать дубли от индексации, необходимо делать редирект на основной адрес, а всякие rel=”canonical” это уже не так интересно. Разумеется, существует масса случаев, когда дубли вынужденные, и тогда без канонизации не обойтись, но если есть возможность сделать редирект, обязательно делайте его. Частые случаи дублей, которые необходимо проверять всегда: адреса со слешем на конце и без, адреса с параметрами и метками – как это решать, я расскажу ниже.

Когда МОЖНО делать 301 редирект

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

Redirect 301 можно использовать в качестве ответа сервера вместо ошибки 404 Not Found – другими словами, пользователь, перейдя по неправильной ссылке или на не существующую страницу, увидит не сообщение, мол, «Извините, такой страницы больше нет», а будет перемещен на другую существующую страницу. Это очень спорный момент среди специалистов, а потому я свое мнение никому не навязываю. Но я предпочитаю использовать именно редирект вместо 404 ошибки, и тут существует несколько вариантов развития событий… Смотрите, есть 2 категории 404 ошибок: первая – классическая, когда страницу действительно удалили, вторая – когда появление ошибки связано с кривыми внешними ссылками. В первом случае, наверное, не стоит делать редирект, а оставить 404 ошибку как она есть. А вот во втором случае стоит озаботиться редиректом на правильный url-адрес, если его можно восстановить из битой ссылки, или редиректом на главную страницу (или категорию).

Когда НЕ СЛЕДУЕТ делать 301 редирект

Несколько слов о том, когда редирект может вам навредить, а потому его не стоит использовать в следующих ситуациях.

Самое главное, чтобы не наделать ошибок, не стоит связываться с редиректами, если вы на 100% не уверены в том, что вы делаете или в чем-то сомневаетесь. Примите это как дружеский совет:)

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

Если с вашим доменом случились проблемы, например, фильтры, бан и т.п., и вы решили сменить адрес сайта (домен), то не стоит делать 301 редирект со старого домена на новый — в результате вы «приклеите» к новому домену и все проблемы сторого. То есть в итоге ничего и не изменится. Да, было какое-то время решение выхода из под гугло-фильтра Пингвин при помощи полного 301-редиректа со старого домена на новый. Действительно все позиции восстанавливались до уровня как до санкций, и это казалось панацеей от злого Пингвина, но при очередном апдейте алгоритма эта особенность была учтена и новый домен так же попадал под фильтр, в итоге ничего не улучшалось после смены домена. Если уж вы решили сменить домен, то можно попробовать перенести весь контент на новый домен, а на старом его удалить и повесить заглушку с сообщением о переезде, а еще лучше начать все «с нуля».

Способов сделать редирект очень много – через htaccess, php, javascript, настройки сервера и т.д. – так вот не надо пытаться использовать сразу все методы одновременно , слишком велика вероятность «разногласий» между разными способами и можно, например, получить бесконечное циклическое перенаправление.

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

http://site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30/ ->
http://www.site.hosting.ru/404.php ->
http://www.site.ru/404.php

А еще в итоге страница http://www.site.ru/404.php, которая должна отдавать 404 ошибку, отдает ответ 200 OK. Это даже мне взорвало мозг, а представьте, что подумал бы поисковый робот, попав в такую карусель! Мало того, что в цепочке поучаствовали три разных домена, так еще и страница ошибки говорит, что она не ошибка и ее надо индексировать.

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

Составляя привила редиректов в.htaccess исключайте реальные адреса директорий и файлов на сервере и следите за выборкой. Ситуация для сайта, попавшего мне однажды на аудит – в борьбе с дублями страниц категорий со слешем на конце и без, вебмастер перестарался немного и наоборот только усугубил проблему. Мало того, что под правила перезаписи попали и реальные файлы js-скриптов и css-стилей из-за чего они перестали корректно работать, так еще и некоторые страницы получили ненужный слеш на конце и появились дубли. Друзья, тщательно следите, чтобы составленные правила распространялись только на ту группу адресов, с которой вы работаете, и ограничивайте все остальные.

Для поиска проблемных страниц и их адресов, от которых необходимо избавиться, используйте возможности панелей вебмастера от Яндекс и Google. Для Яндекса Вебмастер: Выбираем сайт –> Индексирование сайта –> Исключенные страницы. Для Google Webmaster: Выбираем сайт –> Оптимизация –> Оптимизация HTML; А так же: Выбираем сайт –> Конфигурация –> Параметры URL.

Особенности индексации и переиндексации редиректов в Яндекс и Google. Когда вы будете бороться с дублями и проблемными адресами, разумеется, вы будете ждать удаления ошибок из панелей вебмастера, тут есть некоторые особенности. С Google все просто – настроили редиректы, изменения проиндексируются в течение 2 недель, за это же время начнут исчезать ошибки и из панели вебмастера, обычно через месяц все ошибки пропадают. С Яндексом же есть тонкость, и заключается в следующем – после простановки редиректов можно ждать пропадания ошибок из панели вечно, я ждал однажды полгода, пока не написал в поддержку, где мне сообщили, что помимо редиректа необходимо дополнительно закрыть проблемные страницы в robots.txt и только тогда они пропадут из панели вебмастера.

Permanent Redirect 301 через.htaccess

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

У вас на сервере (в корне, там где главный index.php) уже наверняка есть файл.htaccess. Если этот файл не видно:

Проверьте настройки ftp-менеджера, он может скрывать системыне файлы, коим и является файл htaccess
Зайдите в файловый менеджер через панель управления хостера и проверьте права для файла. Я имею ввиду не CHMOD, а группу и пользователя, например, там может стоять пользователь root, а вы подключаетесь через ftp используя доступ пользователя владельца домена.
Банально файла может не быть:) Тогда его следует создать, но под windows иногда возникает проблема, т.к. по сути файл.htaccess видится системой как файл без имени и только с расширением. Предлагаю простой способ – создаем обычный txt-файл, добавляем в него строку «RewriteEngine On» (без кавычек), загружаем txt-файл на сервер, на сервере переименовываем файл в.htaccess

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

Давайте рассмотрим несколько самых распространенных и полезных примеров:

Редирект для домена с www.site.ru на site.ru

RewriteCond %{HTTP_HOST} !^www\.(.*) RewriteRule ^(.*)$ http://www.%1/$1

Вышеописанные варианты редиректа отлично работают и не требуют никаких правок с вашей стороны — только вставить в.htaccess файл. Однако для 100% надежности я бы посоветовал вам другой вариант:

RewriteCond %{HTTP_HOST} !^www.site.ru$ RewriteRule ^(.*)$ http://www.site.ru/$1

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

Первый для тех, у кого основной домен с www, второй – у кого без www. Соответственно в обоих примерах надо вместо «site» вписать название вашего домена.
Итак, чем же данные варианты лучше? Очень просто, они проверяют не только отсутствие/наличие www в имени домена, но проверяют и имя домена на полное его соответствие.
Живой пример: Наверняка вы сталкивались с тем, что неожиданно сайт может проиндексироваться по служебному адресу на хостинге (такой адрес выдается, чтобы к сайту можно было обратиться до привязки вашего реального домена), какому-нибудь зеркалу или вообще ip-адресу! Так вот универсальные правила будут лишь верифицировать отсутствие/наличие www, при этом все равно, к какому домену обращается пользователь или поисковый робот.
Так вот воспользовавшись продвинутым вариантом, вы на 146% будете уверены, что ваш сайт будет доступен только и исключительно по указному лично вами доменному имени и с учетом www. Я пользуюсь только таким вариантом и вам рекомендую!

Редирект с http на https

В свете массового перехода сайтов на защищенный протокол, необходимо знать, как сделать редирект с http на https. Кстати, если вы еще не выбрали SSL-сертификат, вам стоит прочитать мой пост про .

Ниже я предлагаю вам несколько вариантов редиректа с протокола http на https, которые могут работать либо не работать в зависимости от конфигурации именно вашего сервера, но какое-то из правил вам точно подойдет:

RewriteCond %{HTTPS} !=on RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1

RewriteCond %{SERVER_PORT} !^443 $ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI}

RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI}

RewriteCond %{ENV:HTTPS} !on RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1

RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

Редирект с протокола https на http (честно, не знаю, зачем вам может это понадобиться):

RewriteCond %{HTTPS} =on RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1

Внесу некоторую ясность в непонятную абракадабру:

RewriteCond обозначаем условие, при совпадении с которым будет выполнено правило RewriteRule. С помощью регулярных выражений задаются шаблоны строк.
Переменные сервера:
- %{REQUEST_URI} — часть урла без доменного имени и GET-параметров, например, для страницы, которую вы сейчас читаете: blog/post/4393 ,
- %{HTTP_HOST} — хост или доменное имя, например: сайт
- %{QUERY_STRING} — строка с набором GET параметров, то есть часть урла после знака вопроса (и до решётки якоря, если он есть).
- %{REQUEST_FILENAME} — полный путь в файловой системе сервера к файлу или скрипту соответствующим этому запросу..php , а вот в файловой системе сервера это страшная строка /var/www/сайт/data/www/сайт/index.php .
  Бывает, делая редирект, вы получаете неожиданный результат, например, хотели в адресе http://site.ru/page-name?post=17434801_4060 убрать параметры post=17434801_4060 , указали соответствующие правила (о них ниже будет написано), а в итоге получили строку http://site.ru/usr/local/www/site.ru/www/page-name — от параметров избавились, но получили странный адрес. Это все потому, что вы не указали в начале файла после RewriteEngine On директиву RewriteBase /, которая устанавливает конкретный, базовый URL для преобразований в контексте каталога.
Метасимволы используются для задания групп символов или «меток» в шаблоне:
- ^ — метка начала строки,
- $ — метка конца строки,
- ! – отрицание,
- \ — экранирующий слеш, позволяет считать следующий за ним метасимвол обычным символом,
- . – точка, обозначает любой символ, но только один,
- () – группировка.
Модификаторы ставятся после обычных символов, метасимволов или их групп и расширяют возможности использования шаблонов:
- ? — символ повторяется 0 или 1 раз,
- * — Повторяется от 0 до 65536 раз,
- + — Повторяется от 1 до 65536 раз.
Флаги определяют дополнительные опции для данного правила и перечисляются в квадратных скобках через запятую:
- NC — (nocase) отключает проверку регистра символов.
- R — (redirect) останавливает процесс преобразования и возвращает результат браузеру клиента как редирект на данную страницу (302, MOVED TEMPORARY). С данным флагом можно указать другой код результата, например R=301 возвратит редирект с кодом 301 (MOVED PERMANENTLY). Как вы понимаете, это то самое, что нам и надо.
- L — (last) останавливает процесс преобразования, и текущая ссылка считается окончательной.

Самый популярный случай — редирект с index.php (html) на главную страницу. На 90% сайтов встречается проблема дублирования главной страницы по адресам http://site.ru и http://site.ru/index.php (или index.html, index.htm или любой другой вариант, не принципиально, а то и все сразу). Где-то это явно, когда, например, ссылка из логотипа ведет на site.ru, а ссылка в меню ведет на site.ru/index.php, где-то не явно, когда дубль находится при вводе адреса с index.php вручную. Важно просто решить проблему. И я предлагаю универсальный вариант, вот он:

RewriteCond %{THE_REQUEST} ^{3 ,9 }\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1

RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1

Просто вставьте этот код без изменений после строки после строки «RewriteEngine On» и нет проблем!

Многие, кто начинает бороться с дублями на сайте, задаются вопросом, а откуда берутся такие вот ссылки , которые дублируют основную страницу http://site.ru/page-name.html&post=-1234567_8901 ? Откуда взялась приставка &post=-1234567_8901 – это «добро» берется из вконтакте, когда кто-то делится ссылкой на ваш сайт у себя на стене, в группе или паблике, то автоматически добавляется подобная строка, видимо, для отслеживания какой-то статистики.

Чтобы избавиться от этой ерунды раз и навсегда необходимо добавить в htaccess:

RewriteCond %{REQUEST_URI} ^(.*)\&sa= RewriteRule ^(.*)\&sa=(.*)$ $1

Как видите, никакой разницы между этим и предыдущим случаем нет, пусть у вас в url"е будет &post= или &sa= или что угодно — решение одинаковое, просто надо заменить очевидные части кода. Понятно же, правда?

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

Вопрос задавался и в комментариях и много раз на форуме, потому нельзя его обойти стороной. Что делать вот с такими дублями: http://site.ru/?abrakadabra или более реальный случай http://site.ru?utm_source=twitterfeed&utm_medium=twitter

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

RewriteCond %{QUERY_STRING} ^lang=ru$ RewriteRule ^(.*)\.php\?(.*)$ $1\.php

%{QUERY_STRING} — это строка с набором переменных для PHP, часть урла после знака вопроса (и до решётки якоря, если он есть).

Вызываем url — http://site.ru/index.php?lang=ru

RewriteCond %{QUERY_STRING} ^lang=ru $
Запрашиваемый url попадает под это правило, других правил нет, поэтому будет выполнен RewriteRule строкой ниже.
RewriteRule ^(.*) \.php\?(.*) $ $1 \.php

Исходный url: http://site.ru/index .php?lang=ru
Шаблон разборки url’а: ^(.*) \.php\?(.*) $
URL будет разобран по переменным: $1 = http://site.ru/index , $2 = lang=ru и собран обратно уже в виде http://site.ru/index .php ($1 \.php)
А далее будет 301 редирект на новый url.

Пример правил при смене структуры сайта

RewriteRule ^post/category/(.*)$ blog/category/$1 RewriteRule ^post/(.*)$ blog/post/$1

Вот такие строки мне пришлось добавить в htaccess файл, когда я сменил структуру своего блога.

Раньше у меня были адреса такие: http://сайт/post/4358 и http://сайт/post/category/seo, что как-то ломало логику в структуре – ведь блог это только часть сайта, но почему-то посты принадлежат сайту, а не блогу, а категории принадлежат постам, что тоже совсем нелогично..info/blog/category/seo — теперь блог как отдельный раздел сайта, а посты принадлежат ему, и категории принадлежат блогу, а не постам.

Из этого же примера видно, что важно соблюдать последовательность правил. Если бы я поменял строки местами, то есть впереди бы шла строка RewriteRule ^post/(..info/blog/post/category/seo а не как надо на http://сайт/blog/category/seo.

И последний пример — разбор частой ошибки с адресом от корня сервера

Например, вы решили исправить такую проблему, когда страница категории доступна по двум адресам http://site.ru/razdel/podrazdel/index.php и http://site.ru/razdel/podrazdel/. Второй url является правильным и основным, а url с index.php на конце является полным дублем, от которого необходимо избавиться.

Для того чтобы сделать редирект с index.php на категорию вы прописываете правило:

RewriteEngine On RewriteBase /

Простой редирект страницы на новый адрес

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

Redirect 301 /page-name1.html http://site.ru/page-name2.html Redirect permanent /page-name1.html http://site.ru/page-name2.html RedirectPermanent /page-name1.html http://site.ru/page-name2.html

Выбирайте один из трех, а лично я предпочитаю первый вариант — он короче, проще и понятнее. Кстати, здесь site.ru может быть не обязательно тем же самым доменом, но любым другим.

На этом закончим с.htaccess и перейдем к PHP.

Permanent Redirect 301 с помощью PHP

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

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

header (); header ("Location: http://site.ru" ); die("Redirect" );

header("HTTP/1.1 301 Moved Permanently"); header("Location: http://site.ru"); die("Redirect");

Эти строки сообщают браузеру клиента, что с какой-то запрошенной страницы необходимо произвести перманентный редирект на адрес http://site.ru. При этом http://site.ru может являться не только адресом главной страницы текущего сайта, но может быть и любым другим сайтом. Если же что-то пошло не так и произошла ошибка, то в окне браузера мы увидим надпись «Redirect».

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

Функция, позволяющая убрать определенный кусок из url

if (strpos($_SERVER["REQUEST_URI" ], "http://сайт" ) !== false) { $real_page_url = "http://сайт" .str_replace ("/http://сайт" , "" , $_SERVER["REQUEST_URI" ]); header ("HTTP/1.1 301 Moved Permanently" ); header ("Location: $real_page_url" ); die("Redirect" ); }

if (strpos($_SERVER["REQUEST_URI"], "http://сайт") !== false) { $real_page_url = "http://сайт"..1 301 Moved Permanently"); header("Location: $real_page_url"); die("Redirect"); }

Однажды у меня возникла проблема, что в панели вебмастера вылезла куча 404 ошибок, адреса этих страниц были вида http://alaev..е. откуда-то в адресе появился дублирующий адрес сайта. И тогда я написал функцию, которая проверяет, есть ли в URI (заметьте, не URL, а URI) вхождение «http://сайт», и если присутствует, то вырезаем из адреса этот кусок и записываем результат в переменную $real_page_url, а потом делаем 301-редирект на верный адрес из переменной.

Функция, убирающая конечный слеш из url

if (($_SERVER["REQUEST_URI" ], - 1 , 1 ) == "/" ) { $requested_url = rtrim($requested_url, "/" ); header ("HTTP/1.0 301 Moved Permanently" ); header ("Location: $requested_url" ); die("Redirect" ); }

if (($_SERVER["REQUEST_URI"], - 1, 1) == "/") { $requested_url = rtrim($requested_url, "/"); header("HTTP/1.0 301 Moved Permanently"); header("Location: $requested_url"); die("Redirect"); }

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

Существует еще масса вариантов, позволяющих отдавать команду перенаправления на разных языках программирования, типа ASP, Ruby on Rail и т.д., но я с этими языками не знаком, потому не буду тут умничать и пудрить вам мозги. Еще возможны редиректы при помощи метатега meta refresh, а так же редиректы на javascript – но это участь нечистых на руку дорвейщиков, а поисковики эти редиректы не понимают, они получаю ответ от сервера 200 OK. Так что эти варианты мы не рассматриваем.

Permanent Redirect 301 для сервера nginx

Помните я писал про зеркало моего сайта, доступного по ip? В итоге проблему решили редиректом, прописанным в конфигурационном файле сервера, обычно он расположен тут /etc/nginx/nginx.conf. Там прописали вот такие строки:

server { listen 1.2.34.123:80 default; server_name _; rewrite ^/(.*)$ http://site.ru/$1 permanent; }

Здесь говорится о том, что если идет обращение в ip-адресу через 80-ый порт, то необходимо делать permanent redirect на site.ru.

Однако техподдержка не рекомендовала мне так поступать со словами: «Более корректно будет настроить HTTP-сервер таким образом, чтобы он просто закрывал соединение, если к нему обращаются по адресу, который не указан явным образом в конфигурации HTTP-сервера, это наиболее надёжный, простой, безопасный и наименее требовательный к ресурсам сервера вариант. Через некоторое время страницы, которые будут недоступны, скорее всего, будут выкинуты из индекса поисковых систем.»

Следующий совет был такой: «Когда потребуется просто закрывать соединение вместо перенаправления, то укажите вместо строки "rewrite ^/(.*)$ http://site.ru/$1 permanent;" такую строку "return 444;". Затем выполните: "invoke-rc.d nginx reload"».

Вдруг это кому поможет.

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

Редирект для домена www.site.ru на site.ru

server { listen 80; server_name site.ru; rewrite ^ http://www.site.ru$request_uri? permanent; }

Редирект с адреса http://site.ru/index.php на http://site.ru/

location = /index.php { if ($request_uri = /index.php) { rewrite ^ http://$host? permanent;#301 redirect } fastcgi_pass unix:/tmp/fastcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

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

Как проверить HTTP заголовки и статусы ответа сервера

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

Дополнение HttpFox для Firefox

HttpFox (вот ссылка на аддон) — это мой любимый инструмент отслеживания http-заголовков. HttpFox построчно показывает ход загрузки страницы, что позволяет отслеживать, например, цепочки редиректов и вообще порядок и скорость загрузки страницы. Если вы пользуетесь Мозиллой, то однозначно рекомендую.

Расширение HTTP Headers для Chrome

Сам я не пользуюсь расширением HTTP Headers (вот ссылка на него), но интернеты мне посоветовали обратить внимание именно на него. Если у вас есть варианты получше, пожалуйста, отпишитесь в комментариях.

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