¿Cuál es la política de Google sobre contenido separado en las mismas URL en versiones móviles y de escritorio?


8

Actualmente estoy desarrollando una versión móvil de mi sitio donde los dispositivos de los usuarios se identifican automáticamente y luego se muestran vistas móviles o de escritorio de la misma URL.

Para fines de usabilidad, me gustaría mostrar información diferente en ciertas URL en dispositivos móviles que en computadoras de escritorio. Por ejemplo, preferiría que el contenido esté directamente en la primera página en dispositivos móviles, mientras que mi dominio raíz de escritorio es una página de destino.

  • ¿Cómo afectará tal disposición las opiniones de Google sobre mi sitio?
  • ¿Es perjudicial para mi ranking?
  • ¿O Google separa los resultados de escritorio y móviles?

Respuestas:


3

Parece que le preocupa que servir contenido diferente a usuarios móviles que a usuarios de escritorio en la misma URL, utilizando la detección de agente de usuario, pueda considerarse una forma de encubrimiento y, por lo tanto, penalizado por Google.

Según el Blog central de Google Webmaster , este no es el caso, siempre que realice la detección del navegador móvil correctamente. Esencialmente, el detalle importante a tener en cuenta es que los rastreadores de Google usan diferentes cadenas de agente de usuario dependiendo de si esperan contenido de escritorio o móvil. Por ejemplo, una cadena típica de agente de usuario para solicitudes normales de Googlebot sería:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

mientras que para las solicitudes del rastreador móvil, verá algo como:

SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1;
+http://www.google.com/bot.html)

o (para solicitudes de teléfonos inteligentes):

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26
(KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible;
Googlebot/2.1; +http://www.google.com/bot.html)

Siempre y cuando se asegure de detectar correctamente el último tipo de solicitudes de Googlebot (y no el tipo anterior) como móvil, y les sirva contenido móvil, todo debería estar bien. Básicamente, lo importante es que las solicitudes normales de Googlebot deben recibir contenido de escritorio, mientras que las solicitudes móviles de Googlebot deben recibir contenido móvil.

Aquí hay un buen diagrama que ilustra esto, del artículo del Blog de Google Webmaster Central que he vinculado anteriormente:

Diagrama

Además, para que el rastreador de Google sepa que puede haber contenido diferente disponible para los navegadores móviles, querrá configurar su servidor web para enviar el Vary: User-Agentencabezado HTTP para cualquier página para la que esté utilizando la detección de agente de usuario . También querrá asegurarse de evitar dificultades comunes al detectar agentes de usuario .


8

El mejor curso de acción es usar URL canónicas . Esto evita una situación en la que se le penaliza por contenido duplicado.

Cuando se trata de sitios web de escritorio frente a móviles, la mayoría de los sitios tendrán algo como esto en su sitio web móvil:

Ejemplo para: http://m.mywebsite.com/page.html

<link rel="canonical" href="http://mywebsite.com/page.html" />

La etiqueta canónica básicamente le dice a Google que se puede acceder al mismo contenido a través de múltiples URL.

Los usuarios de escritorio / móviles son detectados por el servidor y redirigidos a la versión apropiada (esto sucede en Blogger, que es propiedad de Google).

Con este método, Google no separará los resultados (no desea esto). También significa que los enlaces entrantes a páginas móviles devolverán el peso / "jugo de enlace" a la página original. En este caso, los enlaces a http://m.mywebsite.com/page.htmlafectaránhttp://mywebsite.com/page.html


7

En mi experiencia, los visitantes móviles quieren el mismo contenido que sus visitantes de escritorio. Trabajé para un sitio web de viajes con mucha información sobre hoteles y restaurantes. El sitio es generalmente conocido por los hoteles, pero pensamos que los usuarios de dispositivos móviles estarían mucho más interesados ​​en el contenido de los restaurantes porque estaban buscando algo cuando estaban fuera. Esa suposición no era correcta, los usuarios móviles buscaban el contenido del hotel tanto como los usuarios de escritorio.

También escuché el argumento de que reducir el contenido puede ayudar a la experiencia móvil porque las páginas se cargan más rápido. Descubrí que rara vez el contenido hace que las páginas se carguen lentamente en dispositivos móviles.

  • La latencia es un problema mayor que la velocidad de descarga en dispositivos móviles. Las páginas grandes no son el problema, pero cada solicitud puede demorar unos segundos. A menudo tiene sentido poner más contenido en la página y dejar que el usuario se desplace hacia ella en lugar de hacer clic en más páginas.
  • El peso del contenido a menudo queda eclipsado por el peso del marcado, CSS y JavaScript. Comience con las cosas que el usuario no puede ver cuando intenta eliminar bytes de la página.

Los usuarios tienden a sentirse frustrados cuando no pueden usar el sitio móvil de la manera en que usan el sitio de escritorio. Google utiliza la satisfacción del usuario como una señal importante en sus algoritmos de clasificación. Dudo que Google penalice su sitio directamente por servir contenido diferente a usuarios móviles. Sin embargo, cuando los usuarios encuentran que su sitio es menos utilizable de lo que esperaban, su clasificación caerá.


1
"Los usuarios tienden a frustrarse cuando no pueden utilizar el sitio móvil de la forma en que utilizan el sitio de escritorio" totalmente de acuerdo
Krokola

@Stephen, ¿qué quieres decir con latencia? ¿Cuál es la causa de esto?
AgA

La latencia es tiempo de ida y vuelta. El tiempo que le toma al usuario iniciar una acción hasta que recibe una confirmación de esa acción del servidor. La latencia es bastante normal cuando el teléfono tiene wifi, pero es mucho mayor cuando está conectado a Internet a través de la torre celular.
Stephen Ostermiller


1

Google es lo suficientemente inteligente como para detectar sitios móviles y no móviles. Y comenta específicamente que esto no se ve como spam.

La consideración más importante es marcar su URL preferida como canónica.

Del WMT de Google:

El contenido duplicado generalmente se refiere a bloques sustantivos de contenido dentro o entre dominios que coinciden completamente con otro contenido o son apreciablemente similares. Principalmente, esto no es de origen engañoso. Los ejemplos de contenido duplicado no malicioso podrían incluir:

Discussion forums that can generate both regular and stripped-down pages targeted at mobile devices
Store items shown or linked via multiple distinct URLs
Printer-only versions of web pages

Esto ha sido bien documentado desde 2010.

Vea el artículo de SEL sobre:

No se penalice: los sitios móviles no son contenido duplicado

Más recientemente, Matt Cut de Google ha dicho que no se preocupe demasiado por el contenido duplicado. El problema es más de qué página desea clasificar en los SERP.

¿Cómo se requiere contenido duplicado (términos y condiciones, etc.)

Por último, consulte el tema de herramientas para webmasters de Google en:

Contenido duplicado

También SEOMOz, tiene un gran artículo sobre el tema:

¿Qué es el contenido duplicado?


0

Palabras de Google: cuando un sitio web está configurado para servir navegadores de escritorio y móviles que utilizan diferentes URL, los webmasters pueden querer redirigir automáticamente a los usuarios a la URL que mejor les sirve. Si su sitio web utiliza la redirección automática, asegúrese de tratar a todos los Googlebots como cualquier otro agente de usuario y redirigirlos adecuadamente.

Google reconoce tres configuraciones diferentes para construir sitios móviles.

Google no favorece ningún formato de URL en particular siempre que las páginas y todos los activos de la página sean accesibles para todos los agentes de usuario de Googlebot.

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.