HTTP a HTTPS: Una guía para el SEO para asegurar un sitio web
Antes, cuando escribí el artículo, " ¿Por qué todo el mundo debe estar en movimiento para HTTP / 2 ", que estaba destinado a hacer tomar conciencia de una actualización del protocolo impresionante que yo pensaba que era una victoria fácil para hacer un sitio web más rápido.
Desde entonces, he hablado con cientos de propietarios de negocios y SEO acerca de la actualización, realizado docenas de mejoras y localizado averías docenas más. Me he dado cuenta de que todavía hay un gran obstáculo para los propietarios de negocios y SEO: HTTPS. En el momento de la gotcha con HTTP / 2 es que la mayoría de los navegadores sólo soportan este nuevo protocolo a través de una conexión segura, lo que significa que tiene que migrar su sitio web para HTTPS.
No debería ser una sorpresa para nadie que Google y muchos otros quieren que la Web sea más segura. Google tuvo su campaña de HTTPS en todas partes , se anunció HTTPS como una señal de clasificación , y han comenzado la indexación de páginas seguras a través de las páginas no seguras . Incluso tienen su propia guía, " Protección de su sitio web con HTTPS ", que animo a todos a leer, junto con este artículo.
A pesar de toda esta presión hacia una red más segura, no lo es menos: Menos de 0,1% de los sitios web son seguras .
Parece que todo el mundo está tratando de hacer que sea lo más fácil posible para cambiar mediante la eliminación de barreras a la entrada, como el costo. Vamos a Cifrar ofrece certificados libres (Nota al margen: Estoy muy divertida que Google Chrome tiene el único nofollow en su patrocinio con pagada después siendo llamados a cabo .) muchos anfitriones de sitios web y CDN también están ofreciendo certificados de seguridad gratuitas para animar a la gente para hacer el cambio, pero muchas personas todavía no se están moviendo.
¿Por qué pasar a HTTPS?
Google identifica varias razones para cambiar a HTTPS en su página web guía de migración:Los datos enviados a través de HTTPS se asegura a través del protocolo Transport Layer Security (TLS), que proporciona tres capas fundamentales de la protección:
Cifrado. El cifrado de los datos intercambiados para que esté seguro de miradas indiscretas. Eso significa que mientras el usuario está navegando en un sitio web, nadie puede "escuchar" a sus conversaciones, realizar un seguimiento de sus actividades a través de múltiples páginas o robar su información.
Integridad de los datos. Los datos no puede ser modificado o dañado durante la transferencia, intencionadamente o no, sin ser detectado.
Autenticación. Demuestra que los usuarios se comunican con la página web deseada. Protege contra los ataques man-in-the-middle y construye la confianza del usuario, lo que se traduce en más beneficios para el negocio.
Hay otros beneficios, sin embargo, incluyendo el impulso ranking de Google se ha mencionado anteriormente.
Hacer el cambio a HTTPS también ayuda con la pérdida de los datos de referencia que se produce cuando el valor de referencia en el encabezado se elimina cuando se cambia de un sitio web seguro a un sitio web no segura. Programas de análisis de tráfico sin atribuyen el valor de referencia tan directa, que representa una gran parte de lo que se llama " tráfico de oscuridad ."
El interruptor también impide que un montón de cosas malas, como cuando AT & T estaba inyectando anuncios en sus puntos de acceso . Ellos no habrían sido capaces de inyectar estos anuncios en un sitio web con HTTPS.
¿El seguro HTTPS mi sitio web?
La gente escucha HTTPS se refiere como un protocolo seguro, y piensan que se protege su sitio web. El hecho es que su sitio web no está protegido, y todavía puede ser vulnerable a una o más de las siguientes:desactualizaciones
SSL / TLS vulnerabilidades
Heatbleed, caniche, atasco, etc.
Hacks de un sitio web, servidor o red
Las vulnerabilidades de software
ataques de fuerza bruta
ataques DDoS
Hacer el cambio de HTTP a HTTPS
Comience con un servidor de prueba .
Esto es importante porque le permite tener todo bien y la prueba sin atornillarla en tiempo real. Incluso si usted está haciendo el interruptor sin un servidor de prueba, no hay casi nada que puede hacer que no se puede recuperar de, pero sigue siendo la mejor práctica para tener un plan y tener todo probado antes de tiempo.Rastrear el sitio web actual para que sepa el estado actual de la página web y para fines de comparación.
Lea toda la documentación relacionada con su servidor o CDN para HTTPS . Me encuentro con un montón de diversión cuestiones de CDN, pero también puede ser sencillo.
Obtener un certificado de seguridad e instalar en el servidor. Esto variará dependiendo de la configuración del entorno de servidor de alojamiento y demasiado para mí entrar en detalles, pero el proceso es por lo general bien documentado.
Actualizar las referencias en el contenido . Esto por lo general se puede hacer con una búsqueda y reemplazo en la base de datos. Usted querrá actualizar todas las referencias a los enlaces internos para utilizar HTTPS o rutas relativas.
Actualizar las referencias en las plantillas . Una vez más, dependiendo de cómo se implementa, podría hacerse con Git o simplemente Notepad ++, pero usted querrá asegurarse de que las referencias a los scripts, imágenes, enlaces, etc. estás usando HTTPS o rutas relativas.
Actualizar las etiquetas canónicas . La mayoría de los sistemas CMS se hará cargo de esto para usted cuando usted hace el cambio, pero la comprobación doble, debido a que no siempre es el caso.
Actualizar las etiquetas hreflang si su sitio web, o cualquier otra etiqueta, como las etiquetas OG utiliza para el caso. Una vez más, la mayoría de los sistemas CMS se hará cargo de esto, pero lo mejor es que al control de calidad por si acaso.
Actualizar ninguna plugins / módulos / add-ons para asegurarse de que nada se rompe y que nada incluye contenido no seguro. Yo veo comúnmente búsqueda del sitio interna y formas perdidas.
Configuración CMS-específicos pueden necesitar ser cambiado . Para los grandes sistemas CMS, por lo general son bien documentado en las guías de migración.
Rastrear el sitio para asegurarse de que no se pierda ningún enlace y nada se ha roto. Puede exportar cualquier contenido no seguro en uno de los Screaming Frog informa de si este es el rastreador que está utilizando.
Asegúrese de que todos los scripts externos que son llamadas de soporte HTTPS .
Forzar HTTPS con redirecciones . Esto dependerá de su servidor y la configuración, pero está bien documentado para Apache, Nginx e IIS.Actualización de edad vuelve a dirigir actualmente en vigor (y mientras estás en ello, tomar de nuevo sus enlaces perdidos de redirecciones que no se han hecho en los últimos años). He mencionado durante el Q & A parte del Grupo Técnico de SEO en SMX West que nunca he tenido una caída de sitio en el ranking o tráfico cuando se cambia a HTTPS, y mucha gente me preguntó sobre esto. La debida diligencia en las redirecciones y reorientar las cadenas es probable que la diferencia, ya que esto es lo que veo en mal estado las migraciones más cuando la solución de problemas.
Rastrear las antiguas direcciones URL para cualquier redirección rotos o cualquier cadenas de redirección, que se pueden encontrar en un informe con Screaming Frog.
Actualizar mapas de sitio para utilizar HTTPS versiones de las direcciones URL.
Actualizar el archivo robots.txt para incluir el nuevo mapa del sitio.
Habilitar HSTS . Esto le indica al navegador para usar siempre HTTPS, lo que elimina un registro de entrada del lado del servidor y hace que su sitio web de carga rápida. Esto también puede causar confusión a veces, ya que la redirección se mostrará como 307. Podría tener un 301 o un 302 detrás de él, sin embargo, y puede que tenga que borrar la caché del navegador para ver cuál.
Habilitar OCSP grapado . Esto permite a un servidor para comprobar si un certificado de seguridad se revoca en lugar de un navegador, lo que mantiene el navegador de tener que descargar o una referencia cruzada con la autoridad de certificación emisora.
Añadir / 2 compatibilidad con HTTP .
Añadir la versión HTTPS de su sitio a todas las versiones del motor de búsqueda de herramientas para webmasters que se utilizan y cargar el nuevo mapa del sitio con HTTPS para ellos. Esto es importante, ya que he visto gotas de tráfico mal diagnosticados porque vieron que el tráfico en la gota perfil HTTP, cuando el tráfico en la realidad se trasladó al perfil HTTPS. Otra nota de esto es que no es necesario utilizar la herramienta Cambio de dirección al cambiar de HTTP a HTTPS.Actualizar el archivo de desautorización si tuviera una para la versión HTTPS.
Actualizar la configuración de los parámetros de URL si se hubiera configurado éstos.
¡Ir a vivir!
En su plataforma de análisis , asegúrese de actualizar la URL por defecto si uno está obligado a garantizar que se realiza el seguimiento de HTTPS correctamente, y añadir notas acerca del cambio para que sepa cuándo se produjo para referencia futura.
Actualización de sus acciones recuentos sociales . Hay una gran cantidad de trampas a esto, en que algunas de las redes transferirá el recuento a través de sus API, mientras que otros no lo harán. Ya hay guías para este alrededor de si usted está interesado en mantener su recuento de las acciones.
Actualizar cualquier medio, electrónico o de automatización de marketing campañas de pago para utilizar las versiones de las direcciones URL HTTPS.
Actualizar ninguna de las otras herramientas tales como software de pruebas A / B, mapas de calor y seguimiento de palabras clave a utilizar las versiones de las direcciones URL HTTPS.
Monitorear todo durante la migración y comprobar, una doble comprobación y triple comprobación para asegurarse de que todo va bien. Hay tantos lugares donde las cosas pueden salir mal, y parece que por lo general hay varias cuestiones que surgen en cualquier cambio a HTTPS.
Una pregunta que a menudo me preguntan es si los enlaces entrantes deben limpiarse. Se trata de una enorme cantidad de extensión y esfuerzo. Si tienes tiempo, entonces seguro; pero lo más probable es que usted está ocupado con otras cosas, y no me siento que sea absolutamente necesario. Sin embargo, usted debe actualizar los enlaces en cualquier propiedad que usted controla, tales como perfiles sociales.
Los problemas más comunes con las migraciones HTTPS
Cosas que pueden salir mal incluyen:
la prevención de rastreo de Google de la versión HTTP del sitio, o prevenir sitio se arrastra en general (por lo general ocurre debido a la falta de actualización del servidor de prueba para permitir que los robots).
Problemas de duplicación de contenido, con las dos versiones HTTPS y HTTP de las páginas que muestran y diferentes versiones de la página que muestra en HTTP y HTTPS.
La mayoría de los problemas comunes con las migraciones HTTPS son el resultado de redirecciones aplicadas incorrectamente. (He también tuvieron tiempos de la diversión la limpieza de sitios web que cambiaron la totalidad de su estructura / diseño, al tiempo de hacer el cambio a HTTPS).
Redirecciones merecen su propia sección
Como se ha indicado anteriormente, los principales problemas que veo con la migración a HTTPS tienen que ver con las redirecciones. No ayuda que el cambio se puede hacer a nivel de registro, en la configuración del servidor, o incluso en un archivo .htaccess; todos tienen sus propios "trampas".redirecciones fallidos y redirigir las cadenas son casi siempre problemas. Asegúrese de revisar páginas secundarias, así como la página de inicio; dependiendo de cómo las reglas están escritas y donde se colocan, estos pueden ser afectados de manera diferente. También es necesario mirar realmente lo que está pasando con estos en cuanto a los códigos de estado y lúpulo, no sólo si se llega a la página correcta.
Definitivamente no ayuda cuando la documentación de Apache para esto no incluye a 301 y Apache por defecto un 302. El siguiente código debe actualizarse para R = 301.
En RewriteEngine
# Esto permitirá a las capacidades de reescritura
RewriteCond% {} HTTPS! = Activado
# Esto comprueba para asegurarse de que la conexión no está ya HTTPS
RewriteRule ^ / https? (*.): // {% NOMBRE_SERVIDOR} / $ 1 [R, L]
# Esta regla se redirigir a los usuarios de su ubicación original, en la misma ubicación pero usando HTTPS.
# Es decir http://www.example.com/foo/ a https://www.example.com/foo/
# La barra inicial se hizo opcional para que esto va a funcionar bien en httpd.conf
# O contexto .htaccess
He visto sitios recuperarse de este error cuando se cambia, pero parece ocurrir sólo varios meses después, cuando Google se da cuenta de lo que pasó y corrige el error en su extremo.
Incluso el mejor de nosotros no, a veces:
Cree, pero verifica. Yo uso de herramientas como Screaming Frog y Camino Ayima redireccionamiento para realizar comprobaciones rápidas en algunas de las antiguas direcciones URL - o, con un poco de manipulación de Excel, hacer cheques a granel en grandes cantidades de direcciones URL y las redirecciones de más edad. Esto ayuda a asegurar que todo está volviendo a dirigir correctamente y sin saltos múltiples.
(Consulte la sección "Comprobación de nuestro trabajo" en " Tomar Enlaces Volver ¿Ha perdido " para la ayuda en la recreación de URL que se rastrearán.)
Cierre de pensamientos sobre HTTPS
En pocas palabras, HTTPS no va a desaparecer. HTTP / 2, Google AMP y el protocolo QUIC de Google (que es probable que normalizarse pronto) todos requieren conexiones seguras para los navegadores que utilizan ellos. El hecho es que HTTPS está siendo empujado con fuerza por los poderes fácticos, y es el momento de hacer el cambio.
La mayor parte de los problemas que veo son de mala planificación, falta de implementación y seguimiento deficiente. Si usted sigue los pasos que he descrito, usted debe tener poco o ningún problema cuando se migra de HTTP a HTTPS.
No hay comentarios:
Publicar un comentario