Durante alguns anos, uma pergunta pareceu resumir a transformação que a inteligência artificial estava provocando na internet: se já era possível descrever um site em linguagem natural e receber uma aplicação funcional poucos minutos depois, por que uma empresa continuaria utilizando WordPress? A pergunta não nasceu apenas do entusiasmo em torno de uma nova tecnologia. Ferramentas como v0, Replit Agent, Lovable, Cursor, Claude Code e outras soluções reduziram de maneira concreta a distância entre uma ideia e uma primeira versão de software, permitindo que interfaces, funcionalidades e protótipos que anteriormente exigiriam dias ou semanas de trabalho começassem a existir durante uma conversa. Para quem observava essa transformação principalmente pela camada visível da web, parecia razoável imaginar que boa parte das plataformas acumuladas durante décadas estava prestes a perder relevância.

A transformação era real, e continua sendo. A inteligência artificial alterou a economia do desenvolvimento porque reduziu drasticamente o custo de experimentar, prototipar, escrever código, construir integrações e testar produtos digitais. Negar essa mudança para defender tecnologias anteriores seria tão equivocado quanto concluir que toda infraestrutura existente perdeu sua utilidade simplesmente porque gerar uma primeira versão ficou mais fácil. Depois de milhões de projetos e alguns anos de utilização prática, começaram a reaparecer problemas que raramente ficam evidentes na primeira demonstração: usuários, permissões, dados, segurança, estados transacionais, integrações, rastreamento, SEO, histórico, governança, manutenção, portabilidade, conformidade, automações e continuidade operacional.

Foi essa diferença que me levou a investigar o que realmente aconteceu com WordPress depois da primeira grande onda do vibe coding. O ponto de partida foi um gráfico da BuiltWith que apresenta uma ruptura bastante significativa na trajetória histórica do WordPress e, posteriormente, uma recuperação também expressiva. O estudo poderia ter se limitado a tentar descobrir se usuários abandonaram WordPress para experimentar ferramentas baseadas em inteligência artificial e depois retornaram, mas os dados não permitem uma conclusão tão simples. Quando comecei a cruzar outras fontes e, principalmente, acrescentar tudo aquilo que existe depois da interface, a pergunta sobre o futuro do WordPress passou a parecer pequena diante de um problema empresarial muito maior.

Quando uma interface pode ser produzida em minutos, o valor de um projeto digital começa a depender cada vez mais daquilo que acontece depois que essa interface entra em operação. É nesse momento que surgem publicação, comércio, usuários, dados, tracking, segurança, SEO, integrações, CRM, automações, agentes, conhecimento de domínio e responsabilidade sobre aquilo que foi colocado em produção. A discussão deixa de ser apenas sobre qual tecnologia consegue criar um site mais rapidamente e passa a envolver a diferença entre gerar software e construir uma infraestrutura digital capaz de acumular valor durante anos.

O gráfico da BuiltWith é intrigante, mas não prova que usuários voltaram para WordPress

A BuiltWith mantém uma das maiores bases comerciais de tecnologias detectadas na web e acompanha sistemas de gerenciamento de conteúdo, frameworks, ferramentas de analytics, serviços de infraestrutura, plataformas comerciais e milhares de outras tecnologias. Em agosto de 2026, os dados públicos da BuiltWith identificam aproximadamente 38 milhões de sites WordPress ativos, além de uma base histórica superior a 85 milhões de sites que utilizam ou utilizaram a tecnologia em algum momento. Independentemente de qualquer interpretação sobre participação de mercado, esses números ajudam a colocar em perspectiva algumas previsões sobre desaparecimento, porque estamos falando de uma infraestrutura que continua presente em uma parcela extraordinariamente grande da web observável.

O elemento mais interessante da BuiltWith, entretanto, está na série histórica. Depois de uma longa trajetória de crescimento, a curva apresenta uma depressão muito pronunciada e posteriormente uma recuperação também bastante expressiva. Visualmente, existe uma tentação imediata de construir uma narrativa simples segundo a qual empresas teriam abandonado WordPress durante a explosão das novas ferramentas, experimentado outras formas de construção e posteriormente retornado. É uma hipótese interessante para investigação, mas não pode ser transformada em conclusão porque a BuiltWith não acompanha uma coorte demonstrando que aqueles mesmos sites migraram especificamente de WordPress para Lovable, Replit, v0 ou outra tecnologia e depois voltaram.

Também não encontrei na documentação pública consultada da BuiltWith uma explicação específica atribuindo toda essa ruptura a uma alteração metodológica de detecção. Isso não significa que mudanças internas nunca tenham ocorrido, porque sistemas desse tamanho podem modificar classificação, universo, fingerprints e critérios ao longo do tempo. Significa apenas que não existe base documental suficiente para tratar a curva como um simples erro estatístico, da mesma forma que também não existe evidência suficiente para apresentá-la como prova de um movimento de ida e volta provocado pela inteligência artificial. O fato defensável é mais restrito: a BuiltWith mostra uma queda profunda seguida por recuperação no volume absoluto de sites WordPress detectados.

Quando colocamos essa curva ao lado da W3Techs, a história se torna menos confortável para qualquer tentativa de apresentar uma recuperação completa da plataforma. Em janeiro de 2022, WordPress representava aproximadamente 65,2% dos sites com CMS conhecido dentro da metodologia da W3Techs. A participação passou para 63,7% em janeiro de 2023, 62,9% em janeiro de 2024, 62,0% em janeiro de 2025 e 60,2% em janeiro de 2026. Em agosto de 2026, os dados da W3Techs colocam WordPress em aproximadamente 58,9% dos sites cujo CMS é conhecido e em torno de 40,7% de todos os sites analisados.

Essa série continua mostrando perda de participação relativa, e não recuperação. As duas fontes não precisam estar em conflito, porque uma tecnologia pode aumentar seu número absoluto de instalações e, ao mesmo tempo, perder participação em um mercado que cresce ou se fragmenta mais rapidamente. Shopify avançou, outras plataformas SaaS encontraram nichos específicos, arquiteturas headless amadureceram, frameworks modernos ficaram mais acessíveis e ferramentas generativas criaram novas maneiras de colocar aplicações na web. Dizer simplesmente que WordPress “cresceu” ou “caiu” sem especificar o universo medido é insuficiente para entender essa transformação.

Uma terceira perspectiva aparece quando acrescentamos dados derivados do HTTP Archive, que utiliza outra amostra e outra metodologia. Uma análise publicada em 2026 utilizando dados do HTTP Archive encontrou WordPress em aproximadamente 33,21% dos web origins mensuráveis em abril de 2026, abaixo de aproximadamente 35,76% em julho de 2022. Esse dado é especialmente importante porque o início do declínio nessa série antecede a explosão pública de Lovable e do vibe coding, o que enfraquece qualquer tentativa de atribuir toda a trajetória recente do WordPress à chegada da inteligência artificial.

O Web Almanac 2025 do HTTP Archive ainda encontra WordPress como o CMS dominante por ampla margem dentro de seu universo de identificação, ao mesmo tempo em que registra uma web mais fragmentada. A conclusão metodologicamente mais rigorosa, portanto, não é que WordPress retomou sua antiga trajetória nem que esteja desaparecendo. O que os dados mostram é uma plataforma ainda gigantesca, mas atuando em um mercado muito mais diverso e competitivo do que aquele no qual consolidou sua hegemonia.

A inteligência artificial não fracassou, ela transformou a economia da criação de software

Seria igualmente incorreto utilizar essas limitações estatísticas para diminuir o impacto da inteligência artificial sobre desenvolvimento. Em 2023, o v0 ajudou a popularizar uma experiência na qual interfaces podiam ser produzidas a partir de descrições em linguagem natural. Em setembro de 2024, a Replit apresentou seu Agent, ampliando essa experiência para configuração de ambientes, instalação de dependências, desenvolvimento e execução de aplicações. Cursor, Claude Code e outras ferramentas aprofundaram a mudança, fazendo com que assistência generativa deixasse de ser apenas demonstração tecnológica e passasse a fazer parte do trabalho cotidiano de desenvolvimento.

Lovable oferece talvez o exemplo mais visível da escala alcançada por essa experimentação. Em agosto de 2026, a empresa anunciou uma rodada Série C de US$ 400 milhões, com avaliação de US$ 13,3 bilhões, e informou que mais de 60 milhões de projetos haviam sido criados desde seu lançamento em novembro de 2024 e que aplicações construídas na plataforma recebiam mais de 900 milhões de visitas por mês. Esses números são extraordinários, mas precisam ser comparados corretamente: 60 milhões de projetos criados não equivalem a 60 milhões de aplicações comerciais ativas, assim como não podem ser colocados diretamente ao lado dos quase 38 milhões de sites WordPress ativos detectados pela BuiltWith. Projetos podem incluir testes, protótipos, versões privadas, experiências abandonadas e múltiplos projetos do mesmo usuário, enquanto BuiltWith tenta identificar tecnologias presentes em sites observáveis.

Essa ressalva não reduz a importância do fenômeno. A primeira onda da IA mostrou que milhões de pessoas estão dispostas a construir de uma forma diferente e que tarefas anteriormente reservadas a equipes técnicas podem ser iniciadas por profissionais com muito menos conhecimento de programação. Também mostrou que desenvolvedores experientes conseguem utilizar modelos para automatizar etapas repetitivas, investigar código, gerar testes, produzir integrações e acelerar diferentes partes do trabalho. O que começou a mudar depois foi a percepção de que capacidade de geração e confiança operacional não são a mesma coisa.

A Stack Overflow Developer Survey 2025 mostra essa maturação de forma interessante. A adoção permaneceu alta, com 84% dos respondentes utilizando ou planejando utilizar ferramentas de inteligência artificial no desenvolvimento e 51% dos desenvolvedores profissionais utilizando IA diariamente. Ao mesmo tempo, 46% declararam desconfiar da precisão dos resultados, contra 33% que disseram confiar, enquanto 66% mencionaram como frustração respostas que estavam quase certas, mas não completamente, e 45% apontaram o tempo adicional necessário para depurar código produzido por IA. A mesma pesquisa encontrou 72% dos respondentes dizendo que vibe coding não fazia parte de seu trabalho profissional, o que sugere uma diferença importante entre utilizar IA intensamente e entregar a ela a responsabilidade integral pela engenharia.

Em 2025, a METR acrescentou outro elemento relevante ao debate ao publicar um experimento controlado com 16 desenvolvedores experientes realizando 246 tarefas reais em projetos open source maduros que conheciam profundamente. Antes do estudo, os participantes acreditavam que as ferramentas de IA reduziriam em aproximadamente 24% o tempo necessário para concluir as tarefas, mas, naquele cenário específico, o resultado observado foi aproximadamente 19% mais tempo para conclusão quando a utilização das ferramentas avaliadas era permitida. Esse resultado não demonstra que IA torna desenvolvimento mais lento em geral, porque a amostra era pequena, o contexto era específico e as ferramentas representam um determinado momento tecnológico. Ele demonstra algo mais útil: produtividade depende do tipo de tarefa, da maturidade da base de código e da quantidade de contexto que precisa ser compreendida antes de alterar um sistema existente.

O DORA 2025 State of AI Assisted Software Development Report, produzido pelo Google a partir de quase cinco mil profissionais de tecnologia e mais de cem horas de pesquisa qualitativa, chegou a uma interpretação compatível. A inteligência artificial aparece principalmente como um amplificador, capaz de potencializar organizações que já possuem bons sistemas e processos, mas também de ampliar fragilidades existentes quando qualidade, revisão, arquitetura e fluxo de entrega não acompanham o aumento de produção. Isso muda a pergunta sobre produtividade, porque escrever mais código em menos tempo não significa necessariamente aumentar na mesma proporção a capacidade de manter software durante anos.

Existe ainda uma consequência menos visível dessa aceleração, a dívida técnica. Quando uma equipe consegue produzir implementação em uma velocidade muito superior à sua capacidade histórica, documentação, revisão, testes e decisões arquiteturais também precisam acompanhar esse crescimento. Uma pesquisa de larga escala publicada em 2026 analisou mais de 304 mil commits verificados como produzidos com assistência de IA em milhares de repositórios e identificou centenas de milhares de problemas relacionados a qualidade, segurança e manutenibilidade. Mais de 15% dos commits associados a cada uma das ferramentas avaliadas introduziam pelo menos um problema, e aproximadamente 24,2% das ocorrências acompanhadas ainda permaneciam na versão mais recente do respectivo repositório.

Esses resultados não demonstram que código produzido com IA seja, por definição, inferior ao código humano. Outros trabalhos também sugerem que os efeitos variam conforme escala, arquitetura e maturidade dos projetos. O que começa a ficar evidente é que aumentar a quantidade de implementação produzida exige elevar também a capacidade de revisar, testar, documentar e compreender aquilo que está sendo incorporado. O gargalo do desenvolvimento pode estar migrando gradualmente da capacidade de produzir código para a capacidade de arquitetar, revisar e assumir responsabilidade sobre o código produzido, o que torna conhecimento de engenharia ainda mais importante em vez de simplesmente eliminá-lo.

O problema começa a mudar quando a interface entra em operação

Uma empresa pode pedir a uma ferramenta de inteligência artificial que crie uma landing page, uma área de clientes, um painel administrativo ou um formulário e receber uma primeira implementação excelente. Pode solicitar novas funcionalidades, integrações e mudanças visuais em uma velocidade que poucos anos atrás exigiria uma equipe muito maior. A capacidade técnica dos modelos continuará evoluindo e seria imprudente estabelecer hoje um limite definitivo sobre aquilo que poderão construir nos próximos anos. Ainda assim, sistemas empresariais possuem uma característica que não aparece claramente na primeira demonstração: eles acumulam estado e relações ao longo do tempo.

Usuários passam a existir e precisam ter permissões diferentes, dados começam a mudar, históricos precisam ser preservados, integrações passam a depender de contratos conhecidos, URLs recebem backlinks, conteúdos acumulam versões, leads entram em CRM, pagamentos precisam ser conciliados e diferentes departamentos começam a depender da continuidade daquele sistema. A interface continua importante, mas passa a representar apenas a parte mais visível de uma infraestrutura que precisa funcionar mesmo quando ninguém está olhando para ela. É justamente nesse ponto que a comparação entre um AI builder e WordPress deixa de poder ser reduzida à velocidade de construção da primeira tela.

Quando WordPress é tratado apenas como ferramenta para montar páginas, ele é comparado justamente na dimensão em que os sistemas generativos criaram a maior ruptura. O WordPress utilizado como infraestrutura profissional, entretanto, representa também conteúdo, usuários, papéis, permissões, mídia, revisões, taxonomias, URLs, autenticação, APIs, hooks, extensibilidade e mecanismos de atualização. Nada disso significa que ele seja a melhor escolha para qualquer projeto, porque existem aplicações em que frameworks modernos, arquiteturas específicas ou serviços SaaS oferecem uma solução mais adequada. Significa apenas que julgar uma plataforma madura pela velocidade com que ela cria a primeira página compara uma parcela pequena de seu valor operacional.

Essa distinção ajuda a explicar uma das conclusões mais importantes de toda a investigação. A inteligência artificial tornou a produção de implementação muito mais barata, mas não tornou barato na mesma proporção o conhecimento acumulado sobre os domínios que aquela implementação precisa representar. Gerar código ficou muito mais fácil; compreender comércio, publicação, educação, comunidade, mídia, dados, segurança e operação continua exigindo experiência, arquitetura e decisões que aparecem principalmente quando o sistema começa a ser utilizado de verdade.

WooCommerce mostra por que criar uma loja é diferente de operar comércio

O comércio eletrônico torna essa diferença particularmente clara. Uma ferramenta de IA consegue criar uma vitrine, páginas de produto, carrinho e checkout com enorme velocidade, além de desenvolver integrações com gateways, bancos e APIs quando recebe contexto suficiente. Uma loja real, entretanto, precisa representar produtos, variações, preços, estoque, clientes, pedidos, diferentes estados, cupons, impostos, pagamentos, reembolsos, frete, permissões, webhooks e integrações, e cada uma dessas entidades passa a ter consequências sobre as demais conforme a operação cresce.

WooCommerce acumulou esse conhecimento de domínio durante anos. Um ERP não integra com a aparência do checkout, ele integra com pedidos, produtos, clientes e estados reconhecíveis. Uma transportadora não precisa compreender visualmente a interface para executar uma cotação ou receber um pedido, ela precisa trabalhar com informações corretas e consistentes. Um gateway opera transações, um CRM trabalha com clientes, um sistema de atendimento precisa saber que determinado pedido existe e um ambiente de analytics precisa reconhecer eventos relacionados a comportamento e receita. A plataforma possui valor justamente porque esses conceitos já formam um domínio comercial compartilhado por uma enorme quantidade de integrações.

A inteligência artificial consegue desenvolver cada uma dessas funcionalidades e pode fazer sentido construir uma plataforma própria quando as necessidades do negócio justificam esse investimento. O erro é imaginar que a possibilidade de gerar o código eliminou a complexidade do comércio. Quando uma aplicação produzida por IA termina de modelar produtos, clientes, pedidos, pagamentos, estoque, frete, permissões, APIs e histórico transacional, ela não aboliu a necessidade de uma plataforma comercial, ela construiu uma.

A evolução recente do próprio WooCommerce torna essa relação ainda mais interessante. A partir do WooCommerce 10.9, a plataforma começou a disponibilizar capacidades canônicas para operações relacionadas a produtos e pedidos, com schemas de entrada e saída, metadados, verificações de permissão e comportamento definido. Isso permite representar semanticamente ações como consultar produtos, criar ou atualizar determinados recursos, consultar pedidos, alterar status e adicionar informações sem fazer com que cada consumidor precise compreender todos os detalhes internos da implementação.

Essas capacidades podem ser utilizadas pela WordPress Abilities API, por MCP, por ferramentas administrativas, automações e outras superfícies, e o movimento começou também a alcançar extensões do ecossistema. A documentação publicada pela equipe do WooCommerce descreve capacidades relacionadas a assinaturas, pagamentos, frete e outros domínios, reforçando uma mudança conceitual importante. A plataforma não está apenas adicionando recursos de inteligência artificial à interface, está começando a transformar seu conhecimento comercial em operações estruturadas que agentes podem descobrir e executar.

Isso modifica a própria pergunta sobre IA e e-commerce. Durante a primeira onda, parecia suficiente perguntar se um modelo conseguiria criar uma loja sem WooCommerce. Conforme agentes começam a atuar sobre operações reais, passa a ser necessário perguntar qual sistema mantém produtos, clientes, pedidos, estoque, pagamentos, permissões e regras de maneira suficientemente confiável para que uma inteligência artificial possa agir sobre eles. Quanto maior a capacidade da IA de executar ações, maior se torna a importância da qualidade da infraestrutura, dos dados e das regras que orientam essas ações.

Portais, e-learning e comunidades mostram que interface visual é apenas uma pequena parte do domínio

Um portal de notícias oferece outro exemplo importante porque uma IA consegue gerar rapidamente uma home com manchetes, cards, editorias e páginas de matéria que visualmente se parecem com um produto editorial completo. Uma redação profissional, entretanto, precisa representar repórteres, colunistas, editores e administradores com permissões diferentes, rascunhos, revisões, agendamento, histórico de alterações, autores, editorias, subeditorias, tags, séries, mídia, arquivo, busca, notícias relacionadas, feeds, SEO, dados estruturados, publicidade, newsletters e, em alguns modelos, assinatura ou paywall. O portal que o leitor enxerga é a superfície de uma infraestrutura editorial que precisa continuar funcionando quando centenas ou milhares de conteúdos passam a existir.

A REST API oficial do WordPress expõe posts, revisões, categorias, tags, páginas, comentários, mídia, usuários, tipos de conteúdo e diferentes configurações justamente porque a plataforma trabalha com um modelo editorial persistente. Custom Post Types, taxonomias, metadata e capabilities permitem ainda adaptar esse modelo a estruturas próprias, razão pela qual um portal de notícias ou uma operação editorial construída sobre WordPress pode representar muito mais do que uma coleção de páginas. Uma inteligência artificial pode reconstruir toda essa infraestrutura, mas, conforme faz isso, começa a recriar as abstrações de um CMS editorial.

No e-learning, a diferença entre interface e domínio é ainda mais clara. Uma página contendo vídeo, texto e botão para avançar pode ser gerada em poucos minutos, enquanto uma plataforma educacional real pode precisar representar cursos, módulos, aulas, pré-requisitos, trilhas, professores, alunos, grupos, matrículas, progresso individual, conteúdo liberado por critérios específicos, quizzes, tentativas, notas, certificados, tarefas, relatórios, assinaturas, pagamentos, notificações e integrações com outros sistemas. A inteligência artificial consegue desenvolver essas funções, mas a capacidade de escrevê-las não faz com que matrícula, progressão, controle de acesso ou histórico educacional deixem de ser problemas que precisam ser modelados corretamente.

Comunidades seguem a mesma lógica. Uma IA consegue gerar perfil, avatar, feed, comentários, grupos e mensagens com enorme velocidade, mas uma comunidade operando ao longo dos anos precisa lidar com identidade persistente, relações entre membros, grupos públicos e privados, convites, moderação, notificações, denúncias, spam, privacidade, diferentes níveis de acesso, histórico e regras próprias de convivência. Existem plataformas especializadas excelentes fora de WordPress e, em determinados cenários, elas são escolhas superiores. O ponto não é defender WordPress como solução universal, mas perceber que um construtor genérico baseado em IA não elimina a necessidade de representar corretamente as relações que fazem uma comunidade existir.

Quando comércio, publicação, educação e comunidades são observados em conjunto, começa a aparecer um padrão que considero mais importante do que qualquer comparação isolada de tecnologia. Um e-commerce precisa representar comércio, um portal precisa representar uma redação, um e-learning precisa representar uma jornada educacional e uma comunidade precisa representar pessoas e relações. A inteligência artificial consegue escrever cada vez mais partes dessas estruturas, mas o conhecimento de domínio que define como elas se comportam continua precisando existir em algum lugar da arquitetura.

Projetos especiais e WordPress Headless mostram que a discussão não precisa ser WordPress contra tecnologias modernas

A mesma conclusão aparece em projetos especiais desenvolvidos sobre WordPress e WooCommerce. Portais de fornecedores, áreas de clientes, intranets, diretórios profissionais, catálogos técnicos, sistemas de inscrições, plataformas de associados, aplicações para franquias, painéis de representantes, bases documentais, fluxos de aprovação e integrações com ERP podem utilizar WordPress como infraestrutura para conteúdo, identidade, permissões, APIs e administração enquanto recebem uma camada específica de lógica de negócio. Nesses casos, a plataforma deixa de ser percebida apenas como CMS tradicional e passa a funcionar como uma base extensível sobre a qual entidades e regras específicas são construídas.

A inteligência artificial pode tornar justamente esse tipo de projeto mais interessante, e não menos. Custom Post Types, APIs, integrações, interfaces administrativas, rotinas de importação, testes, automações e funcionalidades específicas podem ser desenvolvidos com muito mais velocidade quando profissionais experientes utilizam IA como acelerador de engenharia. Isso cria uma terceira alternativa que muitas vezes desaparece da discussão pública: a empresa não precisa escolher apenas entre utilizar WordPress da maneira mais convencional ou reconstruir toda a aplicação do zero com IA. Pode preservar uma infraestrutura madura e utilizar inteligência artificial justamente para acelerar a camada que diferencia aquele negócio.

Essa combinação pode ser ainda mais explícita em arquiteturas headless. A REST API do WordPress permite que aplicações externas consumam e manipulem seus dados, fazendo com que uma interface construída em React, Next.js ou outra tecnologia possa utilizar WordPress como infraestrutura editorial e administrativa sem depender do frontend tradicional da plataforma. Nesse cenário, inteligência artificial pode acelerar intensamente a construção da camada visual, das interações e das integrações, enquanto conteúdo, usuários, permissões e outros estados permanecem administrados por uma infraestrutura existente.

Headless não é automaticamente melhor e introduz sua própria complexidade de infraestrutura, cache, autenticação, preview, renderização e manutenção. Ainda assim, ele ajuda a desmontar uma falsa oposição segundo a qual utilizar interfaces modernas ou desenvolvimento generativo exigiria necessariamente abandonar WordPress. Em determinados projetos, o frontend pode mudar radicalmente enquanto a camada responsável por conteúdo, usuários e administração continua funcionando. A inovação na experiência não obriga a empresa a reconstruir simultaneamente todos os sistemas que já resolvem problemas operacionais por trás dela.

O site também não termina quando recebe o clique, porque marketing depende de dados confiáveis

Existe outra camada quase invisível para quem avalia um site pela interface, mas que influencia diretamente seu resultado comercial: mensuração. Uma landing page pode possuir excelente design, boa velocidade, copy adequada e formulário funcionando, mas ainda representar uma infraestrutura de marketing frágil se a empresa não consegue compreender corretamente de onde vieram seus leads, o que aconteceu depois da primeira conversão e quais vendas efetivamente foram produzidas por determinada campanha. Essa diferença se torna ainda mais importante em um ambiente no qual plataformas de mídia utilizam cada vez mais sinais de conversão para automatizar segmentação, atribuição e decisões de lances.

Um site construído com inteligência artificial pode implementar GA4, Google Tag Manager, Meta Pixel, Google Ads, Enhanced Conversions, server side tagging, Conversion API, CRM, webhooks, APIs próprias e diferentes arquiteturas de first party data. Nada disso depende de WordPress e seria incorreto apresentar a plataforma como requisito para uma mensuração madura. Um projeto criado com Lovable, Replit ou uma stack completamente própria pode ter tracking e mensuração muito melhores do que um WordPress mal implementado. A diferença volta a aparecer entre capacidade técnica e arquitetura consciente sobre aquilo que precisa ser medido.

O Google descreve o server side tagging como uma arquitetura na qual parte do processamento dos dados ocorre em ambiente de servidor em vez de depender exclusivamente de scripts executados no navegador. Essa arquitetura pode oferecer maior controle sobre eventos, destinos e processamento, inclusive com endpoints first party, mas não deve ser tratada como mecanismo para ignorar consentimento ou recuperar dados que não deveriam ser coletados. O valor está em permitir que a empresa organize melhor como determinados sinais são recebidos, tratados e encaminhados para diferentes plataformas.

A diferença fica evidente quando comparamos duas páginas visualmente idênticas. Na primeira, um envio de formulário é tratado como conversão final e encerra a visão da mídia sobre a jornada. Na segunda, a empresa preserva a origem da campanha e identificadores permitidos, relaciona o lead ao CRM, acompanha sua qualificação, identifica quando surge uma oportunidade, registra a venda e posteriormente devolve esse resultado para a plataforma de publicidade. Para o usuário, as páginas podem parecer exatamente iguais, mas, para o sistema que precisa aprender quais pessoas geram valor, elas fornecem informações completamente diferentes.

O Google utiliza Enhanced Conversions para melhorar a precisão da mensuração com dados first party tratados conforme suas especificações, enquanto mecanismos de importação e Enhanced Conversions for Leads permitem relacionar informações capturadas no site a resultados que aparecem posteriormente no processo comercial. Isso ajuda a explicar por que tracking não deveria ser pensado apenas como um conjunto de tags instalado depois que a página fica pronta. O site faz parte do sistema de aprendizado da mídia porque os eventos que consegue registrar e devolver influenciam aquilo que a plataforma passa a enxergar como resultado relevante.

Quando uma empresa mede apenas clique em WhatsApp, formulário enviado ou início de checkout, o algoritmo recebe sinais sobre ações intermediárias. Quando consegue fechar o ciclo entre campanha, lead, CRM, oportunidade, venda e receita, passa a fornecer informações mais próximas do resultado econômico que realmente importa. Isso não garante que a campanha será boa, porque estratégia, oferta, mercado, criativo e concorrência continuam sendo determinantes, mas demonstra por que duas páginas aparentemente equivalentes podem oferecer capacidades de otimização completamente diferentes. Um site não é apenas destino do tráfego, ele também participa do sistema de dados que ensina a mídia a interpretar esse tráfego.

Automação e MCP tornam a qualidade do estado ainda mais importante

O mesmo princípio aparece na automação. Um novo lead, uma venda, uma alteração de pedido, uma matrícula, a publicação de determinada notícia ou uma mudança de estado dentro de um projeto especial podem iniciar processos em CRM, ERP, atendimento, logística, marketing ou sistemas internos. Uma inteligência artificial consegue produzir APIs, webhooks e fluxos desse tipo com grande velocidade, mas uma automação crítica precisa lidar também com autenticação, tratamento de erros, repetição segura de operações, logs, filas, limites de requisição e observabilidade. A velocidade de geração reduz o custo de implementação, mas não elimina a necessidade de saber exatamente o que ocorreu e o que deve acontecer quando alguma parte do processo falha.

Model Context Protocol acrescenta uma nova camada porque permite que agentes descubram ferramentas e recursos disponibilizados por sistemas externos. Qualquer aplicação com backend adequado pode implementar seu próprio servidor MCP, portanto isso não é exclusividade de WordPress. Um projeto criado integralmente com IA pode expor ações para criar um lead, consultar um cliente, localizar um pedido, gerar um orçamento, verificar desempenho de campanha ou executar praticamente qualquer outra capacidade que sua arquitetura permita. O aspecto realmente importante é aquilo que existe por trás dessas ações.

MCP não cria automaticamente clientes, pedidos, estoque, regras comerciais, permissões ou histórico. Ele oferece uma maneira estruturada para que agentes trabalhem sobre sistemas que já representam essas entidades. Se dados são inconsistentes, permissões foram mal projetadas ou estados não possuem significado claro, tornar o sistema acessível a um agente pode ampliar o problema em vez de resolvê-lo. Quanto mais autônoma se torna a atuação da IA, mais importante passa a ser a qualidade da infraestrutura que define aquilo que ela pode enxergar e fazer.

É nesse contexto que a WordPress Abilities API, introduzida no WordPress 6.9, merece atenção. Ela oferece uma maneira padronizada de registrar capacidades com descrição, schemas de entrada e saída e verificações de permissão, permitindo que diferentes consumidores descubram o que um sistema consegue fazer. Em fevereiro de 2026, o WordPress apresentou também o MCP Adapter, conectando essas capacidades a clientes compatíveis com Model Context Protocol.

A direção ficou ainda mais concreta no WordPress.com, que passou a disponibilizar suporte a agentes através de MCP e, em 24 de agosto de 2026, anunciou uma integração oficial com ChatGPT para trabalhar com sites autorizados e realizar diferentes ações com controles e confirmações. Isso não demonstra que WordPress venceu qualquer disputa contra inteligência artificial. Demonstra que a própria separação entre “WordPress” e “IA” começa a perder utilidade, porque a primeira onda perguntou se modelos conseguiriam construir sites sem WordPress enquanto a fase seguinte já começa a mostrar agentes operando WordPress e WooCommerce.

SEO também precisa ser analisado sem transformar WordPress em religião

Existe uma ideia repetida há muitos anos segundo a qual WordPress seria simplesmente melhor para SEO. Essa afirmação precisa ser tratada com precisão porque Google não concede um bônus de ranking pelo fato de uma página utilizar WordPress. Uma instalação lenta, mal estruturada, com conteúdo superficial, arquitetura de informação deficiente, plugins problemáticos e experiência inadequada pode ter desempenho orgânico inferior ao de uma aplicação construída em qualquer outra stack. A plataforma não substitui estratégia, conteúdo, qualidade técnica, autoridade ou experiência.

A vantagem do WordPress aparece na maturidade de sua infraestrutura editorial e no ecossistema construído ao redor dela. URLs persistentes, autores, revisões, taxonomias, publicação, sitemap e uma enorme camada de ferramentas para metadata, canonical, redirecionamentos, dados estruturados, links internos e controle de indexação tornam mais natural executar várias das práticas necessárias a uma operação profissional de SEO. Isso facilita construir uma arquitetura madura, mas não garante resultado.

Também seria desatualizado afirmar que sites criados por ferramentas generativas são, por definição, difíceis de rastrear. A documentação atual da Lovable informa que projetos criados desde 13 de maio de 2026 utilizam TanStack Start com server side rendering, enquanto projetos anteriores baseados em React e Vite recebem prerendering em URLs públicas. A plataforma também passou a trabalhar explicitamente com sitemap, metadata, canonical, dados estruturados, HTML semântico, acessibilidade, links internos e performance, o que elimina uma das críticas mais simplistas dirigidas aos primeiros construtores de aplicações JavaScript.

Um site produzido com inteligência artificial pode ser tecnicamente excelente para rastreamento e indexação, assim como pode superar um WordPress mal implementado em velocidade e experiência. A descoberta realmente interessante está em outra direção: conforme os AI builders amadurecem, começam a incorporar justamente as camadas que todo sistema profissional precisa resolver depois que a página existe. Server side rendering, prerendering, sitemap, canonical, semântica e dados estruturados continuam necessários porque a maneira de gerar a interface mudou, mas os fundamentos de descoberta não desapareceram.

Essa convergência também aparece nas experiências generativas dos mecanismos de busca. O Google tem reforçado que as boas práticas tradicionais de SEO continuam relevantes para recursos como AI Overviews e AI Mode porque esses produtos utilizam os principais sistemas de ranking e qualidade da Pesquisa. Para o ChatGPT, a OpenAI explica que sites públicos podem aparecer na busca e recomenda permitir OAI SearchBot quando o publisher deseja facilitar descoberta, exibição e citação. Nada disso estabelece preferência por WordPress, mas reforça que rastreabilidade, semântica, autoridade e clareza continuam importantes mesmo quando a interface de descoberta deixa de ser uma lista tradicional de links.

Quando gerar texto deixa de ser difícil, autoridade passa a valer mais

A inteligência artificial também mudou a economia da publicação porque produzir grandes volumes de texto deixou de exigir necessariamente uma operação editorial proporcional ao volume produzido. Em um estudo com aproximadamente 900 mil páginas novas detectadas em abril de 2025, a Ahrefs estimou que 74,2% continham algum grau de conteúdo produzido com inteligência artificial. Detectores de IA são probabilísticos e podem produzir falsos positivos ou falsos negativos, portanto esse número não deve ser interpretado como identificação perfeita da autoria de cada página, mas a escala é suficiente para mostrar que utilizar IA no processo editorial já deixou de ser uma característica excepcional.

Isso muda a discussão sobre autoridade porque simplesmente utilizar inteligência artificial não diferencia mais uma fonte. O Google não declara aplicar uma penalização automática a conteúdo apenas porque IA participou de sua produção. Sua orientação sobre conteúdo generativo reconhece utilizações legítimas dessas ferramentas e concentra o problema em produção de baixo valor, especialmente quando escala é utilizada principalmente para manipular resultados. A política de scaled content abuse também é tecnologicamente neutra, porque conteúdo produzido por pessoas em grande quantidade pode ser tão pouco útil quanto conteúdo automatizado.

Em julho de 2026, a Ahrefs publicou uma análise baseada em páginas coletadas entre as dez primeiras posições de 100 mil resultados de pesquisa e encontrou conteúdo fortemente classificado como IA inclusive entre as primeiras posições. Ao mesmo tempo, páginas com menor proporção estimada de conteúdo sintético apareciam com maior frequência no topo e apresentavam indicadores melhores em outras dimensões analisadas. Isso representa correlação, não demonstração de uma penalidade algorítmica contra IA, e a própria interpretação do estudo aponta para qualidade e valor como explicações mais plausíveis do que a simples origem tecnológica do texto.

Para mim, existe uma distinção mais útil do que separar rigidamente conteúdo humano de conteúdo produzido por inteligência artificial: separar conhecimento primário de conteúdo derivativo. Um artigo pode ser redigido com grande participação de IA e ainda representar conhecimento original quando nasce de dados próprios, projetos executados, pesquisas, testes, cases, entrevistas, medições, decisões e experiência profissional. Também é possível que uma pessoa escreva manualmente milhares de palavras apenas reorganizando informações já publicadas por terceiros sem acrescentar qualquer conhecimento novo.

Autoridade não nasce apenas de quem pressionou as teclas, ela nasce da origem da informação. Uma inteligência artificial consegue sintetizar milhares de relatos sobre uma implementação de WooCommerce, mas não realizou aquela implementação por conta própria. Pode reproduzir a linguagem de alguém experiente e descrever perfeitamente determinado problema, mas não possui a ocorrência histórica que sustenta aquela experiência. Quando uma empresa publica aquilo que aprendeu depois de executar projetos reais, existem pessoas, dados, erros, decisões e consequências por trás do texto, mesmo que ferramentas de IA tenham participado da pesquisa, da organização e da redação.

À medida que texto se torna abundante, essa proveniência tende a ganhar valor relativo. Reputação, dados próprios, histórico, cases, backlinks conquistados, metodologia, reconhecimento externo e responsabilidade editorial continuam difíceis de produzir instantaneamente. Quando praticamente todos conseguem explicar a mesma coisa, a pergunta mais importante deixa de ser apenas se a frase foi escrita por uma pessoa ou por um modelo e passa a ser quem sabe aquilo, como sabe, qual evidência possui e por que aquela fonte merece confiança. Quando texto se torna commodity, autoridade se torna escassa justamente porque informação original, experiência e reputação continuam exigindo tempo.

Segurança mostra novamente a distância entre funcionar e estar pronto para produção

Quando sistemas começam a receber dados, usuários e transações, segurança deixa de ser detalhe de implementação. E aqui WordPress não merece qualquer narrativa confortável. O relatório da Patchstack registrou 11.334 novas vulnerabilidades no ecossistema WordPress em 2025, com a maior parte concentrada em plugins e temas e apenas uma pequena parcela relacionada ao core. O número demonstra o preço de um ecossistema extremamente aberto e extensível: cada extensão pode adicionar capacidade, mas também adiciona código, dependências, atualizações e potencial superfície de ataque.

Um WordPress negligenciado pode se transformar em uma infraestrutura insegura independentemente de todas as vantagens que a plataforma ofereça em outras áreas. Escolha de componentes, política de atualização, credenciais, infraestrutura, backups, monitoramento e arquitetura continuam determinando grande parte da segurança prática. Open source não significa ausência de risco, da mesma forma que maturidade de ecossistema não elimina vulnerabilidades.

Aplicações produzidas rapidamente com IA apresentam outro perfil de risco. Autenticação, autorização, configuração de banco, secrets, validação de dados, APIs e regras de acesso continuam existindo mesmo quando a interface foi criada em poucos minutos. Um caso registrado como CVE-2025-48757 levantou preocupações relacionadas a políticas insuficientes de Row Level Security em determinadas aplicações produzidas na Lovable, embora o próprio registro também informe que a classificação é contestada pela empresa, que atribui a proteção da configuração de dados da aplicação à responsabilidade do desenvolvedor.

A discussão em torno desse caso é mais interessante do que tentar utilizá-lo para declarar uma tecnologia insegura. Ela demonstra que uma ferramenta pode permitir que alguém construa rapidamente uma aplicação funcional e ainda deixar decisões críticas de segurança sob responsabilidade de quem projetou a aplicação. No WordPress, uma grande parte do risco prático aparece no ecossistema de extensões e na manutenção; em aplicações rapidamente geradas, parte do risco pode aparecer em decisões arquiteturais menos visíveis para quem solicitou a funcionalidade. Em ambos os casos, software que funciona e software preparado para produção são conceitos diferentes.

LGPD e governança de dados entram na discussão quando a aplicação começa a pertencer à operação

Para empresas brasileiras, a questão de dados acrescenta ainda LGPD e transferência internacional. A legislação brasileira não proíbe genericamente que dados pessoais sejam processados fora do país, e a ANPD regulamenta diferentes mecanismos aplicáveis a transferências internacionais. Isso significa que seria incorreto afirmar que utilizar uma plataforma estrangeira viola automaticamente a LGPD ou que hospedar WordPress em um datacenter brasileiro resolve sozinho todas as obrigações de conformidade.

A questão empresarial realmente importante é governança. A organização sabe quais fornecedores tratam seus dados, para quais finalidades, em quais condições contratuais, através de quais jurisdições e com quais mecanismos de proteção? Consegue alterar essa arquitetura quando necessário e sabe quais integrações deixam de funcionar quando um determinado fornecedor é removido? Quanto mais um sistema entra no coração da operação, mais essas perguntas deixam de ser jurídicas apenas no papel e passam a fazer parte da engenharia e da continuidade empresarial.

WordPress autohospedado oferece maior controle sobre servidor, arquivos e banco, mas continua podendo utilizar Google, Meta, Cloudflare, CRM, serviços de e-mail, gateways de pagamento e diversos outros fornecedores que participam do tratamento de dados. A diferença, portanto, não deve ser formulada como WordPress versus LGPD ou AI builder versus LGPD. O que importa é o grau de conhecimento e controle que a empresa possui sobre sua própria arquitetura, suas dependências e seus fluxos de informação.

Um site criado integralmente com IA pode ser um ativo digital

Depois de atravessar criação, operação, conteúdo, comércio, tracking, segurança e dados, chegamos à pergunta empresarial que considero mais importante desta investigação: um site criado integralmente com inteligência artificial pode ser um ativo digital? Pode, e seria um erro afirmar o contrário. Da mesma maneira, um WordPress pode existir durante anos sem se transformar em um ativo relevante quando não acumula conteúdo, autoridade, dados, usuários, relações, integração ou conhecimento operacional.

A tecnologia utilizada para produzir o sistema não determina sozinha a natureza do patrimônio. Um ativo digital começa a existir quando a empresa consegue controlar e preservar aquilo que acumula ao longo do tempo: domínio, conteúdo, URLs, backlinks, autoridade, usuários, dados, software, integrações, eventos, histórico, reputação, automações e conhecimento. A interface participa desse patrimônio, mas raramente representa tudo aquilo que possui valor.

Imagine uma empresa que utiliza o mesmo domínio há dez anos, possui milhares de URLs indexadas, backlinks relevantes, conteúdos próprios, tráfego orgânico, dados de clientes, histórico de campanhas, integrações comerciais e reconhecimento de marca. Ela pode substituir completamente o código do site e preservar grande parte desse patrimônio se mantiver domínio, URLs, redirects, conteúdo, dados e relações. Também poderia manter exatamente o mesmo código e destruir boa parte do ativo se abandonasse o domínio, quebrasse URLs importantes, perdesse acesso aos dados ou eliminasse seu histórico.

Essa diferença mostra por que propriedade contratual e independência operacional não são a mesma coisa. Os termos da Lovable reconhecem direitos do cliente sobre seus dados, projetos e outputs dentro da relação contratual, enquanto a empresa preserva propriedade sobre sua plataforma, infraestrutura e diferentes componentes do serviço. Uma empresa pode possuir contratualmente aquilo que construiu e ainda depender de serviços externos para executá-lo. Isso não torna a arquitetura ruim, mas significa que propriedade e portabilidade precisam ser analisadas separadamente.

Portabilidade real exige perguntas mais concretas. O domínio pertence à empresa? Conteúdo e dados podem ser exportados? Usuários podem ser migrados? O código pode ser executado e mantido por outra equipe? URLs podem ser preservadas? Banco, arquivos e integrações podem ser transferidos? Tracking, CRM e histórico comercial continuam funcionando depois da mudança? Quanto maior o número de respostas positivas, maior tende a ser a independência daquele ativo em relação à tecnologia ou ao fornecedor que participou de sua construção.

WordPress open source possui uma vantagem histórica nesse aspecto porque aplicação, arquivos e banco podem ser movidos entre provedores e o direito de utilizar o software principal não depende da continuidade de uma única empresa. Essa vantagem não é absoluta, porque plugins proprietários, serviços SaaS, gateways, CDNs e outras dependências podem criar diferentes formas de lock in. Ainda assim, a quantidade de caminhos disponíveis para substituir partes da infraestrutura representa uma característica importante de soberania tecnológica.

Propriedade intelectual e manutenibilidade também passaram a fazer parte da conversa

Existe ainda uma dimensão jurídica que ganhou relevância com geração automática de software. Em 2025, o U.S. Copyright Office publicou sua análise sobre proteção de materiais produzidos com inteligência artificial generativa e concluiu que elementos puramente gerados por IA, sem contribuição humana criativa suficiente, podem não receber proteção por copyright, enquanto contribuições humanas relevantes podem ser protegidas. Isso não significa que “código produzido por IA não pertence a ninguém”, porque direitos contratuais, dados, marcas, segredos empresariais e diferentes componentes podem seguir regimes próprios.

Também não é possível transportar automaticamente essa interpretação norte-americana para o Brasil. A Lei nº 9.609 de 1998 regula a proteção de programas de computador no país, enquanto questões específicas envolvendo autoria e sistemas generativos continuam exigindo interpretação jurídica adequada. Para empresas, a conclusão prática é menos sensacionalista: quanto mais estratégico o software, maior deve ser o cuidado documental, contratual e jurídico sobre aquilo que foi produzido, independentemente de a implementação ter sido escrita manualmente ou com grande participação de inteligência artificial.

Existe uma dimensão menos jurídica e igualmente importante, a manutenibilidade. Uma IA permite que uma única pessoa produza uma quantidade de código muito maior em menos tempo, o que pode representar enorme ganho de produtividade, mas também pode fazer com que a quantidade produzida cresça mais rapidamente do que documentação, arquitetura, testes, versionamento e compreensão coletiva do sistema. Esse risco não nasceu com inteligência artificial, porque software desenvolvido manualmente há décadas também pode depender de uma única pessoa e possuir documentação inadequada, mas a velocidade de geração torna possível chegar muito mais rapidamente a uma base de código grande.

Um ativo empresarial precisa sobreviver à troca de desenvolvedor, agência e fornecedor. Se apenas quem conduziu os prompts consegue compreender como a aplicação funciona, existe concentração de conhecimento; se outra equipe consegue assumir código, infraestrutura, dados e operação com documentação suficiente, existe maior independência. Por isso considero que controle, portabilidade, valor acumulado, manutenibilidade e governança são cinco dimensões particularmente úteis para avaliar maturidade de um ativo digital.

Tracking, autoridade, dados e conhecimento também fazem parte do patrimônio digital

Existe uma consequência desse raciocínio que normalmente desaparece quando ativo digital é reduzido a site ou domínio. Uma empresa que mantém histórico de campanhas, eventos, conversões, fontes de aquisição, relacionamento com CRM, vendas, automações e integrações acumulou uma infraestrutura de inteligência comercial. Quando troca a campanha, essa estrutura permanece; quando muda de agência, deveria permanecer; quando começa a utilizar agentes, existe contexto operacional sobre o qual eles podem trabalhar. Tracking não é apenas configuração técnica, ele também representa memória da operação.

O mesmo vale para conhecimento. Uma biblioteca editorial construída ao longo dos anos, com artigos assinados, dados próprios, cases, posições técnicas, pesquisas e links recebidos de outras fontes representa muito mais do que um conjunto de páginas. Ela ajuda a construir a entidade que mecanismos de busca, sistemas de inteligência artificial, clientes e o próprio mercado reconhecem quando procuram informação sobre determinado assunto. Quanto mais fácil fica produzir conteúdo genérico, maior pode se tornar o valor relativo de um histórico editorial que existe porque uma organização possui experiência real para sustentar aquilo que publica.

Um ativo digital maduro, portanto, não acumula apenas código e páginas. Acumula conteúdo, identidade, dados, relações, eventos, histórico, autoridade, conhecimento e contexto operacional. Essa conclusão importa especialmente para empresas que continuam tratando seus sites como peças descartáveis de comunicação, porque a interface pode ser trocada com facilidade crescente enquanto várias das camadas que realmente acumulam valor precisam ser preservadas com muito mais cuidado.

A primeira onda tornou a interface abundante, a próxima fase começa a profissionalizar a operação

Durante a primeira grande onda da inteligência artificial, a parte visível da criação recebeu naturalmente a maior atenção porque assistir a uma aplicação surgir de uma conversa era, e continua sendo, extraordinário. Esse avanço não precisa ser minimizado para reconhecer que a interface representa apenas parte do problema empresarial. Quando uma organização começa a operar conteúdo, comércio, educação, comunidade, mídia, CRM, automação, tracking, segurança e dados, o desafio deixa de ser simplesmente gerar aquilo que aparece na tela e passa a incluir tudo aquilo que precisa continuar correto depois que usuários reais começam a interagir.

É exatamente por isso que plataformas maduras podem continuar relevantes mesmo quando escrever código fica muito mais barato. Elas acumulam modelos de domínio, estados, permissões, integrações e conhecimento construídos a partir de problemas que só aparecem quando milhares ou milhões de operações passam pelo sistema. A inteligência artificial pode reduzir drasticamente o custo de estender essas plataformas, criar funcionalidades específicas, desenvolver integrações e corrigir limitações, o que significa que a relação mais interessante entre IA e infraestrutura talvez não seja substituição, mas combinação.

No caso do WordPress, essa combinação começa a se tornar concreta. A plataforma oferece conteúdo, identidade, permissões, APIs, mídia e extensibilidade; WooCommerce adiciona domínio comercial; soluções educacionais podem adicionar jornada de aprendizagem; comunidades acrescentam relações; projetos especiais modelam regras próprias de negócio; tracking conecta comportamento a marketing e CRM; Abilities API e MCP começam a expor capacidades para agentes. A inteligência artificial pode participar de todas essas camadas como ferramenta de desenvolvimento e, progressivamente, também como agente capaz de operar estruturas existentes.

Isso modifica a natureza da pergunta que iniciou este estudo. Se um agente consegue consultar produtos, alterar um pedido, publicar uma matéria, verificar uma matrícula, analisar uma campanha ou executar uma rotina interna, ele não precisa necessariamente reconstruir o sistema inteiro. Precisa de acesso autorizado a uma infraestrutura que represente corretamente produtos, pedidos, autores, alunos, eventos, permissões e regras. Quanto mais capaz a inteligência artificial se torna de criar e agir, mais importante pode se tornar a qualidade dos sistemas, dados e decisões que dão contexto a essa criação e a essa ação.

Na minha visão

Depois de anos trabalhando com sistemas de gestão, operação, WordPress, WooCommerce, integrações, SEO, tracking e projetos digitais, minha leitura é que a primeira onda da inteligência artificial revelou duas coisas que parecem contraditórias apenas quando observadas superficialmente. A primeira é extraordinariamente positiva: produzir software ficou mais acessível, mais rápido e mais democrático, criando oportunidades para empresas e profissionais que anteriormente não conseguiriam experimentar determinadas ideias. A segunda é que, conforme a primeira versão ficou muito mais barata, ficou também mais fácil confundir a existência de uma interface funcional com a existência de uma infraestrutura digital madura.

Essa diferença aparece em praticamente todos os domínios que analisamos. Uma página de produto não representa uma operação inteira de comércio eletrônico, da mesma forma que um checkout não representa pedidos, estoque, pagamentos, logística e conciliação. Uma home com manchetes não representa uma redação com permissões, revisão, histórico e governança editorial. Uma página com vídeo não representa uma plataforma educacional com matrícula, progressão e certificação. Um feed não representa uma comunidade com identidade, relações e moderação, assim como uma landing page não representa uma infraestrutura de marketing quando o clique não consegue ser relacionado corretamente a CRM, oportunidade, venda e receita.

Nada disso constitui uma crítica à inteligência artificial, porque ela pode ajudar a desenvolver todas essas camadas e provavelmente fará isso com eficiência cada vez maior. O ponto é que a IA não torna desnecessário saber que essas camadas existem, como se relacionam, quais estados precisam ser preservados e quais responsabilidades pertencem a cada parte da arquitetura. Conforme o custo de produzir implementação cai, o diferencial migra progressivamente da capacidade de escrever sintaxe para a capacidade de compreender domínio, arquitetar sistemas, revisar resultados, governar dados, proteger operações e assumir responsabilidade sobre aquilo que foi construído.

Existe também uma consequência empresarial que considero ainda maior. Durante muitos anos, empresas trataram seus sites como peças de comunicação que poderiam ser descartadas quando o design envelhecesse. Essa visão se torna especialmente perigosa em uma época na qual gerar uma interface nova leva poucas horas, porque pode criar a impressão de que tudo aquilo que existe por trás também é descartável. Domínios acumulam histórico, URLs acumulam autoridade, conteúdos acumulam conhecimento, backlinks acumulam reputação, CRMs acumulam relações, tracking acumula sinais, bancos acumulam dados, integrações acumulam contexto, lojas acumulam histórico comercial, comunidades acumulam relações humanas e plataformas educacionais acumulam jornadas de usuários.

É por isso que não considero mais suficiente perguntar se WordPress é melhor ou pior do que determinada ferramenta de inteligência artificial. Uma aplicação criada integralmente com IA pode se transformar em um excelente ativo digital, enquanto um WordPress mal administrado pode ser apenas uma dependência cara e desorganizada. O que interessa é quanto controle a empresa possui, quão portátil é a arquitetura, quanto valor foi acumulado, se outra equipe consegue assumir a operação e se existe governança suficiente para compreender dados, permissões, responsabilidades e dependências.

Também não vejo inteligência artificial e WordPress como duas linhas necessariamente destinadas a uma colisão. Quanto mais capaz a IA fica de criar e operar software, mais importante se torna a qualidade dos sistemas, dados e regras aos quais ela recebe acesso. WordPress e WooCommerce já começam a expor capacidades estruturadas para agentes, enquanto a própria inteligência artificial reduz o custo de desenvolver aquilo que cada empresa precisa de maneira específica sobre essa infraestrutura. A primeira onda democratizou a criação; a fase que começa agora parece muito mais relacionada à profissionalização da operação e à capacidade de transformar geração rápida em sistemas que possam ser mantidos com responsabilidade.

Depois de cruzar BuiltWith, W3Techs, HTTP Archive, Stack Overflow, METR, DORA, pesquisas recentes sobre dívida técnica, Ahrefs, Google, OpenAI, Lovable, WordPress, WooCommerce, dados de segurança e questões de governança e propriedade intelectual, não encontro evidência suficiente para declarar que a inteligência artificial matou WordPress, assim como não encontro fundamento para afirmar que WordPress venceu essa disputa ou retomará inevitavelmente sua antiga participação relativa. O que encontro é uma transformação muito maior na economia do desenvolvimento, na qual ser capaz de gerar uma interface deixa rapidamente de representar sozinho uma vantagem competitiva, porque essa capacidade está se tornando abundante.

O diferencial empresarial passa a estar em construir uma infraestrutura digital que consiga ser encontrada, compreendida, citada, medida, integrada, protegida, operada, transferida e evoluída durante anos, preservando aquilo que a empresa acumulou mesmo quando ferramentas, fornecedores e tecnologias mudarem. Quando observamos o problema dessa forma, a pergunta que iniciou esta investigação deixa de ser sobre a sobrevivência de uma plataforma específica e passa a ser sobre a natureza do patrimônio que estamos construindo na internet. No fim, a pergunta mais importante para uma empresa talvez seja muito mais simples: ela está apenas gerando interfaces ou está construindo um ativo digital?

Perguntas frequentes sobre WordPress, inteligência artificial e ativos digitais

A inteligência artificial matou o WordPress?
Não. Os dados disponíveis não demonstram uma substituição estrutural do WordPress pela primeira onda de ferramentas generativas. A plataforma continua presente em dezenas de milhões de sites e permanece dominante entre CMSs nas principais medições, embora W3Techs e dados derivados do HTTP Archive mostrem perda de participação relativa em seus respectivos universos.

WordPress voltou a crescer?
Depende da métrica utilizada. A BuiltWith apresenta recuperação no volume absoluto de sites WordPress detectados, enquanto W3Techs e HTTP Archive continuam mostrando perda relativa dentro de suas metodologias. Volume absoluto e participação de mercado não são medidas equivalentes.

As empresas abandonaram WordPress para usar IA e depois voltaram?
Não existem dados públicos suficientes para afirmar isso. A coincidência temporal entre a ruptura observada pela BuiltWith e a primeira onda generativa torna a hipótese interessante, mas não existe uma base que acompanhe em escala empresas migrando especificamente de WordPress para AI builders e posteriormente retornando.

Um site criado com IA pode substituir WordPress?
Pode, dependendo do projeto. Uma aplicação construída com IA pode ser superior quando suas necessidades justificam outra arquitetura. A comparação precisa considerar usuários, conteúdo, dados, segurança, integrações, SEO, tracking, manutenção, portabilidade e operação, e não apenas a velocidade necessária para gerar a interface inicial.

Ferramentas de IA produzem necessariamente mais dívida técnica?
Não necessariamente. Pesquisas recentes encontraram problemas de qualidade e manutenibilidade em parte do código produzido com assistência de IA, mas os efeitos variam conforme ferramenta, projeto, escala e práticas de engenharia. O ponto mais importante é que aumentar a velocidade de geração exige aumentar também a capacidade de revisão, testes, arquitetura e documentação.

Uma ferramenta de IA consegue criar uma loja como WooCommerce?
Inteligência artificial consegue desenvolver uma operação de comércio eletrônico completa quando existe engenharia suficiente, mas isso é diferente de gerar apenas uma vitrine, carrinho e checkout. WooCommerce representa um domínio comercial amadurecido, com produtos, variações, clientes, pedidos, estoque, pagamentos, frete, impostos, reembolsos, permissões, APIs e extensões que precisam funcionar de maneira consistente em produção.

Agentes de IA podem operar WooCommerce?
Sim. WooCommerce começou a disponibilizar capacidades canônicas para produtos e pedidos e utiliza a WordPress Abilities API e integração MCP para permitir que determinadas operações sejam descobertas e executadas de forma estruturada, sempre respeitando schemas e permissões.

Uma IA consegue criar um portal de notícias completo?
Tecnicamente, consegue desenvolver todas as funcionalidades necessárias. Um portal profissional, entretanto, precisa representar autores, editorias, permissões, revisão, agendamento, histórico, mídia, busca, arquivos, URLs, SEO e fluxos editoriais, o que significa que, conforme o projeto amadurece, ele precisa resolver os mesmos problemas de domínio que uma plataforma editorial madura já enfrenta.

Uma IA consegue criar uma plataforma de e-learning?
Sim. Cursos, aulas, usuários, quizzes e diversas outras funções podem ser desenvolvidos com IA. Uma plataforma educacional em produção pode exigir ainda matrículas, pré-requisitos, progresso, grupos, certificados, pagamentos, relatórios, conteúdo condicional e integrações, portanto o desafio deixa de ser apenas gerar uma interface e passa a ser operar corretamente a jornada educacional.

Uma IA consegue criar uma comunidade?
Sim. Perfis, feeds, mensagens, comentários e grupos podem ser desenvolvidos com inteligência artificial, mas uma comunidade madura também precisa de identidade persistente, moderação, permissões, notificações, relações entre usuários, histórico, privacidade e políticas de acesso.

WordPress pode ser utilizado em projetos além de sites e blogs?
Sim. Custom Post Types, taxonomias, metadata, usuários, capabilities, REST API, hooks e plugins permitem utilizar WordPress como infraestrutura para portais, áreas de clientes, intranets, diretórios, bases de conhecimento, sistemas de inscrições, plataformas de associados, integrações e diferentes aplicações específicas.

WordPress pode funcionar de forma headless com um frontend criado com IA?
Sim. Sua REST API permite que interfaces externas em React, Next.js ou outras tecnologias consumam e manipulem dados do WordPress. Isso possibilita utilizar IA para acelerar a criação da experiência visual enquanto WordPress continua responsável por conteúdo, usuários, permissões e administração, embora arquiteturas headless também tragam complexidades próprias.

Um site criado com IA consegue utilizar tracking server side?
Sim. A tecnologia utilizada para construir o site não impede a implementação de GA4, Google Tag Manager, server side tagging, Enhanced Conversions, APIs de conversão, CRM, webhooks ou outras estruturas de mensuração. A qualidade depende da arquitetura e da implementação, não do fato de o site ter sido construído com IA ou WordPress.

Um site criado com IA pode ter o mesmo resultado em uma campanha de tráfego pago?
Sim, e pode inclusive superar um WordPress mal implementado. Resultado de campanha depende de oferta, experiência, velocidade, conversão e também da qualidade dos dados devolvidos às plataformas de mídia. Uma página tecnicamente excelente que relaciona clique, lead, CRM, venda e receita pode oferecer sinais muito melhores para otimização do que uma página que mede apenas o envio do formulário.

Por que tracking faz diferença no desempenho de mídia paga?
Porque as plataformas de publicidade aprendem com os eventos e conversões que recebem. Quando uma empresa devolve apenas ações intermediárias, o algoritmo otimiza em direção a essas ações; quando consegue relacionar leads a oportunidades, vendas e valores reais, passa a fornecer sinais mais próximos do resultado econômico desejado.

Um site criado com IA pode alimentar automações e agentes através de MCP?
Sim. Qualquer aplicação com backend adequado pode expor APIs, webhooks e ferramentas MCP. O principal desafio é possuir dados, estados, identidade, permissões e regras confiáveis para que automações e agentes consigam executar ações sem produzir inconsistências.

WordPress é melhor para SEO?
WordPress não recebe um bônus de ranking por ser WordPress. Sua vantagem está na maturidade editorial e no ecossistema disponível para administrar conteúdo, URLs, autores, taxonomias, sitemaps, metadata, redirects, dados estruturados e links internos em escala. Uma implementação ruim pode ter desempenho inferior a qualquer outra arquitetura bem construída.

Sites criados por inteligência artificial podem aparecer normalmente no Google?
Sim. AI builders modernos já conseguem utilizar server side rendering, prerendering, sitemap, metadata e outras técnicas necessárias à indexação. O fato de uma página ter sido criada com IA não a torna automaticamente invisível para mecanismos de busca.

Usar WordPress aumenta a chance de ser citado por sistemas de IA?
Não existe evidência de que ChatGPT, Gemini, Perplexity ou outros sistemas prefiram uma página simplesmente porque ela utiliza WordPress. Rastreabilidade é necessária para descoberta, mas autoridade, relevância, clareza, originalidade e confiabilidade continuam sendo problemas diferentes.

Google penaliza conteúdo criado por inteligência artificial?
Não existe uma penalização automática simplesmente porque IA participou da criação. Google combate conteúdo produzido em escala com pouco valor e objetivo principal de manipular resultados, independentemente de esse conteúdo ter sido produzido por inteligência artificial, pessoas ou uma combinação dos dois.

O que importa mais para autoridade, conteúdo humano ou conteúdo de IA?
Uma distinção mais útil é entre conhecimento primário e conteúdo derivativo. Um artigo assistido intensamente por IA pode possuir grande autoridade quando nasce de pesquisa, dados, experiência e conhecimento próprios, enquanto um texto escrito manualmente pode acrescentar pouco valor quando apenas reorganiza informações produzidas por outras fontes.

Um site completamente criado por inteligência artificial pode ser um ativo digital?
Sim. O fato de ter sido construído com IA não impede que acumule valor. O ativo depende do controle sobre domínio, conteúdo, dados, usuários, software e infraestrutura, além de portabilidade, autoridade, manutenibilidade, governança e capacidade de continuar operando independentemente da ferramenta que participou da criação.

WordPress é automaticamente um ativo digital por ser open source?
Não. O caráter aberto aumenta portabilidade e opções de controle, mas uma instalação sem conteúdo, usuários, autoridade, dados, integrações ou histórico possui pouco valor empresarial. O patrimônio aparece conforme essas camadas são acumuladas ao longo do tempo.

Ter acesso ao código significa possuir um ativo independente?
Não necessariamente. Uma aplicação pode possuir código exportável e continuar dependendo de banco, autenticação, storage, APIs, funções ou infraestrutura proprietária. Direitos sobre o código, portabilidade e independência operacional precisam ser avaliados separadamente.

WordPress é mais seguro do que aplicações criadas com IA?
Não existe uma resposta universal. WordPress possui uma grande superfície de risco em plugins, temas, configuração e manutenção, enquanto aplicações construídas rapidamente com IA podem apresentar riscos relacionados a autenticação, autorização, banco, secrets e outras decisões arquiteturais. Segurança depende de engenharia, revisão e operação em ambos os casos.

Usar uma plataforma estrangeira de IA viola a LGPD?
Não automaticamente. A legislação brasileira admite transferências internacionais de dados dentro das hipóteses e mecanismos aplicáveis. A empresa precisa compreender quem processa seus dados, para quais finalidades, em quais condições e com quais instrumentos jurídicos e técnicos.

Qual é a principal vantagem do WordPress na era da inteligência artificial?
A vantagem não está em preferência de Google ou de sistemas de IA. Está na combinação de conteúdo, identidade, permissões, APIs, extensibilidade, portabilidade e um ecossistema amadurecido, somada agora à possibilidade de expor funcionalidades de maneira estruturada para agentes por meio da Abilities API e do MCP.

Qual pergunta uma empresa deveria fazer antes de escolher WordPress ou uma ferramenta de IA?
Além de comparar velocidade, custo e experiência de desenvolvimento, a empresa deveria avaliar quanto do valor criado continuará sob seu controle quando a ferramenta, a agência, o fornecedor ou a tecnologia mudar. Domínio, dados, conteúdo, URLs, tracking, autoridade, usuários, integrações, segurança, documentação, portabilidade e capacidade operacional deveriam fazer parte dessa decisão.