Operação de websites
Checklist de publicação: valide o caminho público, não apenas a home
Sequência prática para conferir DNS, HTTPS, redirects, rastreamento, sitemap, metadados, erros e uso no celular.
Em resumo
A home abrir em um notebook não é um teste de publicação. Uma entrega confiável verifica hostname público, cadeia de resposta, rotas representativas, instruções para crawlers, metadados e caminho de recuperação fora do ambiente de desenvolvimento.
- Teste o hostname final a partir de um cliente limpo.
- Mantenha redirects curtos, intencionais e sem loops.
- Faça robots.txt e sitemap concordarem com as URLs desejadas.
- Valide conteúdo, erro e idiomas — não só `/`.
- Registre o rollback antes de alterar o tráfego.
1. Defina o contrato da entrega
Liste hostnames públicos, esquema canônico, caminho-base, idiomas e rotas representativas. Inclua conteúdo, ferramenta interativa, página legal, asset, 404 e redirects importantes.
Anote o resultado esperado: URL final, status, marcador da página e indexação desejada. Uma verificação de entrega só é acionável quando “correto” está explícito.
- Hostnames principal e alternativos listados
- URL HTTPS canônica decidida
- Rotas representativas escolhidas
- Responsável e gatilho de rollback registrados
2. Confira DNS, TLS e cadeia de resposta
Resolva o hostname público com resolvedores independentes e conecte por HTTPS. Confirme que o certificado cobre o hostname, está válido e entrega a aplicação desejada.
Siga os redirects sem cache do navegador. HTTP e hosts alternativos devem chegar a um único destino canônico. Cadeias longas aumentam latência e pontos de falha; loops ou destinos mistos bloqueiam a entrega.
3. Alinhe rastreamento e descoberta
Busque robots.txt exatamente onde o crawler buscará. Confirme que ele não bloqueia páginas ou assets necessários e que referências de sitemap apontam para arquivos atuais e acessíveis.
Sitemap é pista de descoberta, não certificado de qualidade. Inclua URLs canônicas desejadas na busca, retire caminhos privados ou duplicados e mantenha links internos normais para cada página importante.
- robots.txt retorna 200
- Sitemaps referenciados estão acessíveis
- URLs do sitemap são canônicas e retornam 200
- Conteúdo público não tem noindex acidental
4. Inspecione o HTML entregue a usuários e crawlers
Em cada rota, confira H1 claro, título e descrição úteis, canonical, idioma, conteúdo principal visível e links internos. Páginas localizadas só devem anunciar traduções recíprocas que realmente existem.
Teste largura móvel, foco por teclado, labels, mensagens de validação e overflow horizontal. A tarefa gratuita principal deve funcionar sem cadastro. Erros precisam orientar o próximo passo.
5. Observe, reverta e teste novamente
Após publicar, repita os testes contra a origem pública e procure erros. Compare asset ou identificador da release ao commit pretendido para ligar o resultado verde à versão certa.
Reverta quando rota crítica, certificado, canonical, limite de dados ou ação central falhar. Depois da recuperação, repita o teste público: reverter arquivos não garante que cache, roteamento ou DNS também voltaram.
Próximo passo
Verifique o seu caso
Perguntas frequentes
Resposta 200 é suficiente?
Não. Uma página genérica ou de erro pode retornar 200. Confira URL final, marcador esperado, metadados e ação principal.
Toda URL deve entrar no sitemap?
Não. Inclua URLs canônicas que devem ser descobertas e indexadas. A navegação ainda precisa ligar as páginas importantes.
robots.txt remove uma página da busca?
Bloquear rastreamento não remove de forma confiável uma URL já conhecida. Use o controle de indexação apropriado e siga a orientação atual do buscador.
Quando devo fazer rollback?
Quando o caminho público, limite de segurança, roteamento canônico ou tarefa essencial falha e uma correção rápida não é mais segura que a reversão.
Fontes primárias e referência
Fontes consultadas na revisão editorial. Links externos abrem a publicação responsável pelo padrão ou orientação.