redirect amp-html

redirect - ¿Cómo sabe el servidor cuándo servir una página de amplificación?



amp-html (2)

Entiendo que habrá una versión de un sitio con HTML diseñado para dispositivos de escritorio y luego las páginas de AMP.

¿Hay algo que deba hacer para que el sitio web publique contenido de AMP en dispositivos móviles?

¡Buena pregunta!

Resumen:

  • AMP no proporciona ningún medio automático de redirección, solo el marcado necesario para su motor de búsqueda (y potencialmente otros sitios web / aplicaciones / motores de búsqueda para enviar a sus usuarios a la página de AMP
  • Se podrían utilizar métodos antiguos para redirigir a los usuarios de dispositivos móviles a sitios móviles, generalmente mediante la detección de agentes de usuarios móviles y redirigirlos a través de la redirección 301/302 a la página de AMP.
  • Redirigir a los usuarios de dispositivos móviles puede que no valga la pena porque los métodos anteriores mencionados son un poco asquerosos

Respuesta completa:

En términos de Google y la página de resultados del motor de búsqueda (SERP), deberá incluir esto en su marcado de escritorio:

<link rel="amphtml" href="https://www.example.com/url/to/amp/document.html">

y esto en tu marcado de AMP:

<link rel="canonical" href="https://www.example.com/url/to/standard/document.html">

para que Google y otras redes de alto tráfico como Twitter, LinkedIn o Pinterest detecten la firma amphtml y dirijan los navegadores móviles a la página de AMP en consecuencia. Diría Facebook, pero dado que AMP es un producto competidor de Facebook Instant Articles , sospecho que arrastrarán los talones.

AMP es, por supuesto, un animal completamente diferente, tanto de código abierto como una tecnología web en lugar de una plataforma nativa de aplicaciones para el contenido, pero la web y las plataformas nativas se oponen entre sí y, si bien Google ofrece una gran cantidad de aplicaciones, Está claro desde tecnologías como ServiceWorker que están presionando para la web como una plataforma de contenido, lo que no debería ser una sorpresa porque el tiempo pasado en Facebook o aplicaciones de Apple es tiempo perdido de la búsqueda de Google y su publicidad, de la que Google obtiene sus ingresos.

Pero estoy divagando: obviamente esta declaración rel="amphtml" solo instruirá a Google et al. para redirigir este resultado a los usuarios de dispositivos móviles desde sus páginas. Esto se debe a que una política de redireccionamiento no era la intención de Google o el equipo de AMP, que más bien prevé un mundo donde todo el mundo pasa por Google u otro gran jugador en lugar de ser visitado directamente o vinculado directamente por correo electrónico o algo así.

En teoría, podría implementarse algún día en el nivel del navegador, pero les lleva a los proveedores del navegador el tiempo suficiente para estandarizar las propiedades esenciales de diseño / estilo y las API de JavaScript, y mucho menos las consideraciones aleatorias no estándar como lo es actualmente AMP. Apple arrastrará sus talones cuando se trata del navegador porque competiría con su propia aplicación de noticias .

Probablemente podamos esperar que la redirección de AMP se implemente en el navegador Chrome (y, por lo tanto, en Opera), pero incluso eso podría tardar un tiempo. Por lo tanto, para obligar a los dispositivos móviles a redireccionar a las páginas AMP en lugar de a las estándar, en última instancia necesitaría configurar su servidor web para detectar agentes de usuario móviles (o tipos MIME menos comunes) y redireccionar (usar 302 por el bien de SEO ) a las páginas de AMP.

Esto puede parecer una especie de regresión a los hábitos del pasado, y estaría en lo cierto al pensarlo. La redirección ralentizará un poco el viaje, aunque AMP es valioso por sus optimizaciones en la página así como por su respuesta HTTP / tiempo de transporte. Antes del advenimiento y el cenit actual del diseño web receptivo, así es como se atendería a los usuarios de dispositivos móviles, especialmente en los días de WAP. Los sitios web mob.website.com una versión mob.website.com dispositivos móviles servida en un subdominio como mob.website.com o m.website.com . Hubo sabores de los dispositivos móviles de orientación XHTML, que todavía utilizan Google+ para sus páginas "básicas" (tenga en cuenta el DOCTYPE ). Estas páginas "básicas" están reservadas para dispositivos de baja resolución de pantalla, como podemos ver en esta línea:

<link rel="alternate" media="only screen and (max-width: 640px)" href="/app/basic/+SOME_PAGE">

Este enfoque puede haber servido incluso de inspiración para AMP.

Es de esperar que una práctica de redireccionamiento similar no presente una dificultad para usted, porque probablemente tenga la intención de usar amp.website.com o tal vez un subdirectorio para sus páginas AMP de todos modos.

Dado que todos los sitios web deben ser receptivos de todos modos, en términos de SEO y debido a que la focalización solo en dispositivos móviles es más difícil debido a la falta de fiabilidad de las técnicas de redireccionamiento y el uso de agentes de usuario y tipos MIME como método de detección, es posible que Estimar la velocidad de conexión o la ubicación física del visitante.

Entonces, si la velocidad de conexión es baja, o si el usuario se encuentra lejos de su servidor de origen, sería mejor redirigirlos a la página de AMP (ya que se sirve desde CDN de Google y utiliza HTTP / 2 + caché pesado para servir contenido más rápido).

Sin embargo, cualquier CDN se puede usar para todas las páginas para entregarlas más rápido a todo el mundo, no solo a usuarios de conexión lenta o personas ubicadas lejos de su servidor de origen; El objetivo de AMP es solo entregar contenido a través de CDN y quizás más acerca de cómo servir páginas construidas de manera responsable a dispositivos que son bien conocidos por sus tiempos de ejecución de JavaScript, como los teléfonos móviles.

En última instancia, no aplicaría una redirección para todos los usuarios de dispositivos móviles. Dejaría que Google ordene a los visitantes que llegan a través de su motor de búsqueda que se envíen a las páginas de AMP. Si AMP se va a poner de moda y será un producto de larga duración, los navegadores lo implementarán eventualmente.

Ahora que lo pienso, si está entregando contenido a dispositivos móviles, podría ser irresponsable servir páginas AMP a personas que usan dispositivos anteriores de Windows Phone o Blackberry cuyos navegadores ni siquiera admiten adecuadamente AMP .

Hay mucho en qué pensar, pero espero haber respondido a su pregunta, y si no, al menos algunas consideraciones a tener en cuenta antes de decidir la respuesta correcta para su producto.

Para obtener más información sobre sitios móviles separados, puede leer esta documentación sobre el tema proporcionado por Google.

Para obtener ejemplos de cómo configurar su servidor web para detectar agentes de usuario móviles y enviarlos a un subdominio diferente, puede encontrar artículos o ejemplos de código con bastante facilidad si los busca.

Solo por completitud, utilicé el siguiente redireccionamiento para servir páginas AMP a ciertos agentes de usuario, es un .htaccess para un servidor web Apache con mod_redirect habilitado:

<IfModule mod_rewrite.c> RewriteBase / RewriteCond %{REQUEST_URI} !/amp/$ [NC] RewriteCond %{HTTP_USER_AGENT} (android|blackberry|googlebot/- mobile|iemobile|iphone|ipod|/#opera/ mobile|palmos|webos) [NC] RewriteRule ^([a-zA-Z0-9-]+)([//]*)$ https://www.yoursite.com/$1/amp/ [L,R=302] </IfModule>