Переадресация с сайта на сайт: Страница не найдена | REG.RU

Что за зверь такой, этот редирект? Редирект используется для перенаправления человека или бота ПС на другой адрес, который отличается от запрашиваемого вначале.

Пример: https://en.uaateam.agency/ перенаправляется на https://uaateam.digital/

Самый распространенный пример использования 301 redirect в SEO—продвижении – это склейка урлов сайта. В этом случае помимо передачи 90% ссылочного веса, передается также и авторитетность сайта с которого идёт перенаправление.

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

Если вы переезжаете на новый домен тоже было бы хорошо сделать редирект на него со старого, ведь таким образом можно сохранить трафик (люди переходят на старый домен через закладки или вписывают УРЛ в поиске, и в этих случаях попадают на новый домен)

Ещё можно использовать редирект для того, чтобы перенаправить пользователя с битой ссылки (битая ссылка — ссылка при переходе на которую сервер отдает 404 код сервера) на какую—то другую; или когда у вас есть страницы с дублирующимся контентом на них.

Но в таких случаях также присутствует еще один вариант исправления ошибки — удаление страницы.

301 редирект

301 редирект — это постоянный редирект, с помощью которого можно передавать  более 90% ссылочного веса, также он говорит о том, что страница имеет новый адрес, а старый УРЛ стоит считать неактуальным.

302 и 307 редирект

302 редирект является временным и передает целых 0% ссылочного веса и не рекомендуются для использования, его приемником в протоколе HTTP 1.1 является 307 редирект. Эти типы перенаправлений следует использовать лишь для перемещения контента на время, например, для проведения технических работ.

Остальные виды редиректов

Также редирект можно выполнить с помощью JavaScript или Meta Refresh, неудобство их использования заключается в том, что они не передают ссылочный вес и выполняются на уровне страницы, а не на уровне сервера как 301 или 302 редиректы.

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

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

1. Переадресация не должна быть циклической, если страница будет ссылаться на саму себя это может привести к тому, что при индексации сайта поисковым ботом, есть вероятность его попадания в такую «петлю», что в конечном счёте повлечет за собой сливание краулингового бюджета и как итог — сайт не будет проиндексирован.
2. Не стоит делать редирект с адреса на который также идёт редирект, то бишь, если у вас есть страница 1, 2 и 3, то не нужно делать редирект с первой на вторую, а со второй на третью, ставьте сразу с первой на третью. Таким образом нагрузка на сервер не будет увеличиваться, а эффективность редиректа не будет уменьшаться.
3. Размещение правил редиректов стоит начинать с общих, и лишь после них вписывать частные, так как при каких-либо противоречиях первыми будут срабатывать общие правила и лишь после них частные.
4. Полезным редиректом будет считаться тот, который ведёт на страницу, копирующую во всех нюансах запрашиваемую.

Самым популярным и распространенным методом выполнения переадресации является создание файла под названием .htaccess в папке сайта или редактирование его, если он у вас имеется.

При использовании веб-сервера Apache файл называется httpd.conf.

Рекомендую вам делать Backup файла или всего сайта, перед тем как вносить какие-либо изменения.

Прежде чем перейти к примерам, хочу сказать, что для написания правил редиректов используются регулярные выражения. Помимо редиректов, они могут использоваться в сервисах аналитики (Google Analytics, Яндекс Метрика), поиске записей по ссылкам, при работе с Google Tag Manager. 

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

• Перенаправляем полностью весь сайт на новый адрес:

• Редирект с одной страницы на другую

• Редирект с www на без www:

• Переадресация с HTTP на HTTPS:

Не забывайте о том, что работая с файлом, команда происходит на уровне сервера с ОС Linux или Apache с активированным модулем Mod_rewrite.

Также можно уменьшить нагрузку на сервер, изменив конфигурационным файлом hpptd.conf. — редирект .htaccess.

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

Если вы знаете структуру web-проекта, разбираетесь в PHP и сайт сделан на CMS, то откройте файл index.php, и в корне движка пропишите:

(в первой строчке указывается старый url, а во второй — новый)

Также, перенаправление PHP можно сделать с помощью отправки заголовков:

ASP редирект

ASP.NET редирект

В корне сайта необходимо будет найти файл web.config и вставить в секцию синтаксис:

ColdFusion редирект

JSP (Java) редирект

Такой способ лучше всего подойдет для корректировки простых проектов. Вы просто прописываете код в одном файле и добавляете на все нужные страницы. А вот и сам код:

(перенаправление на другой сайт)

CGI-скрипт на PERL

Ruby on Rails

Редирект в nginx

HTML-редирект

Если вам необходимо изменить лишь одну страницу на простеньком статическом сайте — сделайте редирект HTML.  Просто добавьте мета-тег внутри.

В данном примере мы используем редирект на наш сайт с 10-секундной задержкой:

Если мы изменим значение с 10 на 1, то пользователь отправится на https://uaateam.agency/ с секундной задержкой.

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

Перенаправление с www / без www

Добавьте эти строки в файл .htaccess, если вам необходимо настроить главное зеркало:

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

Склейка index.php, index.html, index.htm, index.asp

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

Если мы переезжаем на защищенный протокол, то добавляем:

или

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

Склейка дублей со слешем в конце url

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

Код для обратного эффекта:

Удаляем несколько слешей или тире в адресной строке

Делаем перенаправление с лишними слешами на страницу с одним слешем:

Для склейки тире воедино пропишите от www.)

новый адрес

Если некоторых GET-параметров нет или они имеют произвольное значение, выбираем такой синтаксис:

Без сохранения GET-параметров

Для переадресации адреса site.ua/index.php на основное зеркало site.ua:

или

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

Пропишите данный код на уровне php-скрипта:

С внутренней страницы на главную

Перенаправление каталога

Если изменяется структура каталога, отображаемой в url:

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

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

Если из-за переезда на другую платформу у вас изменились расширения файлов, вы можете использовать такую формулу:

Перенаправляем все страницы с одного домена на главную страницу другого

Добавьте в файл .htaccess сайта, с которого делаете редирект, следующие строки:

(site.ua — площадка, на которую будет вести редирект)

Перенаправление на главную с внутренних страниц

Перенаправление на внутреннюю страницу с главной

С поддомена на основной домен

Со страниц одного домена на аналоги в другом

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

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

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

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

Поддержка | Hoster.KZ в Казахстане

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

Перенаправление при добавлении доменного имени:

1. Для добавления домена в разделе "Сайты и домены" нажмите кнопку "Добавить домен".

2. В поле "Имя домена" укажите название добавляемого домена.
3. На открывшейся странице в поле "Тип хостинга" укажите - "Перенаправление".
4. В поле "Конечный адрес" укажите ссылку для переадресации.
5. Выберите тип перенаправления и нажмите "ОК".

Доменное имя, на котором настроено перенаправление, будет отображаться в разделе "Сайты и домены".

Настройка перенаправления с использованием файла .htaccess

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

Для настройки перенаправления необходимо:

1. В панели управления хостингом откройте раздел "Файлы".

2. Войдите в корневой каталог домена, с которого должно срабатывать перенаправление. Корневой каталог вы можете посмотреть в разделе "Сайты и домены", ниже названия домена в графе "Папка сайта".

3. Нажмите кнопку "Создать" и выберите "Создать файл".(.*)$ http://bitrix.kz/$1 [L,R=301]
   Вместо bitrix.kz укажите название домена, на который должно совершаться перенаправление.
   Для сохранения настроек нажмите кнопку "Применить".

На этом настройка перенаправления домена завершена.

Возврат к списку

Array
(
    [0] => Array
        (
            [TEXT] => Общие вопросы
            [LINK] => /faq/general/
            [SELECTED] => 
            [PERMISSION] => R
            [ADDITIONAL_LINKS] => Array
                (
                )

            [ITEM_TYPE] => D
            [ITEM_INDEX] => 0
            [PARAMS] => Array
                (
                    [FROM_IBLOCK] => 1
                    [IS_PARENT] => 
                    [DEPTH_LEVEL] => 1
                    [DESCRIPTION] => 
                )

            [DEPTH_LEVEL] => 1
            [IS_PARENT] => 
        )

    [1] => Array
        (
            [TEXT] => Оплаты и документы
            [LINK] => /faq/payment/
            [SELECTED] => 
            [PERMISSION] => R
            [ADDITIONAL_LINKS] => Array
                (
                )

            [ITEM_TYPE] => D
            [ITEM_INDEX] => 1
            [PARAMS] => Array
                (
                    [FROM_IBLOCK] => 1
                    [IS_PARENT] => 
                    [DEPTH_LEVEL] => 1
                    [DESCRIPTION] => 
                )

            [DEPTH_LEVEL] => 1
            [IS_PARENT] => 
        )

    [2] => Array
        (
            [TEXT] => Технические вопросы
            [LINK] => /faq/technical/
            [SELECTED] => 
            [PERMISSION] => R
            [ADDITIONAL_LINKS] => Array
                (
                )

            [ITEM_TYPE] => D
            [ITEM_INDEX] => 2
            [PARAMS] => Array
                (
                    [FROM_IBLOCK] => 1
                    [IS_PARENT] => 
                    [DEPTH_LEVEL] => 1
                    [DESCRIPTION] => 
                )

            [DEPTH_LEVEL] => 1
            [IS_PARENT] => 
        )

    [3] => Array
        (
            [TEXT] => Услуги и тарифы
            [LINK] => /faq/services/
            [SELECTED] => 
            [PERMISSION] => R
            [ADDITIONAL_LINKS] => Array
                (
                )

            [ITEM_TYPE] => D
            [ITEM_INDEX] => 3
            [PARAMS] => Array
                (
                    [FROM_IBLOCK] => 1
                    [IS_PARENT] => 
                    [DEPTH_LEVEL] => 1
                    [DESCRIPTION] => 
                )

            [DEPTH_LEVEL] => 1
            [IS_PARENT] => 
        )

)

26 июля 2017

Мы очень долго тянули, долго сомневались, но взяли и решились и поменяли наши основные телефонные номера....

4 декабря 2015

С 1 декабря и в течение всех новогодних праздников действуют специальные скидки 12% и 24% на полугодовые...

3 редиректа .htaccess с которыми я часто сталкиваюсь

Пару дней назад лазил по закладкам в своём браузере и нашёл две ссылки на примеры того, как правильно сделать 301-й редирект со старого домена на новый с сохранением URL всех внутренних страниц сайта, а также как сделать редирект с www на без-www и наоборот. А так как закладок и так целая куча, я решил, что лучше объединить эти примеры в один пост у себя на сайте, кроме того, добавив ещё и пример с редиректом на https://.

Думаю, что в настоящее время практически на всех хостингах уже стоят все необходимые модули апач, но всё же я упомяну, что для работы всех примеров из этого поста вам нужен модуль mod_rewrite. Без него ничего не получится. Проверить это можно либо на деле, начав использовать эти примеры, либо при помощи функции phpinfo(), либо написав в супорт хостинга в конце концов.

Добавлять код нужно в тот файл .htaccess, который лежит в корне сайта, если там нет такого файла, то создайте его сами.

1. Редирект со старого домена на новый с сохранением URL каждой страницы

Да, неоднократно приходится осуществлять переезд сайтов с одного домена на другой. Если это был какой-то тестовый домен, даже не индексируемый поисковиками, то можно не париться вообще. Однако если вам важно сохранить трафик, то нельзя оставлять это дело на самотёк, нельзя на старый сайт ставить загрушку «Сайт переехал», также нельзя использовать редирект через директиву Redirect 301, так как она все страницы старого сайта будет перенаправлять лишь на главную нового.

Нам же важно, чтобы каждый URL старого домена редиректил на ту же самую страницу на новом домене.truemisha\.ru RewriteRule (.*) http://truemisha.ru/$1 [R=301,L]

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

Миша

Недавно я осознал, что моя миссия – способствовать распространению WordPress. Ведь WordPress – это лучший движок для разработки сайтов – как для тех, кто готов использовать заложенную структуру этой CMS, так и для тех, кто предпочитает headless решения.

Сам же я впервые познакомился с WordPress в 2009 году. Организатор WordCamp. Преподаватель в школах Epic Skills и LoftSchool.

Если вам нужна помощь с вашим сайтом или может даже разработка с нуля на WordPress / WooCommerce — пишите. Я и моя команда сделаем вам всё на лучшем уровне.

Перенаправление на новый URL-адрес на портале - Power Apps

• 11/04/2019
• Чтение занимает 2 мин

В этой статье

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

Создание перенаправления

1. Откройте Приложение управления порталом.

2. Перейдите в раздел Порталы > Веб-сайт > Перенаправления.

3. выберите Создать.

4. Введите данные перенаправления, как описано ниже.

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

Использование перенаправления

Если запрошен входящий URL-адрес, браузер перенаправляется на URL-адрес целевой веб-страницы для соответствующей записи перенаправления.

Например, для значения входящего URL-адреса cs-survey, для которого задана целевая веб-страница опроса поддержки клиентов, следующий запрос:

https://customerportal.contoso.com/cs-survey

приводит к тому, что браузер запрашивает следующий URL-адрес:

https://customerportal.contoso.com/surveys/customer-service-survey/

: один из способов сделать или остановить миграцию вашего сайта

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

Щелкните изображение доски выше, чтобы открыть версию с высоким разрешением в новой вкладке!

Транскрипция видео

Привет, ребята.Добро пожаловать в выпуск Whiteboard Friday на этой неделе. Меня зовут Камерон Дженкинс, я работаю в Moz. Сегодня мы поговорим о перенаправлениях и о том, как они являются одним из способов сделать или прервать миграцию вашего сайта. Миграция сайта может означать много разных вещей в зависимости от вашего контекста.

Миграции?

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

CMS перемещение / формат URL

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

Так было вроде / 2018 / май / а потом пост. Затем мы меняем CMS. У нас больше гибкости в том, как структурированы наши страницы, наши URL-адреса, поэтому мы собираемся переместить его в просто / post или что-то в этом роде. Таким образом, многие URL-адреса будут перемещаться, потому что мы меняем способ их структурирования.

Условные обозначения "Keywordy"

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

Примером этого может быть, возможно, клиент использовал URL-адреса типа / best-plumber-dallas, и мы хотим изменить его на что-то немного более чистое, более естественное, а не такое ключевое, просто на / сантехники или что-то в этом роде.Так что это может быть еще одним примером перемещения большого количества URL-адресов, если мы захватываем весь сайт и как бы хотим с ними покончить.

Капитальный ремонт содержимого

Другой пример: мы проводим полную переработку контента. Может быть, клиент приходит к нам и говорит: «Эй, мы пишем контент и ведем блог в течение очень долгого времени, и мы просто не видим тот трафик и рейтинги, которые нам нужны. Можете ли вы провести тщательный аудит? весь наш контент? " Обычно мы замечаем, что у вас могут быть даже тысячи страниц, но четыре из них ранжируются.

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

Разве мы не знаем этого? Да, но ...

Это то, что я имею в виду, когда речь идет о миграциях.Но прежде чем мы углубимся, я как бы хотел обратить внимание на тот факт, что разве мы уже не знаем этого? Я имею в виду, что говорю с оптимизаторами поисковых систем, и все мы знаем или должны знать важность перенаправления. Если нет перенаправления, нет пути, по которому можно было бы сообщить Google, куда вы переместили свою страницу.

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

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

Неясное право собственности

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

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

Сроки

Другое дело сроки. На это могут повлиять внутренние и внешние сроки. Вот один пример, с которым я довольно часто сталкивался: клиент говорит: «Эй, нам действительно нужно, чтобы этот проект был выполнен к следующему понедельнику, потому что мы запускаем еще одну инициативу. Мы делаем телевизионную рекламу, и наш домен будет указан в рекламном ролике.Так что мне бы очень хотелось, чтобы этот материал был завершен, когда эти рекламные ролики выйдут в эфир ».

Таким образом, такие внешние дедлайны могут повлиять на то, как быстро мы должны работать. Часто это просто остается на обочине, потому что это не очень заметная вещь. Если вы не знаете, насколько важны перенаправления, вы можете обрабатывать такие вещи, как контент и следить за тем, чтобы все кнопки работали, а шаблон выглядел красиво и тому подобное, с видимыми вещами. Когда люди предполагают, что это перенаправляет, о, это всего лишь бэкэнд.Мы позаботимся об этом позже. К сожалению, перенаправления обычно попадают в эту категорию, если человек, выполняющий их, действительно не осознает важность этого.

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

Специалисты, не занимающиеся поисковой оптимизацией, обрабатывают перенаправление

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

Правила перенаправления для миграций сайтов

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

1. Создайте однозначную переадресацию

Номер один, всегда создавайте индивидуальные перенаправления. Это очень важно.Иногда я видел, что это могло бы сэкономить мне массу времени, если бы я просто использовал подстановочный знак и перенаправлял все эти страницы на домашнюю страницу или на домашнюю страницу блога или что-то в этом роде. Но это говорит Google о том, что страница A переместилась на страницу B, тогда как это не так. Вы не перемещаете все эти страницы на главную. На самом деле они туда не переехали. Так что это неуместное перенаправление, и Google даже сказал, я думаю, что они рассматривают их, по сути, как мягкие 404. Они даже не считаются.Так что убедитесь, что вы этого не делаете. Убедитесь, что вы всегда связываете URL-адрес с его новым местоположением, индивидуально каждый раз для каждого перемещаемого URL-адреса.

2. Остерегайтесь цепочек переадресации

Два, берегитесь цепей. Я думаю, что Google говорит что-то странно конкретное, например, остерегайтесь цепочек переадресации, три, не больше пяти. Просто постарайтесь максимально ограничить это. Под цепочками я подразумеваю, что у вас есть URL-адрес A, затем вы перенаправляете его на B, а затем вы решаете переместить его в третье место.Вместо того, чтобы делать это и проходить через посредника, от A до B к C, сократите его, если можете. Идите прямо от источника к месту назначения, от А до С.

3. Остерегайтесь петель

Три, берегитесь петель. Точно так же может произойти то, что вы перенаправляете позицию A на URL B в другую версию C, а затем обратно в A. Что происходит, так это то, что он преследует свой хвост. Он никогда не разрешится, поэтому вы перенаправляете его в цикле. Так что остерегайтесь подобных вещей. Я считаю, что один из способов проверить эти вещи - это отличный инструмент. В Screaming Frog есть отчет о цепочках перенаправления.Таким образом, вы можете увидеть, сталкиваетесь ли вы с какой-либо из этих проблем после того, как внедрили свои перенаправления.

4. 404 стратегически

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

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

5. Сделайте приоритетными URL-адреса, полезные для SEO

Номер пять, отдавайте приоритет URL-адресам, "ценным для SEO", и я делаю это, потому что я предпочитаю, очевидно, перенаправлять все, что вы перемещаете, все, что движется законно.

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

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

6. Тест!

Номер шесть, просто чтобы закончить, тест. Я думаю, что очень важно просто отслеживать эти вещи, потому что вы могли подумать, что вы все это настроили правильно, но, возможно, были какие-то ошибки форматирования или вы по ошибке перенаправили что-то не в то место. Очень важно просто протестировать. Итак, что вы можете сделать, вы можете создать site: domain.com и просто начать нажимать на все появляющиеся результаты и смотреть, не перенаправляются ли они в неправильное место, может быть, они 404.

Просто проверяю все эти проиндексированные URL-адреса, чтобы убедиться, что они ведут к правильному новому месту назначения. Я думаю, что сканирование сайта Moz - еще одно огромное преимущество здесь для целей тестирования. Что он делает: если у вас настроен домен или URL-адрес для кампании в Moz Pro, он проверяет это каждую неделю, и вы можете принудительно запустить еще один запуск, если хотите.

Но он просканирует ваш сайт на предмет подобных ошибок, а именно 404. Поэтому, если есть какие-либо проблемы, такие как ошибки типа 500 или 400, Site Crawl поймает их и уведомит вас.Если вы не управляете доменом, над которым работаете в кампании в Moz Pro, также существует сканирование по запросу. Таким образом, вы можете запустить это в любом домене, над которым работаете, для тестирования подобных вещей.

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

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

Вернитесь на следующей неделе и сделайте еще один. Спасибо всем.

Транскрипция видео от Speechpad.com

Перемещение веб-сайта и изменение URL-адреса

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

• URL-адрес изменяется с HTTP на HTTPS
• Изменение доменного имени, например, example.com на example.net или объединение нескольких доменов или имен хостов
• URL-пути изменения: example.com/page.php?id=1 на example.com/widget , или example.com/page.html – example.com/page.htm

Обзор

1. Обзор базовый информация о перемещениях сайта . Знайте, чего ожидать и как это может повлиять ваши пользователи и рейтинги. При переходе с HTTP на HTTPS просмотрите лучшие практики для HTTPS.
2. Подготовьте новый участок и тщательно его протестируйте.
3. Подготовьте сопоставление URL-адресов текущих URL-адресов с их соответствующий новый формат.
4. Запустите перемещение сайта , настроив сервер на перенаправление со старых URL-адресов на новые.
5. Отслеживайте трафик как на старых, так и на новых URL-адресах.

Часто задаваемые вопросы по всем переносам сайтов с изменением URL-адресов

• Google рекомендует перемещать все вместе, или можно перемещать по разделам?
  Перемещение по секциям - нормально.
• Как проверить, сколько страниц было проиндексировано?
  Проверяйте данные для каждого свойства отдельно в Search Console. Использовать Статус индекса отчет для широкого обзора.Использовать Файлы Sitemap отчет, чтобы узнать, сколько URL-адресов, представленных в карте сайта, было проиндексировано.
• Сколько времени потребуется Google, чтобы распознать изменения URL?
  Нет фиксированных частот сканирования; это зависит от размера вашего сайта и скорости ползать это возможно. Перемещение происходит для каждого URL-адреса.
• Теряете ли вы кредит на ссылки при перенаправлении на новые URL-адреса?
  Нет, переадресация 301 или 302 не приводит к потере PageRank.

Переход с HTTP на HTTPS

• Ознакомьтесь с лучшими практиками для HTTPS.
• Обязательно добавьте свойство HTTPS в Search Console. Search Console обрабатывает HTTP и HTTPS отдельно; данные об этих свойствах не передаются в Search Console. Поэтому, если у вас есть страницы в обоих протоколах, вы должны иметь отдельное свойство Search Console для каждый.
• Вот дополнительные ответы на вопросы по переносу страниц с HTTP на HTTPS:

  Часто задаваемые вопросы по миграции с HTTP на HTTPS

  Повлияет ли эта миграция на HTTPS на рейтинг?

  Как и во всех других миграциях, вы можете столкнуться с некоторыми колебаниями ранжирования во время миграция.Однако вам также следует ознакомиться с информация о передовых методах работы с HTTPS-страницами чтобы избежать ошибок, связанных с HTTPS.

  Сайты HTTPS получают небольшое повышение рейтинга, но не ожидайте видимых изменений. Google использует HTTPS как положительный сигнал ранжирования. Этот сигнал - один из многих другие, и в настоящее время имеет меньший вес, чем высококачественный контент сайта; ты не следует ожидать значительного преимущества SEO при переходе на HTTPS в краткосрочной перспективе.В в более долгосрочной перспективе Google может усилить поддержку HTTPS.

  Можно ли переместить только некоторые страницы на HTTPS?

  Да, ничего страшного. Начните с детали, проверьте ее, а затем двигайтесь дальше в своем собственном темпе.

  Если вы переходите с HTTP на HTTPS по частям и хотите избежать раннего индексирование поэтапных URL-адресов, мы рекомендуем использовать rel = canonical , а не перенаправляет.Если вы используете редиректы, вы не сможете протестировать перенаправленные страницы.

  Какой сертификат рекомендует Google?

  Для поиска Google приемлем любой современный сертификат, поддерживаемый современными браузерами.

  Меняются ли ключевые слова для поиска после перехода на HTTPS?

  Это не изменится с HTTPS; вы по-прежнему можете видеть поисковые запросы в Search Console.

  Мы ссылаемся на наши карты сайта HTTP в robots.txt. Следует ли нам обновить robots.txt до включить наши новые карты сайта HTTPS?

  Мы рекомендуем отдельные файлы robots.txt для HTTP и HTTPS. Каждый файл robots.txt должен указывать на отдельный файл карты сайта. Мы также рекомендуем перечислить каждый конкретный URL на вашем сайте только в одной карте сайта.

  Какая карта сайта должна отображать раздел в пробной версии HTTPS?

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

  Какие URL-адреса должны быть указаны в наших картах сайта, если у нас есть перенаправления (с HTTP на HTTPS или обеспечить регресс)?

  Перечислите все URL-адреса HTTP в карте сайта HTTP и все URL-адреса HTTPS в карте сайта HTTPS, независимо от редиректов при посещении страницы пользователем.Наличие страниц, перечисленных в вашем карта сайта независимо от переадресации поможет поисковым системам обнаруживать новые URL Быстрее.

  Есть ли что-то еще, что нам нужно добавить в robots.txt для HTTPS? версия?

  Должны ли мы поддерживать HSTS?

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

  Мы используем одну карту сайта для Новостей Google для всего нашего сайта. Что нам делать, если мы переносите наш сайт по частям?

  Если вы хотите использовать карту сайта Новостей Google для нового раздела HTTPS, у вас будет чтобы связаться с командой новостей чтобы сообщить им об изменении протокола, а затем в свойстве HTTPS в Search Console вы можете отправить новая карта сайта для Новостей Google при переносе каждого раздела вашего сайта на HTTPS.

  Есть ли какие-то конкретные рекомендации по Центр издателей Google Новостей с миграцией HTTPS?

  Центр издателей Новостей Google прозрачно обрабатывает переходы HTTP в HTTPS. В как правило, вам не нужно ничего делать с точки зрения Новостей Google, если только вы не также используя карты сайта новостей.В таком случае, свяжитесь с командой новостей и сообщите им об изменении. Вы также можете сообщить команде об изменении разделов, например, если вы переходите на HTTPS, вы можете указать, что вы перемещение http://example.com/section на https://example.com/section .

Подготовить новую площадку

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

• Настройте новую систему управления контентом (CMS) и добавьте в нее контент.
• Передайте изображения и загрузите (например, документы PDF), которые вы в настоящее время размещаете.
  Возможно, они уже получают трафик из поиска Google или ссылок, и полезно сообщить пользователей и робота Google об их новом местонахождении.
• Для перехода на HTTPS получите и настройте необходимые сертификаты TLS на своем сервере.

Создайте robots.txt для своего нового сайта

Файл robots.txt для сайта определяет, какие области может сканировать робот Googlebot.Убедитесь, что директивы в файле robots.txt нового сайта правильно отражают части, которые вы хотите заблокировать от ползания.

Обратите внимание, что некоторые владельцы сайтов блокируют сканирование во время разработки. Если вы последуете этому стратегии, убедитесь, что вы подготовили, как должен выглядеть файл robots.txt после перемещения сайта начинается. Аналогичным образом, если вы используете директивы noindex во время разработки, подготовьте список URL-адресов, из которых вы удалите директивы noindex при запуске переезд сайта.

Предоставить ошибки для удаленного или объединенного содержимого

Если содержимое старого сайта не будет перенесено на новый, убедитесь, что потерянные URL-адреса правильно возвращают код ответа об ошибке HTTP 404 или 410. Вы можете вернуть код ответа об ошибке на старом URL-адресе в панели конфигурации для вашего нового сайта, или вы может создать перенаправление для нового URL-адреса и вернуть код ошибки HTTP.

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

Проверьте правильность настроек Search Console

Успешное перемещение сайта зависит от правильных и актуальных настроек Search Console.

Если вы еще этого не сделали, подтвердите что у вас есть как старый, так и новый сайты в Search Console.Обязательно проверьте все варианты как старого, так и нового сайта. Например, вам следует проверить www.example.com и example.com и включают как HTTPS, так и Варианты сайтов HTTP, если вы используете URL-адреса HTTPS. Сделайте это как для старых, так и для новых сайтов.

Просмотрите проверку Search Console

Убедитесь, что ваша проверка в Search Console продолжит работать после перемещения сайта. Если вы используете другой метод проверки, имейте в виду, что токены проверки могут отличаться при изменении URL.

Если вы используете HTML file, чтобы подтвердить право собственности на ваш сайт в Search Console, убедитесь, что вы не забудьте включить текущий проверочный файл в новую копию сайта.

Аналогичным образом, если вы подтверждаете право собственности с помощью включаемого файла, который ссылается на метатег или Google Аналитика для подтверждения права собственности, убедитесь, что новая копия CMS также включает их.

Проверьте все настроенные параметры в Search Console

Если вы изменили некоторые параметры конфигурации в Search Console для своего старого сайта, убедитесь, что настройки нового сайта обновлены, чтобы отразить эти изменения.Например:

• URL параметры: если вы настроили параметры URL для управления сканированием или индексированием ваши старые URL-адреса, убедитесь, что настройки также применяются к новому сайту, если это необходимо.
• Геотаргетинг: Ваш старый сайт может иметь явный геотаргетинг, например домен с геотаргетингом или домен верхнего уровня с кодом страны (например, .co.uk ). Примените те же настройки к новый сайт, если вы хотите продолжить таргетинг на тот же регион.Однако если ваш сайт move призван помочь вашему бизнесу расширяться во всем мире, и вы не хотите, чтобы ваш сайт был связанных с любой страной или регионом, выберите Не в списке в раскрывающемся списке список страницы настроек сайта.
• Скорость сканирования: Мы рекомендуем не ограничивать скорость сканирования робота Googlebot в Search Console как для старых, так и для новые URL-адреса. Мы также советуем не настраивать скорость сканирования. Только сделай это если вы знаете, что ваш сайт не может обрабатывать объем сканирования роботом Googlebot.Если у вас есть скорость сканирования вашего старого сайта уже ограничена роботом Googlebot, рассмотрите возможность его удаления. Google имеет алгоритмы, которые автоматически обнаруживают, что перемещение сайта было выполнено, и мы изменяем Сканирующее поведение робота Googlebot, поэтому наша индексация быстро отражает перемещение сайта.
• Отклонено обратные ссылки: если вы загрузили файл, чтобы отклонить ссылки на своем старом сайте, мы рекомендуем что вы повторно загрузите его снова, используя учетную запись Search Console на новом сайте.

Очистите недавно купленное домен

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

• Руководство действие для предыдущего спама. Для сайтов, не соответствующих нашим Веб-мастер Руководящие принципы, Google готов принять меры вручную, например понизить их или даже полностью удалить их из результатов поиска.Проверьте страницу "Меры, принятые вручную" в поиске Консоль, чтобы узнать, были ли применены какие-либо ручные действия к новому сайту, и устранить любые проблемы, перечисленные там до подачи пересмотр запрос.
• Удалено URL-адреса. Убедитесь, что предыдущий владелец не удалил URL-адресов, особенно удаление URL по всему сайту. Кроме того, перед отправкой запросов на удаление URL для вашего содержание, убедитесь, что вы понимаете когда не использовать инструмент удаления URL-адресов.

Использовать веб-аналитику

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

Убедитесь, что на вашем сервере достаточно вычислительных ресурсов

После переноса Google будет сканировать ваш новый сайт более интенсивно, чем обычно. Это потому что ваш сайт перенаправляет трафик со старого сайта на новый, и любые обходы старого сайта будут будут перенаправлены на новый сайт в дополнение к любому другому сканированию.Убедитесь, что ваш новый сайт обладает достаточной емкостью для обработки увеличившегося трафика от Google.

Обновить выделение данных

Если вы использовали данные Маркер для сопоставления ваших старых страниц, обязательно переделайте сопоставление для вашего нового сайта.

Обновить ссылки приложения

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

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

Подготовить сопоставление URL-адресов

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

1.Определите ваши текущие URL-адреса

При простейшем перемещении сайта вам может не понадобиться создавать список ваших текущих URL-адресов. За Например, вы можете использовать перенаправление на стороне сервера с подстановочными знаками, если вы меняете домен своего сайта. (например, переход с example.com на example.net ).

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

• Начните с важных URL-адресов .Чтобы их найти:
  • Посмотрите на свои карты сайта потому что, вероятно, именно так были отправлены ваши самые важные URL в Search Console
  • Проверьте журналы сервера или программное обеспечение аналитики на предмет URL-адресов, которые получают наибольший трафик
  • Проверить ссылки к вашему сайту в Search Console для страниц с внутренними и внешними ссылками
• Используйте свою систему управления контентом, , которая обычно предоставляет простой способ получить список всех URL-адресов, на которых размещается контент.
• Проверьте журналы сервера на предмет URL-адресов, которые были посещены хотя бы один раз в последнее время. Выберите период времени, который имеет смысл для вашего сайта, учитывая сезонные колебания трафика.
• Включите изображения и видео —Убедитесь, что вы включили URL-адреса встроенного содержимого в планы перемещения вашего сайта: видео, изображения, файлы JavaScript и CSS. Эти URL-адреса необходимо переместить так же, как и весь другой контент на вашем сайте.

2. Создайте сопоставление старых и новых URL-адресов

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

3. Обновите все сведения об URL

После определения сопоставления URL-адресов вам нужно сделать три вещи, чтобы получить страницы готов к переезду.

1. Обновите аннотации в записи HTML или карты сайта для каждой страницы:
   1. Каждый целевой URL должен иметь ссылку на себя. rel = "canonical" тег .
   2. Если на перемещаемом сайте есть многоязычные или многонациональные страницы, аннотированные с использованием rel-alternate-hreflang аннотации, обязательно обновите аннотации, чтобы использовать новые URL-адреса.
   3. Если у перемещенного сайта есть мобильный аналог, обязательно обновите rel-alternate-media annotations.Дополнительные сведения см. В наших правилах использования веб-сайтов для смартфонов.
2. Обновить внутренние ссылки.
   Измените внутренние ссылки на новом сайте со старых URL-адресов на новые URL-адреса. Вы можете использовать сопоставление, созданное ранее, чтобы помочь найти и обновить ссылки по мере необходимости.
   
3. Создайте и сохраните карту сайта и списки ссылок.
   Сохраните следующие списки для последнего шага:
   • Файл карты сайта, содержащий новые URL-адреса в сопоставлении
   • Файл карты сайта, содержащий старые URL-адреса в сопоставлении
   • Список сайтов, ссылающихся на ваш текущий контент

   Подробнее о файлах Sitemap.

4. Подготовьтесь к переадресации 301

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

Имейте в виду следующее:

• Использовать перенаправления HTTP 301. Хотя робот Googlebot поддерживает несколько видов переадресации, мы по возможности рекомендуется использовать переадресацию HTTP 301.
• Избегайте цепочки перенаправлений. Хотя робот Google и браузеры могут следовать "цепочке" множественные перенаправления (например, Страница 1> Страница 2> Страница 3), мы советуем перенаправить на пункт назначения. Если это невозможно, сохраните количество перенаправлений в цепочке. низкий, в идеале не более 3 и менее 5. Объединение перенаправлений увеличивает задержку для пользователей, и не все браузеры поддерживают длинные цепочки перенаправления.
• Протестируйте перенаправления. Вы можете использовать Инструмент проверки URL для тестирования отдельных URL-адресов или инструментов командной строки или сценариев для тестирования большого количества или URL-адреса.

Начать перемещение сайта

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

1. Решите, как вы будете перемещать свой сайт - сразу или по разделам:
   • Малые или средние сайты: Мы рекомендуем переместить все URL-адреса на вашем сайте. одновременно, а не перемещать по одному разделу за раз.Это помогает пользователям взаимодействовать с сайт лучше в его новой форме, и помогает нашим алгоритмам обнаруживать перемещение сайта и обновите наш индекс быстрее.
   • Большие сайты: Вы можете перемещать большие сайты на один раздел за время. Это может упростить отслеживание, обнаружение и более быстрое устранение проблем.
2. Обновите файлы robots.txt :
   • На старом сайте удалите все robots.txt директивы. Это позволяет роботу Googlebot обнаруживать все перенаправления на новый сайт и обновлять наш индекс.
   • На новом сайте убедитесь, что файл robots.txt позволяет все ползать. Это включает сканирование изображений, CSS, JavaScript и других страниц. активы, кроме URL-адресов, сканирование которых вы точно не хотите.
3. Настройте старый веб-сайт на перенаправления пользователей и робота Google на новый сайт на основе сопоставления URL-адресов.
4. Отправить Изменение адреса в Search Console для старого сайта . Если вы переводите свой сайт с HTTP на HTTPS, вам не нужно использовать Инструмент изменения адреса .
5. На старом сайте отправьте две карты сайта, которые вы подготовили ранее содержащий старый и новый URL. Это помогает нашим сканерам обнаруживать перенаправления со старых URL-адреса на новые URL-адреса и облегчает перемещение сайта.
6. Сохраняйте перенаправления как можно дольше и подумайте о том, чтобы сохранить их бесконечно. Однако переадресация выполняется медленно для пользователей, поэтому попробуйте обновить свои собственные ссылки и любые крупные ссылки с других веб-сайтов, указывающие на новые URL-адреса.

Время, затрачиваемое роботом Googlebot и нашими системами на обнаружение и обработку всех URL-адресов на сайте. move зависит от того, насколько быстры ваши серверы и сколько URL-адресов задействовано. Как общее правило, Для перемещения большинства страниц веб-сайта среднего размера может потребоваться несколько недель, а для больших сайтов требуется дольше.Скорость, с которой робот Googlebot и наши системы обнаруживает и обрабатывает перемещенные URL, зависит от от количества URL-адресов и скорости сервера.

Обновить входящие ссылки

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

• Внешние ссылки: попробуйте связаться с сайтами в сохраненном списке сайтов, ссылающихся на ваш текущий контент, попросив их обновить свои ссылки на ваш новый сайт. Подумайте о том, чтобы расставить приоритеты усилия по количеству входящих посещений для каждой ссылки.
• Ссылки на профили, например, из Facebook, Twitter и LinkedIn.
• Рекламные кампании, указывающие на новые целевые страницы.

Монитор трафика

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

Используйте Search Console для отслеживания трафика

Многие функции Search Console помогают отслеживать перемещение сайта, в том числе:

• Карты сайта: Отправьте две карты сайта, которые вы сохранили ранее из сопоставления. Изначально карта сайта содержащие новые URL-адреса, не будут проиндексированы, а карта сайта старых URL-адресов будет проиндексировано много страниц.Со временем количество страниц, проиндексированных со старых URL-адресов карта сайта упадет до нуля с соответствующим увеличением индексации новых URL-адресов.
• Индекс покрытия отчет: графики будут отражать перемещение сайта, показывая снижение количества проиндексированных URL-адресов на старый сайт и увеличение индексации на новом сайте. Регулярно проверяйте наличие каких-либо непредвиденные ошибки сканирования.
• Поиск запросы: по мере того, как все больше страниц нового сайта индексируются и начинают ранжироваться, поисковые запросы отчеты начнут показывать URL-адреса на новом сайте, получающем поисковые показы и клики.

Используйте другие инструменты для отслеживания трафика

Следите за доступом к серверу и журналами ошибок. В частности, проверьте сканирование Робот Googlebot, любые URL-адреса, которые неожиданно возвращают коды состояния ошибки HTTP, и обычный пользовательский трафик.

Если вы установили на свой сайт какое-либо программное обеспечение для веб-аналитики или ваша CMS предоставляет аналитику, также рекомендуется проверять трафик таким образом, чтобы вы могли видеть, как трафик с вашего старого сайта на новый.В частности, Google Analytics предлагает отчеты в реальном времени, и это удобная функция для использования на начальном этапе перемещения сайта. Вы должны ожидать увидеть падение трафика на старом сайте и рост на новом сайте.

Устранение неполадок на вашем сайте move

Вот несколько распространенных ошибок при переносе сайта с изменением URL (включая HTTP на HTTPS). Эти ошибки могут помешать полной индексации вашего нового сайта.

Как перенаправить мой сайт с помощью файла .htaccess?

Последнее изменение: 6 марта 2020 г.

Обзор

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

ПРОЧИТАЙТЕ Вначале

Конфигурационный файл .htaccess очень мощный. Даже малейшая синтаксическая ошибка (например, отсутствие пробела) может привести к тому, что ваш контент будет отображаться некорректно или вообще.

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

Эта статья предоставлена ​​любезно. Установка, настройка и устранение неполадок сторонних приложений выходит за рамки поддержки, предоставляемой (mt) Media Temple. Найдите минутку, чтобы просмотреть Заявление о поддержке.

Инструкции

1. Создайте пустой текстовый файл с помощью текстового редактора, например блокнота, и сохраните его как htaccess.текст.

ПРИМЕЧАНИЕ:

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

2. Отредактируйте содержимое файла htaccess.txt. Ниже приведены несколько примеров переадресации, которые вы можете использовать. Они помечены в соответствии с тем, какие действия они будут выполнять.

301 (постоянный) перенаправление:

Используйте редирект 301.htaccess, чтобы постоянно указывать для всего сайта другой URL. Это наиболее распространенный тип перенаправления, который полезен в большинстве ситуаций. В этом примере мы перенаправляемся на домен example.com.

При добавлении следующего в файл .htaccess вашего веб-сайта обязательно замените example.com своим собственным доменным именем.

  # Это позволяет перенаправить весь ваш сайт на любой другой домен
Перенаправить 301 / http://example.com/
  

302 (временное) перенаправление:

Укажите для всего сайта другой временный URL.Это полезно для целей SEO, если у вас есть временная целевая страница и вы планируете вернуться к основной целевой странице позже:

  # Это позволяет перенаправить весь ваш сайт на любой другой домен
Перенаправление 302 / http://example.com/
  

Перенаправить index.html в определенную подпапку:

  # Это позволяет перенаправить index.html в определенную подпапку
Перенаправить /index.html http://example.com/newdirectory/
  

Перенаправить старый каталог в новый каталог: