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 search engines e AI assistants conseguem fazer crawl, renderizar e confiar em suas páginas — antes que conteúdo ou backlinks tenham qualquer efeito. Cobre comportamento HTTP, semântica HTML, structured data, hreflang, canonicalização, Core Web Vitals e renderização JavaScript. Faça errado e o resto do seu investimento é peso morto.

Em 2026 a definição se expandiu. Duas mudanças provocaram isso. Primeira, AI Overviews e ChatGPT-powered search agora ficam entre a maioria dos usuários e as páginas subjacentes, o que significa que citation-readiness importa tanto quanto ranking. Segunda, o site modal não é mais uma instalação WordPress — é alguma variação 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 failure modes de 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 crawl do Search Console, uma verificação de citação em AI Overview e um schema validator 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 framework front-end é responsável pela renderização e seu CMS é responsável pelo conteúdo — e o SEO pode cair na lacuna entre os dois. O modelo clássico WordPress + Yoast assumia um servidor, um renderizador, um mecanismo de regras. Extrair conteúdo do WordPress para Next.js ou Astro significa não herdar 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 páginas, 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 plugins, Core Web Vitals são fáceis de manter verdes, e editores mantêm um admin familiar. Os riscos também são reais. Canônicas Yoast e meta descriptions precisam ser transportadas além da API; redirecionamentos definidos no WordPress precisam cair em vercel.json ou Netlify _redirects; sitemaps geralmente precisam ser regenerados no build front-end, não no lado WordPress; e verificação do search console precisa acontecer na origem pública, não no domínio wp-admin.

Stacks modernos puros

Um build Next.js + Sanity, um build Astro + Storyblok, um build Nuxt + Strapi, um build Next.js + Payload — todos pulam WordPress inteiramente. O trabalho de SEO técnico muda para garantir que seu schema de CMS modele os campos SEO que o front-end precisa (canonical override, redirect map, hreflang group, schema-extension JSON), e garantir que revalidação sob demanda dispare quando o conteúdo muda. Envenenamento de cache ISR é o assassino silencioso — uma página é servida desatualizada por horas após publicação porque revalidatePath nunca foi conectado.

O que realmente quebra primeiro

Em cerca de 200 auditorias headless que rodamos, o problema único mais comum que quebra produção é conflito canônico — o front-end emitindo uma URL canônica enquanto os metadados do CMS ou sitemap emitem outra. Google escolhe uma, quase sempre não a que você queria, e a URL errada acaba no índice. Pegamos isso com um linter em tempo de build que compara canonical-emitted-from-template contra canonical-stored-in-CMS para uma amostra de páginas e falha o build em caso de incompatibilidade.

WordPress oferece a mais potência de plugins e as mais maneiras de se atirar. O playbook de SEO técnico em um site WordPress clássico é principalmente sobre subtração — remover canônicas duplicadas, matar conflitos de schema entre Yoast e RankMath e um terceiro plugin que ninguém se lembra de ter instalado, dominar page builders que enviam 2 MB de CSS, e limpar 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 o meta clamping precisa ser construído. Não há schema de plugin, então JSON-LD precisa ser templado. Não há sitemap integrado, então ele precisa ser gerado e transmitido. O volume de código que adicionamos a um projeto headless para SEO costuma ser três a cinco vezes o que um site WordPress já oferece de graça — mas esse código é próprio, 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 uma passagem da sua página e a exibem como a resposta. GEO (Generative Engine Optimisation) é o termo mais novo — otimizar para AI Overviews, pesquisa ChatGPT, 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: uma passagem pronta para citação. As regras estruturais que vencem em todos eles 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 cabeçalho. Mantenha essa resposta com menos de 250 palavras. Certifique-se de que a resposta é renderizada no servidor, não dentro de um componente JavaScript que é hidratado após o carregamento da página. Rastreadores de IA e extractors do Google geralmente não executam JavaScript — se sua resposta precisa de JS para aparecer, você é invisível.

Onde GEO diverge de AEO

Três coisas importam mais especificamente para GEO. Autoridade de entidade — Google e os LLMs constroem um gráfico de quem pode falar sobre o quê, e menções de marca não vinculadas o alimentam. Schema com arrays about e mentions — eles tornam sua página analisável como parte de um gráfico de entidade em vez de um bloco de texto. E llms.txt — um arquivo padrão emergente 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. Implantamos llms.txt em todos os sites que construímos e atualizamos sempre que uma página importante é 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 gráfico único em todo o site em 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 busca de sitelinks se você tiver busca no site.
• BreadcrumbList — em toda página que não seja a inicial, com URLs corretas para locale (uma página em francês deve apontar para ancestrais /fr/, não /en/).
• Article ou BlogPosting — em conteúdo longo, com arrays about e mentions para reforço do grafo de entidades.
• Service — em páginas comerciais, com serviceType, provider, areaServed, audience, e offers.priceSpecification quando você conseguir publicar uma faixa de preço.
• Product — em ecommerce, com offers.priceCurrency, availability, e aggregateRating apenas se você tiver reviews reais.
• FAQPage — quando há pelo menos duas perguntas genuínas na página. Inventar FAQs para ganhar 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 toda linha traduzível. Cada variante locale de uma página compartilha um ID. O emissor de hreflang, o emissor de sitemap e o emissor de canonical derivam seu cluster desse ID. Nunca calcule hreflang apenas do matching de padrão de URL — ele desaba em casos extremos (uma página em espanhol que não tem tradução para hindi quebra o cluster se seu código assume "se pageX existe na locale A, existe na locale B").

O que mata hreflang na prática

Três padrões que vemos repetidamente. Ordenação de regex de locale — colocar "zh" antes de "zh-Hant" em seu regex de detecção de locale, que captura a locale errada e escreve um hreflang quebrado. Esquecer x-default — todo 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 é gerar 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 long-tail em uma escala que conteúdo de um único autor não consegue alcançar. 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 — toda URL tem pelo menos um fato, número ou detalhe único para 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 mantidas em estado de rascunho até que a camada de dados seja preenchida.

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.

Levamos esse playbook operacional para builds programáticos de clientes — front-end em Next.js ou Astro, dados em Supabase ou Postgres, um pipeline de ingestão que pontua páginas em originalidade antes da publicação, um sitemap que faz stream em chunks porque mais de 50 mil URLs não cabem em um único sitemap.xml, e um grafo de link interno que puxa cada página folha para 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 herói e quase sempre resolvido por re-codificar para WebP em 80% de qualidade, dimensionar para as dimensões reais de exibição mais 2x retina, adicionar uma tag preload na head e definir fetchpriority="high". Uma imagem herói de 1 MB virada um WebP de 30 KB é a mudança de maior impacto em maioria dos projetos. CLS vem de imagens e anúncios sem dimensões explícitas — atributos de width e height explícitos em toda imagem, slots de anúncio com altura fixa e espaço reservado para qualquer widget renderizado no cliente. INP vem de JavaScript pesado em interação — geralmente um gerenciador de tags de terceiros ou uma biblioteca de analytics superaguçada. A solução é debounce, lazy-loading ou substituir 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 depois que o JS roda, e seu LCP é o skeleton de carregamento do carousel, não a foto. Segundo, web fonts carregadas sem font-display: swap e sem preload — o texto fica invisível por 200-400 ms enquanto as fonts baixam, e seu LCP é empurrado para além do limiar de 2.5 s mesmo que a imagem seja rápida. Ambos são capturados por uma revisão de dados de campo do CrUX, não por um único Lighthouse run.

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 hardcoded, palavras genéricas de copywriting proibidas.
• 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 roda como a última etapa do npm run build. Qualquer violação falha o build, o que falha o deploy. Sem ele, toda regressão — uma meta descrição 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 — entra silenciosamente. 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 da entidade — presença no Wikipedia, schema de organização consistente, contas sameAs reais, menções de marca em toda a web aberta.
• llms.txt na raiz do site — um mapa curatorial do site para ferramentas de IA, separado do robots.txt e sitemap.xml que servem crawlers tradicionais.
• Schema com about e mentions em conteúdo long-form — declara o grafo de entidade dentro do qual a página se situa.
• Allow-list de robots.txt para crawlers de IA — permita explicitamente GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot e Anthropic-AI. Bloquear nem que seja um desses é uma interrupção de citação auto-infligida.
• Propriedade de schema speakable nas seções ricas em respostas de páginas long-form — uma dica para extractores de voz e IA de que essa é 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 de código aberto. Cohere-AI. Meta-ExternalAgent. Bytespider — rastreador do TikTok — geralmente bloqueado porque é agressivo e a maioria dos projetos não quer que o TikTok copie seu conteúdo.

O que você também precisa fazer

Robots.txt é necessário mas não suficiente. Três outras verificações. Modo bot fight do Cloudflare e gerenciamento de bots — desative os que bloqueiam agentes de IA, ou coloque-os na lista de permissão por IP e user-agent. WAF do Vercel e Edge Middleware — verifique se não correspondem a user agents de IA em uma regex genérica. Plugins de segurança do WordPress como Wordfence — frequentemente vêm com regras que bloqueiam GPTBot e PerplexityBot por padrão; coloque na lista de permissão explicitamente. Teste fazendo curl em cada user agent contra três URLs representativas e confirme uma 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.Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

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. A fase um é audit — crawl completo, revisão de GSC e Ahrefs, validação JSON-LD, verificação de cluster hreflang, pull de dados de campo Core Web Vitals, baseline de citação em IA. A fase dois é remediação — entregamos os fixes, seu time ou o nosso. A 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.
• Export do Search Console — relatório de cobertura, queries, performance por 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.
• AI Overview e baseline de citações do Perplexity — share atual, análise de gap contra três concorrentes nomeados.

A fase de remediação

Trabalho de escopo fixo. Cada ticket tem um estado anterior e um estado posterior bem definidos. Entregamos na ordem de prioridade e você pode encerrar o engagement em qualquer milestone se o orçamento se esgotar. O primeiro lote que entregamos é sempre os itens que falham no linter de build — têm o caminho mais curto para valor porque vão regredir sem o linter, e uma vez que o linter está em operação, cada correção fica permanente.

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.