Era para ser apenas um link
A tarefa inicial era pequena: colocar em um artigo real um link de afiliado para um HDD externo, de modo que uma plataforma de afiliados pudesse revisar a implementação do site.
A página precisava ter conteúdo útil, uma divulgação clara da possível remuneração antes do link comercial e um destino funcional. O link foi criado e o artigo foi commitado no GitHub.
Então apareceu o problema de verdade.
Código existente no GitHub não significa que a página esteja publicada na internet.
O caminho normalmente usado com GitHub Actions não estava disponível. Também surgiu a ideia de interceptar apenas aquela URL com um Cloudflare Worker, mas esse caminho igualmente não podia ser usado nas condições atuais de operação.
Um único link de afiliado virou uma reunião sobre CI, Workers, Pages, Git integration e Direct Upload.
Quase começamos a construir a Sagrada Família do afiliado, prédio número 2.
Quando os mecanismos de deploy são separados corretamente, porém, a situação fica muito mais simples.
1. Por que era necessário ter uma página realmente pública primeiro
O guia de onboarding do Sovrn Commerce para sites de conteúdo e blogs orienta o publisher a implementar os links do Commerce e gerar cliques antes da revisão da campanha para aprovação.[3]
Portanto, o fluxo não é simplesmente “ser aprovado e depois colocar o link”. A equipe de revisão precisa conseguir ver um exemplo real de implementação.
O Sovrn também explica que páginas com links de afiliado devem informar claramente a relação material e que o disclosure deve aparecer antes do link ou da promoção.[4]
Para uma página básica de revisão, os requisitos são modestos:
- existe um artigo real no site enviado;
- o artigo contém o link de afiliado;
- o disclosure aparece antes do link;
- a URL pública abre normalmente;
- depois da implementação, é possível gerar alguns poucos cliques de verificação.
O ponto-chave é: um arquivo dentro do repositório ainda não é uma página pública.
2. GitHub Actions indisponível não significa Cloudflare Pages indisponível
GitHub Actions é o sistema de CI/CD do GitHub para executar build, testes e deploy.
Cloudflare Pages também possui sua própria Git integration. Um projeto Pages pode ser conectado diretamente ao GitHub ou GitLab, e o próprio Cloudflare pode compilar e publicar automaticamente quando um push chega ao repositório conectado.[1]
O fluxo pode ser:
push no GitHub → Cloudflare Pages detecta o commit → Cloudflare faz build → Cloudflare faz deploy
Esse caminho não depende de um workflow do GitHub Actions.
Logo, “não podemos usar GitHub Actions” não é a mesma coisa que “não podemos publicar automaticamente do GitHub para o Cloudflare”.
GitHub Actions é como uma esteira interna. A Git integration do Cloudflare é como uma transportadora que vai até o depósito buscar o pacote.
A esteira pode parar sem que a coleta externa pare.
3. Primeiro descubra qual tipo de projeto Pages já existe
Cloudflare Pages tem dois modelos principais de deploy.
| Modelo | Gatilho | Onde ocorre build/deploy | Melhor uso |
|---|---|---|---|
| Git integration | push no GitHub/GitLab | Cloudflare | quando o repositório é a fonte de verdade e o deploy deve ser automático |
| Direct Upload | saída de build pronta | Wrangler ou dashboard | quando o site é compilado localmente ou em outro CI e enviado pronto |
A documentação do Cloudflare registra uma limitação importante: um projeto criado com Git integration não pode simplesmente ser convertido em um projeto Direct Upload normal. Projetos integrados ao Git ainda podem receber deploy manual via Wrangler, mas o drag-and-drop do dashboard não está disponível para esses projetos Git existentes.[1][2]
O inverso também importa: um projeto criado como Direct Upload não pode receber Git integration posteriormente no mesmo projeto. Para passar a deploy Git automático é necessário criar um novo projeto Pages.[2]
Portanto, a primeira pergunta não deve ser “qual gambiarra eu tento?”.
Deve ser: “O projeto Pages atual é Git integration ou Direct Upload?”
Responder isso elimina metade do labirinto.
4. Se for Git integration, não é necessário ressuscitar GitHub Actions
Se o repositório já estiver corretamente conectado ao Cloudflare Pages, o caminho mais curto não é um Worker nem um novo serviço de CI.
Confira no projeto Pages:
- se o repositório GitHub correto está conectado;
- se a production branch é realmente a branch publicada;
- se builds automáticos dessa branch não foram desativados;
- se build command e output directory correspondem ao projeto atual;
- se um novo deployment aparece após o push;
- se o
pages.devmostra o conteúdo novo; - se o custom domain mostra a mesma versão.
A Git integration do Cloudflare existe justamente para compilar e publicar a partir dos commits do repositório conectado.[1]
Se esse caminho estiver funcionando, uma limitação temporária do GitHub Actions não exige uma nova arquitetura.
Antes de cavar outro túnel de emergência, veja se a porta principal já está aberta.
5. Se for Direct Upload, publique o build completo, não uma página artesanal
Direct Upload recebe assets que já foram compilados. Cloudflare oferece Wrangler e drag-and-drop no dashboard para projetos Direct Upload.[2]
É tentador pensar: “só alterei um artigo; por que não subir um HTML?”
Em um site gerado estaticamente, isso normalmente é o modelo mental errado.
A unidade de deploy é a saída completa do build, não apenas o source file alterado. O build pode regenerar rotas, CSS, JavaScript, índice de busca, metadata e outros assets.
Um fluxo mais seguro é:
obter source mais recente → executar build do projeto → conferir output directory → publicar a saída completa → verificar a URL real
Em projetos Node, o comando pode ser algo como pnpm build, produzindo uma pasta como dist.
O objetivo é não transformar produção em um universo manual separado do repositório.
6. Se Worker não está disponível, remova-o do desenho
Usar uma route de Worker para resolver uma única URL urgente pode ser tecnicamente válido.
Mas se o ambiente atual não permite Workers, manter essa alternativa como plano principal só adiciona complexidade.
A decisão fica simples:
- GitHub Actions indisponível;
- Worker indisponível;
- usar a Git integration existente do Pages ou o caminho válido de Direct Upload.
Dez saídas de emergência não são necessariamente melhores do que uma porta que sabemos abrir.
Não construa uma segunda plataforma de deploy só para publicar um link de afiliado.
7. “Publicado” precisa ser provado na página real, não por um SHA
Escrever código, fazer commit, concluir o build e criar um deployment são marcos intermediários.
A verificação final acontece na URL que o leitor realmente acessa.
Para uma página de revisão de afiliados, confirme:
- a URL pública abre em uma sessão limpa;
- o texto mais recente está visível;
- o disclosure aparece antes do link de afiliado;
- o link chega ao destino esperado;
- a página funciona em mobile;
- se necessário, alguns cliques de verificação são gerados;
- o Sovrn registra tráfego ou avanço no status de revisão.
O fluxo do Sovrn para conteúdo/blog é implementação, geração de cliques e depois revisão.[3]
Portanto, o ponto de partida não é “o código está no GitHub”. É uma implementação pública que o revisor consegue inspecionar.
8. Em escala, não grave URLs de afiliado diretamente no corpo editorial
Um link manual é aceitável.
Centenas ou milhares de artigos mudam o problema. Se cada artigo exigir decisão manual sobre monetização, posição, produto e mercado, a fábrica de conteúdo ganha uma segunda fábrica ao lado.
É melhor separar conteúdo editorial de metadata comercial.
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
O fluxo pode se tornar:
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
O artigo continua sendo um ativo durável. URLs de produto, estoque, merchant e roteamento por país viram componentes substituíveis.
Afiliados devem funcionar como encanamento comercial ligado ao artigo, não como concreto misturado à fundação do texto.
9. Conclusão: quando o CI não está disponível, encontre primeiro a entrada real do Cloudflare
Tudo começou com um único link de afiliado para HDD.
O link existia. O disclosure existia. O source estava no GitHub.
Depois o caminho normal de CI ficou indisponível e o desvio por Worker também não podia ser usado.
Adicionar outro mecanismo teria mudado o objetivo de “publicar um link” para “construir outra plataforma de deploy”.
A árvore de decisão útil é pequena:
- se Pages já usa Git integration, use o build Git nativo do Cloudflare;
- se for Direct Upload, compile o site completo e publique a saída completa pelo caminho suportado;
- se Workers não podem ser usados, remova-os das opções;
- não confunda Git commit com deploy em produção;
- verifique disclosure, link, renderização e cliques na URL pública real.
A arquitetura mais perigosa não é a que tem poucas opções.
É a que mantém para sempre opções que já não podem ser usadas.
