Já tentou abrir seu próprio site e só viu erro? É como chegar à loja e encontrar a porta trancada bem no horário de pico. Bate aquele frio na barriga, porque cada minuto parado custa atenção, leads e vendas. A boa notícia: em poucos minutos dá para descobrir onde está o gargalo e agir.
“Site fora do ar” não é um único problema. Pode ser conexão local, DNS, domínio vencido, servidor no limite, aplicativo quebrado ou certificado expirado. O Google e os clientes não esperam. Em casos de manutenção curta, a própria documentação do Google Search Central orienta usar código 503 com Retry-After para sinalizar indisponibilidade temporária, preservando rastreamento quando bem aplicado.
O erro comum que vejo: sair reiniciando tudo, limpar cache ou “esperar propagar” sem checar a camada certa. Testes genéricos do tipo “está fora do ar só para mim?” ajudam, porém não mostram a causa. Guias superficiais ignoram DNS, certificado, logs e o básico do Search Console, e aí a correção vira tentativa e erro.
O que você vai encontrar aqui: um checklist de 10 minutos, na ordem certa, para separar conexão de servidor, validar domínio e DNS, conferir certificado e decidir quando usar 503 com segurança. Também mostro como reduzir o dano agora (SEO, anúncios, comunicação) e como configurar monitoramento para não passar por isso de novo.
Primeiro: é o site mesmo ou só a sua conexão?
Comece pelo básico: confirme se a falha é sua ou do site. Abra a página no celular com dados móveis e compare com o Wi‑Fi. Teste também em outro navegador em janela anônima. Em segundos você separa problema local de pane real.
Teste de outra rede: Wi‑Fi x 4G/5G e modo anônimo
Desligue o Wi‑Fi e teste no 4G/5G: se abrir no celular e não no seu Wi‑Fi, a falha é local (cache, DNS, VPN, firewall ou provedor). Se falhar nos dois, o site pode estar realmente fora.
No anônimo você elimina cookies e extensões como causa. Trocar de navegador ajuda a expor conflito de plugin. Fontes práticas sugerem validar em outro dispositivo e rede móvel para isolar a origem do erro de forma rápida.
Verificação em múltiplas regiões para descartar falha local
Verifique em várias regiões: use um checker global para testar de diferentes países e cidades. Se alguns pontos carregam e outros não, suspeite de propagação de DNS parcial, rota regional ou borda de CDN instável.
Se falhar em todos os pontos, o destino está com problema. Se só você falha e os checkers passam, a causa está na sua rede, VPN ou provedor. Serviços como Host‑Tracker e monitorias multi‑POP aceleram esse diagnóstico.
Checagem rápida de DNS e latência (ping/trace) sem complicar
Ping e traceroute, sem drama: um ping com latência estável e 0% de perda indica caminho de rede saudável; perda alta sugere falha de rota. O traceroute mostra até onde o tráfego chega antes de morrer.
Confirme o DNS com um resolvedor público: compare o IP do seu domínio no seu DNS e no 8.8.8.8. Se discordarem, há cache DNS desatualizado. Observação importante: muitos servidores bloqueiam ICMP; trate o ping como indício, não prova final.
Sinais de cache, CDN e firewall bloqueando só você
Cache/CDN/WAF podem mirar você: se a página carrega no 4G/5G e falha no seu Wi‑Fi, mas checkers externos veem tudo ok, desconfie de bloqueio por VPN/proxy, firewall local ou regra de WAF/CDN para sua faixa de IP.
Pistas úteis: erro em um navegador e não em outro aponta para extensão; carregar ao desativar VPN sugere IP de VPN bloqueado; variar por região indica CDN. Limpar cache local e da CDN, revisar listas de bloqueio e testar sem VPN costumam resolver.
As 6 causas mais comuns, da mais provável à mais rara
Quase todo apagão segue o mesmo roteiro: na prática, as causas se repetem. Eu checo sempre nesta ordem porque resolve mais rápido e evita ruído.
Hospedagem no limite: CPU, memória e conexões simultâneas
Recursos no limite derrubam o site: quando CPU, RAM ou workers estouram, surgem 5xx e 503 por sobrecarga ou manutenção. Em planos compartilhados, aparece até 508 Resource Limit Reached. Olhe gráficos de carga e logs antes de qualquer mudança.
Segundo guias técnicos, 503 é comum com pools esgotados (ex.: PHP‑FPM) ou autoscaling atrasado; CDNs podem retornar 503 se o origin sem saúde falhar. Ajuste limite de workers, alivie requisições lentas e verifique status da hospedagem.
Erro de aplicação após deploy, plugin ou atualização
Erro após deploy é frequente: conflito de plugin, atualização mal-sucedida ou arquivo .maintenance esquecido causam falhas. O padrão: 500, página branca ou “erro ao conectar ao banco”.
Relatos de campo mostram WordPress sensível a incompatibilidade de PHP e mudanças de dependências. Logue erros do app e do servidor, reverta o último deploy, desative o plugin recente e confirme que o serviço (PHP‑FPM/app server) está rodando.
Certificado SSL vencido ou cadeia incompleta (SNI/TLS)
SSL vencido bloqueia acesso: navegadores exibem alertas como NET::ERR_CERT_DATE_INVALID e param a visita. Em muitos casos o auto‑renew falha silenciosamente em hospedagens compartilhadas.
Fontes de 2026 apontam impacto em confiança e busca. Revise validade, cadeia, nome do host e auto‑renovação de todos os subdomínios. Monitore a data de expiração e teste com um verificador SSL após cada renovação.
Domínio vencido, nameservers trocados ou TTLs impróprios
Domínio expirado some do mapa: o servidor está ok, mas ninguém resolve o nome. Cheque WHOIS/ICANN, estado ativo e cobrança. Nameservers trocados sem apontar o DNS certo derrubam tudo na hora.
TTLs muito longos atrasam correções; muito curtos geram instabilidade. Confirme a data de expiração e que os NS apontam para o seu provedor de DNS atual.
DNS mal configurado: A, CNAME, AAAA, MX e propagação parcial
DNS mal configurado quebra acesso: A/AAAA errados, CNAME em raiz indevida, MX trocado ou propagação parcial causam “funciona aqui, não ali”. Compare respostas no seu DNS e em um resolvedor público como 8.8.8.8.
Use dig/nslookup para validar IP atual, TTL adequado e coerência entre regiões. Erros de cópia após migrações são campeões de instabilidade.
Bloqueios externos: WAF, rate limit, IP banido ou DDoS
Bloqueios externos derrubam só alguns: WAF, rate limit, bloqueio por IP ou DDoS podem afetar regiões ou faixas específicas. CDNs e proxies retornam 503 quando nenhum origin passa no health check.
Revise regras do WAF, limites de tráfego, listas de bloqueio e dashboards da CDN. Se for ataque, habilite modo de proteção e ajuste thresholds; se for falso positivo, crie allowlists para IPs legítimos.
Como checar domínio, DNS, servidor e certificado em minutos
Faça um raio‑X rápido: em minutos você checa domínio, DNS, servidor e certificado. Eu sigo esta ordem porque isola a causa sem adivinhação.
Domínio: WHOIS, status clientHold e data de expiração
Cheque o WHOIS agora: confirme data de expiração e códigos como clientHold ou serverHold; se aparecerem, a resolução DNS foi suspensa e o site fica inacessível até regularizar.
Veja também registrador, nameservers e se o domínio está ACTIVE/ok. Em caso de clientHold, fale com o registrador; serverHold indica ação do registro. Ferramentas de WHOIS/RDAP mostram esses estados em segundos.
DNS: registros A/CNAME/NS corretos e TTL adequado
Compare em resolvedores públicos: consulte A, AAAA, CNAME e NS no 1.1.1.1 ou 8.8.8.8 e verifique o TTL. Se respostas diferirem entre provedores, há cache antigo ou publicação incompleta.
Códigos ajudam: NOERROR com dados é normal; NXDOMAIN indica nome inexistente; NOERROR sem dados (NODATA) mostra que o nome existe, mas não para aquele tipo. TTL define por quantos segundos uma resposta pode ficar em cache.
Servidor: código HTTP (200, 301, 503, 5xx) e tempo de resposta
Veja o código e a latência: 200 e 301 sinalizam caminho saudável; 5xx apontam erro no servidor; 503 indica indisponibilidade temporária. Meça o tempo de resposta e a cadeia de redirecionamentos.
Um teste simples com cabeçalhos HTTP revela status e velocidade. Se responder com erro 500/503, registre a URL exata e horário para cruzar com logs. Lembre que alguns checkers contam “respondeu” mesmo se a resposta for 500.
Certificado: validade, SAN, cadeia e SNI no host certo
Valide o certificado em uso: confira datas de validade, nomes no SAN, cadeia intermediária e SNI apontando para o host correto. Se estiver vencido, o navegador barra o acesso e a confiança despenca.
Há uma mudança importante: certificados publicamente confiáveis estão com janelas menores; a regra atual é de 200 dias de validade máxima em 2026, com reduções programadas nos próximos anos. Monitore a renovação automática e teste após cada emissão.
Logs e incidentes: painel da hospedagem e páginas de status
Abra o painel e o status: verifique logs de aplicação/servidor, uso de recursos e avisos de incidente do provedor. Cruze o horário do erro com eventos recentes, deploys e mudanças de DNS.
Se o monitor mostra picos de erro ou queda de saúde, anote o período e as URLs afetadas. Muitas plataformas permitem anexar o diagnóstico em formato parecido com nslookup/dig, o que agiliza o reporte.
Quando usar 503 + Retry‑After para manutenção planejada
Use 503 com Retry‑After em janelas curtas de manutenção para sinalizar “indisponibilidade temporária”. O cabeçalho Retry‑After aceita data HTTP ou segundos e indica quando tentar de novo.
Prefira uma página leve que também retorne 503. Não troque por 200 “em obras” nem bloqueie tudo no DNS. Após concluir, remova o 503 e valide que o site volta a 200 com tempo de resposta normal.
O que fazer enquanto resolve, para não perder cliente nem ranqueamento
Proteja o usuário e o SEO enquanto corrige: em minutos, você pode reduzir prejuízo com uma página leve, comunicação ativa e ajustes táticos. O objetivo é simples: manter confiança, cortar desperdícios e sinalizar corretamente para o Google.
Suba uma página leve de manutenção com 503 real
Use 503 com Retry‑After: para uma janela curta, retorne 503 em páginas afetadas com Retry‑After realista e HTML estático rápido. Isso diz aos bots que é indisponibilidade temporária, não conteúdo novo.
Mantenha o robots.txt em 200 e fora da regra de manutenção; 503 nesse arquivo bloqueia todo o rastreamento. Google recomenda janelas breves, cerca de 1–2 dias, e verificar a resposta com curl. Retry‑After aceita segundos ou data HTTP (RFC 9110).
Pausar anúncios e ajustar UTMs, redirecionar campanhas
Pare de pagar por cliques perdidos: pause anúncios que apontam para URLs com erro e direcione o tráfego para uma landing estável ou status page. Ajuste UTMs para identificar sessões durante a manutenção.
Se o funil permitir, mova verba para topo de funil ou captação de leads até o site voltar. Preserve audiência com remarketing e listas; retome as campanhas assim que os 200 voltarem estáveis.
Comunicação clara: banner, e‑mail, redes e WhatsApp Business
Avise com clareza e prazo: publique um banner simples, informe ETA e canais de contato. Envie atualização curta por e‑mail, redes e WhatsApp Business para clientes ativos.
Mensagens curtas funcionam melhor: o que aconteceu, quando volta e como falar com a equipe. Evite termos técnicos; ofereça alternativa de pedido, orçamento ou suporte humano.
Plano B: landing estática em CDN ou espelho temporário
Suba uma landing estática na CDN: uma página fora da aplicação, com poucas dependências, coleta leads e reduz carga na origem. Configure cache agressivo e monitore tempo de resposta.
Se usar 503 no site principal, não troque as mesmas URLs por 200 “placeholder”. Prefira uma URL separada (ex.: /status) ou subdomínio em CDN para manter o sinal correto aos bots.
Cuidados de SEO: manter robots.txt 200 e evitar noindex
Robots.txt sempre 200: não deixe esse arquivo responder 503, pois isso pausa o rastreamento do site todo. Não use noindex nem remoções no Search Console para “esconder” a janela.
Em manutenção curta, 503 com Retry‑After preserva o contexto para o Google. Mantenha a janela breve e volte a 200 assim que possível para evitar queda e remoção de URLs ao longo de dias.
Pós‑incidente: validar correção no Search Console e logs
Valide no Search Console: use o Testar URL ao vivo, acompanhe Crawl stats/Host status e clique em Validar correção no item “Erro de servidor (5xx)”. O Google reduz rastreamento com 5xx e pode dropar URLs se persistirem.
Correlacione horários de falha dos relatórios com logs de servidor/CDN para achar a causa raiz. A validação pode levar até duas semanas; monitore resposta média e a limpeza gradual dos erros.
Como evitar que aconteça de novo: monitoramento e alerta
Monitore antes de quebrar: o caminho é claro. Valide conexão, ataque as causas campeãs, cheque domínio, DNS, servidor e certificado. Se cair, segure o estrago com 503 com Retry‑After, mantenha o robots.txt em 200, avise os clientes e pause o tráfego pago. Fechou a janela? Reabra com testes de código 200, valide no Search Console e cruze com logs. Esse ciclo curto evita perda de clientes e protege o ranqueamento.
Vamos blindar sua operação: a Mistura Tech monta monitoramento 24/7 com checagens de minuto, alertas por e‑mail/SMS/WhatsApp, avisos de SSL e domínio perto de vencer, detecção de drift em DNS e playbook de resposta em 10 minutos (inclui 503 correto, Retry‑After e verificação do robots). Quer dormir tranquilo? Peça o setup de monitoramento e um plano de resposta em 10 minutos com a Mistura Tech.
Key Takeaways
Use este checklist prático para diagnosticar e mitigar “site fora do ar” em minutos, mantendo a confiança do usuário e a saúde do SEO.
- Teste outra rede primeiro: Compare Wi‑Fi x 4G/5G em modo anônimo; se abre no móvel e falha no Wi‑Fi, a causa é local (cache/DNS/VPN/firewall/provedor).
- Cheque em várias regiões: Use verificadores globais; falha geral indica pane no destino, divergências por região sugerem CDN ou propagação parcial de DNS.
- Confirme WHOIS e status: Valide expiração e códigos como clientHold/serverHold; nesses estados a resolução é suspensa e o site some até regularizar.
- Valide DNS e TTLs: Compare A/AAAA/CNAME/NS em 8.8.8.8 e 1.1.1.1; respostas diferentes apontam cache antigo ou publicação incompleta; ajuste TTL para mudanças previsíveis.
- Leia o código HTTP: 200/301 sinalizam caminho saudável; 5xx expõem falhas; 503 indica indisponibilidade temporária; meça tempo de resposta e cadeia de redirecionamentos.
- Garanta SSL/TLS válido: Confira validade, SAN, cadeia intermediária e SNI; monitore renovação automática (janelas de validade estão encurtando, ex.: ~200 dias em 2026).
- Use 503 + Retry‑After: Em manutenção curta, retorne 503 com Retry‑After (segundos ou data); nunca 503 o robots.txt; mantenha a janela breve (≈1–2 dias) e teste com curl.
- Mitigue e valide a volta: Página leve de manutenção, pausar anúncios e comunicar; configure monitoramento 24/7 com alertas de 1–5 min; no Search Console, Teste ao vivo e “Validar correção”, correlacionando com logs.
Disponibilidade é disciplina: aplicar 503 corretamente, monitorar continuamente e revisar DNS/infra encurta incidentes e evita perda de receita e ranqueamento.
FAQ — Site fora do ar: dúvidas rápidas
Meu site está fora do ar, o que fazer?
Teste em outra rede (4G/5G) e no modo anônimo. Verifique página de status da hospedagem, WHOIS/domínio e DNS. Cheque o código HTTP (5xx/503). Em manutenção curta, sirva 503 com Retry-After, mantenha robots.txt em 200 e comunique clientes. Registre horário e erro para cruzar com logs.
Como saber se o site caiu para todo mundo?
Compare Wi‑Fi x 4G/5G e use checkers globais (múltiplas regiões). Se falhar em todos, a queda é geral. Se só na sua rede, pode ser cache, DNS local, VPN, firewall ou rota do provedor. Diferenças por região sugerem problema de CDN/DNS.
Site fora do ar prejudica o SEO?
Quedas breves tendem a ter impacto mínimo. Repetições ou janelas longas com 5xx/429 reduzem o crawl e podem levar URLs a sair do índice. Use 503 com Retry-After em manutenção, evite 200 “placeholder” e nunca retorne 503 para o robots.txt.
Quanto tempo de site fora do ar o Google tolera?
Não há garantia fixa. A orientação do Google para desligamento urgente é 1–2 dias com 503 + Retry-After. Passando disso, cresce o risco de queda de rastreamento e remoção de URLs. Mantenha a janela a mais curta possível.
Como configurar alerta de site fora do ar?
Use monitoramento externo com checagens de 1–5 minutos em múltiplas localidades. Ative alertas por e‑mail/SMS/Slack/WhatsApp, monitore homepage e páginas críticas, e configure lembretes de vencimento de SSL e domínio. Acompanhe Crawl Stats no Search Console.
