Как опубликовать сайт: домен, хостинг, HTTPS и проверка после запуска

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

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

Ниже разберем весь маршрут без привязки к одному хостингу.

Сначала выясните тип проекта.

Статический сайт состоит из HTML, CSS, JavaScript и готовых изображений. Его можно раздавать как файлы через CDN. Даже если проект собран на React или Vue, результат может быть статическим.

Серверное приложение выполняет код на сервере: работает с базой, сессиями, закрытыми ключами и API. Ему нужен runtime, переменные окружения, журналы и способ перезапуска.

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

Посмотрите README и конфигурацию сборки. Определите команду production build и каталог результата, например dist, build или .next. Не загружайте исходники на случайный файловый хостинг, если приложению нужен сервер.

Перед публикацией добейтесь чистой воспроизводимой сборки. Начните с состояния Git:

Команда для этого шага: git status.

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

Проверьте минимум:

• главную и все пункты меню;

• мобильную ширину;

• прямое открытие внутренних адресов;

• отправку форм в тестовый обработчик;

• состояния загрузки и ошибки;

• отсутствие ключей в клиентской сборке;

• адреса API для production;

• размер крупных изображений.

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

Для статического сайта подойдет платформа статического хостинга или объектное хранилище с CDN. Для серверного приложения нужен сервис, который поддерживает ваш runtime, либо VPS с настроенным процессом и обратным прокси.

Сравнивайте не только цену первого месяца. Проверьте:

• поддерживаемую версию runtime;

• способ сборки и запуска;

• переменные окружения и секреты;

• журналы и метрики;

• автоматический HTTPS;

• привязку собственного домена;

• резервные копии данных;

• откат на предыдущую версию;

• регион и ограничения платформы;

• экспорт проекта и данных.

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

Многие платформы умеют собирать сайт из GitHub или другого Git-сервиса. Вы выбираете репозиторий и ветку, задаете команду сборки и каталог публикации.

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

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

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

Локальный .env не должен автоматически попадать в Git. В панели хостинга создайте production-переменные отдельно.

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

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

Если секрет когда-либо попал в публичный репозиторий или клиентский JavaScript, удаление строки не делает его безопасным. Отзовите и выпустите ключ заново у провайдера.

Домен регистрируется у регистратора, а сайт размещается у хостинга. Это могут быть разные компании.

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

Решите, какой адрес будет основным: example.com или www.example.com. Второй можно перенаправить на основной. Также определите нужный поддомен, если API или документация живут отдельно.

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

Чаще всего используются:

• A или AAAA для адреса сервера;

• CNAME для связи поддомена с именем платформы;

• TXT для подтверждения владения;

• записи почты, которые нельзя удалять при настройке сайта.

Копируйте имя, тип и значение точно. Не заменяйте все DNS-записи одним новым набором, если на домене уже работает почта. Изменение nameserver передает управление всей зоной и требует переноса существующих записей.

Обновление DNS не всегда видно мгновенно. Проверяйте результат через dig, nslookup или диагностику панели, но учитывайте TTL и кэш. Не меняйте запись каждые пять минут: так сложнее понять, какое значение распространилось.

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

Дождитесь статуса, что сертификат активен. Проверьте оба варианта адреса:

Проверьте оба адреса: http://example.com должен перенаправлять на защищенный https://example.com.

HTTP должен перенаправлять на HTTPS. Если основной адрес без www, версия с www должна вести туда же или быть явно настроена.

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

После включения HTTPS проверьте mixed content: страница не должна загружать скрипты, изображения или API по http://. Браузер может блокировать такие запросы.

Production отличается от локальной среды. Выполните проверку с чистого браузера или инкогнито и с телефона.

Пройдите маршрут нового пользователя:

1. Откройте домен без сохраненных данных.

2. Перейдите по меню и прямым ссылкам.

3. Отправьте форму и проверьте реальный результат на сервере.

4. Перезагрузите внутреннюю страницу.

5. Откройте несуществующий адрес и посмотрите страницу 404.

6. Проверьте изображения, шрифты и favicon.

7. Посмотрите консоль браузера и сетевые ошибки.

8. Повторите на мобильной сети.

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

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

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

Если сайт хранит данные, настройте резервное копирование отдельно от деплоя кода. Проверьте не только факт создания копии, но и процедуру восстановления.

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

robots.txt управляет обходом, но не является способом скрыть секретную страницу. Закрытая информация требует авторизации. sitemap.xml помогает поисковику находить страницы, однако не компенсирует сломанные внутренние ссылки.

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

Не включайте все preview-окружения в индекс. Защитите их паролем или настройками платформы и используйте canonical осознанно.

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

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

Если домен используется для почты, настройка сайта не должна удалять MX, SPF, DKIM и DMARC. Перед изменением DNS выгрузите текущую зону или сделайте снимок записей. После переключения отправьте и получите тестовое письмо.

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

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

Дальнейший цикл должен быть повторяемым:

Не редактируйте production-файлы вручную, если основной процесс идет из Git. Следующий деплой затрет такие изменения.

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

Если вы хотите пройти весь путь от проекта до сервера и домена, на курсе «Вайбкодинг на максималках» отдельно разбираются GitHub, Docker, VPS, DNS, базы и защита приложения.

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

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