Как выложить сайт на хостинг и проверить, что видна новая версия

Вопрос «как выложить сайт на хостинг» начинается с типа проекта. Простая статическая страница может открываться прямо из папки веб‑сервера. Приложение Next.js требует сборки и работающего процесса. Python-сервису нужен собственный запуск, а база данных и загружаемые файлы живут отдельно от кода. Поэтому первая проверка перед выкладкой: что именно должно оказаться на сервере и какой процесс обслуживает запросы.

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

Что проверить до копирования файлов

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

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

git status --short
git fetch origin
git status --short --branch
npm audit --omit=dev --audit-level=high
npm run build

Пример относится к проекту с Git и Node.js. git fetch только получает сведения об удалённой истории; после него всё равно нужно сравнить ветки и прочитать изменения. Не запускайте автоматическое слияние в папке с неразобранными локальными правками. Если проект без Git, сохраните копию исходников и сравните её с тем, что работает на сервере.

Перед отправкой отметьте в своём проекте:

• Какие папки создаёт сборка и какие нужны службе.
• Где лежат загружаемые пользователями файлы.
• Какая копия вернёт прежнюю версию при ошибке.
• Какой адрес покажет новую правку после запуска.

Как доставить файлы без лишнего

Передавайте только то, что требуется выбранной схеме. Для статического сайта это готовые HTML, CSS, JavaScript и изображения. Для приложения часть файлов может создаваться сборкой, часть лежать в public, а зависимости устанавливаться на сервере. Никогда не копируйте рабочую папку целиком вместе с .git, локальным node_modules, временным кешем и секретами. Список исключений нужен до первой отправки, особенно если в команде используется удаление старых файлов.

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

rsync -azn --exclude '.git' --exclude 'node_modules' --exclude '.env*' out/ user@example.org:/var/www/site/
rsync -az --exclude '.git' --exclude 'node_modules' --exclude '.env*' out/ user@example.org:/var/www/site/

Для Next.js папка out/ появляется только в подходящей схеме статического экспорта; обычный серверный Next.js так не публикуют. Проверьте конфигурацию своего проекта: где собирается .next, как ставятся зависимости и какая служба запускает приложение. В моём сайте сборка выполняется локально, затем готовые файлы передаются на VPS, служба перезапускается и проверяются публичные адреса. Это решение связано с ресурсами сервера; его нельзя бездумно копировать для любого сайта.

Что делать после передачи

Серверное приложение должно слушать 127.0.0.1; внешние запросы принимает nginx и передаёт их внутрь. Службу запускайте от отдельного пользователя с нужными правами, не от root. Эти правила проверьте до первого публичного ответа. Если приложение работает как служба, проверьте её состояние и свежий журнал после перезапуска. Ошибка прав на файл, отсутствующая переменная или неверная версия зависимости часто видны там сразу. Затем проверьте HTTP-ответ через публичный домен. Начните с главной и одной изменённой страницы, после этого откройте форму, изображения и важный API‑маршрут без секретных данных. Для сайта со статьями проверьте также карту сайта.

ssh user@example.org 'systemctl status site --no‑pager'
ssh user@example.org 'journalctl -u site -n 50 --no‑pager'
curl -I https://example.org/
curl -I https://example.org/changed-page

Подставьте реальные службу и домен. curl -I запрашивает заголовки, поэтому для сценария формы нужен отдельный безопасный тест. Ответ 200 показывает, что адрес открылся, но не гарантирует новую версию. Добавьте проверяемый маркер изменения: заголовок, конкретный блок или номер сборки, который виден в HTML. Сравните его с исходниками, отправленной сборкой и ответом сервера.

Исходник → сборка → переданные файлы → процесс → nginx → публичный ответ → браузер

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

Как понять, почему пользователь не видит изменение

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

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

Что записать после первой выкладки

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

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

Частые вопросы

Можно ли просто загрузить папку проекта через FTP?

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

Надо ли копировать node_modules на VPS?

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

Почему главная страница открывается, а новая нет?

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

Что делать, если после выкладки пользователь видит старое?

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

Когда нужен откат?

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

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