Как опубликовать HTML-сайт на своём домене и убедиться, что заявки доходят

Перед началом

Сайт открылся — это только первая проверка. Можно увидеть красивую главную страницу и не заметить, что картинки пропали, ссылка на услугу ведёт в ошибку, а форма рисует «Спасибо», ничего не отправляя. Ниже — порядок запуска готового HTML-сайта с проверкой результата.

Инструкция подходит, если вы публикуете готовые HTML, CSS, JavaScript и изображения. Она не заменяет запуск WordPress с базой данных или серверного приложения. Названия кнопок и папок зависят от выбранного провайдера; здесь описаны действия и результат, который нужно получить.

Сохраните исходную копию и найдите папку публикации

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

У готового простого сайта структура может выглядеть так:

site/
index.html
services.html
assets/
style.css
main.js
logo.svg

Это учебная структура, не архив уже испытанного клиентского проекта. В корне публикации должен оказаться index.html, рядом — нужные ему файлы и папки.

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

Не публикуйте .env, резервные копии базы, закрытые документы и токены. Любой ключ в JavaScript, который получает браузер, доступен посетителю. Секрет для отправки писем нельзя прятать в клиентском коде.

Выясните, что делает форма

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

Три разных случая:
— mailto: открывает почтовую программу посетителя; это не серверная отправка;
— внешний сервис формы принимает запрос по своим правилам и лимитам;
— собственный обработчик требует совместимой серверной среды и настройки.

Если обработчика нет, публикация файлов его не создаст. Не включайте рекламу на страницу с формой, пока не определили маршрут заявки.

Добавьте сайт и загрузите файлы

В панели размещения создайте сайт для нужного домена или отдельный проект на статической платформе. Найдите корневую папку именно этого сайта. Она может называться public_html, www или иначе — ориентируйтесь на настройки проекта, а не на чужой скриншот.

Загрузите содержимое папки публикации, сохранив вложенность. Частая ошибка — распаковать архив так, что получится public_html/site/index.html вместо public_html/index.html. Посетитель главной страницы тогда может увидеть ошибку или страницу-заглушку.

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

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

Подключите домен, сохранив почту

Получите у выбранного провайдера точные DNS-записи для своего проекта. Для обычного сервера это могут быть A/AAAA, для платформы — CNAME или другой поддерживаемый способ. Не копируйте IP из примера в статье.

Перед изменением сохраните текущую DNS-зону. Обратите внимание на MX и почтовые TXT-записи: они нужны для работы почты. Также могут существовать записи проверки владения сервисами.

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

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

Включите HTTPS и выберите основной адрес

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

Выберите один основной адрес: например, https://example.ru. Настройте переход с HTTP и другого варианта имени на него. После открытия страницы проверьте консоль браузера: HTTP-ссылки на скрипты, стили и другие ресурсы могут вызывать ошибки смешанного содержимого.

Замок в адресной строке подтверждает защищённое соединение, но не проверяет работоспособность формы и достоверность содержимого сайта.

Проверьте страницы и файлы

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

В инструментах разработчика откройте вкладку Network, перезагрузите страницу и найдите неудачные запросы. Страница, CSS, JavaScript и изображения должны возвращать ожидаемое содержимое. Ответ 200 с HTML вместо файла JavaScript всё равно означает неисправность.

Если картинки пропали, сравните регистр имён: Logo.svg и logo.svg на сервере могут быть разными файлами. Проверьте пути и вложенность. Путь /assets/logo.svg начинается от корня домена; при публикации проекта во вложенной папке это может оказаться другим адресом.

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

Проверяем на учебном примере: две ошибки, одна исправная главная

Мы подготовили две версии небольшой HTML-страницы. Одна опубликована во вложенной папке /broken/, другая — в /fixed/. Здесь нет CMS и базы данных. Главная и внутренняя страницы в обеих версиях возвращают HTTP 200, но у первой версии стили и логотип не загружаются.

Причина 1. В коде написано href="/assets/style.css". Начальный слеш отправляет запрос в корень сервера: /assets/style.css. Но файл лежит в папке проекта — /broken/assets/style.css. Для этой структуры исправление — href="./assets/style.css".

Причина 2. В разметке написано src="./assets/Logo.svg", а файл называется logo.svg. На сервере, различающем регистр, это разные имена. Исправление — src="./assets/logo.svg".

Результат локальной HTTP-проверки 03.11.2026:
— До исправления: CSS — 404, логотип — 404; главная страница — 200.
— После исправления: CSS — 200 с типом text/css, логотип — 200 с типом image/svg+xml.
— Внутренняя страница открывается напрямую; отсутствующая страница возвращает 404.

Проверка воспроизводится командой python3 verify.py из архива примера. Обработчик специально проверяет точное написание имён даже на macOS, чтобы результат не зависел от локальной файловой системы. Сервер работает только локально и останавливается после проверки. Это учебный стенд, а не отчёт об испытании хостера. DNS, HTTPS, внешний браузер и доставка заявок этим запуском не проверялись.

Не исправляйте все адреса на относительные автоматически. /assets/style.css — корректный адрес, если ресурс действительно расположен в корне домена. Ошибка возникает при несовпадении ссылки и структуры публикации.

Главный вывод из примера: HTTP 200 у главной страницы не означает, что сайт опубликован правильно. Проверяйте запросы ресурсов отдельно. А для формы нужна ещё одна независимая проверка — доставка сообщения получателю.

Отправьте заявку и найдите её у получателя

Используйте собственные тестовые контакты и уникальную пометку, например TEST-0311-A. Проверьте всю цепочку:
1) браузер отправил запрос;
2) обработчик принял его без ошибки;
3) письмо или запись появилась в нужном ящике либо CRM;
4) содержание и контакты не потерялись;
5) повторная отправка и ошибка соединения не дают ложного сообщения об успехе.

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

Зафиксируйте, какой аккаунт обслуживает форму, кто имеет к нему доступ и что произойдёт при исчерпании лимита. Это особенно важно при передаче сайта от разработчика владельцу.

Подготовьте сайт к обнаружению поиском

Убедитесь, что после тестового запуска не осталось запрета индексации через meta robots или HTTP-заголовок. Проверьте robots.txt и основной адрес в canonical. Если sitemap создан, проверьте, что в нём опубликованные адреса вашего домена, а не адрес предпросмотра.

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

Запишите результат запуска

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

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

Если размещение ещё не выбрано, сначала прочитайте «Где разместить готовый сайт из архива или GitHub». Для обычного HTML-сайта начинайте со статического или совместимого обычного хостинга. VPS выбирайте при понятной технической необходимости и с ответственным за эксплуатацию.