Момент, когда сайт впервые покидает компьютер разработчика и отправляется на хостинг, часто кажется сложнее, чем создание нескольких страниц. На локальном компьютере все понятно: есть папка проекта, картинки открываются, база работает, localhost отвечает. После покупки хостинга внезапно появляются FTP, SFTP, корневой каталог, DNS, MySQL, SSL и вопрос, куда именно нужно загрузить файлы, чтобы вместо ошибки наконец появился сайт.
На самом деле размещение большинства обычных сайтов состоит из нескольких понятных действий. Файлы нужно отправить в правильный каталог, базу данных при необходимости перенести отдельно, настройки подключения изменить под новый сервер, а домен направить на хостинг. Сложность возникает не из-за большого количества шагов, а потому, что разные типы сайтов требуют немного разного подхода.
Статическая страница на HTML может заработать через несколько минут после загрузки файлов. WordPress или другая CMS дополнительно требуют базу данных. У готового сайта, который уже работал на другом сервере, появляются старые адреса, настройки PHP, Cron и другие детали. Поэтому перед тем как просто залить весь каталог через FTP, полезно понять, из чего именно состоит проект.
Сначала определите что именно вы переносите на сервер
Фраза загрузить сайт на хостинг звучит так, будто сайт является одним файлом. Иногда почти так и есть, но чаще проект состоит из нескольких частей, которые должны снова встретиться уже на сервере.
Для HTML сайта достаточно файлов
Самый простой случай — статический сайт. В его папке находятся HTML-страницы, CSS, JavaScript, изображения, шрифты и другие ресурсы. Серверу не нужно выполнять PHP или обращаться к базе данных. Он просто отдает посетителю готовые файлы.
Такой проект обычно можно загрузить через файловый менеджер панели хостинга, FTP или SFTP. Главная страница чаще всего называется index.html. Если она находится в корневом каталоге сайта, после подключения домена веб-сервер автоматически открывает ее при переходе на адрес.
Здесь важно сохранить структуру папок. Если файл index.html обращается к изображению по пути images/logo.webp, каталог images должен оказаться на сервере именно там, где его ожидает код.
После загрузки статического проекта полезно открыть несколько внутренних страниц, проверить изображения, стили, JavaScript и мобильную версию. Ошибка в регистре имени файла, незаметная на Windows, на Linux-сервере может внезапно привести к 404. Для сервера Logo.jpg и logo.jpg способны быть двумя разными файлами.
PHP сайту уже нужна подходящая среда
Если в проекте есть файлы .php, одного файлового хранилища недостаточно. Хостинг должен поддерживать PHP и желательно позволять выбирать его версию.
Особенно это важно для старых проектов. Код, написанный много лет назад под PHP 7, может выдавать ошибки на современной версии. Обратная ситуация тоже встречается: новая CMS требует PHP, которого на устаревшем хостинге еще нет.
Перед переносом полезно узнать, какая версия использовалась в рабочей среде. Если сайт сначала разрабатывался локально, ее можно посмотреть в настройках локального сервера или уточнить у разработчика.
Сам PHP-файл загружается почти так же, как HTML. Разница проявляется после запуска: сервер выполняет код, поэтому ошибки конфигурации или несовместимости становятся заметны только при открытии страницы.
CMS обычно означает файлы плюс база данных
WordPress, Joomla, Drupal, OpenCart и многие другие системы хранят содержимое не только в папках.
В файлах находятся ядро CMS, тема, плагины, изображения и программный код. А тексты страниц, настройки, пользователи, товары, заказы и множество других данных могут находиться в MySQL или MariaDB.
Если перенести только файлы WordPress, сайт не станет полноценной копией. Он попытается подключиться к базе по старым реквизитам и, скорее всего, покажет ошибку соединения.
Поэтому перенос CMS нужно воспринимать как синхронную операцию: сначала сохранить файлы и базу, затем загрузить оба компонента на новый хостинг и соединить их новыми настройками.
Как загрузить сайт на хостинг без лишних приключений
После покупки тарифа провайдер обычно создает аккаунт и показывает панель управления. Названия разделов отличаются, но почти везде есть управление файлами, доменами, базами данных, SSL и FTP-доступом.
Самый безопасный способ — сначала разместить сайт, проверить его, а уже потом переключать основной домен. Тогда даже если что-то пойдет не так, рабочая версия проекта продолжит открываться на старом месте.
Найдите корневую папку именно вашего сайта
У разных хостингов она может называться public_html, www, htdocs, domains/example.ru/public_html или иначе. Именно содержимое этой папки веб-сервер показывает посетителю.
Одна из самых распространенных ошибок новичка — загрузить весь архив на уровень выше корневого каталога. Файлы на сервере вроде бы есть, но браузер продолжает показывать стандартную заглушку хостинга.
Другая распространенная ошибка — создать лишнюю вложенность. Например, пользователь загружает папку my-site целиком и в результате главная страница оказывается по пути public_html/my-site/index.html. Домен при этом открывает public_html и не находит нужный index.
Обычно внутрь корневой папки нужно помещать именно содержимое проекта, а не дополнительную внешнюю папку, в которой оно лежало на компьютере.
Для небольшого проекта файлового менеджера вполне хватает
Почти каждая современная панель хостинга имеет браузерный файловый менеджер. Для нескольких десятков файлов это самый простой способ.
Можно создать архив проекта ZIP, загрузить его на сервер и распаковать уже там. Это часто быстрее, чем отправлять тысячи небольших файлов по одному.
После распаковки архив лучше удалить, особенно если внутри находились конфигурационные файлы или другие данные, которые не должны лежать на сервере без необходимости.
Файловый менеджер удобен еще и тем, что не требует отдельной программы. Но при большом проекте, регулярной работе с файлами или слабом соединении FTP и SFTP обычно практичнее.
FTP удобен но SFTP предпочтительнее
Для подключения через специальную программу хостинг выдает адрес сервера, логин, пароль и порт. Эти данные вводятся в FileZilla, WinSCP или другой клиент.
Обычный FTP исторически широко используется на виртуальном хостинге, но он не шифрует соединение так, как современные защищенные варианты. Если провайдер поддерживает SFTP или FTPS, лучше выбирать их.
SFTP работает через SSH и передает данные по защищенному каналу. На VPS это один из стандартных способов работы с файлами. На виртуальном хостинге возможность SFTP зависит от тарифа и панели.
После соединения справа обычно видны каталоги сервера, слева — файлы компьютера. Нужно перейти в корневую папку сайта и загрузить проект туда.
Большие сайты лучше переносить архивом
WordPress с годами способен накопить десятки тысяч изображений, миниатюр, кэшей и служебных файлов. Передавать каждый объект отдельно через FTP может быть очень долго.
Если хостинг позволяет работать с архивами, быстрее упаковать проект в ZIP или tar.gz, отправить один файл и распаковать его на сервере.
При этом кэш старого сайта переносить обычно необязательно. Многие CMS и плагины способны создать его заново. Временные файлы тоже могут только увеличивать объем переноса.
Но удалять незнакомые каталоги перед миграцией наугад не стоит. Лучше сначала сохранить полную копию, а оптимизацией заниматься уже после успешного запуска.
Создайте новую базу данных до импорта
Если сайт использует MySQL или MariaDB, в панели нужно создать базу данных, пользователя и пароль. Иногда пользователь создается автоматически вместе с базой, иногда это отдельный шаг.
Названия на новом хостинге могут отличаться от старых. Например, раньше база называлась wordpress, а новый провайдер автоматически добавляет к имени префикс аккаунта.
Это нормально. Главное — записать четыре параметра: имя базы, имя пользователя, пароль и адрес сервера базы данных. Последний часто равен localhost, но полагаться на это без проверки не стоит.
Старую базу обычно экспортируют в файл .sql через phpMyAdmin, панель хостинга или командную строку. Затем этот файл импортируют в новую базу.
Большая база может не помещаться в лимиты веб-интерфейса. В таком случае пригодится SSH, консольный импорт или помощь технической поддержки.
После импорта нужно изменить реквизиты подключения
Сайт все еще помнит старую базу. Нужно сообщить ему новые параметры.
У WordPress они находятся в wp-config.php. У других CMS используется свой конфигурационный файл. Самостоятельно менять неизвестные параметры не нужно — только те, которые отвечают за подключение к базе.
Если база создана правильно, пользователь имеет необходимые права, а настройки указаны без ошибок, сайт должен начать получать данные уже с нового сервера.
Ошибка соединения с базой после переноса почти всегда означает, что стоит проверить именно имя базы, пользователя, пароль, хост или предоставленные пользователю права.
Файлы уже на сервере но переезд еще не закончен
Самое интересное начинается после успешной загрузки. На этом этапе сайт технически существует на новом хостинге, но пользователи все еще могут попадать на старый сервер, SSL еще не выпущен, а некоторые адреса внутри CMS способны указывать на прежнее окружение.
Сначала проверьте сайт до смены DNS
Если провайдер предоставляет технический домен, временный адрес или возможность предварительного просмотра, этим стоит воспользоваться.
Можно также создать отдельный поддомен и направить его на новую площадку. Например, test.example.ru.
Так появляется возможность спокойно проверить главную страницу, формы, административную часть, изображения, авторизацию и базу данных, пока основной example.ru продолжает работать на старом сервере.
Для серьезного интернет-магазина я бы обязательно проверила создание тестового заказа, отправку писем, поиск, фильтры и другие динамические функции.
Домен подключается отдельно от загрузки файлов
Файлы и домен — две разные части системы.
Можно полностью загрузить сайт на сервер, но пока DNS домена указывает на старый IP, посетители продолжат видеть старую площадку.
Если домен и хостинг находятся у одного провайдера, подключение часто автоматизировано. Когда регистратор другой, обычно требуется заменить NS-серверы или изменить A-запись домена на IP нового хостинга.
Какой вариант использовать, зависит от того, где вы хотите управлять DNS. Смена NS передает управление зоной новому DNS-провайдеру. Изменение только A-записи позволяет оставить остальные записи там, где они находятся сейчас.
Это особенно важно, если у домена уже работает корпоративная почта. Неосторожная смена NS без переноса MX и других записей способна оставить компанию без писем, даже если сам сайт откроется прекрасно.
Обновление DNS происходит не мгновенно
После изменения записи часть пользователей может некоторое время видеть старый сервер, а часть уже новый. DNS-кэши обновляются постепенно.
Поэтому при переносе работающего сайта старый хостинг не стоит отключать в ту же минуту, когда изменен IP.
Я бы оставила обе версии доступными некоторое время и следила за запросами. Для интернет-магазина ситуация сложнее: если заказы могут одновременно попадать в две разные базы, простой параллельный режим уже опасен.
В таких случаях миграцию лучше выполнять в период минимальной активности, временно ограничить изменения данных или использовать более аккуратную схему синхронизации.
После переключения домена включите HTTPS
SSL-сертификат обычно можно выпустить из панели хостинга после того, как домен начал указывать на новый сервер.
Бесплатного Let’s Encrypt для обычного сайта достаточно. Намного важнее настроить автоматическое продление и проверить перенаправление с HTTP на HTTPS.
После переезда откройте не только главную страницу, но и несколько внутренних URL. Браузер не должен показывать предупреждения о безопасности.
Если страница открывается по HTTPS, но часть изображений или скриптов загружается по HTTP, может возникнуть mixed content. Такое часто случается у старых CMS, где абсолютные адреса были сохранены непосредственно в базе.
WordPress может помнить старый адрес
Если сайт переносится не просто между хостингами, а с локального адреса или временного домена на настоящий, внутри базы WordPress могут остаться старые URL.
Простая замена текста в SQL-файле подходит не всегда, потому что некоторые данные WordPress и плагинов хранятся в сериализованном формате. Неаккуратное редактирование способно повредить структуру.
Безопаснее использовать инструмент миграции, WP-CLI search-replace или проверенный плагин, который корректно понимает такие данные.
Если домен при переезде не менялся, массовая замена адресов обычно вообще не требуется.
Проверьте версию PHP и расширения
Ситуация довольно типичная: все файлы загружены, база импортирована, DNS переключен, а вместо сайта появляется белый экран или ошибка 500.
Причина может заключаться в другой версии PHP или отсутствующем расширении.
Если проект работал на PHP 8.1, а новый хостинг автоматически включил 8.4, старый плагин или тема могут оказаться несовместимыми. Временно выбрать прежнюю рабочую версию полезнее, чем сразу исправлять несколько неизвестных проблем одновременно.
После успешного запуска уже можно обновлять CMS, плагины и PHP по отдельности, каждый раз проверяя результат.
Не забудьте про Cron и почту
Некоторые сайты выглядят полностью рабочими после переноса, но через несколько дней обнаруживаются странные проблемы. Не создается автоматический отчет, не запускается импорт, не очищается очередь, не приходит служебное письмо.
Причина часто находится за пределами файлов сайта.
На старом хостинге могли быть настроены задания Cron. Они не переезжают вместе с FTP-каталогом и должны быть созданы заново.
То же касается почтовых ящиков. Если почта обслуживалась старым хостингом и DNS переводится целиком на нового провайдера, нужно заранее решить, где теперь будут храниться ящики и какие MX-записи должны использоваться.
Это одна из причин, почему перед миграцией полезно посмотреть не только содержимое public_html, но и всю панель старого аккаунта.
Когда лучше не загружать сайт самостоятельно
Для небольшой визитки самостоятельная публикация вполне разумна. Так пользователь хотя бы один раз понимает, где находятся файлы, база и DNS, а это сильно помогает при дальнейшей работе.
Но есть проекты, где бесплатный перенос от технической поддержки хостинга ценнее желания сделать все вручную.
Если сайт приносит заказы круглосуточно, содержит большую базу, десятки гигабайтов изображений, несколько поддоменов, отдельную почтовую инфраструктуру и фоновые процессы, ошибка в миграции способна стоить намного дороже самой услуги хостинга.
Многие провайдеры переносят сайты новых клиентов бесплатно. Перед покупкой стоит узнать, входит ли такая услуга в тариф, какие данные нужно предоставить и будет ли специалист переносить только файлы с базой или также почту, Cron и дополнительные настройки.
Даже если перенос выполняет поддержка, я бы все равно заранее сделала собственную резервную копию. Никто не должен начинать миграцию ценного проекта без возможности вернуться к исходному состоянию.
Для нового сайта процедура намного спокойнее. Если проект еще не принимает клиентов, можно экспериментировать, удалять файлы, создавать базу заново и учиться на ошибках без реальных последствий.
Поэтому если вы только собираетесь купить хостинг и впервые разместить сайт, не нужно воспринимать FTP, DNS и MySQL как три разные профессии. Для обычного проекта они соединяются в довольно простой последовательности.
Сначала сайт загружается в корневой каталог. Если есть база данных, она импортируется отдельно и подключается через конфигурацию. Затем проект проверяется на новом сервере. После этого домен направляется на хостинг и выпускается SSL. В самом конце проверяются формы, почта, Cron, резервные копии и несколько важных страниц.
И только когда новая версия действительно работает, старую площадку можно считать ненужной.
Такой порядок немного медленнее варианта загрузить все и сразу переключить домен, зато одна ошибка не превращается в ночное восстановление сайта. При размещении в интернете скорость первого запуска обычно менее важна, чем возможность спокойно исправить проблему до того, как ее увидят посетители.
