Перенос сайта
на WordPress

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

Что переносится

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

Адреса страниц — главный риск

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

Переключение и наблюдение

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

Отдельный случай — перенос не между хостингами, а с другой системы управления на WordPress: Bitrix, Joomla, конструктор или самописный движок. Здесь меняется не только место хранения файлов, а сама платформа, поэтому миграция требует больше помощи специалиста. Перенос состоит из дополнительных шагов: разбора структуры прежней CMS и создания новой базы под WordPress.

Причины перехода на WordPress

Владельцы сайтов на Bitrix, Joomla или конструкторах переходят на WordPress из-за широкого выбора плагинов и специалистов, знакомых с CMS. Причиной становится и хостинг: тарифы под прежнюю платформу часто дороже, чем нужно для WordPress, а PHP на них обновляется реже. Использовать привычные инструменты веб-разработки после переноса становится проще, а часть задач проще сделать заранее, чем совмещать с переносом сайта.

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

Файлы и база данных

Перенос с другой CMS редко сводится к простому копированию файлов на новый хостинг. Материалы прежнего сайта выгружаются в архив и попадают в WordPress через импорт: статьи, разделы, вложения, файлы шаблона. Файлы шаблона обычно не используются напрямую — тема WordPress подбирается или дорабатывается отдельно. Отдельная папка отводится под медиафайлы, а база данных MySQL создаётся заново на новом хостинге. Связи между таблицами выстраиваются под структуру WordPress, а не берутся напрямую из прежней CMS.

Часть функций прежнего сайта закрывают отдельные плагины: форма обратной связи, каталог, галерея. Такие блоки становятся аналогами на WordPress, а не приходят из прежней CMS в готовом виде. Плагин под каждую функцию подбирается отдельно, с учётом того, что уже умеет WordPress без надстроек. Ручного просмотра требуют таблицы и вложенные списки — при импорте разметка нередко теряет часть форматирования.

Требования к хостингу перед переносом

Перед тем как перенести сайт, специалист собирает информацию о возможностях хостинга. Учитываются версия PHP, лимиты базы MySQL и доступный объём под папку с файлами. Если тарифа не хватает под требования WordPress, обсуждается замена хостинга или переход на другой план. Имя пользователя базы данных, имя самой базы и пароль для нового пользователя создаются заново, отдельно от прежней CMS.

Хостинг оценивается и по лимитам, важным после переноса: объём памяти для PHP, разрешённый размер файла при загрузке, поддержку нужных расширений. Часть тарифов рассчитана под лёгкие CMS и не подходит под WordPress с несколькими плагинами и активной темой. Если сайт использует много подключаемых модулей, суммарная нагрузка на хостинг после переноса обычно выше, чем была на прежней платформе.

Случаи, когда перенос не подойдёт

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

Не подойдёт перенос и в случае, когда прежний сайт завязан на внешний сервис через уникальную интеграцию. Пример — обмен с 1С в формате, для которого готового плагина WordPress нет. Такую связь дешевле доработать на месте, чем перестраивать под новую платформу. В остальных случаях перенос на WordPress остаётся практичным способом обновить сайт без потери накопленных материалов.

От чего зависит объём миграции

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

У Tilda нет базы, поэтому в WordPress попадают только материалы разделов, а у Joomla или Bitrix — и структура базы MySQL. Инструкция под каждый случай учитывает эти отличия, а не описывает перенос сайта в общем виде. Итоговый список задач согласуется до старта, чтобы объём и состав переноса были понятны заранее. Такой порядок снижает число доработок уже после запуска на WordPress.

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

Доменное имя и вход в панель

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

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

Права пользователей

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

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

Черновик и публикация записи

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

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

Где разделение прав лишнее

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