Перенос сайта с конструктора на обычный хостинг: с чего начать

Этот материал для владельцев сайтов на Tilda, Wix или uCoz, которые переросли конструктор: пошаговый план переноса на обычный хостинг с WordPress без потери контента.

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

Перенос типового сайта-визитки с конструктора на WordPress с настройкой хостинга и доменных записей занимает от 1 до 3 рабочих дней, а доступ к файлам и базе данных на новом сервере обычно открывается через панель управления (ISPmanager или cPanel) и phpMyAdmin.

Речь пойдёт именно о переносе с конструктора (Tilda, Wix, uCoz) на обычный хостинг с WordPress. Перенос между двумя CMS на хостинге или миграцию интернет-магазина с 1С здесь не разбираем.

Зачем переносить сайт с конструктора на хостинг

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

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

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

Можно ли перенести сайт на другой хостинг - да, но переносится контент (тексты, картинки, структура), а не исходный код: конструкторы вроде Wix, Tilda и uKIT не дают выгрузить готовую CMS, сайт собирается заново на новой платформе.

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

Отдельная проблема - магазины на конструкторе. Каталог на 50-100 товаров с фильтрами, остатками и интеграцией с доставкой на многих тарифах либо недоступен, либо работает с заметными ограничениями по числу позиций и функций. На WordPress с WooCommerce таких жёстких потолков по умолчанию нет - растёт каталог, растут только требования к хостингу.

Что нужно подготовить перед переносом

Первый шаг - выберите хостинг и тариф под объём сайта: для визитки хватит простого shared-тарифа (с общими ресурсами сервера, без выделения мощностей под один сайт), для интернет-магазина с нагрузкой стоит смотреть на более мощные варианты. От выбора провайдера зависит и стоимость обслуживания сайта в дальнейшем.

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

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

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

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

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

Если на сайте подключена аналитика - счётчики Яндекс Метрики или Google Analytics - сохраните код счётчика и идентификатор отдельно. На новом хостинге его нужно будет вставить заново в код страниц или через соответствующий плагин, иначе статистика посещений на время прервётся.

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

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

Как выбрать хостинг и тариф

Что лучше для сайта на WordPress - shared-хостинг или VPS? Для старта и среднего потока посетителей достаточно обычного shared-хостинга, VPS или VDS нужны только когда сайт растёт или требует нестандартных настроек. При выборе места размещения смотрите на версии PHP и MySQL - устаревшие версии тормозят CMS и создают дыры в безопасности, панель управления (ISPmanager или cPanel - обе понятны даже без опыта), наличие бесплатного SSL-сертификата и скорость поддержки.

На реальном проекте это выглядит так: клиент заказывает самый дешевый тариф без проверки параметров, через полгода сайт на WordPress начинает падать при наплыве заказов, и приходится переезжать на VDS в разгар продаж. Соотношение цена/качество важнее голой цены - лучшие тарифы для начала это те, где PHP и MySQL обновляются автоматически, а техподдержка отвечает в течение часа. Надёжный российский хостинг с панелью управления, доменами и разумной стоимостью - например, Timeweb, там перенос сайта и выбор тарифа под WordPress занимает минимум действий.

Отдельно смотрите на лимиты тарифа: объём дискового пространства, число баз данных, ограничение по нагрузке на процессор. У бюджетных shared-планов эти цифры скромные, и каталог на несколько тысяч товаров с фотографиями может начать упираться в лимиты раньше, чем кажется на старте.

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

После выбора тарифа хостинг-провайдер предоставляет доступ через FTP или файловый менеджер в панели - именно туда дальше заливаются файлы сайта. WordPress устанавливается через панель управления хостинга (ISPmanager, cPanel) буквально в несколько кликов, без ручной загрузки архивов движка. Если проект изначально кастомный или ожидается большая нагрузка, лучше сразу брать VPS или VDS, а не пытаться ужаться в рамки shared-тарифа.

Экспорт контента с конструктора (Tilda, Wix, uCoz)

Как перенести сайт с Тильды на хостинг? Нужно зайти в настройки проекта, найти раздел экспорта и скачать архив страниц - никакого доступа к коду CMS конструктор не даёт, выгружается только готовая верстка. Если вы только начинаете, вот с чего стоит начать: откройте настройки сайта, найдите кнопку экспорта контента и нажмите на неё, чтобы запустить скачивание zip-архива на компьютер.

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

Скачанный архив распакуйте в отдельную папку на компьютере - внутри будут html-файлы, css, изображения и скрипты, но без базы данных и без движка CMS. Конструктор Wix, Tilda или uKIT не позволяет прямой выгрузки исходного кода CMS, потому что конструктор вообще не использует классическую CMS - весь сайт живёт на серверах самого конструктора. На выходе из экспорта вы получаете статическую копию вида сайта, которую дальше нужно либо верстать в шаблон WordPress, либо использовать как референс для копирайта и структуры при создании сайта с нуля.

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

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

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

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

Перенос файлов и базы данных через FTP и панель управления

Загрузить файлы на новый хостинг можно двумя способами. Первый - через FTP (протокол передачи файлов): нужна программа FileZilla, бесплатный файловый менеджер для соединения с сервером. Логин, пароль и адрес соединения для FTP присылает хостинг-провайдер на почту после регистрации. В FileZilla эти данные вводятся в верхней строке подключения, после чего слева отображаются папки на вашем компьютере, а справа - корневая папка сервера.

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

В обоих случаях файлы нужно скопировать в корневую папку сайта - обычно это public_html. Она хранит все файлы, которые видит браузер посетителя: html-страницы, изображения, скрипты. Если закинуть архив не туда, сайт либо не откроется, либо откроется по неправильному адресу.

С базой данных отдельная история - через FTP её не перенести, файлы БД не лежат в открытом доступе на сервере. Перенос идёт через phpMyAdmin - веб-интерфейс для работы с MySQL, обычно доступный из той же панели управления. На старом хостинге открываете phpMyAdmin, выбираете базу и делаете экспорт - на выходе получаете дамп, файл с расширением .sql, в котором хранится вся структура и содержимое таблиц.

На новом хостинге создаёте новую базу данных и через раздел "Импорт" в phpMyAdmin загружаете этот же .sql файл. Так база переносится через phpMyAdmin или, для опытных пользователей, через консоль MySQL с помощью команд.

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

Обратите внимание и на права доступа к папкам и файлам на сервере - в FileZilla они отображаются в виде числового кода (например, 755 для папок, 644 для файлов). Слишком открытые права - риск безопасности, слишком закрытые - CMS не сможет записывать в них данные, и часть функций сайта откажется работать сразу после переноса.

Если объём файлов большой - десятки тысяч изображений в каталоге магазина - загрузка по FTP может занять часы. В таких случаях быстрее архивировать все файлы в один zip на старом хостинге, перенести этот единственный файл, а затем распаковать его уже на новом сервере через файловый менеджер панели управления.

Установка CMS и настройка сайта на новом хостинге (на примере WordPress)

Когда файлы и база на месте, нужна система управления сайтом (CMS) - без неё текстовый контент из архива конструктора не превратится в рабочий сайт со страницами и навигацией. Самый популярный вариант для начинающих - WordPress.

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

Ручной способ сложнее, но нужен, если автоустановщика нет. Загружаете архив движка WordPress на сервер, распаковываете его в корневой директории сайта, а затем создаёте один из конфигурационных файлов - wp-config.php. В нём указываются имя базы данных, логин и пароль от MySQL, которые вы получили на предыдущем шаге:

define('DB_NAME', 'имя_базы');
define('DB_USER', 'пользователь');
define('DB_PASSWORD', 'пароль');
define('DB_HOST', 'localhost');

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

Отдельно стоит проверить файл .htaccess - он отвечает за редиректы и ряд настроек сервера, и после переноса в нём иногда нужно поправить пути, если адреса страниц изменились.

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

После установки сразу проверьте права постоянных ссылок в настройках CMS - если адреса страниц формируются неправильно (например, остаются вида "?p=123" вместо читаемого URL), это стоит исправить до того, как на страницы начнут вести ссылки из других мест и из поиска.

Если вы переносите не с конструктора, а уже готовый сайт на WordPress на другой хостинг, логика та же: экспортируете базу данных через phpMyAdmin и копируете файлы движка через FTP или файловый менеджер, затем импортируете базу на новом сервере и прописываете её данные в wp-config.php. Как альтернатива - специальные плагины миграции, которые автоматически упаковывают файлы и базу в один архив и разворачивают сайт на новом сервере без ручного экспорта-импорта.

Настройка домена, DNS и SSL после переноса

После того как файлы и база данных загружены на новый хостинг, сайт физически готов работать, но доменное имя пока указывает на старое место. Чтобы посетители увидели новую версию сайта, домен нужно привязать к новому хостингу - для этого изменяют NS-записи у регистратора (если хостинг управляет DNS-зоной сам) или A-запись (если DNS-зона остаётся у регистратора, а меняется только IP-адрес сервера). В личном кабинете хостинга обычно указаны NS-серверы вида ns1.hosting.ru и ns2.hosting.ru - пропишите их в настройках домена у регистратора, чтобы изменить маршрут до сайта.

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

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

Отдельный шаг - подключение SSL-сертификата на новом хостинге. Без него сайт будет открываться по протоколу http, а не https, браузеры начнут показывать предупреждение о незащищённом соединении, и часть посетителей уйдёт. Большинство хостингов выпускают бесплатный сертификат (например, Let's Encrypt) через панель управления в несколько кликов, но сделать это нужно уже после того, как домен указывает на новый сервер - иначе сертификат не пройдёт проверку. После выпуска сертификата стоит проверить, что все внутренние ссылки и пути к изображениям на сайте ведут на https, а не на http, иначе браузер может показывать предупреждение о смешанном контенте.

Сколько времени занимает перенос сайта на хостинг целиком? Однозначного ответа нет: зависит от объёма сайта, способа переноса и того, насколько быстро обновятся DNS-записи. Для небольшого сайта на 10-20 страниц весь процесс - подготовка, загрузка файлов и базы, установка CMS, настройка домена - обычно укладывается в несколько часов работы. С учётом распространения DNS по миру полный переход может занять от нескольких часов до двух суток, даже если техническая часть завершена быстрее.

Проверка работы сайта и типичные ошибки после переноса

Когда домен обновлён и сертификат подключён, нужно пройти по чек-листу и убедиться, что сайт работает корректно, а не просто открывается. Проверка после переноса должна включать: главную страницу и несколько внутренних страниц разных типов, формы обратной связи (отправляются ли заявки и приходят ли письма), подключение почты на домене, корректность редиректов со старых адресов, отсутствие ошибок 404 и 500 в разных разделах, а также то, как сайт выглядит и работает в нескольких браузерах.

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

Вторая типичная проблема - файл .htaccess. Если он был настроен неправильно или не перенесён вовсе, могут возникать ошибки 500, неработающие ЧПУ-адреса (человекопонятные URL) или редиректы, которые ведут в бесконечный цикл. Такая ошибка может возникнуть и из-за неполной копии файлов при переносе. Третья распространённая ошибка - некорректные права доступа к файлам и папкам на сервере: из-за них CMS может не видеть собственные файлы конфигурации или не давать загружать изображения через админку.

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

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

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

Что делать дальше: чек-лист и когда звать специалиста

Если вы прошли все шаги выше - выбрали хостинг, экспортировали контент, перенесли файлы и базу, настроили CMS, домен и SSL, проверили работу сайта - результат уже должен быть на виду: сайт открывается по привычному адресу, формы отправляют заявки, а в адресной строке стоит замок https. В результате переноса перед вами готовый к работе сайт без лишних доработок. Это и есть признак того, что перенос состоялся, а не просто "технически прошёл" - и решиться переехать на хостинг оказалось не так сложно, как казалось вначале.

Чтобы ничего не упустить, пройдитесь по итоговому списку:

1. Выбрать хостинг и тариф под нагрузку сайта.
2. Экспортировать контент с конструктора в удобный для переноса формат.
3. Перенести файлы и базу данных через FTP на новый сервер.
4. Установить и настроить CMS на хостинге.
5. Настроить домен, DNS-записи и SSL-сертификат.
6. Проверить сайт на ошибки: битые ссылки, формы, скорость загрузки.
7. Убедиться, что сайт готов принимать посетителей на постоянной основе.

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

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

Если разбираться самостоятельно не хочется или не хватает времени, задачу переноса можно поручить фрилансеру - например, через Kwork. Там можно найти исполнителя под разные бюджеты: от нескольких сотен рублей за консультацию и проверку DNS до нескольких тысяч за полный перенос сайта под ключ с настройкой CMS и SSL. Это удобный способ закрыть перенос быстро, если своих ресурсов или компетенций не хватает.

После того как сайт переехал и готов к работе, важно позаботиться о SEO. Проверьте индексацию в Google Search Console и Яндекс.Вебмастере - добавьте новый сайт, если нужно, и отследите, что страницы попадают в индекс без ошибок. В первые недели после переезда стоит регулярно смотреть позиции по основным запросам: небольшие колебания - это нормально, а вот резкое падение трафика может сигналить о проблеме, которую нужно решить быстрее, чем через месяц.

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

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

Список литературы

1. Moving WordPress // Официальная документация wordpress.org
2. ISPsystem - Документация ISPmanager: работа с файловым менеджером и базами данных
3. cPanel Inc. - cPanel & WHM Documentation: File Manager and MySQL Databases
4. Google - Site moves with URL changes // Google Search Central Documentation // developers.google.com