Um site entregue parece um produto acabado: as páginas abrem, o formulário chega, o cliente aprova. Mas por baixo dele há peças com prazo de validade — a linguagem em que o site roda, os plugins que fazem o formulário funcionar, o certificado do cadeado, o registro do domínio. Cada uma vence num ritmo diferente, e quase nenhuma manda aviso para o dono da empresa.
A maior parte do que se escreve sobre manutenção de site é um checklist genérico (faça backup, corrija links quebrados, atualize o conteúdo) ou a vitrine de um plano mensal. Este artigo faz outra coisa: mostra o que de fato vence num site pronto, com as datas publicadas, quem avisa quando vence, como conferir a versão do seu site em cinco minutos e o que exigir num contrato de manutenção.
O que é manutenção de site?
Manutenção de site é o conjunto de tarefas recorrentes que mantém o site seguro, compatível e funcionando depois que ele foi ao ar. Ela não cria páginas novas nem muda o layout: cuida para que o que já existe continue de pé enquanto tudo em volta muda — o servidor, o navegador, o sistema de gestão de conteúdo e as ameaças.
Costuma-se dividir o trabalho em quatro frentes. A corretiva conserta o que quebrou. A preventiva atualiza software, testa backup e monitora antes que algo quebre. A adaptativa ajusta o site a mudanças externas, como uma versão nova da linguagem ou uma regra nova de navegador. E a evolutiva faz pequenas melhorias de conteúdo e desempenho. O que este artigo chama de “o que vence” mora quase todo na preventiva e na adaptativa — justamente as que ninguém pede, porque não doem até o dia em que doem.
O que vence num site depois da entrega?
Seis itens concentram o risco de um site institucional ou de uma loja virtual. Alguns têm data marcada, outros vencem sem data nenhuma; o que eles têm em comum é que o dono do site raramente fica sabendo a tempo.
Dois deles já têm artigo próprio aqui no blog. O certificado SSL está ficando mais curto e a renovação passou a ser obrigatoriamente automática — o que muda está no guia sobre o fim da renovação anual do certificado SSL. E o domínio, que vence numa data conhecida, tem um problema anterior: em nome de quem ele está, assunto do artigo sobre em nome de quem registrar o domínio. Aqui o foco é o que costuma ficar fora da conversa: a versão do PHP e os plugins.
Por que a versão do PHP tem prazo de validade?
PHP é a linguagem em que rodam o WordPress e boa parte dos sites feitos sob medida. Cada versão dela tem um ciclo de vida publicado com antecedência pelo grupo que a mantém: dois anos de suporte ativo, em que recebe correções de erros e de segurança, e depois dois anos só de correções de segurança. Terminado esse prazo, a versão continua funcionando, mas nenhuma falha nova descoberta nela será corrigida.
O ponto que quase ninguém percebe: o site não muda de versão sozinho. A versão do PHP é uma configuração da hospedagem, escolhida quando o site foi publicado. Se ninguém trocar, o site entregue em 2023 em PHP 8.2 continua em PHP 8.2 em 2027 — funcionando normalmente, sem nenhum sinal na tela, e sem correção de segurança.
E isso não é exceção. A estatística pública do WordPress.org mostra quantos sites rodam cada versão, e o retrato é de um parque envelhecido:
O próprio WordPress já se posicionou: a página oficial de requisitos recomenda rodar o WordPress em PHP 8.3 ou superior. Ou seja, quem está no 8.2 não está “atualizado com folga”; está numa versão que o próprio sistema já deixou de recomendar e que perde a última camada de proteção no fim do ano.
O que acontece com o site no dia 31 de dezembro de 2026?
Na manhã de 1º de janeiro, nada visível. O site abre, o formulário envia, o carrinho fecha a compra. É por isso que o prazo passa despercebido: fim de suporte não é um desligamento, é a retirada de uma rede de proteção.
O que muda é o que acontece daí em diante. Quando uma falha de segurança nova for encontrada no PHP 8.2, ela não ganhará correção oficial. Os plugins, por sua vez, começam a deixar de testar e de dar suporte a versões antigas, e a atualização de um deles pode passar a exigir uma versão mais nova da linguagem. O site fica preso: não dá para atualizar o plugin sem atualizar o PHP, e não dá para continuar sem atualizar o plugin.
Há ainda o lado da hospedagem. Provedores mantêm versões antigas disponíveis por um tempo, mas o prazo é decisão deles — e a migração forçada, quando vem, costuma chegar com pouca antecedência. Trocar a versão com calma, em ambiente de teste, custa muito menos do que trocá-la às pressas porque o servidor mudou.
Por que os plugins são a porta mais aberta do WordPress?
Se a versão do PHP vence numa data conhecida, os plugins vencem a qualquer momento. Cada plugin é um pedaço de código escrito por um desenvolvedor diferente, com ritmo próprio de manutenção — alguns por empresas com equipe dedicada, outros por uma pessoa que já parou de atualizar. Não é raro um site institucional somar uma dúzia deles sem que ninguém perceba.
Dois números desse levantamento mudam a forma de pensar a manutenção. O primeiro: o núcleo do WordPress quase não é o problema, e ele ainda instala sozinho as atualizações de segurança. O risco está no que foi acrescentado em volta. O segundo: um terço das falhas não tinha correção quando se tornou pública. Para essas, “manter tudo atualizado” não basta — a decisão é desativar ou trocar o plugin, e isso exige alguém que acompanhe os alertas, não só alguém que clique em “atualizar”.
Manutenção não é clicar em “atualizar tudo”. É saber o que está instalado, o que está sem correção e o que precisa sair.
É também por isso que o número de plugins entra na conta do preço de um site — cada um é uma dependência a mais para vigiar, como detalhamos no artigo sobre o que define o preço de um site.
Como conferir a versão do PHP do seu site em 5 minutos?
Não é preciso ser técnico. Há três caminhos, do mais simples ao mais direto:
1. Pelo painel do WordPress
Entre no painel, vá em Ferramentas e depois em Saúde do site. Na aba Informação, abra a seção Servidor: a linha “Versão do PHP” mostra o número. A própria aba Status costuma exibir um alerta quando a versão está desatualizada.
2. Pelo painel da hospedagem
Quase todo painel de hospedagem tem uma área chamada “Versão do PHP”, “Configuração do PHP” ou parecida. Ela mostra a versão em uso e, em geral, permite trocar. Não troque ainda: só anote o número.
3. Perguntando a quem cuida do site
Mande uma pergunta objetiva para a agência ou o desenvolvedor: “Em que versão do PHP o site roda, e quando vocês planejam a migração para a 8.3 ou superior?”. A qualidade da resposta diz muito sobre a manutenção que existe hoje.
Como fazer manutenção de site na prática?
Manutenção que funciona tem calendário. Sem ele, a tarefa vira reação: alguém só olha o site quando o formulário para ou quando o Google avisa que há algo errado. O quadro abaixo organiza as tarefas por frequência, com o motivo de cada uma:
| Tarefa | Frequência | Por que importa |
|---|---|---|
| Atualizar plugins e tema, depois de testar | Semanal ou a cada alerta de segurança | 96% das falhas novas do ecossistema estão em plugins |
| Acompanhar alertas de falha sem correção | Contínua | Um terço das falhas é divulgado sem correção; a saída é desativar ou trocar |
| Conferir backup e fazer um teste de restauração | Mensal | Backup que nunca foi restaurado é uma suposição, não uma garantia |
| Testar formulários, checkout e integrações | Mensal e após cada atualização | É onde o lead e a venda se perdem em silêncio |
| Revisar plugins instalados e remover o que não é usado | Trimestral | Plugin desativado e esquecido continua sendo código no servidor |
| Conferir a versão do PHP e o calendário de suporte | Semestral | Cada versão tem data publicada de fim das correções |
| Conferir vencimento do domínio e renovação do certificado | Semestral | A renovação é automática até o dia em que falha |
Elaborado pela Alliance Comunicação; números de plugins e falhas sem correção da Patchstack (2025) e datas do PHP de php.net.
Duas regras valem para todas as linhas. Primeiro, atualização se testa antes: o ideal é ter uma cópia do site (ambiente de homologação) onde a atualização roda primeiro. Segundo, backup vem antes de qualquer mudança, e não só o automático da hospedagem — uma cópia guardada fora do servidor, para o caso de o problema ser o próprio servidor.
Como migrar a versão do PHP sem quebrar o site
A migração segue uma ordem simples: backup completo; atualização de WordPress, tema e plugins na versão atual do PHP; cópia do site em ambiente de teste com a versão nova; navegação pelas páginas principais, formulários e checkout; e só então a troca em produção, num horário de pouco tráfego, com o backup à mão para voltar se algo falhar. Plugins abandonados costumam ser o que trava a migração — e a migração é a hora de substituí-los.
A manutenção de um site é responsabilidade do desenvolvedor?
Só se estiver no contrato. Por padrão, o desenvolvedor responde pelo projeto que entregou: se algo combinado não funciona na entrega, ou dentro da garantia prevista, cabe a ele corrigir. O que acontece depois — PHP que perde suporte, plugin que ganha uma falha, hospedagem que muda de servidor — não é defeito de entrega. É o desgaste natural de um software que vive num ambiente que muda.
É aí que nasce o mal-entendido mais comum. A empresa entende que “o site é da agência, então a agência cuida”. A agência entende que entregou o projeto e que manutenção é outro serviço. Os dois estão certos dentro da própria lógica, e o site fica sem dono. Quem resolve isso não é a boa vontade, é um contrato de manutenção separado do contrato de criação — ou uma cláusula explícita no mesmo contrato.
Vale lembrar um ponto que vem antes da manutenção: o acesso. Domínio, hospedagem e painel do site precisam estar em nome da empresa, com a agência como operadora. Sem isso, trocar de fornecedor de manutenção vira negociação.
O que pedir no contrato de manutenção de site?
Contrato de manutenção bom é o que transforma o quadro do início deste artigo em responsabilidade nomeada. Os itens que fazem diferença:
- Lista do que está incluído, por item. Atualização de núcleo, tema e plugins; versão do PHP; backup; monitoramento; certificado; domínio. O que não está na lista não está coberto.
- Política de versão do PHP. Compromisso de manter o site numa versão com suporte de segurança e de migrar antes da data de fim, com teste em ambiente separado.
- Como são tratadas falhas sem correção. Quem acompanha os alertas, em quanto tempo o plugin vulnerável é desativado ou substituído, e quem aprova a troca.
- Backup com teste de restauração. Frequência, onde fica guardado (fora do servidor) e a periodicidade do teste — não só a promessa de que existe.
- Tempo de resposta por gravidade. Site fora do ar não pode ter o mesmo prazo de um ajuste de texto.
- Relatório periódico. O que foi atualizado, em que versão o site está, o que ficou pendente. É o que permite à empresa saber que a manutenção existe.
- Horas de evolução, se houver. Pequenas mudanças de conteúdo e layout são outra frente; quando entram no pacote, precisam de limite claro.
- Saída organizada. Entrega de acessos, backups e documentação se o contrato terminar.
Quanto custa manutenção de site?
Não existe um preço de referência confiável e público para manutenção de site no Brasil; as faixas que circulam em blogs de fornecedores são tabelas próprias, sem fonte que permita comparar. O que dá para dizer com segurança é o que move o preço — e usar isso para comparar propostas.
- Quantidade de dependências. Site com três plugins dá menos trabalho que site com trinta. Cada plugin é um item a acompanhar.
- Tipo de site. Loja virtual, área de cliente e integrações (CRM, ERP, meio de pagamento) pedem testes a cada atualização.
- Tempo de resposta contratado. Atendimento em horas custa mais que atendimento em dias.
- Backup e ambiente de teste. Cópia fora do servidor e homologação têm custo de infraestrutura, e valem cada centavo.
- Horas de evolução incluídas. Pacote que inclui ajustes de conteúdo e layout não é comparável a pacote só de manutenção técnica.
Na comparação, o preço baixo engana menos que o preço vago. Desconfie de proposta mensal que não diga o que está incluído, que não mencione a versão do PHP nem fale de backup testado. Pagar pouco por “manutenção” que é só renovar a hospedagem sai caro no dia em que o site é invadido, e limpar um site invadido é trabalho de emergência, feito às pressas e sem orçamento.
O que muda por tipo de site?
O que vence depende de como o site foi construído. Antes de contratar, vale saber em qual destas categorias o seu está:
| Tipo de site | O que vence | Quem cuida |
|---|---|---|
| WordPress institucional | PHP, núcleo, tema e plugins, certificado, domínio | A empresa ou o fornecedor contratado; a hospedagem só cuida do servidor |
| Loja virtual em WordPress | Tudo do anterior, mais extensões de pagamento e frete | Fornecedor com teste de checkout a cada atualização |
| Site em código próprio (PHP ou outra linguagem) | Versão da linguagem e das bibliotecas usadas no projeto | Quem desenvolveu ou quem herdou o código, com documentação |
| Plataforma pronta por assinatura | Domínio e integrações; a plataforma atualiza o resto | A plataforma, enquanto a assinatura estiver em dia |
| Site parado, sem dono definido | Tudo, sem ninguém acompanhando | Ninguém — é o cenário de maior risco |
A última linha é mais comum do que parece. Empresas que trocaram de agência, que perderam o contato do freelancer ou que receberam o site “de herança” de outra gestão costumam estar nela sem saber. O primeiro passo, nesse caso, é um inventário: o que está instalado, em que versão, com quais acessos.
Quais os erros mais comuns na manutenção de site?
- Achar que a hospedagem faz manutenção. A hospedagem cuida do servidor. O que roda dentro dele — WordPress, plugins, versão do PHP escolhida — é responsabilidade de quem administra o site.
- Atualizar tudo direto em produção. Sem backup e sem teste, a atualização que corrige uma falha pode derrubar o formulário de contato por dias sem que ninguém perceba.
- Nunca atualizar por medo de quebrar. É o erro oposto e mais perigoso: o site acumula falhas conhecidas até ficar preso numa versão de PHP sem suporte.
- Deixar plugin desativado no servidor. Desativar não remove o código. O que não é usado deve ser apagado.
- Confiar no backup sem nunca restaurar. A primeira restauração não deve acontecer no dia da emergência.
- Acessos em nome de terceiros. Domínio no CPF de um ex-funcionário ou hospedagem no cadastro da agência antiga transformam uma manutenção simples numa negociação.
Quase todos esses erros têm a mesma raiz: tratar o site como peça de marketing, que se aprova e se esquece, e não como software, que envelhece. O tema conversa com segurança da informação de forma mais ampla — o atacante não escolhe empresa pelo tamanho, escolhe pela porta aberta, como mostra o artigo sobre por que o ataque não escolhe a vítima.
Quando contratar uma empresa de manutenção de site?
Manutenção interna funciona quando há alguém com tempo, conhecimento técnico e responsabilidade formal sobre o site. Na maioria das pequenas e médias empresas, esse alguém não existe: o site fica com o marketing, que entende de conteúdo, mas não de versão de PHP nem de alerta de vulnerabilidade.
Faz sentido contratar quando o site gera lead ou venda (cada dia parado tem custo direto), quando roda em WordPress com vários plugins, quando ninguém sabe dizer a versão do PHP, quando houve troca de fornecedor sem passagem de bastão, ou quando a empresa precisa de alguém que responda pela segurança. Na área de desenvolvimento web da Alliance, a manutenção é tratada como contrato próprio, com a política de versão e o relatório periódico por escrito.
Se o site é só uma das frentes que você quer organizar, o diagnóstico gratuito de marketing avalia presença digital, tecnologia e dados e devolve as prioridades em ordem.
Por onde começar hoje
- Descubra a versão do PHP do site (painel do WordPress, painel da hospedagem ou pergunta direta ao fornecedor).
- Se for 8.2, agende a migração para a 8.3 ou superior antes de 31/12/2026; se for 8.1 ou anterior, trate como urgente.
- Liste os plugins instalados e apague os que estão desativados ou sem uso.
- Confirme que o backup existe fora do servidor e faça um teste de restauração numa cópia.
- Confira em nome de quem estão domínio, hospedagem e acessos do painel.
- Se não houver contrato de manutenção, escreva um com a lista de itens, a política de PHP e o relatório periódico; se houver, confira se esses pontos estão nele.
Um site não vence de uma vez; vence aos poucos, item por item, sem aviso. A data de 31 de dezembro de 2026 é só a mais visível delas — e um bom motivo para olhar as outras enquanto ainda há tempo de fazer isso com calma.