O HTTPS protege a comunicação entre seu navegador e o servidor de ser interceptada e adulterada por invasores. Isso fornece confidencialidade, integridade e autenticação para a grande maioria do tráfego WWW atual.
Qualquer site que mostre um ícone de cadeado na barra de endereço está usando HTTPS.
Neste artigo, você aprenderá:
- Noções básicas de HTTP e HTTPS
- Como funcionam os certificados TLS
- Como o HTTPS ajuda o SEO
- Como configurar o HTTPS
- Como verificar possíveis erros de migração de HTTPS
Primeiro, deixe-me simplificar e ilustrar a comunicação entre o cliente (navegador) e o servidor quando há um invasor entre eles.
Como você pode ver, os invasores podem se apossar de dados confidenciais, como login e detalhes de pagamento, ou injetar código malicioso nos recursos solicitados.
Ataques de rede em potencial podem acontecer em qualquer lugar com um roteador ou ISP não confiável. Qualquer rede Wi-Fi pública é, portanto, vulnerável a esses ataques. Felizmente, parece que o público em geral está se conscientizando desse fato (aumento do uso de VPNs).
No entanto, o ônus de tornar a experiência de navegação de todos segura é e deve ser dos webmasters.
É aí que entra a adoção do HTTPS.
O HTTPS criptografa solicitações e respostas HTTP para que um invasor interceptador veja apenas caracteres aleatórios em vez de detalhes do cartão de crédito, por exemplo.
Uma analogia de como o HTTPS funciona seria enviar objetos de valor em uma caixa de combinação trancada indestrutível. Somente as partes remetente e receptora conhecem a combinação e, se os invasores se apoderarem dela, não entrarão.
Agora, muitas coisas acontecem quando uma conexão HTTPS é formada. Principalmente, o HTTPS depende da criptografia TLS (Transfer Layer Security) para proteger as conexões.
A única maneira de habilitar o HTTPS em seu site é obter um certificado TLS e instalá-lo em seu servidor. Você também o encontrará como um certificado SSL ou SSL/TLS, mas não se preocupe, é tudo a mesma coisa. SSL ainda é uma terminologia amplamente usada, embora todos nós tecnicamente usemos seu sucessor TLS.
Os certificados TLS são emitidos por Autoridades Certificadoras (CA). A função da CA é ser um terceiro confiável no relacionamento cliente-servidor. Basicamente, qualquer pessoa pode emitir certificados TLS, mas apenas as CAs publicamente confiáveis são suportadas pelos navegadores.
Você pode verificar o certificado TLS de cada site e sua CA emissora clicando no ícone de cadeado na barra de endereços do navegador.
Você pode clicar no certificado para saber mais. O importante aqui é a linha “Issued to:”. É quando entramos em diferentes tipos de padrões de validação para certificados TLS, que é o que diferencia principalmente os certificados gratuitos dos pagos.
DV, OV e EV: O que significa e qual escolher?
Os certificados TLS gratuitos que acompanham seus planos de hospedagem e CDN fazem apenas a validação de domínio (DV). Isso valida que um proprietário de certificado controla um determinado nome de domínio. Essa técnica de validação básica é boa o suficiente para blogs e sites que não lidam com informações confidenciais, mas não é ideal para aqueles que o fazem.
Os sites que usam um certificado DV TLS parecem seguros, mas você não verá a linha “Emitido para:” ao clicar no ícone de cadeado.
O certificado DV TLS mais comum vem de uma CA sem fins lucrativos chamada Let’s Encrypt . Isso é o que a maioria das empresas que oferecem certificados TLS gratuitos automaticamente renováveis usam.
Não há nada de errado com certificados somente DV, afinal é o único tipo de certificado TLS que pode ser emitido automaticamente em escala. No entanto, o HTTPS é tão forte quanto o certificado subjacente que autentica o servidor com o qual você está falando.
Se o seu site permitir logins ou pagamentos, você deve investir em um certificado TLS que ofereça validação da organização (OV) ou validação estendida (EV). Esses dois tipos diferem no processo de verificação, sendo o EV mais rigoroso.
Se você deseja comprar apenas um, recomendo ir direto para o certificado EV TLS. É o mais confiável e não custa muito mais do que OV.
Certificados curinga e SAN TLS
Deixando os padrões de validação para trás, vamos para outra categoria de certificados TLS.
Os certificados curinga e SAN são usados para proteger vários (sub)domínios de uma só vez. Se você comprou um certificado EV TLS padrão para example.com, precisará de um certificado separado para blog.example.com.
Os certificados curinga podem proteger subdomínios ilimitados (example.com, blog.example.com, docs.example.com), enquanto os certificados SAN também têm a opção de proteger outros domínios (example.com, blog.example.com, different.org ).
Esses tipos são combinados com os tipos de validação, então você verá todos os tipos de combinações ao navegar pelas opções que as CAs oferecem. Eles também irão guiá-lo através do processo de validação.
Praticamente todos os benefícios do HTTPS estão relacionados ao SEO:
- Sinal de classificação leve
- Melhor segurança e privacidade
- Preserva os dados de referência
- Permite o uso de protocolos modernos que aumentam a segurança e a velocidade do site
Sinal de classificação leve
O Google anunciou que o HTTPS é um fator de classificação leve em 2014. É mais como um desempate do que algo que dispararia sua classificação se outras variáveis do fator de classificação permanecessem inalteradas.
Esta é basicamente a contribuição do Google para uma adoção mais rápida do HTTPS em todo o mundo.
Melhor segurança e privacidade
Já falamos sobre este. Mas como isso está conectado ao SEO?
Ao acessar um site não seguro, você verá algo assim:
Isso realmente não constrói confiança, certo? Estou ciente do meu viés profissional, mas pessoalmente presto atenção a isso e rapidamente fico com uma má primeira impressão se vejo isso em qualquer site.
Meu palpite é que a migração para HTTPS pode melhorar o tempo de permanência e evitar o pula-pula. Embora esses sejam apenas fatores de classificação teorizados (não confirmados), fazer com que as pessoas ‘fiquem’ quando acessam seu site é algo que você deseja, independentemente do SEO.
Preserva os dados de referência
Se seu site ainda estiver em HTTP e você estiver usando serviços de análise da web como o Google Analytics, tenho más notícias para você: nenhum dado de referência é transmitido de páginas HTTPS para HTTP.
Como a maior parte da web é executada em HTTPS atualmente, a origem da maior parte do tráfego de referência (cliques em links de outros sites) será rotulada como direta na maioria dos softwares de análise.
Uma desvantagem disso é que torna seus dados confusos e distorcidos. Outra é que você não consegue ver suas melhores fontes de referência, o que é uma oportunidade desperdiçada de criação de links .
Se você estiver interessado nos erros comuns de rastreamento do Google Analytics, verifique esta postagem .
Permite o uso de protocolos modernos que aumentam a segurança e a velocidade do site
No papel, o HTTPS é mais lento que o HTTP devido aos recursos de segurança adicionados. No entanto, ter HTTPS é o pré-requisito para usar a mais recente tecnologia de segurança e desempenho da Web.
Em outras palavras, além da segurança, o HTTPS também permite que seu site melhore a velocidade da página ao usar protocolos como TLS 1.3 e HTTP/2 . E além de uma melhor experiência do usuário, o Google considera a velocidade da página como um fator de classificação leve semelhante ao HTTPS:
Isso depende do seu cenário.
1. Você está lançando um novo site
Você ganhou na loteria. Vá com HTTPS desde o início e você nunca terá que se preocupar com HTTP e erros associados à migração .
Tudo o que você precisa fazer é ter um bom provedor de hospedagem que o guie pelo processo e que suporte as versões mais recentes dos protocolos HTTP e TLS. Depois que tudo estiver funcionando, implemente o HSTS como a última etapa para selar a segurança.
2. Você já tem um site habilitado para HTTPS
O fato de você estar lendo este artigo me diz que provavelmente não está configurado corretamente. Siga os conselhos da próxima seção para verificar erros comuns.
3. Você ainda tem um site rodando em HTTP
Vai demorar um pouco para preparar tudo e fazer. A complexidade da migração depende de:
- O tamanho e a complexidade do seu site
- Que tipo de CMS você usa
- Seus provedores de hospedagem/CDN
- Suas habilidades técnicas
Embora eu acredite que os proprietários de pequenos sites executados em CMS populares e hospedagem sólida possam fazer a migração por conta própria, há muitas variáveis em jogo.
Sugiro que você verifique a documentação do seu CMS/servidor/hospedagem/CDN e proceda de acordo – e com cuidado. Existem muitas etapas que você precisa executar, então crie ou siga uma lista de verificação de migração e não tente se encaixar em outras atividades.
Se tudo isso soa muito técnico para você, contrate um profissional. Isso economizará horas do seu tempo, poupará seus nervos e garantirá uma implementação à prova de futuro.
Mesmo que você marque toda a lista de verificação de migração de HTTPS, é provável que ainda encontre alguns problemas.
Na verdade, em 2016, analisamos 10.000 domínios de alto escalão para vários erros de HTTPS e descobrimos o seguinte:
- 90,9% dos domínios tiveram implementação de HTTPS abaixo do ideal
- HTTPS não estava funcionando corretamente em 65,39% dos domínios
- 23,01% dos domínios estavam usando redirecionamentos 302 temporários em vez de 301s permanentes
Embora muita coisa tenha mudado e melhorado desde então, recomendo que você verifique os cinco erros comuns de migração de HTTPS abaixo. Não vai demorar muito, e a maioria deles não é tão difícil de consertar.
Erro 1: páginas HTTP restantes
Em primeiro lugar, você precisa garantir que todas as páginas do seu site já estejam em HTTPS.
Você pode descobrir páginas HTTP restantes rastreando completamente o site. Isso não deve ser novidade se você seguir qualquer lista de verificação de migração HTTPS. Apenas certifique-se de que o rastreador tenha todas as fontes de URL necessárias para não deixar as páginas para trás.
Para fazer isso, você pode usar o Ahrefs Webmaster Tools gratuitamente com a seguinte configuração:
Feito isso, abra o último crawl, vá até o Page Explorer e aplique o seguinte filtro:
Exporte a lista de URLs HTTP e redirecione-os para concluir a migração.
As páginas que não estão no mapa do site e não têm links apontando para elas são impossíveis de serem descobertas pelo rastreamento. Isso geralmente pode acontecer com páginas de destino PPC dedicadas. Uma maneira de encontrá-los é exportar a lista de URLs de seus gerenciadores de anúncios, como Google Ads ou FB Business Manager.
A partir daí, verifique se as páginas órfãs foram migradas corretamente. E não se esqueça de atualizá-los em seus painéis de campanha para o formato HTTPS mais recente.
Erro 2: páginas HTTPS com conteúdo HTTP
Este erro ocorre quando o arquivo HTML inicial é carregado usando HTTPS, mas seus arquivos de recursos (imagens, CSS, JavaScript) ainda não foram atualizados para HTTPS.
Se esse for um problema em seu site, você o verá na visão geral do rastreamento e no relatório de páginas internas. Todos os erros, avisos e avisos nas ferramentas gratuitas do Ahrefs para webmasters contêm uma descrição do problema e conselhos sobre como corrigi-lo.
Erro 3: links internos não atualizados para HTTPS
Não atualizar seus links internos para HTTPS causa redirecionamentos desnecessários. Obviamente, isso é melhor do que acessar uma página HTTP, mas já passamos por esse erro. É fácil identificar esses links e corrigi-los.
Você encontrará esse problema no relatório de Links na Auditoria do site nas Ferramentas do Google para webmasters do Ahrefs:
Basta reescrever os URLs para https:// e pronto. Isso só é aplicável se você já se certificou de que nenhuma página HTTP foi deixada usando o aviso do erro nº 1.
Erro 4: tags não atualizadas para HTTPS
Existem dois tipos de tags que você pode usar em seu site que também precisam atualizar seus URLs para HTTPS: tags canônicas e tags Open Graph.
As tags canônicas informam ao Google o que você considera a página mais confiável de várias páginas semelhantes ou duplicadas. Apontar isso para uma versão HTTP pode definitivamente enviar um sinal ruim para o Google e provavelmente será ignorado.
Se você usar tags do Open Graph para otimizar suas postagens de mídia social, as tags de URL serão exigidas pelo Facebook. Eles devem ser iguais aos URLs canônicos.
Para encontrar páginas com tags HTTP canônicas e OG, configure este filtro personalizado no Page Explorer:
Novamente, tudo o que resta é reescrevê-los para https:// dada uma migração completamente concluída.
Erro 5: redirecionamentos com falha
Os redirecionamentos podem ser complicados. Há muitas coisas que podem dar errado, desde redirecionamentos quebrados até cadeias e loops de redirecionamento.
Felizmente, é fácil identificar esses erros com o Site Audit. Basta verificar o relatório de redirecionamentos e passar por todos os problemas.
Depois de clicar no botão “Visualizar URLs afetados”, você verá um relatório semelhante a este, apenas com mais colunas e métricas padrão:
A melhor coisa aqui é que você realmente verá todas as URLs afetadas – as redirecionadas, as dentro da cadeia de redirecionamento e as vinculadas às redirecionadas.
Há duas coisas que você deve fazer aqui.
A primeira é dividir os redirecionamentos, neste caso:
https://blog.example.com/123/> -> redirecionamento 301 -> >https://example.com/blog/987/
Isso garantiria que todos os backlinks apontando para https://blog.example.com/123/ e https://example.com/blog/123/ seriam redirecionados apenas uma vez. Isso é bom para backlinks externos, pois entrar em contato com webmasters com solicitações de edição de link seria altamente ineficaz e bastante irritante.
Podemos fazer melhor internamente.
Você deve se esforçar para obter o menor número de redirecionamentos. É aí que a coluna do número de inlinks entra em jogo.
Inlinks são URLs que apontam para o URL afetado pela cadeia de redirecionamento. Você deseja trocar os links nessas páginas por URLs que retornam um código de status HTTP 200. Se você clicar no número de inlinks, verá todos eles:
Claro, novamente, a próxima etapa seria verificar os inlinks das URLs na cadeia de redirecionamento. No entanto, isso é de menor prioridade, pois já quebramos a cadeia de redirecionamento. Eles seriam marcados como redirecionamentos 301 padrão no relatório de redirecionamentos 3XX no próximo rastreamento.
