Next.js, WordPress e SEO: mudanças de setembro

As últimas semanas de setembro trouxeram mudanças importantes para quem trabalha com desenvolvimento front-end, WordPress headless, Next.js, SEO técnico e mensuração.

Entre os principais pontos estão novas correções de segurança no Next.js e no WordPress, a chegada de dados de pesquisa multimodal ao Google Search Console, novos filtros de hostname no GA4 e melhorias no Chrome DevTools para análise de aplicações com navegação client-side.

Para equipes que desenvolvem landing pages, sites institucionais e arquiteturas headless, algumas dessas mudanças exigem ação imediata.

Next.js recebe nova atualização de segurança

A equipe do Next.js publicou em 22 de setembro uma atualização de segurança fora do ciclo normal de releases.

As versões recomendadas passaram a ser:

Next.js 16.x → 16.3.6
Next.js 15.x → 15.5.26

A recomendação oficial é atualizar imediatamente.

Para projetos com Next.js 16:

npm install [email protected]
npm run build
npm ls next react react-dom

Em aplicações integradas ao WordPress por meio do WPGraphQL, a atualização deve ser acompanhada de testes nas áreas mais sensíveis.

Vale validar:

• consultas WPGraphQL;
• generateStaticParams;
• metadata;
• sitemap;
• imagens;
• rotas dinâmicas;
• formulários;
• build;
• deploy.

Mesmo projetos que utilizam exportação estática com:

output: "export"

não devem ignorar automaticamente a atualização.

Uma arquitetura estática pode reduzir determinados vetores de ataque, mas isso não significa que o projeto esteja fora do escopo de uma vulnerabilidade.

Outro patch de segurança já está previsto

Pouco depois da publicação do Next.js 16.3.6, a equipe anunciou outro pacote de segurança.

As versões previstas são:

Next.js 16.3.7
Next.js 15.5.27

O pacote deve corrigir nove vulnerabilidades, incluindo uma classificada como crítica.

Esse cenário reforça uma prática importante para manutenção de projetos Next.js.

Atualizações de segurança devem ser tratadas de maneira diferente das atualizações de funcionalidades.

Atualização de funcionalidade
→ staging, planejamento e validação

Atualização de segurança
→ prioridade de manutenção

Para sites de clientes, vale transformar a verificação de patches de segurança em uma rotina recorrente.

WordPress 7.1.2 corrige vulnerabilidade crítica

O WordPress lançou a versão 7.1.2 em 22 de setembro, poucos dias depois do 7.1.1.

A atualização corrige uma vulnerabilidade crítica relacionada à resolução de templates.

Em determinadas condições, um atacante não autenticado poderia fazer o WordPress incluir um arquivo PHP local legível fora dos diretórios do tema ativo.

Dependendo da configuração do servidor e do tema utilizado, o problema poderia resultar em execução remota de código.

A atualização pode ser feita pela interface administrativa ou via WP-CLI:

wp core update
wp core version

Depois da atualização, vale testar:

• login;
• CPTs;
• ACF;
• WPGraphQL;
• REST API;
• upload de mídia;
• taxonomias;
• build do front-end.

WordPress headless também precisa de manutenção constante

Em arquiteturas headless, o visitante pode acessar apenas o front-end em Next.js, mas o WordPress continua sendo uma parte crítica da aplicação.

O CMS segue responsável por:

• autenticação;
• permissões;
• uploads;
• plugins;
• REST API;
• GraphQL;
• armazenamento do conteúdo.

Por isso, esconder o WordPress em um subdomínio administrativo não elimina a necessidade de atualizar o Core e os plugins.

Search Console passa a mostrar pesquisas multimodais

Uma das mudanças mais interessantes para SEO veio do Google Search Console.

O Google passou a disponibilizar dados de pesquisas multimodais, realizadas a partir de imagens.

Essas pesquisas podem acontecer por recursos como:

• Google Lens;
• Circle to Search;
• upload de imagens no Google;
• Search this image no Chrome.

Os dados aparecem nos relatórios de performance e podem ser analisados separadamente.

No Search Console, procure pelo filtro:

Performance
→ Search type
→ Multimodal

A disponibilidade pode variar de acordo com o site e com a quantidade de tráfego desse tipo.

O SEO de imagens fica ainda mais importante

A pesquisa multimodal aumenta a importância das imagens dentro da estratégia de SEO.

Isso é especialmente relevante para sites de:

• móveis;
• arquitetura;
• hotelaria;
• imóveis;
• moda;
• automóveis;
• turismo;
• gastronomia;
• e-commerce.

Uma imagem pode se tornar o ponto inicial da busca.

Imagine um usuário apontando o Google Lens para uma cadeira e procurando modelos semelhantes.

Nesse cenário, a capacidade do Google de compreender aquela imagem passa a participar diretamente da descoberta do produto.

Para catálogos e páginas de produto, vale manter:

<img
  src="/cadeira-luna.webp"
  alt="Cadeira Luna estofada em tecido bege com estrutura de madeira"
/>

Também é melhor utilizar nomes descritivos de arquivo:

cadeira-luna-madeira.webp

em vez de:

IMG_58372.webp

O atributo alt, porém, não deve ser transformado em um campo de palavras-chave.

Sua função principal continua sendo acessibilidade.

Para compreender uma imagem, o Google também considera:

• contexto da página;
• títulos;
• textos próximos;
• nome do arquivo;
• dados estruturados;
• conteúdo visual.

GA4 ganha filtros de inclusão por hostname

O Google Analytics 4 passou a oferecer Hostname Include Filters.

O recurso permite declarar quais domínios estão autorizados a enviar dados para determinada propriedade.

Por exemplo:

site.com.br
www.site.com.br
lp.site.com.br

Isso pode ajudar a reduzir dados contaminados por:

• spam;
• cópias do código de tracking;
• implementações antigas;
• domínios desconhecidos;
• ambientes não autorizados.

Analise os hostnames antes de ativar o filtro

É importante não configurar a allowlist sem verificar os dados existentes.

Se a propriedade recebe tráfego legítimo de:

www.site.com.br
lp.site.com.br
checkout.site.com.br

e você incluir apenas:

site.com.br

parte dos eventos válidos pode ser descartada.

Antes de ativar o filtro, crie uma exploração no GA4 com:

Hostname
Sessions
Events
Key events

O objetivo é mapear todos os domínios legítimos antes de criar a lista de inclusão.

Chrome 154 traz melhorias para embeds responsivos

O Chrome 154 começou a adicionar suporte a dimensionamento de iframes baseado no conteúdo.

Hoje, embeds dinâmicos muitas vezes exigem uma solução baseada em:

iframe
→ medir conteúdo
→ postMessage
→ alterar height

Com a nova abordagem, torna-se possível trabalhar com algo como:

.embed {
  width: 100%;
  frame-sizing: content-height;
}

A novidade ainda não deve ser utilizada como única solução em produção.

O suporte entre navegadores precisa ser considerado, então o uso mais seguro é como progressive enhancement.

Chrome DevTools melhora testes em aplicações Next.js

O Chrome DevTools também passou a oferecer suporte mais completo para soft navigations.

Isso interessa especialmente a aplicações com:

• Next.js App Router;
• React;
• SPAs;
• roteamento client-side.

Em uma sequência como:

/catalogo
→ /catalogo/cadeira
→ /catalogo/mesa

o navegador pode trocar de rota sem realizar um carregamento completo da página.

Com o novo suporte, fica mais fácil analisar a performance dessas navegações internas.

Isso aproxima o diagnóstico técnico da experiência real do usuário.

O DevTools também ganhou melhorias na simulação de CPU, permitindo avaliar o comportamento da página em diferentes níveis de hardware.

Para landing pages e sites institucionais, vale testar:

• desktop rápido;
• mobile intermediário;
• mobile limitado.

Uma página rápida no computador do desenvolvedor pode apresentar uma experiência bem diferente em um smartphone intermediário.

WCAG 2.2 continua como referência de acessibilidade

Não houve mudança normativa que altere a referência atual de acessibilidade para produção.

A divisão continua sendo:

Produção → WCAG 2.2
Auditoria → WCAG-EM 2.0
Pesquisa → WCAG 3

A WCAG 3 ainda está em desenvolvimento e não deve substituir os critérios atuais.

Para landing pages e interfaces digitais, o foco deve continuar em:

• navegação por teclado;
• contraste;
• foco visível;
• labels;
• mensagens de erro;
• touch targets;
• headings;
• textos alternativos;
• reduced motion;
• modais;
• componentes interativos.

O que priorizar agora

Para equipes que trabalham com landing pages, WordPress e Next.js, a prioridade deve ser clara.

Primeiro, corrija vulnerabilidades de segurança.

Depois, aproveite os novos relatórios de Search Console e GA4 para melhorar mensuração e diagnóstico.

Por fim, incorpore as novas ferramentas do Chrome ao processo de QA e performance.

As principais ações são:

1. Atualizar Next.js 16 para 16.3.6.
2. Aplicar o próximo patch de segurança assim que disponível.
3. Atualizar WordPress para 7.1.2.
4. Validar ACF, CPTs, WPGraphQL, mídia e build após as atualizações.
5. Conferir o relatório de pesquisa multimodal no Search Console.
6. Revisar imagens de catálogos, portfólios e páginas de produto.
7. Mapear hostnames legítimos antes de ativar filtros no GA4.
8. Adicionar testes de soft navigation ao QA de projetos Next.js.
9. Manter WCAG 2.2 como referência de acessibilidade.

Conclusão

As mudanças mais relevantes deste período reforçam uma prioridade simples: segurança vem antes de otimização.

Novos relatórios de SEO, melhorias de mensuração e recursos do navegador são úteis, mas vulnerabilidades críticas em Next.js e WordPress precisam ser tratadas primeiro.

Depois disso, recursos como pesquisa multimodal, filtros do GA4 e novas ferramentas do Chrome ajudam a melhorar visibilidade, qualidade dos dados e experiência do usuário de forma mais consistente.