Arquitetura web para ranqueamento: stack, semântica e diagnóstico

A escolha de linguagem, framework e estratégia de renderização é uma decisão de custo de transação com o Google, tomada meses ou anos antes de qualquer profissional de SEO ser consultado. Este guia percorre as três camadas dessa herança: a stack, a semântica e o diagnóstico que decide o que corrigir, em que ordem e quando uma migração se justifica.

Existe uma categoria de site que não ranqueia e que nenhuma auditoria convencional de SEO explica. O conteúdo é adequado, as meta tags estão preenchidas, o sitemap foi submetido, e ainda assim o Google Search Console reporta páginas "Rastreadas, mas atualmente não indexadas" ou "Descobertas, mas atualmente não rastreadas" em volume que não diminui. O diagnóstico habitual (produzir mais conteúdo, conseguir mais backlinks) não resolve, porque o problema não está na camada de marketing. Está na camada de engenharia, em decisões de arquitetura web tomadas meses ou anos antes de qualquer profissional de SEO ser consultado.

A escolha de linguagem, framework e estratégia de renderização é uma decisão de custo de transação com o Google. Cada requisição do Googlebot tem um custo computacional para o buscador, e o Google aloca recursos de rastreamento (o crawl budget, nos termos da documentação oficial) de forma proporcional ao valor percebido e inversamente proporcional ao custo de processar o site. Um site que responde HTML completo em 200 ms impõe ao crawler um custo por página ordens de magnitude menor do que um que exige execução de JavaScript para revelar o conteúdo. Essa assimetria não aparece em nenhuma ferramenta de auditoria superficial, mas condiciona quantas páginas o Google conhece, com que frequência as revisita e com que fidelidade as interpreta.

O agravante é a path-dependence (dependência de trajetória): a decisão de stack tomada no dia zero do projeto, frequentemente por critérios legítimos de produtividade da equipe de desenvolvimento e sem participação de quem entende de busca, condiciona o custo de ranqueamento pelos anos seguintes. Migrar de stack depois que o site existe tem custo técnico, custo de transição de rankings e risco operacional.

Este guia trata de três camadas dessa herança: a camada de stack (linguagem, framework e renderização), a camada semântica (entidades, dados estruturados e AI Search) e o processo de diagnóstico que permite decidir o que corrigir, em que ordem, e quando uma migração se justifica. É a parte do SEO técnico que remove o teto artificial, aquele que impede conteúdo merecedor de ranquear.

Leitura semanal sem ruído. Análises como esta, direto no seu inbox. Assine a newsletter da Integrare: sem promessas de "10 dicas", só argumentos fundamentados.

Camada de stack: linguagem, framework e renderização

O que o Googlebot efetivamente processa

A afirmação "o Google renderiza JavaScript" é verdadeira e incompleta. Como descreve a documentação de JavaScript SEO do próprio Google, o processo de indexação opera em duas ondas. Na primeira, o crawler baixa o HTML bruto retornado pelo servidor e indexa o que encontra ali. Na segunda, que pode ocorrer segundos, horas ou dias depois conforme a fila do Web Rendering Service, a página entra em renderização com um Chromium headless, o JavaScript executa e o conteúdo gerado no cliente é finalmente visto.

As consequências práticas dessa arquitetura em duas ondas não são sutis:

• Conteúdo dependente de JS chega atrasado ao índice e, em sites grandes, pode simplesmente não chegar, porque a fila de renderização é um recurso escasso que o Google raciona.
• Links internos gerados via JS só são descobertos na segunda onda, o que atrasa a descoberta de páginas novas e degrada a distribuição de link equity, a autoridade transmitida por links internos.
• Meta tags e canonicals manipulados no cliente criam ambiguidade: o Google pode processar a versão do HTML bruto, a versão renderizada, ou ambas em momentos diferentes, cenário documentado de canonicals conflitantes.
• Erros de JS silenciosos (uma dependência que falha, um erro de hidratação) produzem páginas em branco para o crawler sem nenhum alarme no monitoramento convencional, que testa a experiência do usuário com browser completo, não a do bot.

A linguagem de programação em si (PHP, Ruby, Python, JavaScript no servidor) é neutra para o SEO. O que importa é o modelo de renderização que a stack induz como caminho padrão. E aqui os incentivos dos frameworks divergem.

Modelos de renderização e seu custo para o crawler

Comparativo por stack

A tabela abaixo compara as stacks mais frequentes no mercado brasileiro de pequenas e médias empresas sob os critérios que afetam ranqueamento. As avaliações refletem o comportamento padrão de cada stack; qualquer uma pode ser corrigida com esforço de engenharia. A questão é quanto esforço.

Três observações que a tabela não captura:

WordPress ranqueia apesar de si mesmo. A dominância do WordPress em resultados de busca não decorre de superioridade técnica, mas de dois fatores: renderização server-side por padrão (herança do PHP de 2003, hoje uma vantagem) e um ecossistema que tornou o básico de SEO acessível sem código. O custo aparece na cauda: sites WordPress maduros acumulam plugins até que TTFB e Core Web Vitals degradem (sites com 30 ou mais plugins ativos são a norma, não a exceção), e a essa altura o custo de auditar e remover é alto porque ninguém sabe mais o que cada plugin faz. Mapeamos esse acúmulo, plugin por plugin, na nossa análise dos melhores e piores plugins de SEO para WordPress.

Headless CMS transfere o problema, não o resolve. A arquitetura headless (CMS desacoplado servindo conteúdo via API para um front-end JS) é vendida como modernização, mas desloca toda a responsabilidade de SEO técnico (renderização, meta tags, sitemaps, canonicals) do CMS para a equipe de front-end, que raramente a assume por completo. Headless com SSG/ISR bem implementado é uma arquitetura sólida; headless com CSR é uma regressão que custa caro descobrir.

Infraestrutura é parte da stack. TTFB (time to first byte) alto consome crawl budget: o Googlebot ajusta a taxa de rastreamento para não sobrecarregar servidores lentos, o que significa que um servidor lento é rastreado menos. CDN com cache de HTML na borda, compressão adequada e um host que não colapsa sob rastreamento são pré-condições, não otimizações. Para quem está orçando um projeto novo, essa camada entra na conta desde o início; detalhamos os componentes no guia de quanto custa a criação de um site.

A decisão de stack como decisão econômica

O enquadramento correto não é "qual stack é melhor para SEO", mas "qual stack minimiza o custo total de manter o conteúdo indexável ao longo do ciclo de vida do site, dada a equipe disponível". Uma equipe PHP entrega mais valor de SEO com Laravel bem estruturado do que com um Next.js que ninguém domina; uma empresa sem desenvolvedor entrega mais com WordPress disciplinado (poucos plugins, tema leve, cache configurado) do que com qualquer stack sob medida que dependa de freelancer eventual. A stack tecnicamente superior operada abaixo da competência da equipe produz resultado inferior à stack modesta operada com domínio. Essa é uma afirmação sobre capacidades organizacionais, não sobre tecnologia, e é o mesmo argumento que desenvolvemos ao analisar por que software virou commodity e para onde o valor migrou.

Engenharia e SEO na mesma mesa. Projetos de desenvolvimento web da Integrare nascem com renderização, dados estruturados e topologia definidos antes da primeira linha de código, e o serviço de SEO audita o que já existe. Para SaaS e startups e software houses, essa é a diferença entre ranquear por arquitetura ou apesar dela.

Camada semântica: entidades, dados estruturados e AI Search

Do ranqueamento de páginas ao entendimento de entidades

O Google deixou de ser um índice de documentos para se tornar, progressivamente, um grafo de entidades: pessoas, organizações, produtos, lugares e conceitos, com atributos e relações entre si. Uma página não ranqueia apenas por conter palavras; ranqueia porque o buscador consegue resolvê-la a entidades conhecidas e avaliar a autoridade da fonte sobre aquelas entidades. Essa mudança tem uma implicação arquitetural direta: o site precisa comunicar, de forma legível por máquina, sobre o que ele é e quem o publica. Isso é trabalho de estrutura, não de redação.

Três mecanismos arquiteturais fazem essa comunicação:

Dados estruturados (schema.org via JSON-LD). A marcação em JSON-LD é o canal formal pelo qual o site declara suas entidades: Organization com nome, logo, endereço e perfis sociais; Product com preço, disponibilidade e avaliações; Article com autor e datas; LocalBusiness para operações físicas; FAQPage e BreadcrumbList para estrutura. O vocabulário completo está em schema.org e os tipos que geram rich results, na documentação de dados estruturados do Google. O erro comum é tratar schema como formalidade de plugin: marcações genéricas, incompletas ou inconsistentes com o conteúdo visível. A implementação correta é programática: o JSON-LD gerado a partir dos mesmos dados que renderizam a página (o mesmo model, no vocabulário Laravel), garantindo consistência por construção. Dedicamos um artigo inteiro à economia institucional dos dados estruturados e um ensaio na Revista Integrare sobre o schema.org como instituição. É também aqui que a camada de stack retorna: em SSR o JSON-LD está no HTML bruto e é processado na primeira onda; em CSR ele depende da fila de renderização como todo o resto.

Anchor text interno como declaração semântica. O texto dos links internos é o segundo canal. Um site cujos links internos dizem "clique aqui" e "saiba mais" desperdiça o mecanismo pelo qual o buscador aprende a relação entre páginas e termos. Links internos com âncoras descritivas ("auditoria de SEO técnico", "dados estruturados em JSON-LD") constroem, distribuídos pelo site, um mapa semântico que nenhuma meta tag substitui; o parágrafo que você acabou de ler pratica o que descreve. Isso é decisão de template e de componente, não de redator: se o CMS ou o design system induz botões genéricos, a correção é arquitetural.

Consistência de entidade entre páginas e fontes externas. Nome da organização, endereço, autoria dos conteúdos e vínculos entre autor e organização devem ser idênticos no site, no Google Business Profile, nos perfis sociais e nas citações externas. Inconsistências fragmentam a entidade aos olhos do grafo: a empresa vira duas ou três entidades fracas em vez de uma consolidada.

AI Search: a arquitetura vista por um LLM

Os sistemas de busca assistidos por modelos de linguagem (AI Overviews do Google, ChatGPT com navegação, Perplexity e o modo de busca do Bing/Copilot) mudam o consumidor final da arquitetura, mas não os seus fundamentos. Já sustentamos que a disputa de trono entre ChatGPT e Google é menos ruptura do que parece. Um LLM que precisa citar fontes para responder uma pergunta enfrenta exatamente os custos de transação descritos até aqui, amplificados:

• Conteúdo em CSR é, na prática, invisível para a maioria dos crawlers de LLM: a medição da Vercel sobre GPTBot, ClaudeBot e PerplexityBot confirma que, em geral, eles não executam JavaScript. O que já era penalidade no Google vira exclusão no AI Search.
• Estrutura extraível é citabilidade. LLMs recuperam e citam com mais facilidade conteúdo organizado em unidades autocontidas: headings que formulam a questão que a seção responde, parágrafos que sustentam uma afirmação por vez, tabelas comparativas, definições explícitas de termos. A prosa longa sem hierarquia é cara de extrair; o custo de extração se converte em menor probabilidade de citação.
• Dados estruturados e consistência de entidade alimentam a capacidade do modelo de atribuir a informação a uma fonte nomeada, condição para a citação, que é a nova unidade de tráfego qualificado nesse canal.
• A decisão sobre robots.txt para bots de IA é uma decisão de negócio nova: bloquear os bots documentados pela OpenAI protege conteúdo de treinamento, mas elimina a presença nas respostas; a resposta correta depende do modelo de receita do site, e o ponto arquitetural é que ela deve ser uma decisão explícita, não o default herdado. Tratamos essa negociação em detalhe no ensaio sobre llms.txt e a coordenação entre publicador e máquina.

A leitura econômica: AI Search não é uma disciplina nova que substitui o SEO; a falácia do "novo GEO" já foi dissecada na Revista Integrare. É a mesma função de redução de custo informacional, com um agente adicional (o modelo) intermediando a transação entre conteúdo e usuário. Sites cuja arquitetura já minimiza o custo de rastreamento, extração e atribuição capturam o novo canal como derivada do trabalho existente (é a continuidade técnica entre a busca tradicional e o AI Search); sites que dependiam de artifícios específicos do ranking tradicional, não.