Um site estático entrega arquivos prontos, iguais para todo visitante; um site dinâmico monta cada página no momento do pedido, com dados de um banco. O estático é mais barato, rápido e difícil de invadir. O dinâmico é obrigatório quando o conteúdo depende de quem acessa. O Google indexa os dois, mas lê o HTML pronto com menos esforço.
O que é um site estático e o que é um site dinâmico?
Site estático é aquele em que o servidor devolve sempre o mesmo conteúdo gravado em arquivo; site dinâmico é aquele em que parte da resposta é gerada só na hora, segundo a documentação da MDN. Na prática, o estático é uma pasta de arquivos HTML, CSS e JavaScript. O dinâmico é um programa no servidor que consulta um banco, encaixa o resultado num modelo de página e só então responde.
Exemplo estático: a página "Sobre" de uma empresa, igual para qualquer visitante. Exemplo dinâmico: a área logada de um cliente ou o carrinho de uma loja, montados no instante do pedido.
A confusão começa porque dinâmico virou sinônimo de "site que se mexe". Animação, scroll e 3D acontecem no navegador e cabem num site totalmente estático. O que define a categoria é onde a página nasce: no build, antes da visita, ou no servidor, a cada visita.
Um terceiro tipo complica a conversa: o site que o servidor entrega quase vazio e o JavaScript preenche no navegador, comum em React sem renderização no servidor. Para reconhecer, abra o fonte com Ctrl+U: se o texto está lá, o HTML veio pronto; se há só uma div vazia e um script, a página nasce no navegador. O teste completo está em como ver o código-fonte de um site.
O que muda em hospedagem, velocidade e segurança?
Estático custa menos para hospedar, abre mais rápido e tem menos superfície de ataque, porque não há código executando no servidor. Dinâmico precisa de servidor de aplicação, banco e alguém cuidando das atualizações.
Hospedagem. Uma pasta de arquivos cabe em serviços quase gratuitos. O plano gratuito do Cloudflare Pages aceita até 20.000 arquivos por site e 500 builds por mês (documentação do Cloudflare Pages). O GitHub Pages dá 100 GB de banda por mês, mas proíbe o uso como hospedagem de um negócio (GitHub Docs). Um site dinâmico precisa de servidor com PHP ou Node e de um banco, custo fixo mensal.
Velocidade. O arquivo estático sai do cache da CDN mais próxima do visitante; a página dinâmica espera o servidor montar o HTML. Os limites que o Google usa para considerar uma página boa são LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1, no percentil 75 das visitas (web.dev). Detalhamos cada métrica em Core Web Vitals em 2026.
Segurança. A maior parte da web dinâmica roda em WordPress, presente em 39,7% de todos os sites (W3Techs, outubro de 2026). A Patchstack contou 11.334 vulnerabilidades novas no ecossistema WordPress em 2025, 91% delas em plugins e só 6 no núcleo, com mediana de 5 horas entre a divulgação e a exploração em massa (Patchstack). Um estático não tem plugin para explorar. Comparamos os lados em WordPress ou site sob medida.
| Critério | Site estático | Site dinâmico |
|---|---|---|
| Onde a página nasce | No build, antes da visita | No servidor, a cada pedido |
| Hospedagem | CDN ou pasta de arquivos | Servidor de aplicação e banco |
| Velocidade | Arquivo pronto no cache | Depende do servidor e do cache |
| Segurança | Sem código no servidor | Plugins e banco expostos |
| Conteúdo por visitante | Não | Sim |
| Custo de manter | Baixo | Atualizações constantes |
Fontes: MDN, Cloudflare Pages, Patchstack, consultadas em outubro de 2026.
O que o Google prefere: página pronta no servidor ou montada no navegador?
O Google indexa os dois, mas a documentação diz que renderizar no servidor ou pré-renderizar "continua sendo uma ótima ideia". A razão está no Googlebot: ele processa sites em JavaScript em três fases, rastreamento, renderização e indexação, e põe toda página com status 200 numa fila de renderização que pode levar segundos ou mais (Google Search Central).
No site estático ou renderizado no servidor, o texto já está no HTML na primeira fase. No site que nasce no navegador, o Google espera a vez na fila, executa o JavaScript e só então lê o conteúdo. A mesma página lembra que nem todo robô executa JavaScript.
Durante anos a saída foi a renderização dinâmica: HTML pronto para robôs, JavaScript para pessoas. O Google hoje classifica a técnica como solução de contorno, não recomendada, e indica renderização no servidor, renderização estática ou hidratação (Google Search Central).
Na prática, o Google não prefere "estático" ou "dinâmico". Prefere HTML completo na primeira resposta. Um WordPress bem configurado entrega isso; um React sem SSR não. Para ser citado pelo ChatGPT e pelo Modo IA, o critério é o mesmo, como mostramos em site preparado para IA.
Como o Next.js mistura estático e dinâmico na mesma página?
O Next.js decide por página, e às vezes por trecho de página, se o HTML nasce no build ou no pedido. A documentação chama de pré-renderização o que é gerado no build e servido de CDN, e de renderização dinâmica o que roda no pedido; a página vira dinâmica quando lê cookies, cabeçalhos ou parâmetros de busca (glossário do Next.js).
SSG, geração estática
A página é gerada no build e vira um arquivo HTML servido de CDN. Serve para home, páginas de serviço e blog.
SSR, renderização no servidor
A página é montada a cada pedido e chega pronta ao navegador, para conteúdo personalizado que precisa ser indexado.
ISR, regeneração estática incremental
A página é estática, mas tem prazo de validade. No exemplo da documentação, com revalidate = 60, a primeira visita depois de 60 segundos ainda recebe a versão em cache e dispara a regeneração em segundo plano. O guia recomenda prazos altos, como 1 hora, e revalidação sob demanda quando precisa de precisão (guia de ISR do Next.js).
Existe ainda a exportação estática: com output: 'export', o Next.js gera um HTML por rota, e a pasta pode ser hospedada em qualquer servidor de arquivos, sem Node. O custo é abrir mão de cookies, redirecionamentos, ISR e ações de servidor (Next.js, exportação estática). É o modo que recomendamos para sites institucionais sem área logada.
Por que o Ctrl+S não salva o site inteiro?
Porque o Ctrl+S grava o que o navegador recebeu, não o que o JavaScript montou depois. Num site estático antigo, o HTML já contém tudo. Num site moderno, o arquivo salvo é a estrutura vazia: conteúdo, fontes do CSS, texturas 3D e dados de API ficam para trás.
O mesmo vale para o HTTrack e para qualquer ferramenta que só lê o HTML do servidor: ela enxerga a mesma div vazia que o Googlebot vê na primeira fase. Os casos estão em por que o HTTrack não baixa sites modernos.
Uma captura completa precisa fazer o que o navegador faz: executar o JavaScript, rolar até o fim, interceptar cada arquivo baixado e reescrever os caminhos para a pasta local. É o que o Extrator de Sites, que é o nosso, faz dentro do navegador; o plano grátis dá 2 downloads por mês e o modo Site inteiro segue os links do menu até 2 níveis.
Onde ele não é a melhor escolha: sites com login ou dados por usuário, porque a captura guarda a página, não o sistema por trás dela. Para o seu próprio WordPress, o backup do painel é o caminho. O comparativo de métodos está em como baixar um site completo.
Abrir o site
Carregue a página e espere o JavaScript montar o conteúdo.
Rolar até o fim
Dispare as seções com carregamento preguiçoso.
Interceptar os arquivos
Capture fontes, imagens, vídeos, modelos 3D e shaders.
Reescrever os caminhos
Troque as URLs absolutas por caminhos locais.
Abrir offline
Teste a cópia sem internet e confira animação, fonte e 3D.
Qual escolher para o site de uma empresa?
Para a maioria das empresas, a resposta é estático com partes dinâmicas, não um ou outro. Site institucional, landing page e blog nascem no build. Formulário, agendamento e área do cliente entram como trechos dinâmicos ou serviços externos ligados por API.
A regra de decisão que recomendamos tem três perguntas. O conteúdo muda por visitante, como login ou carrinho? A rota é dinâmica, com SSR para seguir indexável. Muda várias vezes por dia, como preço ou estoque? ISR resolve. Nenhuma das duas? Estático, sem discussão.
A pergunta que fica de fora é quem edita. Se a equipe de marketing precisa trocar texto sem desenvolvedor, o caminho é um CMS que dispara o build a cada publicação; o site segue estático. É o arranjo que recomendamos nos projetos de Website & Design sem área logada.
Perguntas frequentes
Site em WordPress é estático ou dinâmico?
Dinâmico. O WordPress monta cada página em PHP consultando o banco MySQL a cada pedido, por isso precisa de servidor com linguagem rodando. Plugins de cache gravam uma cópia estática do resultado para acelerar, mas painel, banco e plugins continuam expostos à internet.
Site estático pode ter formulário de contato?
Sim. O formulário é HTML, e o envio vai para um serviço externo, uma função sem servidor ou um webhook do CRM. A página continua estática; só o envio é processado fora dela. É o arranjo mais comum em landing pages.
Site estático é sempre mais rápido que dinâmico?
Não. Um estático com imagens pesadas e scripts demais perde para um dinâmico bem cacheado. O que o estático garante é a ausência de tempo de servidor: o arquivo já existe e sai da CDN. O resto depende de peso, fontes e JavaScript, que valem para os dois tipos.
Dá para transformar um site dinâmico em estático?
Dá, quando o conteúdo não depende do visitante. Geradores estáticos e a exportação do Next.js leem o CMS no build e gravam um HTML por página. O que não migra: login, carrinho, busca com filtros no servidor e rotas que leem cookies. Essas partes seguem dinâmicas ou vão para um serviço à parte.
Conclusão
A escolha entre estático e dinâmico não é sobre tecnologia nova ou velha. É sobre onde a página nasce e quem paga por isso, em servidor, segurança e tempo de carregamento. Para a maior parte das empresas, a página nasce antes da visita, e só o que depende de cada pessoa roda na hora.
O mesmo critério explica por que alguns sites baixam inteiros e outros não. Se o HTML chega pronto, qualquer ferramenta guarda. Se nasce no navegador, só uma captura que executa o código guarda o que você vê.
