- Что такое 301 редирект, зачем он нужен и как его сделать.
- Что такое 301 редирект?
- Что означает редирект «301»?
- Когда вы должны использовать 301 редирект?
- А что на счет тега canonical?
- SEO-преимущества 301 редиректа
- Удержание посетителей на вашем сайте:
- Перенаправление ссылочного веса.
- Быстрое удаление старой страницы из индекса поисковиков.
- Проблемы с 301 редиректом
- Как установить 301 редирект
- 301й редирект с помощью файла .htaccess
- 301 Redirect: WordPress
- Парочка полезных советов.
- Заключение.
- Http коды ответа сервера, 301 и 302 редиректы и файл htaccess — простыми словами о том, что мешает раскрутке вашего сайта
- Http запросы — как поисковый робот общается с сервером
- Браузер (поисковый бот) и сервер общаются по протоколу Http
- Почему так важно проверять HTTP заголовки запросов к вашему сайту
- Правильные ответы сервера на Http запросы — залог успешного SEO
- Http коды ответа сервера и их влияние на SEO продвижение
- Как тупой сервер может запороть ваше умное SEO
- 301 и 302 редиректы (коды ответа сервера) их использование
- Какой редирект использовать при смене Урл адреса страницы?
- Сервера бывают разные и редиректы у них настраиваются по разному
- htaccess — файл облегчающий управление сервером Apache
- Настраиваем 301 редирект через файл .htaccess
- Комментарии и отзывы (13)
Что такое 301 редирект, зачем он нужен и как его сделать.
Один из самых распространенных вопросов, касающихся технического SEO продвижения сайта, это использования различных редиректов, из которых, 301 редирект, это самый распространенный.
Что такое 301 редирект?
Редирект 301 — это способ перенаправления посетителей веб-сайта на действующий URL-адрес, когда тот адресс, который изначально запрашивался, был удален. Перенаправление должно указывать на наиболее релевантную или похожую действующую страницу на ту, которая больше не нужна, что обеспечивает лучшие поведенческие факторы.
Например, у вас была старая статья, в силу некоторых причин, вы решили удалить эту статью. В таком случае, вы наверное захотите, чтобы те посетители, которые решили зайти на ту страницу, перешли на другую страницу. Ведь перенаправление посетителя на новую страницу, релевантную старой, это более лучший вариант, нежели показывать посетителю страницу 404.
Например, у вас статья была по старому адресу https://moysite.ru/staraya-statya.html и вы пере направляете посетителей на https://moysayt.ru/novaya-statya.html. Для этого вы можете использовать 301й редирект.
Но ещё один большой плюс 301 редиректа, это его влияние на SEO. Предположим, на старую статью вели несколько внешний ссылок. Если вы просто удалите старую статью, то эти ссылки станут битыми.
Это может и не очень большой минус, но в любом случае, это нежелательно. С помощью 301 редиректа вы указываете поисковикам новый адрес старой страницы. В этом случае, поисковики не будут считать такие ссылки битыми и будут их учитывать в ранжировании сайтов.
Что означает редирект «301»?
301 редирект может отображаться как «301» или «301 Moved Permanently» (перемещен навсегда). Это код ответа HTTP (протокола передачи гипертекста), который показывает ответ от сервера, на котором размещена страница, для браузеров, запросивших URL. Код ответа 301 не является плохим по своей сути, этот код просто указывает, что запрошенная страница была перенаправлена на другую, и браузер должен перейти на эту страницу.
На самом деле, получение ответа 301 может означать, что вы хорошо справляетесь с поддержанием аккуратности своего сайта — не позволяя посетителям попасть на нерелевантные, старые или неработающие страницы.
Код состояния «301» — это один из многих HTTP-ответов, которые сообщают нам и поисковым системам, что происходит с этим URL. Код статуса HTTP-ответа «301» означает, что этот URL-адрес был перемещен навсегда, то есть любые ссылки со старым URL-адресом должны быть перенаправлены на новый предоставленный URL-адрес.
Для проверки статуса страницы, можно воспользоваться утилитой curl. Тогда команда будет выглядеть так.
Здесь мы видим саму команду, видим статус ответа 301, и видим новый адрес страницы. В данном случае, это редирект со страницы с www, на страницу без www.
Или вы можете воспользоваться онлайн инструментом по этой ссылке. Вот как будет здесь показан ответ сервера.
Когда вы должны использовать 301 редирект?
301 редирект следует использовать, когда страница больше не актуальна, не полезна или была удалена. Он также очень полезен при изменении структуры сайта, когда многие старые URL адреса заменяются на новые. Очень важно сделать пере направление со всех старых страниц сайта, если эти страницы более не будут доступны.
Вот ещё несколько ситуаций, когда нужно использовать 301 редирект.
- Переход на новый домен (был сайт — moystariysite.ru, стал newsite.com). В этом случае, нужно сделать редирект со всех старых URL адресов.
- Перенаправление с www на без www, и с обычного протокола http, на безопасный протокол https (http://www.moysite.ru на https://moysite.ru)
- Удаление старых статей.
- Объединение нескольких старых статей. Если на вашем сайте есть несколько похожих статей, вы можете объединить их в одну большую. В этом случае, старые ненужные статьи, также нужно будет удалить и сделать с них редирект на новую большую статью.
А что на счет тега canonical?
Оба эти решения несколько похожи, но различие между ними есть. Если кратко, то canonical не перенаправляет посетителей на новую статью, он лишь указывает, какую из этих статей считать главной. Подробнее о теге canonical, читайте в этой статье.
SEO-преимущества 301 редиректа
301 редирект очень важен для SEO и может быть полезен несколькими способами:
Удержание посетителей на вашем сайте:
Если посетитель нажимает на ссылку и получает страницу 404, это отрицательно повлияет на его восприятие сайта и может привести к разочарованию и уходу. При использовании 301 редиректа посетитель сразу перенаправляется на другую, релевантную страницу. По сути, посетитель всё равно получает то, что он хотел узнать.
Перенаправление ссылочного веса.
Любая страница сайта обладает своим ссылочным весом. Особенно, если на эту страницу ведут внешние ссылки. Если просто удалить страницу, то внешняя ссылка станет битой, а это значит, что даже в лучшем случае, вес такой внешней ссылки размажется тонким слоем по всем другим страницам сайта.
При использовании 301 редиректа, вес старой страницы будет передаваться на указанную страницу, что в большинстве случаев, более эффективно для поискового продвижения.
Быстрое удаление старой страницы из индекса поисковиков.
Когда поисковый робот поисковиков делает переобход сайта, он смотрит, какие страницы доступны, а какие нет. И по идее, если робот не встретит определенную страницу, то поисковик должен сразу удалить эту страницу из своего индекса.
Но на практике, у сайта могут быть различные технические проблемы, и страница может быть просто временно недоступна. Поэтому, поисковики не торопятся удалять страницы, если они не обнаружены.
Использую 301 редирект, вы явным образом сообщаете поисковым роботам, что данная страница была удалена, поэтому, видя 301 редирект, поисковики удаляют такую страницу в ускоренном темпе.
Проблемы с 301 редиректом
Проблемы с редиректом 301 обычно возникают из-за их неправильного использования.
Наиболее частая подобная причина этого — когда владелец веб-сайта перенаправляет все старые страницы сайта на новую главную страницу сайта. Это просто быстрее сделать.
Но если вы меняете структуру сайта, и вы удаляете сразу большое количество URL адресов, то вы должны потратить время, чтобы каждую из старых URL адресов, заменить новым, подходящим адресом. Подумайте о пользователях. Пользователь переходит по ссылке со стороннего сайта в надежде увидеть страничку про кошечек, а попадает на главную страницу блог о диких животных. Навряд-ли это ему понравится.
Еще одна проблема, которая возникает со временем, — это цепочки перенаправления. После нескольких обновлений сайта легко попасть в эту ловушку, но очень важно знать, что такое цепочки и как их удалить из списка переадресации.
Пример цепочки редиректов:
На странице A много обратных ссылок, но вы хотите направить их на страницу B.
Прошло время, страница B вы удалили, и сделали перенаправление на страницу C. Теперь страница B указывает на страницу C.
Страница D — это мощная новая статья, поэтому вы делаете редирект с этой страницы на страницу D.
Теперь у вас есть цепочка переадресации, которая означает, что ссылочная масса пытается перетекать со страницы A на страницу D.
Но на самом деле, этого не нужно делать. Вы должны сделать редиректы с каждой из старой страниц в этой цепочке, на новую страницу. Вот как будет выглядеть такое перенаправление.
- Страница A — Страница D
- Страница B — Страница D
- Страница C — Страница D
Как установить 301 редирект
Теперь, когда мы обсудили, что такое 301й редирект, его важность и случаи, когда вы должны его использовать, давайте посмотрим к наиболее распространенным методам установки 301 редиректа.
301й редирект с помощью файла .htaccess
В подавляющем большинстве случаев веб-сервер настраивается с помощью так называемого файла .htaccess. Это простой текстовый файл, который находится в корневом каталоге вашего сайта. Для установки 301 редиректа вам необходимо поместить файл .htaccess в корневой каталог (если этот файл еще не существует). Вы можете создать или отредактировать файл .htaccess, используя любые инструменты редактирования простого текста, такие как Блокнот, Sublime или Nano.
Начнем мы с простого примера, а именно, с переименования страницы на вашем веб-сайте. Например, если вы хотите изменить URL-адрес страницы с:
Чтобы старая страница перенаправлялась на новую, вам нужно добавить следующий код в ваш файл .htaccess:
redirect 301 /old.html https://www.example.com/new
Вот объяснение того, что означает приведенный код:
- «redirect 301” сообщает поисковым системам (и браузерам), что ваша страница была перемещена навсегда.
- «/old.html» — указывает старое расположение страницы.
- «https://www.example.com/new.html» — это новое расположение страницы, на которую веб-сервер должен перенаправлять посетителей.
Важно отметить, что если вы перемещаете несколько страниц, то вам нужно будет сделать перенаправления для каждой из страниц, которые вы перемещаете. Создание уникальной строки для каждой страницы рекомендуется как самый безопасный подход, если вы хотите, чтобы ваши команды были подхвачены поисковыми системами.
301 Redirect: WordPress
Если у вас сайт на WordPress то вы можете использовать любой из доступных плагинов для создания редиректа. Например, такой плагин как Redirection, позволяет пользователю ввести старый URL, затем новый URL и привязку — и теперь у вас есть 301 редирект. Это упрощает процесс перенаправления и сокращает время. Кроме того, с помощью этого плагина, вы сразу сможете настроить группы перенаправлений.
Парочка полезных советов.
Хотя использование 301 редиректа крайне важно, но работа может занять много времени, поэтому, вот пара советов, которые вам помогут в этой работе.
Если вы можете сохранить свои URL-адреса на новом сайте, сделайте это.
Это не всегда возможно, но если есть страницы на старом сайте, которые переедут на новый сайт, то оставьте их URL прежними. Если URL-адреса беспорядочные или неточно описывают содержание страницы, то их изменять придется.
Использование старых URL-адресов не только сэкономит время на создание перенаправлений, но и снизит риск падения трафика, когда новые страницы заменят старые.
Заранее составьте список старых URL-адресов.
Не нужно всё делать в последнюю минуту. Если вы решили переезжать на новый домен, то вначале проведите всю подготовительную работу. В том числе, составьте полный список ваших старых URL адресов и сохраните их в отдельную страницу.
Если вы будете делать перенаправления с одних страниц на другие, то также заранее укажите в таблице новые URL адреса. Тогда вам проще будет составить список перенаправлений и вы ничего не пропустите.
Заключение.
Надеюсь, теперь вы лучше понимаете:
- Что такое 301 редирект
- Зачем вам его использовать
- Как сделать редирект.
Используя редирект 301, вы, по сути, даёте поисковым системам пометку «эта страница перемещена, найдите последнюю версию этой страницы здесь». Важность этой пометки невозможно переоценить.
А если у вас остались ещё вопросы, то задавайте их в разделе с комментариями.
Источник
Http коды ответа сервера, 301 и 302 редиректы и файл htaccess — простыми словами о том, что мешает раскрутке вашего сайта
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Чуть ранее мы успели с вами поговорить о зеркалах, дублях страниц и их удалении.
Давайте сегодня продолжим тему и посмотрим каким образом поисковые роботы взаимодействую с нашими сайтами, чтобы понять, на какие вещи нужно обязательно обращать внимание и, в случае обнаружения ошибок, обязательно исправлять.
Казалось бы, что язык Http запросов и ответов сервера (сервер — это ПО на хостинге) настолько далек от SEO, что тратить время на понимание его принципов будет чудовищным расточительством. Однако, это не так.
Многие вещи, не заметные при беглом взгляде через браузер, могут оказывать колоссальное влияние на продвижение вашего сайта (вплоть до его полного выпадания из индекса). Увидеть все эти недочеты можно, только поняв, где и что именно нужно смотреть.
Http запросы — как поисковый робот общается с сервером
Теперь для продолжения разговора на тему, нам нужно будет посмотреть в стороны работы браузеров. Я уже довольно подробно писал, что такое браузер, но если говорить кратко, то это программа для просмотра Html страниц, загруженных из интернета. Но нас сейчас интересует конкретный вопрос: как происходит взаимодействие браузера и сайта?
Браузер (поисковый бот) и сервер общаются по протоколу Http
После того, как вы ввели Урл в адресную строку браузера (или, что то же самое, перешли по ссылке, или открыли закладку), он обращается к упомянутому выше DNS серверу (ближайшему), чтобы тот сообщил браузеру IP адрес, соответствующий введенному доменному имени сайта.
Правда, браузер сначала к файлу Hosts обращается и в свой ДНС кеш заглядывает, но если там ничего по данному домену не находит, то начинает ломиться в ближайший ДНС сервер (обычно он находится у вашего интернет-провайдера).
В DNS серверах хранятся таблицы соответствия доменов и соответствующих им IP адресов серверов (компьютеров, всегда подключенных к интернету), где физически размещаются файлы сайтов. Получив искомый IP адрес, браузер делает HTTP запрос к серверу с этим адресом.
Для передачи данных в таком запросе могут использоваться два метода: Get или Post. В обычных случаях используется Get, и если утрировать, то для нашего примера такой запрос может выглядеть так (указывается относительный URL адрес страницы — относительно корня сервера):
Этот запрос уходит на IP адрес, полученный ранее от ДНС сервера. На сервере же установлено программное обеспечение (чаще всего Апач), которое, получив такой запрос, находит нужный файл по указанному относительному пути и отправляет его (в виде Html кода) обратно в браузер.
Браузер же, в свою очередь, этот Html код интерпретирует в веб-страницу с учетом CSS стилей, которые могли быть заданы как в самом Html коде, так и во внешнем файле стилей, который тоже будет подгружен.
А как происходит взаимодействие поискового робота с сайтом? По сути, точно так же. Робот отправляет запрос на ДНС сервер и получив IP отправляет Get запрос с указанием относительного пути до нужного ему файлика вебстраниц. Сервер запрос обрабатывает, находит файлик и отправляет ее в Html виде поисковому роботу.
Т.е. отличий фактически нет, ибо поисковый робот — это тот же самый браузер, у которого за ненадобностью отсутствует графический интерфейс (Html страницы он просто загружает, но не открывает). Кроме этого, бот не выполняет Джава-скрипты и не загружает картинки (их индексацией занимается специальных бот). Но это уже детали.
Следовательно, разобравшись в методах общения браузера с сервером, мы поймем, как поисковый робот общается с нашим сайтом и какие проблемы на этом уровне могут возникать, вызывая серьезные препоны успешному продвижению.
Почему так важно проверять HTTP заголовки запросов к вашему сайту
Посмотреть HTTP заголовок можно разными способами. Например, я использую расширение для браузера Хром под названием HTTP Headers, но подобных аналогов море.
Браузер формирует HTTP запрос типа Get, где указывается относительный путь до вебстраницы и версия данного протокола, по которой готов работать браузер (обычно это 1.1):
Вот такой вот заголовок формируется браузером (он в верхней половине скриншота) при переходе на страницу моего сайта из поисковой выдачи Яндекса:
Из него можно, например, узнать, откуда был совершен переход на запрашиваемую страницу (с помощью содержащийся в поле Referer информации). Также обратите внимание на поле User Agent. Каждый браузер и каждый поисковых имеет свой собственный User Agent, по которому его можно идентифицировать на сервере.
Юзер агенты браузеров довольно-таки длинные (там вначале идут перечисления всякой всячины, а непосредственно название обозревателя идет в самом конце), а вот у ботов они состоят из одного или нескольких слов.
Правильные ответы сервера на Http запросы — залог успешного SEO
В нижней части скриншота показан ответ сервера на HTTP запрос браузера. Именно на основании ответа сервера поисковый робот либо будет любить эту страницу, либо будет ее игнорить. На приведенном скриншоте начальная (самая важная) строка ответа сервера показана вверху под началом запроса браузера и выглядит так:
В этом ответе указывается протокол, который запросил поисковый робот (либо браузер), а дальше идет уже непосредственно код ответа сервера. Если вы помните, то про Http коды ответа я уже писал, но здесь все же повторюсь, чтобы не создавать вам неудобства. Именно этот код ответа сервера определяет дальнейшие действия робота-индексатора с этой страницей вашего сайта.
Кроме кода, в ответе сервера можно найти и еще ряд полезной информации. Например, название программного обеспечения (в поле Server), на котором этот сервер работает (чаще всего встречается Апач, nginx или майкрософт). Тип контента (Content-Type) тоже очень важен для поискового робота, ибо он индексирует не все.
Также очень важным является поле Last-Modified. Плагин HTTP Headers его не показывает, но вы можете ввести Урл страницы в этот сервис и узнать значение Last-Modified для интересующей вас страницы любого сайта (чаще всего нужна информация именно по своему ресурсу).
Ориентируясь на него, поисковый робот может понять, появилось ли на этой странице что-то новое, что имело бы смысл ее переиндексировать, или все осталось по-старому с момента его предыдущего захода.
Заголовок ответа сервера содержит еще ряд полей, после чего следует уже непосредственно Html код вебстраницы, которую и должен будет сохранить робот в случае получения правильного кода ответа (200) или в случае новой даты в поле Last-Modified для ранее проиндексированной страницы.
Http коды ответа сервера и их влияние на SEO продвижение
Основная задача вебмастера (и оптимизатора тоже) заключается в том, чтобы в этом заголовке сервера не было бы чего-то такого, что отвратит от нее поискового бота. Ему не важно, как выглядит страница и что на ней содержится самый важный в мире контент.
Если ответ сервера будет неправильным, то бот развернется и пойдет дальше по своим делам, оставив вашу страницу или весь ресурс не проиндексированным.
А какой ответ считать правильными и какие варианты вообще возможны? Давайте крупными мазками рассмотрим возможные варианты.
Коды ответа делятся по сотням, то есть, допустим, к четырехсотым ошибкам относятся 401, 402, 403. Вкратце это будет выглядеть так:
- Коды с двухсотыми ответами (чаще всего встречается 200 ОК) — все что запросил браузер (или поисковый бот) на сервере имеется и нет никаких преград, чтобы это было отдано (веб-страница в виде Html кода).
- Трехсотые коды ответа сервера — документ по запрошенному адресу временно (302 редирект) или постоянно (301 редирект) перемещен. Сервер сообщает роботу новый адрес веб-страницы, а тот в свою очередь по нему переходит.
- Четырехсотые ответы — ошибка в запросе, сделанном поисковым роботом или браузером (по мнению сервера, ибо своей вины он в этом не видит). Например, пытаются получить доступ к закрытой информации без авторизации (401) или к странице, доступ к которой для данного пользователя запрещен (403). Ну и, конечно же, знаменитая ошибка 404 (страница не найдена на сервере), про которую я в свое время даже отдельную стать написал.
- Пятисотые ответы — сервер признается (посыпая голову пеплом), что виноват в сложившейся нехорошей ситуации он сам (ошибки на стороне сервера). Он может быть перегружен в данный момент из-за высокого наплыва посетителей или в результате Ддос атаки (мне пришлось для защиты от Ddos подключить сайт к CloudFlare). Также он может зависнуть, либо не иметь возможности осуществить запросы к базе данных, ну и еще несколько наиболее частых причин могут вызвать его недоступность.
Наша задача, как вебмастеров и оптимизаторов, состоит в том, чтобы все продвигаемые страницы отдавали бы правильные коды ответа сервера (200 или, на худой конец, 301, если страница поменяла свой Урл по каким-либо причинам).
И что не менее важно, все страницы, на которые по каким-либо причинам были проставлены неправильные Урлы (они могут располагаться ведь не только на вашем сайте), отдавали бы код ошибки 404. Если несуществующие веб-страницы будут отдавать код 200, то это может нанести непоправимый урон сайту и продвигать его средствами СЕО будет затруднительно.
В статье про проверку сайта я упоминал набор общедоступных инструментов из арсенала Яндекс Вебмастера. Есть там и сервис «Проверка ответа сервера«. Вставьте в его форму любой Урл с вашего сайта и намеренно его испортите (добавьте в ту часть адреса, что содержится после доменного имени, какую-нибудь околесицу).
Если в ответ вы увидите код ответа 404, то значит ваш сервер правильно обрабатывает не найденные страницы, а если что-то другое, то нужно искать причину неисправности.
Правда, в случае WordPress может выдаваться код 301 редиректа, если вы галиматью введете в ту часть Урла, которая отвечает за рубрику (это такая особенность работы движка, позволяющая перемещать статьи между рубриками, не переживая о ручной простановке 301 редиректа — все делается автоматически самим движком).
Как тупой сервер может запороть ваше умное SEO
Есть еще целый ряд особенностей в общении между сервером и поисковым ботом, которые могут свести на нет все ваши будущие и текущие усилия по продвижению. Вещи эти кажутся пустяковыми и довольно-таки сложно-непонятными, чтобы большинство вебмастеров и оптимизаторов на них сосредотачивалась. Однако, оно того стоит:
- На последнем скриншоте показано поле Content-Type:
Оно говорит от том, что имеющийся на сервере документ представляет из себя Html файл в кодировке русского языка UTF-8. Правильное указание кодировки очень важно, ибо может вызвать как проблему с прочтение материалов сайта пользователями, так и сложности в ее восприятии поисковыми роботами.
Бот просто читает содержимое charset, и если оно по каким-либо причинам будет не соответствовать реально используемой в тексте кодировке, то загруженные кракозябры, естественно, ни в индекс, ни в выдачу не попадут. Что печально, ибо в дальнейшем поисковый робот, скорее всего, уже на эту страницу заходить не будет, ибо там ничего ценного нет.
Last-Modified — второй камень преткновения (из сонма http ответов веб-сервера поисковому боту), влияющий на продвижение сайта. В этом поле указывается дата изменения документа (последнего обновления информации на данной веб-странице). Робот обязательно смотри в это поле, ибо у него много работы и отвлекаться на просмотр документа, который не изменился с момента его последнего посещения, было бы глупо.
Поисковый робот делает серверу запрос на загрузку страницы — была ли та изменена за время, прошедшее с его последнего прихода (отправляется в поле if-modified-since с датой последней загрузки документа этим роботом). Сервер сие обращение обрабатывает, и если страница с тех пор была действительно изменена (считывается Last-Modified и сравнивается с датой полученной от робота), то он отдает ее содержимое боту (и код 200 в ответ, естественно). Поисковый индексатор ее переиндексирует и будут учтены все внесенные изменения, например, добавленный контент или ссылки.
В противном случае (когда Last-Modified не менялся) сервер отдает боту только лишь код 304. В этом случае робот со спокойной душой пойдет дальше. Проблема может заключаться в том, что страницу вы могли уже за это время десять раз изменить, но в индексе поисковика она не обновится, ибо не обновлялся Last-Modified для этого файла. CMS (движки сайтов) довольно часто этим грешат, нужно обязательно все это проверять и при необходимости настраивать. Как? Это уже другой вопрос.
Главное, чтобы вы поняли где и что смотреть, чтобы вовремя заметить ошибку (смотрите второй из предыдущих скриншотов). Исправлять ее нужно будет уже исходя из ситуации (типа вашей CMS, типа программного обеспечения сервера и т.п.).
Начать же можно с обращения к хостеру с просьбой помочь (бесплатно или за денежку) в решение проблемы. Для них это, как правило, не проблема. Но вы, во-первых, должны сами понять, что у вас эта проблема есть, а во-вторых, должны доходчиво объяснить ее суть администратору сервера.
301 и 302 редиректы (коды ответа сервера) их использование
Бывает, что по каким-либо причинам вы хотите поменять Урл адрес страницы. Например, как уже упоминал чуть выше, захотите перенести статью из одной рубрики в другую (при определенном алгоритме формирования ЧПУ это может повлечь за собой смену Урла). Причин изменения Урлов может быть масса (хотя бы переход с протокола http на защищенный протокол https).
В не зависимости от причины вам важно, чтобы при переходе по старому Урл адресу пользователь попадал бы на нужную ему веб-страницу, а не любовался вашей расчудесной страницей 404 ошибки.
Какой редирект использовать при смене Урл адреса страницы?
Как это сделать? В общем-то не сложно, но важно, чтобы сервер при этом выдавал правильный код ответа (301). Вариантов кода ответа для редиректа (перенаправления) при этом обычно используется два:
- 301 — документ был перемещен по новому адресу навсегда и в дальнейшем искать его нужно будет только там. В этом случае поисковик в выдаче заменит Урл адрес на новый и лишней переадресации потом происходить уже не будет. Кроме этого, по 301 редиректу передается ссылочный вес (в том числе и Пр), накопленный страницей (правда, не сразу и не факт, что полностью).
- 302 — документ был перемещен временно. В этом случае поисковик не будет заменять Урл в выдаче и переносить веса. Какое-то время назад пользоваться 302 редиректом не советовали, но точных причин этого я уже не помню (может быть вы мне напомните).
Если вы не делаете 301 редирект, а просто меняете Урл страницы, то теряете положение (позицию) в выдаче, ибо старый урл, живущий в индексе поисковика, будет отдавать 404 код ответа, а значит со временем будет удален из индекса.
Новый же Урл должен быть сначала проиндексирован, потом еще вам придется набирать заново ссылочную массу, ждать месяцы, и то не факт, что все вернется туда, где и было. Далеко не факт. Поэтому при смене Урла обязательно делайте 301 редирект со старого Урла на новый и будет вам счастье.
Особенно это важно, когда переходите на новый движок сайта (или переносите разделы), т.е. когда меняются Урлы всех страниц сразу, как, например, при cмене доменного имени или переездt сайта на защищенный протокол Https.
В таких случаях обязательно нужно делать постраничный 301 редирект, иначе потеряете весь трафик на очень продолжительный период времени. Причем даже после восстановления он может вернуться не полностью. А при 301 редиректе, скорее всего, все пройдет «чинно и благородно», т.е. практически незаметно в плане снижения трафика из поисковых систем.
Вся имеющаяся внешняя ссылочная масса постепенно перетечет на новые Урлы. 301 редирект устанавливается на постоянной основе несмотря на то, что в индексе поисковика со временем старых Урлов уже не останется.
Сервера бывают разные и редиректы у них настраиваются по разному
Сервер, по сути, тот же компьютер, только в особом (серверном) исполнении. У него есть материнская плата, жесткие диски, процессор и оперативная память. Разве что только нет персонального монитора. Программное обеспечение на него ставится тоже серверное.
Виндовс на веб-серверах используется не часто, ибо эта ОС стоит денег, в то время как большинство аналогов из мира Линукса бесплатны (Debian, CentOS, Ubuntu и другие) — вот они и получили наибольшую популярность.
Но одной операционной системы для работы сервера не достаточно. В ОС устанавливается специальное программное обеспечение, среди которых основной программой является веб-сервер.
Самой популярной из таких программ является Apache (более трех четвертей серверов с сайтами в интернете работают на ней), ибо она бесплатная, постоянно обновляемая, хорошо оттестированная и имеющая большое количество расширений.
Перед Apache иногда ставят еще и Nginx (как и в случае с этим блогом), который является прокси сервером. Это, кстати, отечественная разработка, постепенно завоевывающая весь мир.
Кроме программы веб-сервера устанавливаются еще и интерпретаторы различных языков серверного программирования. Многие CMS написаны на PHP (Joomla, WordPress) и без интерпретатора этого языка работать не будут, но также имеются и другие.
Ну и, конечно же, базы данных тоже требуются для многих движков. Наиболее распространена MySql, но имеются и другие разновидности, как MSSql, Оракл. Еще что-то может быть установлено для решения специфических задач.
С высокой вероятностью ваш сайт будет работать под управлением веб-сервера Apache, а именно он формирует коды ответа сервера, о которых мы говорили чуть выше.
Особенностью работы с подобными средами является то, что:
- У файлов в вебе нет расширений (об этом мы упоминали при разговоре про зеркала). Все, что пытаются изобразить, добавляя через точку к Урлам страниц (типа .html и т.п.), является просто следованием традициям, а точнее привычкам «чайников», коих в интернете около девяносто процентов (включая меня).
- Второй особенностью серверных программ является способ их управления, который кардинально отличается от того, к чему мы привыкли в Виндовс. Это не какие-то графические меню, а конфигурационные файлы, в которых прописаны определенные параметры и инструкции для исполнения.
htaccess — файл облегчающий управление сервером Apache
У веб-сервера Apache основной конфигурационный файл называется httpd.conf. Однако, если в нем прописана разрешающая директива, то для каждого каталога сайта на вашем сервере можно будет использовать дополнительный файл конфигурации .htaccess.
Возможности у него такие же, как и у httpd.conf, но все прописанные в нем директивы будут применяться только к той папке, в которой он находится.
Однако, если разместите файл .htaccess в корне, то его действие распространится на весь ваш сайт. Этот способ конфигурирования Apache удобен тем, что доступ к .htaccess, лежащему в корне сайта, можно получить по обычному ФТП соединению с помощью любого ФТП клиента. Редактировать же его можно в любом текстовом или Html редакторе (в том числе и в онлайн редакторе).
Если у вас в корневой директории .htaccess нет, то просто создайте у себя на компьютере пустой текстовый файл и сохраните его без расширения и с точкой перед названием htaccess. После этого подключитесь к сайту по ФТП и скопируйте данный пустой файлик в корневую папку. Потом по мере необходимости открывайте его и вносите нужные вам инструкции, которые с превеликим удовольствие выполнит веб-сервер Apache.
Однако, настоятельно рекомендую перед каждой правкой .htaccess сохранять его к себе на компьютер, ибо из-за ошибки во вносимой инструкции может стать недоступным весь сайт. Имея бекап, вы сможете восстановить все как было в считанные секунды. Ну и также советую правку вносить не в обычном блокноте Виндовс, а в редакторе на вроде Notepad++, где есть возможность откатиться назад.
Что же именно можно прописывать в .htaccess? Очень много всего, и для полного и самостоятельного понимания сути вам придется окунуться в мир администрирования серверов и программирования (см. статью про волшебный файл .htaccess). Очень часто в таких записях встречаются так называемые «регулярные выражения», которые позволяют точечно применять прописанные директивы.
Все это нужно знать, чтобы полностью самостоятельно управлять своим веб-сервером для реализации требуемых на сайте функций. Однако, никто вам не мешает пользоваться чужими наработками в огромных количествах наличествующих в сети.
Хорошим примером может служить склейка зеркал через 301 редирект, описанная в статье по приведенной ссылке или же в первой части данной публикации. Также с помощью записей в .htaccess мы:
Настраиваем 301 редирект через файл .htaccess
Напомню, что сегодня мы говорим про ответы сервера и 301 редирект, который является абсолютно необходимой вещью при смены Урла одной страницы или переносе всего сайта на новый домен, переезде на Https или при склейке зеркал. Этот самый редирект чаще всего реализуются именно с помощью файла .htaccess (если сайт работает на сервере Apache. Давайте посмотрим примеры его реализации.
Для перенаправления с одного Урла на другой будет достаточно добавления в .htaccess такой вот строчки:
В директиве Redirect обозначения старой страницы (с которой идет переадресация) используется относительный адрес (ибо редирект по-любому будет выполняться на этом сайте), а для нового Урла — абсолютный (ибо можно сделать редирект и на страницу другого сайта). Кстати, вместо директивы Redirect 301 можно использовать RedirectPermanent или Redirect permanent.
Если идет переадресация в пределах одного домена, то можно использовать в обоих случаях относительные адреса. Вот реальный пример из .htaccess, живущего в корневой папке моего блога (между двумя адресами ставится пробел):
Однако, если вам нужно сделать постраничный редирект (например, для смены расширения страниц сайта с .html на .php или еще что-то, что позволяет не прописывать отдельные строки 310 редиректа для каждой страницы), то гораздо удобнее использовать регулярные выражения. Такой способ называют пакетным редиректом.
Для этого используется уже директива RedirectMatch, в которой допускается использование регулярных выражений. Например, для смены окончаний страниц .html на .php можно использовать такой вот код:
Чпу (человекопонятные ссылки) на сайтах многих CMS тоже реализуются с помощью подобных редиректов. Ну и, конечно же, та самая склейка зеркал, возникающая из-за WWW, тоже происходит за счет 301 редиректа (с использованием возможностей модуля mod_rewrite веб-сервера Apache):
Редирект на WWW:
Кроме возможностей дополнительного файла конфигурирования Apache (.htaccess) для создания редиректов используют и другие методы, реализованные на возможностях различных языков программирования (PHP, Javascript и других). Даже средствами Html возможно сделать перенаправление (правда, не знаю, как это будет восприниматься поисковиками). Об этом я писал в статье про то, как можно скрыть партнерскую ссылку.
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru
Комментарии и отзывы (13)
Редирект на WWW:
Options +FollowSymLinks RewriteEngine On RewriteCond %
Так это не на WWW, на оборот с WWW (Проверьте самый низ статьи)
Мощно, большое спасибо пригодилось.
‘бот не выполняет Джава-скрипты’
Уже не совсем так.
Прочитав статью выяснил, что движки Joomla не отдают LastModified.
Не подскажете как это вылечить?
Тема не раскрыта. Долго, нудно, не интересно и НЕ полезно.
Тот случай, когда всё осталось «вокруг да около»
Зколебался читать, извините
А мне,как начинающему, понравилась статья и у меня конкретнъй вопрос. У меня бъл сайт простенький такой на.html Осваивала всю ету систему и сделала. Сейчас сделала на joomla и сразу же потеряла трафик. На старом уже дошла до сотни, а сейчас свалилась опять на 20-25. И оказъвается вся фишка в редиректе,как я понимаю? А сейчас конкретно: значит надо в файле.htaccess прописать RedirectMatch 301 как указано у вас с заменой //www.yourdomain.ru$1.php на име моего сайта? Буду благодарна за ответ.
Очень жаль, что Въ не ответили на вопрос.
Я еще бы порекомендовал http://seo-webtester.com/
Спасибо за познавательную статью! У меня к вам вопрос как специалисту, ответьте пожалуйста, при проверке моего сайта http://smotridtp.ru/, персональным менеджером seopult.ru, выявлено, что «адреса страниц, не повторяют структуру разделов» То есть у меня на данный момент ссылки выглядят так: http://smotridtp.ru/videoobzor-land-rover-discovery-4/, а необходимо что бы было так: http://smotridtp.ru/avto-novosti/videoobzor-land-rover-discovery-4/. Изменить структуру постоянных ссылок я могу, но вопрос в том как сделать редирект? Я уже как только не пробовал, попадаю на стр 404. И еще вопрос: а стоит ли вообще их менять? Как к этому отнесутся поисковики ведь страниц в поиске уже много? Да, еще у вас в конце ссылки стоит .html, а у многих сайтов просто /, в чем разница и так уж необходим .html Спасибо!
Дмитрий, добрый день.
У меня сайт на muse (без админки). Сейчас такая ситуация:
В вебмастере яндексе и гугле главное зеркало указано www.site.ru
На хостинге сайт находится на site.ru и настроена серверная (не уверен, что это правильный термин) переадресация на www.site.ru
При этом сайт открывается (без переадресации) по адресам site.ru, www.site.ru, site.ru/index.html, www.site.ru/index.html
(Насколько я понимаю, это ошибка, нужно было делать главным зеркалом site.ru, с www.site.ru настраивать переадресацию через директиву host, с /index.html настраивать 301 редирект)
Сейчас (в связи с открытием филиалов в других городах) мы хотим сделать на site.ru общую страницу компании, а текущий сайт перенести на домен moscow.site.ru (чтобы потом по тому же принципу создавать локальные географические поддомены).
Как это можно проделать наиболее безболезненно?
Не подскажите как именно настроить сервер и WordPress, чтобы сайт начал отдавать заголовки (желательно адекватные) Last-Modified и 304 Not Modified? Я все варианты в интернете пересмотрел, при этом, ни один не работает. 🙁
Дмитрий, вы вообще на комментарии отвечаете?
Спасибо за полезный текст. Но есть вопрос:
Скажите, а повлияет ли на ранжирование сайта тот факт, что для поисковиков и для пользователей используется два разных зеркала?
Например, в поиске рабочее зеркало site.org, а для пользователей – site.com. Соответственно настроен редирект (все страницы).
Нормально это будет или плохо? Только не спрашивайте зачем.
Источник