Estamos Em Obra Desculpe O Transtorno

O que é "Estamos em obra, desculpe o transtorno" e por que quase todo mundo faz errado

A mensagem "estamos em obra, desculpe o transtorno" é uma página de manutenção ou construção que sites e aplicativos mostram quando estão fora do ar temporariamente. Parece simples, mas a maioria das pessoas Implementa de qualquer jeito, sem pensar em SEO, acessibilidade ou experiência do usuário. Eu já vi páginas assim em produção e é sempre a mesma coisa: um texto genérico num fundo branco, talvez uma imagem qualquer, e pronto. Ninguém pensou em meta tags, em canonicalização, em crawlabilidade. O problema é que quando seu site entra em obra, o Google continua enviando robôs de indexação. Se a página não tiver os cabeçalhos HTTP certos, se não tiver um robots.txt configurado, se simplesmente retornar um 200 OK com conteúdo vazio, você pode ter problemas sérios. Já aconteceu comigo num projeto de migrar um e-commerce inteiro pro novo servidor: esqueci de colocar o cabeçalho status 503 e o Google passou três dias reindexando uma versão parcialmente montada. Quando voltei, a página principal tinha conteúdo duplicado disperso por URLs de teste.

Estamos em obra, desculpe o transtorno — como implementar do jeito certo

Vamos começar pelo mais importante, o que ninguém menciona: o código de status HTTP. A página precisa retornar 503 Service Unavailable. Esse é o número que diz aos motores de busca "me esqueça por enquanto, volto em breve". Não é um 404, não é um 200 disfarçado. Se você só esconder o conteúdo com CSS, o Google vai indexar a versão sem conteúdo ou, pior, parte da versão nova e parte da antiga. Além do 503, você precisa do cabeçalho Retry-After. Ele informa há quantos segundos ou qual data o site estará disponível novamente. Exemplo prático: Retry-After: 86400
Significa "volte daqui a 86.400 segundos", ou seja, 24 horas.

Se você não souber exatamente quando vai ficar pronto, coloque Retry-After: 3600 como mínimo. É melhor não dizer nada do que prometer algo e quebrar. Outro ponto negligenciado: o robots.txt. Antes de colocar a página de obra no ar, verifique se o robots.txt não está permitindo que bots acessem URLs internas que ainda não foram finalizadas. Já perdi uma manhã inteira caçando URLs indexed indevidas num site que estava em obra e o robots.txt permitia o crawl de diretórios completos. Configure comDisallow para / durante o período de manutenção. É simples, mas passa despercebido na pressa.

Implementação prática, sem complicação

Se você usa Apache, basta adicionar estas linhas ao .htaccess antes de ativar a página de obra: RewriteEngine On
RewriteCond %{REQUEST_URI} !/obra.html$
RewriteRule .* /obra.html [R=503,L]
Header set Retry-After "3600" Isso redireciona tudo para obra.html, exceto o próprio arquivo, e envia o status 503 com o cabeçalho Retry-After de 1 hora. Se você quiser um período maior, ajuste o valor.

Para Nginx, a configuração no site é diferente: location / {
  error_page 503 /obra.html;
  return 503;
}

location = /obra.html {
  internal;
  add_header Retry-After "3600";
} Um detalhe que causa dor de cabeça: o arquivo obra.html precisa estar acessível para o servidor, mas o navegador do usuário também tem que conseguir carregá-lo. Se você usar a diretiva internal no Nginx e configurar mal o bloco location, o arquivo não será servido corretamente. Teste com curl -I antes de colocar em produção.

O que colocar na página em si

A página de obra não precisa ser um portfólio. Mas tem regras básicas que a maioria ignora. O título da página deve conter a mensagem "estamos em obra, desculpe o transtorno". Isso serve tanto para visitantes quanto para mecanismos de busca entenderem o contexto. O HTML deve ser enxuto, carregar rápido, e idealmente não depender de JavaScript para renderizar o conteúdo principal. Inclua um link para as redes sociais ou um formulário de contato, se fizer sentido. Mas evite colocar scripts de analytics pesados numa página que as pessoas raramente ficam. Eu vi uma vez uma página de obra carregando o Google Tag Manager inteiro, o Facebook Pixel e um chatbot flutuante. O tempo de carregamento era de 8 segundos. Ninguém aguenta isso. Se o seu site é uma loja virtual em obra prolongada, considere também manter uma versão estática com links para os produtos mais importantes. Isso preserva parte do valor de SEO acumulado enquanto a obra avança. Claro, isso só funciona se a estrutura de URLs não mudar drasticamente. Se vai reformar completamente o site, melhor limpar tudo e reconstruir.

Pegadinhas que eu aprendi na prática

A primeira: cache. Se você testar a página de obra com o navegador aberto, o cache pode esconder o status 503 e mostrar um 200. Use sempre modo anônimo ou ferramenta como curl para verificar os cabeçalhos reais. Testei em obra num cliente e só percebi o erro quando o SEO manager disse que a página ainda estava retornando 200. O problema era o Cloudflare cache, não o servidor. Limpei o cache e funcionou. A segunda: URLs canônicas. Durante a obra, se alguma URL interna ainda estiver apontando para a versão antiga, o link canônico pode levar a URLs quebradas ou a conteúdo duplicado. Coloque um canonical para a página principal mesmo durante a manutenção. Isso evita problemas de SEO pós-obra. A terceira, e a mais chata: backup. Sempre faça backup completo antes de colocar qualquer site em obra. Eu tive um caso onde o deploy automatizado quebrou o banco de dados e fiquei seis horas sem conseguir reverter. Ter um snapshot do banco e dos arquivos salvos antes de começar economiza horas de nervosismo.

Quando NÃO usar uma página de obra genérica

Se o seu site é pequeno e a obra é apenas para um ajuste rápido, talvez não valha a pena. Uma reinicialização do servidor, uma atualização de plugin, uma migração de DNS — tudo isso pode levar de 10 minutos a uma hora. Colocar uma página de obra completa nesses casos é overhead desnecessário. Nesses cenários, basta garantir que o uptime monitoramento avise a equipe e que o rollback esteja pronto. Por outro lado, se a obra durar mais de 4 horas, ou se envolver mudanças estruturais no site, aí sim a página de obra é justificável. O Google tolera 503s por alguns dias sem penalizar. Mas se a obra estourar pra semana ou duas, aí a coisa começa a ficar séria. Os rankings caem, o tráfego orgânico despenc, e recuperar o que foi perdido leva tempo. Planeje os períodos de obra para horários de menor tráfego, de preferência fins de semana ou madrugadas.

Checklist rápido antes de colocar o site em obra

1. Configurar robots.txt para bloquear crawl durante a obra.
2. Criar a página obra.html com título "estamos em obra, desculpe o transtorno" e meta description clara.
3. Verificar se o servidor retorna status 503 com Retry-After.
4. Confirmar que URLs canônicas estão apontando para a página principal.
5. Fazer backup completo (arquivos + banco de dados).
6. Testar com curl -I e em modo anônimo do navegador.
7. Notificar stakeholders sobre o período de obra.
8. Ter um plano de rollback pronto. Execute esses oito passos na ordem. Leva cerca de 15 minutos. Evita seis horas de dor de cabeça. A página de obra não é só um aviso visual — é uma configuração técnica que afeta indexação, cache e performance. Trate com a mesma seriedade que você trataria um deploy normal. Só que, nesse caso, o objetivo é fazer o site sumir do ar de forma controlada, e não o contrário.