SEO Técnico que sobrevive a AI Overviews, rebuilds headless e seu próximo update de algoritmo.

SEO Técnico é a camada de trabalho que decide se os motores de busca e assistentes de IA conseguem rastrear, renderizar e confiar nas suas páginas, antes que conteúdo ou backlinks tenham qualquer efeito. Cobre comportamento HTTP, semântica HTML, dados estruturados, hreflang, canonicalização, Core Web Vitals e renderização JavaScript. Erre nisso e o resto do seu investimento é peso morto.

Em 2026 a definição se expandiu. Duas mudanças impulsionaram isso. Primeiro, AI Overviews e buscas alimentadas por ChatGPT agora ficam entre a maioria dos usuários e as páginas subjacentes, o que significa que citabilidade importa tanto quanto ranking. Segundo, o site modal não é mais uma instalação WordPress, é alguma variante de front-end headless puxando conteúdo de Sanity, Strapi, Payload, Storyblok, Contentful, ou um backend WordPress headless. Cada um desses stacks introduz seus próprios modos de falha em SEO técnico que o playbook antigo não cobre.

Minha definição de trabalho para clientes em 2026: SEO técnico é tudo que uma execução Lighthouse, um relatório de rastreamento Search Console, uma verificação de citação AI Overview, e um validador de schema notam, em cada locale, cada template, cada caminho de renderização. Se qualquer um desses quatro sinais está falhando em uma URL representativa, o engajamento começa ali.

Em um site headless ou Jamstack, seu front-end framework controla a renderização e seu CMS controla o conteúdo, e SEO pode cair na lacuna entre eles. O modelo clássico WordPress + Yoast assumia um servidor, um renderizador, um motor de regras. Puxe conteúdo do WordPress para Next.js ou Astro e você não herda nada disso automaticamente.

WordPress headless combinado com Next.js ou Astro

A configuração mais comum que vemos em 2026: WP REST ou WPGraphQL expondo posts e pages, Next.js App Router ou Astro puxando-os em tempo de build ou via ISR. Os ganhos são reais, páginas saem sem inchaço de plugin, Core Web Vitals são fáceis de manter verdes, e editores mantêm um admin familiar. As armadilhas também são reais. Canonicals e meta descriptions do Yoast precisam ser transportados através do limite da API; redirecionamentos definidos no WordPress precisam chegar em vercel.json ou Netlify _redirects; sitemaps geralmente precisam ser regenerados no build do front-end, não no lado WordPress; e a verificação search console precisa acontecer na origem pública, não no domínio wp-admin.

Stacks modernos puros

Uma build Next.js + Sanity, uma build Astro + Storyblok, uma build Nuxt + Strapi, uma build Next.js + Payload, todas pulam WordPress completamente. O trabalho de SEO técnico muda para garantir que seu schema CMS modele os campos SEO que o front-end precisa (canonical override, mapa de redirecionamento, grupo hreflang, JSON de extensão de schema), e garantir que a revalidação sob demanda dispare quando o conteúdo muda. ISR cache poisoning é o assassino silencioso, uma página é servida obsoleta por horas após publicação porque revalidatePath nunca foi conectado.

O que realmente quebra primeiro

Em cerca de 200 audits headless que rodamos, o problema mais comum que quebra produção é conflito canonical, o front-end emitindo uma URL canonical enquanto o metadado CMS ou sitemap emite outra. Google escolhe uma, quase sempre não a que você queria, e a URL errada acaba no índice. Capturamos isso com um linter em tempo de build que compara canonical-emitido-do-template contra canonical-armazenado-no-CMS para uma amostra de páginas e falha a build em caso de incompatibilidade.

WordPress te dá o máximo de firepower de plugin e o máximo de formas de atirar em si mesmo. O playbook de SEO técnico em um site WordPress clássico é principalmente sobre subtração, removendo canonicals duplicados, eliminando conflitos de schema entre Yoast e RankMath e um terceiro plugin que ninguém lembra de ter instalado, controlando page builders que enviam 2 MB de CSS, e limpando cadeias de redirecionamento que cresceram por oito anos.

O stack padrão que recomendamos em 2026: um único plugin SEO (RankMath ou Yoast, nunca ambos), um host gerenciado com cache de edge adequado (Cloudways, Kinsta, WP Engine), Bricks Builder para novos builds onde performance importa ou Gutenberg nativo com Kadence ou Blocksy, um gerenciador de redirecionamento que exporta para um formato portável, e Perfmatters ou FlyingPress para limpeza de assets. O trabalho de auditoria é descobrir qual dessas decisões foi tomada de forma diferente em seu site e desfazer as consequências.

No lado headless, o trabalho muda de subtração para construção. Não há Yoast, então meta clamping tem que ser construído. Não há schema de plugin, então JSON-LD tem que ser templateado. Não há sitemap built-in, então tem que ser gerado e streamado. O volume de código que adicionamos a um projeto headless para SEO é geralmente três a cinco vezes o que um site WordPress já te dá de graça, mas esse código é seu, versionado, testável, e não quebra na próxima atualização de plugin.

GEO e AEO são os nomes para duas formas diferentes de recursos de IA consumirem tráfego de busca. AEO (Answer Engine Optimisation) é o termo mais antigo, cobre recursos do Google como Featured Snippets, People Also Ask e Knowledge Panels que extraem um trecho da sua página e o exibem como resposta. GEO (Generative Engine Optimisation) é o termo mais novo, otimização para AI Overviews, ChatGPT search, Perplexity e Bing Copilot, onde o assistente gera um parágrafo e cita sua página como fonte.

O que isso significa estruturalmente

Ambas as superfícies querem a mesma coisa: um trecho pronto para citação. As regras estruturais que vencem em todas elas são as mesmas. Use uma pergunta como seu H2, não um rótulo de tópico. Coloque a resposta nas primeiras uma ou duas frases após o título. Mantenha essa resposta sob 250 palavras. Certifique-se de que a resposta é renderizada no servidor, não dentro de um componente JavaScript que hidrata após o carregamento da página. Rastreadores de IA e extratores do Google principalmente não executam JavaScript, se sua resposta precisar de JS para aparecer, você é invisível.

Onde GEO diverge de AEO

Três coisas importam mais para GEO especificamente. Entity authority, Google e os LLMs constroem um gráfico de quem tem permissão para falar sobre o quê, e menções de marca sem link alimentam isso. Schema com arrays about e mentions, eles tornam sua página analisável como parte de um gráfico de entidade em vez de uma parede de texto. E llms.txt, um padrão emergente de arquivo em /llms.txt que oferece às ferramentas de IA um mapa curado do seu site, da mesma forma que robots.txt e sitemap.xml ajudam rastreadores de busca. Implementamos llms.txt em cada site que construímos e atualizamos sempre que uma página principal é lançada.

Você precisa de menos tipos de schema do que a maioria dos plugins emite, mas os que você usa precisam ser válidos e consistentes. Uma lista curta cobre nove em cada dez projetos.

• Organization, um único gráfico em todo o site no seu layout, com logo, sameAs (apenas contas de redes sociais reais), address e contactPoint. Nunca duplique isso por página.
• WebSite, uma vez, no layout, com potentialAction para sitelinks search se você tiver busca no site.
• BreadcrumbList, em cada página que não seja a home, com URLs corretas para a localidade (uma página em francês deve apontar para ancestrais /fr/, não /en/).
• Article ou BlogPosting, em conteúdo de formato longo, com arrays about e mentions para reforço de gráfico de entidade.
• Service, em páginas comerciais, com serviceType, provider, areaServed, audience e offers.priceSpecification quando você consegue publicar uma faixa de preço.
• Product, em ecommerce, com offers.priceCurrency, availability e aggregateRating apenas se você tiver avaliações reais.
• FAQPage, quando há pelo menos duas perguntas genuínas na página. Falsificar FAQs para vencer marcação de schema é o gatilho de ação manual mais comum que limpamos.
• LocalBusiness ou um de seus subtipos, em páginas de localização física, com coordenadas geográficas e openingHoursSpecification.

Três coisas matam schema em produção. Inventar propriedades que schema.org não define. Inventar valores para sameAs (URLs fake do LinkedIn, contas Twitter abandonadas). E enviar grafos Organization conflitantes de múltiplos plugins. Rodamos validadores de schema no linter de build e falhamos a build em qualquer um desses três padrões.

Hreflang falha em escala porque a restrição é bidirecional e o dataset é esparso. Toda variante de locale de uma página deve auto-referenciar, deve referenciar toda outra variante, e deve ser referenciada de volta por toda outra variante. Perca uma direção em uma página em um locale e Google silenciosamente faz downgrade do cluster.

O padrão que escala

Armazene um content_group_id (ou equivalente) em cada linha traduzível. Toda variante de localidade de uma página compartilha um ID. O emissor de hreflang, o emissor de sitemap e o emissor de canônico derivam seu cluster desse ID. Nunca calcule hreflang apenas com base em padrão de URL, isso falha em casos extremos (uma página em espanhol que não tem tradução em hindi quebra o cluster se seu código assume "se páginaX existe na localidade A, existe em B").

O que mata hreflang na prática

Três padrões que vemos repetidamente. Ordenação de regex de localidade, colocando "zh" antes de "zh-Hant" na sua regex de detecção de localidade, que captura a localidade errada e gera um hreflang quebrado. Esquecer x-default, cada cluster precisa de um fallback x-default, geralmente apontando para a versão em inglês. Cluster ID drift, uma tradução recebe um novo ID em vez de herdar o ID da fonte, silenciosamente dividindo um único cluster em dois não relacionados, nenhum dos quais tem um conjunto recíproco completo.

Sempre adicionamos um linter de hreflang em tempo de build que faz crawl de uma amostra de páginas, percorre os clusters de hreflang que elas referenciam e falha o build se algum cluster estiver incompleto ou assimétrico.

SEO programático está gerando milhares de páginas a partir de uma fonte de dados estruturados mais um template, diretórios, páginas de comparação, páginas de localização, páginas de glossário. Feito corretamente pode atingir a cauda longa em uma escala que conteúdo de autor único não consegue. Feito errado dispara uma ação manual e remove a maioria de suas páginas indexadas da noite para o dia.

O que diferencia um build programático limpo de um de conteúdo fino

Três coisas. Dados reais por página, cada URL tem pelo menos um fato, número ou detalhe único a ela; páginas programáticas finas compartilham 95% do seu conteúdo. Um template significativo, o template adiciona contexto, comparação, recomendação ou agregação em torno dos dados únicos, não apenas um wrapper otimizado para busca. E gating de qualidade, páginas com dados únicos insuficientes são mantidas fora do sitemap, bloqueadas do índice ou retidas em estado de rascunho até que a camada de dados se preencha.

O que aprendemos executando isso em escala

Construí o HostList.io como uma plataforma de SEO programático com cerca de 28 mil páginas de empresas de web hosting em Next.js mais Supabase. As páginas que sobreviveram a dois anos de atualizações do Google foram as que tinham pelo menos três pontos de dados únicos por URL mais um template que comparava, pontuava ou recomendava com base nesses dados. As páginas que desindexamos foram aquelas onde o dado único era apenas um nome e um preço. O custo de remover páginas finas do índice foi pequeno; o custo de deixá-las lá foi uma penalidade de ranking em todo o site quando a atualização de conteúdo útil de março de 2024 chegou.

Trazemos esse playbook operacional para builds programáticos de clientes, front-end Next.js ou Astro, dados Supabase ou Postgres, um pipeline de ingestão que pontua páginas em singularidade antes da publicação, um sitemap que faz streaming em chunks porque mais de 50.000 URLs não cabem em um único sitemap.xml, e um gráfico de link interno que puxa cada folha em um cluster temático.

Passe no Core Web Vitals no 75º percentil dos dados de campo, não em um Lighthouse run controlado em laboratório. Os dados de campo do CrUX são o que o Google usa; Lighthouse é uma ferramenta de debug. Os dois frequentemente discordam por 30% ou mais em sites reais.

Para onde o orçamento realmente vai

LCP é quase sempre a imagem hero e quase sempre resolvido recodificando para WebP com 80% de qualidade, dimensionando para as dimensões reais de exibição mais 2x retina, adicionando uma tag preload no head e definindo fetchpriority="high". Uma imagem hero de 1 MB virando um WebP de 30 KB é a mudança de maior impacto em a maioria dos projetos. CLS vem de imagens e anúncios sem dimensões explícitas, atributos de width e height explícitos em cada imagem, slots de anúncio de altura fixa e espaço reservado para qualquer widget do lado do cliente. INP vem de JavaScript pesado em interação, geralmente um gerenciador de tag de terceiros ou uma biblioteca de análise entusiasmada demais. A solução é debouncing, lazy-loading ou substituição por um equivalente mais leve.

Onde a maioria dos projetos erra

Dois padrões. Primeiro, uma imagem LCP dentro de um componente Carousel ou um layout acionado por JavaScript, a imagem só renderiza após a JS rodar, e seu LCP é o skeleton de carregamento do carousel, não a foto. Segundo, web fonts carregadas sem font-display: swap e sem preload, texto é invisível por 200-400 ms enquanto as fonts baixam, e seu LCP é empurrado para além do limite de 2.5 s mesmo que a imagem seja rápida. Ambos são detectados por uma revisão de dados de campo CrUX, não por uma única execução do Lighthouse.

Um build-time SEO linter é um script que roda no final do seu build, coleta uma amostra de arquivos HTML renderizados do diretório de saída e falha o build se encontrar padrões que degradariam o SEO em produção. É o hábito de maior impacto que adicionamos aos codebases de clientes.

O que nossas verificações checam

• Cada página tem exatamente um H1.
• Meta descrição em toda URL indexável tem entre 120 e 155 caracteres.
• O atributo html lang corresponde ao caminho da localidade (uma página /fr/ tem lang="fr").
• Os clusters de hreflang são completos e bidirecionais nas rotas traduzíveis.
• JSON-LD em cada página é válido contra as definições schema.org.
• Nenhum padrão de conteúdo banido, URLs de redes sociais falsas em sameAs, texto de placeholder de teste codificado, palavras de redação genérica banida.
• A URL canônica emitida pelo template corresponde à canônica armazenada no CMS.
• Verificação de WebP de imagem e dimensões explícitas em uma amostra de templates.

O linter é executado como o último passo de npm run build. Qualquer violação falha na build, que falha no deploy. Sem ele, toda regressão, uma meta description que cresceu além do limite, um campo SEO que alguém esqueceu de definir, um emissor de schema que quebrou quando uma propriedade foi renomeada, silenciosamente faz ship. Com ele, a regressão é detectada antes de sair do laptop do desenvolvedor.

Consiga citações escrevendo cada página relevante como um conjunto de passagens prontas para citação. Uma passagem pronta para citação é um H2 em forma de pergunta, uma resposta direta de uma ou duas frases imediatamente depois, nuances de suporte para os próximos 100-200 palavras, e zero conteúdo renderizado por JavaScript no bloco de resposta. Extractores de IA pegam aquela frase de abertura e citam a página.

O que ajuda além da estrutura de passagens

• Autoridade de entidade, presença na Wikipedia, schema de organização consistente, contas reais de sameAs, menções de marca em toda a web aberta.
• llms.txt na raiz do site, um mapa curado do site para ferramentas de IA, separado de robots.txt e sitemap.xml que servem crawlers tradicionais.
• Schema com about e mentions em conteúdo de formato longo, declara o gráfico de entidade dentro do qual a página se situa.
• Lista de permissão de robots.txt para AI-crawlers, permitir explicitamente GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot e Anthropic-AI. Bloquear mesmo um destes é uma falta de citação auto-infligida.
• Propriedade de schema speakable nas seções ricas em respostas de páginas de formato longo, uma dica para extractores de voz e IA de que esta é a passagem citável.

Rastrear citações é a parte que a maioria das equipes pula. Otterly, Profound e AthenaHQ rastreiam a participação de citação do AI Overview e Perplexity por domínio. Adicionamos rastreamento de citações semanal em cima de cada engajamento e o reportamos junto com tráfego orgânico. Se você não está medindo citações, não pode dizer se seu trabalho de GEO está fazendo algo.

Rastreadores de IA conseguem ler seu site apenas se seu robots.txt permite explicitamente seu user-agent e sua camada de hospedagem não os bloqueia na borda da rede. Ambas as verificações precisam passar. Configurações padrão do Cloudflare, regras padrão do WAF do Vercel e plugins de segurança padrão do WordPress bloqueiam rotineiramente bots de IA sem aviso.

A lista de permissão robots.txt que fornecemos

GPTBot e ChatGPT-User e OAI-SearchBot para produtos ChatGPT e OpenAI search. PerplexityBot e Perplexity-User. ClaudeBot e Claude-Web e anthropic-ai. Google-Extended para Bard e AI Overviews. Applebot-Extended. CCBot para Common Crawl, que alimenta muitos modelos open-source. Cohere-AI. Meta-ExternalAgent. Bytespider, o crawler do TikTok, geralmente bloqueado porque é agressivo e a maioria dos projetos não quer que o TikTok pegue seu conteúdo.

O que você também precisa fazer

Robots.txt é necessário mas não suficiente. Três outras verificações. Cloudflare bot fight mode e bot management, desligar os que bloqueiam agentes de IA, ou colocá-los na whitelist por IP e user-agent. Vercel WAF e Edge Middleware, certificar-se de que não correspondem a user agents de IA em regex genérico. Plugins de segurança WordPress como Wordfence, frequentemente vêm com regras que bloqueiam GPTBot e PerplexityBot por padrão; colocar explicitamente na whitelist. Testar fazendo curl de cada user agent contra três URLs representativas e confirmando resposta 200.

Construímos fundações de SEO técnico alinhadas com o UK Government Digital Service Standard e o GOV.UK Design System. O GDS Service Standard é o conjunto mais rigorosamente documentado de princípios de qualidade para serviços digitais disponível publicamente: progressive enhancement, acessibilidade WCAG 2.2 AA, performance, HTML semântico e degradação graciosa quando o JavaScript falha. Seguimos isso em cada engajamento de SEO técnico da Seahawk.

Por que isso importa especificamente para SEO: sites alinhados com GDS passam Core Web Vitals consistentemente, rankeiam bem em buscas orgânicas clássicas e estão singularmente bem posicionados para citação em AI Overview porque a clareza estrutural que GDS exige é a mesma clareza estrutural que os extraction de busca por IA utilizam. O padrão precede a era de busca com IA, mas se mapeia perfeitamente para ela.

Para clientes de enterprise do UK, setor público e indústrias reguladas, o alinhamento GDS é um sinal real de procurement. Para todos os outros, é um marcador de qualidade que diferencia o trabalho de agências que entregam com um padrão inferior.

Três a dez semanas, três fases, preço fixo. Fase um é auditoria, crawl completo, revisão de GSC e Ahrefs, validação de JSON-LD, verificação de cluster de hreflang, pull de dados de campo de Core Web Vitals, baseline de citação de IA. Fase dois é remediação, entregamos as correções, seu time ou o nosso. Fase três é a camada de linter e monitoramento que previne regressões.

Os deliverables da fase de audit

• Crawl completo do Screaming Frog em CSV mais um brief escrito sobre os problemas que importam, rankeados por impacto.
• Exportação de Search Console, relatório de cobertura, queries, performance em nível de página, com anotações sobre o que é anômalo.
• Passa de schema validator sobre uma amostra de templates e uma nota escrita sobre cada tipo que está quebrado ou ausente.
• Relatório de integridade do cluster hreflang nas rotas traduzíveis.
• Extração de dados de campo do Core Web Vitals do CrUX com gráfico das últimas 25 semanas por métrica.
• Baseline de citação de AI Overview e Perplexity, share atual, análise de gaps contra três competidores nomeados.

A fase de remediação

Trabalho de escopo fixo. Cada ticket tem um estado inicial e um estado final bem definidos. A gente entrega na ordem de prioridade e você pode encerrar o contrato em qualquer marco se o orçamento acabar. O primeiro lote que a gente entrega é sempre os itens que falham no linter da build, eles têm o caminho mais curto para valor porque vão regredir sem parar sem o linter, e uma vez que o linter está em lugar, cada correção permanece.

A fase de monitoramento

Linting automatizado semanal em staging e produção, relatório mensal de Core Web Vitals, rastreamento mensal de citações de IA, e um canal Slack sempre ativo onde respondo a qualquer coisa que o Google ou seu time sinalizarem. Entregamos os dashboards no encerramento para que você mantenha visibilidade, renove ou não.