Ошибка redirect true - Не ошибается лишь тот, кто ничего не делает!

I’m redirecting to an Error page with a prettified error message in my Application_Error, in Global.asax.

At the moment it says:

Response.Redirect("Error.aspx", true);

Should that be:

Response.Redirect("Error.aspx", false);

I’m not sure under which circumstances I should use true and which I should use false? The MSDN page says to prefer using false to avoid ThreadAbortExceptions, so when should I use true?

asked Jul 15, 2011 at 13:10

Jackson PopeJackson Pope

14.5k6 gold badges56 silver badges80 bronze badges

You use false when you don’t want to abort the thread. What that means is that false will cause the code to continue to execute. So lines of code which appear after the Response.Redirect will be executed. A true will just kill the thread so nothing further will execute, which in turn throws a ThreadAbortException.

So it’s really a judgment call based on how the rest of the code in that situation looks. Generally you want to put calls to Response.Redirect at the end of an execution path so that nothing further needs to be executed. But many times that’s not the case. It’s just a matter of how you control the logic flow in the code.

For example, if the next line after Response.Redirect is a return and the execution path simply ends, then you’re probably fine. But if there’s all kinds of logic and executing it in this case would leave the system in an unknown state, then you may want to abort the thread.

Personally I consider aborting the thread to be indicative of poor logic control. It’s similar to a well known code smell where exceptions are used to control logic flow, which is universally frowned upon. If you can control the logic flow without the need for aborting a thread and throwing an exception, that would probably be preferred.

answered Jul 15, 2011 at 13:17

Response.Redirect(URL,false): The client is redirected to a new page and the current page on the server will keep processing ahead.

Response.Redirect(URL,true): The client is redirected to a new page, but the processing of the current page is aborted.

You can also see this video which demonstrates the differences Response.Redirect ( False vs True) ASP.NET Interview questions with answers.

answered Jul 30, 2013 at 12:44

You never need to use true, as there is an overload without the boolean parameter.

Response.Redirect("Error.aspx", false);

Response.Redirect("Error.aspx");

The boolean parameter was added so that you could set the redirect without stopping the execution. If you can exit out of the page code yourself without that causing any extra cost, like for example data binding occuring, that is preferable.

answered Jul 15, 2011 at 13:29

GuffaGuffa

684k108 gold badges733 silver badges1000 bronze badges

Here it is best to use true, because you want all the other threads to abort; there has been an error and the application cannot continue.

answered Jul 15, 2011 at 13:13

τεκτεκ

2,9541 gold badge16 silver badges13 bronze badges

If you set it to true, the application ends the response and sends it back to the user, and if you set it to false the code after the redirect will continue to be executed, and the user will be redirected to the new page after the full page-load life cycle ends.

answered Jul 15, 2011 at 13:15

AtzoyaAtzoya

1,37713 silver badges30 bronze badges

Источник

Let us demonstrate above explanation practically by creating one simple web application are as follows

Start» — «All Programs» — «Microsoft Visual Studio 2010».
«File» — «New Project» — «C#» — «Empty Web site » (to avoid adding a master page).
Provide the project a name such as ResponseTrueAndFalse or another as you wish and specify the location.
Then right-click on Solution Explorer and select «Add New Item» then select Default.aspx page.
Add another page and rename it as GetData.aspx.
Drag and Drop one button onto the Default.aspx page.

Now the solution explorer will be look like as follows

Now the Default.aspx source code will be as follows:

<%@ Page Language=«C#» AutoEventWireup=«true» CodeFile=«Default.aspx.cs» Inherits=«_Default» %>
<!DOCTYPE html PUBLIC «-//W3C//DTD XHTML 1.0 Transitional//EN» «http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd»>
<html xmlns=«http://www.w3.org/1999/xhtml»>
<head id=«Head1» runat=«server»>
<title>Article by Vithal Wadje</title>
</head>
<body bgcolor=«blue»>
<form id=«form2» runat=«server»>
<h4 style=«color: White;»>
Article for C#Corner
</h4>
<div>
</div>
<asp:Button ID=«Button1» runat=«server» OnClick=«Button1_Click» Text=«Redirect» />
</form>
</body>
</html>

Now open the default.aspx page and write the following code on button click event are as

protected void Button1_Click(object sender, EventArgs e)
{
Session[«BeforeMsg»] = «Code written Before page Redirecting»;
Response.Redirect(«GetData.aspx»,true);
Session[«after»] = «code written after page Redirecting»;
}

Code explanation

In the above code sample ,we are calling response.Redirect method and before and also after Response.Redirect method ,we are storing one sting message to the session which will accessed on another page.

The above code will not be execute the code written after the Response.Redirect method because we are ing true values in Response.Redirect method which means terminate the current page execution and redirect to the GetData.aspx page.

Now open DetData.aspx.cs Page and write the following code on page load as

protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Session[«BeforeMsg»] + «</br>»);
Response.Write(Convert.ToString(Session[«after»]));
}

Code explanation

In the above code sample, we are accessing the session values which are stored in session before and after page redirecting.

Whole code of the default.aspx.cs and GetData,aspx.cs will be as follows :

default.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text;
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void Button1_Click(object sender, EventArgs e)
{
Session[«BeforeMsg»] = «Code written Before page Redirecting»;
Response.Redirect(«GetData.aspx»,true);
Session[«after»] = «code written after page Redirecting»;
}
}

GetData,aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class GetData : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Session[«BeforeMsg»] + «</br>»);
Response.Write(Convert.ToString(Session[«after»]));
}
}

Now run the application then the page will look like as follows

Now click on above button then the Page will be redirected to the Next page that is GetData.aspx page as

In the above image you have seen that only session value is displayed which is set before the Response.Redirect method because we used true value in Response.Redirect(«GetData.aspx»,true) method so the current page execution is terminated and redirected to the next page instead of executing code which is written after the Response.Redirect method.

Now let us change in code which will execute the code which is written after the Response.Redirect as

protected void Button1_Click(object sender, EventArgs e)
{
Session[«BeforeMsg»] = «Code written Before page Redirecting»;
Response.Redirect(«GetData.aspx»,false);
Session[«after»] = «code written after page Redirecting»;
}

Now run the application and click on Redirect button, it will shows the following output

In the above image you have seen that both session values are displayed which are set before and after the Response.Redirect method because we used false value in Response.Redirect(«GetData.aspx»,false) method so the current page execution not terminated and it execute code which is written after the Response.Redirect method and then redirect the page to the GetData.aspx

From all above explanation we have learned the difference between the true and false property and also when to use true and false in the Response.Redirect method.

Notes

Download the Zip file from the attachment for the full source code of the application.

Summary

I hope this article is useful for all readers, if you have any suggestion then please contact me including beginners also.

Источник

Что такое редирект?

Редирект (или перенаправление, переадресация, форвардинг) — это способ, который позволяет один и тот же документ сделать доступным с других адресов (URL’ов).

300 редирект — множественный выбор

300 Multiple Choices

Множественный выбор (Multiple Choices) — это вид редиректа, который применяется для автоматического (или в некоторых случаях — ручного) принятия решения браузером: какой именно документ показать пользователю, в зависимости от предпочтений конкретного пользователя.

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

Как это работает?

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

Но вот вдруг этот пользователь запрашивает страницу сайта, и в ответ получает 300-й код редиректа вместе со списком характеристик и адресов, на которые следует перейти.

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

301 редирект — перемещен навсегда

301 Moved Permanently

Перемещен навсегда (Moved Permanently). Редирект сообщает браузеру и поисковой машине о том, что запрошенный адрес страницы не существует. И навсегда перемещен по новому адресу, который указывается в заголовке после Location, где его впредь и следует искать.

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

Как это работает?

Браузер клиента (или поисковая машина), при запросе некоторого адреса, вдруг получает в ответ 301 Moved Permanently.

В идущих за данным ответом служебных заголовках ищется такой, который начинается на «Location:», и загружается страничка с новым адресом, указанным после двоеточия.

Данный редирект кэшируется.

302 редирект — документ найден

302 Found, 302 Moved Temporarily

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

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

Как это работает?

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

Кэширование производится только в случае наличия заголовка Cache-Control или Expires.

303 редирект — смотри другое

303 See Other

Смотри другое (See Other) — это специальный редирект, который говорит о том, что запрошенный документ найден. Но на него следует перейти используя метод GET, вне зависимости от того метода, каким был запрошен исходный документ.

Данный редирект был введен вместе с 307 для устранения неоднозначности c 302 редиректом: нужно ли менять метод запроса документа (GET, POST, HEAD — 303 редирект), или нет — 307 редирект.

Где это используется?

303 редирект используется достаточно редко.

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

Данный редирект запрещен к кэшированию.

304 редирект — не изменялось

304 Not Modified

Не изменялось — сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

Как это работает?

Браузер запросил документ, и передал вместе с запросом временные или иные метки в заголовках Last-Modified или ETag.

При следующем обращении браузера к этой странице, он должен передать эти метки в заголовках If-Modified-Since и If-None-Match соответственно.

Если документ не изменился с прошлого запроса, сервер вместо страницы документа, выдает в ответ 304 редирект.

Браузер берет из своего локального кеша страницу, сохраненную при прошлом запросе, и показывает ее пользователю.

305 редирект — используй прокси

305 Use Proxy

Используй прокси (Use Proxy) — данный редирект означает, что доступ к этой странице или сайту возможен только через прокси, адрес которого передается в заголовке Location.

Как это работает?

Браузер запрашивает страницу.

В ответ сервер выдает 305 редирект, и в заголовке Location передает адрес прокси-сервера.

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

306 — не используется

306 (Unused)

306 редирект на данный момент не используется.

Он использовался в прошлых реализациях http-протокола, и на данный момент зарезервирован для дальнейшего использования. Упомянут в RFC 2616 (обновление HTTP/1.1).

307 — временный редирект

307 Temporary Redirect

Временный редирект (Temporary Redirect) означает, что необходимо запросить документ, переданный в заголовке Location тем же методом (GET, POST, HEAD), что и исходный документ.

Данный редирект был введен вместе с 303 для устранения неоднозначности c 302: стоит ли менять метод запроса документа (GET, POST, HEAD — 303 редирект), или нет — 307 редирект.

Как это работает?

Браузер или робот поисковой системы запрашивает

Данный редирект временный. Кэширование следует производить только в случае наличия в ответе сервера заголовков Cache-Control или Expires.

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

Делаем редирект на php

В php есть замечательная функция header(), которая разрешает не только подменять стандартные заголовки, но и добавлять новые.

void header ( string string [, bool replace = true [, int http_response_code]] );

Первый параметр string — полностью сформированная строка заголовка, который необходимо добавить (без завершающего перевода строки «n»)

Второй параметр replace указывает, нужно ли заменять заголовки с одинаковыми именами (true), или же добавлять в конец (false).

Параметр http_response_code указывает код http-ответа (300, 301, 302 и т.д.).

Пример редиректа на php

header( 'Location: http://yandex.ru/yandsearch?text=redirect', true, 301 );

Делаем редирект в .htaccess

Для осуществления редиректа в .htaccess, можно использовать любую из трех директив Apache (Апач, httpd): Redirect, RedirectMatch, либо RewriteRule (при включенном RewriteEngine).

Redirect [status] URL-path URL-to-redirect

Необязательный параметр status — это три цифры — код редиректа (например, 301). Если не указан, то по умолчанию подставляется 302.

URL-path — часть запрашиваемого пользователем (или поисковиком) адреса, которая должна обязательно начинаться со слеша (/).

URL-to-redirect — полный адрес сайта (и, возможно, часть пути), на который будет осуществляться редирект. Должен быть вида http: //site.ru/ — то есть обязательно должен присутствовать протокол (http://) и закрывающий адрес сайта слеш (/).

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

Если URL-path заканчивается слешем, то редирект сработает не только для указанного адреса, но и для всех, которые начинаются на указанный. А к URL-to-redirect будет добавлена часть адреса, следующая за последним указанным слешем в URL-path.

Пример

Redirect 301 /hello.html http://google.ru/search?q=bye

Делаем редирект на html

Это особый вид редиректа. Так как он располагается в заголовке html-документа, то страница, на которой он расположен, с одной стороны является полноценной страницей — на най может присутствовать текст, картинки и т.д. А с другой — это редирект, который срабатывает через несколько секунд (или сразу же, если указать задержку в 0 секунд).

<meta http-equiv="refresh" content="seconds;URL-to-redirect">

Первый параметр seconds — это количество секунд (после полной загрузки страницы), по истечении которых произойдет редирект на второй параметр URL-to-redirect.

Пример

Данный редирект должен располагаться в секции <head> html-документа, таким образом:

<head>
    <meta http-equiv="refresh" content="seconds; URL-to-redirect">
</head>
<body>
    текст страницы
</body>

Редирект при помощи javascript

Редирект, написанный на яваскрипт (или же джаваскрипт — как кому больше нравится), хотя и не отдает 3xx редирект, но все же позволяет переадресовывать пользователей на нужную страницу.

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

<script type="text/javascript">
    location="http://yandex.ru";
    document.location.href = "http://yandex.ru";
    location.replace("http://yandex.ru");
    window.location.reload("http://yandex.ru");
    document.location.replace("http://yandex.ru");
</script>

PHP
Редиректы
Примеры

Источник

В моем проекте Django я создаю собственную страницу администратора (НЕ admin из Django). У меня 2 страницы входа. Один для администратора, второй для других пользователей.

Ниже вы можете увидеть файл urls.py для admin. Я тестирую его, и он отлично работает. После успешного входа в систему Django перенаправляет пользователя на URL-адрес, который был следующим параметром (/administration/dashboard/).

Я написал unit тест, и он вызывает ошибку. Из-за ошибки я понимаю, что Django перенаправляет URL-адрес по умолчанию (/accounts/profile/). Почему unit тест не использует настройки, которые я сделал в файле urls.py (следующий параметр)?

Как решить эту проблему?

Прямо сейчас я замечаю, что проблема исчезает, только если я использую этот код LOGIN_REDIRECT_URL = '/administration/dashboard/' в settings.py. Я не могу использовать его, потому что в будущем я буду использовать LOGIN_REDIRECT_URL для моей другой страницы входа.

Я был бы признателен за любую помощь!

urls.py:

from django.contrib.auth import views as authentication_views

urlpatterns = [
    # Administration Login
    url(r'^login/$',
        authentication_views.login,
        {
            'template_name': 'administration/login.html',
            'authentication_form': AdministrationAuthenticationForm,
            'extra_context': {
                'next': reverse_lazy('administration:dashboard'),
            },
            'redirect_authenticated_user': True
        },
        name='administration_login'),
]

tests.py:

class AdministrationViewTestCase(TestCase):
    def setUp(self):
        self.client = Client()
        self.credentials = {'username': 'user', 'password': 'password'}
        self.user = User.objects.create_user(self.credentials, is_staff=True)
        self.data = dict(
            self.credentials,
            next=reverse("administration:dashboard")
        )

    def test_administration_authorization(self):
        self.assertTrue(self.user)

        # logged_in = self.client.login(**self.credentials)
        # self.assertTrue(logged_in)

        response = self.client.post(
            reverse("administration:administration_login"),
            self.data,
            follow=True
        )
        # self.assertEqual(response.status_code, 302)
        self.assertRedirects(
            response,
            reverse("administration:dashboard"),
            status_code=302,
            target_status_code=200
        )

ОШИБКА:

Traceback (most recent call last):
  File "/home/nurzhan/CA/administration/tests.py", line 51, in test_administration_authorization
    reverse("administration:dashboard"),
  File "/srv/envs/py27/lib/python2.7/site-packages/django/test/testcases.py", line 271, in assertRedirects
    % (response.status_code, status_code)
AssertionError: Response didn't redirect as expected: Response code was 200 (expected 302)

forms.py:

from django import forms
from django.contrib.auth.forms import AuthenticationForm
from django.utils.translation import ugettext_lazy as _


class AdministrationAuthenticationForm(AuthenticationForm):
    """
        A custom authentication form used in the administration application.
    """
    error_messages = {
        'invalid_login': (
            _("ERROR MESSAGE.")
        ),
    }
    required_css_class = 'required'

def confirm_login_allowed(self, user):
    if not user.is_active or not user.is_staff:
        raise forms.ValidationError(
            self.error_messages['invalid_login'],
            code='invalid_login',
            params={
                'username': self.username_field.verbose_name
            }
        )

login.html:

<form action="{% url 'administration:administration_login' %}" method="post">
  {% csrf_token %}
  {{ form.as_p }}
  <input type="submit" value="Submit">
  <input type="hidden" name="next" value="{{ next }}"/>
</form>

Источник

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

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

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

Как работает редирект

В настройках сайта указывается адрес страницы (донора), с которой посетитель должен перенаправляться , например, www.kokoc.com, и страницы (акцептора), на которую он должен попасть, например, kokoc.com.

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

Посетитель вводит в адресную строку браузера адрес www.kokoc.com.
Браузер обращается к серверу сайта, запрашивая страницу www.kokoc.com.
Сервер обрабатывает запрос, последовательно применяя все правила, которые прописаны в его настройках.

На каком-то шаге он обнаруживает инструкцию «со страницы с WWW нужно переадресовать посетителя на страницу без WWW» и отправляет в ответ браузеру страницу с адресом kokoc.com. Если правило было прописано на самом начальном этапе обработки запроса — до загрузки контента первой страницы — переадресация пройдет максимально быстро и незаметно для пользователя.

Посетителю в браузере загружается контент страницы kokoc.com.

В каких случаях нужны редиректы

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

Редирект на сайте используется почти для таких же целей:

добавляют или не добавляют перед доменом префикс WWW — рудимент, оставшийся еще с эпохи зарождения интернета;
ставят или не ставят в конце слеш (/);
пишут адрес заглавными буквами или строчными;
указывают или не указывают расширения .html, .htm, .php и т. д.

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

Как бы не запутаться в зеркалах!

Кроме того, поисковые системы не понимают, что зеркала — это вариации адреса одной и той же страницы. Например, для Google и «Яндекса» это 4 разных URL:

www.kokoc.com
kokoc.com
www.kokoc.com/
kokoc.com/

Они будут индексироваться отдельно, в результате возникнет дублирование контента.

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

Перенаправление с HTTP на HTTPS или обратно

После внедрения защищенного протокола HTTPS возник еще один вариант зеркала. URL на HTTP и на HTTPS также воспринимаются поисковыми системами как разные.

С HTTP на HTTPS тоже нужен редирект

Переезд на другой домен

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

Смена CMS сайта

У нового движка может быть другой алгоритм формирования URL страницы. К примеру, если на старом сайте адрес страницы товара имел вид site.ru/catalog/tovar, то на новом это site.ru/product/tovar. Нужно настраивать редирект всех таких страниц, чтобы не потерять позиции в поисковых системах и трафик.

Переадресация на мобильную версию

Если для адаптации сайта под мобильные вы выбрали вариант с отдельной мобильной версией, то нужно перенаправлять всех посетителей с мобильных устройств на нее. Например, основной адрес вашего сайта — site.ru, а мобильной версии — m.site.ru. Благодаря настройке редиректа сервер будет определять устройство посетителя, и если он использует смартфон или планшет — перенаправлять его на адрес с префиксом m.

Появление поддоменов

При расширении сайта часто принимается решение вынести отдельные каталоги товаров или услуг на поддомены. Например, вы сделали для бытовой техники поддомен bt.your-site.ru, а значит, понадобится редирект всех старых адресов раздела your-site.ru/bt на адреса bt.your-site.ru.

Удаление страниц

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

К примеру, у вас были страницы двух отдельных услуг: подготовки рекламных объявлений для PPC (site.ru/uslugi/kreativy) и комплексного запуска рекламных кампаний (site.ru/uslugi/reklama-ppc). Вы некоторое время активно продвигали обе услуги: покупали ссылки, создавали посты со ссылками на эти страницы в соцсетях и т. д. Но позже пришли к выводу, что подготовка объявлений как отдельная услуга не оправдывает себя, и стали предоставлять ее только в рамках комплексного запуска.

Хороший выход — удалить (скрыть) страницу о подготовке объявлений и поставить с нее редирект на страницу комплексного запуска. Конечно, позаботившись, чтобы на странице-акцепторе была информация, что подготовка рекламных объявлений входит в комплексную услугу. Так вы не потеряете ссылочный вес страницы и посетителей.

Изменение структуры сайта

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

Например, на вашем сайте в корне каталога был небольшой раздел «IP-камеры» с парой десятков товаров (site.ru/catalog/ip-camery). Постепенно вы расширили ассортимент продаж и решили создать целый раздел «Видеонаблюдение», а уже в нем подразделы с камерами, регистраторами и т. п. Странице с IP-камерами пришлось сменить адрес на site.ru/catalog/videonabludenie/ip-camery. Что делать, чтобы не потерять ее позиции в ПС, посещаемость, ссылочный вес? Конечно же поставить редирект с site.ru/catalog/ip-camery на site.ru/catalog/videonabludenie/ip-camery.

Перенаправление с устаревших страниц

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

Например, был некий популярный товар X. По каким-то причинам производитель снимает его с производства, и выпускает товар Y — с небольшими доработками, немного другим дизайном, но все равно это почти полный аналог X. Здесь два варианта решения:

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

Классификация редиректов: отличия и применение

Все редиректы можно классифицировать по двум признакам:

По типу переадресации. Каждому редиректу присваивается определенный тип — 301, 302, 307 и т. д. Он одновременно означает и код протокола HTTP, который будет выдаваться в ответ на запрос адреса страницы-донора, и статус этой страницы для поисковых систем.
По способу реализации редиректа. Переадресацию можно настроить с помощью панели управления сайтом, директив файла .htaccess, PHP-скриптов, JavaScript и так далее.

Разберем отличия и применение каждого подвида.

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

300 «Множественный выбор» (Multiple Choices)

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

301 «Перемещена навсегда» (Moved Permanently)

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

302 «Перемещена временно» (Moved Temporarily)

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

303 «Смотри другое» (See Other)

Используется редко. В отличие от 301 или 302 редиректа этот код ответа не говорит, что «страница перемещена». Он говорит: «то, что ты хочешь, есть на другой странице, посмотри ее». На практике в основном, встречаются два варианта его использования:

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

304 «Не модифицировано» (Not Modified)

Используется редко и поддерживается не всеми браузерами. Применяется в случаях, когда на странице есть заголовки If-Modified-Since и Last-Modified. Если со времени последнего посещения на странице ничего не менялось, сервер советует браузеру, чтобы тот брал страницу из кеша. А для поисковых ботов это сигнал, что можно не переобходить страницу. В результате экономится краулинговый бюджет.

305 «Используй прокси» (Use Proxy)

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

306 — зарезервировано

Этот вид применялся раньше, но был отменен за ненадобностью. Сейчас он в статусе «зарезервирован» и не используется. Если в будущем появится необходимость в отдельном коде переадресации, вполне можно использовать 306.

307 «Временная переадресация» (Temporary Redirect)

Аналогичен 302-му, но с небольшими отличиями:

307 редирект более новый и точный. Создан для HTTP 1.1.;
более корректно, чем 302 редирект, обрабатывает переадресацию запросов с методом POST;
поддерживается не всеми браузерами, поэтому в большинстве случае лучше использовать переадресацию 302 типа.

308 «Перемещено навсегда» (Permanent Redirect)

Аналог 301-го редиректа. Отличается тем, что сохраняет POST-метод обработки запроса, не меняя его на GET. Редиректы 301 и 308 обрабатываются Google-ботом одинаково.

Способы реализации редиректов

Все реализации редиректов можно разделить на 2 группы:

Серверные. Переадресации с помощью правил .htaccess, панели управления хостингом, PHP-скриптов — это примеры серверных реализаций. Такие редиректы происходят очень быстро, практически моментально, так как выполняются еще на этапе обработки запроса сервером.
Браузерные. JavaScript, HTML, Meta-refresh — это браузерные редиректы. Они гораздо медленнее серверных, так как срабатывают уже после загрузки страницы или ее части в браузере.

Стандартные переадресации — с HTTP на HTTPS, со старого адреса на новый и т. д. —чаще всего реализуются с помощью серверных редиректов. Они надежные, быстрые и незаметные. Браузерные редиректы в этих случаях использовать крайне не рекомендуется: помимо медленного срабатывания, они могут не поддерживаться браузерами (тот же JavaScript может быть отключен).

Разберем подробнее.

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

Большинство популярных панелей управления позволяют добавить в настройках правила типовых редиректов: с адреса, начинающегося на WWW на адрес без WWW, с HTTP на HTTPS и подобные. Что-то более точное в панели можно настроить, но уже через .htaccess — просто открывать и редактировать его вы можете и из панели управления хостингом.

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

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

Важный момент: файл .htaccess существует только у сайтов под управлением веб-сервера Apache, но их — большинство.

Чтобы проверить, под Apache ваш сайт или нет, можно воспользоваться инструментом от Netcraft. Смотрите в разделе Hosting History, в колонке Web Server.

Kokoc.com — под управлением Apache

Редирект на серверах Ngnix

Если ваш сайт работает не под Apache, а под Ngnix, здесь все настраивается совершенно по-другому. Есть основной файл конфигурации для всех доменов на сервере — ngnix.conf, а есть отдельные файлы для виртуальных хостов, т. е. отдельных доменов.

Для редактирования правил используется терминал. Синтаксис переадресаций для Ngnix отличается от синтаксиса в .htaccess. Но есть специальные сервисы, например, Winginx, которые помогают преобразовать правила из .htaccess в правила конфигурации Ngnix.

Плагины CMS

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

OpenCart: Менеджер 301 редиректов, Менеджер редиректов для OpenCart 3.0.
Битрикс: Редиректы для SEO, Простой редирект страниц.
Joomla: Domainredirect.

Чтобы настроить в них редирект, вам потребуется только указать адреса страниц-доноров и акцепторов, или маску для их определения, а также основные параметры редиректа: постоянный, временный и т. п. Многие плагины имеют дополнительные преимущества: например, отслеживают изменение URL страницы-акцептора и соответственно меняют правило переадресации.

Особенно широкий выбор дополнений, конечно, в WordPress. Есть узкоспециализированные плагины, например, только для переадресаций на HTTPS (Easy HTTPS Redirection).

Простой плагин только для одной функции

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

Свыше 2 миллионов установок

А в арсенале Rank Math SEO не только настройка перенаправлений, но и большое количество других инструментов для оптимизации сайта.

В названии не просто так написано «лучший» — это действительно мегаполезное многофункциональное дополнение с хорошими отзывами

PHP-редирект

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

Редирект через PHP оптимален в тех случаях, когда у вас много правил для отдельных страниц или групп страниц. Файл .htaccess может сильно нагружать сервер, из-за множества директив.

JavaScript-редирект

Это уже переадресация браузерного типа. Редирект произойдет только когда страница-донор будет загружена в браузере. JavaScript-редирект оптимально подходит для нескольких ситуаций:

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

Переадресация с задержкой

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

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

Подтверждение перехода по ссылке на сайте text.ru

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

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

HTML-редирект или meta-refresh

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

Пример кода тега meta refresh с задержкой перенаправления 2 секунды

У meta-refresh плохая репутация среди поисковых систем, так как этот метод довольно часто использовался для перенаправления на дорвеи. Кроме того, у meta-refresh есть и другие недостатки:

поддерживается не всеми браузерами;
приводит к ошибкам сканирования. Поисковый робот не сканирует страницу, на которой расположен метатег refresh, а сразу переходит к той, на которую ведет переадресация;
может определяться Google и «Яндексом» как спам, с соответствующими санкциями;
Google-бот может игнорировать страницы с этим метатегом и не индексировать их.

W3C (World Wide Web Consortium) не рекомендует использовать этот атрибут.

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

перенаправления посетителя после оформления заказа на страницу благодарности;
«подстраховки» переадресаций, реализованных на JavaScript — если браузер посетителя не поддерживает скрипты;
перенаправления посетителя на страницу со ссылками для загрузки корректных браузеров — если в его браузере ваш сайт будет отображаться и работать с ошибками.

Rel=«canonical»: редирект для поисковых систем

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

Тег rel=«canonical» сообщает краулеру, что страница, на которой он находится, не важна, не нужно ее индексировать и показывать в поиске. Зато есть аналогичная каноническая, оригинальная страница (в теге указывается ссылка) и нужно проиндексировать ее.

Как работает rel=«canonical». Источник: https://ahrefs.com

Атрибут rel=«canonical» используется для исправления проблемы с дублированным контентом, как и 301 редирект. В каких случаях какой метод лучше использовать — обсудим далее.

В каких случаях применять 301 редирект, а в каких — rel=«canonical»

Ситуация	301 редирект	rel=«canonical»
страница удалена или уже неактуальна	+	—
смена домена	+	—
страница навсегда перемещена	+	—
дублированный контент с точки зрения поисковых систем, но не пользователя (одинаковые описания товаров для разных цветов, размеров и т. п.)	—	+
дублированный контент с точки зрения пользователя (статьи на одну и ту же тему)	+	—
по сути одна и та же страница, но с разными url (сортировки товара в каталогах, страницы пагинации)	—	+
у вас есть сайты с похожим контентом. в индексе нужно оставить только один, но для пользователей вы хотите сохранить доступными все. это поддерживается только google, у яндекса канонический адрес не учитывается, если в его качестве указан url в другом домене или поддомене.	—	+

Примеры применения 301 редиректа и rel=«canonical»

Основное отличие ситуаций, в которых лучше использовать тег rel=«canonical», а не 301-й редирект, — вы хотите оставить страницу-донор доступной для пользователя.

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

Какой тип редиректа выбрать

Чаще всего правильным решением будет поставить 301 редирект. С точки зрения SEO в большинстве случаев это самая правильная переадресация:

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

Оптимальная реализация редиректа — через файл .htaccess:

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

Дальше мы будем говорить именно о настройке 301 редиректа через .htaccess как о самом оптимальном и распространенном методе.

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

Где найти файл .htaccess и как его редактировать

Конфигурационный файл обычно расположен в корневой папке сайта. Его можно найти двумя способами:

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

Для работы с FTP чаще используется Filezilla — простой и бесплатный FTP-клиент. Если вы и дальше планируете вносить изменения на сайт самостоятельно, установите эту программу, она еще не раз пригодится

Интерфейс Filezilla и файл .htaccess

Файл можно править прямо на сервере: в Filezilla нажмите на него правой кнопкой мыши и выберите «Просмотр/Правка». Но для многих новичков удобнее скачать файл на компьютер.

Открыть и редактировать .htaccess можно с помощью простого текстового редактора — стандартного «Блокнота» в Windows. Но лучше использовать специализированные программы — например, бесплатный Notepad++.

Файл .htaccess может находиться не только в корневой папке, но и во вложенных. Иерархия простая: правила, прописанные в корневом файле, распространяются на весь сайт, а прописанные во вложенном — только на каталог. При этом правила в .htaccess каталога приоритетнее правил в «главном» файле.

Если вы не можете найти .htaccess, варианта три:

Ваш сайт не под Apache. Как это проверить, мы писали выше;
Файл называется по-другому. Очень редко встречается, но возможно. Актуальное название можно уточнить у хостинг-провайдера: это может быть, например, .config, .htaccess.http, access.conf.
Файл еще не создан. Это самый распространенный случай. Нужно создать файл .htaccess и позже вписать в него директивы переадресаций.

Сделать новый файл .htaccess просто:

Создайте пустой текстовый файл с расширением .txt.
Переименуйте его, убрав имя и добавив расширение .htaccess. Файл готов.
Если вы работаете на macOS, файл без имени не будет виден. Тогда присвойте любое имя, а переименуете уже после загрузки на сервер.

Сделайте резервную копию файла

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

Котик плохого не посоветует

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

Внедряйте правила по одному и проверяйте после каждого изменения

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

Для работы с командами в .htaccess их надо разъяснить. Редиректы в .htaccess чаще всего прописываются с использованием модуля mod_rewrite. В этом случае в примерах кода вы увидите команды RewriteEngine On, RewriteCond, RewriteRule (см. ниже).

Также редирект можно настроить с помощью директив Redirect либо RedirectMatch — команд из модуля mod_alias. Это стоит знать, чтобы не «смешивать» директивы и условия из разных модулей.

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

Строки в .htaccess, которые начинаются со знака решетки (#), не считываются и не выполняются сервером. Поэтому в таких можно оставлять комментарии к правилам — что здесь и для чего вы делали.

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

Флаги

В конце директивы RewriteRule указываются флаги. Чаще всего это два флага — [L,R=301]:

L означает команду серверу прекратить преобразования после этой строки.
R=301 — обозначение редиректа и его тип.

Что должно быть в начале файла

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

RewriteEngine On. Включает механизм преобразований модуля mod_rewrite.
Options +FollowSymLinks. Часто требуется для корректной работы модуля.
RewriteBase. Это базовая часть URL, которая будет дописана в начале всех адресов, получившихся после преобразований по директивам .htaccess. Чаще всего в RewriteBase указывается только слеш (/). В этом случае подразумевается, что все URL начинаются от корня сайта.

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

Кириллические адреса

В .htaccess нельзя использовать кириллические имена сайтов. Необходимо преобразовать их в формат punycode. Можно воспользоваться любым whois-сервисом — в нем будет указан адрес сайта в этом формате.

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

Добавьте блок IfModule

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

Окружите фрагмент кода с правилами для mod_rewrite условием IfModule — это поможет избежать проблем.

Например, вы хотите добавить вот такую переадресацию:

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

Чтобы избежать ошибок, сделайте так:
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_HOST} ^www.domain.ru$ [NC]
RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]
</IfModule >

Сервер, увидев условие (If), проверит, установлен ли модуль mod_rewrite. Если нет — директивы внутри условия выполняться не будут.

Порядок правил имеет значение

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

Например, вы хотите перенаправлять URL вида site.ru/articles/…. на URL вида site.ru/blog/… Но при этом у вас есть страница site.ru/articles/faq, которую вам нужно перенаправить на URL site.ru/faq.

Если вы расположите вторую (частную) переадресацию в файле .htaccess ниже первой (более общей), то при получении запроса на страницу site.ru/articles/faq сервер дойдет до правила «перенаправляем все site.ru/articles/… на site.ru/blog/…» и выполнит его. Клиент попадет на страницу site.ru/blog/faq. Правильная переадресация не будет выполнена, так как она расположена ниже.

Почему нужно пробовать разные варианты

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

Попробуйте вариант с другим синтаксисом. Проще говоря, вам нужен код, в котором команды и условия написаны немного по-другому.

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

Используйте генераторы .htaccess

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

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

Некоторые генераторы, например, IKSWEB, предоставляют несколько вариантов кода — для разных версий Apache. также вы можете использовать:

Htaccess.ru
Aleydasolis.com
Htaccessredirect.net

Возможности Htaccess.ru

Как настроить 301 редирект в .htaccess

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

Редирект сайта с WWW — на без WWW

Первый вариант:

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

Второй вариант:

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

Редирект сайта без WWW на URL с WWW:

Первый вариант:

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

Второй вариант:

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

Редирект на HTTPS с HTTP

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

Второй вариант:

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]

Четвертый вариант:

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

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

На URL без слеша

Первый вариант:

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]

На URL со слешем

Первый вариант:

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

Второй вариант:

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

Заменяем два последовательных редиректа на один

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

Пример переадресации с URL с WWW сразу на адрес с протоколом HTTPS и без префикса WWW, минуя промежуточный редирект (с HTTP на HTTPS):

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

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

RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]

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

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

Проще всего воспользоваться директивой Redirect. Попробуйте один из вариантов:

Redirect 301 /old-page /new-page
или
Redirect 301 /old-page/ https://your-site.com/new-page

Можно перенаправить и с помощью модуля mod_rewrite:

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

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

Первый вариант:

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

Второй вариант:

RewriteRule ^old-catalog /new-catalog/$1 [R=301,L]

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

Первый вариант:

RewriteCond %{HTTP_HOST} ^old-your-site.com [NC,OR]
RewriteCond %{HTTP_HOST} ^www.old-your-site.com [NC]
RewriteRule ^(.*)$ https://new-your-site.com/$1 [L,R=301,NC]

Второй вариант:

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

Как проверить, правильно ли сделана переадресация

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

Как работает кеш в браузере

Еще лучше проверять статусы страниц с помощью специальных сервисов:
- Чекер от Websiteplanet.com
- Проверка редиректов Prcy-info.ru
- Redirect-checker.org
После настройки переадресации получили ошибку 500? Первое, что нужно сделать — проверить ваш код на опечатки, например, в адресе страницы, командах. Это самая распространенная причина.

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

Если сайт большой и вы сделали массовую переадресацию десятков, сотен страниц — для проверки можно использовать Screaming Frog SEO Spider. Он покажет статус ответа сервера по каждой странице и еще массу полезной информации.

Типичные ошибки переадресаций

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

Если вы сделаете 301 редирект там, где нужен тег rel=canonical, то можете ухудшить юзабилити сайта. Это, в свою очередь, скажется на позициях в ПС и продажах. О том, когда нужно выбирать канонизацию, а когда — редирект, мы подробно написали выше.

Редирект robots.txt

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

Страница-акцептор нерелевантна донору

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

Например, Google в Search Console может указать по таким переадресациям ложную 404 ошибку. Для него ситуация выглядит так: страница не существует, правильного редиректа на 404 не сделано, а 301 редирект «не считается», так как ведет на нерелевантную страницу.

Цепочки переадресаций

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

Например, вы удалили страницу A и поставили 301 переадресацию на страницу B. Позже удалили B и поставили редирект на страницу C. В итоге пользователь, который хочет попасть на страницу A, сначала перенаправляется на страницу B, а потом — на C.

Робот не понимает, зачем вы так делаете

В идеале редирект на странице A нужно исправить, поставив его сразу на страницу C.

А здесь робот доволен — редирект сделан правильно

Чем плохи цепочки редиректов:

они замедляют открытие конечной страницы, ухудшают поведенческие показатели сайта и Core Web Vitals;
поисковые роботы могут обработать не более 5-ти редиректов;
повышается риск возникновения циклических переадресаций, а они ведут к недоступности страницы.

Обнаружить множественные переадресации можно с помощью специальных сервисов:

Redirect Detective
Инструмент от Otzyvmarketing.ru
Расширение для Google Chrome — Redirect Path, и т. п.

Цепочки редиректов можно увидеть также в отчете Screaming Frog SEO Spider — он показывает число перенаправлений.

Циклические редиректы

Условный пример: вы настроили редирект со страницы A на страницу B, оттуда на страницу C. Но на странице C уже есть редирект на страницу A. Получается замкнутый круг переадресаций. Все URL в цепочке становятся недоступными для пользователей и поисковых систем.

Так и сломаться можно

На практике циклические переадресации часто возникают при путанице в правилах массового редиректа: страниц со слешем и без, с WWW и без и тому подобных.

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

Страницы с кодом 301 остались в карте сайта

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

Редирект ведет на 404 страницу

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

А сколько на вашем сайте таких дорог?

«Я все попробовал, но ничего не работает»

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

другие, ранее настроенные переадресации. В том числе, не в .htaccess, а в PHP;
версия Apache-сервера;
директивы, которые прописал хостер в главном конфигурационном файле Apache и т. д.

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

В техническом задании на настройку редиректов опишите все нюансы задачи, например:

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

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

Бонус: как с помощью 301 редиректа увеличить посещаемость сайта

До этого мы рассматривали ситуации, когда переадресация применяется как вынужденная мера для устранения ошибок: после удаления или переезда страниц, для «склеивания» появившегося дублированного контента и т. п.

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

Способ первый: объединяем статьи

Допустим у вас в блоге есть 2 статьи на похожую тематику, или освещающие один и тот же вопрос, но с разных точек зрения. Можно объединить их: написать одну большую статью, в которой будет информация из обеих. И поставить 301 редирект со старых статей на новый URL.

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

В итоге:

ссылочный вес и авторитет объединяемых страниц перейдет на новую;
поведенческие показатели вырастут — ведь объединенная статья полнее и лучше предыдущих;
profit! — вы получаете прирост трафика и позиций в поиске.

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

показываются по одним и тем же ключевым словам (каннибализация);
существенно отстают по трафику от конкурентов;
немного устарели и их нужно обновить.

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

Способ второй: склейка сайтов

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

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

Примерная стратегия:

Купить сайт, похожий на ваш по тематике.
Выбрать на нем страницы с хорошим ссылочным весом и трафиком, актуальной темой.
Сделать страницы с таким же контентом на своем сайте. В идеале дополнить и расширить его. Если у вас уже есть релевантные страницы — использовать их.
Поставить 301 редирект с каждого такого URL купленного сайта на ваши страницы.
Те URL купленного сайта, у которых слабые показатели ранжирования и посещаемости, можно направить на уже существующие релевантные страницы вашего сайта. Или удалить.
Остальные страницы можно удалить, или в крайнем случае — сделать 301 редирект на вашу главную.

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

10 главных мыслей статьи

В большинстве случаев оптимален 301 редирект. 302 и другие временные типы переадресаций настраивайте только если страница будет недоступна временно.
Лучше всего настраивать переадресации через файл .htaccess.
Если вы хотите, чтобы страница осталась доступна пользователям, но не индексировалась поисковой системой — используйте тег rel=«canonical», а не редирект.
Перед изменениями обязательно сделайте резервную копию .htaccess.
Располагайте директивы в .htaccess от частных к общим, используйте блок Ifmodule.
Внедряйте и проверяйте редиректы по одному. Проверяйте, очистив кэш браузера или специальными сервисами.
Избегайте цепочек переадресаций и циклических редиректов.
Страница-донор и страница-акцептор долдны быть релевантны другу другу, иначе поисковые системы будут считать такой редирект ошибкой.
Есть много готовых правил редиректов для разных случаев, часть из которых мы приводим в статье.
301 редирект можно использовать для склейки не очень эффективных страниц и сайтов и повышения роста трафика на страницу и позиций.

Источник

How to redirect to another page with PHP.

In this tutorial you’ll learn how to redirect in PHP.

We are going to see:

How to redirect to another URL by sending a location header.
How to redirect with or without using the header() function.
The most common mistake and how to avoid it.
…and more.

Let’s dive right in.

Contents

How redirection works.
How to redirect in PHP: the header() function.
Redirection and output (how to avoid the most common mistake).
How to redirect with an HTML meta tag.
How to redirect with JavaScript.
301 and 302 HTTP redirect codes.

How redirection works.

Redirection happens when you open a web page and you are sent automatically to a different URL.

Redirections can happen at two stages.

Let’s say that you go to page A, and then you are redirected to page B. This redirection can happen:

Before page A is loaded. Or,
After page A is loaded.

In the first case, you are immediately sent to page B before any content is received from page A.

An example of this is a form submission page: when you fill and submit the form, the page automatically redirects you to a different “thank you page”, without showing the form again.

In the second case, you open the first URL and your browser loads page A. After that, your browser is sent to page B, immediately or after a timeout.

This type of redirection happens often after an online payment: the payment confirmation page tells you that you are going to be redirected to the store’s page in a few seconds.

Now, let’s see how you can perform these operations in PHP.

In PHP, you can do a page redirect with the header() function.

Let’s see an example right away:

header('Location: https://www.google.com/');
die();

The argument of the header() function is a string made of two parts:

A fixed “Location: “ part.
The URL where to redirect the user.

As soon as the header() function is executed, the remote user is redirected to the new URL.

This is an “immediate” redirect: the user does not receive any web content before the redirection.

The destination URL should be an absolute URL, like: https://www.google.com.

However, most browsers accept relative URLs too. This can be handy if you want to redirect to a relative URL on your own website.

For example:

$thankyou_page = 'thank_you.php';
if ($form_data_valid) {
	header('Location: ' . $thankyou_page);
	die();
}

NOTE:

You should always call die() after header(). Otherwise, the script execution may continue after the redirection.

Redirection and output.

The header() function sends an HTTP header to the browser. This header tells the browser to go to a different URL.

It’s important to call header() before any output is sent to the browser, including:

Any HTML outside of the PHP tags.
Any text or data printed with PHP.

To better understand what that means, here are three wrong examples.

Wrong example #1: HTML output before header()

<html>
<?php
header('Location: https://www.google.com/');
die();

Wrong example #2: text printed with PHP before header()

echo 'Redirecting...';
header('Location: https://www.google.com/');
die();

Wrong example #3: a white line before header() (this happens if you leave one or more empty lines before the PHP opening tag)


<?php
header('Location: https://www.google.com/');
die();

But what if the redirection comes after some output has already been sent?

In these cases, you have three choices:

Save the output in a variable (instead of echoing it).
Use output buffering.
Use front-end redirection.

The first solution is the easiest. Basically, instead of using echo or similar commands, you save all the output inside a variable.

Then, you output the variable only if no redirection occurs.

For example:


$html = '<html><head></head>';
$redirect = TRUE;
if ($redirect) {
   
   header('Location: https://www.google.com/');
   die();
}
else {
   echo $html;
}

Now let’s look at output buffering.

Output buffering makes your PHP script keep all the output until the end of the script.

So, basically, it does exactly what you need without having to use variables explicitly.

Using output buffering is very simple. You just need to call ob_start() when you want the buffer to begin, and then ob_end_flush() when you want all the buffer to be sent.

Here’s how it works:

<?php
ob_start();
?>
<html>
<head></head>
<?php
$redirect = TRUE;
if ($redirect) {
   header('Location: https://www.google.com/');
   die();
}
ob_end_flush();

Now, let’s see how front-end redirection works.

Redirect with an HTML meta tag.

Another way to perform a redirection is to use a specific HTML meta tag.

This tag must be added to the HTML page that you generate with PHP. After the browser has loaded the page, it reads the redirection tag and executes it.

Contrary to the PHP redirect, this is not an immediate redirect, because the browser loads the first page before performing the redirection.

Let’s see an example:

<html>
   <head>
      <meta http-equiv="refresh" content="0; url=https://www.google.com/">
   </head>
   <body>
   ...
   </body>
</html>

The redirection tag is an HTML meta tag with the http-equiv=”refresh” attribute, and the content attribute containing:

A number that tells how many seconds to wait before the redirection. If set to 0, the redirection is immediate. This number is followed by a ;
The new URL, in the form url=new_url. If this is not set, then the current URL is loaded again (so, in practice, it works as an auto-refresh).

Redirect with JavaScript.

Instead of using the HTML meta tag, you can also use JavaScript to perform a redirect.

In JavaScript, the redirection command is performed by the window.location.replace() function.

You need to make the page execute this function when you want to perform the redirection, which is usually right after the page is loaded.

For example:

<html>
  <head>
    <script>
      function goToGoogle()
      {
        window.location.replace('https://www.google.com');
      };
    </script>
  </head>
  <body onload="goToGoogle();">
  </body>
</html>

If you want to redirect after a timeout, you can simply use the standard JavaScript setTimeout() function.

Like this:

<html>
  <head>
    <script>
      function redirectWithTimeout()
      {
        setTimeout(goToGoogle, 5000);
      }
      
      function goToGoogle()
      {
        window.location.replace('https://www.google.com');
      };
      </script>
  </head>
  <body onload="redirectWithTimeout();">
    <p>You will be redirected in 5 seconds.</p>
  </body>
</html>

HTTP redirect codes.

Let’s go back to the PHP header() redirection.

When you redirect using the header() function, you can also specify an optional redirection HTTP code.

Redirection is done for two reasons:

You simply want to move the user to a different page, like in the form submission example.
You have moved an URL to a different address, so you want to redirect all the requests to the first URL to the second.

When you send the redirection header, you can also tell the browser the reason why this redirection happens by sending the appropriate HTTP header.

This is mostly relevant for SEO purposes.

In particolar, you want to send:

a 301 code if the page has moved permanently to the new URL
a 302 code if the page has moved temporarily to the new URL

By default, the header() function sends a 302 code – a temporary redirection.

If you want to send a 301 code instead, because the old URL has moved permanently to the new URL, then you must specify it explicitly.

You can do it by sending a 301 header before the redirection header. Like this:

<?php
Header( "HTTP/1.1 301 Moved Permanently" );
header('Location: https://www.google.com/');

You can also use the third header() argument to specify the response code:

<?php
header('Location: https://www.google.com/', TRUE, 301);

Conclusion

In this tutorial you learned how to redirect with PHP.

You saw how to use the header() function and how to avoid sending output before the redirection.

You also saw how to perform front-end redirection with an HTML meta tag and with JavaScript, and how to specify the redirection type (301 and 302).

Do you have any questions? Then leave a comment below and I’ll get back to you.

And be sure to subscribe to my free newsletter to get my weekly tips!

Alex

Image copyright: Decision vector created by vectorjuice – www.freepik.com

Источник

Редирект, перенаправление, переадресация — все эти термины обозначают один и тот же процесc, когда пользователь пытается открыть один URL-адрес, а его перенаправляют на другой. Например, вы запрашиваете в браузере https://www.seranking.com/, а в итоге видите в адресной строке https://seranking.com/ — это работа редиректа. Такие перенаправления можно и не заметить. Но бывает и по-другому: если пользователь идет на страницу товара, а оказывается на главной, не заметить разницу будет сложно. Так зачем же вебмастера морочат голову пользователям?

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

Зачем настраивать редирект

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

Для указания главной версии сайта

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

Например, главное зеркало нашего сайта — https://seranking.com/. Поэтому обращения к URL-ам http://seranking.com/, http://www.seranking.com/ и https://www.seranking.com/ будут перенаправлять на главное зеркало.

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

Для решения проблемы дублей

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

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

Перенаправление при добавлении завершающего слеша

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

Ниже мы адаптировали схему, которой аналитик Google Джон Мюллер поделился в своем аккаунте Twitter.

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

Решить проблему можно двумя способами: использовать тег canonical либо установить перенаправление на нужный вам вариант страницы.

Перенаправление при использовании расширения файлов в URL

Иногда в конце адреса страницы указывается расширение файла, например, .html, .htm, .php, .aspx. Чтобы пользователь, вбивая в строку поиска URL вида https://site.com/page/, все равно попал на страницу https://site.com/page.html и чтобы избежать дублирования контента, используется перенаправление.

Перенаправление URL-адреса в нижний регистр

Один и тот же URL-адрес, прописанный в верхнем и нижнем регистре, — это две разные страницы. Правило хорошего тона — использовать в URL нижний регистр. Поэтому чтобы адрес вида https://site.com/PAGE/ был доступен только как https://site.com/page/, также применяется перенаправление. Естественно, редирект здесь нужен и для того, чтобы предотвратить проблемы с дублями.

Для сохранения ссылочного веса и трафика при смене URL

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

Например, вы использовали страницу https://site.com/festivals-2020/, но в конце года решили обновлять контент страницы и публиковать на ней все фестивали следующего года. Чтобы убрать из URL-а прошлый год, вы решаете создать новую страницу https://site.com/festivals/. Эта страница будет постоянно обновляться и содержать контент, который ранее публиковался на странице https://site.com/festivals-2020/. Чтобы избежать каннибализации, вы принимаете решение удалить старую страницу https://site.com/festivals-2020/ и перенаправить трафик и ссылочный вес на новую страницу https://site.com/festivals/.

Для склейки доменов

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

Какие бывают редиректы

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

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

Что происходит во время загрузки страницы?

Вы вбиваете адрес страницы или кликаете по ссылке.
Браузер связывается с сервером, на котором хранятся файлы нужного вам сайта.
Сервер возвращает код ответа браузеру. Если все хорошо, ответ будет 200 ОК и начнется передача файлов от сервера к браузеру.
Если браузер не может начать передачу файлов, он вернет ответ 3ХХ, 4ХХ или 5ХХ. Каждый код объясняет, почему страница недоступна.
Передача файлов браузеру начинается с HTML — это каркас сайта, на который нанизываются другие элементы. HTML-файлы мало весят и быстро загружаются.
Дальше начинается загрузка CSS- и JS-файлов — они отвечают за внешнюю привлекательность сайта и его интерактивность. CSS- и особенно JS-файлы бывают тяжелыми и их обработка занимает довольно много времени.
Из всех полученных файлов браузер собирает страницу и отображает ее вам.

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

HTTP-перенаправления

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

В зависимости от кода в ответе сервера (301, 302, 303 и т.д.) HTTP-перенаправления делятся на постоянные, временные или специальные. Для SEO-целей обычно используется 301 редирект, так как он передает максимум ссылочного веса конечной странице.

HTML-перенаправления

Этот вид перенаправления происходит на этапе загрузки HTML-кода страницы. Реализуется он с помощью тега <meta> и имеет следующий вид:

<meta http-equiv=”refresh” content=”0; url=https://site.com/” />

Рассмотрим значения атрибутов этого тега:

http-equiv — содержит определения поведения страницы
refresh — говорит о том, что необходимо загрузить документ в текущее окно браузера
content — указывает число секунд до начала загрузки другого документа
url — указывает, какой именно документ нужно загрузить

Когда используется HTML-перенаправление, браузер начинает загружать страницу, но потом видит в коде метатег refresh и через указанное число секунд загружает в том же окне другой URL. Это значит, что страница в любой момент может начать перезагружаться без участия пользователя. В то же время если редирект сработает быстро, пользователь может и ничего не заметить.

Недостатки meta редиректов:

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

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

И все же бывают ситуации, когда использование meta редиректа оправдано. Например:

на странице «спасибо», которую вы не индексируете, и хотите, чтобы она открывалась автоматически после целевого действия пользователя
для перенаправления пользователя внутри корзины интернет-магазина
для закрытия внешниз ссылок. Например, если вы не хотите, чтобы ваш сайт-форум содержал прямые ссылки вида <a href=”https://sitewelinkto.com/”>https://sitewelinkto.com/</a> на другой сайт, можно использовать ссылки вида <a href=”https://mysite.com/redirect.php?=https://sitewelinkto.com/”>https://sitewelinkto.com/</a>. Таким образом все внешние ссылки становятся внутренними, а перенаправление выполняется через meta refresh.

Это лишь пример и могут быть иные способы реализации.

JavaScript-перенаправления

Как вы догадались из названия, этот вид перенаправления происходит на этапе обработки JavaScript-файлов, то есть ближе к концу загрузки страницы. Реализуется он с помощью свойства window.location = “https://site.com/”. Использовать JS-перенаправления можно в тех же случаях, что и HTML.

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

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

Недавно в ответ на вопрос о 302 редиректе Гэри Илш из Google напомнил, что использовал именно JS-редирект для переезда webmaster.googleblog.com. Его коллега Джон Мюллер прокомментировал такой ответ шуточным вопросом о передаче ссылочного веса.

В то же время в одной из веток Reddit Гэри Илш написал, что по возможности не стоит использовать JS-редиректы:

«Мы использовали JS-перенаправления для webmasters.googleblog.com, потому что это было единственное доступное решение для перенаправления каждого отдельного URL-адреса на его аналог. Этот метод работает в Google, но я вижу, что другим поисковым системам труднее понимать такие редиректы. Если бы у меня был выбор, я бы никогда не использовал JS-редиректы».

Приоритетность выполнения перенаправлений

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

Если такой возможности нет, настройте HTTP-перенаправление, установив в теге <meta> для параметра content показатель 0 — тогда переадресация начнется сразу, как только браузер увидит тег в коде страницы.

К JavaScript-перенаправлениям стоит прибегать в последнюю очередь и только если возможна интерпретация скрипта на стороне клиента.

Теперь давайте вернемся к HTTP-перенаправлениям и разберемся, что означают разные коды ответа сервера.

Постоянные перенаправления

Ответ сервера 301 Moved Permanently

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

Ответ сервера 308 Permanent Redirect

Этот ответ сервера говорит о том, что страницу переместили на постоянной основе. 308 редирект практически не отличается от 301 и в целом выполняет ту же функцию, но с одним отличием: при использовании метода POST для передачи данных 301 редирект позволяет потом заменить его на GET, а 308 — нет. Такой код стоит использовать при наличии на странице HTML-форм, использующих метод POST, или в других случаях, когда обязательно нужно использовать метод POST.

В этой статье мы еще упомянем методы GET и POST, поэтому давайте разберемся, что же это такое.

Метод GET передает данные в параметрах URL в виде пар переменная = значение. Пример: https://site.com/test/demo_form.php?name1=value1&name2=value2 Этот метод подходит, когда пользователю нужно получить данные от сервера и ему не нужно самому вносить данные на сайт — авторизоваться, заполнять форму обратной связи или заказа. Такие страницы могут кэшироваться в браузере, индексироваться, их можно добавлять в закладки.

Метод POST передает данные в теле HTTP-запроса.В этом случае параметры не сохраняются при повторном переходе по ссылке. Например, ваш логин и пароль не сохраняется в истории браузера, а форма заказа не проиндексируется поисковиками.

Временные перенаправления

Ответ сервера 302 Found

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

Стоит отметить, что в HTTP версии 1.0 ответ сервера 302 интерпретируется как Moved Temporarily (временно перемещен), а в HTTP 1.1 этот ответ сервера означает уже Found (документ найден).

302 перенаправление приходит на помощь сеошнику, когда нужно сохранить старый URL в индексе или на время поменять URL-адрес.

Такой редирект подходит для:

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

Иногда 302 редирект используют по ошибке, и Google это прекрасно понимает. Поэтому каждое 302 перенаправление рассматривается индивидуально и может интерпретироваться как 301. Джон Мюллер говорил об этой ситуации во время встречи с вебмастерами.

Ответ сервера 303 See Other

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

Ответ сервера 307 Temporary Redirect

Ответ сервера 307 похож на 302, но имеет одно отличие. Он сообщает браузеру, что если в первом запросе использовался метод POST, то его нужно использовать и дальше. Как и в случае с 308 редиректом, 307 код ответа используется, когда нужно гарантировать, что метод POST не будет изменен в ходе перенаправления.

Специальные перенаправления

Ответ сервера 300 Multiple Choice

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

Ответ сервера 304 Not Modified

Ответ сервера 304 используется, чтобы сообщить браузеру, что запрашиваемый URL не менялся и можно использовать текущею версию страницы. Таким образом можно экономить трафик и снизить нагрузку на сервер.

Технически это работает так:

Клиент отправляет серверу запрос с заголовком If-Modified-Since с датой, которая сравнивается с датой последнего обновления Last-Modified.
Если окажется, что дата Last-Modified старее, чем дата в If-Modified-Since (то есть в кэше браузера хранится актуальная версия страницы), браузер получит код ответа 304 и не будет загружать страницу заново. Если страница обновлялась после даты Last-Modified (а значит версия из кэша устарела) — от сервера придет ответ 200 и браузер загрузит свежую версию страницы.

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

Где настраиваются редиректы

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

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

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

Ошибки при использовании перенаправлений

Если редирект настроить неправильно, это может навредить ранжированию сайта. Поэтому важно избегать ошибок, которые мы рассмотрим ниже. Если же вам приходилось настраивать редиректы раньше, стоит проверить свой сайт на наличие ошибок в перенаправлениях. Большинство из них можно легко обнаружить при помощи инструмента «Технический аудит сайта» от SE Ranking. Тул просканирует ваш сайт по 110 параметрам — и вы сможете посмотреть, есть ли на вашем сайте ошибки, связанные с редиректами, и если есть, то на каких страницах.

Цепочки редиректов

Бывает такое, что со страницы настроили редирект, а потом еще один с новой страницы. Проще говоря:

https://site.com/page1/ перенаправляет на https://site.com/page2/, а https://site.com/page2/, в свою очередь, перенаправляет на https://site.com/page3/. Чтобы исправить ошибку, достаточно исключить из цепочки лишнее звено: https://site.com/page1/ -> https://site.com/page3/ .

Проверить, есть ли на вашем сайте цепочки редиректов, можно в «Отчете об ошибках» инструмента «Аудит сайта». Эта ошибка — первая в категории «Редиректы».

Зацикленная переадресация

Также случается, что со страницы настроили переадресацию, а со временем передумали и настроили редирект на оригинальную страницу. То есть https://site.com/page1/ перенаправляет на https://site.com/page2/, а с https://site.com/page2/ стоит редирект обратно на https://site.com/page1/.

В такой ситуации ни пользователи, ни поисковые роботы не смогут попасть на https://site.com/page1/. Пользователи увидят в браузере ошибку «Сайт выполнил переадресацию слишком много раз», а поисковики запутаются и не будут сканировать цепочку.

Решить эту проблему можно, устранив обе переадресации. А вот найти такую проблему на сайте вам поможет все та же категория «Редиректы» в «Аудите сайта».

Неверный код ответа сервера

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

Имеет смысл проверить, какой код ответа отдают ваши существующие редиректы. В «Аудите сайта» эта проверка называется «Временные редиректы 302, 303, 307».

Перенаправление на несуществующую страницу

Страница, на которую настраивается редирект, должна:

отдавать ответ сервера 200
быть открытой для сканирования в файле robots.txt

При этом страница НЕ должна:

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

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

Проверить, нет ли вашем сайте страниц с редиректом на 4ХХ или 5ХХ страницы, можно в один клик в разделе «Редиректы».

Перенаправление на нерелевантный контент

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

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

Ссылки на старые страницы внутри сайта

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

Получить полный список внутренних ссылок на страницы с редиректом очень легко — ищите их в «Аудите сайта» в категории «Коды ответа сервера». Проверка называется «Внутренние ссылки на страницы с 3ХХ редиректом».

Тег canonical вместо 301 редиректа

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

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

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

Точки зрения на редиректы

SEO — область знаний, которая полна мифов и гипотез.

Ниже мы тезисно перечислим различные точки зрения о работе редиректов. Верить им или нет — оставляем на ваше усмотрение.

301 редирект не передаетпередает санкции поисковых машин
302 редирект не передаетпередает санкции поисковых машин
302 редирект передает ссылочный вес в очень малом объеме

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

Куда вас отредиректили, или как не сломать все

Редиректы — это базовая механика, которую должен понимать каждый SEO-специалист. Они имеют колоссальное влияние на оптимизацию сайта, поэтому очень важно использовать их правильно. Не злоупотребляйте HTML- и JS-перенаправлениями, используйте корректные коды ответа сервера и внимательно выбирайте страницу, на которую настраиваете редирект. Очень важно, чтобы ваши перенаправления не путали поисковых роботов и не вызывали недоумения у пользователей.

Обязательно разберитесь, чем отличаются редиректы и rel=”canonical”, а если сомневаетесь, как поступить, смело обращайтесь к материалам нашего блога и пишите вопросы в комментариях. Также советуем регулярно проверять свой сайт на наличие ошибок в редиректах — с помощью инструмента «Аудит сайта» сделать это очень просто.

Александр Лушин — независимый SEO-эксперт. Занимается SEО и созданием сайтов с 2008 года. Специализируется на аудитах сайтов, поисковом продвижении и решениях под ключ. Руководит небольшой командой специалистов.

Источник

Ошибка «Сайт выполнил переадресацию слишком много раз»

Причина возникновения ошибки

Сайт, на который не установлен сертификат безопасности, работает по незащищённому протоколу HTTP. URL такого сайта выглядит так: http://your_site.ru. Чтобы сайт работал по защищённому соединению, нужно приобрести SSL-сертификат. Подробнее о HTTP читайте в статье Для чего необходим SSL-сертификат.

При установке сертификата ваш сайт становится доступен по безопасному протоколу HTTPS и URL выглядит так: https://your_site.ru. Однако одной покупки и установки SSL-сертификата недостаточно. По умолчанию сайт по-прежнему открывается по протоколу HTTP. Чтобы ваш сайт начал работать по HTTPS, необходимо настроить редирект с HTTP на HTTPS.

Вариантов сделать редирект несколько. Всё зависит от платформы, на которой сделан сайт. Проще всего сделать редирект на WordPress с помощью плагинов. Если сайт самописный, редиректы устанавливают через конфигурационные файлы .htaccess или web.config. Также можно использовать инструмент для добавления редиректа в панели управления хостингом. Все перечисленные способы вы можете найти в разделе Редиректы.

Если редирект был сделан неправильно, у пользователя может возникнуть циклическая переадресация, которая приводит к ошибке. Как это происходит? При настройке редиректа вы задаёте перенаправление http://your_site.ru —> https://your_site.ru. Если при этом в CMS или на сайте задан параметр открывать сайт строго по протоколу http, возникает замкнутый цикл: http://your_site.ru —> https://your_site.ru —>http://your_site.ru —> https://your_site.ru>… Сервер фиксирует слишком большое количество переадресаций и выдаёт ошибку ERR_TOO_MANY_REDIRECTS.

Сайт выполнил переадресацию слишком много раз или ERR TOO MANY REDIRECTS: как исправить

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

ERR TOO MANY REDIRECTS: что делать, если я владелец сайта

Подумайте, какие действия вы делали с сайтом за последнее время. Вернитесь к старой версии сайта, – если ошибка пропала, значит, новые настройки были некорректны.
Проверьте настройки HTTPS. Часто ошибка ERR_TOO_MANY_REDIRECTS появляется при неправильной настройке переадресации HTTP на HTTPS. Правильно ли вы настроили редирект, можно проверить по инструкциям:
- редирект в панели управления ISPmanager, cPanel или Plesk,
- редирект для сайтов на WordPress.
Проверьте, не влияют ли на работу сайта плагины. Иногда плагины нарушают работу сервера и могут появляться различные ошибки, в том числе и TOO MANY REDIRECTS 310. Отключите по очереди каждый плагин или переименуйте папку plugins в каталоге файлов вашего сайта на любое другое название. Если сайт заработает, удалите плагин-виновник.
Если у вас кириллический домен, проверьте, как в настройках WordPress указан ваш домен. Кириллические домены хоть и удобны в использовании, однако они не соответствуют UNICODE-системе, поэтому для них создали Punycode. Именно в этой форме нужно добавлять название сайта во все настройки. Чтобы перевести кириллический домен в Punycode, используйте конвертер. Например, ваш сайт дачник.ру. В формате Punycode он будет выглядеть xn--80ahnin3d.xn--p1ag.
Ошибка в конфигурационном файле. Каждая CMS имеет собственный конфигурационный файл, который использует индивидуальные правила для перенаправления. Описать все способы исправления этой ошибки невозможно. Вы можете проверить все добавленные правила переадресации и устранить конфликт, обратившись за помощью к разработчикам сайта или на тематические форумы по используемой CMS. Также вам может помочь замена текущего файла .htaccess на стандартный для используемой вами CMS. Если вы используете WordPress или Joomla, можете добавить некоторые записи в конфигурационные записи по одной из инструкций ниже.

Как исправить ошибку в WordPress

Для исправления ошибки в CMS WordPress hosting добавьте в конфигурационный файл wp-config.php, который размещён в корневой директории вашего сайта, строки:

define('FORCE_SSL_ADMIN', true);

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') 
$_SERVER['HTTPS']='on';

Для решения этой проблемы на VPS и выделенных серверах добавьте в httpd.conf (конфигурационный файл Apache) строку:

SetEnvIfNoCase X-Forwarded-Proto "https" HTTPS=on

Чтобы изменения вступили в силу, перезапустите веб-сервер Apache.

Как исправить ошибку в Joomla

Для исправления ошибки в CMS Joomla в конфигурационный файл .htaccess после строки RewriteEngine On добавьте:

RewriteCond %{HTTP:X-FORWARDED-PROTO} ^https$
RewriteRule .? - [E=HTTPS:on]

Важно

Для успешного исправления ошибки «Сайт выполнил переадресацию слишком много раз» PHP должен работать в режиме FastCGI. Подробнее о режимах работы PHP. На виртуальном хостинге по умолчанию установлен режим PHP FastCGI. На VPS-сервере этот режим также доступен.

Что делать, если я пользователь

Откройте сайт в другом браузере. Если ошибка сохраняется, значит есть проблема с сервером и восстановить доступ к сайту может только владелец. Если сайт загружается, значит проблема со стороны вашего устройства. Выполните шаги описанные ниже.
Очистите cookies и кэш браузера. Временные файлы сохраняют данные посещённых сайтов, чтобы в дальнейшем не тратить время на обращение к серверу, а использовать информацию с устройства. Несмотря на пользу временных файлов, бывает, что они мешают показать новую версию сайта. Если на веб-ресурсе была ошибка и владелец её исправил, пользователь может не увидеть новый вариант. Чтобы браузер обратился к серверу сайта, а не к временным данным, очистите кеш и cookies браузера.
Проверьте расширения в браузере. Они могут влиять на связь браузера и сервера. Отключите недавно установленные расширения. Если сайт заработал, расширение придётся удалить.
Если вы используете VPN, попробуйте зайти на сайт без него. Некоторые сайты ограничивают вход для зарубежных серверов, через которые могут работать сервисы VPN.
Проверьте дату и время на устройстве. Для HTTPS-соединения важно, чтобы дата и время совпадали (хотя бы примерно) с датой и временем на сервере сайта. Если на устройстве время отстаёт или спешит, могут возникать различные ошибки, в том числе и ошибка переадресации.
Если вы попробовали все вышеописанные решения и ничего не изменилось, но вы уверены, что виноват браузер, возможно, ошибка в самой программе. Удалите и заново установите браузер или сбросьте его до базовых настроек.

Как отключить или удалить расширения в браузере Google Chrome

1.

В правом верхнем углу нажмите на три точки. В выпадающем списке нажмите Настройки:
2.

В левом меню нажмите Расширения:
3.

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

Как отключить или удалить расширения в браузере Google Chrome 3

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

Источник

Что такое редирект?

300 редирект — множественный выбор

Как это работает?

301 редирект — перемещен навсегда

Как это работает?

302 редирект — документ найден

Как это работает?

303 редирект — смотри другое

Где это используется?

304 редирект — не изменялось

Как это работает?

305 редирект — используй прокси

Как это работает?

306 — не используется

307 — временный редирект

Как это работает?

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

Делаем редирект на php

Пример редиректа на php

Делаем редирект в .htaccess

Пример

Делаем редирект на html

Пример

Редирект при помощи javascript

Как работает редирект

В каких случаях нужны редиректы

Перенаправление с HTTP на HTTPS или обратно

Переезд на другой домен

Смена CMS сайта

Переадресация на мобильную версию

Появление поддоменов

Удаление страниц

Изменение структуры сайта

Перенаправление с устаревших страниц

Классификация редиректов: отличия и применение

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

300 «Множественный выбор» (Multiple Choices)

301 «Перемещена навсегда» (Moved Permanently)

302 «Перемещена временно» (Moved Temporarily)

303 «Смотри другое» (See Other)

304 «Не модифицировано» (Not Modified)

305 «Используй прокси» (Use Proxy)

306 — зарезервировано

307 «Временная переадресация» (Temporary Redirect)

308 «Перемещено навсегда» (Permanent Redirect)

Способы реализации редиректов

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

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

Редирект на серверах Ngnix

Плагины CMS

PHP-редирект

JavaScript-редирект

HTML-редирект или meta-refresh

Rel=«canonical»: редирект для поисковых систем

В каких случаях применять 301 редирект, а в каких — rel=«canonical»

Какой тип редиректа выбрать

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

Где найти файл .htaccess и как его редактировать

Сделайте резервную копию файла

Внедряйте правила по одному и проверяйте после каждого изменения

Комментарии

Флаги

Что должно быть в начале файла

Кириллические адреса

Добавьте блок IfModule

Порядок правил имеет значение

Почему нужно пробовать разные варианты

Используйте генераторы .htaccess

Как настроить 301 редирект в .htaccess

Редирект сайта с WWW — на без WWW

Редирект сайта без WWW на URL с WWW:

Редирект на HTTPS с HTTP

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

На URL без слеша

На URL со слешем

Заменяем два последовательных редиректа на один

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

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

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

Как проверить, правильно ли сделана переадресация