O site não carrega: a primeira pergunta é para quem.
Antes de haver causa há uma bifurcação: o site está em baixo para toda a gente, ou só para quem se queixou. São dois problemas sem nada em comum, e responder à pergunta errada custa a tarde.
Um site que não carrega pode estar em baixo, ou pode estar perfeitamente de pé com alguma coisa a impedir uma pessoa concreta de lá chegar. Do lado de quem se queixa, os dois casos são idênticos: um ecrã que não abre.
Do lado de quem tem de resolver, não têm nada a ver um com o outro. No primeiro caso o trabalho é no servidor. No segundo é DNS em cache, um IP bloqueado por um firewall, uma rota partida do operador, ou um browser a servir um erro guardado — e mexer no servidor não só não resolve como introduz um problema novo em cima do que já havia.
Por isso a primeira acção nunca é abrir o painel do alojamento. É verificar o site a partir de um sítio que não seja a tua rede nem a do cliente, e ver o que responde de facto.
// causas prováveis
Por onde é que isto costuma vir.
Por ordem de frequência e não por ordem de gravidade. A primeira da lista explica mais casos do que as outras todas juntas.
-
DNS em cache no computador de quem se queixa
O site mudou de servidor nas últimas horas e a máquina dele guardou o endereço antigo. Toda a gente vê o site novo e ele vê o vazio. Um `ipconfig /flushdns` resolve, e reiniciar o router costuma resolver também.
-
O IP foi bloqueado pelo firewall do alojamento
Tentativas de login falhadas, um scanner, pedidos a mais. O site fica em baixo literalmente só para uma pessoa. É mais comum do que parece com clientes que erram a palavra-passe várias vezes.
-
O servidor está mesmo em baixo
A máquina não responde, o alojamento tem uma avaria, ou o plano foi suspenso por falta de pagamento. A verificação externa devolve erro de ligação e não um código de estado.
-
O certificado expirou
O browser recusa mostrar a página e o aviso ocupa o ecrã todo. Muita gente descreve isto como "o site não carrega" porque nunca chega a ver o site.
-
A rota entre a rede dele e o servidor está partida
Acontece com um operador concreto e não com os outros. Testar pelos dados do telemóvel, com o Wi-Fi desligado, é o teste de dez segundos que confirma isto.
// diagnóstico
Passo a passo, do que custa menos ao que custa mais.
Cada passo elimina hipóteses. Saltar um passo poupa dois minutos e costuma custar uma hora — a ordem é a parte que interessa.
- 01
Verifica de um servidor que não é teu
É o passo que separa os dois mundos. Uma verificação externa devolve o código de estado e o tempo de resposta a partir de fora — se responder 200, o site está de pé e o problema é de quem se queixou. O "Está em baixo, ou és só tu?" faz isto sem conta nenhuma.
- 02
Se está de pé, testa em janela anónima e nos dados do telemóvel
A janela anónima elimina cache e extensões. Os dados do telemóvel eliminam a rede e o DNS de casa. Se abrir num dos dois, já sabes de que lado está o problema, e nenhum deles é o servidor.
- 03
Limpa o DNS local
No Windows, `ipconfig /flushdns`. No macOS, `sudo dscacheutil -flushcache`. É obrigatório sempre que o site tenha mudado de alojamento nas últimas 48 horas, e é a explicação para metade dos casos de "só eu é que não vejo".
- 04
Se não está de pé, olha para o que respondeu
Um 500 é código. Um 502 ou 504 é um intermediário. Um 503 pode ser manutenção. Nenhuma resposta é o servidor em baixo ou o DNS a não resolver. Cada um desses casos tem página própria, e o código de estado é o que te encaminha.
- 05
Confirma que o domínio ainda é vosso
Domínios expiram e a renovação automática falha com um cartão que caducou. É um dos poucos casos em que o site "desaparece" por inteiro, e é humilhante descobri-lo tarde. Uma consulta ao registo do domínio responde em segundos.
- 06
Só então é que vale a pena falar com o alojamento
Com a hora exacta, o código de estado e o que já testaste. É a diferença entre uma resposta útil e três emails a pedir informação que já tinhas.
O primeiro passo é sempre o mesmo — ver de fora o que o servidor responde de facto. Faz isso aqui, a partir de um servidor em Portugal. Sem conta, sem custo, e não guardamos o que verificares.
// que não volte
Como evitar que volte a acontecer sem dares por isso.
Resolver o incidente é metade do trabalho. A outra metade é a parte que ninguém factura e é a que decide se há um terceiro.
-
Verifica de fora antes de mexer
É a única forma de saber se estás a resolver um problema que existe. Mexer num servidor saudável por causa de um DNS em cache é como se corrigem coisas que não estavam partidas.
-
Põe o domínio e o certificado a avisar antes de expirarem
São as duas falhas com data marcada e as duas mais evitáveis. Ambas deitam o site abaixo por completo e ambas avisam com meses de antecedência, se alguém estiver a ouvir.
-
Guarda o que respondeu, e não só que falhou
O código de estado, a hora e o tempo de resposta. Sem esses três, o incidente da semana passada é uma história e não um facto.
-
Não dependas de alguém reparar
Um site de cliente pode estar em baixo horas antes de alguém tentar entrar. Uma verificação automática de fora é a única coisa que muda a ordem por que se fica a saber.
// limites
Onde é que esta página encalha.
Uma página de diagnóstico que não diz onde acaba manda-te dar voltas até desistires. Estes são os casos em que não chega.
- Uma verificação externa vê a página de entrada. Se o site responde 200 e a área de clientes está avariada por dentro, ela diz que está tudo bem e está errada na prática.
- Não conseguimos ver o que se passa na rede de quem se queixou. Podemos dizer que o site responde de fora — o resto do caminho é do lado dele e diagnostica-se aí.
- Um site lento não é um site em baixo, e nenhum código de estado o distingue. Se a queixa é de demora, o número a olhar é o tempo de resposta.
- Se o site está atrás de uma protecção contra bots agressiva, uma verificação automática pode apanhar uma página de desafio em vez do site. Nesse caso a resposta não é sobre o site, é sobre a protecção.
// perguntas
O que nos perguntam a seguir.
O site abre no telemóvel e não no computador. O que é?
Quase de certeza DNS em cache ou uma extensão do browser. O telemóvel usa outra rede e outro resolvedor, por isso vê o estado actual. Limpa o DNS no computador e testa em janela anónima antes de procurar mais longe.
Quanto tempo demora a propagação de DNS?
Depende do TTL que estava definido antes da mudança, e é por isso que se baixa o TTL uns dias antes de migrar. Na prática costuma estar resolvido em poucas horas, e o limite de 48 horas é o pior caso e não a norma.
Como é que sei se fui bloqueado pelo firewall do alojamento?
Se o site abre por dados móveis e não por Wi-Fi, e uma verificação externa diz que está online, é a hipótese mais provável. Confirma-se pedindo ao alojamento — a maior parte desbloqueia à primeira e diz-te qual foi a regra.
// erros vizinhos
Se afinal não era este.
Metade do diagnóstico é perceber que se estava a olhar para o erro errado. Estes três são os que mais se confundem com este.
-
O DNS não resolve
A tradução do nome para o endereço falhou. Propagação, configuração errada ou domínio expirado.
-
O WordPress não abre
Ecrã branco, wp-admin inacessível ou erro de base de dados. Cinco problemas com o mesmo sintoma, separados por ordem.
-
O site está muito lento
Servidor, base de dados ou browser? Como medir antes de tocar em nada, e o que atacar primeiro.
E se acontecer às três da manhã?
Reparar que um site não carrega é uma coisa que acontece por acidente: alguém tenta entrar. A De Olho vai tentar entrar por ti a cada minuto, de um servidor em Portugal, e avisar-te quando a resposta mudar. Entretanto, a verificação isolada já dá para fazer hoje — é a mesma verificação, o que falta é ela repetir-se sozinha.
A De Olho abre em 2026 e ainda não dá para usar. Quem estiver na lista de espera fica a saber primeiro e mantém o preço de lançamento enquanto a subscrição durar.