O WordPress continua
De poucos em poucos anos, surge uma tecnologia que parece destinada a ocupar o lugar do WordPress…
Pesquisar
De poucos em poucos anos, surge uma tecnologia que parece destinada a ocupar o lugar do WordPress…
Por vezes, o problema não começa quando o tráfego diminui. Começa quando há demasiado.Foi o que…
De poucos em poucos anos, surge uma tecnologia que parece destinada a ocupar o lugar do WordPress.
Primeiro foram as frameworks JavaScript. Depois, os geradores de sites estáticos, os CMS headless, as plataformas SaaS, as ferramentas no-code e, mais recentemente, a inteligência artificial.
Cada nova vaga chega acompanhada por uma promessa semelhante: uma web mais rápida, mais flexível, mais segura, mais simples de manter ou mais preparada para o que vem a seguir.
E quase sempre reaparece também a mesma previsão: desta vez, o WordPress ficará para trás.
É uma previsão fácil de partilhar. Sobretudo quando se trabalha com ele há algum tempo e se conhece também tudo o que implica mantê-lo a funcionar.
E, no entanto, o WordPress continua aqui.
Não necessariamente porque seja a opção mais moderna nem porque não existam alternativas melhores para determinados projetos. Continua aqui porque, de algum modo, continua a fazer parte da conversa quando chega o momento de decidir como construir e gerir uma presença digital.
Talvez, por isso, a pergunta interessante já não seja porque é que o WordPress não desapareceu.
Talvez seja o que continua a resolver suficientemente bem para que continuemos a utilizá-lo.
O facto de o WordPress continuar aqui não significa que tenha permanecido intacto.
O WordPress atual pouco se parece, em muitos aspetos, com o CMS que utilizávamos há quinze anos. Mudaram o editor, a forma de construir interfaces, as APIs disponíveis, as versões de PHP em que funciona, os ambientes de alojamento, os processos de implementação e as expectativas de desempenho e segurança.
Também mudou a relação entre quem desenvolve uma web e quem depois tem de a gerir.
O Gutenberg introduziu uma lógica baseada em blocos. A REST API abriu a porta a arquiteturas desacopladas. O alojamento gerido transformou em serviços tarefas que antes recaíam diretamente sobre programadores ou administradores de sistemas. E práticas como staging, controlo de versões, automatização de implementações ou monitorização fazem hoje parte de muitos projetos que, há anos, eram geridos de uma forma muito mais artesanal.
Nada disto transforma automaticamente o WordPress numa tecnologia moderna por definição. Também não elimina as inércias, dependências ou problemas acumulados ao longo dos anos.
Mas obriga a matizar uma ideia: o WordPress não sobreviveu simplesmente porque milhões de sites continuam a utilizar uma instalação antiga em que ninguém se atreve a mexer.
Permaneceu porque foi mudando.
E talvez uma das chaves dessa permanência seja precisamente ter conseguido fazê-lo sem deixar de ser reconhecível para quem já trabalhava com ele.
Uma parte significativa da conversa tecnológica sobre a web acontece do ponto de vista do desenvolvimento.
Falamos de frameworks, arquiteturas, componentes, rendering, APIs, pipelines de implementação ou desempenho. E tudo isso importa. Mas nem todas as organizações precisam de construir um produto de software.
Muitas precisam de algo bastante mais quotidiano: publicar e organizar conteúdos, manter a sua informação atualizada, preparar campanhas ou incorporar novas secções quando o projeto o exige.
Uma universidade. Uma associação. Uma empresa industrial. Um meio de comunicação. Uma consultora. Uma fundação. Um site institucional.
Em todos esses casos, a pergunta principal nem sempre é qual é a arquitetura mais sofisticada, mas quem conseguirá trabalhar com ela daqui a seis meses, dois anos ou cinco.
Porque uma web não termina quando é publicada.
Depois chegam as equipas de comunicação, marketing, conteúdos, administração ou negócio. Pessoas que não querem necessariamente saber como funciona o frontend, onde o projeto é implementado ou que serviço está a responder a cada pedido.
Querem poder trabalhar.
E aí surge uma das razões pelas quais continua a ser difícil afastar o WordPress de determinadas conversas. Não porque resolva todos os problemas melhor do que qualquer alternativa, mas porque durante anos tentou resolver algo menos espetacular e, muitas vezes, mais importante: permitir que uma web continue a ser utilizável depois de terminado o desenvolvimento inicial.
Quando avaliamos uma tecnologia web, tendemos a olhar para o que acontece durante o desenvolvimento.
Como é construída. Como é implementada. Como escala. Como se integra com outros sistemas. Que desempenho oferece.
Mas uma parte importante da vida de uma web começa depois.
Alguém terá de publicar uma notícia, alterar uma página, substituir uma imagem, criar uma landing page, corrigir um texto ou reorganizar uma secção. E, em muitos projetos, essas tarefas não serão realizadas pela mesma equipa que construiu a plataforma.
Aí, o WordPress compete num terreno diferente.
Não importa apenas o que consegue fazer tecnicamente, mas também até que ponto permite que pessoas de comunicação, marketing, conteúdos ou negócio trabalhem com alguma autonomia, sem depender continuamente da equipa de desenvolvimento.
Vistas de fora, muitas dessas tarefas parecem menores. Dentro de uma organização, não o são.
Esperar vários dias para alterar um texto, abrir um ticket para substituir uma imagem ou precisar de uma nova intervenção técnica sempre que surge uma campanha pode transformar uma web perfeitamente construída numa ferramenta incómoda de utilizar.
Por isso, a experiência editorial também faz parte da arquitetura, embora raramente apareça nos diagramas.
O WordPress compreendeu muito cedo essa necessidade. Com resultados discutíveis em alguns momentos e com uma evolução que continua em aberto, mas colocando sempre a gestão de conteúdos perto do centro do produto.
E provavelmente reside aí outra parte da sua permanência: não apenas no que permite construir, mas no que permite continuar a fazer quando quem desenvolveu a web já não está presente.
Parte da força do WordPress nunca esteve apenas no software.
Está também em tudo o que existe à sua volta: temas, plugins, fornecedores de alojamento, agências, programadores, documentação, integrações e uma enorme comunidade de pessoas que trabalham com a plataforma há anos.
Esse ecossistema reduz barreiras.
É relativamente fácil encontrar alguém que conheça WordPress, ligar um serviço externo, adicionar uma funcionalidade existente ou resolver um problema que provavelmente outra pessoa já tenha tido antes.
Mas essa mesma amplitude tem um custo.
Quanto mais peças entram em jogo, mais dependências surgem. E nem todas evoluem ao mesmo ritmo, nem têm a mesma qualidade, nem são mantidas durante o mesmo tempo.
Um plugin pode deixar de ser atualizado. Outro pode entrar em conflito com uma nova versão de PHP. Um tema pode condicionar durante anos decisões que pareciam menores no momento da sua instalação. E uma funcionalidade adicionada rapidamente pode acabar por se tornar numa dependência difícil de substituir.
Também aumenta a superfície que é preciso vigiar: compatibilidades, atualizações, vulnerabilidades, desempenho e decisões técnicas tomadas por terceiros sobre os quais o projeto não tem controlo direto.
Por isso, algumas das maiores vantagens do WordPress e alguns dos seus problemas mais conhecidos têm exatamente a mesma origem.
O seu ecossistema.
E talvez por isso seja insuficiente falar de WordPress como se fosse simplesmente um CMS. Para compreender tanto a sua permanência como os seus limites, é necessário observar tudo o que existe à sua volta.
Na tecnologia, é fácil confundir o mais recente com o melhor.
Uma arquitetura mais recente pode oferecer um desempenho superior, uma separação de responsabilidades mais clara, uma experiência de desenvolvimento mais atrativa ou uma maior capacidade de adaptação a determinados cenários.
Mas nenhuma arquitetura existe em abstrato.
Existe para um projeto concreto, com uma equipa concreta, um orçamento definido e uma vida útil que provavelmente será muito mais longa do que o entusiasmo inicial pela tecnologia escolhida.
Por isso, uma solução tecnicamente mais elegante não é necessariamente uma decisão melhor.
Também é preciso perguntar quanto custa construí-la, quem poderá mantê-la, que conhecimentos exige, quanto depende de perfis especializados, com que facilidade poderá evoluir e até que ponto permite trabalhar com autonomia a quem a utilizará todos os dias.
Poderíamos falar aqui de suficiência tecnológica: escolher uma tecnologia não porque seja capaz de fazer mais, mas porque faz suficientemente bem aquilo de que o projeto precisa sem introduzir uma complexidade que não acrescenta um valor equivalente.
E talvez o WordPress tenha encontrado precisamente esse espaço ao longo dos anos.
Nem sempre será a opção mais rápida, a mais elegante ou aquela que um programador escolheria para começar do zero sem qualquer restrição. Mas, em determinados projetos, continua a oferecer um equilíbrio difícil de substituir entre custo, flexibilidade, autonomia, disponibilidade de profissionais e conhecimento acumulado.
Isso não transforma o WordPress na decisão certa por defeito.
Mas ajuda a explicar porque é que ser mais antigo não o torna automaticamente na decisão errada.
Talvez estejamos a fazer a pergunta errada.
Talvez a pergunta não seja como pode o WordPress continuar a existir em 2026.
Talvez a pergunta útil seja outra:
Em que contextos continua a fazer sentido utilizá-lo?
A alteração parece pequena, mas também muda a conversa.
Já não se trata de confrontar o WordPress com frameworks modernos, CMS headless, plataformas SaaS ou ferramentas no-code para decidir qual é superior em abstrato. Nem de defender que uma tecnologia veterana merece continuar a ser utilizada simplesmente porque o é há muitos anos.
Trata-se de compreender que problema estamos a tentar resolver, quem vai trabalhar com a plataforma, durante quanto tempo, com que recursos e com que nível de complexidade.
Essa será também a perspetiva desta série.
Não vamos explicar como instalar WordPress. Não vamos fazer uma lista de plugins indispensáveis nem tentar demonstrar que é melhor do que qualquer alternativa.
Vamos observar que lugar ocupa hoje numa web que mudou profundamente à sua volta: quando continua a ser uma boa decisão, quando começa a tornar-se um fardo e o que acontece quando tentamos adaptá-lo a necessidades para as quais talvez nunca tenha sido pensado.
Porque o facto de o WordPress continuar aqui não significa que tenha de estar em todo o lado.
E, para compreender porque continua aqui, teremos primeiro de deixar de pensar no WordPress como uma única tecnologia.
Se hoje tivesses de começar esse mesmo projeto do zero, voltarias a escolher WordPress?
Comentários