Здравствуйте, уважаемые друзья и гости блога! Сегодня пойдет речь о такой странной вещи на сайте, как ошибка 301 Moved Permanently (переехал навсегда) или по другому редирект 301.
Думаю. что все с таким сталкивались, а некоторые даже использовали данную “ошибку 301” на своих сайтах. Но не все знают для чего эта ошибка 301 или иначе редирект 301 нужна на сайте? Для чего он, 301 редирект, используется?!
Вот сейчас мы с вами и займемся разбором этого вопроса во всех его подробностях и нюансах …
Ошибка 301 или редирект 301 что это?
Как Вы уже наверное догадались по переводу слов “moved permanently” – это дословно, что сайт или отдельная его страница “переехал навсегда” по адресу на который Вас перекинул ваш браузер. Тут надеюсь все понятно и ясно без лишних пояснений!
Но возникает вопрос. Для чего это сделано вебмастером этого сайта? Почему он поставил редирект 301 и у нас с вами выскакивает иногда 301 ошибка? А все просто! Ошибка 301 появляется, когда сервер перебрасывает нас с уже не работающего сайта на страницу сделанную специально для перенаправления пользователя на рабочий сайт, но просто с некоторой задержкой или вообще на этой странице нужно самостоятельно перейти по ссылке. Вот это в двух словах об ошибке 301.
Теперь самый важный момент, зачем же все таки нужен редирект 301 на сайте …
Редирект 301 и для чего он нужен?
Есть несколько причин у вебмастера, чтобы использовать редирект 301. Вот они:
- Причина первая: Склейка домена с www и без www. При этом все seo показатели сайта и его ссылочный вес будут совмещены и не будут отличаться друг от друга.
- Причина вторая: Если вдруг пришлось сменить домен для сайта. Тогда применяется редирект 301 и он как раз перенаправляет посетителя сайта и поисковые роботы на рабочий домен сайта. Это также позволит вам сохранить все seo показатели вашего переехавшего сайта, как тИЦ, PR, так и своих посетителей.
- Причина третья: Использование редиректа 301 при переносе отдельной страницы сайта на другой ресурс. Бывают и такие случаи, когда это нужно сделать.
- Причина четвертая: Например у Вас есть сайт, где высокий тИЦ и PR и много посетителей. И еще есть другой сайт, который нужно немного пропиарить и прибавить к нему посещения. Тогда Вы просто на просто перенаправляете при помощи того же редирект 301, с одной страницы высоко посещаемого сайта на страницу более низко посещаемого сайта и тем самым выигрываете, добавив ему веса ссылочной массы и соответственно посещений.
Вот основные причины для использования редирект 301 или ошибка 301 Moved Permanently.
Теперь давайте узнаем, как правильно использовать редирект 301 на своем сайте и как настроить его через файл htaccess …
301 редирект и файл htaccess – как правильно настроить?
Как я вам уже говорил выше – 301 редирект это переадресация посетителя и поискового робота на сайт или отдельно взятую страницу сайта на URL адрес отличный от первоначально запрошенного в браузере.
Для чего это нужно мы с вами также уже разобрали. Но как же это сделать правильно на нашем сайте используя файл htaccess? Сейчас я вам все подробно объясню и приведу примеры внесения изменений в файл htaccess для вашего сайта!
- Перенаправление домена с www на без-www
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
или вот более понятный синтаксис:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]
- 301 редирект запросов без-www на домен с www префиксом
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]
Альтернативный вариант:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.(.*) [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]
- 301 редирект старого домена на новый в фале htaccess
Options +FollowSymLinks RewriteEngine on RewriteRule (.*) http://www.newdomain.com/$1 [R=301,L]
- Если вам нужно, чтобы вместо rewrite.htm загружался файл rewrite.html, добавьте в файл htaccess вот это:
RewriteEngine on RewriteBase / RewriteRule ^rewrite.htm$ rewrite.html [R=permanent]
- Чтобы заменить все .htm файлы на .html внесите в файл htaccess:
RewriteEngine on RewriteBase / RewriteRule ^(.*).htm$ $1.html [R=permanent]
- Варианты, когда не нужно использовать 301 редирект на вашем сайте:
- Если реализация 301 редиректа невозможна или она займет неоправданно много времени.
- Если контент вашего сайта дублируется на двух или нескольких страницах, но эти страницы должны быть доступны в поиске пользователю ввиду некоторых отличий (на пример, выбор какого-то товара).
- Если одна страница имеет несколько URL адресов (сортировка каталога товаров по различным категориям или критериям).
- Для кросс-доменов. Это, когда контент сайта на двух URL адресах дублируется, но он должен быть доступен на каждом из двух или нескольких доменах.
Этот материал посвящен выходу 301-ой статьи на моем блоге!
Может вам интересно узнать, что такое ошибка 503 и как ее устранить?
На этом пока все. Всем удачи и благополучия!
Код перенаправления 301 Moved Permanently протокола передачи гипертекста (HTTP) показывает, что запрошенный ресурс был окончательно перемещён в URL, указанный в заголовке Location (en-US). Браузер в случае такого ответа перенаправляется на эту страницу, а поисковые системы обновляют свои ссылки на ресурс (говоря языком SEO, вес страницы переносится на новый URL-адрес).
Даже если спецификация требует, чтобы при выполнении перенаправления, метод и тело запроса не изменялись, не все пользовательские приложения обращают на это внимание, и вы все ещё можете столкнуться с программами имеющими этот баг. Именно поэтому код 301 рекомендуется только в качестве ответа на GET или HEAD запрос, а для POST рекомендуется код 308 Permanent Redirect, так как он явно запрещает изменение метода запроса.
Статус
Пример
Запрос клиента
GET /index.php HTTP/1.1 Host: www.example.org
Ответ сервера
HTTP/1.1 301 Moved Permanently Location: http://www.example.org/index.asp
Характеристики
| Спецификация | Название |
|---|---|
| RFC 7231, секция 6.4.2: 301 Redirect Permanently | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
Совместимость с браузером
BCD tables only load in the browser
Смотрите также
Редиректы – это просто. Их используют для автоматического перенаправления пользователей с одного 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:
В отчете Redirect chain доступны детали по всем URL в цепочке, включая конечную страницу переадресации
Как исправить цепочки редиректов
- Перенастроить редирект. Это самый очевидный способ: нужно убрать все промежуточные звенья и настроить редирект напрямую, между двумя страницами.
- Заменить внутренние ссылки. Если вы не хотите связываться с перенастройкой редиректов, можно пойти обходным путем и отредактировать на сайте внутренние ссылки, которые ведут на перенаправленные страницы. Так, несмотря на фактическое сохранение цепочки, поисковые роботы уже не будут тратить ресурсы на неэффективные обходы многоуровневых ссылок, а пользователи – выжидать долгого перехода после нажатия на линк.
Посмотреть все внутренние ссылки, которые стоят на цепочку перенаправлений, можно в столбце 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 никогда не будет лишним.
Вот как это можно сделать:
- Выгружаем список всех URL из карты сайта.
- Прогоняем список через один из описанных выше онлайн-чекеров.
- Отфильтровываем 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 не будет.
Каждый раз, когда мы кликаем на какую-то ссылку или на наш сайт заходят поисковые роботы, происходит один из диалогов примерно такого содержания:
— Привет, сервер! Я поисковый робот. Могу я просканировать эту страницу?
— Привет! Конечно, заходи.
— А если вот эту страницу?
— А вот здесь пока ведутся ремонтные работы, приходи позже.
Язык ответов HTTP понимают и браузеры, и поисковые роботы, и SEO-специалисты, которым он нужен при работе с сайтом.
Если вы до сих пор путаете 301 с 302, и не знаете, зачем нужен 410 ответ — вам просто необходимо разобраться в кодах ответов HTTP, которые встречаются чаще всего. О них я и расскажу в этой статье. А еще мы узнаем, какую роль они отыграют в SEO и как не допустить ошибок в их использовании.
Какие ответы серверов существуют?
Начнем с того, что все коды ответов (состояния) серверов делятся на 5 классов, каждый из которых несет определенный смысл:
- 1XX. Эти информационные коды говорят о том, что запрос был понят, принят сервером и уже обрабатывается. Такие временные ответы обычно не отображаются на экране пользователей, но служат внутренними кодами для браузеров.
- 2XX. Обозначают успешную обработку полученного запроса. Они используются браузерами для подтверждения того, что запрос был принят, обработан и отражают его текущий статус.
- 3XX. Это коды перенаправления. Говорят о том, что серверу нужно выполнить дополнительные действия — например, перейти по редиректу на новый адрес.
- 4XX. Говорят об ошибке на стороне пользователя. Чаще всего появляются, если время ожидания браузера истекло или запрос был введен неправильно.
- 5XX. Говорят об ошибке сервера. Это значит, что вы запрашиваете специфический ресурс и он найден, но сервер не может дать вам к нему доступ. В конечном счете, запрос не может быть обработан.
Не все ответы сервера можно увидеть прямо на экране, большинство так и остаются внутренними кодами для браузеров и поисковых роботов. Чтобы быстро узнать статус любой страницы, откройте инструменты разработчика в браузере Chrome (нажмите F12). Перейдите на вкладку Network, обновите страницу и получите список статусов каждого элемента, включая саму страницу:
Именно в этих трех цифрах в колонке Status зашифрованы данные о состоянии страницы: можно ли ее сканировать, находится ли она по этому адресу, загружается ли все ее содержимое и т. д.
Какие же коды ответов сервера встречаются чаще всего? И что они значат для оптимизации сайта? Давайте внимательно рассмотрим самые полезные для SEO ответы и способы их обработки.
Ответы серверов, которые встречаются чаще всего
На самом деле существует более 70 различных кодов состояния сервера, но, скорее всего, вы никогда не столкнетесь с большей половиной из них. Однако знать самые распространенные коды состояния HTTP очень важно, потому что ответы сервера напрямую влияют на индексацию вашего сайта, краулинговый бюджет и продвижение ресурса в поисковых системах.
301 Moved Permanently
Говорит о том, что URL был навсегда перенесен на новое место. Браузеры самостоятельно переходят по 301 переадресации — никакого действия от пользователя не требуется.
301 код ответа обычно используют при переводе сайта с HTTP на HTTPS, склейке зеркал (страниц с www и без www), настройке слеша в конце URL, а также при переносе части сайта или всех страниц на новый домен. Этот редирект идеально подходит, если вы хотите передать ссылочный вес старой страницы на новую и сохранить результаты SEO-продвижения.
Совет: Старайтесь не перенаправлять пользователей с удаленного URL на главную страницу сайта. Например, в вашем интернет-магазине есть карточка с неактуальным товаром, но с неплохой ссылочной массой. Вы хотите сохранить этот вес и ставите 301 редирект на главную. Здесь и кроется ошибка! Такой редирект воспринимается Google как 404 Soft, а это означает, что поисковик не будет передавать сигналы со старого URL на новый. В такой ситуации всегда перенаправляйте страницу на максимально похожую (или 404, если аналогичная страница отсутствует).
Кроме того, избегайте цепочек редиректов с двумя и больше переадресациями, так как они создают дополнительную нагрузку на сервер и даже могут помешать пользователям перейти на ваш сайт как небезопасный. Google не индексирует дальше 4-го редиректа, и после каждого теряется вес, поэтому лучше ставьте прямые редиректы (вместо 1 -> 2 -> 3, сразу 1 -> 3).
Через несколько лет можете смело удалять 301, чтобы уменьшить нагрузку на сервер.
302 Found / Moved Temporarily
В отличие от постоянного 301 редиректа, этот — временный. Он говорит о том, что страница найдена, но пока размещена по другому адресу.
Обычно его путали с 301, а после того, как Google объявил, что все 3хx редиректы передают ссылочный вес, — ситуация усугубилась. По факту, его нужно ставить, если вы точно уверены, что будете использовать старый URL снова. Как раз об этом вы и сообщаете поисковику с помощью 302 сигнала, а он в ответ оставляет весь ссылочный вес за старой страницей.
Если вы будете использовать 302 редирект на постоянной основе, Google в конечном итоге воспримет его как 301 со всеми вытекающими последствиями. Также проверьте, нет ли на вашем сайте 302 редиректов, которые на самом деле должны быть 301 — такая ошибка встречается очень часто.
304 Not Modified
Сервер отдает 304 Not Modified ответ, когда страница остается неизменной со времени последнего посещения.
Все браузеры хранят в своем кэше данные заголовка Last-Modified. В свою очередь, это позволяет им точно знать, когда страница была в последний раз изменена. И когда поисковые роботы заходят на страницу и видят, что значение заголовка совпадает с уже сохраненным в кэше, сервер возвращает 304 ответ.
Этот код можно использовать для ускорения индексации сайта. Ведь получив такой ответ, поисковый робот не будет загружать страницу, а значит, успеет проиндексировать больше других страниц.
Лучший ответ сервера для оптимизатора ― 200 ОК. Он означает, что запрос успешно обработан. Но 304 несет ту же нагрузку. Как правило, на новые страницы и первое посещение должен выдаваться ответ 200, на все последующие, если не произошло изменений — 304.
403 Forbidden
Этот код ответа говорит о том, что пользователю запрещен доступ к странице.
403 ошибка может появиться, если пользователь вошел на сайт, но у него нет разрешения для доступа к закрытой внутренней сети. Например, если я попытаюсь зайти в кабинет админа SE Ranking по прямому URL, используя пароль и логин личного аккаунта, на экране будет 403 ошибка «Нет доступа». Также 403 ошибка возникает, если индексный файл для главной указан неправильно. Он обязательно должен иметь название index и расширение: *.shtml, *.html, *.htm, *.phtml или *.php.
Кроме того, когда вы переносите сайт на HTTPS, то 403 ответ появится, когда DNS-кэш ещё не успел обновиться, а вы уже что-то от него хотите. Лучше подождите, или, если это вопрос жизни и смерти, обновите кэш принудительно.
Совет: страницы с 403 кодом ответа в конечном итоге будут удалены из индекса, поэтому Google рекомендует использовать 404 ответ вместо 403.
404 Not Found
Самая «любимая» ошибка в SEO. Говорит о том, что сервер ничего не нашел по указанному адресу, хотя соединение между сервером и клиентом прошло успешно.
Не стоит переживать, если вы увидите много 404 страниц в своей Google Search Console. Поисковик просто сообщает вам, какие страницы удалены, а вам уже решать, нужно ли их проверять. Но что стоит точно сделать — убрать все ссылки на удаленные страницы, чтобы не путать посетителей при навигации по вашему сайту.
Обычно мы видим этот код ошибки, когда вводим неправильный URL в браузер и, как следствие, пытаемся получить доступ к несуществующей странице. Или, например, владелец сайта удалил страницу без редиректа URL по новому адресу. Как результат — 404 ошибка. Чтобы решить проблему, посетителю нужно перепроверить написание URL или попробовать найти информацию на сайте самостоятельно через поиск, а владельцу ресурса ― исправить «битые» ссылки на рабочие.
404 страница не индексируется и не передает вес. Поэтому некоторые оптимизаторы грешат «мягкой 404», выдавая стандартную страницу с ответом 200 вместо 404. Но это считается плохой практикой, потому что 200 код говорит Google, что по этому URL есть реальная страница. В конечном счете, страница оказывается в индексе, и поисковик продолжает свои попытки сканировать несуществующие URL-адреса вместо сканирования ваших реальных страниц.
Как настроить 404 страницу для своего сайта
Если раньше после перехода на несуществующую страницу пользователь видел перед собой только цифру 404, то сейчас — просто море креатива. Но не стоит забывать, что он пришел с конкретным запросом и ваша задача — дать решение, а не развлечь его. Поэтому не забудьте оптимизировать 404 страницу — добавьте навигацию своего сайта или контактную форму, особенно если на 404 страницы идет трафик.
Если ваша CMS (система управления контентом) не создала 404 страницу, вы можете создать ее самостоятельно.
С помощью htaccess
Самый простой способ настроить страницу с 404 ошибкой — добавить сообщение об ошибке, например ErrorDocument 404 “<H1> Not Found </ H1>” в сам файл .htaccess.
В результате у вас должно получиться что-то вроде этого:
Через PHP
Вы можете использовать функцию заголовка и менять контент 404 страницы в зависимости от разных сценариев (например, юзер сделал ошибку в URL самостоятельно или уже перешел по «битой» ссылке с какого-то ресурса).
Детальнее — в этой инструкции.
Через WordPress
У вас есть несколько вариантов:
- Отредактируйте существующую страницу 404, которая уже есть в вашей теме.
- Добавьте свою 404 страницу, если ваша тема ее не предлагает по умолчанию.
- Используйте плагин для 404 страницы.
Подробности можно узнать здесь.
410 Gone
Этот ответ говорит о том, что страница или документ не доступны по указанному адресу и новый адрес неизвестен.
Более того, инструмент проверки URL в Google Search Console обозначает 410 ответы как 404, что приводит к еще большему количеству 404 ошибок, обнаруженных в консоли.
410 ответ чаще всего встречается на страницах с низким трастом, без ссылок или тех, что удалены безвозвратно. Например, с товаром, которого больше не будет в продаже.
Поскольку Google все-таки относится к 404 и 410 ошибкам по-разному, нужно использовать 410 код только тогда, когда вы точно знаете, что страница удалена и больше не вернется. Такой ответ по умолчанию кэшируется, поисковый робот больше не заходит на страницу, а она в свою очередь удаляется из индекса.
Совет: подумайте дважды, прежде чем удалять страницу навсегда. Если вы сомневаетесь, лучше поставить редирект на похожую страницу и получить хотя бы часть текущего трафика. Если же удаления страницы не избежать, обязательно проверьте ссылки, которые на нее ведут — как только страница будет удалена, магия ссылок закончится тоже.
503 Service Unavailable
Этот статус говорит поисковым роботам и пользователям, что в данный момент страница недоступна и, следовательно, сервер не может обработать входящий запрос.
В большинстве случаев 503 появляется, если сервер перегружен, например, превышено ограничение на число входящих запросов или сервер проходит техническое обслуживание.
Могут быть ещё такие причины:
- DDOS-атака на сайт.
- Использование большого количества скриптов и других элементов с внешних ресурсов: виджеты, картинки.
- Запросы к базе данных и извлечение оттуда информации занимают слишком много времени.
- Чрезмерное количество обращений к сайту от поисковиков, пользователей или сервисов по парсингу сайта.
Совет: в идеале в сообщении с 503 ошибкой обязательно нужно указать, что пользователю нужно вернуться на сайт через Х времени. К сожалению, так очень редко делают — обычно просят попытать удачу позже.
И последнее, но не менее важное: код состояния 503 не позволяет поисковым системам индексировать сайт. Кроме того, он сообщает, что сайт плохо обслуживается, потому что пользователи не могут попасть, куда хотели. Поэтому важно, чтобы неполадки были устранены как можно быстрее — иначе это скажется на позициях сайта.
Как настроить 503 страницу для своего сайта через PHP
Вот как выглядит код состояния 503 в PHP:
<?php
header("HTTP/1.1 503 Service Temporarily Unavailable");
header("Status: 503 Service Temporarily Unavailable");
header("Retry-After: 3600");
?>
Больше подробностей можно почитать в этой инструкции.
Как проверить коды состояния всех страниц на сайте
Чтобы быть в курсе всего, что происходит на вашем сайте, нужно мониторить коды состояния всех ваших страниц. Конечно, для этого можно использовать расширение Live HTTP Headers для Chrome или отчет «Покрытие» в Google Search Console, но лучше, если вы проанализируете ответы до того, как до них доберутся поисковые роботы.
Если вы хотите быстро проверить коды состояния всех страниц вашего сайта одним кликом, обязательно попробуйте наш инструмент «Аудит сайта».
Инструмент не просто проверит все страницы на вашем сайте и проанализирует ключевые параметры оптимизации, но и выполнит SEO-аудит всего ресурса по важным техническим параметрам, найдет ошибки и даже подскажет методы их решения.
Все статусы страниц вы увидите в основном отчете, в котором проанализированы технические параметры, страницы, мета-теги, ссылки и контент.
Кстати, вы можете воспользоваться бесплатной пробной версией, чтобы протестировать все основные функции аудита.
Если же вас интересуют только коды состояния всех страниц, просто перейдите на вкладку «Сканированные страницы». Все данные можно экспортировать в формате XLS для подробного изучения:
Безусловно, найти ошибки в кодах ответов это только полдела. Решать проблемы, связанные с ошибками сервера, вам все равно придется самостоятельно, но сам поиск ошибок у вас теперь будет занимать считанные минуты. Оптимизировав коды состояния своих страниц, не забудьте отправить их на повторную индексацию.
Чтобы сдать этот экзамен на отлично, мы подготовили для вас шпаргалку по правилам HTTP-знаков с лучшими SEO-советами. Теперь какой бы знак не встретился у вас на пути, вы будете знать, что делать.
Юлия — контент-маркетолог c 10-летним опытом работы в журналистике, копирайтинге, рекламе и PR.
Своим опытом и знаниями она делится, создавая полезные статьи про SEO и диджитал-маркетинг для блога SE Ranking и популярных медиа.
Когда Юлия не пишет статьи, она осваивает новые асаны, путешествует и помогает волонтерской организации YWCA.
Содержание
- 1 Что такое 301 редирект для сайта
- 2 Для чего нужен 301 Redirect
- 2.1 Адрес страницы изменен
- 2.2 Склейка зеркал
- 2.3 Смена домена
- 2.4 Исправляем технический бардак
- 2.5 301 редирект вместо 404 Not Found
- 3 Когда не надо использовать код сервера 301 и другие нюансы
- 3.1 Временная переадресация при неуверенности
- 3.2 Спасение от фильтров стоит ли?
- 3.3 Нюансы использования 301 редиректа
- 4 Как настроить 301 Редирект в .htaccess на Apache
- 4.1 301 Редирект с www на без www для склейки зеркал
- 4.2 301 Redirect без www на www
- 4.3 301 Редирект с https на http и наоборот в Htaccess
- 4.4 Универсальный редирект с index.php и .html на ссылку без них
- 4.5 301 редирект со страницы на страницу
- 5 Redirect в PHP
- 5.1 Как убрать дубль адреса сайта в адресной строке с помощью ПХП
- 5.2 Как убрать дубль страницы со слешем с помощью PHP
- 6 Особенности настройки Permanent Redirect на nginx.
- 6.1 301 редирект на nginx с www на без www
- 6.2 Permanent Redirect 301 на nginx с домена без www на домен с www
- 6.3 Redirect 301 в nginx.conf со страницы с index.php на адрес без index.php
- 7 Как сделать Редирект с http на https без htaccess — ковыряем web.config
- 8 Когда редирект с https на http не работает — что делать?
- 9 301 moved permanently что это и как исправить
- 10 302 Редирект — временное переселение
- 10.1 Чем отличается 302 Редирект от 301?
- 11 Сервисы для контроля Редиректов
Сегодня мы поговорим о редиректе и постараемся разобрать данный вопрос максимально широко и в то же время не распыляться. Важность редиректов в сео просто огромна, в то же время велики и риски проблем из-за неправильной переадресации. Вопрос важный, сложный и очень нужный, так что читаем далее!
Что такое 301 редирект для сайта
Что такое 301 редирект? Даже не так. Что такое Redirect? Это команда поисковому роботу перенаправлять посетителя на другую страницу, которая была перемещена в другое место. Цифра 301 — это код, который говорит об окончательном перемещении страницы в новую локацию. Ведь когда мы переходим на какую-то страницу и нам выдается ошибка, мы видим перед собой код этой ошибки и расшифровку. Например, код 404 говорит нам — Not Found, что означает — страница не найдена, а 505 ошибка сообщает, что ответ от сервера не был получен. Но если вышеописанные ошибки видны посетителю на открытой странице браузера, то шифры перенаправления видят только роботы, которые и направляют гостя по другой ссылке (если, конечно, редирект был настроен правильно). Вот как раз новую ссылку, меняющуюся в адресной строке браузера посетитель и заметит. То есть 301 редирект перебрасывает пользователя с одной страницы на другую, не останавливаясь на промежуточном адресе, доводя до конечного места локации контента.
Официальное название редиректа — Permanent Redirect 301, используется как инструмент в SEO. Код прописывается в файлах на сервере, где расположен сайт, и при обращении по ссылке, которая указана в редиректе как та, с которой нужно увести посетителя, сервер отдает системе код 301 с новыми данными для отображения ссылки и «пометкой» — перемещен на другой адрес (moved permanently).
Каким образом происходит процесс перемещения? С помощью кода в файлах на сервере с сайтом размещается специальный код, который роботы поисковых систем считывают и выполняют. В этом коде обязательно присутствуют константы: откуда переместить и куда. Причин для использования 301 редиректа на сайте может быть множество, рассмотрим основные из них в этой статье, ведь, возможно, что какой-то способ вам понабиться, и вы им воспользуетесь.
Я подготовил мощный мини-курс по SEO текстам, которые сами выходят в ТОП! Курс записан в формате пошаговых инструкций и в данный момент доступен БЕСПЛАТНО, вместо 2999, так что не упустите! Ссылка на скачивание мини-курса.
Для чего нужен 301 Redirect
301 редирект является тем видом перенаправления, который поисковые системы признают как правильное решение для перемещенных страниц сайта. Поэтому при настройке Permanent Redirect никаких изменений в ранжировании или наложений штрафных санкций не происходит. Это естественная переадресация. Какое-то время назад этот способ переадресации использовался вебмастерами для выхода из под фильтров, но не факт, что на сегодняшний день этот способ может помочь. Хотя от определенных фильтров иногда спасает (ссылка).
На сегодняшний день основными показаниями к использованию 301 Редиректа являются ситуации:
- изменения адреса страницы сайта, даже на одну букву или символ;
- склейка зеркал (домен с www и без www, домены в разных зонах);
- смена домена интернет-ресурса;
- борьба с дублями из-за технического бардака.
Где делают Permanent Redirect 301? Способы зависят от возможностей вебмастера и его доступа к данным. Поэтому создать 301 Редирект можно через htaccess, php, настройки сервера, javascript. Естественно, что использовать все способы одновременно не надо.
Адрес страницы изменен
Самый простой и распространенный вариант наломать мелких дров в админпанели сайта и создать ошибки при переходе по ссылке — это откорректировать уже проиндексированный неЧПУ. Когда формируется новая страница сайта, ей присваивается номер и адрес из латинских букв. Первое время не очень красивая ссылка никого не смущает, но когда обнаруживается, что можно сделать покрасивше — руки так и чешутся откорректировать url к более человекоподобному:). И тут наступает момент, когда в вебмастере гугла и яндекса обнаруживается огромное количество дублей. Особенно, когда была видоизменена категория сайта в структуре. Google, например, после обновления базы, то есть когда робот заново обошел сайт с начала до конца, покажет в панели вебмастера новые адреса страниц, но старые тоже оставит в поиске, сделав замечание владельцу, что у него на сайте присутствуют одинаковые мета-данные, которых на самом деле там и нет. Переход по старому адресу из поисковой системы выдаст пользователю ошибку 404 (если конечно она правильно настроена), тем самым убив желание потенциального посетителя переходить далее на сайт.
Итог бездумной корректировки URL? Поисковая система видит отказ пользователя и понижает сайт в выдаче по поисковому запросу. Катастрофа. А все из-за какой-то корявой ссылки, которая изначально осталась незамеченной и никого, кроме самого «вебмастера» совершенно не смущала. Но эту ситуацию можно исправить как раз 301 редиректом. Как сделать 301 редирект с одной страницы на другую (со старого url на новый), расскажем дальше.
Склейка зеркал
Зеркала — это, например, когда сайт один, а доменов несколько. Обычно, компании, работающие на бренд, выкупают сразу все доступные зоны, чтобы никто не смог воспользоваться их именем. Также присоединяются названия адреса сайта через дефис и без него. Но даже без такой катавасии, на вашем сайте 100% есть зеркала! В данном случае это написание адреса сайта с www и без, а также доступ через https. В любом из этих случаев делается 301 redirect, причем еще при создании вебресурса, иначе от головной боли с дублями страниц потом тяжело избавится. Редирект 301 с www на без www и наоборот (если основным сайтом является www.имя_домена.ru), а также c http на https (сомневаюсь, что часто бывает перенаправление наоборот), включая разные доменные зоны, обязателен! Для проверки наличия основного зеркала, помогут панели вебмастера поисковых систем.
Смена домена
По разным причинам сайту нужно переехать на новый домен. Чаще всего компания делает ребрендинг, а название домена не отвечает поставленным целям. Ради благозвучия и соответствия названия домена бренду, сайт переезжает. Чтобы не потерять уже постоянных посетителей и поставить перед фактом поисковых роботов, сеошники делают 301редирект со старого домена на новый. Очень важно, чтобы поисковые системы получали ответ от сервера код 301, а не 404 или 302. Работа окажется легкой, если сайтик небольшой (визитка, лэндинг, промо-страница) и понадобится много труда для огромного интернет-магазина, потому что перенаправление на главную страницу здесь не подойдет. Каждый старый URL привязывают к аналогичному новому (постраничная переадресация).
Исправляем технический бардак
Здесь вариантов устроить технический бардак уйма начиная с нарушений элементарных правил создания страниц и заканчивая дублями, которые создаются плагинами на сайте (переводчики, комментарии, поиск по сайту). Сюда же можно отнести мобильные версии выдачи страниц (с этим в последнее время хлопот немало), но их лечат прописыванием canonical. Дубли создаются не только по вине вебмастера, есть и вынужденные. Но случаи по неопытности первого, все же больше наносят вреда. Некоторые прячут такие погрешности закрытием от индексации, но лучше использовать 301 Permanent Redirect и тогда робот точно поймет, что хочет ему сказать человек.
301 редирект вместо 404 Not Found
Не торопитесь сразу убирать 404 (Страница не найдена) и везде проставлять 301 Редирект. Тут важно прочувствовать разницу. Код 404 Not Found обязателен на страницах, которые удалены или никогда не существовали, а вот с битыми ссылками можно бороться 301 Редиректом! Если страница, которую ищет пользователь, существует, зачем отсылать его по древу сайта для ее поиска? Найдена битая ссылка на какую-то страницу? Перенаправляем по правильному адресу кодом 301 и посетитель даже не догадается о том, что ссылка уже была нерабочая.
Когда не надо использовать код сервера 301 и другие нюансы
Есть моменты когда так и хочется воспользоваться 301 редиректом на сайте, но не всегда цель оправдывает средства. Вообще, желательно, во внутренних ресурсах сайта использовать код 301 только в случаях крайней необходимости. Иначе, бездумно посылая робота со ссылки на ссылку, можно создать бесконечное циклическое перенаправление, которое просто убьет весь сайт. И поисковый робот бросит все старания найти место размещения контента, чем навредит репутации ресурса в целом, не доведя посетителя до конца.
Временная переадресация при неуверенности
Permanent Redirect 301 (Перманентный редирект) используется для указания роботам окончательного решения. Что это значит? А это говорит о том, что если вы не уверены навсегда ли будет перемещена страница, тогда безопасней 301 редирект не делать. Redirect склеивает странички, и робот уже просто не видит первой, а это значит, что она канула в лету безвозвратно. Для временной переадресации используют другие способы, когда при принятии решения вернуть все на свои места, не вызовет никаких проблем.
Спасение от фильтров стоит ли?
Когда-то 301 редиректом спасались от фильтров поисковых систем, но нет 100% гарантии, что фильтр в будущем не переместится на новый домен. Создавая постоянное перенаправление на новый сайт, перемещается ТИЦ с PR. Мною замечено, что с алгоритмом «Пингвина» еще можно помудохаться, а вот от АГС такие манипуляции не спасут однозначно. Поэтому сейчас Permanent Redirect не так популярен для спасения от фильтров ПС, но зато помогает не потерять заслуженные позиции. Чего вполне достаточно для усердных вебмастеров.
Нюансы использования 301 редиректа
- Исправлять ссылки ведущие извне 301 редиректом вполне нормально, потому что отредактировать их у нас нет возможности. А вот кривые внутренние пути надо максимально исправлять вручную другими, более щадящими способами.
- Настраивая redirect, нужно быть предельно внимательным, чтобы не захватить какие-нибудь системные ссылки из корневых каталогов или пути к папкам и плагинам.
- Для поиска ссылок, нуждающихся в исправлении, необходимо использовать инструменты поисковых систем Google и Яндекс Вебмастер. Очевидные дубли страниц видны в Гугл Вебмастер во вкладке Вид в поиске > Оптимизация HTML, а в Яндексе — Индексирование — Статистика.
- Между нашими главными поисковыми гигантами есть одна огромная особенность: если Google после обновления базы самостоятельно уберет исправленные ошибки из панели вебмастера, то Яндекс этого может вообще не сделать. Это дело можно поправить прописыванием в robot.txt запрета на индексирование или подать ручной запрос в поддержку на удаление из базы плохих ссылок. В 2016 Вебмастер Яндекса перешел на новый уровень, расширив функционал системы. Правда, некоторые возможности еще не работают, но уже функционируют корректно бывшая аддурилка, а теперь запрос на внеочередной переобход страницы роботом, проверка мобильности страниц, удобная статистика по ключевым словам с разбивкой на ТОП 3, 10, 50.
Как настроить 301 Редирект в .htaccess на Apache
Одним из самых старых и распространенных способов запустить 301 редирект на Apache является прописывание специального кода в корневом каталоге сайта в файле .htaccess. Неоспоримым преимуществом этого метода является быстрая загрузка команд сразу с сервера еще до запуска скриптов без дополнительной на него нагрузки. Не зря перед названием htaccess я поставил точку — это файл без названием с расширением. Знаю, непривычно, но этот файлик есть в корневой папке сайта или, по крайней мере, должен быть.
Как найти htaccess? Открываем FTP-клиент (например, Fillezilla), переходим на каталог сайта и опля! Не случилось опля? Нет такого файла? Попробуйте проверить настройки ftp-клиента. К примеру, в FilleZille нажмите на вкладку Сервер и выберите пункт Принудительно отображать скрытые файлы. Ничего не появилось? Значит, создаем новый файл на свое компьютере. Создаем .txt-шный файл, вписываем нужный код и сохраняем. И тут паника: Windows не сохраняет файл с расширением .htaccess и без имени! Катастрофа, думаете вы. Вовсе нет. Забрасываете файл с расширением тхт через ftp-менеджер в корневую папку сайта и там переименовываете. Ура! Файл .htaccess создан. Теперь, при внесении каких-либо изменений в него, достаточно его просто открыть в блокноте через ftp-клиент или в NotePad++.
А какой код писать, как настроить 301 редирект в htaccess? А вот в зависимости от того, для чего он нам нужен, и будем моделировать код перенаправления. В первую очередь, Permanent Redirect 301 прописывается в самом начале страницы htaccess после строки «R ewriteEngine On», для того чтобы команда обрабатывалась первой. Сервер читает файл построчно сверху. Ниже привел популярные коды для перенаправления.
301 Редирект с www на без www для склейки зеркал
Заранее оговорюсь — во всех примерах в команде R ewriteCond лишний пробел, уберите его перед копированием!
RewriteCond %{HTTP_HOST} ^www.site.ru$ [NC]
R ewriteRule ^(.*)$ http://site.ru/$1 [R=301,L]
301 Redirect без www на www
R ewriteCond %{HTTP_HOST} ^site.ru$ [NC]
R ewriteRule ^(.*)$ http://www.site.ru/$1 [R=301,L]
Чувствуете разницу? R ewrite переводится как переписать, Cond — условие, Rule — правило. А с виду для русскоязычных можно запомнить: кто рулит? Рулит вторая строчка, то есть указываем тот путь, куда перенаправляем. Каждый второй вариант приведенных выше правил лучше первого тем, что при перенаправлении будет проверяться не только наличие www в адресе сайта, а и соответствие названия домена указанному. Таким образом, исключается возможность доступа посторонних лиц к файлам на сервере, например, через IP-адрес. А это, как-никак, дополнительная защита.
А теперь расшифровка всех символов в коде 301 редиректа:
R ewriteCond — искомое условие, то есть ссылка, которую, в нашем случае, нужно перенаправить.
R ewriteRule — правило, которое необходимо выполнить с тем условием, которое указано в предыдущей строке.
Мета-символы:
^ — начало строки;
$ — конец строки;
! — отрицание;
— за экранирующим слешем считать метасимволы обычными символами;
. — любой символ в количестве одной штуки:)
() — разбиение на группы;
? — повторение символа от 0 до 1 раза;
* — повторение от 0 до 65536;
+ = повторение от 1 до 65536;
[] — дополнительные опции;
NC (NOCASE) — отключить проверку регистра;
R=301 (Redirect 301) — вернуть ответ браузеру с кодом 301;
L (LAST) — остановка процесса перенаправления, указывая на конечность текущего местоположения данных.
%{QUERY_STRING} — набор переменных для php.
301 Редирект с https на http и наоборот в Htaccess
Небольшим кодом делаем перенаправление с https на http в htaccess:
R ewriteEngine On
R ewriteCond %{HTTPS} on
R ewriteRule ^.*$ http://%{SERVER_NAME}%{REQUEST_URI}
Если нужно сделать обратный редирект 301 с http на https, то прописываем такой вариант:
R ewriteEngine OnR ewriteCond %{HTTPS} =on
R ewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]
Универсальный редирект с index.php и .html на ссылку без них
Создание дублей страниц с добавкой в конце пути index.php или расширения html у веб-страницы происходит сплошь и рядом. Явно это становится видно, когда адрес вашей главной страницы уже выглядит так http://ваш_сайт/index.php или http://ваш_сайт.html. Не очень красиво, правда? Короче — хуже только крокозябры:) Предлагаю исправить ситуацию универсальным кодом:
R ewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.(php|html) HTTP/
R ewriteRule ^(.*)index.(php|html)$ $1 [R=301,L]
А добавки к адресу, которые берутся вроде бы ниоткуда, когда на сайте все нормально настроено: http://ваш_сайт/страница_перехода.html&post=абракадабра? Эти малопривлекательные крякозябры цепляются к хвосту благодаря социальным сетям, где лояльный читатель поделился вашим постом. К адресам сайтов добавляются статистика для отслеживания источников (и тут, екалемене, анонимности никакой).
Избавляемся от абракадабры прописыванием 301 редиректа в htaccess:
R ewriteCond %{REQUEST_URI} ^(.*)&post=R ewriteRule ^(.*)&post=(.*)$ $1 [R=301,L]
Аналогично проделываем процедуру с другими видами хвостиков, например, когда после адреса страницы вылазит &bau=fdf=fdwnf,Jf;pg’;bui=ds643dfvv5, видоизменяем код так:
R ewriteCond %{REQUEST_URI} ^(.*)&bau=
R ewriteRule ^(.*)&sa=(.*)$ $1 [R=301,L]
Структура остается прежней, меняем только первую повторяющуюся часть ссылки. А таких «липучек» может быть много, но делать это надо, потому что такие ссылки индексируются поисковыми системами.
Еще одним примером могу привести, когда нужно убрать после фразы index.php другие параметры, сопутствующие в пути из-за скриптов. Если ссылка выглядит как http://ваш_сайт/index.php?list=1, можем очистить хвосты скриптов следующим кодом в htaccess:
R ewriteCond %{QUERY_STRING} ^list=1$
R ewriteRule ^(.*).php?(.*)$ $1.php [R=301,NC,L]
Избавится от дублей с index.php (редиректс index.php на категорию), чтобы после ЧПУ не было больше приставок, поможет следующий код:
R ewriteRule ^(.*)index.php$ $1 [R=301,L]
Теперь вид сайта в адресной строке будет выглядеть как http://ваш_сайт.ru, а не http://ваш_сайт.ru/index.php. Правда, так лучше?
301 редирект со страницы на страницу
Когда нужно сделать 301 редирект с одной страницы на другую можно воспользоваться следующим кодом в нескольких вариациях синтаксиса. Только каждое перенаправлению на новую страницу создается отдельной строкой. Вот как выглядят правила:
Redirect 301 /адрес_страницы_1.html http://ваш_домен.ru/адрес_страницы_2.html
или
Redirect permanent /адрес_страницы_1.html http://ваш_домен.ru/адрес_страницы_2.html
или
RedirectPermanent /адрес_страницы_1.html http://ваш_домен.ru/адрес_страницы_2.html
Обратите внимание, что адрес домена, на который перенаправляется первая страница, может быть совершенно другим. То есть это может быть реальная переадресация со страницы одного сайта на страницу другого.
Redirect в PHP
301 Редирект в PHP используется, когда с созданием в htaccess возникают трудности, а функция в ПХП будет более логичной. Синтаксис permanent redirect в php выглядит так:
header(«HTTP/1.1 301 Moved Permanently»);header(«Location: http://ваш_домен.ru»);die(«Redirect»);
Данный синтаксис сообщает браузеру пользователя с какой страницы и на какой сайт надо сделать перманентный редирект. Стоит учесть что http://ваш_домен.ru — необязательно главная страница одного и того же ресурса, это может быть как отдельная страница, категория, так и совершенно левый домен. Если при написании функции redirect была допущена ошибка, браузер сообщит об этом в окне надпись «Redirect». Примеры функций Permanent Redirect далее.
Как убрать дубль адреса сайта в адресной строке с помощью ПХП
if (strpos($_SERVER[‘REQUEST_URI’], ‘http://ваш_сайт.ru’) !== false)
{
$real_page_url = «http://ваш_сайт.ru».str_replace ( «/http://ваш_сайт.ru», «», $_SERVER[‘REQUEST_URI’] );
header(«HTTP/1.1 301 Moved Permanently»);
header(«Location: $real_page_url»);
die(«Redirect»);
}
Вот такой функцией убирается дублирование адреса вида: http://ваш_сайт.ru/ http://ваш_сайт.ru/страница. Обратите внимание на написание URL в условии — здесь оно пишется как URI. Получается что при выполнении условия нахождения в адресной строке двойной ссылки, браузер должен перенаправить пользователя 301 редиректом на корректную страницу с помощью переменнной $real_page_url, а кривую ссылку считать ложной.
Как убрать дубль страницы со слешем с помощью PHP
if ( ( $_SERVER[‘REQUEST_URI’], — 1, 1 ) == ‘/’ )
{
$requested_url = rtrim($requested_url, ‘/’);
header(«HTTP/1.0 301 Moved Permanently»);
header(«Location: $requested_url»);
die(«Redirect»);
}
Эта простая функция проверяет наличие в адресной строке конечного слеша. И если слеш обнаружен, то он обрезается с помощью перенаправления на ссылку без конечного слеша.
Особенности настройки Permanent Redirect на nginx.
Permanent Redirect на nginx используют не так часто, как на Apache — на это есть множество причин, и основная из них — это сложности настройки этого конфигурационного серверного файла. Да и не все хостинги дают возможность вебмастеру таким способом решать возникшие трудности. Одним из вероятных проблем, которые можно решить 301 редиректом на nginx — это закрытие индексирования через IP и тестовые сервера.
Чтобы настроить permanent redirect на nginx с ip на http://ваш_домен.ru — находим файл nginx.conf, чаще всего размещенный по пути /etc/nginx/nginx.conf. В нем прописываем строки:
server {listen 0.0.00.000:80 default;server_name _;R ewrite ^/(.*)$ http://ваш_домен.ru/$1 permanent;}
Нолями обозначили IP, через который был доступен сайт и порт 80. Таким способом перенаправляем любой запрос по IP на нормальную ссылку. Можно обойтись и без 301 редиректа, а указать закрытие доступа, строкой return 444, вместо R ewrite ^/(.*)$ http://ваш_домен.ru/$1 permanent, и выполнить ‘invoke-rc.d nginx reload’.
Одним из вариантов не ковыряться в nginx является корректная настройка HTTP-сервера, на котором закрывается соединение через IP. Если страницы через доступ по IP попалив индекс, то после таких манипуляций, со временем они исчезнут оттуда. Но как всегда Яндекс может самостоятельно этого не сделать — и тогда опять пишем в поддержку.
301 редирект на nginx с www на без www
server
{
listen 80;
server_name www.имя_сайта.ru;
R ewrite ^ http://имя_сайта.ru$request_uri? permanent;
}
Permanent Redirect 301 на nginx с домена без www на домен с www
server
{
listen 80;
server_name имя_сайта.ru;
R ewrite ^ http://www.имя_сайта.ru$request_uri? permanent;
}
Redirect 301 в nginx.conf со страницы с index.php на адрес без index.php
location = /index.php {
if ($request_uri = /index.php) {
R ewrite ^ http://$host? permanent;#301 redirect
}
fastcgi_pass unix:/tmp/fastcgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
Как сделать Редирект с http на https без htaccess — ковыряем web.config
Если вы хотите сделать 301 редирект с http на https без htaccess и вам не подходят настройки nginx, возможно, у вас хостинг под управлением Windows? Тогда добавляем вот такие строчки в файл web.config на сервере:
<?xml version=»1.0″ encoding=»UTF-8″?>
<configuration>
<system.webServer>
<R ewrite>
<rules>
<rule name=»Redirect to https» stopProcessing=»true»>
<match url=»(.*)» />
<conditions>
<add input=»{HTTPS}» pattern=»off» ignoreCase=»true» />
</conditions>
<action type=»Redirect» url=»https://{HTTP_HOST}{REQUEST_URI}» redirectType=»Permanent» />
</rule>
</rules>
</R ewrite>
</system.webServer>
</configuration>
Таким образом, будет настроено полное перенаправление домена с http на https, вместе с поддоменами. Но если поддомены трогать запрещено, тогда используем код ниже, вставляя его в тот же web.config:
<?xml version=»1.0″ encoding=»UTF-8″?>
<configuration>
<system.webServer>
<R ewrite>
<rules>
<rule name=»Redirect to https» stopProcessing=»true»>
<match url=»(.*)» />
<conditions>
<add input=»{HTTPS}» pattern=»off» ignoreCase=»true» />
<add input=»{HTTP_HOST}» pattern=»^domain.ru» />
</conditions>
<action type=»Redirect» url=»https://{HTTP_HOST}{REQUEST_URI}» redirectType=»Permanent» />
</rule>
</rules>
</R ewrite>
</system.webServer>
</configuration>
Когда редирект с https на http не работает — что делать?
Не всегда прописывание одного кода на разных сайтах срабатывает с полным успехом. Бывает, возникают ошибки по вине сервера, из-за бардака в конфигурационных файлах или элементарно сделана ошибка в командных строчках.
Когда 301 редирект с https на http не работает — пользуемся другими вариациями кода. В htaccess меняем предыдущий распространенный код на вот такой:
# Redirect HTTPS to HTTP
R ewriteCond %{HTTP:X-Forwarded-Proto} =https
R ewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Если не работает redirect 301 с http:// на https://, в .htaccess прописываем следующее:
R ewriteEngine On
R ewriteCond %{SERVER_PORT} !^443$
R ewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
В случае возникновения циклической реакции — корректируем под такой шаблон:
R ewriteEngine On
R ewriteCond %{HTTPS} off
R ewriteCond %{HTTP:X-Forwarded-Proto} !https
R ewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
301 moved permanently что это и как исправить
Что это за глава? Подумаете вы после прочтения всего того, что было описано выше. А я, в двух словах, поясню. Moved permanently в переводе означает «переехал навсегда». Некоторые вебмастера еще и краем уха не слышали о 301 Moved permanently, тем более о Permanent Redirect, то есть о постоянном редиректе, и ищут ответ, почему у них выбивает такую ошибку на странице. А теперь обращение к тем, кто искал, как исправить 301 moved permanently — начинайте читать статью сначала и находите свой конкретный случай для решения своих задач. А мы переходим к следующему этапу: коротко о том, что такое 302 редирект и зачем он нужен, если есть 301-й.
302 Редирект — временное переселение
Что такое 302 редирект и чем он отличается от 301? Исходя из названия, 302 Temporary redirect (временное перенаправлению) осмелюсь сказать, что этим редиректом мы можем временно перенаправлять робота и посетителей с одной страницы на другую. Сколько может длиться период временного перенаправления — это никем не указано, то есть догажываемся, что до момента, пока это перенаправление будет актуальным. Здесь хочеться уточнить, что после злоупотребления сеошниками временными перенаправлениями и введения санкций от поисковых систем к недобросовестным сайтам, крайне не рекомендуется делать 302 Redirect с одного домена на другой. То есть мы можем решать временные задачи только в пределах одного сайта.
Чем отличается 302 Редирект от 301?
Какая особенность 302 Редиректа? Сравнивая его с 301 можно сказать, что постоянное перенаправление полностью передает весь вес сайта, включая ТИЦ, PR и фильтры, а также дает роботам понять, что страница, с которой идет 301 Редирект больше не нуждается в индексации. То есть из поиска она выпадает и заменяется второй. 302 Редирект ничего подобного не передает странице, на которую делается перенаправление, разве что вторая страница быстрее индексируется. А это означает для робота, что обе страницы доступны и должны присутствовать в поиске.
Для каких нужд используют 302 Redirect? Чаще всего для перенаправления на обновленные данные, пока на «редирекнутой» странице не будет обновлена информация или для придания акцента и большего внимания новой странице. Например, вместо страницы категории для выбора можно переадресовать посетителя сначала на акцию, а по его желанию он может по заметной ссылке перейти снова на страницу категории. Команды для создания 302 Temporary redirect не привожу, так это будет уже совсем иная статья. Пользуемся с умом.
Сервисы для контроля Редиректов
Конечно же, как же без сервисов для отслеживания редиректов на сайтах. За всем нужен глаз да глаз. Поэтому посоветую парочку вариантов для контроля.
Расширения для браузера, которые контролируют редиректы:
- HttpFox для Mozilla;
- HTTP Headers для Google Chrome.
С помощью этих инструментов можно отслеживать перенаправление по адресам, скорость и порядок загрузки страниц. Таким способом можно выявить циклическую цепочку, если она образовалась. На этом закругляю свои длинную статейку, надеюсь, мои советы вам помогут разобраться во всех основных тонкостях перенаправления ссылок.
Содержание
Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.
Что такое код ответа HTTP
Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос.
Первая цифра в ответе обозначает класс состояния, другие две — причину, по которой мог появиться такой ответ.
Как проверить код состояния страницы
Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.
В браузере
Для примера возьмём Google Chrome.
-
Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы».
-
Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу:
В Яндекс.Вебмастере
Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:
Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса
В Google Search Console
Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:
Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».
А затем в открывшемся окне перейдите на вкладку «Подробнее»:
Теперь расскажем подробнее про все классы кодов состояния HTTP.
1* класс кодов (информационные сообщения)
Это системный класс кодов, который только информирует о процессе передачи запроса. Такие ответы не являются ошибкой, хотя и могут отображаться в браузере как Error Code.
100 Continue
Этот ответ сообщает, что полученные сведения о запросе устраивают сервер и клиент может продолжать отправлять данные. Такой ответ может требоваться клиенту, если на сервер отправляется большой объём данных.
101 Switching Protocols
Сервер одобрил переключение типа протокола, которое запросил пользователь, и в настоящий момент выполняет действие.
102 Processing
Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.
103 Checkpoint
Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.
POST отправляет данные на сервер, PUT создает новый ресурс или заменяет существующий данными, представленными в теле запроса.
Разница между ними в том, что PUT работает без изменений: повторное его применение даёт такой же результат, что и в первый раз, а вот повторный вызов одного и того же метода POST часто меняет данные.
Пример — оформленный несколько раз интернет‑заказ. Такое часто происходит как раз по причине неоднократного использования запроса PUT.
105 Name Not Resolved
Не удается преобразовать DNS‑адрес сервера — это означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.
2* класс кодов (успешно обработанные запросы)
Эти коды информируют об успешности принятия и обработки запроса. Также сервер может передать заголовки или тело сообщений.
200 ОК
Все хорошо — HTTP‑запрос успешно обработан (не ошибка).
201 Created
Создано — транзакция успешна, сформирован новый ресурс или документ.
202 Accepted
Принято — запрос принят, но ещё не обработан.
203 Non‑Authoritative Information
Информация не авторитетна — запрос успешно обработан, но передаваемая информация была взята не из первичного источника (данные могут быть устаревшими).
204 No Content
Нет содержимого — запрос успешно обработан, однако в ответе только заголовки без контента сообщения. Не нужно обновлять содержимое документа, но можно применить к нему полученные метаданные.
205 Reset Content
Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.
206 Partial Content
Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.
GET — метод для чтения данных с сайта. Он говорит серверу, что клиент хочет прочитать какой‑то документ.
Представим интернет‑магазин и страницы каталога. Фильтры, которые выбирает пользователь, передаются благодаря методу GET. GET‑запрос работает с получением данных, а POST‑запрос нужен для отправки данных.
При работе с подобными ответами следует уделить внимание кэшированию.
207 Multi‑Status
Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus.
226 IM Used
Успешно обработан IM‑заголовок (специальный заголовок, который отправляется клиентом и используется для передачи состояния HTTP).
3* класс кодов (перенаправление на другой адрес)
Эти коды информируют, что для достижения успешной операции нужно будет сделать другой запрос, возможно, по другому URL.
300 Multiple Choices
Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.
301 Moved Permanently
Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.
302 Found/Moved
Временно перемещено — страница временно перенесена на другой URL, который указан в поле Location.
303 See Other
Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.
304 Not Modified
Модификаций не было — с момента последнего визита клиента изменений не было.
305 Use Proxy
Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.
306 Unused
Зарезервировано. Код в настоящий момент не используется.
307 Temporary Redirect
Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.
Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.
308 Resume Incomplete
Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.
4* класс кодов (ошибки на стороне клиента)
Эти коды указывают на ошибки со стороны клиентов.
400 Bad Request
Неверный запрос — запрос клиента не может быть обработан, так как есть синтаксическая ошибка (возможно, опечатка).
401 Unauthorized
Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.
Для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization.
402 Payment Required
Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.
403 Forbidden
Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.
404 Not Found
Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).
405 Method Not Allowed
Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.
406 Not Acceptable
Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).
407 Proxy Authentication Required
Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.
408 Request Timeout
Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение и просто обновите страницу.
409 Conflict
Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).
410 Gone
Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и недоступен (серверу неизвестно месторасположение).
411 Length Required
Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length.
Нужно исправить заголовки на сервере, и в следующий раз робот сможет проиндексировать страницу.
412 Precondition Failed
Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.
413 Request Entity Too Large
Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.
414 Request‑URI Too Long
Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.
415 Unsupported Media Type
Формат не поддерживается — сервер не может принять запрос, так как данные подгружаются в некорректном формате, и сервер разрывает соединение.
416 Requested Range Not Satisfiable
Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.
Корректного диапазона в необходимом документе может просто не быть, или есть опечатка в синтаксисе.
417 Expectation Failed
Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».
418 I’m a teapot
Первоапрельская шутка разработчиков в 1998 году. В расшифровке звучит как «я не приготовлю вам кофе, потому что я чайник». Не используется в работе.
422 Unprocessable Entity
Объект не обработан — сервер принял запрос, но в нём есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.
423 Locked
Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.
424 Failed Dependency
Неуспешная зависимость — сервер не может обработать запрос, так как один из зависимых ресурсов заблокирован.
Выполнение запроса напрямую зависит от успешности выполнения другой операции, и если она не будет успешно завершена, то вся обработка запроса будет прервана.
425 Unordered Collection
Неверный порядок в коллекции — ошибка возникает, если клиент указал номер элемента в неупорядоченном списке или запросил несколько элементов в порядке, отличном от серверного.
426 Upgrade Required
Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection.
Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.
428 Precondition Required
Нужно предварительное условие — сервер просит внести в запрос информацию о предварительных условиях обработки данных, чтобы выдавать корректную информацию по итогу.
429 Too Many Requests
Слишком много запросов — отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS‑атаки, для защиты от которой запросы блокируются.
431 Request Header Fields Too Large
Превышена длина заголовков — сервер может и не отвечать этим кодом, вместо этого он может просто сбросить соединение.
Исправляется это с помощью сокращения заголовков и повторной отправки запроса.
434 Requested Host Unavailable
Адрес запрашиваемой страницы недоступен.
444 No Response
Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.
Nginx — программное обеспечение с открытым исходным кодом. Его используют для создания веб‑серверов, а также в качестве почтового или обратного прокси‑сервера. Nginx решает проблему падения производительности из‑за роста трафика.
449 Retry With
Повторите попытку — ошибка говорит о необходимости скорректировать запрос и повторить его снова. Причиной становятся неверно указанные параметры (возможно, недостаточно данных).
450 Blocked by Windows Parental Controls
Заблокировано родительским контролем — говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров системы родительского контроля.
451 Unavailable For Legal Reasons
Недоступно по юридическим причинам — доступ к ресурсу закрыт, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав.
456 Unrecoverable Error
Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.
499 Client Closed Request
Запрос закрыт клиентом — нестандартный код, используемый nginx в ситуациях, когда клиент закрыл соединение, пока nginx обрабатывал запрос.
5* класс кодов (ошибки на стороне сервера)
Эти коды указывают на ошибки со стороны серверов.
При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. И его можно использовать в работе.
500 Internal Server Error
Внутренняя ошибка сервера — сервер столкнулся с неким условием, из‑за которого не может выполнить запрос.
Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.
501 Not Implemented
Не выполнено — код отдается, когда сам сервер не может идентифицировать метод запроса.
Сами вы эту ошибку не исправите. Устранить её может только сервер.
502 Bad Gateway
Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.
Актуально исключительно для прокси и шлюзовых конфигураций.
503 Service Unavailable
Временно не доступен — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее).
В поле Retry‑After заголовка сервер укажет время, через которое можно повторить запрос.
504 Gateway Timeout
Тайм‑аут шлюза — сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.
Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере.
Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.
505 HTTP Version Not Supported
Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.
506 Variant Also Negotiates
Неуспешные переговоры — с такой ошибкой сталкиваются, если сервер изначально настроен неправильно. По причине ошибочной конфигурации выбранный вариант указывает сам на себя, из‑за чего процесс и прерывается.
507 Insufficient Storage
Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.
508 Loop Detected
Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.
509 Bandwidth Limit Exceeded
Превышена пропускная способность — используется при чрезмерном потреблении трафика. Владельцу площадки следует обратиться к своему хостинг‑провайдеру.
510 Not Extended
Не продлён — ошибка говорит, что на сервере отсутствует нужное для клиента расширение. Чтобы исправить проблему, надо убрать часть неподдерживаемого расширения из запроса или добавить поддержку на сервер.
511 Network Authentication Required
Требуется аутентификация — ошибка генерируется сервером‑посредником, к примеру, сервером интернет‑провайдера, если нужно ввести пароль для получения доступа к сети через платную точку доступа.
Сообщение с кодом 301 Redirect сервер возвращает в том случае,
если пользователь либо поисковый робот перенаправляется на URL,
отличающийся от того, на который совершается переход.
О чем свидетельствует код 301
Эта ошибка указывает на то, что старый адрес утратил свою актуальность, и что содержимое,
расположенное по этому адресу, перемещено на другой.
Для поисковых систем это сообщение приводит к автоматической переиндексации,
вследствие чего они начнут перенаправлять пользователей на новый адрес.
Код 301 не является ошибкой, это сервисное сообщение,
которое используется администратором ресурса для настройки переадресации.
Это важно для сохранения рейтинга страницы, адрес которой изменяется, в поисковых системах.
Индексация страницы по новому адресу при использовании редиректа будет происходить точно так же,
как и старой, и раскручивать новый адрес в поиске не понадобится.
Что делать пользователю, когда в браузере появляется код ошибки 301
Поскольку настройка редиректа всегда зависит только от администратора ресурса или хостинг-провайдера,
пользователю не следует ничего предпринимать в том случае,
если сервер перенаправил его на требуемую страницу.
В случае, если перенаправление привело на другую страницу либо возвратило ошибку с любым другим кодом,
например, 404 Page not found, следует сообщить об этом администратору ресурса или
провайдеру услуг хостинга.
Причины возникновения кода 301 redirect
Этот код не сигнализирует об ошибке, он является сервисным сообщением,
которое используют системные администраторы для самых разных задач:
- сохранение «пользовательских сигналов» контента, размещенного на странице;
- сохранение и передача накопленной ссылочной массы на другой адрес;
- перемещение страниц;
- удаление повторяющихся страниц, склейка;
- ребрендинг сайта;
- смена доменного имени;
- управление трафиком – перенаправление на нужный адрес.
Появление сообщения с кодом 301 Redirect сигнализирует о том,
что владелец ресурса настроил переадресацию.
Если все сделано правильно, пользователь будет перенаправлен на искомую страницу.