Как перенести сайт с конструктора на свой хостинг

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

Доступное описание VPS-хостинга Beget позволяет рассматривать VPS как среду для самостоятельного размещения сайта и управления его серверной частью. Однако в нём нет достаточных сведений о конкретном порядке переноса проектов с Tilda или Readymag. Поэтому платформенные ограничения, доступность экспорта и поддерживаемые сценарии необходимо отдельно проверять по актуальной документации соответствующего конструктора.

Что именно требуется перенести

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

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

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

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

Проверка возможностей Tilda и Readymag

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

Проверить подходящий вариант можно на странице Beget.

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

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

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

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

Подготовка VPS и тестовой площадки

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

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

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

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

Перед настройкой откройте Beget и сверьте актуальные условия.

Домен, DNS и HTTPS

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

Особого внимания требуют записи для почты. Запись A или AAAA, указывающая сайт на VPS, не должна автоматически заменять MX-записи, SPF, DKIM и DMARC. Если почта обслуживается отдельным провайдером, её записи необходимо сохранить. Ошибочное изменение DNS может привести к тому, что сайт откроется, но письма перестанут доставляться.

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

HTTPS требуется настроить для основного домена и всех используемых поддоменов. После получения сертификата нужно проверить открытие страниц по защищённому протоколу, перенаправление с HTTP, отсутствие смешанного содержимого и корректность ссылок в письмах и рекламных объявлениях. Если сайт использует несколько вариантов адреса с www и без него, следует выбрать один основной вариант и настроить единообразное перенаправление.

Формы, почта и интеграции

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

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

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

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

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

Приёмка и план возврата

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

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

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

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

Главный вывод состоит в том, что VPS решает задачу размещения и самостоятельного управления сервером, но не заменяет этап анализа исходного конструктора. Для Tilda и Readymag сначала нужно подтвердить, какой объём проекта доступен для экспорта и какие функции придётся реализовать заново. Только после этого можно оценивать сроки, требования к серверу и риски переключения домена.

Что почитать дальше

Обложка вдохновлена гравюрой Альбрехта Дюрера «Меланхолия I» (1514). Посмотреть оригинал в коллекции Метрополитен-музея.