Платежи по карте виза. Платёжные системы банковских пластиковых карт. Стоимость оплаты за услуги с карты уралсиб

Платежи по карте виза. Платёжные системы банковских пластиковых карт. Стоимость оплаты за услуги с карты уралсиб

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

Что такое 301 редирект и зачем он нужен?

301 редирект призван помочь вебмастерам переадресовать пользователей с одного URL, который изначально был в адресной строке браузера, на совершенно иной. С точки зрения поисковой оптимизации, 301 Moved Permanently - это постоянный редирект, который помогает переместить до 99% ссылочного веса на новый URL, а старый «пометить» в качестве устаревшего. То есть благодаря этому удастся сохранить позиции в поисковых системах, а если просто изменить адрес URL, не делаля редирект, то для Яндекса и Гугла это будет новой страницей, которая будет ранжироваться без связки с предыдущей историей.

Есть несколько вариантов, когда нужно воспользоваться этим редиректом:

  • при совершении склейки доменов;
  • для переезда сайта на новый адрес, например, в случае снижения трафика вследствие попадания вашего ресурса под фильтры поисковиков. 301 редирект не позволит тем, кто добавил ваш сайт в закладки, потерять его из виду;
  • чтобы увеличить показатели тИЦ, PR, трафик из ПС на основном сайте. В этом случае понадобится приобрести домен, который обладает неплохими показателями и настроить редирект на тот ресурс, который нуждается в улучшении данных параметров;
  • при смене адреса конкретной страницы для сохранения высоких позиций в ПС (например, это может быть актуально при переезде сайта из одной CMS в другую);
  • и др.
Как сделать 301 редирект?

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

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

Redirect 301 / http://site.ru

А если нужно организовать перенаправление со страницы на страницу сайта, то понадобится вот такой код:

Redirect 301 /старая-страница.html http://новый-домен.ru/новая-страница.html

RedirectPermanent /старая-страница. html http://новый-домен.ru/новая-страница.html

Как склеить домен с www с вариантом без?

В данный момент применение www в названии сайтов считается устаревшим. Однако, такой вариант встречается нередко. Если это не покупка готового сайта , то при создании нового ресурса лучше указывать везде без www. При склеивании доменов объединяются все их самые важные параметры, такие как тИЦ, PR и посещалка. К тому же это поможет оптимизировать ресурс, и избежать ситуации, когда ПС отражение сайта с www принимают за «самозванца» с «ворованным» контентом.

Код для склеивания домена с использованием www на домен без www выглядит так:

RewriteEngine on RewriteCond %{HTTP_HOST} ^www.site.ru$ RewriteRule ^(.*)$ http://site.ru/$1

При этом значение RewriteEngine on/off является специализированной директивой, служащей для подключения либо прекращения доступа к коду самого файла. А доступ происходит посредством модуля mod_rewrite. RewriteCond - директива, используемая для формирования условий по правилам преобразования. А RewriteRule - предписание, отвечающее за производимые преобразования, в конкретной ситуации - редирект 301.

301 редирект при переезде на HTTPS

Современный тренд - перенос сайтов на защищенный протокол HTTPS. При этом настройка переадресации со страниц с HTTP на HTTPS является ключевым этапом. Делается это следующим образом в файле .htaccess.

RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://site.ru/$1

Примечания и ошибки

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

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

Также существует несколько ситуаций, когда использование 301 редиректа будет ошибочным. Так, лучше не применять многоходовый редирект, если его внедрение займет слишком продолжительное время. Или, например, при наличии контента, который дублируется, и по ряду причин нужно сохранить обе страницы для пользователей. Если страница и ее содержимое не релевантны, то от редиректа тоже стоит отказаться. Ошибкой будет настройка редиректа на некорректно работающую страницу (страница должна быть с 200 или 404 ответом сервера). И, наконец, неверным будет редирект файла robots.txt .

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

Опытные вебмастеры помимо самого популярного 301 редиректа используют и некоторые другие: от 300-го по 307-й. К примеру, 302 и 307 - это временный редирект, 305 - доступ исключительно посредством прокси и т. д. Также довольно востребованным типом редиректов можно назвать Meta Refresh. Он выполняется не на уровне сервера, а на уровне страницы. Однако, такой редирект эксперты рекомендуют применять как можно реже. Это обосновано тем, что к ним зачастую прибегают дорвейщики и спамеры. К тому же применение этого редиректа практически не дает возможности для передачи ссылочного веса.

Привет, друзья. Сегодня хотелось бы обсудить очень заезженную, но всегда актуальную тему - это 301 Редирект (Permanent Redirect 301) - в seo-тусовке и без формальностей именно это подразумевается под словом «редирект» . Технически это является ответом сервера на обращение к нему, этот ответ имеет код 301, обозначающий, что адрес обращения был изменен навсегда (moved permanently). В результате всех этих хитрых махинаций мы должны получить какой-то новый конечный адрес.

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

Так как пост вышел очень большим, то я решил сделать оглавление для вашего удобства :

  • Редирект:
  • Практика редиректа:
Когда НЕОБХОДИМО делать 301 редирект

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

Следующий частый случай использования 301 редиректа - смена адреса сайта или склейка зеркал. Если вы решили поменять адрес сайта в связи с ребрендингом компании или зарегистрировали новый более красивый и короткий домен для указания его на печатной промо-продукции — очень важно, чтобы при обращении к адресу на старом домене пользователь попадал на ту же самую страницу (а не на главную страницу), но на новом домене. Что касается промо-сайтов, то обычно они состоят из одной-двух страниц, ссылки с которых ведут на основной сайт, или же при переходе на промо-сайт сразу происходит редирект на специальную страницу основного сайта. Еще иногда при создании сайта регистрируется сразу несколько доменов, например, из-за неоднозначного написания имени компании на латинице. Чтобы интуитивно набирая адрес, пользователь попал куда надо, и регистрируются несколько доменов - очень важно, чтобы со всех «вспомогательных» доменов происходил 301 редирект на один основной адрес. Ни в коем случае нельзя допустить, чтобы по всем адресам был доступен один и тот же сайт.

И еще о зеркалах - может случиться так, что ваш сайт будет доступен по адресам http://www.site.ru, http://site.ru и https://site.ru (последнее редко, но бывает) - это все классические ошибки, которые нельзя допускать, и в их решении как раз участвует 301 редирект. Так же как и в случае с разными адресами сайтов, необходимо определиться с главным зеркалом (с www или без www) и настроить редиректы на основное зеркало. Конечно, поисковики не глупые и в таких ситуациях часто сами справляются, а так же им можно помочь, сделав правильные настройки в панелях вебмастера и в robots.txt (для Яндекса, директива Host). Но seo - дело тонкое, и я бы не стал полагаться на удачу, а воспользовался проверенным способом!

Иногда случается очень неприятная ситуация, когда копия сайта оказывается доступной не только при вводе в адресной строке названия домена, но и IP-адрес сервера. Такая ситуация вряд ли может произойти на виртуальном хостинге, а вот если у вас выделенный сервер, то запросто. Это может являться причиной некорректной настройки сервера - решить проблему поможет отключение возможности доступа при обращении к ip-адресу, но лучше всего здесь выручит 301-редирект на уровне веб-вервера (apache или nginx). Пару месяцев назад у меня случилась как раз такая ситуация - у меня был выделенный сервер, на котором висела часть сайтов, но под один из сайтов я решил взять еще один отдельный сервер. Я перенес сайт, все работало как часы, и вот однажды натыкаюсь в выдаче Гугла на клон моего сайта - шок, паника - оказалось, что это ip адрес моего нового сервера и, разумеется, на нем живет мой сайт, а при обращении сервер отдает ответ 200 OK, и Google проиндексировал его полностью. На предыдущем сервере такой проблемы не было, там изначально был настроен 301-редирект с ip на домен, указанный в качестве основного для этого ip. Теперь я научен горьким опытом и всегда проверяю такие вещи - будьте в курсе и вы, не повторяйте ошибок. Проблему решили путем добавления в конфиги веб-сервера nginx 301 редиректа на основной домен, пример кода покажу в практической части поста ниже.

Ситуация подобная предыдущей - когда копия сайта находится и доступна через служебный тестовый домен , например, вида site.hosting.ru. Такие случаи в моей практике тоже встречаются, и, в отличие от предыдущего случая, это свойственно как раз для виртуального хостинга. Для чего такое существует? Например, у вас еще не куплен домен или вы переносите сайт с одного хостинга на другой, а NS сервера для домена не сменили, или еще не обновились записи DNS у провайдера. В таких ситуациях и делают тестовые адреса, где вы можете все настроить и установить, прежде чем перенаправлять адрес сайта на новый хостинг. И вот некоторые хостеры грешат тем, что не закрывают доступ к таким техническим адресам и при этом даже не запрещают их индексацию. Если и у вас случилась эта неприятная ситуация, то стоит попробовать прописать 301-редирект с технического адреса на основной в файле.htaccess.

Ну и, конечно же, 301 редирект очень любят применять правильные сеошники для борьбы с различными дублями страниц. Почему только правильные сеошники? Да потому, что неправильные хуй забили на сайт клиента и, что вполне вероятно, даже не заходя на сайт, стали закупать ссылки - увы, это не редкость. Ко мне периодически обращаются заказчики, которые хотят проверить добросовестность своих подрядчиков/сотрудников, отвечающих за оптимизацию и продвижение сайта, насколько качественно идет работа - заказывают seo аудит сайта - и пока еще ни разу не было такого, чтобы я не нашел на сайтах ошибок или недоработок. Так что, имейте в виду - я всегда рад вам помочь. Вернемся же к дублям - я считаю, что вместо того чтобы закрывать дубли от индексации, необходимо делать редирект на основной адрес, а всякие rel=”canonical” это уже не так интересно. Разумеется, существует масса случаев, когда дубли вынужденные, и тогда без канонизации не обойтись, но если есть возможность сделать редирект, обязательно делайте его. Частые случаи дублей, которые необходимо проверять всегда: адреса со слешем на конце и без, адреса с параметрами и метками - как это решать, я расскажу ниже.

Когда МОЖНО делать 301 редирект

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

Redirect 301 можно использовать в качестве ответа сервера вместо ошибки 404 Not Found - другими словами, пользователь, перейдя по неправильной ссылке или на несуществующую страницу, увидит не сообщение, мол, «Извините, такой страницы больше нет», а будет перемещен на другую существующую страницу. Это очень спорный момент среди специалистов, а потому я свое мнение никому не навязываю. Но я предпочитаю использовать именно редирект вместо 404 ошибки, и тут существует несколько вариантов развития событий… Смотрите, есть 2 категории 404 ошибок: первая - классическая, когда страницу действительно удалили, вторая - когда появление ошибки связано с кривыми внешними ссылками. В первом случае, наверное, не стоит делать редирект, а оставить 404 ошибку как она есть. А вот во втором случае стоит озаботиться редиректом на правильный url-адрес, если его можно восстановить из битой ссылки, или редиректом на главную страницу (или категорию).

Когда НЕ СЛЕДУЕТ делать 301 редирект

Несколько слов о том, когда редирект может вам навредить, а потому его не стоит использовать в следующих ситуациях.

Самое главное, чтобы не наделать ошибок, не стоит связываться с редиректами, если вы на 100% не уверены в том, что вы делаете или в чем-то сомневаетесь. Примите это как дружеский совет 🙂

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

Если с вашим доменом случились проблемы, например, фильтры, бан и т.п., и вы решили сменить адрес сайта (домен), то не стоит делать 301 редирект со старого домена на новый — в результате вы «приклеите» к новому домену и все проблемы сторого. То есть в итоге ничего и не изменится. Да, было какое-то время решение выхода из под гугло-фильтра Пингвин при помощи полного 301-редиректа со старого домена на новый. Действительно все позиции восстанавливались до уровня как до санкций, и это казалось панацеей от злого Пингвина, но при очередном апдейте алгоритма эта особенность была учтена и новый домен так же попадал под фильтр, в итоге ничего не улучшалось после смены домена. Если уж вы решили сменить домен, то можно попробовать перенести весь контент на новый домен, а на старом его удалить и повесить заглушку с сообщением о переезде, а еще лучше начать все «с нуля».

Способов сделать редирект очень много - через htaccess, php, javascript, настройки сервера и т.д. - так вот не надо пытаться использовать сразу все методы одновременно , слишком велика вероятность «разногласий» между разными способами и можно, например, получить бесконечное циклическое перенаправление.

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

http://site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30/ ->
http://www.site.hosting.ru/404.php ->
http://www.site.ru/404.php

А еще в итоге страница http://www.site.ru/404.php, которая должна отдавать 404 ошибку, отдает ответ 200 OK. Это даже мне взорвало мозг, а представьте, что подумал бы поисковый робот, попав в такую карусель! Мало того, что в цепочке поучаствовали три разных домена, так еще и страница ошибки говорит, что она не ошибка и ее надо индексировать.

По возможности стремитесь к отсутствию редиректов внутри сайта - если внешние ссылки на сайт исправить уже нельзя и редирект неизбежен, то внутренние ссылки надо стараться исправлять. Может быть это и не скажется на качестве индексации и ранжировании, но и нельзя быть уверенным наверняка, а потому лучше избегать таких спорных ситуаций. В отслеживании внутренних редиректов и вообще ошибок внутри сайта вам поможет замечательная программа Page Weight Desktop (или ее более простой аналог PW Lite).

Составляя привила редиректов в.htaccess исключайте реальные адреса директорий и файлов на сервере и следите за выборкой. Ситуация для сайта, попавшего мне однажды на аудит - в борьбе с дублями страниц категорий со слешем на конце и без, вебмастер перестарался немного и наоборот только усугубил проблему. Мало того, что под правила перезаписи попали и реальные файлы js-скриптов и css-стилей из-за чего они перестали корректно работать, так еще и некоторые страницы получили ненужный слеш на конце и появились дубли. Друзья, тщательно следите, чтобы составленные правила распространялись только на ту группу адресов, с которой вы работаете, и ограничивайте все остальные.

Для поиска проблемных страниц и их адресов, от которых необходимо избавиться, используйте возможности панелей вебмастера от Яндекс и Google. Для Яндекса Вебмастер: Выбираем сайт -> Индексирование сайта -> Исключенные страницы. Для Google Webmaster: Выбираем сайт -> Оптимизация -> Оптимизация HTML; А так же: Выбираем сайт -> Конфигурация -> Параметры URL.

Особенности индексации и переиндексации редиректов в Яндекс и Google. Когда вы будете бороться с дублями и проблемными адресами, разумеется, вы будете ждать удаления ошибок из панелей вебмастера, тут есть некоторые особенности. С Google все просто - настроили редиректы, изменения проиндексируются в течение 2 недель, за это же время начнут исчезать ошибки и из панели вебмастера, обычно через месяц все ошибки пропадают. С Яндексом же есть тонкость, и заключается в следующем - после простановки редиректов можно ждать пропадания ошибок из панели вечно, я ждал однажды полгода, пока не написал в поддержку, где мне сообщили, что помимо редиректа необходимо дополнительно закрыть проблемные страницы в robots.txt и только тогда они пропадут из панели вебмастера.

Permanent Redirect 301 через.htaccess

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

У вас на сервере (в корне, там где главный index.php) уже наверняка есть файл.htaccess. Если этот файл не видно:

  • Проверьте настройки ftp-менеджера, он может скрывать системыне файлы, коим и является файл htaccess
  • Зайдите в файловый менеджер через панель управления хостера и проверьте права для файла. Я имею ввиду не CHMOD, а группу и пользователя, например, там может стоять пользователь root, а вы подключаетесь через ftp используя доступ пользователя владельца домена.
  • Банально файла может не быть 🙂 Тогда его следует создать, но под windows иногда возникает проблема, т.к. по сути файл.htaccess видится системой как файл без имени и только с расширением. Предлагаю простой способ - создаем обычный txt-файл, добавляем в него строку «RewriteEngine On» (без кавычек), загружаем txt-файл на сервер, на сервере переименовываем файл в.htaccess

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

Давайте рассмотрим несколько самых распространенных и полезных примеров:

Редирект для домена с www.site.ru на site.ru

RewriteCond %{HTTP_HOST} ^www\.(.*) RewriteRule ^(.*)$ http://%1/$1

RewriteCond % { HTTP_HOST } ^ www \ . (. * ) [ NC ]

RewriteRule ^ (. * ) $ http : //%1/$1

Редирект для домена с site.ru на www.site.ru

RewriteCond %{HTTP_HOST} !^www\.(.*) RewriteRule ^(.*)$ http://www.%1/$1

RewriteCond % { HTTP_HOST } ! ^ www \ . (. * ) [ NC ]

RewriteRule ^ (. * ) $ http : //www.%1/$1

Вышеописанные варианты редиректа отлично работают и не требуют никаких правок с вашей стороны — только вставить в.htaccess файл. Однако для 100% надежности я бы посоветовал вам другой вариант:

RewriteCond %{HTTP_HOST} !^www.site.ru$ RewriteRule ^(.*)$ http://www.site.ru/$1

RewriteCond % { HTTP_HOST } ! ^ www . site . ru $ [ NC ]

RewriteRule ^ (. * ) $ http : //www.site.ru/$1

RewriteCond %{HTTP_HOST} !^site.ru$ RewriteRule ^(.*)$ http://site.ru/$1

RewriteCond % { HTTP_HOST } ! ^ site . ru $ [ NC ]

RewriteRule ^ (. * ) $ http : //site.ru/$1

Первый для тех, у кого основной домен с www, второй - у кого без www. Соответственно в обоих примерах надо вместо «site» вписать название вашего домена.
Итак, чем же данные варианты лучше? Очень просто, они проверяют не только отсутствие/наличие www в имени домена, но проверяют и имя домена на полное его соответствие.
Живой пример: Наверняка вы сталкивались с тем, что неожиданно сайт может проиндексироваться по служебному адресу на хостинге (такой адрес выдается, чтобы к сайту можно было обратиться до привязки вашего реального домена), какому-нибудь зеркалу или вообще ip-адресу! Так вот универсальные правила будут лишь верифицировать отсутствие/наличие www при этом все равно, к какому домену обращается пользователь или поисковый робот.
Так вот воспользовавшись продвинутым вариантом, вы на 146% будете уверены, что ваш сайт будет доступен только и исключительно по указному лично вами доменному имени и с учетом www. Я пользуюсь только таким вариантом и вам рекомендую!

Внесу некоторую ясность в непонятную абракадабру:

  • RewriteCond обозначаем условие, при совпадении с которым будет выполнено правило RewriteRule. С помощью регулярных выражений задаются шаблоны строк.
  • Метасимволы используются для задания групп символов или «меток» в шаблоне:
    • ^ — метка начала строки,
    • $ — метка конца строки,
    • ! - отрицание,
    • \ — экранирующий слеш, позволяет считать следующий за ним метасимвол обычным символом,
    • . - точка, обозначает любой символ, но только один,
    • () - группировка.
  • Модификаторы ставятся после обычных символов, метасимволов или их групп и расширяют возможности использования шаблонов:
    • ? — символ повторяется 0 или 1 раз,
    • * — Повторяется от 0 до 65536 раз,
    • + — Повторяется от 1 до 65536 раз.
  • Флаги определяют дополнительные опции для данного правила и перечисляются в квадратных скобках через запятую:
    • NC — (nocase) отключает проверку регистра символов.
    • R — (redirect) останавливает процесс преобразования и возвращает результат браузеру клиента как редирект на данную страницу (302, MOVED TEMPORARY). С данным флагом можно указать другой код результата, например R=301 возвратит редирект с кодом 301 (MOVED PERMANENTLY). Как вы понимаете, это то самое, что нам и надо.
    • L — (last) останавливает процесс преобразования, и текущая ссылка считается окончательной.

Самый популярный случай — редирект с index.php (html) на главную страницу. На 90% сайтов встречается проблема дублирования главной страницы по адресам http://site.ru и http://site.ru/index.php (или index.html, index.htm или любой другой вариант, не принципиально, а то и все сразу). Где-то это явно, когда, например, ссылка из логотипа ведет на site.ru, а ссылка в меню ведет на site.ru/index.php, где-то не явно, когда дубль находится при вводе адреса с index.php вручную. Важно просто решить проблему. И я предлагаю универсальный вариант, вот он:

RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1

RewriteCond % { THE_REQUEST } ^ [ A - Z ] { 3 , 9 } \ / index \ . (php | html | htm ) \ HTTP /

RewriteRule ^ (. * ) index \ . (php | html | htm ) $ $ 1 [ R = 301 , L ]

Просто вставьте этот код без изменений после строки после строки «RewriteEngine On» и нет проблем!

Многие, кто начинает бороться с дублями на сайте, задаются вопросом, а откуда берутся такие вот ссылки , которые дублируют основную страницу http://site.ru/page-name.html&post=-1234567_8901 ? Откуда взялась приставка &post=-1234567_8901 - это «добро» берется из вконтакте, когда кто-то делится ссылкой на ваш сайт у себя на стене, в группе или паблике, то автоматически добавляется подобная строка, видимо, для отслеживания какой-то статистики.

Чтобы избавиться от этой ерунды раз и навсегда необходимо добавить в htaccess:

RewriteCond %{REQUEST_URI} ^(.*)\&post= RewriteRule ^(.*)\&post=(.*)$ $1

RewriteCond % { REQUEST_URI } ^ (. * ) \ & amp ; post =

RewriteRule ^ (. * ) \ & amp ; post = (. * ) $ $ 1 [ R = 301 , L ]

Чтобы вам был понятен принцип, я приведу еще один пример , его как раз предложили решить в комментариях. Иногда вы можете обнаружить у себя вот такие ссылки:
http://site.ru/&sa=U&ei=AsguT72dLdHLtAaZ0tyVDQ&ved=0CCwQFjAIOFo&usg=AFQjCNFwbE9i0bqrQUGJLoDh6xyVd1nhxg
Что печально — эти ссылки индексируются Гуглом и попадают в выдачу.

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

RewriteCond %{REQUEST_URI} ^(.*)\&sa= RewriteRule ^(.*)\&sa=(.*)$ $1

RewriteCond % { REQUEST_URI } ^ (. * ) \ & amp ; sa =

RewriteRule ^ (. * ) \ & amp ; sa = (. * ) $ $ 1 [ R = 301 , L ]

Как видите, никакой разницы между этим и предыдущим случаем нет, пусть у вас в url’е будет &post= или &sa= или что угодно — решение одинаковое, просто надо заменить очевидные части кода. Понятно же, правда?

Избавляемся от параметров или меток в адресе

Вопрос задавался и в комментариях и много раз на форуме, потому нельзя его обойти стороной. Что делать вот с такими дублями: http://site.ru/?abrakadabra или более реальный случай http://site.ru?utm_source=twitterfeed&utm_medium=twitter

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

RewriteCond %{QUERY_STRING} ^utm_source= RewriteRule (.*) $1?

RewriteCond % { QUERY_STRING } ^ utm_source = [ NC ]

RewriteRule (. * ) $ 1 ? [ R = 301 , L ]

Как вы понимаете, значение «utm_source=» можно заменить на вашу «abrakadabra» и так жу будет происходить 301-редирект на адрес без всякой абракадабры.

Пример избавления от параметров скрипта в url страницы

Пусть мы хотим в адресе http://site.ru/index.php?lang=ru избавиться от параметра lang=ru так, чтобы на выходе получить http://site.ru/index.php.

В.htaccess необходимо прописать такие строки:

RewriteCond %{QUERY_STRING} ^lang=ru$ RewriteRule ^(.*)\.php\?(.*)$ $1\.php

RewriteCond % { QUERY_STRING } ^ lang = ru $

RewriteRule ^ (. * ) \ . php \ ? (. * ) $ $ 1 \ . php [ R = 301 , NC , L ]

%{QUERY_STRING} — это строка с набором переменных для PHP, часть урла после знака вопроса (и до решётки якоря, если он есть).

Вызываем url — http://site.ru/index.php?lang=ru

RewriteCond %{QUERY_STRING} ^lang=ru $
Запрашиваемый url попадает под это правило, других правил нет, поэтому будет выполнен RewriteRule строкой ниже.
RewriteRule ^(.*) \.php\?(.*) $ $1 \.php

Исходный url: http://site.ru/index .php?lang=ru
Шаблон разборки url’а: ^(.*) \.php\?(.*) $
URL будет разобран по переменным: $1 = http://site.ru/index , $2 = lang=ru и собран обратно уже в виде http://site.ru/index .php ($1 \.php)
А далее будет 301 редирект на новый url.

Пример правил при смене структуры сайта

RewriteRule ^post/category/(.*)$ blog/category/$1 RewriteRule ^post/(.*)$ blog/post/$1

RewriteRule ^ post / category / (. * ) $ blog / category / $ 1 [ R = 301 , L ]

RewriteRule ^ post / (. * ) $ blog / post / $ 1 [ R = 301 , L ]

Вот такие строки мне пришлось добавить в htaccess файл, когда я сменил структуру своего блога.

Раньше у меня были адреса такие: http://alaev.info/post/4358 и http://alaev.info/post/category/seo, что как-то ломало логику в структуре - ведь блог это только часть сайта, но почему-то посты принадлежат сайту, а не блогу, а категории принадлежат постам, что тоже совсем нелогично. Я решил логику восстановить, и получилось: http://alaev.info/blog/post/4358 и http://alaev.info/blog/category/seo — теперь блог как отдельный раздел сайта, а посты принадлежат ему, и категории принадлежат блогу, а не постам.

Из этого же примера видно, что важно соблюдать последовательность правил. Если бы я поменял строки местами, то есть впереди бы шла строка RewriteRule ^post/(.*)$ blog/post/$1 то редирект с адреса http://alaev.info/post/category/seo шел на страницу http://alaev.info/blog/post/category/seo а не как надо на http://alaev.info/blog/category/seo.

И последний пример — разбор частой ошибки с адресом от корня сервера

Например, вы решили исправить такую проблему, когда страница категории доступна по двум адресам http://site.ru/razdel/podrazdel/index.php и http://site.ru/razdel/podrazdel/. Второй url является правильным и основным, а url с index.php на конце является полным дублем, от которого необходимо избавиться.

Для того чтобы сделать редирект с index.php на категорию вы прописываете правило:

RewriteRule ^(.*)index\.php$ $1

RewriteRule ^ (. * ) index \ . php $ $ 1 [ R = 301 , L ]

А в итоге при обращении к странице: http://site.ru/razdel/podrazdel/index.php
Редиректит на что-то подобное: http://site.ru/home/site.ru/public_html/razdel/podrazdel/

Т.е. почему-то выводит полный путь от корня сервера.

Для решения этой проблемы (и не только этой, кстати) необходимо, чтобы в начале.htaccess файла стояла не просто строка RewriteEngine On, но после нее шла еще одна, которая обрезает полный путь (от корня сервера) до корня сайта, вот так:

RewriteEngine On RewriteBase /

RewriteEngine On

RewriteBase /

Простой редирект страницы на новый адрес

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

Redirect 301 /page-name1.html http://site.ru/page-name2.html Redirect permanent /page-name1.html http://site.ru/page-name2.html RedirectPermanent /page-name1.html http://site.ru/page-name2.html

Redirect 301 / page - name1 . html http : //site.ru/page-name2.html

Redirect permanent / page - name1 . html http : //site.ru/page-name2.html

RedirectPermanent / page - name1 . html http : //site.ru/page-name2.html

Выбирайте один из трех, а лично я предпочитаю первый вариант — он короче, проще и понятнее. Кстати, здесь site.ru может быть не обязательно тем же самым доменом, но любым другим.

На этом закончим с.htaccess и перейдем к PHP.

Permanent Redirect 301 с помощью PHP

Обычно PHP редирект я использую, когда возникают трудности с.htaccess или оказывается так, что функция на php оказывается более логичной и понятной.

Сам синтаксис 301 редиректа на php выглядит следующим образом:

header("HTTP/1.1 301 Moved Permanently"); header("Location: http://site.ru"); die("Redirect");

header () ;

header ("Location: http://site.ru" ) ;

die ("Redirect" ) ;

Эти строки сообщают браузеру клиента, что с какой-то запрошенной страницы необходимо произвести перманентный редирект на адрес http://site.ru. При этом http://site.ru может являться не только адресом главной страницы текущего сайта, но может быть и любым другим сайтом. Если же что-то пошло не так и произошла ошибка, то в окне браузера мы увидим надпись «Redirect».

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

Функция, позволяющая убрать определенный кусок из url

If (strpos($_SERVER["REQUEST_URI"], "http://alaev.info") !== false) { $real_page_url = "http://alaev.info".str_replace ("/http://alaev.info", "", $_SERVER["REQUEST_URI"]); header("HTTP/1.1 301 Moved Permanently"); header("Location: $real_page_url"); die("Redirect"); }

if (strpos ($ _SERVER [ "REQUEST_URI" ] , "http://alaev.info" ) !== false ) {

$ real_page_url = "http://alaev.info" . str_replace ("/http://alaev.info" , "" , $ _SERVER [ "REQUEST_URI" ] ) ;

header ("HTTP/1.1 301 Moved Permanently" ) ;

header ("Location: $real_page_url" ) ;

die ("Redirect" ) ;

Однажды у меня возникла проблема, что в панели вебмастера вылезла куча 404 ошибок, адреса этих страниц были вида http://alaev.info/http://alaev.info/post/4358, т.е. откуда-то в адресе появился дублирующий адрес сайта. И тогда я написал функцию, которая проверяет, есть ли в URI (заметьте, не URL, а URI) вхождение «http://alaev.info», и если присутствует, то вырезаем из адреса этот кусок и записываем результат в переменную $real_page_url, а потом делаем 301-редирект на верный адрес из переменной.

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

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

Одним из таких статусов может быть перенаправление запроса — заголовок содержит статус с ошибкой 3хх. Здесь есть несколько вариантов, например, временное перенаправление (307), ресурс временно перемещен (302), ресурс перемещен окончательно (301) и другие.

Определение 301 редиректа

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

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

Редирект 301 чаще всего используется вебмастерами, как наиболее дружелюбный в плане поисковой оптимизации. Например, я рассказывал о — здесь тоже используется 301 ответ сервера. У WordPress есть встроенная функция перенаправления, определяемая основной адрес ресурса:

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

Настройка 301 редиректа

Если используется любая другая платформа, или было принято решение изменить основной домен (например, убрать из адреса префикс www), то можно использовать код для редиректа через файл.htaccess, который располагается в корневой директории:

1 2 3 RewriteEngine On RewriteCond % { HTTP_HOST} ^www. webliberty. ru [ NC] RewriteRule ^(.* ) $ https: //сайт/$1

RewriteEngine On RewriteCond %{HTTP_HOST} ^www.сайт RewriteRule ^(.*)$ https://сайт/$1

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

Кроме использования файла.htaccess для перенаправления можно использовать и другие методы, например, с использованием , PHP или HTML мета-тегов. Кому интересно, предлагаю почитать какое применение можно найти для редиректа с использованием мета-тегов, пример приведен мною в комментариях к .

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

Но здесь подойдут не все методы, а только те, которые обрабатывают запрос на стороне сервера (.htaccess, PHP), мета-теги на HTML в этом случае не помогут, т.к. выполняют перенаправление уже после обработки запроса и загрузки страницы.

Определение HTTP статуса заголовка страницы

Я иногда проверяю какой заголовок отдает сервер для страницы. Раньше я проверял ответ сервера с помощью онлайн-сервисов, например, когда разбирался с в теме, то проверял на cy-pr.com. А теперь для определения статусов можно воспользоваться удобным плагином для браузера Google Chrome, который так и называется — HTTP Headers, который можно бесплатно установить в интернет-магазине Chrome Webstore .

После установки этого расширения на панели инструментов появится значок с логотипом «H», на скрине ниже второй справа. Щелкая на него в окошке будет отражен заголовок текущей открытой страницы, который отдает сервер, содержащий HTTP статус:

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

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

На сегодня все, но впереди Вас ждет еще много всего интересного, поэтому подписывайтесь на обновления блога по RSS или получайте свежие записи прямо на почту! А в следующей статье открою небольшой секрет и приведу еще один пример использования 301 редиректа на WordPress. Не забудьте подписаться, чтобы не пропустить 😉

С 301-ым редиректом (переадресацией) вы обязательно столкнетесь при склейке зеркал сайта с префиксом WWW и без него, в случае переезда сайта на новый домен, с HTTP на HTTPS, переноса страницы в другой раздел сайта и изменения ее адреса. Во всех этих случаях важно сохранить позиции и трафик, перенаправляя его на новые страницы. Как это сделать? Предлагаем техническую инструкцию.

Код состояния HTTP 301 (Moved Permanently или 301 редирект) - это стандартный код ответа сервера , который сообщает, что запрашиваемый ресурс перемещен и получил новый URL.

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

Настроить 301-й редирект можно разными способами (с помощью HTML, PHP, плагинов для CMS, скриптов), но самый надежный и простой вариант - с помощью.htaccess (для Apache) или web.config (для IIS).

Настройка 301 редиректа в.htaccess

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

Если в корневой папке вашего сайта нет файла.htaccess, его нужно создать и загрузить с помощью FTP-клиента. Теперь можно приступать к настройке.

Когда вам требуется сделать редирект с текущего домена на другой (например, при переезде сайта), можно использовать директивы модуля mod_alias. Пропишите в.htaccess следующую директиву (вместо newsite.ru укажите ваш новый домен):

Redirect permanent / http://newsite.ru/

Redirect 301 / http://newsite.ru/

Приведем еще примеры настройки переадресации 301.

Редирект со страницы page1.html на страницу page2.html :

Redirect 301 /page1.html site.ru/page2.html

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

Redirect 301 / site.ru/cat

Редирект с каталога /cat на главную :

Redirect 301 /cat site.ru

Редирект часто используют для склеивания зеркал. В этом случае применяется модуль mod_rewrite. Например, если вы хотите, чтобы шел редирект , то пропишите такие строки (где yoursite.ru - ваш домен):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.yoursite.ru$
RewriteRule ^(.*)$ http://yoursite.ru/$1

И наоборот - редирект с домена без www на домен с www :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^ yoursite.ru
RewriteRule (.*) http://www.yoursite.ru/$1

Редирект всех страниц сайта при переезде с http на https :

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI}

Если не сработает, можно попробовать такой вариант:

RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Также 301 редирект используется в борьбе с дублями страниц. Приведем несколько примеров.
Для поисковых систем URL http://www.yoursite.ru/ и http://www.yoursite.ru являются разными. Поэтому надо решить, какой тип использовать: со слешем в конце или без него. Для того чтобы убрать слеш в конце URL , пропишите правило:

RewriteEngine On
RewriteCond %{HTTP_HOST} (.*)
RewriteCond %{REQUEST_URI} /$
RewriteRule ^(.*)(/)$ $1

Добавить слеш можно таким образом:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*[^/])$ $1/

Для того чтобы заменить все.htm файлы.html файлами , пропишите следующие строки:

RewriteEngine on
RewriteBase /
RewriteRule ^(.*)\.htm$ $1.html

Если вы прописываете несколько директив, то строка «RewriteEngine on » указывается один раз - с ее помощью включается модуль mod_rewrite .

Если вы создаете файл.htaccess с нуля, то все команды указываются внутри таких строк:



Например, так будет выглядеть файл.htaccess с двумя редиректами: с www на без www и со страниц без слеша на страницы со слешем в конце:

Настройка редиректа в web.config

Вариант редиректа с помощью.htaccess работает только для Apache. Для веб-сервера IIS настраивать переадресацию нужно в файле web.config . Например, редирект с одной страницы (yoursite.ru/page.html) на другую (yoursite.ru/page2.html) будет выглядеть так:








301 редирект с домена с www на домен без www настроить можно таким образом:















Альтернативные способы настройки переадресации

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

Синтаксис следующий:

В этом случае происходит принудительная передача кода HTTP-ответа 301, и пользователь перенаправляется на страницу http://newsite.ru/.

Если у вас небольшой сайт с парой страниц, то редирект можно сделать с помощью HTML:

Изменяя цифру 0 , вы задаете количество секунд до переадресации. В этом случае редирект реализуется не на стороне сервера, а на стороне клиента (не передается заголовок 301).

Также редирект можно сделать с помощью JavaScript:


window.location.replace("newsite.ru");

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

Вариантов редиректов бесчисленное множество. Упростить работу можно с помощью генераторов редиректов. Это онлайн-сервисы, которые выдают готовые коды, - вам нужно лишь указать, откуда и куда перенаправить пользователя. Вот некоторые из этих сервисов: www.webconfs.com , www.rapidtables.com , www.htaccessredirect.net .

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

Настройка редиректа - сложная техническая задача, для выполнения которой не обойтись без профильных знаний. Если вы не владеете навыками разработки и программирования, и у вас под рукой нет штатного программиста, можно воспользоваться поддержкой хостинг-провайдеров. Многие из них предлагают услугу web-форвардинга (или «переадресация домена», «URL-форвардинг» и т. п.). Она позволяет настроить переадресацию с одного URL на другой. При этом используется 301 редирект.

Другой вариант - настройка редиректов с помощью плагинов для популярных CMS. Так, для WordPress есть плагины Redirection, Safe Redirect Manager, Simple 301 Redirects, а в Joomla! и Wix есть встроенные инструменты редиректа.

Не уверены, что сможете правильно настроить редиректы своими руками? Лучше не рисковать - в системы PromoPult за вас все сделают профессиональные вебмастера.

Заключение

Лучший способ настроить 301 редирект - с помощью.htaccess. Но он подходит только для веб-серверов Apache. Для IIS придется настраивать web.config. Если же нужно не просто сделать редирект, а учесть определенные условия, то используйте PHP, но в этом случае без помощи программиста не обойтись.

Есть и другие способы (в частности, с помощью HTML и JavaScript), но это не 301 редирект, а просто перенаправление без передачи веса. Также можно использовать плагины для популярных CMS или подключить услугу web-форвардинга, если ее оказывает ваш хостинг-провайдер.

Также стоит понимать, что не всегда есть смысл использовать 301-й редирект. В некоторых случаях лучше подойдет, например, атрибут rel=“canonical”.

Какой бы вариант вы ни выбрали, главное, чтобы он правильно работал. Проверить корректность редиректов на вашем сайте (как и многие другие аспекты работоспособности сайта) можно посредством от PromoPult.