Хостинг для сайта из Claude в 2026: 3 способа выложить статический проект

Что такое хостинг простыми словами

Я представляю сайт как набор деталей. В него входят HTML, CSS, JavaScript, изображения и другие файлы. Хостинг хранит этот набор на подключённом к интернету компьютере.

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

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

Для простой одностраничной страницы схема выглядит так:

1. Файлы сайта лежат в хостинге.
2. Посетитель открывает публичную ссылку.
3. Браузер получает HTML, CSS и JavaScript.
4. JavaScript собирает интерфейс на экране.

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

Нужен ли отдельный хостинг готовому сайту

Публикация Artifact доступна на тарифах Free, Pro и Max. После публикации любой человек со ссылкой может открыть результат и пользоваться его базовой функциональностью без регистрации Claude.

В документации Anthropic упоминается инфраструктура для AI-powered artifacts, то есть тех, которые вызывают Claude через window.claude.complete(). К статическим HTML-страницам, опубликованным как Artifact, это утверждение не относится: они просто отдаются как статический контент.

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

У готового результата есть несколько вариантов:

• опубликовать Artifact через Claude;
• разместить статические файлы в сервисе публикации;
• использовать отдельную инфраструктуру для приложения с серверной частью.

Публикация Artifact не равна загрузке произвольного набора файлов HTML, CSS и JavaScript. В документации Anthropic есть подтверждение для публикации Artifact, но нет подробной инструкции по загрузке такого набора файлов.

Три способа разместить сайт в интернете

Карта выбора выглядит так:

• GitHub Pages - вариант для обычного index.html или Vite.
• Cloudflare Pages - вариант для обычного HTML, если команда сборки не нужна.
• Surge - вариант с короткой последовательностью команд в терминале.

Сначала определи, что именно собрал ИИ. В проекте может лежать готовый index.html. Может быть исходный Vite-проект, который сначала собирается командой npm run build. Это разные исходные условия.

Если в проекте есть папка dist, она может быть результатом сборки. Но связывать каждый конкретный результат AI-сборки с обязательной папкой или командой нельзя: я не нашёл подтверждения в документации.

Проверь структуру проекта до публикации:

1. Найди index.html.
2. Проверь, есть ли package.json.
3. Посмотри команды в разделе scripts.
4. Уточни, какая папка появляется после сборки.
5. Не публикуй секреты из .env и браузерного JavaScript.

Платные тарифы и лимиты трёх сервисов я не проверял. Поэтому ниже нет обещаний о цене, трафике, количестве сайтов или сроке хранения.

Можно ли выложить сайт бесплатно: что подтверждено документацией

Публикация Artifact доступна на Free, Pro и Max. В документации Claude тариф Free указан как $0, а Pro стоит $20 в месяц или $200 в год. Это цена тарифа Claude, а не отдельная цена публикации сайта: цены хостинга я не проверял.

Документация описывает публикацию так:

«Makes your artifact publicly available. Anyone with the link can view and interact with it.»

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

• Anthropic, Publish and share Artifacts

Для статической страницы подходят GitHub Pages, Cloudflare Pages и Surge. Фактура не подтверждает стоимость этих сервисов и не даёт точных бесплатных лимитов.

Поэтому безопасная формулировка такая:

• Artifact можно опубликовать на Free.
• Статический сайт можно разместить через один из трёх выбранных сервисов.
• Отдельная плата именно за публикацию Artifact не указана.
• Бесплатный домен не обещан.
• Лимиты трафика и срок жизни ссылки я не проверял, в документации их нет.

Посетителю не обязательно регистрироваться в Claude. Опубликованный Artifact можно открыть без регистрации и использовать его базовую функциональность.

Для каких сайтов подходит размещение HTML-файлов

Anthropic относит к Artifacts одностраничные HTML-сайты и интерактивные React-компоненты. Это подтверждает базовый сценарий для одностраничного сайта.

Обычный статический результат может выглядеть так:

index.html
style.css
script.js

В другой структуре исходники могут собираться через Vite. Тогда в проекте есть package.json, а результат появляется после команды сборки. Для таких проектов в фактуре указан GitHub Pages.

Разница между двумя случаями:

• index.html уже готов для публикации;
• Vite-проект сначала собирается, затем публикуется результат сборки;
• приложение с backend требует места, где этот backend будет выполняться;
• JavaScript в браузере не должен содержать секретный API-ключ.

Отдельной подтверждённой инструкции по загрузке набора HTML, CSS и JavaScript в Anthropic я не нашёл. Поэтому не стоит обещать, что папку можно просто перетащить в Claude и получить самостоятельную публичную ссылку.

Посмотри структуру текущего проекта и ответь только по фактам из файлов:

1. Есть ли готовый index.html в корне или во вложенной папке?
2. Есть ли package.json?
3. Какая команда сборки указана в package.json?
4. Какая папка создаётся после сборки?
5. Есть ли backend, API или обращения к localhost?
6. Есть ли секреты или API-ключи в браузерном коде?

Не меняй файлы. Не запускай публикацию. В конце выбери один вариант:
- GitHub Pages
- Cloudflare Pages
- Surge
- нужен отдельный backend

Для каждого вывода укажи конкретный файл или команду, на которой он основан.

GitHub Pages: разместить index.html или Vite

В найденном примере Vite-приложение собирается локально командой npm run build, после чего файлы отправляются в GitHub. Дополнительный CI не нужен, если публиковать ветку напрямую.

Последовательность настройки Pages в источнике выглядит так:

1. Open the repo on Github.com
2. Go to the Settings tab
3. Find the Pages section
4. Make sure that Source is Deploy from a branch
5. Below, set Branch to main
6. Click Save and wait a few minutes!

По-русски:

1. Открой репозиторий на GitHub.com.
2. Перейди во вкладку Settings.
3. Найди раздел Pages.
4. Выбери источник Deploy from a branch.
5. Укажи ветку main.
6. Нажми Save и дождись публикации.

Для Vite в примере также используется настройка базового пути:

export default defineConfig({
  build: { outDir: '..' },
  base: '/your-repo-name-here/',
});

Вместо your-repo-name-here в такой настройке указывают имя репозитория. Сам факт настройки зависит от структуры конкретного проекта. Готовой полной инструкции от регистрации GitHub до первой ссылки в фактуре нет.

Cloudflare Pages: опубликовать обычный HTML

Этот способ относится к статическому сайту. Если готовому HTML не нужна команда сборки, поле build command не заполняется. Корневую папку проекта нужно указать так, чтобы сервис видел нужные файлы.

Общая схема из фактуры:

1. Выбрать проект для публикации.
2. Указать корень проекта.
3. Не задавать build command для обычного HTML.
4. Нажать Save and Deploy.

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

Если HTML лежит не в корне репозитория, не подставляй путь наугад. Я ошибался с корневой папкой, и хостинг не видел index.html или собирал не тот каталог.

Как выложить сайт через Surge

1. Установи Surge глобально

   Команда добавит CLI-инструмент для публикации из терминала.

   bash

   Скопировать

   npm i -g surge

2. Собери проект командой

   Выполни сборку из папки проекта.

   bash

   Скопировать

   npm run build

3. Опубликуй папку dist

   Передай Surge каталог с результатом сборки.

   bash

   Скопировать

   surge dist

Команды нужно выполнять именно в таком порядке: сначала установить Surge, затем собрать проект, затем опубликовать dist.

Если после npm run build папка dist не появилась, не меняй команду публикации случайным образом. Сначала проверь фактический результат сборки и настройки проекта. В документации для Surge указан именно каталог dist.

Практикум помогает пройти публикацию руками: увидеть структуру результата AI-сборки, проверить команду сборки и не потерять рабочий сайт при изменениях. ?utm_source=article&utm_campaign=kuda-vylozhit-sajt&utm_content=text-cta

Как выбрать способ для статического сайта

Сравнение трёх вариантов:

Я выбираю GitHub Pages, если результат уже связан с репозиторием GitHub или собран как Vite-сайт. В найденном примере это названо простым вариантом.

Выбирай Cloudflare Pages, если перед тобой обычный HTML и команда сборки не нужна. Здесь критично правильно указать корень проекта.

Выбирай Surge, если нужен короткий сценарий через терминал и результат сборки лежит в dist.

Не выбирай способ только по слову «бесплатный». Точные цены и лимиты трёх сервисов не подтверждены фактурой. Сначала проверь структуру проекта и способ, которым получен готовый результат.

Почему сайт работает на компьютере, но ломается по ссылке

Локально сайт может обращаться к адресу вроде localhost:8000/api/v1/.... На твоём компьютере этот адрес ведёт к запущенному API. После публикации браузер посетителя пытается найти тот же API на своём компьютере. Так теряется контекст: серверная часть осталась на твоей машине, а фронтенд ушёл в публичный доступ.

В источнике проблема описана так:

Если API работает на том же домене, используй относительный путь вроде /api/users. Если backend опубликован отдельно, укажи его опубликованный HTTPS-адрес в переменной окружения Production.

У этой ошибки есть несколько соседних причин.

Почему переменная окружения не попала на хостинг?

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

На примере Vercel порядок проверки такой:

1. Открой настройки проекта.
2. Добавь переменную в Production или нужное окружение.
3. Запусти новый деплой.
4. Проверь точное имя переменной, включая регистр и подчёркивания.

Документация Vercel говорит:

Почему CORS работает локально, но не на продакшене?

CORS настраивается на сервере, к которому обращается браузер. Если сайт вызывает API на другом домене, разрешающий заголовок должен вернуть именно API.

Если backend принадлежит одному проекту, используй относительный путь /api/.... Если backend свой, настрой CORS-заголовки и обработку OPTIONS на backend. Если API чужой и запрещает запросы из браузера, нужен серверный вызов через собственный API route или serverless function.

AI-ключ попал в браузерный код

Секретный API-ключ нельзя оставлять в JavaScript фронтенда. Всё, что попало в браузерный код, можно посмотреть через DevTools или скачать.

Vercel формулирует правило так:

Храни ключ в переменной окружения на хостинге. Вызывай AI-провайдера из serverless function, API route или backend. Фронтенду отдавай только результат. Если ключ уже попал в опубликованный код, отзови его и выпусти новый.

Что проверить, если опубликованный сайт не открывается правильно

При обновлении вложенной страницы появляется 404

У SPA может не быть физического файла для адреса /about. При переходе через меню маршрут обрабатывает уже загруженный JavaScript. При обновлении страницы хостинг ищет настоящий файл /about и возвращает 404.

В SPA физически есть только один index.html, а все остальные маршруты обрабатывает JavaScript на стороне клиента. При обновлении страницы хостинг пытается найти файл, соответствующий адресу, и не находит его.

Для такого сценария нужен rewrite неизвестных адресов на index.html. Конкретный файл зависит от хостинга. Например, в Vercel правило задаётся в vercel.json в корне проекта:

{
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/index.html"
    }
  ]
}

Хостинг ищет неправильную папку сборки

Сначала локально выполни npm run build. Затем посмотри, какая папка появилась. В фактуре указаны распространённые варианты dist для Vite и build для Create React App.

В настройках хостинга укажи эту папку относительно Root Directory. Не дублируй имя папки в base, publish и Output Directory.

В репозитории есть client и server

Если package.json и исходники лежат в client, а хостинг собирает корень репозитория, он может не найти нужное приложение. Отдельный репозиторий для каждой папки не нужен.

Для Vercel в настройках Build and Deployment укажи:

Root Directory: client

После этого проверь Build Command, Install Command и Output Directory относительно папки client.

Рабочая ссылка сервиса есть, а домен не открывается

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

На примере Vercel порядок проверки такой:

1. Добавь домен в Settings -> Domains.
2. Настрой A-запись, которую показывает сервис.
3. Для www настрой CNAME из карточки домена.
4. Добавь оба варианта домена, если нужны example.com и www.example.com.
5. Удали конфликтующие A-записи.
6. Дождись распространения DNS.

Браузер показывает старую версию

После нового деплоя браузер может использовать старый HTML или старые ссылки на JavaScript-файлы. Открой уникальный URL конкретного деплоя, сделай hard refresh и проверь сайт в приватном окне или другом браузере.

Также проверь, что в панели сервиса выбран последний Production deployment.

Вопросы и ответы