A WPPoland (Mariusz Szatkowski) faz manutenção de sites WordPress: cópias de segurança diárias, atualizações primeiro em staging, monitorização da disponibilidade a cada 1 a 5 minutos, a qualquer hora. WordPress desde 2006, a partir de Gdynia. Orçamento escrito depois de um briefing curto.
Manutenção de sites WordPress em Portugal, feita à distância
A manutenção de um site WordPress é o trabalho técnico contínuo de que depende o site funcionar, carregar depressa e não distribuir malware. Um site sem atualizações acumula falhas nos plugins, e um site sem uma cópia de segurança testada pode perder encomendas e faturas na primeira avaria do alojamento.
Faço a manutenção à distância, por isso o mesmo âmbito serve empresas em Lisboa, no Porto, em Braga, em Coimbra ou em Faro. Em aquisições e mudanças de stack, antes do primeiro mês de manutenção, comece pela avaliação de migração WordPress. Depois da mudança, mantenha a loja num Store Reliability Plan, para que a monitorização e as atualizações fiquem explícitas. Se o checkout já está em baixo, comece pelo sprint de recuperação WooCommerce antes de uma avença. Quando o site já não funciona, o que precisa é de reparação e suporte técnico WordPress.
O que inclui a manutenção de um site WordPress
A manutenção junta vários trabalhos fixos. Cada um tem uma página própria com a descrição completa.
O núcleo, os plugins e os temas atualizo-os todas as semanas, primeiro em staging, depois de uma cópia de segurança completa, e depois de cada atualização comparo capturas de ecrã de antes e de depois. A passagem para uma versão mais recente de PHP também está incluída. As versões principais dos plugins reviso-as todos os meses e a lista de plugins todos os trimestres. O calendário, o desenrolar de uma ronda e o que faço quando uma atualização parte algo estão na página atualizações WordPress.
A monitorização analisa os ficheiros à procura de malware e vigia a sua integridade. Quando há uma intrusão, trabalho numa ordem fixa: provas, diagnóstico, limpeza numa cópia, novas palavras-passe, pedido de revisão ao Google. Os pormenores, o RGPD e a notificação à CNPD estão na página remover malware do WordPress. Uma avaliação pontual e aprofundada das proteções é o que faz a auditoria de segurança WordPress.
Os intervalos de preço para site de empresa e loja, o que entra na avença e o que é faturado à parte estão na página preço da manutenção WordPress.
Na manutenção meço as Core Web Vitals todos os meses e vigio que o resultado não desça. Uma melhoria de velocidade pontual e concentrada é feita na otimização de velocidade WordPress.
Números medidos para um endereço, antes de qualquer conversa sobre âmbito, é o que dá a verificação de site WordPress.
Como começa a manutenção
O primeiro mês de manutenção. A auditoria inicial está incluída na mensalidade desse mês.
Orçamento depois de um briefing curto
Envia o endereço do site e a descrição do que funciona nele. Respondo com um orçamento escrito com valor, limite de horas e tempo de resposta.
Contrato de subcontratação antes do acesso
Antes de eu ter acesso ao site, assinamos o contrato de subcontratação do artigo 28.º do RGPD. A sua empresa continua a ser a responsável pelo tratamento e eu sou o subcontratante.
Acessos numa só folha
Junto num só sítio os acessos ao alojamento, ao domínio, ao painel do WordPress e ao Search Console. Com vários sites, a folha mostra também onde está cada um e quais são lojas.
Auditoria inicial
Verifico a versão de PHP, os plugins, o tema, o acesso ao servidor e se as cópias de segurança existentes se deixam restaurar. A auditoria não é paga à parte.
Cópias, monitorização e staging
Configuro cópias diárias na nuvem guardadas pelo menos 30 dias, monitorização da disponibilidade a cada 1 a 5 minutos com alerta para mim e um clone de staging para testar as atualizações.
Primeiro relatório
Resultado da auditoria, estado das atualizações e lista do que há a corrigir, por ordem. O trabalho fora do âmbito da manutenção recebe orçamento próprio.
Calendário de trabalho na manutenção
Ritmo fixo de trabalho num site. Numa loja, as janelas de atualização são combinadas à parte.
Todas as semanas
- Correções menores e versões de segurança por WP-CLI, num clone de staging
- Testes aos percursos principais: início de sessão, formulário de contacto e, numa loja, carrinho, pagamento e fatura
- Comparação de capturas de ecrã e publicação numa janela combinada
Todos os meses
- Revisão das versões principais dos plugins e das listas de alterações: atualizar ou reter
- Revisão das contas de administrador
- Medição das Core Web Vitals e limpeza da base de dados
- Relatório: atualizações, disponibilidade, desempenho, erros de indexação
Por trimestre e por semestre
- Por trimestre: revisão do inventário de plugins e remoção do código abandonado
- Passagem para PHP mais recente: segundo o plano, testada em staging
- Por semestre: revisão de segurança, com integridade de ficheiros, contas, permissões, endpoints expostos e comparação entre staging e produção
Todos os dias, à margem do calendário, nasce uma cópia de segurança e a monitorização verifica a disponibilidade a cada 1 a 5 minutos e vigia os ficheiros.
Atualizações e segurança
A equipa de segurança do WordPress publica correções para as falhas encontradas, mas a correção só protege quando chega ao seu site. Segundo a página da equipa, só a versão mais recente do WordPress tem suporte oficial. Um site parado várias versões atrás pode ficar sem correção.
O processo de atualização é sempre o mesmo. Primeiro uma cópia completa da base de dados e dos ficheiros, depois a atualização em staging, ou seja, numa cópia do seu site, e testes às funções principais. Depois da atualização comparo capturas de ecrã de páginas escolhidas, de antes e de depois, porque um teste funcional não repara numa grelha desalinhada. Só depois de um teste positivo a alteração chega à produção, e durante as 24 horas seguintes mantenho uma monitorização reforçada. Se algo correr mal, volto à versão anterior a partir da cópia. Foi por causa deste staging primeiro que o WP Rocket 3.23.2.2 passou por um clone antes do WordPress 7.1: WP Rocket, erro fatal no WordPress 7.1 e Cloudflare.php.
As correções de segurança críticas não esperam pelo ciclo semanal. Passam à frente, pelo mesmo caminho de staging, e a janela exata para elas fica no orçamento. Sei das falhas pelas bases de dados de vulnerabilidades, entre elas a WPScan e a Patchstack. A descrição completa do calendário está na página atualizações WordPress.
Cópias de segurança e restauro
As cópias de segurança protegem contra avarias de hardware, erros humanos, intrusões e atualizações falhadas. Na manutenção são diárias e incrementais, vão para a nuvem, fora do servidor do site, e ficam guardadas pelo menos 30 dias. Uma cópia incremental guarda só as alterações desde a anterior, por isso não pesa no servidor e permite voltar a vários pontos no tempo. Isso conta quando um problema só se revela passados alguns dias.
Sigo a regra 3-2-1, com uma cópia fora do servidor. Fora do servidor quer dizer outro fornecedor, noutra jurisdição, diferente da conta de alojamento e nunca com o mesmo login do painel. Na prática uso armazenamento compatível com S3 noutra jurisdição da UE, com o fornecedor de armazenamento identificado como subcontratante. A base de dados restaura-se em separado da pasta wp-content/uploads, para ser possível repor conteúdo sem levar contas de utilizadores e encomendas de volta à terça-feira passada.
Uma cópia só prova o que vale quando é restaurada, por isso faço testes de restauro regulares, e o relatório mostra o estado das cópias e a data do último teste. Depois de uma intrusão só restauro uma cópia depois de verificar a data da infeção: uma cópia de há uma semana não ajuda se o código malicioso está no site há um mês.
Desempenho e Core Web Vitals
A velocidade do site pesa na experiência de quem o visita e na posição nos resultados de pesquisa, porque o Google tem em conta as métricas Core Web Vitals: LCP, INP e CLS. Na manutenção meço-as todos os meses. Quando o resultado desce, procuro a causa: um plugin novo, imagens maiores, uma base de dados a crescer.
Avalio a base de dados pelo tamanho, pelo tempo das consultas e pela estrutura das tabelas. Verifico, entre outros, transients, revisões de artigos, metadados órfãos e índices em falta. Só apago dados depois de confirmar que a aplicação não precisa deles, e comparo o efeito de cada alteração com uma medição de base. As grandes alterações ao tema ou à arquitetura do site ficam fora da manutenção; para essas, comece pela otimização de velocidade WordPress ou pela auditoria Core Web Vitals.
Monitorização, SEO técnico e relatório
Muitos fatores técnicos que o Google tem em conta dependem do estado do site: velocidade, HTTPS, endereços canónicos corretos, mapa do site XML, ficheiro robots.txt. Na manutenção verifico se o conteúdo novo é indexado e se o Search Console não mostra erros de indexação ou rastos de spam deixados por uma intrusão.
Um site infetado pode receber um aviso nos resultados do Google. Por isso verifico os alertas de segurança, o HTTPS e a validade do certificado. Se a renovação do certificado é feita pelo alojamento, verifico também se essa automatização funciona.
O relatório técnico mostra o estado das atualizações, a disponibilidade, o desempenho e os erros de indexação encontrados. Inclui uma lista de ações, mas não substitui uma estratégia de conteúdos nem um serviço de SEO à parte.
Faturação certificada, pagamentos e integrações da loja
Numa loja portuguesa, a atualização que mais pode custar é a que mexe no que a loja liga a sistemas de fora. O WooCommerce não emite faturas: quem fatura por programa informático tem de usar um programa certificado pela AT, com ATCUD e código QR, e os elementos das faturas são comunicados à AT até ao dia 5 do mês seguinte, como explico no artigo sobre faturação no WooCommerce em Portugal. O conector entre a loja e esse programa é um plugin como outro qualquer, com o seu ritmo de versões. Depois de o atualizar, emito uma fatura de teste no ambiente de testes do programa certificado, e o clone de staging fica ligado a esse ambiente para nunca emitir faturas reais.
Os pagamentos por referência Multibanco e MB WAY chegam à loja pelo plugin de um prestador de pagamentos. Quando o WooCommerce e esse plugin recebem atualizações na mesma semana, atualizo-os em separado, com teste ao carrinho entre um e outro, para saber logo que alteração causou um problema. O teste corre o percurso carrinho, dados, entrega e pagamento sem fazer uma encomenda real.
Uma loja ligada a um ERP ou CRM pede ainda um teste da troca de dados em staging depois de cada atualização do conector. A arquitetura destas ligações está nos guias integração WooCommerce com ERP e WordPress API-first. Na manutenção mantenho a funcionar as integrações que existem; construir uma nova é um projeto à parte.
Ferramentas que uso na manutenção
Para gerir vários sites uso o ManageWP ou o MainWP, conforme a topologia de cada cliente, porque preciso de comandos repetíveis em janelas combinadas. As cópias fora do servidor seguem pelo BlogVault ou pelo UpdraftPlus para armazenamento compatível com S3, de preferência noutra jurisdição da UE e sempre com o papel de subcontratante identificado. O Wordfence ou o Sucuri completam o controlo de integridade e a análise de malware. O New Relic ou o Better Uptime correm verificações sintéticas no início de sessão, no checkout e nas páginas de campanha, além da página inicial. O WP-CLI é a interface do dia a dia: wp db search-replace nas migrações, wp transient delete --all na limpeza, wp cron event run para repor tarefas agendadas e wp core verify-checksums para comparar o núcleo com o original.
Manutenção de um site que não está em WordPress
Algumas empresas têm, ao lado do WordPress, um site noutro sistema, ou um site inteiro fora do WordPress. Também mantenho esses sites, com a mesma regra: cópia, staging, testes, publicação numa janela, plano de reversão.
- Drupal: atualizações de segurança num processo assente em Composer e Drush, migrações entre versões, módulos próprios. O Drupal 10 perde o suporte de segurança a 9 de dezembro de 2026, como descrevo no artigo fim de suporte do Drupal 10.
- TYPO3: atualizações de segurança, passagem para novas versões LTS, extensões em Extbase e Fluid.
- Laravel: versões de correção na produção em poucos dias, com a atualização das dependências do Composer, sempre primeiro num servidor de testes.
- Symfony: atualizações a partir de versões antigas, camadas de integração entre WordPress ou WooCommerce e um ERP, CRM ou PIM.
A manutenção destes sistemas é orçamentada depois de uma auditoria, porque o âmbito depende da versão, do número de módulos e de quem gere o servidor. Quando manter um sistema antigo deixa de compensar, avaliamos a passagem para WordPress. Quando essa passagem faz sentido está descrito nos artigos sobre a migração a partir do TYPO3 e a partir do Joomla.
Manutenção ao lado de migrações, integrações e auditorias
A manutenção mantém o que já funciona. Quando o site precisa de uma alteração maior, faço-a como projeto separado, com orçamento próprio, e depois o site volta à avença normal.
A mudança do WordPress para outro servidor inclui a cópia, a transferência da base de dados e dos ficheiros, a alteração de DNS e a verificação depois da publicação. Quando o site precisa de outra arquitetura, faço a migração para Next.js ou Astro.
As lojas WooCommerce em que cada dia de vendas conta acompanho-as no Store Reliability Plan, e uma loja com o carrinho parado passa primeiro pelo sprint de recuperação WooCommerce. Como se recupera o desempenho de uma loja sem a reconstruir mostra o estudo de caso anónimo de uma loja WooCommerce.
Os sites que têm de provar conformidade com regras da UE começam por uma auditoria: acessibilidade WCAG para o Ato Europeu da Acessibilidade, Core Web Vitals ou conformidade NIS2 e DORA. A manutenção sustenta depois o resultado da auditoria.
Manutenção de 5 a 10 sites do mesmo proprietário
Quando o mesmo proprietário tem vários sites, organizo a manutenção assim:
- Começamos por uma folha única: onde está alojado cada site, quem tem os acessos ao alojamento e ao domínio e quais são lojas online.
- O âmbito fica escrito site a site, porque uma loja WooCommerce pede outra atenção do que um site institucional.
- O limite de horas e o tempo de resposta entram no orçamento como valores concretos, nunca como “depende”.
- Uma rede Multisite é orçamentada caso a caso, como o resto da carteira.
- Os intervalos de preço da manutenção estão na página preço da manutenção WordPress e na lista de preços. O preço da sua carteira vem no orçamento, depois de um briefing curto.
O que inclui a manutenção WordPress e o que fica de fora
Na manutenção
- Atualizações: núcleo, plugins, temas e versão de PHP, primeiro em staging
- Cópias de segurança: diárias, incrementais, na nuvem, guardadas pelo menos 30 dias, com restauro depois de uma falha
- Monitorização e segurança: disponibilidade a cada 1 a 5 minutos, análise de malware, integridade de ficheiros
- Auditoria inicial no primeiro mês, sem custo à parte
- Contrato de subcontratação (artigo 28.º do RGPD) antes do acesso ao site
- Desempenho: medição mensal das Core Web Vitals, limpeza da base de dados
- Pedidos: por email ou sistema de pedidos, todos registados
- Relatório: estado das atualizações, disponibilidade, desempenho, erros de indexação
- Alojamento, domínios, email: só quando constam do orçamento escrito
Fora da manutenção
- Refazer um elemento que, depois de uma atualização, precisa de código novo
- Dados perdidos antes de existir a primeira cópia
- Alterações de segurança fora do âmbito acordado
- Grandes alterações ao tema ou à arquitetura do site
- Páginas novas, funcionalidades novas, design gráfico
- Estratégia de conteúdos e serviço de SEO à parte
- Migrações, integrações novas e auditorias pontuais
- Notificação de uma violação de dados à CNPD em seu nome, salvo se o contrato o previr
- Alojamento, domínios e email que não constam do orçamento
Como funcionam o limite de horas e o tempo de resposta
As horas de desenvolvimento têm um limite mensal fixado no orçamento, junto com o valor das horas acima desse limite. Esta página não traz o número, porque depende de quantos sites tem e de que tipo. As horas não usadas não passam para o mês seguinte. Trabalho fora do âmbito recebe orçamento próprio e começa depois da sua confirmação.
A monitorização corre a toda a hora. Respondo em dias úteis (CET), sem tempo de resposta garantido; não ofereço piquete 24/7. O tempo de resposta vale em dias úteis CET e significa diagnóstico e plano, sem garantia de tempo de reparação. A manutenção reduz o risco de intrusão, sem garantia de que o site nunca seja atacado com sucesso. A responsabilidade de cada parte é a que o contrato define.
Como trabalho com código
Todo o código em que mexo na manutenção fica num sistema de controlo de versões (Git): correções no tema, em plugins feitos para a empresa, na configuração. Verifico o código WordPress face às WordPress Coding Standards com o PHP_CodeSniffer e as regras WPCS, e o código PHP fora do WordPress (Laravel, Symfony, módulos Drupal) segundo a norma PSR-12. A análise estática com PHPStan apanha erros antes de o código chegar aos testes em staging. Antes de publicar, revejo a minha alteração mais uma vez, separadamente da escrita. Assim, ao fim de um ano de manutenção, o seu site tem um histórico de alterações que qualquer outro programador pode assumir.
Quem faz a manutenção
A WPPoland é Mariusz Szatkowski, programador WordPress sénior, a trabalhar com WordPress desde 2006. Faço a manutenção pessoalmente: atualizações, cópias, monitorização e relatórios ficam com a mesma pessoa com quem combina o âmbito. Escrevo o orçamento depois de um briefing curto, e o primeiro mês de manutenção começa pela auditoria inicial, incluída na mensalidade desse mês. Se está a mudar de prestador, veja antes o que verificar no contrato ao mudar de fornecedor.
Antes de fixarmos o âmbito, veja o site por si: a verificação de site WordPress obtém a versão pública de um endereço e indica números medidos, incluindo os pedidos que bloqueiam a primeira pintura e quanto pesam. O resultado é imediato e não pede email.







