Как исправить цепочку редиректов

Редиректы – это просто. Их используют для автоматического перенаправления пользователей с одного URL-адреса на другой. Но это, если смотреть на редиректы глазами тех, кто не утруждает себя вопросами поисковой оптимизации. С точки зрения SEO все сложнее. Редиректы напрямую соотносятся с продвижением в поиске и могут привести к множеству проблем, которые ухудшат представление сайта в Google и Яндексе. При этом от 301-редиректов никуда не деться: для каждого оптимизатора рано или поздно наступает момент, когда его настройка на сайте становится обязательной. Разбираем главные SEO-вопросы по этой теме в нашем FAQ.

Что такое 301-редирект

Это код ответа сервера, сообщающий, что исходная ссылка получила новый URL-адрес. Другими словами, код 301 указывает браузеру, что неактуальная страница (или весь сайт) окончательно перемещены в новое место. Перейдя по ссылке, с настроенным редиректом, или введя ее в браузерную строку – пользователь автоматически перенаправится на другой URL-адрес.

Почему 301-редирект так важен для SEO?

Каждая страница сайта имеет свой поисковый рейтинг, который определяет ее ранжирование, т. е. позиции в выдаче и количество трафика из поиска. Перенаправление через 301-редирект позволяет исключить из поискового индекса неактуальный URL и перенаправить поисковый вес со старой страницы на новую. Таким образом, актуальная версия URL-адреса сохранит в выдаче позиции прежней страницы и тот же объем поискового трафика. Если не заморачиваться с редиректом и просто создать новую страницу, ее рейтинг в Google и Яндексе придется прокачивать с нуля.

Резюмируя: 301-редиректы – это в первую очередь о сохранении SEO-потенциала сайта при замене старых URL-адресов, а не о простом автоматическом перенаправлении для удобства пользователей (хотя это тоже бывает важно).

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

Мы описали общую логику работы редиректов. Теперь – когда их используют на практике.

✓ Навсегда меняют URL-страницы

Это может быть актуально при смене CMS или переезде на самописный сайт; при изменении структуры ресурса или просто массовом обновлении URL-адресов, например, при переходе на систему ЧПУ.

✓ Переезд на новый домен

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

✓ Установка сертификата безопасности SSL

Переход с HTTP на защищенный протокол HTTPS влечет фактическое изменение адреса сайта и всех его страниц. Все запросы к старым версиям URL должны быть корректно перенаправлены на версии с HTTPS.

✓ Склейка страниц без WWW и WWW-версий

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

✓ Редиректы с безслешевых версий URL на слешевые

URL страниц по умолчанию имеют слеши в конце. Если мы убираем слеш, нужно настроить соответствующее перенаправление (/blog/statia/ →301→ /blog/statia). Не сделав это, поисковая система распознает безслешевый урл как абсолютно другой документ с тем же самым содержанием, что и страница со слешем. А как мы знаем, дубли – это очень плохо для SEO.

✓ Склейка двух и более страниц с похожим содержимым

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

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

Чем 301-редирект отличается от 302?

Существует несколько видов редиректов. Для нужд SEO применяют  главным образом два: 301 и 302. Здесь все просто: если контент перенаправляют на новый URL навсегда – ставят 301 редирект. Для временного перемещения используют возможности 302 редиректа.

Выше мы рассмотрели типичные ситуации под 301-перенаправление. Теперь – коротко, когда используют 302 редирект.

✓ Перенаправление пользователей на актуальную для них версию сайта (с учетом ГЕО или языка).

✓ Проведение A/B-тестирования и получение обратной связи о новой (тестируемой) странице без ущерба для позиций старой.

✓ Временное перенаправление аудитории, например, на страницу с акционным предложением.

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

Что происходит с индексацией страниц и ссылочными сигналами при 301 и 302 редиректах

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

Индексация

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

✓ При 301-редиректе в индекс попадает новая (конечная) страница, на которую стоит перенаправление.

✓ При 302-редиректе в индексе остается первоначальный URL, с которого стоит перенаправление.

Касательно индексации страниц с 302-редиректом есть ряд нюансов. Поисковая система какое-то время воспринимает старые версии страниц как основные, но со временем начинает учитывать 302-редирект как постоянный. По крайней мере, так работает Google. Обычно это занимает несколько недель или месяцев, после чего страница, на которую стоит 302-редирект, залетает в индекс , а старая версия – удаляется. В исключительных случаях Google сразу индексирует 302-редиректы как 301.

Ссылочные сигналы

С точки зрения SEO-оптимизации куда важнее вопрос, что происходит с перераспределением ссылочного веса между страницами, связанными 301 и 302 редиректами.

В Google редиректы раньше «съедали» приблизительно 15-20% PageRank (цифры очень условные) при каждом перенаправлении. То есть, если вы делали перенаправление со старой страницы, например, с PageRank 50, то новый URL получал только 40 PR. 

С 2016 Google прекратил официальное обновление PageRank (хотя сам принцип определения «ценности» страниц в том или ином виде продолжает работать и сейчас), и в этом же году Google пересмотрел свою позицию касательно обработки редиректов.

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

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

✓ Для 301-редиректов ссылочные переносятся «вперед»

(то есть, вес от всех ссылок, проставленных на старую страницу, перетекает на новый URL)

✓ Для 302-редиректов ссылочный вес перераспределяется «назад»

(эффект от всех ссылок на новый URL-адрес будет усиливать рейтинг старой версии страницы)

Важно!
Для эффективного перераспределения ссылочных сигналов большое значение имеет релевантность двух страниц. Если редиректить URL сайта на тематически НЕблизкую страницу, то последняя не только не получит ссылочных сигналов, но и, вероятнее всего, будет учитываться как ложная ошибка (soft 404). Поэтому и 301, и 302 редиректы всегда должны связывать максимально релевантные документы.

Что происходит с позициями сайта после массового обновления URL

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

Как настроить 301-редирект

Существует несколько способов сделать 301-редирект, но самый общепризнанный метод — редактирование .htaccess (файла дополнительной конфигурации веб-сервера Apache).

Этот файл находится в корневой папке сайта:

Естественно, этот способ актуален исключительно для Apache-серверов. Но вряд ли здесь возникнут какие-либо проблемы: почти половина всех сайтов (46%) работает на этом ПО, так что, вероятнее всего, – и ваш тоже.

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

WP-плагины для автоматической настройки редиректов

Настроить редиректы на сайте можно и другими способами: посредством HTML и PHP или через специальные скрипты. Но это для тех, кто ориентируется на уровне кода (или готов с этим разобраться). Для всех остальных, у кого сайт работает на CMS, оптимальным решением будет использование плагинов. Возможно, этот способ не такой надежный, как другие варианты; в дополнение к этому, плагины – это всегда лишние нагрузки и источник потенциальных уязвимостей. Тем не менее никто не будет спорить, что это самый простой способ создания редиректов.

Популярные WP-плагины для настройки редиректов

Redirection – топовый WP-плагин для комплексной работы с редиректами. Помимо настройки перенаправлений (как простых редиректов, так и на основе разных условий), плагин умеет собирать статистику переадресаций, мониторить 404-ошибки, поддерживать регулярные выражения. Имеет русскоязычную версию. Систематически обновляется. Бесплатный.

Safe Redirect Manager — еще один популярный редирект-плагин для WP. По части дополнительных функций уступает вышеописанному варианту, но выигрывает с т. з. ресурсоемкости. Не имеет русскоязычной версии. Постоянно обновляется.

Quick Page – простой и нетребовательный в плане ресурсов плагин. Позволяет создавать быстрые 301-редиректы и перенаправления с тонкими настройками. Нет русской локализации. Бесплатный.

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

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

Чем найти редиректы онлайн (бесплатно):

Webmasta

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

 Redirectdetective

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

Httpstatus

Быстро проверяет коды состояний, http-заголовки и находит цепочки переадресаций. Есть удобные функции фильтрации и выгрузки результатов. Обрабатывает до 100 URL за одну проверку.

Браузерные расширения для проверки редиректов

•         Link Redirect Trace (Chrome);
•         Redirect Path (Chrome);
•         Live HTTP Header (Mozilla Firefox, Chrome).

Многофункциональный SEO-софт

Это самые удобные и надежные инструменты для проверки редиректов. За использование таких программ придется платить. Но есть исключения. Например, популярный сервис Ahrefs позволяет бесплатно использовать часть функционала для своих сайтов. Речь идет об инструментах, входящих в пакеты Site Explorer и Site Audit. Чтобы получить к ним доступ, достаточно подтвердить владение сайтом. После этого в вашем распоряжении будет набор мощных инструментов для мониторинга проблем с редиректами (и не только). Как это работает.

Переходим на вкладку Site Audit:

↓

Сканируем ресурс или выбираем дату последнего обхода:

↓

Переходим к отчету Redirects:

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

Также здесь можно посмотреть детали по каждому редиректу (↓)

Какие проблемы могут быть связаны с 301-редиректами?

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

Некорректные перенаправления с HTTP-версии на HTTPS

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

Перейдите на домашнюю страницу – в адресной строке должен отображаться протокол https и иконка с замком. При изменении адреса сайта на HTTP и последующем вводе, браузер должен автоматически перенаправлять на защищенную HTTPS-версию.

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

В Ahrefs некорректные перенаправления с HTTPS на HTTP можно увидеть в отдельном отчете:

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

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

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

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

Находить цепочки редиректов умеет большая часть инструментов. Например, так их определяет вышеупомянутый онлайн-чекер Httpstatus:

А вот так связки переадресаций отображаются в Ahrefs:

Как исправить цепочки редиректов

1. Перенастроить редирект. Это самый очевидный способ: нужно убрать все промежуточные звенья и настроить редирект напрямую, между двумя страницами.
2. Заменить внутренние ссылки. Если вы не хотите связываться с перенастройкой редиректов, можно пойти обходным путем и отредактировать на сайте внутренние ссылки, которые ведут на перенаправленные страницы. Так, несмотря на фактическое сохранение цепочки, поисковые роботы уже не будут тратить ресурсы на неэффективные обходы многоуровневых ссылок, а пользователи – выжидать долгого перехода после нажатия на линк.

Посмотреть все внутренние ссылки, которые стоят на цепочку перенаправлений, можно в столбце No. of href inlinks.

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

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

Циклические перенаправления

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

Представим себе цепочку редиректов, в которой дублируется конечный URL-адрес:

При таком синтаксисе, попадая на последнюю страницу, цикл перенаправлений будет повторяться сначала:

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

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

В Ahrefs такие ошибки называются Redirect loop и отображены в соответствующем отчете.

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

Захламленность карты сайта страницами с 301-кодами

Файл sitemap – это список XML-документов, которые указывают поисковым системам необходимые ориентиры для эффективной индексации. Поскольку страниц с кодом состояния 301 технически больше нет, поисковым системам не нужно рекомендовать их к обработке. В противном случае роботы могут продолжать совершать по ним обход, впустую расходуя краулинговый бюджет (лимиты индексирования). Помимо этого, Google использует данные sitemap как один из факторов при выборе канонических URL.

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

Вот как это можно сделать:

1. Выгружаем список всех URL из карты сайта.
2. Прогоняем список через один из описанных выше онлайн-чекеров.
3. Отфильтровываем URL с кодами состояния 301.

С Ahrefs все еще проще. Ошибки переадресации в карте сайта можно посмотреть в отдельном отчете (если они присутствуют).

Редиректы на 404-страницы

Еще одна потенциальная проблема для SEO – битые редиректы, т. е. переадресации, ведущие на несуществующие страницы (которые возвращают ответ HTTP с кодом 4XX или 5XX). В отличие от примеров выше, эта проблема чаще возникает не из-за неправильных настроек или заражений вирусами, а по естественным причинам, например, когда старые страницы удалены или перенесены в другие разделы. Таким образом, появление 404-страниц – естественный процесс, но запускать эту проблему не нужно.

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

В Ahrefs опцию пакетного сканирования на битые редиректы можно найти в том же инструменте Site Audit (отчет Internal pages → вкладка Broken redirect).

Как исправить битые редиректы?

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

Использование 302-редиректов и Meta Refresh для постоянных переадресаций

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

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

Иногда вместо 301-редиректа может быть использован метатег Meta Refresh, через который браузер получает команду перенаправлять пользователей на другой URL.  Настройка перенаправлений Meta Refresh – нежелательная практика, от которой рекомендует отказаться сам Google.

Поэтому, если на сайте стоят такие переадресации, их нужно или убрать, или заменить на 301-редиректы.

Переходы из поиска на страницы с кодом 301

При создании 301-редиректа в индекс попадает конечная версия страницы, а предыдущая – удаляется. Соответственно, URL с кодом состояния HTTP 301 не должны получать трафик из поиска. Если это происходит, такие страницы будут отображены в отчете 3XX page receives organic traffic.

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

Практические сценарии использования 301-редиректов для усиления SEO

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

Склейка тематически близких страниц

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

Какой контент объединять?

Для начала отметим, что лучше НЕ проводить таких экспериментов с топовыми страницами, которые имеют высокие позиции и дают много трафика. Оптимальные кандидаты для объединения – тематически близкие страницы (фактор релевантности очень важен) с низкой и средней посещаемостью. Даже если что-то и пойдет не так, пессимизация этих статей вряд ли сильно отразится на KPI сайта.

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

Как склеивать похожие статьи?

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

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

Перенаправление 404-страниц с обратными ссылками

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

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

Используем уже упомянутые отчеты Ahrefs. Открываем Site Audit → Internal pages и смотрим список всех ошибок 404 page.

Разворачивает детальный отчет по всем 404-страницам, найденным при сканировании.

Нажимаем на кнопку Manage columns и добавляем метрику No. of dofollow backlinks – она покажет все dofollow-ссылки, которые есть у 404-страниц. Если список 404 page большой, сортируем столбец в порядке убывания.

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

Если ссылка хорошая, целесообразно поступить следующим образом (на выбор):

1. Перенаправить через 301-редирект 404-страницу на другой релевантный (!) документ на вашем сайте.

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

Логика этих действий, думаем, понятна: ссылочные сигналы, передающиеся через трастовые бэклинки, не будут уходить в никуда. Но если восстановленное содержимое нерелевантно прежней версии 404-страницы, поисковые системы будут учитывать редирект как ложную ошибку (soft 404) и никакого положительного эффекта от такой переадресации для SEO не будет.

Здравствуйте. Суть задачи состоит в том, чтобы убрать цепочку редиректа. Сам я фронт и не особо разбираюсь в этом вопросе. Вижу, что редиректов уйма, а как убрать цепочку не до конца понимаю. Скрины с сервиса и .htaccess ниже:

#This Apache config file was created by Duplicator Installer on 2021-07-20 16:07:59.
#The original can be found in archived file with the name .htaccess__[HASH]
# BEGIN WordPress
# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.

RewriteEngine On

RewriteCond %{HTTPS} off

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

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{THE_REQUEST} //
RewriteRule .* /$0 [R=301,L]
RewriteCond %{REQUEST_URI} ^(.*)--(.*)$
RewriteRule . %1-%2 [R=301,L]
# SLASH START
RewriteEngine On
RewriteCond %{HTTP_HOST} ^([^www].*)$
RewriteRule ^(.*)$ http://www.%1/$1 [L,R=301]
RewriteCond %{REQUEST_URI} !=/wp-admin
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !?
RewriteCond %{REQUEST_URI} !&
RewriteCond %{REQUEST_URI} !=
RewriteCond %{REQUEST_URI} !.
RewriteCond %{REQUEST_URI} !/$
RewriteRule ^(.*[^/])$ /$1/ [R=301,L]
# SLASH END
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Циклическая переадресация – это постоянное перенаправление с одного адреса страницы на другой, которое вызывает сбои в работе браузера.

Содержание:

• Причины появления
• Как найти циклические редиректы
• Как исправить циклическую переадресацию 

Причины появления

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

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

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

4. Большой объем данных, сохраняющихся в кэше и cookie браузера.

5. Наличие запрета на сохранение cookie сайтов в браузере.

6. В файле .htaccess и в панели управления хостингом одновременно указана переадресация на протокол HTTPS.

7. Ошибка циклического редиректа может появиться при неправильной установке или настройке CMS.

Как найти циклические редиректы

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

Redirect Path

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

Redirectdetective

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

Netpeak Spider

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

Как исправить циклическую переадресацию

Для решения проблемы с редиректом воспользуйтесь следующими методами:

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

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

3. Очистить cookie, кэш и историю посещений в браузере.

4. Разрешить сохранение cookie сторонних сайтов.

5. Проверить файл .htaccess на наличие ошибок в правилах редиректов.

6. Переустановить CMS сайта (в самом крайнем случае).

Заключение

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

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

Однако иногда применение HTTPS может вызвать ошибку ERR_TOO_MANY_REDIRECTS, или циклическую переадресацию. Причиной проблемы могут быть уже существующие похожие или конфликтующие редиректы. Например, у Вас есть редирект с HTTP на HTTPS, а сразу после него — переадресация с HTTPS на HTTP. Это создаст петлю. Эта статья поможет Вам решить проблему ERR_TOO_MANY_REDIRECTS, вызванную новой установкой SSL 😊

Наиболее частые причины возникновения циклической переадресации:

Причина 1 – Конфликтующие или повторяющиеся редиректы в панели управления или .htaccess

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

Ещё один вариант — проверить раздел перенаправлений в панели управления hPanel, так как некоторые редиректы могут быть созданы там.

Причина 2 – Неверные настройки Cloudflare

Если Вы используете Cloudflare, причиной может быть неправильный тип связи SSL или отключенная опция Universal SSL.

Если Вы используете Cloudflare через Hostinger, откройте Хостинг → Управлять → Cloudflare:

И убедитесь, что для опции SSL / Тип шифрования связи выбран вариант Полный:

Если Вы используете Cloudflare напрямую, необходимое значение можно найти на странице SSL/TLS как SSL/TLS encryption mode.

Чтобы проверить включён ли Universal SSL, обязательно войдите в свою панель управления Cloudflare (если у Вас есть Cloudflare от Hostinger, используйте адрес электронной почты своего профиля и выберите опцию «Забыли пароль?»). Universal SSL находится на вкладке SSL/TLS → Edge Certificates:

Вы должны увидеть такое сообщение:

Причина 3 – Некорректный URL домашней страницы WordPress в базе данных

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

Там проверьте значения siteurl и home, они должны быть с https:// впереди:

Если вместо этого Вы видите префиксы http, измените их на https:// и Ваш сайт заработает правильно.