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

Новости трендов

Как завершить закрытие сайта с помощью раздельной миграции

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

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

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

Почему это называется «разделенной миграцией»?

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

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

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



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

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

Однако этот процесс будет более кропотливым для обычной миграции или переплатформы, которая включает в себя:

  • Метаданные
  • Содержание
  • Заголовки
  • 404 ошибки
  • Существующие редиректы
  • Картинки
  • И т.п.

С точки зрения обеспечения качества (QA), базовое перенаправление URL легче протестировать и убедиться, что все работает правильно. Тем не менее, мы все же прошли через несколько этапов, чтобы процесс прошел гладко, начиная с «обнаружения».

Фаза открытия

Я знал, что моей самой большой проблемой было определить существующие страницы на всех трех веб-сайтах. Из соображений конфиденциальности, интеллектуальной собственности и других юридических соображений назовем их Source, Destination1 и Destination2.

Я начал со сканирования Screaming Frog, которое просматривало исходный веб-сайт и определяло все индексируемые страницы. А чтобы упростить процесс принятия решений, мне пришлось использовать данные Google Analytics и Google Search Console с помощью API.

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

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

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

Этап настройки

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

  • Очистите список, чтобы исключить параметры URL или другие дубликаты.
  • Определите владельцев страницы (на какой сайт она должна перейти — Destination1 или Destination2).
  • Каков приоритет страницы? (Есть ли у него прямой трафик? Рейтинг в Google? Есть ли у него обратные ссылки?)
  • Что такое код состояния страницы? (Это 200 или 301 или 404?)

Я поместил свои данные ScreamingFrog и данные Semrush на отдельные листы и создал файл Google Sheets:

Как завершить закрытие сайта с помощью раздельной миграции

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

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

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

В моей задаче я работал с 18 000 URL-адресов, и после некоторой фильтрации и удаления тех, которые не были важны, я получил 11 000.

Тестирование

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

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

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

Обновление экспорта ScreamingFrog в SF-внутренний ВСЕ лист автоматически скорректирует данные в лист URL-адресов и показать вам те, у которых неверный целевой URL.

Но что пошло не так?

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

Этот контроль качества миграции был основан на двух вещах:

  • Таргетинг.
  • Проверка 301 редиректа.

Мы потратили больше времени на этап обнаружения, чем на саму миграцию.

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

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

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

Использование шаблона нам очень помогло.

Шаблон

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

Вывод

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

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

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

Однако это только часть истории. Мы также ждали следующего, прежде чем признать проект победным:

  • Страницы исходного сайта начали медленно деиндексироваться.
  • Рейтинг целевой страницы начал расти.

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

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


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


Новое в поисковой системе

Об авторе

Как завершить закрытие сайта с помощью раздельной миграции

Людвиг Махян — участник Search Engine Land, занимающийся органическим и техническим SEO. Его опыт работы в веб-разработке и цифровом маркетинге. Людвиг имеет более чем 20-летний опыт работы в области дизайна, кодирования и продвижения веб-сайтов. Он является соучредителем MAZELESS, корпоративного SEO-агентства.


Подборка статей о ИТ компаниях. Обмен опытом. Обучение востребованным профессиям в сфере IT. Маркетинг. Анализ рынка. Полезная информация. Подпишитесь на нас в социальных сетях, что бы не пропустить важное.

Информация для Вас была полезна?
0
0
0
0
0
0
0

Похожие статьи

Кнопка «Наверх»