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

При работе с веб-ресурсами возникают ситуации, когда происходит удаление, перенос или изменение url-адреса отдельных страниц или сайта целиком. При этом требуется сохранить индексацию в поисковых системах и перенаправить пользовательский трафик на новый адрес. Для решения этой задачи используется функция под названием 301 Redirect. Это один из инструментов SEO, который позволяет не только избежать ошибок при открытии отдельных страниц, но и добиться корректной работы ресурса. Правильные настройки редиректа дают дополнительную возможность получить синергетический эффект в поисковой оптимизации и увеличить количество органического трафика на релевантные страницы. Рассмотрим более подробно, как происходит настройка редиректа 301.

Что такое переадресация 301

Permanent Redirect 301 применяется с целью организации постоянной переадресации с неактуального доменного адреса или url отдельной страницы на рабочую версию. Редирект может понадобиться в связи с глобальным переносом сайта на другой домен, техническими изменениями в написании адреса, удалением страниц, необходимостью внутренней и внешней перелинковки. Один из вариантов использования перманентной переадресации – редирект с нескольких доменных имен, созданных в разных зонах, на один актуальный адрес. Грамотное использование редиректа позволяет перемещать контент без потерь в поисковой индексации, сохранить и даже увеличить прежний вес и позицию в выдаче.

Настроить код состояния HTTP 301 можно разными способами:

• с помощью HTML и PHP;

• через панель управления или плагины соответствующей CMS;

• при помощи специальных скриптов (программ);

• на уровне хостинг-провайдера;

• внесением соответствующих записей в файлы .htaccess для сервера Apache или web.config для IIS.

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

Альтернативные методы переадресации

• Редирект 302. Применяется в случае временной переадресации с одного url на другой. При его использовании поисковая система индексирует все доступные версии сайта или страницы. Объединения ссылочного веса и внутренних метрик на приоритетном ресурсе не происходит. 
• 307 Temporary Redirect рекомендуется применять в исключительных случаях. Например, при техническом обслуживании сайта, когда он недоступен некоторое время. 
• Обновления Meta Refresh выполняют переадресацию не на уровне сервера, а непосредственно на сайте. Пользователь сталкивается с временной задержкой (обычно около пяти секунд), после чего для перехода на нужную страницу должен принудительно запустить определенную команду. Этот метод часто приводит к падению посетительского интереса и проседанию поисковых индексов.
• Редирект rel=«canonical». Позволяет сохранить доступ посетителям ресурса к контенту дублирующихся страниц. При этом для поисковиков наличие команды canonical на одной из страниц говорит о том, что только она подлежит индексации в поиске.

В большинстве случаев постоянная переадресация является более правильным решением, чем временная. На практике это объясняется просто. Предположим, сайт сменил доменную зону, а затем еще и обзавелся защищенным протоколом https. При настройке временной переадресации в индексе Яндекса и Google по одним и тем же запросам появились три версии сайта с пропорциональным проседанием позиций в выдаче. После настройки редиректа 301 на приоритетный url произошло склеивание дублей, робот вернул сайт в топ выдачи. 

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

В каких случаях используется постоянный редирект 301

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

2. Изменение написания url определенных страниц в целях SEO-продвижения, смены CMS или по иным причинам. Требуется настроить редирект с site.ru/1hdkr5 на site.ru/page_adress.

3. Перенос разделов на субдомены. Необходимо сменить адрес www.site.ru/example на example.site.ru.

4. Для аккумуляции трафика с адресов, купленных в разных доменных зонах, на один приоритетный ресурс. 

5. Исключение дублирующихся страниц из индекса. 

6. Склейка зеркал сайта – вариантов сайта с идентичным контентом, но разным написанием адресов: site.ru, www.site.ru, https://site1.ru и т.д. В этом случае выбирается один приоритетный домен и на него настраивается редирект со всех остальных зеркал.

7. Удаление ранее существовавшей страницы. В этом случае пользователи обычно видят ошибку 404. Большое количество таких сообщений негативно воспринимается как пользователями, так и поисковиками.

8. Для быстрого перехода пользователя на мобильную версию ресурса со смартфонов и планшетных устройств.

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

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

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

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

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

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

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

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

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

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

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

RewriteEngine On

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

RewriteRule ^(.*)$ http://sng-it.ru/$1 [R=301,L]

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

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

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

Настройка 301 редирект в .htaccess

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

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

Найти файл можно через панель управления хостинга либо использовать FTP-клиент. При любом варианте нужно включить отображение скрытых файлов.

Предварительная подготовка

• Для создания 301 редиректа перейдите в панель управления вашего сайта.

• Проверьте наличие .htaccess файла в корневом каталоге сайта (public_html, если используете WordPress). Если файл отсутствует, создайте его.

• Рекомендуем все условия редирект записывать в блоке IfModule, дабы избежать ошибок при выполнении файла htaccess.

<IfModule mod_rewrite.c>
</IfModule>

• Перед тем как начать прописывать правила перенаправления, необходимо включить механизм преобразований (RewriteEngine) при помощи команды RewriteEngine On.

• Хостинги применяют по умолчанию 302 или любой другой 3xx редирект. В связи с этим в правилах используются флаги. Рекомендуем дописывать в своих правилах [R=301,L].

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

Склейка зеркал сайта (www / без www)

Сайты http://name.site и http://www.name.site для поисковых систем являются разными. А по факту это разные адреса одного сайта.

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

Если изначально в индекс поисковой системы попала версия «с www», в файл .htaccess добавляется редирект на «без www»:

RewriteCond %{HTTP_HOST} ^www.name.site$ [NC]

RewriteRule ^(.*)$ http://name.site/$1 [R=301,L]

Если произошла обратная ситуация и необходима переадресация с без «www» на «www», то в файл прописывается:

RewriteCond %{HTTP_HOST} ^v name.site$ [NC]

RewriteRule ^(.*)$ http://www.name.site/$1 [R=301,L]

Редирект с http на https для всего сайта

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

RewriteCond %{SERVER_PORT} !^443$

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

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

RewriteCond %{HTTPS} =on

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

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

Если редирект не работает и в этом случае, попробуйте такой вариант:

RewriteEngine On

RewriteCond %{SERVER_PORT} !^443$

RewriteCond %{REQUEST_URI} =/page.php

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

В результате пройдет перенаправление на https всех пользователей и поисковых систем.

Постранично

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

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteCond %{REQUEST_URI} !^/page.php

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

Для одной страницы

Для редиректа с http на https одной страницы (например page.php), в файл добавьте следующую конструкцию:

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteCond %{REQUEST_URI} =/page.php

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

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

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

RewriteCond %{SERVER_PORT} ^443$ [OR]

RewriteCond %{HTTP} =on

RewriteRule ^(.*)$ https://name.site/$1 [R=301,L]

Изменение домена

В том случае. если необходимо перейти на другой домен, при этом сохранив SEO-позиции, в файл .htaccess прописывают следующее:

RewriteCond %{HTTP_HOST} ^www.old_name.ru$ [NC]

RewriteRule ^(.*)$ http://new_name.ru/$1 [L,R=301]

RewriteCond %{HTTP_HOST} ^old_name.ru$ [NC]

RewriteRule ^(.*)$ http://new_name.ru/$1 [L,R=301]

Редирект на страницу с другим url (без параметров)

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

RewriteRule ^(.*)old_page.html$ http://vash-sait.ru/new_page.html [R=301,L]

Редирект для url (с параметрами)

Если адрес содержит параметр (например, http://name.site/articles.php?section=1, где параметром является «section=1» ), то прописывают следующую конструкцию:

RewriteCond %{QUERY_STRING} section=1

RewriteRule ^index.php http://name.site/articles.php? [R=301,L]

Редирект с index.php на главную страницу

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

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.php HTTP/

RewriteRule ^index.php$ http://name.site/ [R=301,L]

Редирект со страниц со слешем на без слеша (для всего сайта)

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

RewriteCond %{REQUEST_URI} !?

RewriteCond %{REQUEST_URI} !&

RewriteCond %{REQUEST_URI} !=

RewriteCond %{REQUEST_URI} !.

RewriteCond %{REQUEST_URI} ![^/]$

RewriteRule ^(.*)/$ /$1 [R=301,L]

Или более короткий вариант:

RewriteCond %{REQUEST_FILENAME} !-d

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

RewriteRule ^(.+)/$ /$1 [R=301,L]

Редирект со страниц без слеша на слеш (для всего сайта)

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

RewriteCond %{REQUEST_URI} !?

RewriteCond %{REQUEST_URI} !&

RewriteCond %{REQUEST_URI} !=

RewriteCond %{REQUEST_URI} !.

RewriteCond %{REQUEST_URI} !/$

RewriteRule ^(.*[^/])$ /$1/ [R=301,L]

301 редирект с 404 Not Found

Код 404 Not Found (страница не найдена) присваивается удаленной или несуществующей странице на сайте. Создание постоянного перенаправления с таких страниц актуально для контентных сайтов и крупных интернет-магазинов, где страницы часто удаляются по естественным причинам. Тогда возникает потребность перенаправить посетителей на одну из главных страниц сайта, чтобы они не уходили с ресурса при виде ошибки.

301 редирект для страниц 404 Not Found сделать совсем не сложно. Например, этот код перенаправит со всех 404-страниц на главную:

ErrorDocument 404 http://www.site.com/301.html

Однако делать такие редиректы в массовом порядке не рекомендуется, так как это может испортить SEO-статистику всего ресурса.

Финальный вид файла .htaccess

Пример файла htaccess, после добавления в него редиректов:

Options -Indexes

ErrorDocument 404 /404.php

php_flag register_globals off

php_value pcre.recursion_limit 1000

#Условия 301 редиректа


<IfModule mod_rewrite.c>

RewriteEngine On

# склейка зеркал


RewriteCond %{HTTP_HOST} ^my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.my_site.ru$ [NC]

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

# без слеша


RewriteCond %{REQUEST_FILENAME} !-d

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

RewriteRule ^(.+)/$ /$1 [R=301,L]

</IfModule>

php_value default_charset utf-8

AddType 'text/html; charset=utf-8' .html .htm .shtml

Синтаксис для регулярных выражений в .htaccess

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

Другие способы создания переадресации 301

Через PHP

Данный вариант подойдет тем, кто хорошо разбирается в web-программировании и PHP. Необходимо открыть файл index.php в корне CMS-движка и прописать там:

if($_SERVER['REQUEST_URI'] == "/index.php") {

 header("Location: /",TRUE,301);

 exit();

}

(в первой строке укажите старый url, а во второй — новый)

Второй способ — перенаправление при помощи отправки заголовков (скрипта):

<?php

  header("HTTP/1.1 301 Moved Permanently");

  header("Location: http://www.newdomain.ru/newdir/newpage.htm");

  exit();

?>

ASP-редирект

<%@ Language=VBScript %>

<%

Response.Status="301 Moved Permanently"

Response.AddHeader "Location", "http://www.new-url.com"

response.end

%>

ASP.NET редирект

Найдите в корне своего сайта файл web.config и вставьте в секцию синтаксис:

<script runat="server">

  private void Page_Load(object sender, System.EventArgs e)

  {

    Response.Status = "301 Moved Permanently";

    Response.AddHeader("Location","http://www.new-url.com");

  }

</script>

ColdFusion редирект

<.cfheader statuscode="301″ statustext="Moved permanently">

<.cfheader name="Location" value="http://www.new-url.com">

JSP (Java) редирект

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

<script type="text/javascript" src="redirect.js"></script>

<script type="text/javascript">

  location="https://yandex.ru";

</script>

CGI-скрипт на PERL

$q = new CGI;

print $q->redirect("http://www.new-url.com/");

Ruby on Rails

def old_action

headers["Status"] = "301 Moved Permanently"

redirect_to "http://www.new-url.com/"

end

Редирект в Nginx

if ($host = 'www.domain.com' ) {

  rewrite ^(.*)$ http://domain.com$1 permanent;

}

HTML-редирект

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

<meta http-equiv="refresh" content="5;https://livepage.pro">

Если поставить значение 0 вместо 5, то переадресация на https://livepage.pro произойдет моментально.

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

Редирект 301 в панелях управления сервера

Большинство панелей управления сервера предоставляют возможность настройки переадресации с кодом 301. Рассмотрим варианты решения этой задачи на примере двух популярных ПУ для VDS.

Cpanel

Нужно перейти в блок «Домены» => «Перенаправления». В появившемся окне выполнить следующее:

• В строке «Тип» выбрать «Постоянный 301».

• В строке «https://www» из выпадающего списка выбрать домен сайта (например, example.ru).

• В строке «Перенаправляет на» указать для домена адрес http://example.ru.

• В блоке «Перенаправление www» поставить галочку напротив «Перенаправлять только с www».

• Сохранить изменения кликом на «Добавить».

ISPmanager

В этой панели можно вручную править файлы nginx.config или .htaccess, но есть и встроенный механизм переадресации. Например, для настройки редиректа на https/http нужно снять галочку с соответствующего пункта в разделе «WWW-домены».

Автоматическое создание переадресации

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

• Seomagnifier — 301 для www;

• 301 Redirect Code Generator Tool — для доменов и страниц;

• Generate .htaccess— для страниц, разделов сайтов, доменов.

Проверка корректности настроек 301 редиректа

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

Для автоматической проверки можно воспользоваться специальными сервисами:

• Redirect Checker, bertal.ru или Header Checker Tool для тестирования отдельных страниц;

• программой Screaming Frog Seo Spider, способной просканировать весь сайт.

Существует ряд ошибок, которые следует избегать при настройке редирект 301:

• использование перенаправлений между страницами сайта без изменения их url в ссылках;

• установка временной переадресации вместо постоянной;

• неправильный выбор типа редиректа;

• перенаправление файла robots.txt;

• непонимание разницы между rel=canonical и кодом 301;

• редирект на нерелевантный контент;

• переадресация, которая не приводит к 200-й странице.

Стоит отметить проблему создания цепочки ссылок, которая может привести к появлению циклического редиректа — ошибки с кодом «ERR_TOO_MANY_REDIRECTS». Наиболее распространенные причины возникновения такого бага – неправильная настройка в процессе создания переадресации, вирусная атака, слишком длинная цепочка редиректов. Не рекомендуется настраивать редирект, содержащий более пяти адресов. Оптимальной является прямая переадресация со старого на новый url.

Заключение

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

Инструментов для настройки корректной работы Permanent Redirect 301 существует достаточно много. Наиболее удобный и правильный – внесение записей в файл .htaccess. Недостаток этого метода в том, что он доступен только для веб-серверов Apache. При использовании IIS придется настраивать web.config. Для создания сложных правил переадресации более всего подходит PHP, но в этом случае без помощи программиста не обойтись. Еще одним вариантом настройки 301 редиректа может быть обращение к хостинг-провайдеру с целью подключения услуги web-форвардинга.

Автор: Питер Мейерс (Dr. Peter J. Meyers) – научный сотрудник Moz и эксперт по поисковому маркетингу

Можно ли отменить 301 редирект? Короткий ответ: «Да». Вы можете отозвать переадресацию, даже если технически она является постоянной. Однако это изменение может сработать не так, как вы ожидали, или даже ухудшить ситуацию. В статье мы рассмотрим четыре возможных сценария.

Примечание и
предупреждение

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

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

Сценарий 1. Одна
страница, полная отмена

Давайте начнём с самого простого сценария. У вас настроена
переадресация 301 со страницы А на страницу B (A→B) и вы хотели бы её удалить, а вместо этого настроить 301
редирект с B на A.

Для этого нужно:

• Удалить 301 редирект с A→B
• Добавить 301 редирект с B→A
• Отправить обе страницы в Google через Search Console
• Дать Google время на обновление страницы B в кеше

Последний шаг – это то место, где многие специалисты ошибаются. У вас может возникнуть соблазн полностью избавиться от страницы B, в том числе удалив её из файлов Sitemap.xml. Однако делать этого не стоит. Дело в том, что Google нужно время на обработку новых сигналов, но он не сможет этого сделать, если вы спрячете страницу B или, что ещё хуже, полностью заблокируете доступ к ней для краулеров. Позвольте Google просканировать страницу B и обработать новые сигналы. Оставьте её в покое на какое-то время.

Сценарий 2. Одна страница, но нужно сохранить оба URL

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

Сценарий 2А. Страница
B доступна для поиска

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

Пошагово этот процесс будет выглядеть так:

• Удалите 301 редирект с A→B
• Добавьте самореферентные атрибуты rel=canonical (A→A, B→B)
• Отправьте обе страницы в Google через Search Console

Самореферентные rel=canonical – это довольно слабый сигнал, но они помогают Google понять, что страница B теперь является отдельным независимым объектом.

Сценарий 2Б. Страница
B скрыта из поиска

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

Для этого выполните следующие шаги:

• Удалите 301 редирект с A→B
• Добавьте rel=canonical с B→A
• Обновите внутренние ссылки, чтобы они указывали
  на страницу А
• Отправьте обе страницы в Google через Search Console

Помните, что rel=canonical – это сильный
сигнал, но он не гарантирует, что страница B не будет ранжироваться. Если страница B не имеет ценности для поиска, и вы
хотите передать её сигналы странице А, тогда это будет наилучший вариант.

Сценарий 3. Отмена
переадресации 301 на уровне сайта

Вот здесь уже возможны проблемы. Допустим, вы внедрили
изменение URL на уровне сайта, например, переключились с http на https, обновили структуру подпапок или
добавили/удалили параметры. Такие изменения влияют на большинство или на все
страницы сайта, но мы будем исходить из того предположения, что ваш корневой
домен и структура поддоменов остались прежними.

Если вы решили отменить такое изменение, как переход с http на https, потому что оно не принесло ожидаемого результата (т.е. вы не заметили улучшений в ранжировании), то я бы убедительно советовал вам этого не делать. Все изменения на уровне сайта сопряжены с рисками, а их отмена запутывает сигналы ещё больше.

С учётом всех предупреждений основные шаги будут выглядеть так:

• Удалите все 301 редиректы с A→B
• Добавьте 301 редиректы на уровне сайта с B→A
• Добавьте самореферентные rel=canonical на все страницы
• Обновите внутренние ссылки, чтобы они указывали на URL типа «А»
• Обновите файлы Sitemap.xml, чтобы они содержали URL типа «А»
• Отправьте критически важные страницы в Google через Search Console
• Обновите отдельные входящие ссылки, чтобы они указывали на URL «А-типа».

В Search Console
есть лимиты на количество отправляемых в Google страниц (в новой версии эти
ограничения, похоже, варьируются от сайта к сайту), а простого процесса для
массовой отправки URL
на данный момент нет. Поэтому сосредоточьтесь на высоко авторитетных страницах
и страницах, которые расположены выше в структуре внутренних ссылок. Это должно
побудить Google также
пересканировать те страницы, что расположены ниже – как минимум, до некоторой
степени.

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

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

Сценарий 4. Отмена
переадресации при смене домена

Допустим, вы перевели сайт на новый домен и спустя несколько недель заметили, что ваш домен также является названием кавер-группы Nickelback. Конечно, вы начнёте паниковать. Во-первых, успокойтесь. Трезво оцените, действительно ли проблема настолько серьёзна. Если это так, то тогда эта ситуация похожа на сценарий №3, но более рискованна, поскольку в данном случае имеются аспекты, связанные с вашим доменом и его историей, которые могут влиять на ранжирование независимо от того, насколько хорошо или плохо вы реализовали 301 редиректы.

Если у вас действительно нет выбора, то потребуется
выполнить следующие шаги:

• Удалить все 301 редиректы с A→B
• Добавить переадресацию на уровне сайта с B→A
• Добавить самореферентные rel=canonical на все страницы
• Обновить внутренние ссылки, чтобы они указывали
  на домен А
• Повторно добавить домен А в Search Console
• Перестроить файлы Sitemap.xml для домена А
• Отправить критически важные страницы в Google через Search Console
• Обновить выбранные входящие ссылки, чтобы они
  указывали на домен А

В данном случае вам потребуется отдельный аккаунт в Search Console. Если вы удалили
старый профиль, повторно добавьте его и воссоздайте файлы XML Sitemap. Чтобы ускорить процесс,
отправьте в Google критически важные страницы.

Если у вас нет доступа к домену B (например, у него истёк срок регистрации и его перехватил кто-то другой), то вы не сможете настроить переадресацию с B→A. Правда в том, что в данном сценарии процесс отмены будет длинным и непростым. Вторичные сигналы, такие как входящие ссылки, в данном случае будут очень важными.

Как повторно отправить страницы в Search Console?

Ниже – те шаги, которые нужны для отправки запроса на
индексацию или повторную индексацию страницы:

• Проверьте
  URL в соответствующем инструменте в Search Console. Чтобы повторно отправить
  страницу в индекс Google,
  сначала её нужно будет проверить.
• Запросите
  повторное индексирование. Search Console
  вернёт страницу с текущим статусом URL и некоторой дополнительной информацией. Индексируете ли вы
  страницу впервые или повторно, в обоих случаях нажмите «REQUEST INDEXING». В
  большинстве сценариев, связанных с отменой 301 редиректов, вам нужно получить
  статус «URL is on Google».
  Если URL пока не
  проиндексирован, то остальная часть страницы будет содержать информацию с
  результатами диагностики.

Это всё, что вам нужно сделать. В итоге Google должен вернуть следующее окно:

Теперь скрестите пальцы и ждите. Повторная индексация может
занимать разное время и заранее его спрогнозировать невозможно.

Пара примечаний по этому процессу. Во-первых, на данный момент переиндексация выполняется довольно медленно. Во-вторых, у Google определённо есть лимиты на то, как часто вы можете использовать этот инструмент. Однако эти лимиты варьируются от сайта к сайту. К сожалению, опции массовой переиндексации в Search Console нет. При всех масштабных изменениях вам придётся полагаться в первую очередь на обновление XML-карт сайта.

Вместо заключения –
ещё одно примечание и предупреждение

Помните, что наибольшее различие между теорией и практикой в этих ситуациях состоит в том, что реальные сайты часто посылают смешанные сигналы. Если вы отменяете 301 редирект, вы уже посылаете смешанный сигнал (в сравнении с вашими прошлыми сигналами). Если наряду с этим изменением у вас имеются несоответствующие внутренние ссылки, некорректные атрибуты rel=canonical, устаревшие XML-карты сайта или слишком длинные цепочки редиректов, которые не всегда возвращают одну и ту же страницу, то тогда риски будут ещё выше, а сам процесс отмены займёт больше времени. Убедитесь, что все ваши новые сигналы согласованы с этим изменением.

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

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

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

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

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

• Редирект:
  • Когда нужно делать?
  • Когда можно делать?
  • Когда не стоит делать?
• Очень важные рекомендации!
• Практика редиректа:
  • Через .htaccess
  • Через PHP
  • Через nginx
• Проверка http-заголовков

Когда НЕОБХОДИМО делать 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 редирект очень любят применять правильные сеошники для борьбы с различными дублями страниц. Почему только правильные сеошники? Да потому, что неправильные хуй забили на сайт клиента и, что вполне вероятно, даже не заходя на сайт, стали закупать ссылки – увы, это не редкость. Ко мне периодически обращаются заказчики, которые хотят проверить добросовестность своих подрядчиков/сотрудников, отвечающих за оптимизацию и продвижение сайта, насколько качественно идет работа – заказывают seo аудит сайта – и пока еще ни разу не было такого, чтобы я не нашел на сайтах ошибок или недоработок. Так что, имейте в виду – я всегда рад вам помочь. Вернемся же к дублям – я считаю, что вместо того чтобы закрывать дубли от индексации, необходимо делать редирект на основной адрес, а всякие rel=”canonical” это уже не так интересно. Разумеется, существует масса случаев, когда дубли вынужденные, и тогда без канонизации не обойтись, но если есть возможность сделать редирект, обязательно делайте его. Частые случаи дублей, которые необходимо проверять всегда: адреса со слешем на конце и без, адреса с параметрами и метками – как это решать, я расскажу ниже.

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

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

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

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

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

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

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

Если с вашим доменом случились проблемы, например, фильтры, бан и т.п., и вы решили сменить адрес сайта (домен), то не стоит делать 301 редирект со старого домена на новый — в результате вы «приклеите» к новому домену и все проблемы старого. То есть в итоге ничего и не изменится. Да, было какое-то время решение выхода из под гугло-фильтра Пингвин при помощи полного 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. Это даже мне взорвало мозг, а представьте, что подумал бы поисковый робот, попав в такую карусель! Мало того, что в цепочке поучаствовали три разных домена, так еще и страница ошибки говорит, что она не ошибка и ее надо индексировать.

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

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

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

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

Вообще рекомендую прочитать официальные мануалы от поисковиков по теме: Переадресация 301 от Google и Обработка перенаправлений (редиректов) от Яндекс.

Permanent Redirect 301 через .htaccess

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

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

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

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

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

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

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

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

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

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

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

Либо

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

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

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

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

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

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

RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

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

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

RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L] #site.ru надо заменить на ваш домен

RewriteCond %{HTTP:X-Forwarded-Protocol} !=https
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Если возникает циклический редирект, то воспользуйтесь этим вариантом:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

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

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

Недавно я написал очень подробную инструкцию как правильно перевести сайт с HTTP на HTTPS без потерь. Если вы планируете переезд с https на https, вы обязаны ее прочитать!

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

• RewriteCond обозначаем условие, при совпадении с которым будет выполнено правило RewriteRule. С помощью регулярных выражений задаются шаблоны строк.
• Переменные сервера:
  • %{REQUEST_URI} — часть урла без доменного имени и GET-параметров, например, для страницы, которую вы сейчас читаете: blog/post/4393,
  • %{HTTP_HOST} — хост или доменное имя, например: alaev.info
  • %{QUERY_STRING} — строка с набором GET параметров, то есть часть урла после знака вопроса (и до решётки якоря, если он есть).
  • %{REQUEST_FILENAME} — полный путь в файловой системе сервера к файлу или скрипту соответствующим этому запросу. Чтобы было понятно, адрес скрипта, как нам это привычно такой — alaev.info/index.php, а вот в файловой системе сервера это страшная строка /var/www/alaev_info/data/www/alaev.info/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) останавливает процесс преобразования, и текущая ссылка считается окончательной.

Самый популярный случай — 301-редирект с 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} ^[A-Z]{3,9} /index.(php|html|htm) HTTP/ 
RewriteRule ^(.*)index.(php|html|htm)$ $1 [R=301,L]

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

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

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

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

Чтобы вам был понятен принцип, я приведу еще один пример, его как раз предложили решить в комментариях. Иногда вы можете обнаружить у себя вот такие ссылки:
http://site.ru/&sa=U&ei=AsguT72dLdHLtAaZ0tyVDQ&ved=0CCwQFjAIOFo&usg=AFQjCNFwbE9i0bqrQUGJLoDh6xyVd1nhxg
Что печально — эти ссылки индексируются Гуглом и попадают в выдачу.

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

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

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

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

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

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

RewriteCond %{QUERY_STRING} ^utm_source= [NC]
RewriteRule (.*) $1? [R=301,L]

Как вы понимаете, значение «utm_source=» можно заменить на вашу «abrakadabra» и так жу будет происходить 301-редирект на адрес без всякой абракадабры.

Пример избавления от параметров скрипта в url страницы

Пусть мы хотим в адресе http://site.ru/index.php?lang=ru избавиться от параметра lang=ru так, чтобы на выходе получить http://site.ru/index.php.

В .htaccess необходимо прописать такие строки:

RewriteCond %{QUERY_STRING} ^lang=ru$
RewriteRule ^(.*).php?(.*)$ $1.php [R=301,NC,L]

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

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

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

Исходный 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 [R=301,L]
RewriteRule ^post/(.*)$ blog/post/$1 [R=301,L]

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

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

Из этого же примера видно, что важно соблюдать последовательность правил. Если бы я поменял строки местами, то есть впереди бы шла строка RewriteRule ^post/(.*)$ blog/post/$1 [R=301,L] то редирект с адреса https://alaev.info/post/category/seo шел на страницу https://alaev.info/blog/post/category/seo а не как надо на https://alaev.info/blog/category/seo.

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

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

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

RewriteRule ^(.*)index.php$ $1 [R=301,L]

А в итоге при обращении к странице: http://site.ru/razdel/podrazdel/index.php
Редиректит на что-то подобное: http://site.ru/home/site.ru/public_html/razdel/podrazdel/

Т.е. почему-то выводит полный путь от корня сервера.

Для решения этой проблемы (и не только этой, кстати) необходимо, чтобы в начале .htaccess файла стояла не просто строка RewriteEngine On, но после нее шла еще одна, которая обрезает полный путь (от корня сервера) до корня сайта, вот так:

RewriteEngine On
RewriteBase /

301-редирект со страницы на страницу, на новый адрес

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

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("HTTP/1.1 301 Moved Permanently");
header("Location: http://site.ru");
die("Redirect");

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

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

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

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

Однажды у меня возникла проблема, что в панели вебмастера вылезла куча 404 ошибок, адреса этих страниц были вида https://alaev.info/https://alaev.info/post/4358, т.е. откуда-то в адресе появился дублирующий адрес сайта. И тогда я написал функцию, которая проверяет, есть ли в URI (заметьте, не URL, а URI) вхождение «http://alaev.info», и если присутствует, то вырезаем из адреса этот кусок и записываем результат в переменную $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");
}

Вот такая вот простейшая функция, которая смотрит, есть ли в запрошенном адерсе страницы слеш на конце, и если он есть, то слеш обрезается и происходит 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 www.site.ru;
	rewrite ^ http://site.ru$request_uri? permanent;
}

Редирект для домена с site.ru на www.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 (вот ссылка на него), но интернеты мне посоветовали обратить внимание именно на него. Если у вас есть варианты получше, пожалуйста, отпишитесь в комментариях.

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