Era para ser só um link
Resposta curta: você não precisa do GitHub Actions para publicar no Cloudflare Pages. Se o seu projeto do Pages está conectado ao GitHub, o próprio Cloudflare faz o build e publica a cada push. Se é um projeto de Direct Upload (envio direto), você faz o build do site inteiro e sobe o resultado com o Wrangler. Foi assim que eu aprendi, dando muita volta.
A tarefa era bem pequena. Para passar na análise de um programa de afiliados, eu precisava colocar um único link de um HD externo num artigo de verdade. Antes do link vinha um aviso claro: "Esta página tem links de afiliado, e o dono do site pode ganhar uma comissão se você comprar". Criei o link, coloquei no artigo e fiz o commit no GitHub.
Pronto, pensei.
Só que, assim que o código chegou ao GitHub, apareceu um mal-entendido.
Código no GitHub não quer dizer página publicada na internet.
O GitHub Actions, que eu usava normalmente, não estava disponível. Alguém sugeriu interceptar só aquela URL com um Cloudflare Worker e servir a página por ali. Mas, pelas condições de uso desta vez, esse caminho também não dava.
Eu só queria colocar um link e, de repente, estava numa reunião de deploy: "E o CI? E o Worker? O Pages está ligado ao Git ou é Direct Upload?".
Assim começou a obra da Sagrada Família dos afiliados, prédio n.º 2.
Mas, quando você separa cada peça, o problema fica bem mais simples.
1. Por que primeiro precisava existir uma página pública
O Sovrn Commerce orienta sites de conteúdo e blogs a primeiro colocar links do Commerce no site e gerar alguns cliques. Só depois a campanha entra em análise.[3]
Ou seja, não é "aprova e depois você coloca os links". Quem analisa precisa ver antes um exemplo real funcionando.
O Sovrn também pede que cada página com links de afiliado avise claramente os leitores de que você pode ganhar dinheiro com eles. Esse aviso tem que aparecer antes do link ou da divulgação.[4]
Não precisa de um site de comparação de produtos cheio de firula. A lista é curta:
- existe um artigo de verdade no site cadastrado;
- esse artigo tem o link de afiliado;
- o aviso aparece antes do link;
- qualquer pessoa consegue abrir a página pela URL pública;
- depois de publicar, dá para gerar alguns cliques de teste.
O ponto principal é o penúltimo item: um arquivo num repositório do GitHub ainda não é uma página pública.
2. GitHub Actions fora do ar não quer dizer Cloudflare Pages fora do ar
O GitHub Actions é a ferramenta de automação (CI/CD) do GitHub. Ele roda builds, testes e deploys dentro do GitHub.
Já o Cloudflare Pages tem a sua própria integração com Git. Você conecta o projeto do Pages direto ao GitHub ou ao GitLab e, a cada push nesse repositório, o Cloudflare faz o build e publica sozinho.[1]
O fluxo fica assim:
push no GitHub → o Cloudflare Pages percebe o commit → o Cloudflare faz o build → o Cloudflare publica
Nessa cadeia não aparece nenhum workflow do GitHub Actions.
Esse é o ponto-chave. "Não dá para usar o GitHub Actions" não é o mesmo que "o GitHub não consegue publicar no Cloudflare". São coisas diferentes.
Pense assim: o GitHub Actions é a esteira dentro do seu próprio depósito. A integração com Git do Cloudflare é uma transportadora que vem buscar o pacote ela mesma.
A esteira pode estar parada e a transportadora passa para buscar do mesmo jeito.
3. Primeiro, descubra que tipo de projeto do Pages você tem
Se você pular essa etapa, o Cloudflare Pages vira um labirinto rapidinho.
Existem duas formas principais de publicar:
| Tipo | O que dispara | Quem faz o build e publica | Ideal para |
|---|---|---|---|
| Integração com Git (Git integration) | um push no GitHub / GitLab | Cloudflare | o repositório é a versão oficial e você quer publicar automaticamente |
| Direct Upload (envio direto) | arquivos já prontos do build | Wrangler ou o painel | você faz o build no seu computador ou em outro CI e sobe o resultado |
A documentação oficial do Cloudflare deixa claro um detalhe: um projeto criado com integração com Git não pode virar depois um projeto comum de Direct Upload. Mesmo assim, dá para fazer um deploy manual com o Wrangler num projeto ligado ao Git, mas não dá para usar o arrastar e soltar do painel.[1][2]
O contrário também vale. Num projeto que começou como Direct Upload não dá para adicionar a integração com Git depois. Se você quer deploy automático pelo Git, precisa de um projeto novo do Pages.[2]
Por isso, a primeira pergunta não é "como eu faço o deploy?".
É esta: "O meu projeto atual do Pages é de integração com Git ou de Direct Upload?"
Com essa resposta, metade das opções some.
4. Se for integração com Git, não precisa ressuscitar o GitHub Actions
Se o seu repositório do GitHub já está bem conectado ao Cloudflare Pages, o caminho mais curto não é um Worker nem um CI novo.
Confira isto no seu projeto do Pages:
- está conectado ao repositório certo do GitHub;
- a branch de produção é a branch que você quer mesmo publicar;
- os builds automáticos da branch de produção não estão pausados;
- o comando de build e a pasta de saída batem com o projeto atual;
- depois de um push, aparece um deploy novo na tela Deployments do Pages;
- o conteúdo novo aparece no seu endereço
pages.dev; - no fim, o seu domínio próprio mostra o mesmo conteúdo novo.
A integração com Git do Cloudflare faz o build e publica a partir dos commits da branch conectada.[1]
Então, mesmo com o GitHub Actions fora por um tempo, dá para continuar publicando enquanto o build do próprio Cloudflare estiver funcionando.
A tarefa aqui não é montar outro sistema complicado. É ver se a porta de coleta do Cloudflare já está aberta.
5. Se for Direct Upload, suba o build completo, não uma página solta
Direct Upload significa entregar ao Cloudflare Pages um conjunto pronto de arquivos estáticos. A documentação oficial explica como subir arquivos já gerados com o Wrangler ou pelo painel.[2]
Aqui aparece um atalho perigoso:
"Só mudei um artigo. Por que não subo só esse HTML?"
Se o seu site estático é gerado inteiro de uma vez, é melhor evitar.
O que você publica não é "o arquivo que mudou no Git", e sim o resultado completo do build do site naquele momento. Um build costuma gerar de novo listas de páginas, CSS, JavaScript, índices de busca, imagens e regras de rota. Se você enfia uma página na mão, o site no ar deixa de bater com o repositório.
Com Direct Upload, o fluxo básico é:
puxar a versão mais recente → rodar o comando de build do projeto → conferir a pasta de saída → publicar todo o resultado → checar a URL no ar
Por exemplo, num site estático feito com Node, você roda o comando do próprio projeto, como pnpm build, e sobe a pasta gerada, como dist.
O importante é que o site em produção não vire um mundo paralelo misterioso que alguém editou na mão.
6. Se não dá para usar Worker, tire ele do plano
Se você precisa publicar uma página com urgência, interceptar essa rota com um Worker pode funcionar em teoria.
Mas, se as condições de uso não permitem Workers, como neste caso, não faz sentido montar o plano em volta disso.
Cada caminho de "talvez dê" que fica no desenho deixa tudo mais difícil de manter.
- GitHub Actions: indisponível
- Worker: indisponível
- Então escolha um: integração com Git do Cloudflare Pages ou Direct Upload
E só.
Achar a única porta principal que está aberta é mais rápido do que construir dez saídas de emergência.
Não construa um segundo sistema de deploy só para publicar um link de afiliado.
Essa foi a maior lição de tudo isso.
7. "Publicado" se confirma na página de verdade, não com o hash de um commit
Um erro clássico ao cuidar de um site é chamar de "pronto" uma etapa do meio do caminho.
- você escreveu o código
- fez o commit no GitHub
- o build passou
- apareceu um deploy no Cloudflare
Tudo isso importa, mas os leitores só veem a URL final.
Para uma página de análise de afiliados como esta, a checagem final é:
- a URL pública abre numa janela anônima;
- aparece a versão mais recente do artigo;
- o aviso de afiliado aparece antes do link;
- o link do produto leva para o lugar certo;
- a página fica boa no celular;
- se precisar, você gera alguns cliques de teste;
- você confere na sua conta do Sovrn o número de cliques e o status da análise.
O Sovrn descreve o fluxo das campanhas de conteúdo e blogs assim: colocar os links, gerar cliques e depois a análise.[3]
Então "já está no GitHub, agora é esperar a análise" não serve. Você só está na linha de largada quando quem analisa consegue ver tudo funcionando na URL no ar.
8. Mais para frente, não deixe as URLs de afiliado fixas no texto do artigo
Um link colocado na mão tudo bem.
Mas, quando você tem centenas ou milhares de artigos, se alguém precisa decidir toda vez "Esse artigo leva anúncio? Onde? Qual produto? Para qual país?", do lado da sua fábrica de conteúdo nasce outra fábrica de anúncios.
O próximo passo é separar o texto do artigo dos dados de monetização.
Por exemplo, cada artigo leva só um bloquinho de configurações assim:
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
E, na hora de publicar, tudo segue assim:
artigo → decisão de monetização → escolha dos produtos → geração do link de afiliado → inserção ao montar a página → medição dos resultados
O artigo fica como um ativo de longo prazo. URLs de produtos, estoque, lojas e divisão por país viram peças que dá para trocar.
Assim você não precisa revisar o texto nos 12 idiomas toda vez que um link quebra ou um produto muda.
O link de afiliado não é o artigo.
Trate ele como um cano de vendas que você liga no artigo depois. No longo prazo, isso aguenta muito melhor.
9. Conclusão: se o CI falhar, procure a entrada de verdade do Cloudflare antes de construir outro castelo
Essa história toda diz muito.
Começou com: "Vamos colocar um link de HD para a análise".
O link estava pronto. O aviso, escrito. Tudo estava no GitHub.
Mas, na hora de publicar, o GitHub Actions não podia ser usado. Tentar contornar com um Worker também não deu.
Se nesse momento você adiciona mais um sistema, o objetivo muda sem você perceber: de "publicar um link" para "ampliar a plataforma de deploy".
No fim, você só precisa destas decisões:
- se o seu projeto do Pages usa integração com Git, deixe o Cloudflare fazer o build;
- se é Direct Upload, faça o build do site inteiro e publique o resultado oficial;
- se não dá para usar Workers, risque da lista;
- nunca chame um commit no GitHub de "publicado";
- confira o aviso, o link, como a página aparece e os cliques na URL pública de verdade.
O mais arriscado não é ter poucas opções.
É deixar para sempre no desenho opções que você não pode usar.
