SSL, Factor de Posicionamiento Web SEO

Así como los dominios web que trabajemos deben estar aparcados en proveedores diferentes de alojamiento y usar diferentes DNS, diferentes direcciones IP no correlativas, etcétera, hay especificaciones técnicas para configuraciones de servidor y establecimiento de protocolos de comunicación web que deben cumplirse a cabalidad, cuando emanan directamente desde la fuente oficial: Google. Una de estas especificaciones técnicas clave, que deben ser utilizadas sine qua non, son los certificados SSL, y forzar la comunicación entre el servidor y el usuario, a través del puerto 443.

El año 2014, desde Google anunciaron que el uso de certificado SSL comenzaría a formar parte de la familia de señales de ranking, afectando inicialmente al 1% de las búsquedas, y que este porcentaje iría aumentando de manera progresiva, con el objetivo de dar tiempo a los webmasters para que la migración de HTTP a HTTPS fuera gradual, al punto de convertirse en regla, es decir, los sitios web que no tengan certificado SSL no aparecerán en los SERP de Google:

 

  • https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html
  • https://www.joshuaprovoste.com/seo-y-https-el-nuevo-giro-de-google/

 

Certificados SSL como factor de Ranking SEO y Posicionamiento Web
Certificados SSL como factor de Ranking SEO y Posicionamiento Web

Esta iniciativa viene a solucionar diversos problemas de seguridad informática que tienen relación directa con la comunicación que se realiza entre el dispositivo del usuario (smartphone, desktop, laptop, etc.) y el servidor web (hosting, VPS, etc.), como por ejemplo, ataques de tipo MitM, a través de los cuales es posible interceptar y registrar los datos personales frágiles que un usuario ingresa en formularios de contacto, registro y compra (nombres de usuario, email, contraseñas, tarjetas de crédito, etc.). En este sentido, Google comenzó a notificar a los administradores de sitios web mediante Google Chrome y Google Search Console, enfocándose en la detección de sitios de campos de formulario para este fin:

 

  • https://www.searchenginejournal.com/google-is-requiring-https-for-secure-data-in-chrome/183756/
  • https://searchengineland.com/google-emails-warnings-webmasters-chrome-will-mark-http-pages-forms-not-secure-280907
  • https://searchengineland.com/google-search-console-warns-nonsecure-collection-passwords-upcoming-chrome-browser-release-266486
  • https://searchengineland.com/google-emails-warnings-webmasters-chrome-will-mark-http-pages-forms-not-secure-280907
  • https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
  • https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html

 

Afortunadamente, podemos comenzar a utilizar Let’s Encrypt como alternativa, para posteriormente utilizar un certificado SSL obedeciendo a las necesidades:

 

  • https://letsencrypt.org/
  • https://documentation.cpanel.net/display/CKB/The+Let%27s+Encrypt+Plugin
  • https://blog.cpanel.com/announcing-cpanel-whms-official-lets-encrypt-with-autossl-plugin/

 

Sin embargo, hasta el momento, es autofirmado, razón por la cual arroja alertas de configuración en Google Search Console, por lo tanto, la solución real a esta necesidad, es utilizar un certificado SSL firmado y proveído por empresas del rubro:

 

  • https://searchengineland.com/google-sending-messages-to-webmasters-for-ssltls-certificate-not-matching-235732

 

En la base de datos que sea utilizada, todos los registros de URL “http” deben ser reemplazados por “https” (en el caso de migración a este protocolo), y lo mismo debe ser aplicado a nivel de programación. Si estos cambios no son efectuados, el certificado SSL no se ejecutará de manera correcta en el browser, arrojando alertas de seguridad o dejando de mostrar su color verde característico. Una herramienta útil para este fin es Why No Padlock, la cual entrega información detallada acerca de qué tipos de archivos y URLs son las que generan este tipo de error para corregirlos:

 

  • https://www.whynopadlock.com/

 

De igual manera, se debe forzar la ejecución de SSL de lado del servidor, usando reglas para que toda comunicación HTTP (puerto 80) se realice por medio de HTTPS (puerto 443). En el caso de Apache, las configuraciones son muchas, pero hay dos reglas o casos que al implementarse por medio del fichero .htaccess producen esta reglamentación en el sitio:

Regla o caso A,

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Regla o caso B,

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://tusitioweb.com/$1 [R=301,L]

Obviamente, estas reglas de .htaccess no aplican para todos los tipos de servidores que utilizan Apache (las configuraciones de cada servidor tienden a ser diferentes), por lo cual se recomienda probar esta regla antes de implementarla en un sitio web que está online. Por estas mismas razones, la declaración del status de las redirecciones pueden variar, partiendo desde sus bases, las cuales pueden ser [R=301] o [R=301,L], e incluso de forma temporal (302).

En el caso particular de WordPress, uno de los problemas usuales cuando no está habilitado el servicio del fichero .htaccess, es que pese a la estipulación de https en la sección de configuraciones generales para dirección de WordPress y dirección de sitio, no se ejecuta el certificado SSL en el navegador al interior del panel de administración. Esto puede solucionarse, eventualmente, añadiendo la siguiente línea de código en el archivo wp-config.php:

define(‘FORCE_SSL_ADMIN’, true);

Como medida complementaria, podemos reemplazar las reglas del fichero .htaccess que por defecto genera WordPress tras instalar el CMS, incluyendo las reglas anteriores de forzado de certificado SSL:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>