SEO

Редиректы и SEO — полное руководство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Редиректы и SEO - полное руководство * 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

Редиректы и 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 / реферальных кампаний :

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

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

Редиректы и SEO - полное руководство

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

Если посетители должны перенаправляться на конкретный 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-адреса назначения редиректа должны регулярно проверяться, чтобы предотвратить возникновение цепочки.

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

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

Пример:

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

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

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

Редиректы и SEO - полное руководство С точки зрения 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-коррекции пагинации.

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

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