Как развивать сайт на Astro + Cloudflare по функциям

Перед добавлением CMS или поиска к Astro и Cloudflare разделите редакторов, публичные данные и обработку для конкретного пользователя. Начните со статических статей и Functions для отправок или внешних API, проверяя лишь нужные подключения по Cloudflare Pages: Bindings, чтобы ограничить объём внедрения.

Обновление от 26 сентября 2026 года: Эта статья описывает архитектуру июня 2026 года. В более позднем исходном коде CMS сохраняет изменения прямо в main через GitHub App после проверки прав, содержимого и HEAD; переводы выполняются через OpenAI Batch и PR; контактный ИИ обращается к общему Worker через Service Binding. Упоминания ниже перевода Copilot, сохранения CMS через PR и прямых вызовов API ИИ относятся к прежней реализации. Подробности: CMS, переводы, ИИ.

Когда сайт начинается с Astro и Cloudflare Pages, обычно достаточно быстрой и безопасной статической публикации.

Со временем появляются новые задачи: редактирование из браузера, локализованные страницы, навигация через AI-чат, передача контекста услуги в форму и комментарии.

Эта статья служит индексом внедрения: помогает решить, к какому слою относится функция, в каком порядке ее добавлять и какую подробную статью читать дальше. Пример взят с сайта Acecore, но подход переносится на другие сайты Astro + Cloudflare.

Кратко

Роли разделены так:

Слой	Ответственность
Astro	Страницы, блог, OGP, RSS, sitemap и UI
Cloudflare	Pages, Pages Functions, D1 и Turnstile
GitHub	PR, CMS-diff, переводы и история
Sveltia CMS	Японский source, авторы, теги, изображения
OpenAI API	Ответы AI-чата
Pagefind	Индекс поиска для проверенного HTML

То, что можно сделать статическим, остается статическим. Runtime нужен только для небольших API.

Маленькие API на Cloudflare

AI-чат и комментарии используют один паттерн.

Astro рисует UI. Pages Functions держит API-границу. Secrets, D1 bindings, Turnstile, Origin checks и rate limits остаются на серверной стороне.

CMS как интерфейс редактирования

Sveltia CMS не является runtime-базой данных. Он создает Git-изменения.

Японские статьи, авторы, теги, изображения и JSON-тексты проходят через PR, build и review.

Перевод как статический контент

Локализация не сводится к переводу интерфейса в браузере.

Каждый язык получает URL, title, description, OGP, JSON-LD, RSS, sitemap и hreflang.

Каналы обращения разделены

AI-чат помогает выбрать услугу. CTA услуги сохраняет контекст. Форма фиксирует официальное обращение.

Вывод AI не является доверенным HTML

Markdown-ссылки из AI сначала валидируются.

Только ссылки из allowlist становятся DOM-элементами.

Комментарии остаются в Cloudflare

Комментарии не используют внешний виджет.

Pages Functions принимает GET/POST, D1 хранит комментарии, Turnstile защищает отправку.

1. 1 Проверенный статический текст Публиковать проверенные статьи как статический HTML и включать их в индекс Pagefind.
2. 2 Публикации посетителей Комментарии обрабатываются динамическим API и хранилищем; данные форм не включаются в статический поиск. Для индексации нужны модерация и пересборка.
3. 3 Администрирование и среды Не включать администрирование в публичный поиск. Проверять Preview и production отдельно; список настроек не доказывает работу.

Читать по цели

Не нужно сначала читать все подряд. Начните с функции, которую хотите добавить.

Цель	Что читать первым
Редактировать статьи и изображения из браузера	Руководство по внедрению Sveltia CMS
Публиковать индексируемые многоязычные страницы	Как вести многоязычный блог с Sveltia CMS
Направлять посетителей через AI-чат	Технический дизайн AI-чата для обращений
Безопасно рендерить ссылки в ответах AI	Безопасный рендеринг Markdown-ссылок в ответах AI-чата
Передавать контекст услуги в форму	Передача контекста CTA услуги в форму обращения
Добавить комментарии без внешнего сервиса	Комментарии блога Astro только на Cloudflare

Порядок внедрения

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

1. Закрепить статические страницы, блог, RSS, sitemap и OGP в Astro.
2. Добавить Sveltia CMS для редактирования японского source.
3. Генерировать локализованные страницы как статический HTML.
4. Добавить навигацию через AI-чат и CTA услуг.
5. Зафиксировать безопасные границы для Markdown-ссылок, prefill формы, Origin checks и rate limits.
6. Добавить комментарии внутри Cloudflare только тогда, когда они действительно нужны.

Итог

Astro + Cloudflare позволяют расширять корпоративный сайт, не теряя преимуществ статической доставки.

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

Дополнение: разделение сред и настроек сборки Workers

Добавлено 30 сентября 2026 года. Обобщаем улучшения настроек без названий сервисов и внутренних значений. Для нескольких Workers в репозитории сопоставьте каждый файл Wrangler с корнем исходников и целями сборки и развёртывания. Разделение файлов само по себе не доказывает изоляцию.

Проверьте переменные, секреты и подключения D1, R2 и Service Binding для рабочей и тестовой сред. Bindings и переменные сред Worker автоматически не наследуются: объявляйте их отдельно. Отсутствие обязательных настроек должно останавливать обработку, а не незаметно переключать её на рабочие ресурсы. Постоянная staging-среда и Preview для веток или PR — разные процессы.

Определите один путь рабочего выпуска с предварительными проверками. Сборки или загрузки версий вне рабочей среды служат проверке; их успех не означает выпуск в рабочую среду. В Git-сборках проверьте ветку, commit, корень, выбранные настройки, среду и команду развёртывания. Успешная публикация Pages не подтверждает развёртывание отдельного Worker. Проверяйте отдельно CI, рабочую сборку, активные версии и подключения, поведение домена. Это проверки при переносе подхода, а не доказательство изоляции всех сервисов.

См. среды Worker, Builds для нескольких Workers и настройки сборки. Отличайте настройки Pages Functions.

Дополнение: ограничение повторов и изоляция ошибок по источникам

Добавлено 30 сентября 2026 года. Загрузка открытых каналов вроде RSS отличается от публикации RSS. Ограничьте ожидание и число повторов, чтобы временная ошибка не продлевала задачу бесконечно.

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

Дополнение от 6 октября 2026 года: контракт API и границы проверки вложений

В обезличенном изменении исправлен путь, где несоответствие контрактов сессии и лимитов frontend и backend превращало ответ в 503 даже после успешного выполнения операции. HTTP-результат, сохранённое состояние и отображение в интерфейсе сверяются отдельно; повторные запросы клиента обрабатываются так, чтобы не создать двойную запись.

Наличие поля для вложения также не означает, что проверены передача, сохранение и повторное получение реального файла. Одних изменений интерфейса или API недостаточно для такой проверки. Границы между статическим публичным сайтом и закрытым административным интерфейсом описаны в статье Аутентификация и агрегация закрытой панели, а сверка внешних состояний платежей — в статье Управление состояниями webhook.