Hospedagem de Sites em Brasília

O que "gerenciada" quer dizer na prática

Gerenciada não descreve o disco nem o painel: descreve quem está do outro lado no dia em que algo sai do lugar. Em um ambiente sem gestão, o cliente é quem precisa descobrir que o consumo de memória estourou, que a versão de PHP mudou numa atualização automática ou que um certificado deixou de renovar. Nada disso aparece na página inicial do site. Aparece em um log que alguém tem de abrir.

O que encurta o caminho é o que já se conhece do projeto: qual plugin gera os formulários, por que a versão de PHP foi fixada por causa de uma integração, qual rotina roda de madrugada e pesa no servidor. Com essa informação, a conversa começa no log e não no roteiro genérico de limpar cache e desativar plugins.

Vale marcar o limite, porque ele evita frustração depois: hospedagem é infraestrutura, não é manutenção. O servidor mantém o site no ar e entrega as páginas; ele não atualiza WordPress, tema e plugins, não corrige código quebrado e não altera conteúdo. Esse trabalho contínuo é da Administração Web (/manutencao-de-sites/). Os dois se somam: nenhum substitui o outro.

Compartilhada, VPS, dedicado ou nuvem: o que cada tipo de hospedagem entrega

Os nomes dos planos mudam de fornecedor para fornecedor, mas quase todos cabem em poucos desenhos, e o que separa um do outro é quanto do servidor é só seu e quem cuida dele. Entender essa diferença evita os dois erros mais caros: pagar por máquina que o site nunca vai usar e colocar sistema pesado num ambiente que não aguenta.

Hospedagem gratuita e hospedagem embutida em construtor de site ficam fora da lista por um motivo: nelas o endereço, o e-mail e às vezes o próprio conteúdo ficam presos à plataforma, e mudar de lugar depois costuma significar refazer. A escolha certa não é o tipo mais potente, é o que corresponde ao que o site precisa sustentar, e as perguntas que medem isso estão mais adiante nesta página.

• Compartilhada: vários sites dividem o mesmo servidor e os mesmos recursos. É o formato mais barato e atende bem site institucional de tráfego previsível; o risco é o vizinho que consome demais num servidor lotado.
• VPS, servidor virtual privado: uma fatia do servidor com memória e processamento reservados. Traz previsibilidade e liberdade de configuração, e em troca exige alguém que administre o sistema.
• Dedicado: a máquina inteira para um só uso. Faz sentido para aplicação pesada ou para quem precisa de controle total, e é o formato que mais depende de administração competente.
• Nuvem: recursos distribuídos na infraestrutura de grandes provedores, que crescem e diminuem com a demanda. Resolve pico de acesso e sistema que escala, e cobra pelo uso, o que obriga a acompanhar a fatura.
• Gerenciada: não é outro tipo de máquina, e sim um jeito de operar qualquer uma delas, com alguém responsável por manter o ambiente, e não apenas por alugá-lo.

O que o servidor faz antes de o site aparecer: LiteSpeed, cache, HTTP/3 e compressão

Antes de o navegador desenhar qualquer coisa, o servidor precisa receber o pedido, montar ou buscar a página e devolvê-la. Esse intervalo, o tempo até o primeiro byte, é a parte da velocidade que pertence à hospedagem, e ele pesa em tudo o que vem depois. O restante do carregamento, com imagens, scripts e as medidas que o Google chama de Core Web Vitals, depende do próprio site, e está explicado na página de consultoria de SEO.

O LiteSpeed é o servidor web do plano, e três recursos dele fazem diferença prática. O cache guarda a página já montada e a entrega pronta aos visitantes seguintes, em vez de consultar o banco de dados a cada acesso; em WordPress, isso é feito pelo plugin oficial LiteSpeed Cache, que conversa direto com o servidor. O HTTP/3 usa o protocolo QUIC para abrir a conexão com menos idas e voltas, o que ajuda justamente na rede móvel instável. E a compressão Brotli reduz o tamanho do HTML, do CSS e do JavaScript no caminho.

Dá para conferir tudo isso neste próprio site, que é servido por LiteSpeed: a resposta anuncia HTTP/3, o HTML chega comprimido em Brotli, a conexão usa TLS 1.3, e os arquivos de estilo e de script vão com cache de um ano no navegador, porque a versão no endereço muda a cada publicação. Qualquer pessoa confirma isso na aba de rede das ferramentas de desenvolvedor do navegador.

Disco não é o único limite: memória, processos e número de arquivos

Plano de hospedagem costuma ser comparado pelo espaço em disco, e ele é o limite menos provável de derrubar um site. Em ambiente com vários sites, cada conta também tem teto de memória, de processamento e de processos atendidos ao mesmo tempo, e é esse teto que aparece quando uma campanha joga muita gente na mesma página no mesmo minuto: o site não cai por falta de espaço, ele passa a responder com erro para quem chegou por último.

Existe ainda o limite de quantidade de arquivos, que pega de surpresa quem nunca pensou nele. Cache de plugin, miniaturas geradas pelo WordPress para cada imagem enviada, cópias de segurança guardadas dentro da própria conta e caixas de e-mail com milhares de mensagens contam arquivo por arquivo. Uma conta com disco sobrando pode estar no limite de arquivos, e aí o painel recusa até o envio de uma imagem nova.

Por isso o dimensionamento pergunta como o tráfego se comporta, e não apenas quanto ele soma no mês, e por isso rotina que acumula arquivo dentro da conta, como backup guardado no mesmo servidor, é tratada como problema a resolver, e não como segurança.

Tráfego que não é gente: robôs também consomem o plano

Uma parte das visitas de qualquer site não vem de pessoas. Rastreadores de buscadores, rastreadores de ferramentas de inteligência artificial, monitores de disponibilidade, ferramentas de SEO de terceiros e robôs que tentam senha na página de login pedem páginas ao servidor do mesmo jeito que um visitante, e cada pedido usa memória e processamento da conta.

Os robôs legítimos leem o robots.txt e obedecem ao que ele diz, e é por esse arquivo que se decide quem entra. Este site, por exemplo, libera por decisão declarada os rastreadores de buscadores e de IA, porque quer ser lido e citado por eles. Os robôs mal-intencionados ignoram o arquivo, e contra eles valem medidas de servidor e de aplicação: limite de tentativas de login, bloqueio de endereços que insistem e página de login fora do caminho padrão.

O efeito prático aparece em dois lugares. No consumo da conta, quando um pico de robô chega perto do teto de processos e o visitante de verdade recebe erro. E na leitura da audiência, quando a ferramenta de estatística do servidor soma robô como visita e o número parece muito maior do que o Analytics mostra. O Analytics tende a filtrar boa parte desses acessos; o log do servidor mostra tudo.

Versão de PHP: o servidor oferece, o site precisa acompanhar

WordPress e a maior parte dos sistemas de site rodam em PHP, e cada versão da linguagem tem data para parar de receber correção de segurança. Pelo calendário oficial do projeto, a versão 8.2 recebe correções de segurança até 31 de dezembro de 2026, a 8.3 até o fim de 2027, a 8.4 até o fim de 2028 e a 8.5 até o fim de 2029. A 8.1 e as anteriores já estão fora de suporte, e o WordPress recomenda hoje PHP 8.3 ou superior.

O papel da hospedagem é oferecer versões suportadas e permitir escolher a versão por site, porque nem todo site acompanha a mais nova no mesmo dia. Tema antigo e plugin abandonado costumam quebrar na troca, e é por isso que a mudança de versão se testa antes numa cópia. Esse teste, e a correção do que não acompanhou, fazem parte da administração web; à hospedagem cabe garantir que a versão certa exista e esteja disponível.

Para 2026, a conta é simples: site que ainda roda em 8.1 ou anterior já está sem correção de segurança da linguagem, e site em 8.2 entra na mesma situação no primeiro dia de 2027.

O que um WordPress precisa do servidor, além de espaço

O WordPress publica os requisitos que recomenda para o ambiente: PHP 8.3 ou superior, MariaDB 10.11 ou MySQL 8.0 em diante e HTTPS em toda instalação. Rodar em versões mais antigas ainda é tecnicamente possível, e a própria página de requisitos avisa que isso expõe o site a vulnerabilidades. É o mínimo que se confere antes de hospedar um WordPress em qualquer lugar.

Há um detalhe de funcionamento que o painel não mostra. As tarefas agendadas do WordPress, como publicar um post marcado para depois, enviar e-mail de formulário em fila ou rodar a rotina de um plugin, dependem do WP-Cron, que é disparado quando alguém carrega uma página. Em site com pouca visita, a tarefa atrasa até o próximo acesso; em site com muita visita, a verificação roda o tempo todo sem necessidade. Nos dois casos, a solução costuma ser trocar esse disparo por uma tarefa agendada de verdade no servidor.

O resto do desempenho de um WordPress sai da combinação entre servidor e site: cache de página no servidor, imagens no tamanho certo e poucos plugins pesados. A parte do servidor está nesta página; a parte do site é da administração web e de quem construiu o tema.

Certificado e e-mail: os dois itens que ninguém explica

Certificado, e-mail no domínio e filtro de spam entram em toda lista de hospedagem como se fossem óbvios, e são justamente os que mais geram chamado. Sem entender o que cada um resolve, é impossível comparar dois ambientes.

• Certificado SSL: cifra o tráfego entre o navegador do visitante e o servidor. Sem ele o navegador marca a página como não segura, e o aviso aparece bem no momento em que o visitante ia digitar nome e telefone. O cadeado protege o transporte da informação; ele não impede invasão, e essa confusão é comum. Todo certificado tem validade e precisa ser reemitido, e é isso que o painel de certificados do plano administra.
• E-mail no domínio: contato@suaempresa.com.br em vez de um endereço gratuito. Criar a caixa é a parte simples; a difícil é a entrega. Os registros SPF, DKIM e DMARC ficam no DNS do domínio e informam aos provedores de destino quem tem autorização para enviar em nome dele. Quando esses registros ficam desatualizados, a mensagem sai da caixa e cai no spam do destinatário: do lado de cá parece que funcionou, e o cliente jura que nunca recebeu.
• Filtro anti-SPAM: trabalha no sentido inverso, sobre o que chega. A classificação por grau de tolerância existe porque o ajuste é individual: quem recebe currículo, nota fiscal e cotação de fornecedor desconhecido precisa de um filtro mais frouxo do que quem troca mensagem apenas com uma lista fechada de contatos.
• Backup gerenciado: não é item do plano de hospedagem. É um dos itens da Administração Web (/manutencao-de-sites/), junto com as atualizações testadas antes de ir ao ar. Vale saber disso na hora de contratar, e não no dia em que a cópia faz falta.

O certificado de 90 dias, e por que a renovação precisa ser automática

O certificado que habilita o cadeado tem prazo, e o prazo está encurtando por decisão do setor. Em abril de 2025, o CA/Browser Forum, que reúne autoridades certificadoras e fabricantes de navegador, aprovou um calendário de redução da validade máxima dos certificados públicos: 200 dias a partir de 15 de março de 2026, 100 dias a partir de março de 2027 e 47 dias a partir de março de 2029.

O Let's Encrypt, autoridade gratuita usada por grande parte dos sites, já emite certificados de 90 dias e anunciou a transição para 45 dias até 2028. O certificado deste site é do Let's Encrypt, com validade de 90 dias.

Com prazos assim, certificado renovado à mão vira queda com data marcada: basta uma renovação esquecida para o navegador bloquear o site com aviso de conexão não segura. A pergunta a fazer a qualquer hospedagem não é se ela oferece certificado, e sim se a emissão e a renovação são automáticas para todos os domínios e subdomínios, inclusive os que forem apontados para o servidor depois.

E-mail que chega: as exigências do Gmail para quem envia

Desde fevereiro de 2024, o Gmail publica regras para quem envia mensagens às caixas dele, e elas valem para empresa pequena também. Todo remetente precisa ter SPF ou DKIM configurado no domínio, registros de DNS direto e reverso válidos para o servidor de envio, conexão com TLS e taxa de denúncia de spam abaixo de 0,3%. Quem envia mais de 5 mil mensagens por dia para contas Gmail precisa, além disso, de SPF e DKIM juntos, de DMARC, de alinhamento entre o remetente e o domínio autenticado e de descadastro com um clique nas mensagens de marketing.

Na prática, isso muda duas coisas para quem tem e-mail no domínio. O e-mail do dia a dia, a proposta, o boleto, a resposta ao cliente, depende desses registros tanto quanto a newsletter: sem autenticação, a mensagem pode ser recusada ou cair no spam. E disparo de campanha pelo mesmo servidor e pelo mesmo domínio do e-mail comercial põe a reputação dos dois no mesmo balde, de modo que uma lista ruim derruba a entrega das mensagens de trabalho.

O DMARC tem ainda uma função que pouca empresa aproveita: ele permite receber relatórios de quem está enviando e-mail em nome do domínio. É assim que aparece um sistema de nota fiscal ou uma ferramenta de marketing enviando sem autenticação configurada, ou alguém tentando se passar pela empresa.

IMAP ou POP3: por que o e-mail aparece num aparelho e some do outro

As contas do plano funcionam com os dois protocolos de leitura, e a escolha feita ao configurar o celular ou o computador explica boa parte das reclamações de e-mail sumido. No IMAP, as mensagens ficam no servidor e cada aparelho mostra o mesmo conteúdo: o que foi lido, apagado ou movido no celular aparece assim no computador. No POP3, o programa baixa as mensagens para o aparelho e, conforme a configuração, apaga a cópia que estava no servidor.

É por isso que a mensagem baixada por POP3 no computador do escritório não aparece no celular, e que a troca de máquina às vezes leva embora anos de correspondência que só existiam naquele disco. Para equipe que lê e-mail em mais de um aparelho, IMAP é o padrão sensato. O cuidado que ele pede é o espaço: como tudo fica no servidor, a caixa cresce, e a cota dividida com os arquivos do site precisa ser acompanhada.

O webmail, quando usado, lê a mesma caixa que o IMAP e serve de conferência rápida: se a mensagem está no webmail e não aparece no aparelho, o problema está na configuração do aparelho, e não no servidor.

E-mail no mesmo servidor do site ou num serviço separado

E-mail no domínio não precisa morar no mesmo lugar do site. O registro MX do DNS decide para onde vão as mensagens, e ele pode apontar para o servidor da hospedagem ou para um serviço de correio separado, como os pacotes de e-mail corporativo das grandes plataformas, enquanto o site continua onde está.

Manter os dois juntos é mais simples e costuma sair mais em conta para equipe pequena: um painel, um contrato, contas sem custo por usuário. Separar faz sentido quando o correio é o centro da operação: equipe grande, caixas que precisam de muito espaço, agenda e documentos compartilhados integrados ao e-mail ou exigência de retenção e auditoria das mensagens. Separar também isola os dois problemas, porque uma queda no servidor do site deixa de parar o e-mail.

O que não pode acontecer é a separação pela metade: MX apontado para o serviço novo e registros de SPF e DKIM ainda descrevendo o servidor antigo. A mensagem sai, mas chega sem autenticação, e as regras de remetente descritas acima fazem o resto.

O painel de controle: o que dá para fazer sozinho e o que é melhor pedir

O plano inclui painel para domínios, subdomínios, bancos de dados, certificados e contas de e-mail, e parte do que ele faz é tarefa de rotina que a própria empresa resolve em minutos. Outra parte parece igualmente simples e derruba site ou e-mail com um clique, e vale conhecer a diferença antes de entrar.

Na dúvida, a regra é simples: se a alteração mexe em algo que outro serviço usa, como o DNS, o banco de dados de um sistema ou a versão da linguagem, ela merece uma conversa antes. O que se desfaz sozinho e não afeta mais ninguém pode ser feito direto.

• Pode fazer sozinho: criar e remover caixas de e-mail, trocar senha de conta, ajustar filtro de spam da própria caixa, criar redirecionamento de mensagem.
• Pode fazer sozinho, com atenção: criar subdomínio para um hotsite e baixar uma cópia de arquivos antes de uma mudança.
• Melhor pedir antes: editar registros de DNS, porque um MX ou um TXT errado para o e-mail ou quebra a autenticação.
• Melhor pedir antes: trocar a versão de PHP de um site em produção, excluir ou restaurar banco de dados, apagar arquivos da raiz do site.
• Melhor pedir antes: mudar a pasta para onde um domínio aponta, o que pode tirar o site do ar sem mensagem de erro clara.

DNS sem mistério: os registros que levam o domínio ao site e ao e-mail

O DNS é a lista que diz a qualquer computador do mundo para onde vai cada serviço de um domínio. Ele não fica necessariamente dentro da hospedagem: fica onde o domínio foi configurado para ser administrado, que pode ser o próprio registro.br, a hospedagem ou um serviço separado. Saber onde ele é editado é metade da solução de qualquer problema de site ou e-mail fora do ar.

Uma edição errada num único registro explica quedas que parecem misteriosas: site no ar e e-mail parado, e-mail funcionando e site antigo aparecendo, verificação de ferramenta que nunca conclui. Por isso, antes de qualquer mudança, vale guardar uma cópia da zona de DNS como ela está.

• A e AAAA: apontam o domínio para o endereço IP do servidor, em IPv4 e IPv6. É o registro que decide em que servidor o site abre.
• CNAME: faz um nome apontar para outro nome, como o www apontando para o domínio principal ou um subdomínio apontando para um serviço externo.
• MX: indica qual servidor recebe o e-mail do domínio. Site e e-mail podem morar em lugares diferentes, e é o MX que separa os dois.
• TXT: guarda textos de verificação e de autenticação, como SPF, DKIM e DMARC, e as provas de propriedade pedidas pelo Google e por outras ferramentas.
• TTL: o tempo que outros servidores podem guardar a resposta antes de perguntar de novo. Baixá-lo dias antes de uma troca de servidor encurta a janela em que parte da internet ainda enxerga o endereço antigo.

Vários endereços no mesmo plano: .com e .com.br, domínio antigo e subdomínio

É comum a empresa ter mais de um domínio: o .com.br e o .com, a grafia com e sem hífen, o nome antigo de antes de uma mudança de marca, o endereço de uma campanha. Todos podem apontar para a mesma hospedagem, e a decisão que importa é qual deles é o endereço principal. Os outros devem redirecionar para ele de forma permanente, com o código 301, e não abrir o mesmo site em paralelo.

A diferença não é estética. O mesmo conteúdo publicado em dois domínios obriga o Google a escolher qual mostrar, divide os links que o site recebe e confunde o visitante que salvou um endereço e cai em outro. Com o redirecionamento permanente, o buscador entende que existe um endereço só e concentra nele o que os outros acumularam. Este site, por exemplo, responde apenas no endereço sem www, e as versões com www e as URLs antigas redirecionam para o endereço atual.

Subdomínio é outra coisa: um endereço como loja.suaempresa.com.br ou teste.suaempresa.com.br, que funciona como site separado dentro do mesmo domínio e precisa de certificado e configuração próprios. Serve para loja em plataforma diferente, ambiente de teste ou área de cliente. Cada domínio e subdomínio a mais entra na conta do plano, e é por isso que a quantidade de endereços está entre as perguntas de dimensionamento.

O domínio vence separado da hospedagem

Domínio e hospedagem são dois contratos diferentes, e essa é a origem de boa parte das quedas que não têm nada a ver com servidor. O .com.br é registrado no registro.br; a hospedagem só responde pelo endereço enquanto o DNS aponta para ela. Se o registro vence, o servidor continua ligado, com o site inteiro intacto dentro dele, e mesmo assim ninguém acessa.

O erro clássico é o aviso de renovação chegar a um endereço que a empresa não controla mais: o e-mail de um ex-funcionário ou o de quem montou o site anos atrás e não trabalha mais com você. Ninguém vê a cobrança. Quando o domínio deixa de responder, o site sai do ar e o e-mail para junto, e é o e-mail que se percebe primeiro. Passado o período de carência, o domínio pode ser liberado para outra pessoa registrar.

Por isso o vencimento entra na rotina do ambiente, e o contato administrativo do registro precisa ser um endereço que alguém da empresa realmente lê. Vale rodar esta conferência mesmo que a hospedagem esteja em outro fornecedor (o tema da titularidade, de quem fica com o quê, é tratado em Criação de Sites (/criacao-de-sites/):

• Onde o domínio está registrado hoje e quem tem o acesso a esse painel.
• Se o e-mail de contato administrativo do registro ainda é lido por alguém da empresa.
• Se domínio e hospedagem vencem em fornecedores e datas diferentes.
• Se o DNS aponta para o servidor em que o site realmente está, e se alguém sabe onde esse DNS é editado.

Quando o servidor oscila, quem reclama primeiro é o e-mail

Site fora do ar é um prejuízo silencioso: quem não conseguiu abrir a página quase nunca avisa. Com o e-mail acontece o contrário: a queda vira telefonema no mesmo dia, porque do outro lado tem alguém esperando um documento que precisava sair naquela hora.

O tamanho do estrago depende do que trafega ali. Em uma operação que vende pela internet, a conta aparece no carrinho abandonado. Em um escritório que trabalha por documento, peça processual, exame, guia, nota, projeto para aprovação, a conta aparece no prazo de outra pessoa, e o anexo pesado ainda ocupa disco no caminho. São dois desenhos de ambiente diferentes, e a pergunta sobre volume de e-mail costuma pesar mais do que a pergunta sobre visitas.

A Criattus mantém escritório em Águas Claras, Brasília, com telefone e WhatsApp no 61 3024 1336. Para assuntos que travam por falta de acesso: domínio herdado de um fornecedor antigo, painel sem senha conhecida, dimensionamento de um ambiente que já vive no limite, sentar à mesa costuma render mais que trocar mensagem, e essa é uma opção real para quem está no DF.

Onde o servidor fica, e o que a LGPD diz sobre isso

Uma dúvida comum de escritório de advocacia, clínica e contabilidade é se o site precisa estar hospedado no Brasil para cumprir a LGPD. A lei não exige isso. Ela permite a transferência internacional de dados pessoais nas hipóteses do artigo 33, e a ANPD regulamentou o tema na Resolução CD/ANPD nº 19, de agosto de 2024, que traz cláusulas-padrão contratuais para essas transferências e deu prazo de adequação encerrado em agosto de 2025.

O que a lei exige de qualquer forma é saber onde os dados estão e quem tem acesso a eles. Formulário de contato guarda nome, telefone e mensagem; loja guarda endereço e histórico de compra; caixas de e-mail guardam anexos com documento de cliente. Esse inventário entra na política de privacidade do site e no registro das operações de tratamento da empresa, e a hospedagem é uma das respostas dele.

A localização também tem efeito técnico. Quanto mais longe o servidor está de quem acessa, maior o tempo de ida e volta de cada pedido, e isso aparece no tempo até o primeiro byte. Para público concentrado no DF, servidor no Brasil tende a responder mais rápido do que um do outro lado do continente, e rede de distribuição de conteúdo encurta essa distância entregando os arquivos a partir de um ponto próximo do visitante.

Ambiente de teste: mudança grande se confere onde ninguém vê

Tema novo, troca de versão de PHP, plugin de pagamento, redesenho de página: nenhuma dessas mudanças deveria estrear no site que os clientes estão usando. O caminho seguro é uma cópia em ambiente de teste, normalmente num subdomínio, onde se confere tudo antes de publicar. É por isso que ambiente de teste aparece entre as perguntas de dimensionamento: ele ocupa espaço, banco de dados e certificado próprios.

O erro comum com ambiente de teste é deixá-lo aberto. Cópia do site num endereço público pode ser encontrada e indexada pelo Google, e aí passa a competir com o site verdadeiro pela mesma busca, com conteúdo duplicado e às vezes com dados de teste à mostra. Bloquear só pelo robots.txt não resolve: o Google explica que esse arquivo não é mecanismo para manter uma página fora dos resultados. O que resolve é senha no acesso ao ambiente, e a marcação noindex como segunda camada.

Quando a mudança é aprovada, o caminho de volta também precisa de cuidado: publicar o que foi testado sem trazer junto a senha, o bloqueio de indexação e as configurações do ambiente de teste. Esquecer o noindex ligado ao publicar é uma das formas mais rápidas de um site sumir do Google sem ninguém entender por quê.

Como ler uma promessa de disponibilidade antes de assinar

Percentual de disponibilidade parece tudo igual e não é. Num mês de 30 dias, 99% de disponibilidade admite até 7 horas e 12 minutos fora do ar; 99,9% admite 43 minutos; 99,99%, pouco mais de 4 minutos. A distância entre o primeiro e o último número é a distância entre uma tarde perdida e uma pausa para o café.

Mais importante que o número é o que o contrato conta como indisponibilidade. Manutenção programada costuma ficar fora da conta, a medição pode ser feita pelo próprio fornecedor, de dentro da rede dele, e a compensação por descumprimento, quando existe, costuma ser crédito na mensalidade, que não devolve o pedido que deixou de chegar. Vale ler essas três cláusulas antes do percentual.

Por isso monitoramento externo, que testa o site de fora em intervalos curtos e avisa quando ele para de responder, diz mais do que qualquer promessa: ele mostra a disponibilidade que o visitante realmente teve, e não a que o contrato calculou.

O que perguntamos antes de dimensionar o ambiente

A conversa de hospedagem é técnica e tem sempre as mesmas perguntas. Elas existem por um motivo prático: ambiente apertado cai no pior momento, e ambiente folgado demais cobra por recurso parado. Se você já tiver estas respostas em mãos, a proposta sai bem mais rápido:

• O que roda ali: site institucional, que entrega páginas praticamente prontas; catálogo com busca; loja virtual, que processa carrinho e checkout a cada visita; ou sistema com rotinas em segundo plano. Cada um consome processamento de um jeito.
• Como o tráfego se comporta: visita distribuída ao longo do mês ou concentrada por campanha, que joga muita gente na mesma página no mesmo horário.
• Quanto o disco precisa segurar: arquivos do site e caixas de e-mail dividem o mesmo espaço, e mídia pesada, vídeo institucional, catálogo de imagens, portfólio fotográfico, muda a conta. As caixas crescem sozinhas, ano após ano, acumulando anexo.
• Quantos endereços entram: domínio principal, subdomínios, ambiente de teste para conferir antes de publicar e hotsite de campanha. Cada um ocupa estrutura e pede certificado próprio.
• O que a aplicação exige: versão de linguagem, banco de dados, tarefas agendadas e integrações externas que dependem de endereço fixo. Quando o ambiente não atende ao que a aplicação pede, dizemos isso antes de fechar, e não depois.

Trocar de hospedagem sem o site sair do ar

Migração é o momento em que mais site cai, e quase sempre pelo mesmo motivo: alguém aponta o domínio para o servidor novo antes de o servidor novo estar pronto. A ordem correta é o contrário, e ela não tem mistério.

Primeiro o ambiente novo é montado e o site é publicado nele, acessível por um endereço temporário. Depois tudo é conferido no ambiente novo com o site antigo ainda no ar: páginas abrindo, formulário enviando de verdade, certificado válido, e-mails entrando e saindo. Só então o domínio é apontado, e a troca acontece com o destino já funcionando.

A parte mais esquecida é o e-mail. Domínio carrega o site e o correio na mesma configuração, e é comum a migração levar o site e deixar as mensagens caindo no servidor antigo por horas. Quando isso acontece, ninguém percebe pelo site: percebe porque um pedido de orçamento nunca chegou. Por isso as caixas são migradas com o conteúdo antes da troca, e não depois.

Existe ainda um intervalo em que parte da internet enxerga o servidor novo e parte ainda enxerga o antigo, porque a informação de endereçamento leva tempo para se propagar. Durante essa janela o site antigo precisa continuar de pé, respondendo normalmente. Desligar o servidor anterior no mesmo dia é o erro que transforma uma migração tranquila em indisponibilidade.

Antes de tudo isso, uma cópia completa do que existia. Não a cópia automática do provedor, que morre junto com a conta se ela for encerrada, mas um arquivo guardado fora do provedor, em poder de quem contratou.