HTTPS para SEO

TL;DR — HTTPS é a versão segura e criptografada do HTTP — o ícone de cadeado no navegador. O Google dá um pequeno empurrão de ranking às páginas HTTPS, mas os motivos reais para mudar são que o Chrome rotula sites HTTP simples como “Not Secure”, e HTTPS agora é simplesmente o que a web espera. A migração é segura se for feita corretamente: redirecione toda URL antiga http:// para sua versão https:// e não quebre nada no caminho.

O que é HTTPS

Quando você carrega um site, o navegador conversa com um servidor. Com o HTTP simples, essa conversa acontece às claras — qualquer pessoa na rede entre os dois (seu provedor, o Wi-Fi de uma cafeteria, um invasor) pode lê-la ou alterá-la. HTTPS é a mesma conversa, criptografada. O “S” significa “Secure”. Você obtém isso instalando um certificado TLS (as pessoas ainda o chamam de “certificado SSL”) no servidor.

Você pode ver se uma página usa HTTPS na barra de endereço: uma URL que começa com https:// e normalmente um ícone de cadeado. Uma página http:// simples no Chrome mostra o rótulo “Not Secure”.

HTTPS cobre apenas a conexão em si — não atesta o que está na página. O cadeado significa que os dados em trânsito estão criptografados; ele não diz nada sobre a confiabilidade do conteúdo do site, sobre a legitimidade de um formulário na página ou sobre a realidade do negócio por trás dele. Sites de phishing podem, e de fato conseguem, funcionar com certificados HTTPS válidos.

HTTPS ajuda no SEO?

Um pouco, historicamente. O Google confirmou em 2014 que usa HTTPS como sinal de ranking — mas é um sinal muito pequeno, e a própria equipe do Google o descreveu na época como um critério de desempate: se duas páginas forem iguais em todos os outros aspectos, a segura pode ficar à frente. Isso não vai elevar uma página fraca acima de uma página forte, e a orientação atual do Google não reafirma hoje um ganho direto de ranking por HTTPS. Quem promete grandes ganhos de ranking “só por adicionar SSL” está exagerando.

Os motivos que realmente importam:

• O Chrome diz “Not Secure”. Desde 2018, toda página HTTP recebe esse aviso. Isso afasta visitantes independentemente do que o Google pensa.
• Agora é o padrão básico. Estima-se que 9 em cada 10 sites já usem HTTPS (W3Techs, 2026). Ficar de fora parece um defeito.
• Recursos modernos precisam dele. Muitas capacidades do navegador (e conexões mais rápidas via HTTP/2) simplesmente não funcionam sem HTTPS.

A migração vai prejudicar meu ranking?

Não, se você fizer tudo com cuidado. Passar de HTTP para HTTPS é uma espécie de migração de site, e a regra de ouro é a mesma de qualquer migração: redirecione toda URL antiga para sua nova versão segura com um redirecionamento 301. Feito corretamente, você mantém seus rankings. Feito de qualquer jeito — com redirecionamentos ausentes e links quebrados para imagens e scripts — você pode perder tráfego. A mudança em si é segura; são os erros ao redor dela que causam dano.

Quer entender tudo — quanto o sinal realmente pesa, a migração passo a passo, conteúdo misto e HSTS? Mude para a aba Avançado.

TL;DR — A orientação atual do Google sobre experiência na página diz que aspectos além dos Core Web Vitals “don’t directly help your website rank higher” (tradução) «não ajudam diretamente seu site a obter uma posição melhor» — portanto, não prometa um ganho de ranking atual por causa do HTTPS. O que está confirmado é histórico: o Google anunciou HTTPS como um sinal de ranking “very lightweight” (tradução) «muito leve» em agosto de 2014 (menos de 1% das consultas), e Gary Illyes o caracterizou como um critério de desempate em 2015 — comentários datados, não um mecanismo atual documentado. Separadamente, a orientação de canonicalização do Google hoje prefere ativamente páginas HTTPS como canônicas em relação às equivalentes HTTP — mas apenas de forma condicional: um certificado inválido, dependências inseguras, um redirecionamento HTTPS→HTTP ou uma tag canonical HTTP perdida podem inverter essa preferência, e HSTS não consegue substituí-la. O caso real do HTTPS é o rótulo “Não seguro” (Not Secure) do Chrome, HTTP/2 (em todos os principais navegadores), APIs modernas do navegador e o fato de que ele agora é requisito básico — não uma alavanca de crescimento. Migrar é uma migração de site: faça 301 de cada URL (301s não perdem PageRank), corrija conteúdo misto, atualize canonicals/sitemaps/links internos e verifique novamente o Search Console — não existe ferramenta Change of Address para uma troca de protocolo. HSTS e seu redirecionamento interno 307 são uma proteção na camada do navegador, além dos seus 301 do servidor, e não um substituto para eles.

O Google promete atualmente um ganho de ranking por HTTPS?

Comece pelo que o Google diz hoje, não em 2014. A documentação atual sobre experiência na página declara que, além dos Core Web Vitals, os aspectos da experiência na página — entre os quais HTTPS está listado — “don’t directly help your website rank higher in search results.” (tradução) «não ajudam diretamente seu site a obter uma posição melhor nos resultados da pesquisa». Essa é a orientação direta e mais atual disponível, e ela não sustenta a promessa de um ganho de ranking no presente por estar em HTTPS.

O sinal de 2014 e o enquadramento de “critério de desempate” — histórico, não mecanismo atual

O que está confirmado é história: o Google anunciou HTTPS como sinal de ranking em 6 de agosto de 2014 e foi excepcionalmente franco sobre o pouco peso que ele tinha no lançamento. A formulação original: era um “very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (tradução) «um sinal muito leve, que afeta menos de 1% das consultas globais e tem menos peso que outros sinais, como conteúdo de alta qualidade». A publicação acrescentou que o Google “may decide to strengthen it” (tradução) «pode decidir fortalecê-lo» com o tempo para incentivar a adoção — “fortalecer”, não o “impulso” que a imprensa de SEO frequentemente parafraseou.

Um ano depois, em setembro de 2015, Gary Illyes caracterizou o sinal como um critério de desempate: “it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost.” (tradução) «funciona mais como critério de desempate. Por exemplo, se todos os sinais de qualidade forem iguais para dois resultados, aquele em HTTPS receberia … ou poderia receber … o impulso adicional». No mesmo ano, ele foi direto sobre as prioridades: “you should switch to HTTPS for users, not as a ranking signal.” (tradução) «você deve mudar para HTTPS pelos usuários, não como sinal de ranking». O enquadramento de John Mueller no mesmo período — não espere nenhuma mudança visível de ranking apenas pela troca — aponta na mesma direção.

Trate “critério de desempate” como uma observação datada e representativa de Illyes, de 2015–2016, não como algo que o Google documenta atualmente como mecanismo de ranking ativo — a formulação sobre experiência na página acima é a fonte mais conservadora no presente. Portanto, a resposta honesta e datada para “HTTPS ajuda no SEO?” é: o Google confirmou um sinal pequeno em 2014, um funcionário do Google o caracterizou como critério de desempate em 2015, e a orientação atual não reafirma diretamente esse mecanismo. Se você está escolhendo onde investir esforço, HTTPS é item de higiene, não alavanca de crescimento — independentemente do peso exato do sinal histórico hoje.

A preferência canônica do Google por HTTPS — condicional, não apenas baseada no esquema

Separada do sinal de ranking de 2014 está uma preferência de canonicalização que o Google documenta hoje: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as” (tradução) «o Google prefere páginas HTTPS às páginas HTTP equivalentes como canônicas, exceto quando há problemas ou sinais conflitantes, como» um certificado SSL inválido, dependências inseguras (exceto imagens), uma página HTTPS que redireciona usuários para ou através de uma página HTTP, ou uma página HTTPS com rel="canonical" apontando para a versão HTTP.

Essa é a nuance que quase todo outro guia ignora, e ela contraria uma simplificação comum (incluindo a frase de Illyes de 2016 de que o sinal de ranking está “basically looking at the first five characters in front of the URL” (tradução) «olhando basicamente para os cinco primeiros caracteres antes da URL») — essa abreviação descreve o sinal de ranking de 2014, não essa decisão de canonicalização. A própria orientação do Google é explícita: um certificado ruim ou um redirecionamento de downgrade substitui a preferência por HTTPS: “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (tradução) «Evite certificados TLS/SSL inválidos e redirecionamentos de HTTPS para HTTP, pois eles fazem o Google preferir HTTP com muita força». E HSTS não resolve isso: “Implementing HSTS cannot override this strong preference.” (tradução) «Implementar HSTS não pode superar essa forte preferência».

A consequência prática: um certificado expirado ou mal configurado não é apenas um problema de UX — ele também pode levar o Google a indexar sua página HTTP em vez da versão HTTPS que você quer ranquear. Para os tipos de falha de certificado e como diagnosticá-los, consulte Certificados SSL/TLS; para entender o relatório específico do Search Console sobre essa decisão, consulte o relatório de HTTPS.

Por que HTTPS realmente importa

Deixando de lado a questão do ranking, o caso a favor do HTTPS é incontestável — com uma ressalva que vale declarar de início: HTTPS protege o canal de transporte entre navegador e servidor. Ele não audita o código da aplicação, não atesta seus endpoints nem garante a intenção do usuário — um site HTTPS invadido, um formulário de phishing servido por HTTPS e uma violação de dados após a descriptografia continuam sendo possíveis. HTTPS é higiene necessária, não uma garantia de segurança para tudo que acontece depois da conexão.

Dado esse escopo, o caso prático:

• O aviso “Não seguro” (Not Secure) do Chrome. Desde o Chrome 68 (julho de 2018), o Chrome marca todas as páginas HTTP como “não seguras”. Esse rótulo aparece na barra de endereço diante de visitantes reais — um problema de conversão muito maior que qualquer pequeno empurrão de ranking.
• É o pré-requisito prático para HTTP/2 (e HTTP/3). Nenhum navegador principal oferece HTTP/2 por HTTP simples — todos os principais navegadores só o negociam sobre TLS, embora a especificação do HTTP/2 em si não exija criptografia. Como observa a documentação do Google, “in some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (tradução) «Em alguns casos, o TLS pode melhorar o desempenho, principalmente por viabilizar o HTTP/2». Esse “pode” é qualificado, não uma garantia — a sobrecarga do TLS, a configuração do servidor e o reuso da conexão ainda importam — mas a multiplexação e a compressão de cabeçalhos do HTTP/2 frequentemente tornam um site HTTPS+HTTP/2 mais rápido que HTTP/1.1 simples, o oposto da antiga preocupação de que “TLS adiciona latência”.
• Recursos modernos do navegador precisam dele. Service workers, APIs de geolocalização/câmera/microfone e aplicativos web progressivos geralmente exigem um contexto seguro (verifique o recurso e o navegador específico para exceções como localhost). Google: “HTTPS is required for many new browser features, especially those required for progressive web apps.” (tradução) «HTTPS é necessário para muitos recursos novos do navegador, especialmente os exigidos por aplicativos web progressivos».
• Dados de referência e “tráfego escuro” — por padrão, não universalmente. Navegadores que usam a política de referência padrão moderna (strict-origin-when-cross-origin) removem completamente o cabeçalho Referer quando um link vai de uma página HTTPS para um destino HTTP — uma navegação no mesmo esquema ou de upgrade ainda envia pelo menos a origem. Portanto, se você ainda usa HTTP, o tráfego que envia (e a atribuição de entrada) pode virar “direct” por padrão — mas o cabeçalho Referrer-Policy do próprio site pode substituir esse padrão em qualquer direção, então não trate isso como regra absoluta ao auditar a lacuna de analytics de outra pessoa.
• É requisito básico. Estima-se que ~89% dos sites usem HTTPS (W3Techs, 2026 — trate como uma estimativa direcional, não como contagem atual exata). A história de SEO não é o ganho da migração — é o risco de ser o caso visível que ficou para trás.

Migrando de HTTP → HTTPS

Uma mudança de HTTP→HTTPS é uma migração de site e merece a mesma disciplina. A boa notícia, diretamente da orientação do Google sobre mudança de site: “301 and other permanent redirects don’t cause a loss in PageRank.” (tradução) «301 e outros redirecionamentos permanentes não causam perda de PageRank». O antigo medo de que a mudança custaria equidade de links é um mito — o risco está inteiramente na execução, não na troca de protocolo: 301s ausentes, conteúdo misto, canonicals desatualizados e uma propriedade HTTPS não verificada no Search Console são o que realmente custa tráfego.

A disciplina central em um parágrafo: faça primeiro um benchmark do site HTTP ativo (crawling, rankings, exportação do Search Console, perfil de backlinks), obtenha um certificado TLS (um certificado DV gratuito da Let’s Encrypt transmite o mesmo sinal que um OV/EV pago), redirecione com 301 cada URL HTTP para sua equivalente HTTPS individualmente, torne HTTPS canônica em todos os lugares (links internos, sitemap, hreflang — não dependa de redirecionamentos para encobrir links internos desatualizados), corrija conteúdo misto antes da virada, verifique novamente as quatro propriedades do Search Console (não é necessária a ferramenta Change of Address para uma troca de protocolo) e mantenha os redirecionamentos ativos por pelo menos um ano. Espere uma oscilação temporária de ranking — uma queda que se recupera é a mudança se acomodando; uma queda persistente significa que algo quebrou.

Esse é o mapa de riscos, não o passo a passo. Para a sequência detalhada, o ensaio em staging, o mapeamento de redirecionamentos em escala, o plano de rollback e o checklist completo da migração, consulte Migração de HTTP para HTTPS — esta página permanece como uma visão geral concisa para não sair de sincronia com o guia mais aprofundado.

Conteúdo misto

Conteúdo misto ocorre quando uma página HTTPS carrega um subrecurso por HTTP. Há dois tipos, e a distinção define suas prioridades:

• Conteúdo misto ativo — scripts, folhas de estilo, iframes, XMLHttpRequest. Os navegadores bloqueiam isso de forma direta, porque um script adulterado pode reescrever a página inteira. É isso que realmente quebra seu site depois de uma migração, portanto corrija primeiro.
• Conteúdo misto passivo — imagens, áudio, vídeo. Os navegadores normalmente ainda o exibem, mas rebaixam o indicador de segurança e exibem um aviso.

Encontre-o rastreando o site HTTPS (Ahrefs Site Audit, Screaming Frog), observando o console do Chrome DevTools ou coletando relatórios de CSP. A correção proativa mais limpa é o cabeçalho Content-Security-Policy: upgrade-insecure-requests, que instrui o navegador a reescrever silenciosamente as solicitações de subrecursos http:// para https:// antes de fazê-las — uma rede de segurança útil durante e depois da migração. Observe que links âncora comuns para páginas HTTP não contam como conteúdo misto; eles apenas fazem uma navegação.

HSTS (e por que não substitui seus 301)

HSTS — segurança estrita de transporte HTTP (HTTP Strict Transport Security) — é um cabeçalho de resposta (Strict-Transport-Security) que diz aos navegadores para sempre usarem HTTPS no seu domínio, mesmo que o usuário digite ou clique em um link http://. Ele fecha o “problema da primeira requisição”: com apenas um 301 instalado, aquela primeira requisição de um novo visitante ainda sai por HTTP antes de o redirecionamento ser disparado, que é a janela desejada por um ataque de remoção de SSL (SSL stripping). Como dizem os documentos do Google, HSTS permite “avoid the cost of the 301 redirect” (tradução) «evitar o custo do redirecionamento 301» para visitantes recorrentes e “defeats attacks like SSL Stripping.” (tradução) «impede ataques como a remoção de SSL».

Duas coisas que SEOs devem manter separadas:

• HSTS não substitui seus 301 do servidor. Quando um navegador respeita HSTS, ele executa um redirecionamento 307 interno para HTTPS — mas isso acontece dentro do navegador, onde crawlers não o veem. Os mecanismos de busca ainda precisam do seu 301 real, no servidor, para entender a mudança e transportar a equidade de links. Você precisa dos dois.
• O preload de HSTS é quase permanente. Você pode enviar seu domínio à lista de preload incorporada aos navegadores (exigindo max-age de pelo menos um ano, includeSubDomains e preload), o que fecha a lacuna até para visitantes de primeira viagem. Mas sair da lista de preload é lento e doloroso. O Google alerta: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (tradução) «Não ative HSTS até ter certeza de que a operação do site é robusta o bastante para nunca implantar HTTPS com erros de validação do certificado». Trate o preload como uma porta de sentido único.

Mitos comuns

• “HTTPS dá um grande impulso atual de ranking.” Não — o sinal de 2014, “muito leve”, em menos de 1% das consultas, e o enquadramento de “critério de desempate” de 2015 são comentários datados; a orientação atual diz que aspectos da experiência na página além dos Core Web Vitals não ajudam diretamente a obter uma posição melhor.
• “A mudança vai derrubar meus rankings.” Não, se os redirecionamentos forem feitos corretamente; 301s não perdem PageRank. Migrações mal executadas causam dano, a troca de protocolo não.
• “Você precisa da ferramenta Change of Address.” Não para HTTP→HTTPS — apenas para mudanças de domínio.
• “Um certificado expirado só prejudica a UX, não o SEO.” Não — um certificado ruim é uma das condições nomeadas que podem inverter a preferência canônica do Google por HTTPS em favor da sua página HTTP, além de quebrar a página para usuários.
• “HTTPS só importa para páginas de checkout.” Não — o Chrome sinaliza todas as páginas HTTP, e as APIs modernas geralmente exigem um contexto seguro.
• “TLS deixa os sites mais lentos.” Na prática, geralmente ocorre o contrário, porque HTTPS libera HTTP/2 — embora TLS possa ajudar o desempenho, não o garanta.

A migração de HTTP→HTTPS faz parte da disciplina mais ampla de migrações de site — se você também estiver mudando de domínio ou plataforma, leia esse material primeiro, porque migrações empilhadas multiplicam o risco.

Resumo de IA

Uma síntese da versão Avançada:

• A orientação atual do Google não promete um ganho de ranking. O documento sobre experiência na página diz que aspectos além dos Core Web Vitals “don’t directly help your website rank higher” (tradução) «não ajudam diretamente seu site a obter uma posição melhor» — HTTPS está entre eles.
• O sinal de 2014 e o enquadramento de “critério de desempate” de 2015 são históricos. “Muito leve”, menos de 1% das consultas (2014); a frase de Illyes sobre critério de desempate (2015) — comentário datado, não um mecanismo atual reafirmado. Não trate HTTPS como uma alavanca de crescimento em hipótese alguma.
• A preferência canônica do Google por HTTPS é separada — e condicional. Atualmente, o Google prefere páginas HTTPS como canônicas, exceto quando há certificado inválido, dependências não seguras que não sejam imagens, redirecionamento HTTPS→HTTP ou tag canonical HTTP perdida — e HSTS não pode substituir isso. Um certificado ruim é risco de canonicalização, não apenas de UX.
• HTTPS protege apenas o transporte — não a lógica da aplicação, os endpoints ou a intenção do usuário; uma página de phishing pode funcionar com HTTPS válido.
• Os motivos reais para estar em HTTPS: o rótulo “Não seguro” do Chrome em todas as páginas HTTP (desde julho de 2018), HTTP/2 em todos os principais navegadores (frequentemente mais rápido que HTTP/1.1, embora TLS possa ajudar no desempenho sem garanti-lo), recursos do navegador e PWAs em contexto seguro, comportamento padrão (mas substituível) dos dados de referência e o fato de ser requisito básico para cerca de ~89% da web.
• Migração = migração de site, em visão geral aqui. Faça 301 de cada URL individualmente (301s não perdem PageRank), torne HTTPS canônico, atualize links internos/sitemaps/hreflang, corrija conteúdo misto, verifique novamente no GSC (HTTP e HTTPS são propriedades separadas), mantenha redirecionamentos por ≥1 ano e não use Change of Address para uma troca de protocolo — as etapas completas estão na página dedicada de migração.
• Conteúdo misto: o ativo (scripts/iframes) é bloqueado — corrija primeiro; o passivo (imagens) emite aviso. O CSP upgrade-insecure-requests é a rede proativa.
• HSTS fecha a lacuna da primeira requisição, mas usa um 307 somente no navegador que crawlers nunca veem — fica além dos 301 do servidor, não no lugar deles. Preload é quase permanente; não o faça às pressas.

Documentação oficial

Documentação de fontes primárias dos mecanismos de busca e das equipes de navegadores.

Google

• HTTPS como sinal de ranking (anúncio de 2014) — a publicação original sobre o “sinal muito leve”.
• Ative HTTPS nos seus servidores (web.dev) — certificados, 301s, canonicals, HSTS e cookies.
• Por que HTTPS importa (web.dev) — o caso de segurança e recursos do navegador.
• Corrigindo conteúdo misto (web.dev) — conteúdo misto ativo vs. passivo e upgrade-insecure-requests.
• Mudanças de site com alterações de URL — o manual de migração (redirecionamentos e ausência da ferramenta Change of Address para HTTPS).
• Entendendo a experiência na página — onde HTTPS se encaixa na experiência da página; fonte atual para “não espere um ganho direto de ranking”.
• Como especificar uma URL canônica — a preferência canônica HTTPS-vs.-HTTP atual e condicional, com as exceções (certificados ruins, dependências inseguras e redirecionamentos de downgrade) que a substituem.

Chrome / Chromium

• Rumo a uma web mais segura (2016) — o início da implementação do aviso “Não seguro”.
• Uma web segura veio para ficar (2018) — o Chrome 68 marcando todo HTTP como “não seguro”.

Bing / Microsoft

• Diretrizes para webmasters do Bing — diretrizes gerais; confirme a redação atual sobre HTTPS no navegador.

Citações da fonte

Declarações registradas do Google. Cada link é um deep link que salta para o trecho citado na página de origem.

Google — o anúncio do sinal de ranking de 2014

• “We’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (tradução) «Estamos começando a usar HTTPS como sinal de ranking. Por enquanto, é apenas um sinal muito leve, que afeta menos de 1% das consultas globais e tem menos peso que outros sinais, como conteúdo de alta qualidade.» — Zineb Ait Bahajji e Gary Illyes, Google. Ir para a citação
• “But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS.” (tradução) «Mas, com o tempo, podemos decidir fortalecê-lo, pois gostaríamos de incentivar todos os proprietários de sites a mudar de HTTP para HTTPS.» — a mesma publicação. Ir para a citação

Gary Illyes — enquadramento de critério de desempate

• “With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.” (tradução) «Com o impulso de ranking do HTTPS, ele funciona mais como critério de desempate. Por exemplo, se todos os sinais de qualidade forem iguais para dois resultados, aquele em HTTPS receberia … ou poderia receber … o impulso adicional necessário para superar o outro resultado.» — Gary Illyes, Google (via Search Engine Land). Leia a cobertura
• “You should switch to HTTPS for users, not as a ranking signal.” (tradução) «Você deve mudar para HTTPS pelos usuários, não como sinal de ranking.» — Gary Illyes, SMX East 2015 (via Search Engine Land). Leia a cobertura
• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (tradução) «Basicamente, olha os cinco primeiros caracteres antes da URL e, se for HTTPS … receberá um impulso mínimo.» — Gary Illyes, 2016 (via Search Engine Land). Leia a cobertura

Google — preferência canônica por HTTPS (orientação atual)

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following.” (tradução) «O Google prefere páginas HTTPS às páginas HTTP equivalentes como canônicas, exceto quando há problemas ou sinais conflitantes, como os seguintes.» — Google Search Central. Ir para a citação
• “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (tradução) «Evite certificados TLS/SSL inválidos e redirecionamentos de HTTPS para HTTP, pois eles fazem o Google preferir HTTP com muita força.» — Google Search Central. Ir para a citação
• “Implementing HSTS cannot override this strong preference.” (tradução) «Implementar HSTS não pode superar essa forte preferência.» — Google Search Central. Ir para a citação

Google — orientação sobre migração e HSTS

• “301 and other permanent redirects don’t cause a loss in PageRank.” (tradução) «301 e outros redirecionamentos permanentes não causam perda de PageRank.» — Google Search Central. Ir para a citação
• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (tradução) «Se você está mudando seu site de HTTP para HTTPS, não precisa usar a ferramenta Change of Address.» — Google Search Central. Ir para a citação
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (tradução) «Não ative HSTS até ter certeza de que a operação do site é robusta o bastante para nunca implantar HTTPS com erros de validação do certificado.» — web.dev (Google). Ir para a citação
• “In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (tradução) «Em alguns casos, o TLS pode melhorar o desempenho, principalmente por viabilizar o HTTP/2.» — web.dev (Google). Ir para a citação

Chrome — a implementação do aviso “Não seguro”

• “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (tradução) «A partir de julho de 2018, com o lançamento do Chrome 68, o Chrome marcará todos os sites HTTP como “não seguros”.» — Emily Schechter, Chrome Security (Chromium Blog). Ir para a citação

Checklist de migração HTTP → HTTPS

Uma versão condensada de pré-voo — para o checklist completo de execução, o ensaio em staging e o plano de rollback, consulte Migração de HTTP para HTTPS.

Antes

• Crawl completo do site HTTP ativo salvo (cada 200 + cada redirecionamento existente).
• Snapshot de rankings, exportação do Search Console e perfil de backlinks arquivados.
• Certificado TLS obtido e testado (um certificado DV gratuito é suficiente para o sinal).

A mudança

• Toda URL HTTP redireciona com 301, no servidor e individualmente, para sua equivalente HTTPS.
• Nenhuma cadeia de redirecionamentos (URL antiga → URL HTTPS final diretamente).
• Nenhum redirecionamento em massa para a homepage de URLs sem correspondência.
• Cada página faz referência a si mesma com rel="canonical" apontando para sua URL HTTPS.
• Links internos, sitemaps XML e hreflang atualizados para HTTPS (não deixados para os redirecionamentos).
• Conteúdo misto ativo (scripts, estilos, iframes) corrigido — eles são bloqueados.
• Conteúdo misto passivo (imagens, mídia) corrigido; CSP upgrade-insecure-requests configurado.

Search Console e depois

• Propriedade HTTPS verificada no GSC (ou uma propriedade de domínio cobrindo todas as variantes).
• Novo sitemap HTTPS enviado.
• Ferramenta Change of Address não usada (serve apenas para mudanças de domínio).
• Arquivo de disavow (se houver) revisado quanto a URLs HTTP.
• Redirecionamentos mantidos por pelo menos 1 ano — idealmente durante toda a vida do site.
• Indexação + Crawl Stats monitorados; uma queda que não se recupera = algo quebrou.

Os modelos mentais

1. HTTPS é higiene, não alavanca de crescimento. “Very lightweight”, menos de 1% das consultas, um critério de desempate. Invista o esforço de ranking em conteúdo e links; faça HTTPS porque a web exige, e siga em frente.

2. Separe o sinal de ranking de 2014 da preferência canônica atual. O sinal de ranking de 2014 é historicamente baseado no esquema — a frase de Illyes sobre os “first five characters” o descreve, e é um comentário datado, não um mecanismo atual documentado. A preferência canônica atual do Google por HTTPS é diferente e condicional: um certificado ruim, dependências inseguras ou um redirecionamento de downgrade podem fazer o Google voltar a indexar sua página HTTP. Portanto, um certificado quebrado não é apenas uma emergência de UX — também pode custar sua canonical HTTPS.

3. Uma migração é conduzida por 301s — todo o resto é sinal de apoio. Redirecionamentos (que não perdem PageRank) fazem o trabalho real de mover rankings. Canonicals, sitemaps, atualizações de links internos e a reverificação no GSC apenas ajudam o Google a processar a mudança de forma mais rápida e limpa.

4. Duas camadas de “forçar HTTPS”, e você precisa das duas. O 301 no servidor é para crawlers e equidade de links. HSTS (um 307 apenas no navegador) é para visitantes humanos recorrentes e proteção contra SSL stripping. Eles resolvem problemas diferentes — HSTS nunca substitui o 301.

5. Conteúdo misto: faça a triagem pelo que o navegador faz. O conteúdo ativo (scripts/estilos/iframes) é bloqueado → corrigi-lo é uma questão funcional, faça isso primeiro. O conteúdo passivo (imagens/mídia) apenas emite um aviso → corrija depois. upgrade-insecure-requests é a rede de segurança para o que você deixar passar.

HTTPS para SEO — resumo rápido

A realidade do ranking

Fatos sobre redirecionamentos e migração

Conteúdo misto e HSTS

Forçar HTTPS e configurar HSTS

Exemplos para as duas stacks mais comuns. Teste primeiro em staging — um cabeçalho HSTS é persistente, e um loop de redirecionamento malfeito bloqueia o acesso das pessoas.

Apache (.htaccess)

# 301 every HTTP request to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# HSTS — only add once you're confident HTTPS is solid
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# On the HTTPS server block, add HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Adicione ; preload ao cabeçalho HSTS somente quando pretender enviá-lo para hstspreload.org — é algo quase irreversível.

Encontre conteúdo misto pela linha de comando

Rastreie suas páginas HTTPS e faça grep por quaisquer subrecursos http:// que ainda tenham ficado no HTML.

macOS / Linux

# Pull a page and flag insecure script/img/link/iframe sources
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

# Same idea in PowerShell
(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Para uma varredura do site inteiro, um crawler (Ahrefs Site Audit, Screaming Frog) ou o console do Chrome DevTools é mais rápido que executar scripts página por página.

Recursos que valem seu tempo

Minha palestra

• Melhor prevenir do que remediar com HTTPS — SMX East 2016 (SlideShare) — meu aprofundamento sobre TLS, falhas comuns de implementação do HTTPS e armadilhas da migração. (O aviso padrão se aplica: esta é minha compreensão desses sistemas, e as estatísticas de adoção nela são de 2016.)

Minha publicação relacionada

• Guia para iniciantes em SEO técnico — onde HTTPS se encaixa no panorama mais amplo.

De outras fontes (oficiais)

• O Ative HTTPS nos seus servidores e o Corrigindo conteúdo misto, do Google — o conjunto concentrado de documentos de implementação mais útil.
• hstspreload.org — verifique a elegibilidade antes de se comprometer com o preload.
• SSL Labs Server Test — avalie sua configuração de TLS.

Da indústria

• HTTPS como fator de ranking — Search Engine Journal — análise do SEJ sobre o sinal, seu peso real e por que ele continua sendo um critério de desempate, não uma alavanca.
• Gary Illyes, do Google: HTTPS pode desempatar dois resultados de busca equivalentes (Search Engine Land) — a cobertura original do enquadramento de “critério de desempate” de Illyes.
• Google começa a dar impulso de ranking a sites HTTPS/SSL seguros (Search Engine Land) — a cobertura do anúncio de 2014 e a reação inicial da indústria.
• HSTS — o que é e como usá-lo (Kinsta) — guia prático de implementação que aborda os riscos da lista de preload e os avisos de bloqueio.
• Let’s Encrypt — autoridade certificadora DV gratuita e automatizada, amplamente usada quando você precisa apenas do esquema https:// sem pagar por OV/EV.
• HTTPS é fácil (Troy Hunt) — série curta de vídeos que desmistifica a configuração do TLS para quem está começando.

Estatísticas que vale citar

• HTTPS é “um sinal muito leve, que afeta menos de 1% das consultas globais”. O próprio enquadramento do Google sobre o peso do ranking no lançamento de 2014 — um número histórico, ainda a melhor referência para ajustar expectativas, mas não uma reafirmação dos mecanismos atuais. Fonte
• Todas as páginas HTTP são marcadas como “não seguras” desde o Chrome 68 (julho de 2018). O motivo prático mais visível para mudar. Fonte
• ~89% dos sites agora usam HTTPS. É requisito básico — o risco de SEO é ser o caso que ficou para trás, não o ganho da migração (W3Techs, 2026; confirme a cifra atual).
• Redirecionamentos 301 não perdem PageRank. A declaração direta do Google, que elimina o mito de que mudar custa equidade de links. Fonte

Teste seus conhecimentos: HTTPS para SEO

Cinco perguntas rápidas sobre HTTPS para SEO. Escolha uma resposta para cada uma e depois confira.

Registro de alterações