Что такое редирект для SEO - полное руководство

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

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

С технической точки зрения: что такое редирект

Редирект - это автоматический переход с запрашиваемого URL-адресу к URL-адресу назначения. Редирект завершается, когда клиент перенаправляется на URL-адрес назначения.

Редирект может быть инициирован, как на стороне сервера, так и на стороне клиента:

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

• HTTP-коды статусов 30x.

Редиректы на стороне клиента:

• мета-обновление;
• Javascript-редиректы.

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

HTML redirect на другую страницу на стороне сервера происходит, когда на HTTP-запрос приходит ответ с кодом статуса сервера, который указывает, что запрашиваемый документ перемещен на другой URL-адрес. После этого клиент запрашивает URL назначения, и пользователь перенаправляется на него.

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

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

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

В следующей таблице приведены коды статуса 30x и их технические характеристики:

* cache-default для кодов состояния 301, 302, 307 и 308 может быть переназначен кэшированием метода запроса или с помощью явных элементов управления кэшем. Более подробную информацию по этой теме вы можете найти в RFC 7234, раздел 4.2.2.

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

• Является ли HTML redirect временным или постоянным?
• Может ли изначальный URL-адрес редиректа отображаться в результатах поиска?
• Есть ли информация о том, как долго будет активен редирект?

Код статуса редиректа может помочь ответить на эти вопросы.

Редирект 301 - "Перемещено навсегда"

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

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

Метод запроса может изменяться при повторном запросе. Современные браузеры обычно используют метод GET для передачи запроса к URL-адресу назначения даже если первоначальный запрос был отправлен с помощью метода POST.

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

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

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

• Перемещение домена на постоянной основе;
• Перемещение документа на постоянной основе;
• Изменение протокола сайта на постоянной основе;
• Изменение структуры сайта на постоянной основе.

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

Редирект 301 является неверным решением для случаев, в которых кэширование может привести к неожиданному негативному поведению.

Примеры:

• Геотаргетинг;
• Таргетинг устройств;
• А / В тестирование;
• Отслеживание (включая кампании с платой за клик и реферальные кампании).

Redirect 301 HTML также не следует использовать, если вы хотите применить временное перенаправление.

Примеры:

• Сезонные товары на сайтах электронной коммерции;
• Временные специальные предложения на целевых страницах сайтов электронной коммерции.

Редирект 302 - "Найден" / "Временно перемещен"

Код состояния 302 указывает, что запрашиваемый документ временно перемещен на другой URL-адрес.

Редирект 302 не кэшируется по умолчанию. cache-default может быть переопределен кэшированием метода запроса или с помощью явных элементов управления кэшем.

Редирект 302 впервые был определен в HTTP / 1.0 (RFC 1945) и описан фразой "Временно перемещено". Хотя было указано, что первоначальный метод запроса должен использоваться и для URL-адреса назначения, браузеры часто обрабатывают редирект 302 вопреки стандарту с использованием для URL-адреса назначения метода GET.

В HTTP / 1.1 (RFC 2616) редирект 302 был переименован в "Найдено" и были добавлены коды статуса 303 и 307, чтобы предоставить возможность использовать различные временные редиректы, позволяющие и не позволяющие изменять метод запроса к URL-адресу назначения.

Код статуса 302 на сегодняшний день по-прежнему является наиболее часто используемым статусом временного HTML meta redirect и обеспечивает обратную совместимость для клиентов, которые не поддерживают HTTP / 1.1.

Из-за временного характера редиректа 302 его поведение всегда можно изменить. Именно поэтому поисковые системы, как правило, не предают через него PageRank или SEO-вес URL-адресу назначения. Это также является причиной того, что редирект 302 часто рассматривается как "плохой" редирект для оптимизаторов, что является заблуждением. Есть случаи, в которых специфические характеристики редиректа 302 могут быть использованы с положительным эффектом для SEO.

Когда использовать редирект 302

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

Случаи использования редиректа 302:

• Геотаргетинг;
• Таргетинг устройств;
• А / В тестирование;
• Отслеживание;
• Периодическое временное содержимое;
• Перенаправление при отсутствии страницы в результатах поиска.

Примеры:

• Сезонные товары на сайтах электронной коммерции;
• Временные специальные предложения на целевых страницах сайтов электронной коммерции.

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

Код статуса 302 не следует использовать, если нужно передавать SEO-вес URL-адресу назначения.

Примеры:

• Перемещение домена на постоянной основе;
• Перемещение документа на постоянной основе;
• Изменение протокола сайта на постоянной основе;
• Изменение структуры сайта на постоянной основе.

HTML redirect 302 также не следует применять, если метод исходного запроса необходимо использовать для запроса к URL-адресу назначения.

Примеры:

• Временное перемещение URL-адреса обработчика формы, которая использует метод POST.

303 - "Смотреть другие"

Код статуса 303 был определен в HTTP / 1.1 и указывает на временный редирект. Метод запроса для URL-адреса назначения всегда GET.

Редирект 303 никогда не кэшируется. Большинство клиентов обрабатывают код статуса 303 так же, как и статус 302.

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

Редирект 303 может использоваться, как и редирект 302. Благодаря тому, что он не кэшируется ни при каких обстоятельствах, мы рекомендуем использовать 303 вместо 302, когда временный редирект задается на неопределенный период времени или URL-адрес назначения может изменяться. Тем не менее, запрос к URL-адресу назначения всегда будет выполняться с использованием метода GET.

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

• Все случаи использования редиректа 302, которые обрабатываются с помощью метода GET для повторных запросов:
• Геотаргетинг;
• Таргетинг устройств;
• А / В тестирование;
• Отслеживание;
• Периодическое временное содержимое;
• Перенаправление при отсутствии страницы в результатах поиска;
• PRG-шаблон (POST / редирект / GET).

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

HTML redirect на другую страницу 303 не может использоваться, если для повторного запроса должен быть использован метод POST. Также не рекомендуется использовать редирект 303 для клиентов, которые не поддерживают HTTP / 1.1.

Как и редирект 302, редирект 303 не может быть использован для сценариев, которые имеют постоянный характер.

Примеры:

• После первичного запроса требуется использовать метод POST. Например, при перемещении URL-адреса обработчика формы, для которого требуется метод POST;
• Перенаправление является постоянным;
• Значение SEO должно передаваться URL-адресу назначения.

Редирект 307 - "Временно перемещено"

Код статуса 307 был определен в HTTP / 1.1, чтобы заменить код 302 для случаев, когда метод запроса не должен изменяться для URL-адреса назначения.

Редирект 307 не кэшируется по умолчанию. cache-default может быть переопределен кэшированием метода запроса или с помощью явных элементов управления кэшем.

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

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

Случаи использования редиректа 307:

• Для повторного запроса требуется метод POST. Например, перемещение URL-адреса обработчика формы, для которой требуется метод POST.

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

Редирект 307 не должен использоваться для PRG-шаблона. Код статуса 307 также не следует использовать, если редирект имеет постоянный характер.

Редирект 308 - "Перемещено навсегда"

Код статуса 308 определен в RFC 7538. Это постоянный аналог кода статуса 307. В противоположность редиректу 301 он указывает, что метод повторного запроса URL-адреса назначения должен быть таким же, как и метод первоначального запроса.

HTML redirect 308 кэшируется по умолчанию, если не указано иное. cache-default может быть переопределен кэшированием метода запроса или с помощью явных элементов управления кэшем.

RFC 7538 ограничивает использование кода статуса 308 теми случаями, "когда сервер полностью уверен, что клиент распознает новый код, или когда резервный вариант семантики кода статуса 300 не является проблемой".

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

Редирект 308 может быть применен, если нужно использовать метод первоначального запроса для повторного. Например, редирект на URL-адрес обработчика формы с использованием метода POST.

Случаи использования редиректа 308

• Перемещение на сложном сайте с большим количеством форм, использующих метод POST;
• Если для повторного запроса требуется метод POST. Например, перемещение URL-адреса обработчика формы, для которой требуется метод POST;
• Все случаи использования редиректа 301:
• Перемещение домена на постоянной основе;
• Перемещение документа на постоянной основе;
• Изменение протокола сайта на постоянной основе;
• Изменение структуры сайта на постоянной основе.

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

Редирект 308 - это неверное решение для всех случаев, в которых кэширование может привести к неожиданному негативному поведению.

Заключение по редиректам на стороне сервера

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

Редиректы на стороне клиента

Редирект на стороне клиента - это прямой переход к URL-адресу назначения. Он инициируется непосредственно клиентом, например, браузером.

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

"Применение JavaScript для перенаправления пользователей может быть правильной практикой. Например, если вы перенаправляете пользователей на внутреннюю страницу, после того, как они авторизовались. При принятии решения об использовании JavaScript или других методов перенаправления, чтобы обеспечить соответствие практик, используемых на сайте, нашим рекомендациям, рассмотрите аспект, связанный с тем, для чего это делается. Имейте в виду, что редиректы 301 лучше всего использовать при переносе сайта, но можно использовать для этой цели JavaScript-редиректы, если у вас нет доступа к серверу." --- Справка Google Search Console - Руководство по повышению качества.

Обновление с помощью метаконтента

В HTML можно запустить редирект, используя следующий синтаксис в разделе <head>:

<meta http-equiv="refresh" content="5; URL=http://www.example.com/">

Метатег HTML предлагает атрибут "http-equiv", который можно использовать со значением "refresh", чтобы задать автоматический запрос целевого URL-адреса через заданное время. URL-адрес и время должны быть указаны в атрибуте "content". Значение атрибута content должно содержать количество секунд, через которое запускается редирект, после которого через точку с запятой указывается URL-адрес. URL-адрес не является обязательным. Метаэлементы должны располагаться в пределах раздела <head>.

Приведенный в примере код указывает выполнить HTTP-запрос с помощью метода GET к URL-адресу http://www.example.com/~~HEAD=pobj~~V через 5 секунд. Чтобы выполнить HTML redirect немедленно, укажите 0 секунд. В данном процессе не задействованы коды статуса редиректа.

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

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

JavaScript-редиректы

Javascript-редиректы являются альтернативным метаобновлению редиректом на стороне клиента. Для этого необходимо, чтобы клиент был в состоянии интерпретировать JavaScript.

Случаи использования:

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

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

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

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

Примеры JavaScript-редиректов

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

Вот несколько примеров для различных методов реализации JavaScript-редиректа:

location.href = "http://www.example.com/";
location.assign("http://www.example.com/");
location.replace("http://www.example.com");

Заключение по редиректам на стороне клиента

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

Если перенаправление на стороне сервера применить невозможно, могут быть использованы JavaScript-редиректы при отслеживании конкретного браузера/клиента или геотаргетинге.

Общие случаи использования редиректов для целей SEO

Редиректы при изменении структуры сайта

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

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

• Постоянным;
• Кэшируемым.

Для предотвращения тупиков и сохранения пути пользователя, а также SEO-веса, мы предлагаем использовать код статуса 301 или 308 для перенаправления пользователей со старых URL-адресов на новые.

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

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

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

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

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

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

Исходя из перечисленных выше требований, мы предлагаем использовать для геотаргетинга редиректы 303, 302 или 307. Вебмастера могут помочь поисковым системам лучше понять международные сайты, если атрибут ссылки hreflang используется должным образом.

Перенаправление для Pay Per Click / реферального маркетинга

При использовании редиректа для Pay Per Click или реферального маркетинга для предотвращения определенных проблем требуется временный редирект. Адреса назначения HTML meta redirect могут меняться в зависимости от тестирования различных посадочных страниц или вследствие изменений в инфраструктуре отслеживания. Чтобы избежать проблем, поведение кэширования клиента должно контролироваться.

Pay Per Click / реферальные кампании порождают много внешних ссылок на сайты рекламодателей. Сайты часто покупают ссылки, где используется постоянный редирект, и, следовательно, имеет место передача SEO-веса. В то же время поисковые системы в целях борьбы с SEO-ссылками применяют различные санкции к таким сайтам. В худшем случае это может привести к попаданию под фильтр, например, Google Penguin. Сайт-продавец также может подвергнуться санкциям.

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

Требования к редиректу для Pay Per Click / реферальных кампаний:

• Временный;
• Некэшируемый / кэшируемый, в зависимости от задач.

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

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

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

• HTML redirect должен быть временным;
• Редирект должен быть не кэшируемым;
• Поисковым системам должны предоставляться вариативные заголовки.

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

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

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

Google поддерживает как HTTP-редиректы, так и Javascript-редиректы при отслеживании устройств, но предлагает использовать редирект 302 вместе с определением rel=alternate.

Мы предлагаем использовать при отслеживании устройств redirect HTML code 303, 302 или 307.

Используя rel=alternate должным образом, веб-мастера могут помочь поисковым системам лучше понять международные сайты.

Редиректы при изменении хоста или протокола и других коррекциях URL-адреса

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

Это, как правило, включает в себя (но не ограничивается этим):

• Перевод на не-www версию с www версии;
• Перевод на протокол HTTPS с HTTP;
• Добавление слэша в конце.

Редирект для URL-коррекции должен быть постоянным, кэшируемым и передавать SEO-вес для объединения потока пользователей и веса на целевом URL-адресе.

Требования, предъявляемые к редиректу для URL-коррекции:

• Постоянный;
• Кэшируемый.

Мы предлагаем использовать для URL-коррекций редирект 301 или 308.

Редиректы и Canonical в SEO

Технически, HTML redirect и rel=canonical вряд ли можно сравнивать. Однако с точки зрения SEO они помогают:

• Избежать проблем с дублированным контентом;
• Объединить свойства URL, например, популярность ссылок.

В противоположность редиректу, "canonical" - это HTML мета-элемент ссылки, который определяет предпочтительную версию документа, доступного по более чем одному URL-адресу. Это может помочь передать SEO-вес от исходного URL адресу назначения, в то время как пользователь может получить доступ непосредственно к документу-дубликату. Тем не менее, "Спецификация по связям канонических ссылок" (RFC 6596) говорит, что, если автор использует canonical, ему следует ожидать, что поисковые системы, объединят свойства URL-адресов в каноническом URL-адресе.

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

И в отличие от неопределенного характера canonical, редирект является конкретным решением с четко определенным поведением приложений. Исходя из этого, редирект следует рассматривать как более предпочтительное решение, чем canonical, когда речь идет об объединении свойств URL-адреса и предотвращении проблем, связанных с дублированным контентом.

Типичные ошибки SEO, связанные с редиректом

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

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

Появление цепочки HTML redirect ведет к:

• Выводу предупреждения клиента "слишком много редиректов".
• Более продолжительному времени задержки.
• Проблем с бюджетом сканирования.
• Потере SEO-веса.

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

Редиректы как источник возникновения задержки

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

Пример:

Различные клиенты выдают сообщение "Слишком много редиректов" при различном количестве редиректов.

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

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

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

Перенаправление как причина проблем с бюджетом сканирования

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

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

Сбой отображения URL-адресов из-за редиректа

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

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

Поисковая система может:

• использовать для вывода в результатах поиска изначальный URL-адрес;
• использовать для отображения в результатах поиска URL-назначения redirect HTML index.

Факторы, которые могут быть приняты во внимание поисковыми системами:

• Период, на протяжении которого активен временный редирект;
• Входящие ссылки на каждый URL-адрес;
• Трастовость хоста;
• Длина первоначального URL-адреса и URL-адреса назначения;
• Сигналы пользователей в результатах поиска;
• Внутренний или внешний это редирект.

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

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

Петля редиректов из-за кэширования редиректов

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

Пример:

1. Мы реализуем редирект с URL-адреса http://example.com на URL-адрес http://www.example.com. Редирект кэшируется.
2. Затем реализуем обратный редирект. Теперь с http://www.example.com на http://example.com. Этот редирект также кэшируется.

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

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

Неправильный редирект при пагинации

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

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

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

Мы рекомендуем использовать некэшируемые временные редиректы для URL-коррекции пагинации.