Como preparar um domínio para publicar o teu projeto
Para preparar um domínio para publicar o teu projeto, confirma quem gere o DNS, inventaria os serviços existentes e configura o endereço no alojamento de destino. Usa os valores atuais desse projeto, define o comportamento com e sem www e prepara a verificação de HTTPS, páginas e funções. Guarda também o estado anterior para poderes recuperar.
Define o que vai mudar no endereço público
Começa por descrever a alteração pretendida e os serviços que dependem do domínio. Podes estar a publicar um projeto novo, a substituir um site no mesmo endereço ou a mudar para outro domínio. Cada situação exige verificações diferentes. Um plano claro permite preparar a mudança sem tratar todas as migrações como se fossem iguais.
Vamos usar um cenário fictício: uma pequena empresa tem um site antigo, email em funcionamento e um subdomínio usado por uma ferramenta interna. Pretende colocar uma nova versão do site no domínio principal, mantendo o email e a ferramenta. Os exemplos deste artigo descrevem a preparação; não representam uma migração executada.
Escreve uma frase que defina o resultado: “O domínio principal passa a mostrar a nova versão, com os mesmos serviços de email e com o subdomínio interno preservado.” Acrescenta quem pode aprovar a publicação e quem tem acesso às configurações necessárias. Se a publicação já estiver autorizada, regista esse âmbito e trabalha dentro dele.
Distingue ainda domínio de alojamento. Ter acesso à conta onde compraste o domínio não significa que essa conta gira a zona DNS ativa. Da mesma forma, uma aplicação disponível num endereço de teste ainda pode não estar associada ao endereço final que queres divulgar.
Antes de mexer no domínio, a versão de destino deve estar identificada e testada. O guia para publicar uma aplicação na Vercel e confirmar que funciona ajuda a preparar essa entrega. Neste artigo, o foco é ligar o endereço certo ao projeto certo e conferir os serviços à volta.
Confirma onde a zona DNS está realmente ativa
Identifica o fornecedor que responde pelo DNS do domínio e confirma que tens acesso à zona usada publicamente. Esta verificação evita editar registos numa conta que já não controla o endereço. Regista o domínio, os servidores DNS ativos e o local onde a alteração será feita, para que o plano corresponda à configuração real.
Na documentação da OVHcloud sobre edição de zonas DNS, a edição através da Área de Cliente pressupõe que o domínio utiliza os servidores DNS da OVHcloud. Se a configuração ativa estiver noutro fornecedor, é nesse fornecedor que deves tratar os registos relevantes.
Confirma também a conta e o projeto de destino. Uma organização pode ter vários sites com nomes parecidos ou contas partilhadas entre equipas. Regista um identificador do projeto e a versão que deverá aparecer no endereço final. Isso ajuda a evitar uma configuração tecnicamente válida que aponta para o site errado.
Não alteres servidores DNS apenas porque vais mudar o alojamento do site. Primeiro, identifica o que a mudança exige. Se a opção escolhida for transferir a gestão da zona, prepara os serviços existentes no novo local antes da troca e confere o âmbito com quem os mantém.
Guarda esta informação num registo de operação simples. Deve ser possível a outra pessoa perceber onde está o domínio, onde está o DNS e onde está a aplicação. Evita guardar palavras-passe ou chaves nesse documento; basta identificar as contas e o percurso autorizado de acesso.
Inventaria o que já funciona antes da alteração
Cria uma lista dos registos e serviços existentes, indicando a função de cada um e se precisa de mudar. Inclui o site, o email, os subdomínios e as verificações de serviços externos. Esta fotografia inicial ajuda a limitar a alteração ao necessário e oferece uma referência concreta para comparar o estado depois da publicação.
No cenário fictício, a página principal muda de alojamento, mas o email e a ferramenta interna continuam onde estão. Não reinicies a zona para facilitar a configuração do site. Prepara uma alteração específica e identifica os registos que ficariam afetados por qualquer substituição.
| Elemento a inventariar | Pergunta a resolver | Evidência a guardar |
|---|---|---|
| Endereço principal e www | Qual será o destino de cada nome? | Registos atuais e valores pedidos pelo alojamento |
| Que configuração permite envio e receção? | Registos e serviço responsável | |
| Subdomínios | Que ferramentas dependem deles? | Nome, destino e responsável |
| Verificações externas | Que serviços usam esses registos? | Finalidade e estado conhecido |
| Site antigo | Como recuperar se a mudança falhar? | Versão, acesso e configuração anterior |
Faz uma cópia da configuração antes de editar e confirma que consegues interpretá-la. Uma captura parcial pode deixar de fora um registo importante. Sempre que o fornecedor permitir, guarda também uma exportação ou o histórico adequado, mantendo esse material num local com o acesso necessário.
A recuperação do código e a recuperação dos serviços são tarefas diferentes. O guia para usar Git e recuperar uma versão do projeto ajuda na primeira. Para a mudança de domínio, acrescenta DNS, configurações do alojamento e dependências externas ao plano de recuperação.
Recolhe os valores atuais do alojamento de destino
Adiciona o endereço pretendido ao projeto de alojamento e consulta as instruções que esse projeto apresenta. Regista o tipo de registo, o nome e o destino exigidos. Não copies valores de uma captura antiga ou de outro projeto, porque uma configuração correta num exemplo pode não corresponder à tua aplicação nem à infraestrutura atual.
A documentação da Vercel para adicionar um domínio orienta a associação do endereço ao projeto e a configuração dos registos. A raiz pode usar um registo A e os subdomínios um CNAME, conforme o método indicado. A plataforma apresenta um CNAME específico do projeto; usa esse valor atual.
Confirma se o endereço está associado à produção, a outro ambiente ou a um redirecionamento. O facto de aparecer na lista de domínios não prova sozinho que vai mostrar a versão pretendida. Compara a configuração com o plano e conserva uma referência ao deployment que queres disponibilizar.
Se o alojamento pedir uma prova de controlo do domínio, segue a instrução específica e verifica o resultado. Não confundas essa prova com a migração de todos os serviços. São operações com objetivos diferentes, mesmo quando ambas envolvem acrescentar um registo na zona DNS.
Prepara uma lista curta de alterações: registo atual, alteração proposta, motivo e resultado esperado. Essa lista deve permitir rever a operação antes de a executar. Se estiveres a usar um agente, pede-lhe para mostrar os valores encontrados e a origem de cada decisão, sem expor credenciais.
Decide como vão funcionar a raiz e o www
Escolhe um endereço principal e define o comportamento das variantes que as pessoas podem escrever. O domínio sem www e o endereço com www precisam de estar preparados, mesmo que um redirecione para o outro. Confirma ainda os caminhos das páginas, para que o visitante chegue ao conteúdo esperado e não apenas à página inicial.
No cenário, podes escolher www.example.com como endereço principal e fazer example.com chegar à mesma página através de redirecionamento. Estes nomes são apenas exemplos. O objetivo é que uma pessoa que abra qualquer variante consiga continuar o percurso sem encontrar uma versão antiga, um erro ou um destino inesperado.
Um registo DNS não define por si um redirecionamento de páginas. Configura o comportamento no alojamento ou na aplicação e testa-o como visitante. Confere também uma página interior: a variante sem www deve levar à página correspondente no endereço principal, quando essa é a regra escolhida.
Se mudarem URLs existentes, prepara uma correspondência entre os endereços antigos e os novos. As orientações do Google para mudanças de URL recomendam destinos relevantes, ligações internas atualizadas e referências canónicas coerentes. Evita enviar indiscriminadamente todas as páginas antigas para a homepage.
Confere os parâmetros que o percurso precisa de conservar, como os usados na atribuição de uma campanha. Testa um exemplo sem dados pessoais e observa o destino final. A mudança de endereço deve manter a informação necessária ao processo, sem transportar parâmetros indevidos por simples hábito.
Prepara a mudança e interpreta a espera com evidência
Define quando aplicar a alteração, o que vais observar e em que condições deves corrigir ou recuperar a configuração anterior. O DNS pode ser visto de forma diferente durante a atualização das caches. Regista a hora e os valores publicados, para distinguires uma espera normal de uma configuração errada ou de um problema na aplicação.
As orientações do Google sobre mudança de alojamento sugerem preparar o TTL com antecedência e acompanhar a transição. Reduzir esse valor apenas depois da mudança não apaga imediatamente cópias que já estavam guardadas. Planeia a operação antes de precisares que todos os visitantes vejam o novo destino.
Se num computador ainda aparece o site antigo, começa por confirmar a resposta DNS observada e o endereço final aberto. Compara com outra rede e com a configuração publicada no fornecedor. Não concluas que tudo é cache apenas porque uma pessoa já consegue ver a nova versão.
Limpar a cache local pode ajudar a testar esse dispositivo, mas não força a atualização de todos os resolvedores na Internet. Também não corrige um registo que aponta para o destino errado. Mantém separados os dados da observação e a hipótese que estás a testar.
Evita alterar repetidamente os valores sem registar o motivo. Cada mudança torna mais difícil perceber qual configuração está a ser observada. Se o destino publicado está correto e a diferença corresponde a caches antigas, acompanha a atualização; se os valores estão errados, corrige a causa identificada.
Verifica HTTPS e o funcionamento real do site
Depois da alteração, abre os endereços finais e verifica separadamente ligação, certificado, conteúdo e funções essenciais. Uma página que carrega não prova que os restantes percursos estão operacionais. Usa uma lista de testes ligada ao objetivo do projeto, para que a confirmação da publicação descreva o que foi realmente observado no destino público.
Confirma que a ligação HTTPS funciona nos nomes usados, incluindo a variante que redireciona. Um certificado válido ajuda a proteger a ligação, mas não demonstra por si que a aplicação está correta ou que todos os seus controlos funcionam. Se surgir um erro, identifica o nome e a condição afetados antes de alterar o DNS novamente.
No site fictício, abre a homepage, uma página de serviço e a página de contacto. Confere imagens, menus, ligações e apresentação em telemóvel. Se existir uma função com envio ou gravação de dados, testa-a apenas dentro do âmbito autorizado e verifica o resultado no destino, em vez de aceitar só uma mensagem visual de sucesso.
Revê integrações que possam depender do endereço. Uma configuração de acesso, uma ligação de retorno ou uma ferramenta incorporada pode continuar a usar o domínio de teste. Regista o que foi conferido e o que ficou pendente. Não apresentes a publicação como concluída se o percurso principal ainda não funciona.
Por fim, confirma os serviços preservados. No caso do email, a comparação dos registos é uma verificação de configuração; um teste autorizado de envio e receção observa o serviço. Distingue essas evidências no registo, para que ninguém confunda ausência de alterações com prova de funcionamento completo.
Confere pesquisa, medição e plano de recuperação
Antes de divulgar o endereço, revê as configurações que permitem encontrar e medir o site e confirma que o plano de recuperação continua disponível. A migração deve conservar o que o projeto precisa para funcionar e ser acompanhado. Uma verificação técnica concluída não garante tráfego, indexação imediata ou resultados comerciais, mas permite identificar problemas concretos.
Confirma que as páginas públicas destinadas à pesquisa não ficaram com um bloqueio temporário de indexação usado durante o desenvolvimento. Mantém protegidas as áreas que não devem ser públicas. Revê sitemap, ligações e endereço canónico de acordo com a versão final, sem tratar a publicação de rascunhos como parte automática da mudança.
Preserva a verificação do Search Console e a configuração de medição que faz sentido manter. O guia sobre Search Console e Google Analytics explica as perguntas que cada ferramenta ajuda a responder. Depois da mudança, observa os dados com o período e o contexto adequados.
Guarda a versão publicada, a hora da alteração e os testes efetuados. Mantém o site anterior recuperável enquanto confirmas a transição. Repor DNS pode ajudar a recuperar um destino, mas não desfaz automaticamente dados criados entretanto noutro sistema. Inclui essas dependências no plano se existirem no teu projeto.
A entrega fica clara quando consegues indicar o endereço final, a versão servida, os serviços preservados e as verificações realizadas. Se ainda houver uma pendência, descreve-a com precisão e define o próximo teste. Esse registo será útil na manutenção e na próxima alteração do site.
Como podes aprender isto no Laboratório da IA
No Laboratório da IA, podes aprender a levar um projeto da preparação até à publicação, compreendendo as decisões e os testes que acompanham o processo. As aulas semanais e os Zooms de acompanhamento semanais ajudam-te a trabalhar com agentes e a rever o resultado. Leva o teu cenário, os serviços existentes e a dúvida que precisas de resolver.
Prepara um inventário do domínio, identifica o alojamento de destino e escreve a lista de verificações antes de mudar valores. Pratica com um âmbito claro e aprende a distinguir código pronto, deployment concluído e site a funcionar no endereço final. A publicação passa a ser uma etapa que consegues explicar e conferir.
Referências e data de revisão
Este artigo foi revisto em 14 de outubro de 2026 com base em materiais do Laboratório da IA sobre publicação, migração e preservação de serviços. As referências oficiais apoiam as configurações descritas. O cenário da pequena empresa é fictício e não representa uma alteração efetuada; os valores concretos devem ser obtidos no projeto de destino.
Aprende a construir isto no Lab.
Trabalha o processo com aulas, materiais e acompanhamento. Leva o que estás a construir e esclarece as dúvidas da tua implementação.
- Preparar o domínio preservando email, subdomínios e serviços.
- Conferir DNS, HTTPS, redirecionamentos e percurso público.
- Praticar publicação nas aulas e Zooms semanais do Laboratório.
Aulas semanais para aprender e aplicar. Zooms de acompanhamento semanais para esclarecer dúvidas. Replay e materiais para retomar o trabalho ao teu ritmo.
Entrar no Laboratório da IA