Контрольный список миграции вашего веб-сайта: 3 важных шага

            

Что такое миграция контента?

Как решить проблему миграции контента

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

Как проверить миграцию контента

Использование переносимых форматов

Форматы данных, используемые при переносе контента

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

Я до сих пор помню свою первую попытку перенести мой блог-хобби http://zsolt-nagy.github.io/ после покупки домена http://zsoltnagy.eu и установка CMS. Несмотря на то, что я использовал один из самых простых методов миграции, проблемы начали возникать. Подсветка синтаксиса не работает для исходного кода. Дискуссионные комментарии не сработали. Некоторые внутренние ссылки перестали работать из-за использования абсолютных URL-адресов вместо относительных. Это был беспорядок.

Эта статья — моя попытка помочь вам в успешной миграции контента.

Что такое миграция контента?

Миграция контента — это процесс перемещения контента и связанных с ним метаданных из источника, где контент существует, в место назначения. Стоит подчеркнуть метаданные, потому что между исходным контентом и его окружением существует множество связей.

Общие проблемы с миграцией контента

Самой простой и распространенной формой миграции является замена системы управления контентом (CMS ) без изменения домена, и все внутренние URL остаются неизменными. Предположим, вы прочитали статью, сравнивающую WordPress и ButterCMS и решили перенести ваш сайт WordPress в ButterCMS. Обычно это быстрый и простой процесс, поскольку вы сохраняете всю структуру, теги, категории, свою базу пользователей и все остальное в неизменном виде. Имейте в виду, что технические проблемы с вашим блогом WordPress могут создавать проблемы, требующие пользовательских модификаций, но в целом этот процесс по-прежнему наиболее прост.

Технический долг

Одним из простых примеров технической задолженности WordPress является использование абсолютных URL-адресов в области контента, ссылающихся на контент в том же домене. После того, как вы измените домен, вы должны найти эти ссылки одну за другой. То же самое относится к формам подписки, сгенерированным плагинами, такими как Ninja Popups. Соблазнительно разместить тег [ninja-inline=ID] внутри сообщения блога для отображения формы подписки, но вы должны обновлять эти объявления по одному при переносе контента.

Изменение доменов

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

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

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

Как решить проблему миграции контента

В каждом успешном процессе миграции контента есть три шага, о которых необходимо позаботиться:

1. Планирование миграции
2. Выполнение миграции
3. Проверка и мониторинг

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

Шаг 2 — это соблюдение плана и его выполнение. Первое, что мы должны сделать на шаге 2, это сделать резервную копию на случай, если что-то пойдет не так. Также стоит убедиться, что наш сайт не может быть сканирован во время процесса миграции. Затем мы выполняем тщательно спланированные шаги миграции контента.

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

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

Контрольный список миграции контента состоит из трех основных этапов. Во-первых, мы планируем миграцию и формулируем критерии приемлемости:

1. Определите цели миграции
2. Резервное копирование исходного сайта
3. Проверка развертывания и отката вашей промежуточной и производственной среды
4. Подготовка аналитических данных и связанных метаданных для нового сайта
5. Полный список URL-адресов и внутренних ссылок
6. Ссылки, ссылающиеся на другие статьи из того же домена (абсолютные и относительные)
7. Файлы активов и ссылки
8. CMS-специфичные плагины, которые влияют на содержимое
9. Просмотр пользовательских стилей, аннотации содержимого
10. Интерактивный контент, такой как интерактивный текстовый редактор или календарь
11. Всплывающие окна, формы регистрации
12. План миграции комментариев, связанных с постом
13. Пространства баннеров, которые могут или не могут быть перенесены
14. Учитывать различия кодировки символов
15. HTML-теги исходного содержимого
16. Категории и теги, связанные с контентом
17. SEO ключевые слова, связанные с контентом
18. Содержание при миграции серии
19. Информация об авторе
20. Данные пользователя, если есть зарегистрированные пользователи

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

Если у вас есть тестовый сайт, вы можете проверить большинство пунктов приведенного выше контрольного списка.

Затем следует второй шаг, Выполнение миграции :

1. Выполнить и проверить резервную копию
2. Отключить возможность сканирования сайта
3. Выполните тестовую миграцию в промежуточной среде и проверьте все точки ваших критериев приемлемости в ней
4. В случае смены домена обновите DNS и выполните все сопутствующее администрирование и автоматическое перенаправление
5. Выполнение реальной миграции всего инвентаря контента
6. Включить новый сайт, восстановить возможность сканирования

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

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

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

Контрольные списки также могут отличаться от миграции к миграции. В каждом случае два списка элементов должны быть определены, в идеале, на первом этапе процесса (этап планирования):

1. Что должно быть перенесено?
2. Что не нужно переносить?

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

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

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

Как проверить миграцию содержимого

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

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

• Полнота. Пройдите инвентаризацию контента и проверьте каждый раздел. Убедитесь, что все, что вы занесли в белый список, было перенесено.
• Качество сканирования. Прокрутите перемещенный контент и определите все, что выделяется. Отметьте эти ошибки и исправьте их, прежде чем начать работу. Включите эстетические ошибки и исправьте их перед проверкой SEO на более позднем этапе.
• Нет битых или нежелательных ссылок. После завершения миграции отобразите содержимое и щелкните каждую ссылку в содержимом. Вручную проверьте, является ли желаемый результат. Есть четыре возможных результата.
• Единственный приемлемый результат, который не приведет к дальнейшим задачам с вашей стороны, — это если щелчок приведет к содержанию, на которое вы хотите сослаться.
• Второй лучший результат — это если щелчок приводит к неверной ссылке, поскольку вы ссылаетесь на контент, который не был перенесен. Каждая неработающая ссылка должна быть отмечена и исправлена ​​до того, как результаты миграции будут опубликованы.
• вот третий результат, который может быть приемлем в краткосрочной перспективе, если предположить, что он будет исправлен в конце концов. Вы можете обнаружить, что некоторые ссылки указывают на источник контента. Это приемлемо, если вы запомните эти элементы TO-DO и выполните миграцию на более позднем этапе.
• Четвертая возможность заключается в том, что ссылка полностью повреждена или является нежелательной, и эту ошибку нельзя исправить, перенеся другой контент с использованием того же процесса. Эти ошибки должны быть исправлены перед запуском.
• Нет нежелательных персонажей. Нежелательные символы могут исходить из ошибок кодирования символов или альтернативных диалектов, понятных только исходной CMS. Например, для меня было неприятным моментом сделать вывод, что в более ранней версии моей книги по JavaScript был тег WordPress, описывающий встроенную форму регистрации моего плагина Ninja Popups. Программное обеспечение Leanpub, создающее мою книгу из источника уценки, отображало тег [ninja-inline id=1] в виде простого текста.
• Допустимая подсветка синтаксиса. Если вы отображаете исходный код, убедитесь, что подсветка синтаксиса работает должным образом. Если, например, вы используете TypeScript или JSX, обычная подсветка JavaScript вам не подойдет. Этот шаг требует экспертизы для конкретной области.
• Правовые аспекты. В Европейском Союзе соблюдение GDPR является актуальной темой, поскольку компании могут потерять до 4% своих доходов в результате нарушения правил защиты данных. В процессе миграции вам, возможно, придется проверить, используете ли вы данные для каких-либо целей, которые нарушают соответствие. Вы также должны убедиться, что вы запрашиваете согласие пользователя на файлы cookie, а также запрашиваете согласие на подписку при регистрации по электронной почте.
• Без SEO-штрафа за контент для сканирования. Этот шаг требует некоторой экспертизы SEO. Если вы дублируете контент, обязательно посетите источник и проверьте, есть ли каноническая ссылка в теге head. Например, во всех сообщениях в блоге zsolt-nagy.github.io можно найти каноническую ссылку.

На этой странице:

http://zsolt-nagy.github.io/Handling-Time-in-Javascript-Inspired-by-the-Bug-Report-of-the-Century/ каноническая ссылка:

<link rel = "canonical" href = " http://www.zsoltnagy.eu/Handling-Time-in-Javascript-Inspired-by-the-Bug-Report- оф-века / ">

Убедитесь, что результат структурирован с учетом SEO. Чем больше структурных изменений сделано между исходным контентом и HTML, тем больше вам нужно обратить внимание на этот шаг.

• Просмотрите белый список миграции и определите все метаданные и интерактивные функции, которые не были перенесены. Это очевидный, но трудоемкий шаг в случае популярного контента. Выполните эти шаги один за другим в зависимости от ваших приоритетов.

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

Использование переносимых форматов

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

Автоматизация с переносными форматами

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

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

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

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

CMS Exports

Экспорт CMS предоставляет быструю возможность для миграции контента. Ваш контент может быть экспортирован, и как часть процесса, специфичная для плагина CMS нотация может быть удалена. В этом разделе мы рассмотрим экспортеров контента ButterCMS, WordPress, Joomla и Drupal.

Что касается экспортеров CMS, существует разница между

• экспорт содержимого всей CMS и импорт его на новую платформу CMS,
• экспорт подмножества статей и связанных метаданных.

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

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

1. Экспорт содержимого базы данных в промежуточный формат, такой как SQL или JSON
2. Преобразовать формат в формат другой CMS (при необходимости)
3. Заполните CMS назначения преобразованными данными

Существует несколько инструментов, таких как https://cms2cms.com/ которые автоматизируют процесс миграции контента для вас в обмен на низкую цену. Однако выполнение процесса автоматической миграции не гарантирует, что вы закончили с миграцией, поскольку могут появиться небольшие ошибки.

Когда дело доходит до перехода на https://buttercms.com/ ознакомьтесь со статьей https://buttercms.com / blog / buttercms-vs-wordpress-Why-Choose-Butter поскольку статья определяет, как просто экспортировать WordPress в ButterCMS.

Форматы данных, используемые при переносе контента

Выбор правильных форматов данных может резко увеличить или уменьшить количество времени, необходимое для переноса контента. Markdown, HTML, JSON, XML и визуализированный HTML являются распространенными форматами, которые работают с различными усилиями.

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

уценки

Markdown пожалуй, самый удобный формат для использования при переносе контента. Большинство решений CMS предлагают уценку как формат для описания вашего контента. Даже если ваша CMS не поддерживает Markdown, вы все равно сможете сохранить исходный код Markdown и преобразовать его в формат, поддерживаемый CMS с помощью преобразователей Markdown (например, Markdown-to-HTML плагин Atom.io ). Это один шаг, который окупается больше всего, когда дело доходит до переноса контента, потому что Markdown удобен для чтения, компактен и также определяет большинство элементов вашего контента.

Этот язык имеет диалекты. При написании своих книг я регулярно использую Маркуа . Ваша CMS также может содержать какой-то специальный дополнительный контент в вашем файле Markdown. Например, на моих сайтах WordPress есть специальные обозначения для плагинов, такие как форма регистрации. При использовании всплывающих окон ниндзя это обозначение [ninja-inline id=”1”]где 1 — идентификатор онлайн-формы. Это содержание понимается CMS. Однако при перепрофилировании контента в форме книги Leanpub вышеуказанный контент теряет свое значение. То же самое относится к миграции с одной CMS на другую платформу CMS, где наши плагины недоступны.

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

HTML

Уценку можно напрямую преобразовать в HTML . Любой контент HTML может быть помещен в файл Markdown. Посетите онлайн-конвертер https://markdowntohtml.com/ чтобы увидеть визуальное преобразование между форматами. Преобразование уценки в HTML — простая задача, поэтому было бы удивительно, если бы ваша CMS не поддерживала ее.

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

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

JSON / XML

Также возможно определить контент, используя XML (расширяемый язык разметки) или JSON (нотация объектов JavaScript). JSON to XML похож на Markdown to HTML. JSON более компактен, чем XML, он более интуитивно понятен, и поэтому он стал наиболее широко используемым способом описания полезных нагрузок конечных точек API.

Человекочитаемый JSON:

  {

   "name": "Zsolt Nagy",

   «сайты»: [ "zsoltnagy.eu", "devcareermastery.com" ]

}  

XML:

  



    Жольт Наги 

   

        zsoltnagy.eu 

        devcareermastery.com 

   

  

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

Контент как услуга

Аналогичным образом можно также создать свой контент или приобрести услугу поставщика контента. В этой статье я назову этот контент сервисом . Контент как услуга — все о запросе контента из API и представлении его в вашей CMS.

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

На протяжении всей моей карьеры худшим типом миграции, который я когда-либо видел, была функция «сохранить как HTML» в Microsoft Word. Около восьми лет назад я работал с клиентом, содержимое которого находилось в пользовательской CMS. Этот клиент мог использовать только Microsoft Word для создания HTML-контента, и, к сожалению, Word был очень многословен с точки зрения созданных HTML-тегов. Этот HTML является ужасным форматом, когда речь идет о определении контента, дружественного к SEO, и его удобство обслуживания было не слишком хорошим.

Сколько обычно стоит перенос контента?

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

Если ваш контент не является переносимым, в худшем случае он может окупиться, если переписать ваш контент, а не решать проблемы сопровождения в каждом конкретном случае. В качестве альтернативы можно запросить помощь у таких источников, как PeoplePerHour UpWork или [Top4al][19459][19459[19459][19459[19459][1945]. Почасовая ставка разработчиков варьируется от 30 до 100 долларов, а количество часов, которое вам нужно, зависит от сложности ваших проблем, возможно, в сумме до нескольких тысяч долларов.

Если ваш контент переносимый, простая служба миграции, такая как https://cms2cms.com/ может дать вам оценку затрат на автоматическую миграцию. Расходы зависят от объема контента, который у вас есть, и ваших особых потребностей, и обычно они не превышают 1000 долларов США. Простой блог может стоить несколько сотен долларов за миграцию.

Вывод: сохраняйте контент переносимым

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

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

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

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

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