Миграция сайта: SEO-стратегия и лучшие практики

Опубликовано: 2021-07-14

Вам может потребоваться перенести свой веб-сайт/бизнес по определенной причине. Как SEO-специалисты, мы называем это «миграцией» или «перемещением сайта». Неправильно подготовленная миграция может привести к значительному снижению вашего органического трафика. В этом руководстве я расскажу, как наиболее эффективно выполнить процесс переноса сайта.

Зачем вам нужно перенести свой сайт? Для этого может быть одна или несколько причин.

Во-первых, давайте взглянем на типы миграции

  1. Изменение домена:
    Вы можете переместить свой сайт x.com на y.com
  2. Изменение структуры URL:
    URL-адреса со словами, которые имеют отношение к содержанию и структуре вашего сайта, более удобны для посетителей, просматривающих ваш сайт. Если URL-адреса сайта не оптимизированы для SEO, вы можете изменить их.
  3. Миграция HTTP > HTTPS:
    Безопасность является главным приоритетом для Google. Если вы переносите свой сайт с HTTP на HTTPS, Google рассматривает это как перемещение сайта с изменением URL-адреса. Это может временно повлиять на некоторые из ваших номеров трафика.
  4. Изменение платформы:
    Платформа сайта — это то, на чем построен наш сайт. Вы могли бы создать свой сайт на WordPress, Shopify, Wix или любой другой платформе. Кроме того, у вас может быть собственный сайт, созданный командой разработчиков. Возможно, вы захотите перейти на лучшую платформу. При смене платформы, на которой построен ваш сайт, мы должны протестировать SEO-функции вашей новой платформы.
  5. Изменения структуры и иерархии:
    Ваш веб-сайт может начать работать в совершенно другой области. Или URL-адрес вашего сайта и структура категорий могут быть не оптимизированы для SEO. Независимо от причины, мы можем начать работу над совершенно новым сайтом.
  6. Изменение сервера:
    Миграция серверов представляет риск, прежде всего, с точки зрения скорости загрузки страниц. Скорость сайта является фактором ранжирования SEO, но, что более важно, это проблема пользовательского опыта и коэффициента конверсии. Вы можете подумать о том, чтобы настроить промежуточный сайт на новом сервере и протестировать на нем скорость страницы. Кроме того, не забудьте проверить перенаправления, чтобы убедиться, что они ведут себя должным образом.
  7. Отдельная миграция мобильного сайта:
    Google рекомендует адаптивный веб-дизайн в качестве шаблона дизайна, поскольку его проще всего реализовать и поддерживать. Таким образом, вы можете запланировать перенаправление вашей версии m-dot на основную адаптивную версию. Делать редирект там абсолютно правильно. Это то, что должно быть довольно просто и должно быть довольно легко сделать.

Если вся структура останется прежней, изменится только домен (1-й тип миграции), то можно сказать, что наша работа проста. В других типах миграции или при объединении нескольких типов миграции все может быть сложнее.

Есть десятки примеров, когда во время миграции произошла массовая потеря трафика.

Некоторые ошибки, приводящие к потере трафика при переносе сайта:

  1. Отсутствие планирования
  2. Низкие знания SEO и UX
  3. Низкий бюджет
  4. Проблемы с перенаправлением
  5. Ошибки сопоставления URL
  6. Ошибки сканирования
  7. Не мешают мгновенные ошибки

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

Прежде чем я начну, я хочу предупредить вас о нескольких вещах:

  • ! Google не рекомендует одновременно изменять дизайн и структуру URL. Если возможно, полезно выполнять эти два или более типов миграции в разное время, шаг за шагом.
  • ! Если сайт перемещается на другой домен, следует изучить историю нового доменного адреса. Archive.org, поисковый запрос «yoursite.com» и инструменты аудита будут работать. Если есть регистрация домена или сайт, созданный ранее, это необходимо пересмотреть. Установка домена с брендом в Google, который был подвержен таким проблемам, как спам-ссылки или взлом, или обслуживание на совершенно другой тематике, приведет к потере значительной части трафика.
  • ! В некоторых случаях, даже если планирование и реализация миграции выполнены без проблем, существует вероятность того, что органический трафик снизится на 15% и более. Поскольку на сайте происходит важное изменение структуры, Google заново изучает и оценивает каждую страницу одну за другой. Этот период обычно составляет несколько недель, но может быть больше для крупных сайтов. Если все пойдет хорошо, ваш органический трафик наберет положительную динамику через очень короткое время после этой оценки.
  • ! Сайт не должен быть закрыт для пользователей во время или до переноса. Если необходимо внести изменения в дизайн или структуру, вы можете заранее объявить эту информацию своей аудитории с помощью простых методов. (Карусель, электронная почта, SMS, push-уведомления и т. д.) Страницы с разными кодами состояния или предупреждающими сообщениями могут быть негативно восприняты роботом Googlebot.
  • ! Момент миграции (запуск новой структуры) должен приходиться на часовой пояс, в котором сайт получает наименьшую посещаемость. Таким образом, в случае возникновения нежелательных проблем количество затронутой аудитории будет поддерживаться на минимальном уровне. Кроме того, в эти часы, когда нагрузка на сервер низкая, робот Googlebot будет быстрее сканировать и индексировать новый сайт.

[Пример успеха] Не позволяйте редизайну наносить ущерб SEO

Через год после редизайна своего веб-сайта EasyCash вскоре осознала, что производительности, на которую они надеялись, нет. Они определили и устранили несколько препятствий SEO.
Читать тематическое исследование

Планирование и сбор данных

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

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

Совет. Хранение файлов журналов за 45 дней до даты переноса позволит вам проанализировать поведение робота Googlebot и принять незамедлительные меры в случае обнаружения различий.

Создать тестовый сайт и запретить

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

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

Как запретить поисковым ботам файл robots.txt?

Создайте файл robots.txt . Вы можете создать файл с именем test.example.com/robots.txt и выполнить следующие команды:

——

Пользовательский агент: *
Запретить: /
# Эта команда блокирует доступ всех ботов к моему сайту.

——

Агент пользователя: OnCrawl
Разрешать: /
# Эта команда позволяет только боту OnCrawl получить доступ к моему веб-сайту.

—–

Можно решить, с какими ботами тестировать, и определить трассировку до пользовательского агента через файл robots.txt. Oncrawl имеет функции, которые значительно упростят работу.

Ограничение IP : если вы участвуете в плане переноса веб-сайта компании, вы можете открыть доступ только к IP-адресу компании и отключить доступ ко всем другим IP-адресам, чтобы предотвратить раскрытие нового проекта. В этом случае вам нужно будет предоставить доступ к частному IP агентству или консультантам, с которыми вы работаете, если таковые имеются. Даже если вы делаете ограничение по IP, вы должны запретить ботов файлом robots.txt.

Защита паролем : для входа на тестовую площадку можно создать комбинацию идентификатора и пароля. Приложения для сканирования, такие как Oncrawl, имеют функции доступа с паролем.

Тег Noindex . Метатег noindex можно добавить в раздел заголовка всех страниц, чтобы предотвратить индексацию страниц тестового сайта Google.

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

Отслеживание эффективности с помощью Google Analytics

Одним из наиболее важных моментов для отслеживания эффективности является продолжение работы с той же учетной записью Google Analytics без потери данных. Поэтому существующий код GA и GTM должен быть активен на новом сайте с миграцией.

Создание нового кода GA усложняет вам измерение производительности сети.

Добавление напоминания на панель инструментов Google Analytics в день переезда облегчит вам сравнение производительности позже.

Создание существующего списка URL-адресов

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

* Файл .htaccess — это файл конфигурации, расположенный на серверах Apache.

RewriteEngine On RewriteCond %{HTTP_HOST} ^oldsitee\.com$ [ИЛИ]
RewriteCond %{HTTP_HOST} ^www\.newsite\.com$
Правило перезаписи (.*)$ https://newsite.com/$1 [R=301,L]

Этот набор правил гарантирует, что адрес домена автоматически перенаправляет 301 на https://newsite.com при достижении любого URL-адреса на oldsite.com или www.oldsite.com.

Однако, если ваша работа заключается в исправлении неправильной структуры URL, здесь все усложняется. Я объяснил эту ситуацию позже в статье.

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

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

Начать с XML Sitemap — всегда правильный шаг. Чтобы просто перенести URL-адреса из вашего XML-файла в электронную таблицу, вы можете скопировать ссылку сюда и написать свой собственный URL-адрес карты сайта вместо https://www.sinanyesiltas.com/post-sitemap.xml в первой строке.

  • Все URL с показом в Search Console,
  • Все URL-адреса с просмотрами страниц через Google Analytics,
  • Все URL-адреса, полученные в результате сканирования с помощью Oncrawl,
  • Продвижение вперед с использованием нескольких сторонних инструментов сканирования гарантирует, что задание будет ясным. Важно убедиться, что ни один URL-адрес не пропущен, используя различные функции каждого приложения для сканирования.
  • Здесь важно включить страницы, которые уже получили ссылки. Для этого необходимо обнаружить связанные страницы с помощью инструментов Search Console, Ahrefs, Semrush и Majestic и добавить их в тот же документ.

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

У нас есть много разных таблиц Excel с доступными URL-адресами. Пришло время объединить их все в один файл и сделать его уникальным. Мы продолжаем наш путь с документом, в котором нет совпадающих URL-адресов, перечислены ваши текущие URL-адреса и не пропущено ни одного важного URL-адреса. Вкладка ВСЕ на изображении представляет область, о которой я говорю.

Сопоставление URL-адресов (старое — новое сопоставление URL-адресов)

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

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

На этом этапе необходимо учитывать важные моменты:

  • 301 перенаправление на стороне сервера должно использоваться в применяемых переадресациях. Этот постоянный тип перенаправления перенаправляет страницу X на страницу Y и гарантирует, что все значение страницы X будет передано на страницу Y. Использование 302, 307, JS, Meta или других типов перенаправления является очень серьезной ошибкой в ​​​​процессе миграции.
  • Не включайте URL-адреса без посетителей, с плохим содержанием и которые, по вашему мнению, наносят ущерб вашему краулинговому бюджету, в файл сопоставления URL-адресов. Помните, что Google зарезервировал место для вашего сайта в своем центре обработки данных, и вы должны использовать это пространство для наиболее эффективных страниц. Если вы определили ненужную группу страниц, заставьте эти страницы отвечать кодом состояния 410.
    Почему 410? Код состояния 410, в отличие от 404, говорит о том, что эта страница сейчас удалена и больше не будет активной. Если вы используете код состояния 404, робот Googlebot посещает ваш сервер, чтобы проверить, активна ли снова та же страница. Исключая эти посещения, ошибка 410 является важным решением для эффективного использования вашего краулингового бюджета.
  • Не перенаправляйте несколько страниц на одну страницу массово. Это вызывает путаницу как у пользователей, так и у ботов. Вместо того, чтобы применять массовую проверку 301 для страниц, которые вы не используете и считаете непродуктивными, просмотрите решение 410.
  • Если вы находитесь в процессе миграции сайта электронной коммерции с тысячами страниц, невозможно подготовить однозначное сопоставление для каждого URL-адреса. В этом случае вы можете направить свою ИТ-команду, подготовив шаблоны.

Перенаправление изображений

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

Как сделать?

  1. Сканируйте файлы изображений с помощью Oncrawl.
  2. Вы можете анализировать источники изображений, которые получают обратные ссылки, с помощью Ahrefs, Semrush и Majestic.
  3. Вы можете анализировать страницы с вашими изображениями через Search Console > Тип поиска > Изображение.
  4. Соберите все URL-адреса, которые вы получите, в том же формате Excel, что и мы для страниц, устраните дубликаты и завершите настройку сопоставления.

(Если домен меняется) Инструмент изменения адреса Google

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

  • Владение ресурсом Search Console требуется как для старого, так и для нового сайта.
  • Изменение адреса используется только для изменения домена. Недоступно для изменения URL-адреса подпапки или миграции HTTP > HTTPS.
  • В этом инструменте изменений необходимо обрабатывать каждый поддомен отдельно, если таковой имеется.
  • Когда эти условия соблюдены, процесс можно запустить, выбрав старый и новый сайты с помощью инструмента изменения адреса Google.

Обновления ссылок

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

  • Все внутренние ссылки на странице
  • Канонические теги
  • -Если есть- Теги Hreflang
  • -Если есть- Альтернативные теги
  • -Если есть- HTML-ссылки на карту сайта
  • Ссылки на профили в социальных сетях
  • Ссылки на целевые страницы, используемые в рекламных кампаниях

Совет . Если вы полностью изменили структуру URL-адресов, я рекомендую какое-то время сохранить XML-файл карты сайта со старыми URL-адресами. Создайте отдельную карту сайта XML с новой структурой URL. Некоторое время продолжайте отправлять старые URL-адреса роботу Googlebot. Таким образом, Googlebot ускорит процесс просмотра и индексации перенаправления на старые URL-адреса. В зависимости от размера сайта я рекомендую сохранять активным XML-файл карты сайта не менее 1 месяца назад.

Элементы управления

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

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

  • Файл robots.txt
  • Код отслеживания Google Аналитики
  • Контроль проверки Search Console (если домен изменился, его следует продолжить с 2 разными доменами, старым и новым)
  • Метатег (noindex, подписка)
  • Канонический тег

Также обратите внимание на это:

  • Если возможно, следует связаться с поставщиками обратных ссылок и заменить старые ссылки новыми. Если есть большая сеть обратных ссылок, планирование может быть сделано в порядке важности, и можно связаться только с важными из них./li>
  • Целевые страницы, используемые в рекламных кампаниях, должны быть проверены или должны быть проинформированы соответствующие группы.
  • Сканируя новый сайт, следует проверить, работают ли все ссылки без сбоев, и если внутри сайта возникает петля перенаправления, следует немедленно принять меры.
  • Ссылки в профилях социальных сетей должны быть обновлены.
  • Необходимо следить за индексацией новых страниц.
  • Необходимо отслеживать эффективность ключевых слов.
  • 301 редиректы не следует отключать в ближайшее время, они всегда должны оставаться активными.
  • Если домен был изменен; Старый домен должен храниться как минимум еще 2 года.
  • Старые данные (URL-адреса, журналы, эффективность ключевых слов и т. д.) следует хранить некоторое время.
  • Если файл дезавуирования установлен на старом сайте, его также необходимо загрузить на новый домен.

Google выполняет настройку маршрутизации между старым и новым сайтом в течение 180 дней. По истечении 180-дневного периода он не распознает никакой связи между старым и новым сайтами и рассматривает старый сайт как нерелевантный сайт, если он все еще существует и доступен для сканирования.