John Mueller (Google) Revela Qual Security Header Afeta o SEO

Última atualização em 26 de junho de 2026 às 14:34

John Mueller, do Google, confirmou em uma resposta no Reddit que, entre todos os headers de segurança, o X-Frame-Options (ou o equivalente moderno CSP: frame-ancestors) é o único que tem relação direta com SEO, porque impede que outros sites “roubem” seu conteúdo via iframe e ranqueiem no Google com ele. Os demais headers de segurança não afetam o ranqueamento diretamente, mas protegem o site contra hackeamento, XSS e vazamento de dados — e um site hackeado é um site que perde posição. Mais abaixo eu te mostro exatamente onde colar o código no .htaccess para corrigir isso, sem quebrar o cache do LiteSpeed.

Eu vi essa discussão circulando essa semana e resolvi parar tudo pra escrever sobre ela, porque toca em um ponto que muita gente que faz auditoria técnica de SEO — inclusive eu, com os blogs que administro — costumava deixar de lado: os headers de segurança.

A história começou com uma pergunta no Reddit, no subreddit r/TechSEO. Alguém estava montando uma auditoria de segurança completa para o próprio site e para clientes, e queria saber quais headers (CSP, X-Frame-Options, X-Content-Type-Options, Permissions-Policy) realmente importavam para SEO, além desses que já tinha mapeado.

John Mueller, que é Search Advocate da Google, respondeu de forma direta: na opinião dele, o único header de segurança que pode ter efeito sobre SEO é o que bloqueia o iframing por outros sites — seja pelo header clássico X-Frame-Options, seja pela diretiva mais nova frame-ancestors do Content-Security-Policy. Os demais, segundo ele, são “apenas” sobre segurança, sem relação direta com ranqueamento.

Eu concordo com o Mueller na parte técnica, mas, como alguém que vive de tráfego orgânico há 8 anos, eu discordo um pouco da forma como ele simplificou a resposta. Vou te explicar por quê — e, principalmente, vou te mostrar como resolver isso na prática, direto no .htaccess da sua hospedagem.

O que são os Security Headers, afinal?

Os headers de segurança são instruções que o seu servidor manda para o navegador de quem está acessando o site. É uma conversa que acontece “por baixo dos panos”, antes mesmo da página carregar visualmente, dizendo ao navegador como ele deve se comportar diante daquele conteúdo.

Eles existem para proteger contra os ataques mais comuns na web, como:

• Roubo de dados — informações sensíveis do usuário sendo capturadas por scripts maliciosos;
• Sequestro de sessão — alguém roubando o login de um usuário logado;
• Ataques man-in-the-middle — interceptação do tráfego entre o navegador e o servidor;
• Clickjacking — quando outro site “embute” o seu conteúdo dentro de um iframe disfarçado, fazendo o visitante interagir sem saber que está no seu site.

Esse último ponto é exatamente o que conecta segurança com SEO — e é o motivo de o Mueller ter citado o X-Frame-Options como exceção.

Veja, você pode gostar de ler também sobre: Spam Update do Google: Atualização Contra Spam em Junho de 2026 Focada em Manipulações por IA

Por que o X-Frame-Options importa tanto pra SEO

O header X-Frame-Options existe há quase vinte anos e continua extremamente relevante hoje. A função dele é simples: impedir que outros domínios carreguem o seu site dentro de um iframe.

Na prática, sem esse header, qualquer pessoa pode criar uma página em outro domínio, colocar seu blog dentro de um <iframe>, e exibir o seu conteúdo como se fosse parte do site dela. Isso abre a porta para um problema sério: sites concorrentes ou maliciosos conseguirem ranquear no Google usando o seu próprio conteúdo, sem nunca ter escrito uma linha sequer.

Ou seja, esse não é só um problema de segurança — é um problema direto de canibalização externa de tráfego. Alguém pode literalmente “vestir” o seu artigo com o domínio dele.

E os outros headers? Eles realmente não importam pra SEO?

Aqui que eu divirjo um pouco da resposta do Mueller. Tecnicamente, ele está certo: nenhum outro header de segurança é um fator de ranqueamento direto. Mas, na prática de quem cuida de blog todo santo dia, eu penso assim: tudo que evita que o seu site seja hackeado é, indiretamente, uma proteção de SEO.

Um site infectado por malware, redirecionando visitantes pra spam ou injetando scripts maliciosos, é um site que o Google pode marcar como inseguro, remover de resultados ou simplesmente fazer despencar de posição enquanto você limpa a bagunça. Eu já vi isso destruir meses de trabalho de SEO em poucos dias.

Por isso, na minha visão, uma auditoria técnica de SEO completa também deveria revisar headers de segurança — do mesmo jeito que revisamos plugins desatualizados do WordPress.

Os headers que eu considero essenciais

Strict-Transport-Security (HSTS) Força o navegador a sempre se conectar ao site via HTTPS, nunca via HTTP. Evita ataques de downgrade de conexão.

X-Content-Type-Options Com a diretiva nosniff, ajuda a evitar ataques de Cross-Site Scripting (XSS), impedindo que o navegador “adivinhe” o tipo de um arquivo de forma perigosa.

X-Frame-Options O que já te expliquei acima — bloqueia o uso do seu conteúdo em iframes de outros domínios.

Altamente recomendado

Content-Security-Policy (CSP) Restringe de quais fontes o navegador pode carregar scripts, imagens e outros recursos, reduzindo bastante o risco de XSS e injeção de dados. É também onde fica a diretiva moderna frame-ancestors, que substitui o X-Frame-Options em navegadores atuais.

Opcionais, mas úteis

Referrer-Policy Controla quanta informação de origem é compartilhada quando alguém clica em um link saindo do seu site. Também pode ser definido via HTML, com a tag <meta name="referrer" content="origin" />.

Permissions-Policy Restringe quais recursos do navegador (câmera, microfone, geolocalização etc.) um site pode usar. Vale lembrar que esse header ainda tem suporte limitado em alguns navegadores populares.

Quem cuida disso no WordPress?

Se você usa um construtor de sites fechado, como o Wix, esses headers normalmente já vêm configurados pela própria plataforma. Já no WordPress — que é o caso da imensa maioria dos blogs que eu vejo por aqui, inclusive os meus — isso geralmente depende de plugin ou de configuração manual no servidor.

Plugins como AIOSEO, W3 Total Cache, Really Simple Security e até o Redirection oferecem alguma função pra adicionar headers de segurança. Curiosamente, plugins de segurança populares como Sucuri e Wordfence não trazem essa função embutida, e plugins de SEO como Yoast e Rank Math também não cuidam disso.

Por isso eu prefiro resolver direto na fonte: no .htaccess da hospedagem. É mais leve, não depende de mais um plugin rodando no seu WordPress, e funciona mesmo se você trocar de plugin de SEO no futuro.

Veja, você pode gostar de ler também sobre: O Google Está Avaliando Seu Blog Para Agentes de IA

Como adicionar os Security Headers no .htaccess (passo a passo)

Agora vem a parte prática, que é o motivo de eu estar escrevendo esse artigo: onde exatamente colar esse código sem quebrar nada na hospedagem.

Se você usa LiteSpeed Cache (que, depois de testar bastante, é o que eu recomendo hoje pros meus alunos pra Core Web Vitals), o seu .htaccess tem um bloco gerado automaticamente pelo plugin, que normalmente termina com a linha # END NON_LSCACHE, seguido logo depois do bloco padrão # BEGIN WordPress.

É exatamente nesse espaço entre esses dois blocos que você deve inserir o código dos headers de segurança. Assim, você evita que uma futura atualização do LiteSpeed Cache ou do WordPress sobrescreva sua configuração sem querer.

Passo 1 — Faça backup do seu .htaccess

Antes de tocar em qualquer coisa, baixe uma cópia do arquivo atual pelo gerenciador de arquivos da sua hospedagem ou via FTP. Se algo sair errado, você volta em 10 segundos.

Passo 2 — Localize os blocos no arquivo

Abra o .htaccess (geralmente na raiz do seu site) e procure por essa estrutura:

apache

# BEGIN LSCACHE
...
# END NON_LSCACHE

# BEGIN WordPress
...
# END WordPress

Passo 3 — Cole o código entre os dois blocos

Insira exatamente isto entre # END NON_LSCACHE e # BEGIN WordPress:

apache

# BEGIN SECURITY HEADERS
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>
# END SECURITY HEADERS

Ficando assim, na ordem correta:

apache

# BEGIN LSCACHE
...
# END NON_LSCACHE

# BEGIN SECURITY HEADERS
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>
# END SECURITY HEADERS

# BEGIN WordPress
...
# END WordPress

Sobre o valor do X-Frame-Options

Eu usei SAMEORIGIN no exemplo, que permite que o próprio domínio use iframes do seu conteúdo (útil se você mesmo usa iframes internos, por exemplo, pra mapas ou players de vídeo), mas bloqueia qualquer outro domínio. Se o seu site não precisa de iframe nenhum, nem do próprio domínio, pode usar DENY no lugar de SAMEORIGIN pra um bloqueio total.

Passo 4 — Salve e limpe o cache

Depois de salvar o .htaccess, é fundamental limpar o cache do LiteSpeed (e qualquer cache de CDN, se você usa). Eu já vi configuração correta “não funcionar” simplesmente porque o cache antigo continuava sendo servido. Sempre teste em janela anônima depois de qualquer alteração de plugin ou de servidor — isso já me poupou várias dores de cabeça aqui nos meus projetos.

Passo 5 — Teste se os headers estão ativos

Depois de aplicar, eu recomendo testar o resultado em um verificador de headers de segurança, como o SecurityHeaders.com. Em poucos segundos ele te mostra exatamente quais headers o seu site está enviando e qual nota você tirou.

O que eu penso sobre isso na prática de quem vive de SEO

Eu sei que parece “coisa de desenvolvedor”, mas a verdade é que qualquer ajuste técnico que proteja o seu site também protege o seu investimento em conteúdo. Eu já passei por situação de blog hackeado, de injeção de script malicioso afetando velocidade de carregamento e até de queda de ranqueamento por conta disso. Esses cinco minutos editando o .htaccess valem muito mais do que parecem.

Veja, você pode gostar de ler também sobre: Google Search Console Terá Relatório de IA: Veja Como Funciona

E voltando ao ponto do Mueller: ele está certo tecnicamente, o X-Frame-Options é o único com efeito direto sobre SEO. Mas, na minha visão de quem cuida de blog no dia a dia, segurança e SEO técnico caminham juntos — um site fora do ar, hackeado ou redirecionando para spam não ranqueia, simples assim.

Quer aprender SEO técnico, AIO e tudo isso na prática?

Esse tipo de ajuste — junto com SEO técnico, AIO, criação e monetização de blog com Google AdSense, vendas como afiliado aqui no Brasil e também na gringa, e até criação de canal no YouTube pra gerar tráfego orgânico pro seu blog — é exatamente o que eu ensino, passo a passo, na Império dos Blogs.

São 7 cursos completos na minha formações, do zero ao avançado, pra quem quer construir um blog de verdade, que ranqueia, monetiza e te dá liberdade.

Clique aqui e conheça a Império dos Blogs

Perguntas frequentes sobre Security Headers e SEO

Kildary Oliver

Olá, sou especialista em criação de sites e blogs no WordPress, uma jornada que começou em 2018. Desde então, já ajudei milhares de pessoas a transformar suas ideias em projetos digitais de sucesso. Hoje, conto com mais de 27mil inscritos no meu canal no YouTube e mais de 10 mil alunos que confiam nos meus cursos online para alcançar seus objetivos.