Colocar um site estático no ar resolve só a primeira parte do trabalho. A pergunta que vem depois é mais útil: alguém abriu o link?
Também vale saber de onde vieram as visitas, quais páginas foram abertas, se o site está sendo visto no celular ou no desktop, quais países aparecem e se imagens, PDFs, vídeos ou fontes pesadas já estão consumindo banda demais.
Para essa primeira leitura, nem todo projeto precisa começar com uma pilha completa de análise. Muitas vezes, estatísticas simples ligadas ao projeto publicado já respondem o que importa nos primeiros dias.
Comece pela pergunta que o site precisa responder
Estatísticas ficam confusas quando todo número parece ter o mesmo peso.
Um site estático normalmente tem uma função bem concreta. Pode ser um portfólio online, currículo online, landing page, prévia para cliente, documentação, projeto de faculdade, site gerado por IA ou uma página com PDF. Cada caso pede uma leitura diferente.
| Tipo de site | Primeira pergunta | Dados que ajudam |
|---|---|---|
| Portfólio online | O link chegou a clientes ou recrutadores? | Visitantes, origens, páginas principais, dispositivos |
| Landing page | Qual canal trouxe tráfego? | Origens, links UTM, páginas principais, países |
| Currículo online | A página funciona bem no celular? | Dispositivos, navegadores, páginas vistas |
| Prévia para cliente | A versão certa foi aberta? | Visitas recentes, países, dispositivos, páginas |
| Documentação | As pessoas chegaram na página correta? | Páginas principais, origens, caminhos estranhos |
| Site com imagens ou PDF | O peso dos arquivos já aparece? | Banda, páginas principais, tamanho dos arquivos |
Se você não sabe o que o site deveria provar, o painel não resolve sozinho. Você vai ver uma curva subir ou cair, mas não vai saber se precisa trocar o texto, corrigir uma rota, comprimir uma imagem, compartilhar melhor o link ou conectar um domínio.
Visitas e visitantes não contam a mesma história
Visitas ou páginas vistas mostram quantas vezes uma página foi carregada. Visitantes dão uma ideia de quantas pessoas, navegadores ou sessões diferentes chegaram ao site.
Esses dois números são úteis, mas não significam a mesma coisa.
Nos primeiros dias, você, sua equipe, um cliente ou um professor podem abrir e recarregar o mesmo link várias vezes. Isso aumenta páginas vistas sem aumentar a audiência de verdade. O contrário também acontece: poucas visitas, mas vindas de origens e dispositivos diferentes. Para portfólio, currículo ou protótipo, essa diferença pode orientar a próxima ação.
| Indicador | Ajuda a entender | Erro comum |
|---|---|---|
| Páginas vistas | Atividade por URL | Tratar testes internos como interesse real |
| Visitantes | Alcance aproximado | Ler como número exato de pessoas |
| Páginas principais | URLs que foram abertas | Olhar só a página inicial |
| Banda | Peso dos arquivos e pressão no plano | Perceber tarde que uma página ficou pesada |
Cada ferramenta usa nomes próprios. No Google Analytics 4, page_view é um evento enviado quando uma página é carregada. Ferramentas mais leves, como Plausible ou Cloudflare Web Analytics, costumam mostrar páginas vistas, visitantes, referentes, países, dispositivos e navegadores de forma mais direta.
O nome exato importa menos do que a leitura em conjunto. Páginas vistas, visitantes, origem do tráfego e páginas principais explicam melhor o lançamento do que uma métrica isolada.
No DeployPages, as estatísticas do projeto mostram páginas vistas, visitantes estimados, banda, páginas principais, referentes, países, dispositivos, navegadores, sistemas operacionais e visitas recentes. Para um site estático recém-publicado, essa primeira camada costuma ser suficiente.
A origem do tráfego mostra se a distribuição funcionou
Muitos lançamentos pequenos não falham por causa da página. Falham porque quase ninguém viu o link, ou porque ele foi compartilhado no lugar errado.
Ver a origem do tráfego ajuda a separar esses casos.
| O que aparece | O que pode significar | Próximo passo |
|---|---|---|
| Muito direct | E-mail, chat, QR code, link copiado ou referente ausente | Usar UTM no próximo compartilhamento |
| Uma rede social domina | O post ou repost funcionou | Ver páginas e dispositivos desse tráfego |
| Busca começa a aparecer | A página está sendo encontrada fora do envio inicial | Revisar title, description e domínio |
| Domínio interno ou de cliente | Existe tráfego de revisão | Não misturar com resposta pública |
| Referentes estranhos | Ruído, bots ou visitas pouco úteis | Não mudar a página por esse sinal |
Se a mesma página vai para newsletter, Instagram, WhatsApp, LinkedIn, QR code e link na bio, prepare URLs identificáveis. O gerador UTM ajuda a definir source, medium e campaign antes de publicar.
O objetivo não é criar atribuição perfeita. É evitar a pergunta que sempre aparece depois: de onde veio esse acesso?
Dispositivos e navegadores indicam onde testar
Site estático costuma ser montado no notebook e aberto no celular.
Um portfólio que parece equilibrado no desktop pode virar uma lista longa no mobile. Uma landing page pode deixar o botão principal visível em tela grande e escondido em um celular. Um currículo em HTML pode estar bom no Chrome do computador e apertado no Safari móvel.
Dados de dispositivo, navegador e sistema operacional não escolhem o design por você. Eles mostram onde testar primeiro.
Se a maior parte das visitas vem de celular, abra o link real em um telefone antes de reescrever a página inteira. Se iOS Safari aparece muito, confira imagens, vídeos, fontes e áreas de toque nesse ambiente. Se uma revisão de cliente vem de navegador antigo, evite transformar a reunião em uma conversa sobre compatibilidade.
Isso é mais útil do que repetir "mobile first" sem contexto. A estatística fala do site que acabou de sair.
Páginas mais acessadas quebram suposições
Quem publica costuma imaginar uma porta de entrada. Quem visita pode usar outra. É por isso que vale olhar as páginas mais acessadas, além das páginas principais mostradas no painel.
Alguém compartilha uma URL interna. Um QR code aponta para uma rota de campanha. Um documento antigo guarda um link velho. A busca encontra primeiro um artigo. Um site gerado por IA pode deixar uma rota de teste visível na navegação.
Olhe as páginas principais principalmente depois de:
- enviar uma nova versão;
- trocar o link de prévia por domínio personalizado;
- migrar de GitHub Pages, portfólio antigo ou documentação;
- usar links diferentes em campanha, e-mail, redes sociais ou QR code;
- mexer em
index.html, navegação ou caminhos de arquivos; - publicar PDFs, imagens ou downloads.
Uma página interna no topo não é necessariamente ruim. Talvez ela seja a melhor entrada. O problema é quando aparecem rotas antigas, downloads quebrados ou páginas que ainda não estavam prontas para público.
Largura de banda vira problema quando você olha tarde demais
Banda não chama tanta atenção quanto visitas, mas em sites estáticos ela pode ser o sinal mais prático de custo e desempenho.
Imagens grandes, PDFs, vídeo de fundo, fontes pesadas e capturas exportadas sem compressão parecem inofensivos quando só três pessoas abrem a prévia. O assunto muda quando o link entra em uma campanha, portfólio, QR impresso ou post que começa a circular.
Vale observar banda quando:
- o site usa muitas fotos, capturas ou imagens de produto;
- PDFs, cardápios, apresentações ou arquivos de mídia ficam no mesmo projeto;
- uma campanha pode gerar pico curto;
- o projeto se aproxima dos limites do plano;
- a audiência entra principalmente pelo celular.
A banda não diz automaticamente qual arquivo pesa demais. Ela funciona como alerta. Depois disso, revise dimensões de imagem, compressão, lazy loading, vídeos, fontes e o lugar onde arquivos grandes aparecem.
Estatísticas integradas primeiro, análise mais profunda depois
Google Analytics, Plausible, Matomo, Fathom, Simple Analytics e PostHog podem fazer sentido. A questão é quando adicionar cada um.
Logo depois de publicar, as perguntas costumam ser simples:
- O link abre?
- De onde vieram as visitas?
- Quais URLs foram abertas?
- O tráfego é mais mobile ou desktop?
- Os países fazem sentido para o público esperado?
- A banda está dentro do normal?
Estatísticas integradas funcionam bem para essa primeira camada porque ficam ligadas ao projeto publicado. Você envia uma pasta, recebe um link HTTPS, compartilha e lê a reação inicial sem alterar os arquivos estáticos para instalar outro script.
Uma ferramenta de análise mais completa entra quando você precisa medir cliques em botões, funis, conversões, testes A/B, campanhas pagas, usuários logados, eventos de produto ou e-commerce.
Separar esses níveis deixa a decisão mais clara. Estatísticas de publicação respondem se o site está sendo visto. Análise de produto responde o que as pessoas fazem depois de chegar.
Privacidade, LGPD e scripts externos
No Brasil, qualquer ferramenta que mede acesso pode tocar em temas de privacidade, cookies, armazenamento no navegador e dados pessoais. Não trate isso como detalhe.
Uma estatística de lançamento não é a mesma coisa que uma pilha completa de rastreamento.
| Nível | Pergunta principal | Exemplos |
|---|---|---|
| Estatísticas de publicação | O link público foi aberto? | Páginas vistas, origens, dispositivos, países, banda |
| Análise de marketing ou produto | O que a pessoa fez dentro do site? | Eventos, conversões, segmentos, testes A/B, publicidade |
O DeployPages oferece a primeira leitura ligada ao projeto. Isso não substitui revisar sua Política de Privacidade. Se você adiciona Google Analytics, pixels de anúncio, mapas de calor, chat, formulários externos ou outros scripts, confira quais dados são enviados, o que fica no navegador e que aviso o site precisa mostrar.
A ideia não é transformar uma página pequena em projeto jurídico. É evitar que um site simples carregue ferramentas que ninguém configurou nem explicou.
Uma rotina simples para a primeira semana
Você não precisa olhar estatísticas o dia inteiro. Para site estático, algumas checagens já ajudam bastante.
| Momento | O que olhar | Por quê |
|---|---|---|
| Primeira hora | Se a página abre, 404, imagens e scripts | Corrigir antes de compartilhar mais |
| Primeiro dia | Origens, dispositivos, páginas principais | Ver se distribuição e layout combinam com a audiência |
| Primeira semana | Tendência, países, banda, páginas que seguem ativas | Decidir se vale melhorar, manter ou trocar |
| Depois de nova versão | Páginas principais e visitas recentes | Confirmar que nenhuma URL útil quebrou |
| Depois de conectar domínio | Direct, busca, URLs antigas | Ver se o domínio substituiu o link de teste |
O objetivo não é criar relatório por costume. O objetivo é saber o próximo passo: corrigir um caminho, comprimir uma imagem, trocar o link compartilhado, conectar domínio ou adicionar uma análise mais profunda.
Como o DeployPages entra nesse fluxo
O DeployPages trata estatísticas como parte do fluxo de publicação.
Você pode publicar uma pasta estática, ZIP, build front-end, site gerado por IA, página com PDF ou portfólio. Depois, no projeto, pode revisar páginas vistas, visitantes estimados, origens, páginas principais, países, dispositivos, navegadores, sistemas, banda e visitas recentes.
O mesmo projeto pode crescer para domínio personalizado, proteção por senha, restaurar versão anterior, deploy via CLI e estatísticas.
Para muitos sites estáticos, essa ordem é mais natural: publicar primeiro, olhar sinais reais e só então decidir se o projeto merece domínio, otimização, equipe ou uma ferramenta de análise mais profunda.