Mejores prácticas HTTPS para SEO y usabilidad


8

Considere una página, http://example.comque se puede ver tanto públicamente como cuando un usuario se autentica. Ahora suponga que habilita HTTPS para cada página cuando un usuario inicia sesión en su sitio web, pero solo cuando está conectado. Su página http://example.comahora es https://example.compara todos los usuarios registrados. Si a ese usuario conectado le gusta su página y decide vincularla a través de una publicación de blog o un sitio web de redes sociales, existe una buena posibilidad de que usen la versión HTTPS de la URL.

Desde una perspectiva de SEO, ¿cuál es su estrategia para evitar problemas de contenido duplicado entre las dos URL?

¿Qué debería suceder si un usuario llega a la URL HTTPS pero no ha iniciado sesión o no tiene una cuenta? ¿Debería haber una redirección a la versión HTTP? Si es así, ¿cómo lo manejarías?

Mi instinto es que para todas las páginas que se pueden ver tanto públicamente como mientras están conectadas, la página debe detectar primero si el usuario está conectado. Si está conectado, sigue siendo HTTPS o utiliza una redirección 302 de la versión HTTP a HTTPS. Si el usuario no ha iniciado sesión y llega a la versión HTTPS de la URL, utiliza una redirección 301 a la versión HTTP. Sin embargo, agradecería una solución más elegante o efectiva.

Editar : estaba asumiendo que si un usuario ha iniciado sesión, cada URL debería ser HTTPS (o al menos, debería ser una opción), pero como he investigado un poco más, tal vez esa suposición fue incorrecta. La forma en que veo a las personas que lo implementan es que solo habilitan HTTPS para las páginas que envían y reciben datos confidenciales: inicio de sesión, pago del carrito de compras, administración del perfil de usuario, etc. Estoy tratando de averiguar qué modelo es el mejor.

Aparentemente, Google Mail ofrece a los usuarios la opción de usar HTTPS en cada página a través de una configuración en el perfil del usuario. Esa es ciertamente una opción, pero aún necesitaría abordar el comportamiento de las páginas disponibles públicamente para todos los estados de autenticación.

Debido a que estoy construyendo un sistema de administración de contenido que será utilizado por otras personas, necesito asegurarme de hacerlo bien. ¿Qué configuraciones deberían estar disponibles para el propietario del sitio? En este punto, estoy pensando en un control granular sobre cada página (ya sea que esté segura o no con SSL) y luego para todo el sitio también. Sin embargo, otorgar ese nivel de control puede ser un error si las personas no comprenden todos los problemas y pueden terminar causando problemas de seguridad. Ese, quizás, es el primer problema. ¿Cuáles son los niveles apropiados de control y cuáles son los valores predeterminados inteligentes? El segundo es cómo deben comportarse las páginas para el usuario. Desde una perspectiva de SEO, creo que el proceso que describí anteriormente o el uso delrel="canonical" (como sugirió jmb) funcionaría, pero también es esencial definir el comportamiento de la página para que sea segura y sin problemas.

Respuestas:


6

Es posible que desee investigar <link rel="canonical" />. Ver http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html . En los comentarios, alguien de Google dice que se puede usar para problemas de http / https.

Advertencia: no estoy seguro de si <link rel="canonical" />los motores de búsqueda que no sean Google, Yahoo y Bing son compatibles con ellos. Si otros motores son importantes para su sitio, debe consultar sus preguntas frecuentes.

Desde la perspectiva del usuario: Redirigir a un usuario que ha iniciado sesión desde http a https es inseguro (si entiendo correctamente que le gustaría crear un proceso continuo). En el punto donde llega al sitio (antes de la redirección), transfería su cookie de sesión a través de http, haciéndolo vulnerable al secuestro de sesión. Dicho usuario debe iniciar sesión nuevamente desde una página https.

En el caso de que un usuario llegue a través de https y no haya iniciado sesión: Dependiendo de las circunstancias (tamaño del sitio, volumen de tráfico esperado, número esperado de veces que esto sucederá) puede simplemente mantenerlo en https. También vea HTTPS para todo el sitio y /programming/174348/will-web-browsers-cache-content-over-https para discusiones sobre cómo ejecutar un sitio en https (en parte en su caso).

Actualizar:

¿Cuáles son los niveles apropiados de control y cuáles son los valores predeterminados inteligentes?

Niveles apropiados de control:

  • Seguro (https activado, incluida la página de inicio de sesión y todo a partir de ahí)

y

  • Inseguro (sin https).

No hay término medio si quieres "hacerlo bien". Ver también http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ y /programming/274274/is-it-secure-to-submit -de-a-http-form-a-https

Valor predeterminado: depende de quiénes son sus clientes.


Estaba pensando en esto como una opción también. La razón por la que no estaba seguro al respecto es porque, aunque aborda el problema de SEO, no aborda cómo debería comportarse la página para un usuario. ¿Alguna idea?
Virtuosi Media

Buen punto, actualicé mi respuesta.
jmb

¿La regeneración de la sesión en cada carga de página resolvería el problema de secuestro de sesión?
Virtuosi Media

Gracias. Una pregunta más: ¿cómo cree que las personas verían un CMS que requiere un certificado SSL si aceptan el registro del usuario?
Virtuosi Media

Creo que eso depende mucho del público objetivo. Los bancos lo verían como un requisito, incluso en áreas no centrales que no incluyen información financiera. Una organización sin fines de lucro con un presupuesto probablemente desaprobará el costo y la complejidad adicional.
jmb

2

No existe una estrategia de SEO para páginas SSL. Parte de la definición de almacenamiento en caché es esta:

If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.

ver: tutorial de almacenamiento en caché

Por lo tanto, para evitar la superposición con páginas que no son SSL donde esto puede perjudicar la clasificación, es tener sus páginas sensibles a SSL en URL completamente diferentes.

Irónicamente, he visto que los motores de búsqueda realmente almacenan y mantienen enlaces con la URL HTTPS en ellos. Esto es contrario a lo que normalmente debería suceder, pero lo hace en los casos en que la página es un área de inicio de sesión, es la página de inicio o de lo contrario ha reescrito el pragma de caché para permitir el almacenamiento en caché. Yo diría que evite esto si es posible, ya que su página caerá en PageRank generalmente.


1
Gracias, Talvi, pero creo que puedes haber entendido mal mi pregunta, que no se refería al almacenamiento en caché del navegador. Debido a que los motores de búsqueda rastrean e indexan páginas https, significa que se enfrentan a problemas de contenido duplicado si alguien enlaza con la versión https. Cambiar la URL no ayuda porque http y https ya son dos URL diferentes a los ojos del motor de búsqueda. Con diferentes URL, está dividiendo efectivamente su PageRank. El meollo de mi pregunta era cómo se podía desarrollar una estrategia para evitar el problema del contenido duplicado. Desafortunadamente, no creo que el enlace de almacenamiento en caché ayude a resolver esto.
Virtuosi Media

Estoy de acuerdo con Virtuosi Media: los motores de búsqueda generalmente no tienen problemas con https: // - URLs.
John Mueller

1
@virtuosi Me tienes allí. ¿Golpear el motor de búsqueda con un objeto contundente tal vez?
Talvi Watia

2

La redirección 302 no transfiere el ranking de búsqueda, por lo que puede perder el ranking de búsqueda si 302 masifica su sitio.

301 puede cambiar las definiciones de marcadores, no me gustaría constantemente 301 mis usuarios.

Además, asegúrese de que la versión http incluya un formulario de inicio de sesión para que el usuario pueda volver rápidamente a la versión https.

Ahora la gran pregunta es: si los datos se pueden ver a través de http, ¿por qué tiene una versión https? ¿Qué datos estás ocultando con el cifrado https que aún no existe?

Puede crear un área de miembros https o publicar formularios en la URL https desde la página http o muchas otras opciones que no incluyen tener todo el sitio en http y https.

Aparte de eso, su idea parece viable, pero no tengo información privilegiada sobre cómo funcionan Google y los otros sitios web y realmente no puede estar seguro de cómo esto afectará su clasificación (y es un caso tan extremo que puede cambiará drásticamente cada vez que Google actualice el algoritmo).


Supongo que estaba asumiendo que si un usuario inicia sesión, cada URL debería ser https, pero como he investigado un poco más, tal vez esa suposición fue incorrecta. La forma en que veo a las personas que lo implementan es que solo habilitan https para las páginas que envían y reciben datos confidenciales: inicio de sesión, pago del carrito de compras, administración del perfil de usuario, etc. Estoy tratando de averiguar qué modelo es el mejor. Debido a que estoy construyendo un sistema de administración de contenido que será utilizado por otras personas, necesito asegurarme de que lo hago bien.
Virtuosi Media
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.