Um site estático começa a parecer pronto para público quando sai da URL de prévia e chega a um domínio que você controla.
Também é nessa etapa que projetos simples ficam confusos. Registros DNS, domínio raiz, www, certificados HTTPS, redirecionamentos, URLs antigas e cache do navegador aparecem ao mesmo tempo. Nada disso é difícil isoladamente. O problema é fazer na ordem certa.
Primeiro a prévia, depois o domínio
Use a URL de prévia como link de trabalho até o site ser aprovado.
Isso separa bem os problemas:
- A URL de prévia prova que os arquivos enviados funcionam.
- O domínio personalizado prova que o lançamento público está pronto.
Se você conecta o domínio cedo demais, cada correção de conteúdo vira também investigação de DNS. Mantenha as coisas separadas. Envie a pasta, abra a prévia HTTPS, teste o site e só então conecte o domínio.
No DeployPages, o envio pela página inicial permite começar pela prévia. Quando o site estiver pronto, avance para domínios personalizados e SSL gratuito.
Domínio raiz ou www?
Você normalmente tem três escolhas:
| Tipo de domínio | Exemplo | Melhor para |
|---|---|---|
| Domínio raiz | example.com | O endereço público mais limpo |
Subdomínio www | www.example.com | Muito comum e geralmente fácil de rotear |
| Subdomínio personalizado | docs.example.com, app.example.com | Docs, campanhas, projetos paralelos, prévias |
A própria documentação do GitHub Pages recomenda pensar com cuidado na configuração de domínio raiz e www, e observa que subdomínios www são o tipo mais estável no GitHub Pages por não dependerem de mudanças nos IPs dos servidores do GitHub. Os registros exatos variam por host, mas a lição operacional é mais ampla: escolha um endereço principal e redirecione o outro para ele.
Para a maioria dos sites de marketing, portfólios e docs, qualquer uma destas opções funciona:
example.comcomo principal, comwww.example.comredirecionando para ele.www.example.comcomo principal, comexample.comredirecionando para ele.
Não deixe os dois servirem cópias separadas do mesmo site. Isso cria URLs duplicadas para usuários e mecanismos de busca.
DNS em português claro
Você não precisa decorar todos os tipos de registro DNS. Em hospedagem de site estático, normalmente vai encontrar estes:
| Registro | O que faz | Uso típico |
|---|---|---|
CNAME | Aponta um subdomínio para outro hostname | www.example.com para um destino fornecido pelo host |
A | Aponta um domínio para um endereço IPv4 | Domínio raiz quando o provedor fornece IPs |
AAAA | Aponta um domínio para um endereço IPv6 | Domínio raiz quando IPv6 é compatível |
ALIAS ou ANAME | Aponta um domínio raiz para um hostname | Alternativa específica de provedor ao A |
TXT | Guarda texto de verificação | Checagens de propriedade de domínio |
Seu host deve informar exatamente qual registro adicionar. Se não informa, o problema é do produto, não do usuário.
Depois de editar registros, use uma ferramenta de consulta. O DeployPages inclui uma consulta DNS para verificar se a internet pública já enxerga a mudança.
HTTPS faz parte do lançamento
Domínio personalizado sem HTTPS parece quebrado para usuários, navegadores e mecanismos de busca.
Antes de anunciar o link, confira:
- O domínio abre com
https://. - O certificado cobre exatamente o hostname usado.
- A versão
http://redireciona para HTTPS. - O hostname não principal redireciona para o principal.
- Avisos do navegador sumiram em uma janela privada.
Se o DNS ainda está propagando, emitir o certificado SSL pode levar um tempo. Não fique trocando registros a cada poucos minutos, a menos que os valores estejam errados. Espere, confira e só mude o que precisa mudar.
O verificador SSL ajuda aqui porque permite confirmar o certificado fora do cache do seu navegador.
Como domínios personalizados entram na publicação estática
A cadeia mais limpa de publicação fica assim:
| Etapa | URL | Finalidade |
|---|---|---|
| Primeiro envio | URL temporária de prévia | Conferir arquivos e compartilhar internamente. |
| Revisão | URL estável de prévia | Enviar para clientes, colegas ou pessoas envolvidas. |
| Lançamento | Domínio personalizado | Tráfego público e SEO. |
| Atualização | Nova versão de publicação | Corrigir ou melhorar sem quebrar a versão anterior. |
| Recuperação | Restaurar versão anterior | Voltar a uma versão boa se a atualização falhar. |
Esse é um motivo para um host estático fazer mais do que guardar arquivos. Quando um site usa domínio próprio, você precisa de consciência de versão. Um envio quebrado não deveria derrubar o link público sem caminho de recuperação.
No DeployPages, restaurar versão anterior é recurso do produto, não um exercício manual de "achar o ZIP antigo". Veja restaurar versão anterior para o lado de controle de publicação.
Erros comuns com domínio personalizado
Enviar o build errado antes de conectar DNS
Se a URL de prévia está quebrada, o domínio também vai quebrar. Corrija os arquivos primeiro.
Misturar dois hostnames principais
Escolha example.com ou www.example.com. Redirecione o outro.
Esquecer links antigos
Se você está substituindo um site existente, verifique caminhos antigos importantes. Sites estáticos também podem precisar de redirecionamentos.
Achar que DNS mudou porque o painel mudou
O painel do provedor de DNS não é a mesma coisa que resolução DNS pública. Use ferramentas de consulta.
Lançar sem metadados
Antes de lançar com domínio, defina título final, descrição, favicon e imagem social. O gerador de meta tags e a ferramenta de imagem OG ajudam nessas partes chatas, mas visíveis.
Quando vale usar domínio personalizado
Adicione domínio quando:
- O site representa uma empresa, pessoa, produto, evento ou cliente.
- O link será impresso, usado em anúncios ou colocado em um perfil.
- SEO importa.
- Pessoas vão voltar ao site depois.
- Você precisa de confiança além de uma URL temporária de prévia.
Pule o domínio em prévias descartáveis, ciclos rápidos de feedback ou demos internas que serão substituídas amanhã.
Hospedagem estática funciona melhor quando permite as duas velocidades. Links de prévia devem ser rápidos. Lançamentos com domínio devem ser deliberados.