Como projetar um site Astro + Cloudflare que cresce por funcionalidade

Antes de adicionar CMS ou busca ao Astro e Cloudflare, diferencie editores, dados públicos e processamento por usuário. Comece com artigos estáticos e Functions para envios ou APIs externas; confira apenas as conexões necessárias em Cloudflare Pages: Bindings para limitar o escopo.

Atualização de 26 de setembro de 2026: Este artigo registra a arquitetura de junho de 2026. No código posterior, o CMS grava diretamente em main por meio de um GitHub App após verificar permissões, conteúdo e HEAD; as traduções usam OpenAI Batch e PRs; e a IA de contato chama um Worker compartilhado via Service Binding. As referências abaixo à tradução com Copilot, ao salvamento do CMS por PR e às chamadas diretas à API de IA descrevem a implementação anterior. Consulte os guias de CMS, tradução e IA.

Ao começar com Astro e Cloudflare Pages, normalmente basta publicar páginas estáticas rápidas e seguras.

Depois surgem novas necessidades: edição pelo navegador, páginas localizadas, orientação com chat de IA, contexto do serviço no formulário e comentários.

Este artigo é um índice de implementação: ajuda a decidir em qual camada cada função fica, em que ordem adicionar e qual guia detalhado ler depois. O exemplo é o site da Acecore, mas o padrão funciona em outros sites Astro + Cloudflare.

Resumo

A arquitetura separa responsabilidades:

Camada	Responsabilidade
Astro	Páginas, blog, OGP, RSS, sitemap e UI
Cloudflare	Pages, Pages Functions, D1 e Turnstile
GitHub	PRs, diffs de CMS, traduções e histórico
Sveltia CMS	Fonte japonesa, autores, tags e imagens
OpenAI API	Respostas do chat de contato
Pagefind	Índice de busca para HTML revisado

O que pode ser estático fica estático. O que precisa de runtime vai para pequenas APIs.

APIs pequenas no Cloudflare

Chat com IA e comentários seguem o mesmo padrão.

Astro renderiza a UI. Pages Functions cuida da fronteira de API. Secrets, bindings D1, Turnstile, Origin checks e rate limit ficam fora do navegador.

CMS como interface de edição

Sveltia CMS não é banco de dados em runtime. Ele cria mudanças no Git.

Conteúdo japonês, autores, tags, imagens e JSON passam por PR, build e review antes de produção.

Tradução como conteúdo estático

Localização não é só traduzir a tela no navegador.

Cada idioma tem URL, title, description, OGP, JSON-LD, RSS, sitemap e hreflang próprios.

Canais de contato separados

O chat com IA ajuda quem ainda está escolhendo. O CTA de serviço preserva contexto. O formulário registra a consulta formal.

Cada um tem uma função.

Saída de IA não é HTML confiável

Links Markdown vindos da IA são tratados como texto até serem validados.

Só links permitidos por allowlist viram nós DOM seguros.

Comentários dentro do Cloudflare

Os comentários não usam widget externo.

Pages Functions recebe GET/POST, D1 guarda comentários e Turnstile protege envios. Para um blog institucional pequeno, isso é suficiente.

1. 1 Conteúdo estático revisado Publique artigos revisados como HTML estático e inclua-os no índice Pagefind.
2. 2 Envios de visitantes Comentários usam uma API dinâmica e armazenamento; não misture formulários ou outros dados na busca estática. Indexar exige moderação e nova geração.
3. 3 Administração e ambientes Mantenha a administração fora da busca pública. Verifique Preview e produção separadamente; configuração não comprova execução.

Ler por objetivo

Não é preciso ler tudo primeiro. Comece pela função que você quer adicionar.

Objetivo	Leia primeiro
Editar artigos e imagens pelo navegador	Guia de instalação do Sveltia CMS
Publicar páginas multilíngues indexáveis	Como operar um blog multilíngue com Sveltia CMS
Orientar visitantes com chat de IA	Design técnico do chat de contato com IA
Renderizar links seguros em respostas de IA	Renderização segura de links Markdown em respostas de IA
Levar contexto do serviço ao formulário	Passar contexto do CTA para o formulário
Adicionar comentários sem serviço externo	Comentários de blog Astro usando só Cloudflare

Ordem de implementação

Para um site parecido, a ordem prática é:

1. Consolidar páginas estáticas, blog, RSS, sitemap e OGP com Astro.
2. Adicionar Sveltia CMS para editar a fonte japonesa.
3. Gerar páginas localizadas como HTML estático.
4. Adicionar orientação com chat de IA e CTAs de serviço.
5. Proteger links Markdown, prefill de formulário, Origin checks e rate limits.
6. Adicionar comentários dentro do Cloudflare só quando forem necessários.

Conclusão

Astro + Cloudflare permite ampliar um site institucional sem perder as vantagens da entrega estática.

Use esta página como entrada e adicione apenas as partes que seu site precisa, sem enfraquecer a base estática.

Complemento: separar ambientes e configuração de build dos Workers

Adicionado em 30 de setembro de 2026. Generalizamos melhorias de configuração sem nomes de serviços ou ajustes internos. Com vários Workers no mesmo repositório, relacione cada configuração Wrangler à raiz do código e aos destinos de build e deploy. Arquivos separados não comprovam isolamento.

Confira variáveis, segredos e destinos de D1, R2 e Service Binding em produção e testes. Bindings e variáveis dos ambientes Worker não são herdados automaticamente: declare-os por ambiente. A falta de configuração obrigatória deve interromper o processamento, sem recorrer silenciosamente à produção. Staging persistente e Previews por branch ou PR são fluxos distintos.

Defina um único caminho de publicação em produção e exija verificações prévias. Builds ou versões não produtivos servem para validação; o sucesso não os promove à produção. Nos builds Git, confira branch, commit, raiz, configuração, ambiente e comando de deploy. Uma publicação Pages bem-sucedida não comprova o deploy de outro Worker. Verifique CI, build de produção, versões e conexões ativas e comportamento no domínio separadamente. São verificações para adaptar o projeto, não prova de isolamento de todos os serviços.

Veja ambientes Worker, Builds com vários Workers e configuração de Builds. Distinga a configuração de Pages Functions.

Complemento: limitar novas tentativas e isolar falhas por fonte

Adicionado em 30 de setembro de 2026. Importar feeds públicos como RSS é uma operação diferente de publicar RSS. Limite a espera e as tentativas para que uma falha temporária não mantenha o trabalho ativo indefinidamente.

Trate as fontes separadamente. Uma falha não deve interromper entradas que possam ser atualizadas de forma independente. Não apresente sucesso parcial como total: mantenha resultados por fonte e falhas pendentes no relatório. Confira obtenção, dados gerados, builds de produção e páginas públicas separadamente. São verificações gerais, não prova de todas as condições de falha ou de futuras integrações.

Atualização de 6 de outubro de 2026: contrato da API e escopo da verificação de anexos

Em uma alteração anonimizada, foi corrigido um caminho em que a divergência entre os contratos de sessão e limite do frontend e do backend transformava a resposta em 503 mesmo após a operação ter sido concluída com sucesso. O resultado HTTP, o estado salvo e a exibição na interface são conferidos separadamente; novas tentativas do cliente são tratadas para não duplicar uma gravação.

A exibição de um campo de anexo também não significa que a transferência, o armazenamento e a recuperação do arquivo real tenham sido verificados. Uma mudança apenas na interface ou na API não conclui essa verificação. Os limites entre um site público estático e uma interface administrativa privada são descritos em Autenticação e agregação do painel privado; a conciliação de estados externos de pagamento está em Gestão de estados de webhook.