Редирект с http на https

Примеры Универсальный редирект с www на без www

Тут самое интересное, почему то везде приводятся примеры, жестко привязанные к домену сайта. Зачем?, если есть универсальное решение:

Проверяем доменное имя, если оно начинается с www, то сработает правило: «все, на http://%1/$1«. Здесь %1 это наш домен без www (взят из условия), а $1 это адрес (взят из самого правила).

Универсальный редирект с без www на www

Тут маленько сложнее. Первое условие нужно для того чтобы получить домен (%1), оно всегда истина. Второе условие проверяет, что домен начинается не с www. Ну и само правило, аналогичное предыдущему примеру

Реврайт без редиректа

Иногда требуется, чтобы был редирект без смены адреса, т.е. реврайт без редиректа. Для этого просто не указываем флаг редирект (R), и получаем желаемый результат, теперь по адресу news/happy получим news.html, а в адресной строке останется news/happy

Редирект от GET параметров

Например, нужно что бы со страницы /?action=page&id=15 был редирект на /page/15/:

Поясню, первым условиям проверяем что есть get параметр action=page, вторым условием проверяем что id равно числу. Эти условия нельзя объединять, т.к. параметры могут идти и наоборот, т.е.
index.php?action=page&id=15 и index.php?id=15&action=page должны быть равноценны. Но и наконец правило, там все обычно, кроме знака вопрос (?) на конце. Он нам нужен, чтобы отсечь исходные GET параметры, иначе получим /page/15/?action=page&id=15

Редирект на мобильную версию сайта

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

Первой строкой мы проверяем USER_AGENT, определяем что он относится к мобильникам. (эту строку я детально не проверял, взял на просторе интернета, возможно она не совсем корректная, или есть более универсальная строка. Но на моих мобильных устройствах этот пример работает)

Второй строкой проверяем что мы находимся на нужном домене (т.к. пример не универсальный)

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

Универсальная версия

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

Редирект с главной страницы

Речь идет про запрос типа site.ru (без site.ru/index.php)

Здесь оказалось не все так очевидно, я столкнулся с необъяснимым поведением.

Реврайт без редиректа (урл не меняется). Рабочий вариант:

Редирект. НЕ рабочий вариант:

Реврайт без редиректа (урл не меняется). НЕ рабочий вариант:

Редирект. Рабочий вариант:

Если мне кто — нибудь расскажет почему эти примеры работают крест накрест, а обратно не работают — буду очень рад.

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

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

Временная переадресация при неуверенности

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

Спасение от фильтров стоит ли?

Когда-то 301 редиректом спасались от фильтров поисковых систем, но нет 100% гарантии, что фильтр в будущем не переместится на новый домен. Создавая постоянное перенаправление на новый сайт, перемещается ТИЦ с PR. Мною замечено, что с алгоритмом «Пингвина» еще можно помудохаться, а вот от АГС такие манипуляции не спасут однозначно. Поэтому сейчас Permanent Redirect не так популярен для спасения от фильтров ПС, но зато помогает не потерять заслуженные позиции. Чего вполне достаточно для усердных вебмастеров.

Нюансы использования 301 редиректа

  1. Исправлять ссылки ведущие извне 301 редиректом вполне нормально, потому что отредактировать их у нас нет возможности. А вот кривые внутренние пути надо максимально исправлять вручную другими, более щадящими способами.
  2. Настраивая redirect, нужно быть предельно внимательным, чтобы не захватить какие-нибудь системные ссылки из корневых каталогов или пути к папкам и плагинам.
  3. Для поиска ссылок, нуждающихся в исправлении, необходимо использовать инструменты поисковых систем Google и Яндекс Вебмастер. Очевидные дубли страниц видны в Гугл Вебмастер во вкладке Вид в поиске > Оптимизация HTML, а в Яндексе — Индексирование — Статистика.
  4. Между нашими главными поисковыми гигантами есть одна огромная особенность: если Google после обновления базы самостоятельно уберет исправленные ошибки из панели вебмастера, то Яндекс этого может вообще не сделать. Это дело можно поправить прописыванием в robot.txt запрета на индексирование или подать ручной запрос в поддержку на удаление из базы плохих ссылок. В 2016 Вебмастер Яндекса перешел на новый уровень, расширив функционал системы. Правда, некоторые возможности еще не работают, но уже функционируют корректно бывшая аддурилка, а теперь запрос на внеочередной переобход страницы роботом, проверка мобильности страниц, удобная статистика по ключевым словам с разбивкой на ТОП 3, 10, 50.

Кэш браузера

Для начала проверим активен ли кэш браузера на сайте, переходим на сервис webpagetest, вводим в поле url главной страницы и находим start scan.

Проверка функций блога

Ждем процесса проверки и смотрим на результаты. Ищем строчку Leverage browser caching и определяем кэшируются ли документы. В моем случае да, исключение – метрика, аналитика и vk, на них повлиять нельзя.

Есть ли кеш браузера

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

Gzip сжатие

Gzip сжатие потеряло актуальность при появлении AMP и Турбо страниц, но пользоваться ими нужно. Проверяем тем же сервисом webpagetest, только ищем строчку «Use gzip compression for transferring compressable responses».

Наличие gzip сжатия

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

Такими встроенными возможностями обладают большинство провайдеров, например:

  • Beget
  • Timeweb
  • Masterhost

Для безопасности и защиты wp-config

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

Отображение wp-config

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

Пример сжатия на .htaccess

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

FilterDeclare   COMPRESS

FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/html

FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/css

FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/javascript

FilterChain     COMPRESS

FilterProtocol  COMPRESS  DEFLATE change=yes;byteranges=no

Эти сжатия работают на серверах Apache 2.1 и выше, которые используют
модуль mod_filter. Этот модуль
использует алгоритм сжатия DEFLATE,
который основан на указании content-type.
В этом случае мы определяем text/html,
text/css и text/javascript.

В примере выше, мы начинаем с декларации фильтра COMPRESS, используя директиву FilterDeclare. Далее мы перечисляем типы файлов, которые
будут проходить через фильтр. Директива FilterChain,
дает указание серверу строить звено фильтра, основанное на директивах FilterProvider. Директива FilterProtocol позволяет нам определить
опции, применяемые для звена фильтра, когда он будет запущен. В примере мы
используем change=yes (контент должен
быть изменен с помощью фильтра (в этом случае сжат)), и byteranges=no (фильтр должен быть применен для определенных файлов).

В более старых версиях Apache, модуль mod_deflate
также использовался для настройки DEFLATE сжатия. Мы имели меньше возможностей
в настройках, но они были проще:

SetOutputFilter DEFLATE

AddOutputFilterByType DEFLATE text/html text/css text/javascript

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

Как правило, ваш веб сервер использует один из этих модулей,
в зависимости от версии Apache.
В основном, если вы разрабатываете свой проект, вы знаете, какой код следует
использовать. Но если вы разрабатываете продукт, и не знаете, на каком сервере
он будет использован, вам следует использовать оба кода сразу. Для этого оба
кода необходимо взять в директиву , это определит, какой из этих модулей используется, и
сервер не возвратит 500 ошибок о попытке настройки модуля, которого не
существует.

Проверка редиректа

Так же, вы можете воспользоваться одним из онлайн-сервисов, которые позволяют просмотреть правильность выполнения редиректа. Например, Redirect Checker. Для выполнения проверки вам нужно:

  1. 1.Перейти на страницу онлайн-сервиса по этой ссылке
  2. 2.В поле для ввода указать адрес, с которого должно осуществляться перенаправление в формате http://имя-сайта.ру .
  3. 3.А затем нажать на кнопку «Analyse».

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

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

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

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

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

Я надеюсь, что данная статья поможет вам правильно настроить редирект для HTTPS –протокола и осуществить переход на SSL-сертификат с наименьшими потерями. Если данная статья вам понравилась, делайте репост в социальные сети и подписывайтесь на мою рассылку. Желаю вам успешного переезда и до встречи в следующих статьях.

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, ‘http://ваш_сайт.ru’) !== false)

{

$real_page_url = «http://ваш_сайт.ru».str_replace ( «/http://ваш_сайт.ru», «», $_SERVER ); 

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, — 1, 1 ) == ‘/’ )

{

$requested_url = rtrim($requested_url, ‘/’);

header(«HTTP/1.0 301 Moved Permanently»);

header(«Location: $requested_url»);

die(«Redirect»);

}

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

Что такое перенаправление порта

Перенаправление порта  — это сопоставление определённого порта на внешнем интерфейсе роутера с определённым портом нужного устройства в локальной сети.

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

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

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

301 Moved Permanently

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

302 Found (HTTP 1.1) / Moved Temporarily (HTTP 1.0)

302 редирект означает временное перенаправление. Такая переадресация практически не передает ссылочного веса, и в основном её не следует использовать. Сегодня сеть Интернет работает на основе нескольких протоколов. Один из них – HTTP протокол, с помощью которого определяется, как управлять URL-адресами. В двух вариантах данного стандарта код ответа сервера будет отличаться:

  • HTTP 1.0: 302 с ответом сервера “Moved Temporarily” (Временно перемещен) – веб-документ временно перенесен на другой URL-адрес.
  • HTTP 1.1: произошло изменение в ответе сервера на «Найдено» – веб-документ был найден.

307 Moved Temporarily (HTTP 1.1 Only)

307 редирект в протоколе HTTP 1.1 получил 302 перенаправление. Хотя основные поисковые роботы будут рассматривать его как альтернативу переадресации с кодом 302, но практически в любых ситуациях лучше применять 301 редирект. Исключить из правила можно только ситуации, когда контент перемещался на краткий период времени (к примеру, когда сайт закрывался на техническое обслуживание), а поисковики уже определили, что ваш сервер работает по протоколу HTTP 1.1. Трудно выяснить действительно ли поисковые роботы понимали, что ваш сервер имеет совместимость с этим стандартом. Поэтому для недолгосрочного перенесения контента проще пользоваться 302 редиректом.

Другие виды редиректов

В арсенале оптимизаторов есть и другие типы переадресаций: использование обновления мета-данных (Meta Refresh) или через JavaScript. Они запускаются на страницах, а не на сервере.

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

Синтаксис и символы

  • . — Точка означает любой символ.
  • — перечень символов, совпадающих с буквами a, b, или с.
  • — перечень символов, не входящих в диапазон. Условию соответствует любой символ, кроме a, b, с.
  • * — предыдущий символ может повторяться 0 и более раз.
  • * — найти символы из заданного набора идущие подряд.
  • * — обратная операция.
  • .* — замена любого набора символов. «.*» — найти все подстроки между кавычками.
  • ^ — обознает начало строки (при использовании в начале выражения).
  • $ — конец строки.
  • \w — буква, цифра или подчёркивание _.
  • \d — любая цифра.
  • \D — любой символ, кроме цифр.
  • — указание на любую цифру.
  • — указание на любую букву от a до z с нижним регистром.
  • — указание на любую букву от A до Z с верхним регистром.
  • — любая буква от a до Z, регистр не важен.
  • — тоже самое, только короче.

Флаги для доп. опций

  • NC — NoCase отключает проверку регистра символов при срабатывании правила.
  • R — Redirect останавливает изменение URL-адреса и возвращает результат. Самое популярное значение R=301, однако встречаются и другие для временных редиректов (302, MOVED TEMPORARY).
  • L — Last останавливает создание URL-адреса и строка считается окончательной.

Какие ответы серверов существуют?

Начнем с того, что все коды ответов (состояния) серверов делятся на 5 классов, каждый из которых несет определенный смысл:

  • 1XX. Эти информационные коды говорят о том, что запрос был понят, принят сервером и уже обрабатывается. Такие временные ответы обычно не отображаются на экране пользователей, но служат внутренними кодами для браузеров.
  • 2XX. Обозначают успешную обработку полученного запроса. Они используются браузерами для подтверждения того, что запрос был принят, обработан и отражают его текущий статус.
  • 3XX. Это коды перенаправления. Говорят о том, что серверу нужно выполнить дополнительные действия — например, перейти по редиректу на новый адрес.
  • 4XX. Говорят об ошибке на стороне пользователя. Чаще всего появляются, если время ожидания браузера истекло или запрос был введен неправильно.
  • 5XX. Говорят об ошибке сервера. Это значит, что вы запрашиваете специфический ресурс и он найден, но сервер не может дать вам к нему доступ. В конечном счете, запрос не может быть обработан.

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

Именно в этих трех цифрах в колонке Status зашифрованы данные о состоянии страницы: можно ли ее сканировать, находится ли она по этому адресу, загружается ли все ее содержимое и т. д. 

Какие же коды ответов сервера встречаются чаще всего? И что они значат для оптимизации сайта? Давайте внимательно рассмотрим самые полезные для SEO ответы и способы их обработки.

Для чего нужен 301 Redirect

301 редирект является тем видом перенаправления, который поисковые системы признают как правильное решение для перемещенных страниц сайта. Поэтому при настройке Permanent Redirect никаких изменений в ранжировании или наложений штрафных санкций не происходит. Это естественная переадресация. Какое-то время назад этот способ переадресации использовался вебмастерами для выхода из под фильтров, но не факт, что на сегодняшний день этот способ может помочь. Хотя от определенных фильтров иногда спасает (ссылка).

На сегодняшний день основными показаниями к использованию 301 Редиректа являются ситуации:

  • изменения адреса страницы сайта, даже на одну букву или символ;
  • склейка зеркал (домен с www и без www, домены в разных зонах);
  • смена домена интернет-ресурса;
  • борьба с дублями из-за технического бардака.

Где делают Permanent Redirect 301? Способы зависят от возможностей вебмастера и его доступа к данным. Поэтому создать 301 Редирект можно через htaccess, php, настройки сервера, javascript. Естественно, что использовать все способы одновременно не надо.

Адрес страницы изменен

Итог бездумной корректировки URL? Поисковая система видит отказ пользователя и понижает сайт в выдаче по поисковому запросу. Катастрофа. А все из-за какой-то корявой ссылки, которая изначально осталась незамеченной и никого, кроме самого «вебмастера» совершенно не смущала. Но эту ситуацию можно исправить как раз 301 редиректом. Как сделать 301 редирект с одной страницы на другую (со старого url на новый), расскажем дальше.

Склейка зеркал

Зеркала — это, например, когда сайт один, а доменов несколько. Обычно, компании, работающие на бренд, выкупают сразу все доступные зоны, чтобы никто не смог воспользоваться их именем. Также присоединяются названия адреса сайта через дефис и без него. Но даже без такой катавасии, на вашем сайте 100% есть зеркала! В данном случае это написание адреса сайта с www и без, а также доступ через https. В любом из этих случаев делается 301 redirect, причем еще при создании вебресурса, иначе от головной боли с дублями страниц потом тяжело избавится. Редирект 301 с www на без www и наоборот (если основным сайтом является www.имя_домена.ru), а также c http на https (сомневаюсь, что часто бывает перенаправление наоборот), включая разные доменные зоны, обязателен! Для проверки наличия основного зеркала, помогут панели вебмастера поисковых систем.

Исправляем технический бардак

Здесь вариантов устроить технический бардак уйма начиная с нарушений элементарных правил создания страниц и заканчивая дублями, которые создаются плагинами на сайте (переводчики, комментарии, поиск по сайту). Сюда же можно отнести мобильные версии выдачи страниц (с этим в последнее время хлопот немало), но их лечат прописыванием canonical. Дубли создаются не только по вине вебмастера, есть и вынужденные. Но случаи по неопытности первого, все же больше наносят вреда. Некоторые прячут такие погрешности закрытием от индексации, но лучше использовать 301 Permanent Redirect и тогда робот точно поймет, что хочет ему сказать человек.

301 редирект вместо 404 Not Found

Не торопитесь сразу убирать 404 (Страница не найдена) и везде проставлять 301 Редирект

Тут важно прочувствовать разницу. Код 404 Not Found обязателен на страницах, которые удалены или никогда не существовали, а вот с битыми ссылками можно бороться 301 Редиректом! Если страница, которую ищет пользователь, существует, зачем отсылать его по древу сайта для ее поиска? Найдена битая ссылка на какую-то страницу? Перенаправляем по правильному адресу кодом 301 и посетитель даже не догадается о том, что ссылка уже была нерабочая

Пример .htaccess кэширования

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

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

Если вы проверите свой сайт через Google PageSpeed, то получите сообщение об установках сроков
кэширования (far-future expiry headers). Это делается следующим образом:

ExpiresActive on

ExpiresByType image/gif                 ";access plus 1 month";

ExpiresByType image/png                 ";access plus 1 month";

ExpiresByType image/jpg                 ";access plus 1 month";

ExpiresByType image/jpeg                ";access plus 1 month";

ExpiresByType video/ogg                 ";access plus 1 month";

ExpiresByType audio/ogg                 ";access plus 1 month";

ExpiresByType video/mp4                 ";access plus 1 month";

ExpiresByType video/webm                ";access plus 1 month";

Вы можете применять ExpiresByType,
для определения различных типов контента, для которых вы хотите применить
кэширование. Указание ExpiresActive on,
просто убеждается в том, что генерация Expires headers доступна. Доступность
определяется наличием установленного модуля mod_expires
на сервер Apache.

Ссылка на основную публикацию