Google no quiere que enlaces a la versión AMP de una página sino a su versión (móvil) original

Las páginas AMP son un projecto de Google Google AMP (Accelerated Mobile Pages) para acelerar la búsqueda en dispositivos móviles ofreciendo al usuario una versión optimizada del contenido original eliminado elementos innecesarios como scripts o extensiones.

El sistema AMP funciona de la siguiente manera. Cada página AMP tienen en realidad tres URL: La versión original del sitio, que suele ser la url (de la versión móvil si el sitio tiene distintas URL para los móviles) con /amp al final, la versión cacheada del documento, que no se muestra, y la versión que muestra Google con su URL de la siguiente manera: www.google.com/amp/www.example.com/amp/doc.html

Google muestra en los resultados la versión cacheada de la página desde sus propios servidores, añadiendo delante www.google.com/amp, para mejorar la rapidez y la seguridad.

Esto molesta a muchos editores que lo ven como un robo del contenido. Además, a la hora de compartir la página en Twitter o en otras redes sociales, la URL es la de Google, aunque se redirige la URL a la original de la página.

Pero esto funciona si Google mantiene el sistema tal cual. Si en un futuro lo cambia, dejará de funcionar.

Para evitar esto, Google ha actualizado la forma en la que muestra los resultados AMP, añadiendo una cajón debajo de la URL del navegador con el enlace original para copiarlo a la hora de compartir.

No enlazar a la versión AMP

Con esta actualización, Google facilita los enlaces hacia las páginas originales y no hacia sus propias URL. Además, un factor importante para el usuario es poder ver la URL del resultado que quiere como factor de credibilidad. En la versión AMP ofrecida por Google se ve primero la URL de Google.

Este icono de la cadena aparecerá cuando el navegador no disponga de una aplicación nativa para compartir. Chrome de momento no la tiene, pero acabará implantándola, también en sus apps. También asegura que está mirando formas de adaptar su Web Share API para los usuarios que la usen.

Pero quienes están acostumbrados a copiar la URL del navegador seguirán compartiendo URLs de Google.

Más información de Google sobre esta actualización y las páginas AMP.

Qué cambiar primero: de HTTP a HTTPS o la estructura de las URL

Cambiar la estructura de las URL es una de esas cosas que deberíamos evitar siempre que sea posible, pero a veces es inevitable. Y ya que cambiamos las URL, aprovechemos para pasar a https.

¿O es mejor empezar por cambiar a https y después la estructura de las direcciones? ¿O todo a la vez?

Según JonhMu, ya que te pones, es mejor hacerlo todo a la vez, porque el resultado va a ser el mismo:

Pero como el resultado va a ser el mismo, es mejor considerar algunas cosas antes de saltar. Para Google, el cambio de protocolo de HTTP a HTTPS es algo sencillo, porque solo cambia una parte y todo el resto permanece igual.

Cambiar la estructura de la URL, cómo se forman las direcciones web, puede ser algo más complejo, ya que tiene que volver a entender cómo va toda la estructura, y eso le lleva más tiempo.

¿Cuál es el mejor orden para cambiar la dirección de las páginas?

Desde el punto de vista del SEO da lo mismo. El resultado final va a ser el mismo. Google dice que so van a cambiar ambas cosas, hazlo todo a la vez y ya acabas con ello y te olvidas.

Desde el punto de vista técnico, sobre todo para webs grandes o complicadas, yo primero cambiaría la estructura por una sencilla razón: para asegurarme que no hay errores. Cambiar todo a la vez puede ser una pesadilla si empiezan a ocurrir errores.

Primero cambia la estructura URL, comprueba durante un tiempo que no hay errores, y luego simplemente añade el HTTPS.

IMDb cierra su sección de comentarios

IMDb ha tomado la decisión de cerrar sus foros en base a los datos y al tráfico. Por lo visto, la sección de comentarios ha dejado de ser útil para la mayor parte de sus 250 millones de usuarios alrededor del mundo.

A pesar de la dudosa calidad del sistema de comentarios de IMDb, feos e incómodos de usar, y la baja calidad de las aportaciones en general, a la altura de los comentarios de YouTube, es una decisión que parece sorprendente.

Primero, porque aunque la mayoría de los comentarios son lamentables y campan a sus anchas un número de trolls más elevado de lo habitual por permisividad y falta de moderación, existe un grupo sólido de usuarios que llevan muchos años aportando contenido interesante y que aporta valor, y segundo, porque más allá de consultar la altura o el estado civil de algún actor no hay mucho más que hacer en la página. Quizá las críticas.

En la nota de prensa añaden que seguirán comprometidos con nuevas e innovativas formas de atraer y enganchar a sus usuarios y para que se expresen y se relacionen entre ellos de forma significativa. Quizá dejen los comentarios para sus usuarios de pago, lo que en teoría parece que mejorará la calidad de dichos comentarios.

El valor de una web con sección de comentarios

Es un viejo debate la utilidad de los comentarios en una página. ¿Qué beneficios e inconvenientes tienen los comentarios?

Los comentarios sirven para ofrecer al lector una opción más de disfrutar de tu sitio. Son páginas vistas, usuarios recurrentes y una de las mejores formas de fidelizar usuarios. Además, más veces de las que parece lo mejor del contenido, de cara al usuario, está en los comentarios. Si estos son de calidad.

Si no, es una pérdida de tiempo y de recursos, pueden dar mala imagen y a veces incluso un motivo para penalizar todo el contenido por parte de Google.

Yo soy fan de los comentarios para la gran mayoría de páginas. Una web, y un artículo con muchos comentarios da la sensación de ser un contenido con vitalidad.

Redes sociales

Una de las principales motivaciones de comentar regularmente en una web es relacionarte con otros comentaristas. Y eso se está dejando de hacer en páginas concretas para hacerse en las redes sociales. Y esto tiene su impacto en cómo posiciona un post en Google por motivos que no voy a tratar ahora.

La jerarquía o nivel de carpeta de una URL no es importante para Google

La jerarquía de las categorías en las que clasificamos cada página, por ejemplo en menús o breadcrumbs, siempre ha sido un tema relevante a la hora de planificar un sitio de cara al SEO. Tiene que ver con la importancia que queremos dar al contenido de la web. El contenido más importante lo colocaremos cerca de la portada, por ejemplo portada->categoría->URL, mientras el menos importante lo hundiremos dentro de subdirectorios y carpetas.

Pero esto tiene más que ver con la experiencia de usuario más que con el buscador. Según Google, «la jerarquía de una URL no es tan importante para el buscador.»

Con tal de que Google tenga acceso a la URL, es suficiente para que la rankee donde se merezca. Pero esto no quiere decir que no sea importante. Lo primero que tiene que pasar es que Google encuentre la URL, y para ésto, debe estar cerca de la portada, independientemente de su jerarquía dentro de la página.

Por lo tanto, si una URL está en la subcategoría 5 en las profundidades de tu web, basta con que la enlaces desde un nivel cercano a la portada para que la encuentre (lo ideal es mantener las URL importantes en los tres primeros niveles de la web).

La velocidad de página en dispositivos móviles definida por Google

En 2016 la métrica de la velocidad de página se volvió más importante para Google ya que afecta directamente a la primera interacción del usuario con tu página.

¿Qué es la velocidad de página

La velocidad de página mide lo rápido que se cargan los elementos visibles de una web. Esto es, mide el tiempo que le toma al usuario ver e interactuar con una página del sitio. Es un factor crítico para la experiencia de usuario en dispositivos móviles. El 53% de los visitantes desde el móvil abandonan la página si ésta no se carga en menos de tres segundos.

La velocidad de página debe ser una medida centrada en el usuario en cada página individual y mantenerla en cada página con la que interactúe. Si la página es lenta, puedes perder la oportunidad de mantener al visitante en tu página durante más tiempo.

Google ha creado una infografía sobre la velocidad de página móvil en referencia a las ganancias que se pueden obtener de la publicidad, el sitio, las estadísticas y el usuario. Los puntos que destaca son:

  • La velocidad media de carga de una página por 3G es de 19 segundos. El 77% tarda más de 10 segundos.
  • El peso medio de página es de 2.5 MB, lo que tarda 13 segundos en cargarse por 3G
  • Cada página móvil tiene una media de 214 conexiones con el servidor, y casi la mitad tienen que ver con la publicidad
  • Las páginas que cargan en 5 segundos obtienen el doble de beneficios por publicidad que las que tardan 19 segundos.
  • Una página que carga rápido consigue unas sesiones de usuario el 70% más largas
  • Las páginas rápidas tienen un 35% menos de tasa de rebote
  • Las páginas rápidas tienen un 60% más de páginas vistas

Los usuarios:

  • El 50% esperan que la página cargue en dos segundos o menos
  • El 46% dice que lo que menos les gusta es tener que esperar a que la página cargue
  • Si tu página tarda más de dos segundos en cargar no estás cumpliendo con las expectativas del usuario
  • Los usuario frustrados por una página lenta son menos propensos a buscar más contenido en tu página, incluso si esperan hasta que la primera página cargue

Qué hacer si te han hackeado la web según Google

Google ha publicado una guía de pasos actualizada para ayudar a los webmasters que han sido hackeados a recuperar su web.

Si alguna vez te has encontrado con algo de esto al buscar contenido de tu página, es posible que hayas sido hackeado:

Estos son algunos de los ejemplos que usa Google para avisar a los buscadores de que el contenido de una página está comprometido.

El siguiente vídeo explica lo que es el hacking tratando los siguientes puntos:

  • Cómo y porque se hackean las webs
  • El proceso de recuperar tu web y eliminar los avisos de contenido malicioso de los resultados
  • Tiempo aproximada de recuperación de una web hackeada (un día o así para phising, varias semanas para spam)
  • Arréglalo tú mismo o contrata a un profesional

Google ofrece una lista de 7 puntos a la hora de tomar acción para arreglar el hacking:

  1. Junta un equipo de soporte, empezando por tu hosting
  2. Por tu sitio en cuarentena para evitar que el hacker siga haciendo daño
  3. Utiliza la consola de búsqueda para determinar el tipo de hack
  4. Determina el daño I. Para spam, determina qué debe arreglarse
  5. Determina el daño II. Para malware, determina qué debe arreglarse
  6. Identifica la vulnerabilidad
  7. Limpia y realiza labores de mantenimiento de tu web
  8. Solicita una revisión a Google para que elimine el aviso

Qué es el Crawl Budget para Googlebot

El Crawl Budget es un concepto aparentemente sencillo que según John Mueller de Google: «es uno de esos mitos que se oyen mucho sobre todo los SEO y webmasters acerca de cómo definen y entienden el rastreo por parte de los robots de Google. En Google no tenemos esa noción de Crawl Budget de la que la gente habla».

Añade también que la gran mayoría de las webs no tienen que preocuparse por el Crawl Budget. Solo esas páginas que generan un número infinito de páginas deberían considerar cómo sus servidores pueden lidiar con la carga. Una página de un tamaño razonable no debería ocultar enlaces internos, añadir etiquetas noindex o enredar con las direcciones canonical. Solo webs con bastantes miles de páginas o que generen un exceso de ellas deben considerarlo. Pero la mayoría no necesitan ni siquiera pensar en eso.

Quizá por eso Google ha publicado una entrada explicando de forma concisa lo que es el Crawl Budget. Básicamente es la tasa de rastreo y la demanda de rastreo juntas (crawl rate and crawl demand together).

«Considerando a la vez crawl rate y crawl demand definimos el crawl budget como el número de URLs que Googlebot puede y quiere rastrear»

Crawl rate limit define cuánto quiere Googlebot rastrear tus páginas para no sobrecargar el servidor y perjudicarlo. Es «el número de conexiones paralelas que Googlebot puede usar para rastrear tu sitio, así como el tiempo de espera entre peticiones». Google no rastreará tanto como para tirar tu servidor y respetará el límite que pongas en la consola de búsqueda.

Crawl demand es la demanda de Google para rastrear tus páginas, nuevas y viejas. La demanda se determina por la popularidad de tu sitio y tus URLs, y la necesidad de Google de prevenir que el contenido quede obsoleto en su index. Esto significa que aunque tengas tasa de rastreo por gastar, si la demanda no requiere más rastreo, Googlebot no seguirá rastreando.

Junta ambos conceptos y tienes el Crawl Budget, o lo que es lo mismo, lo que Google rastreará tu página.

Qué afecta negativamente al Crawl Budget

El Crawl Budget se ve afectado negativamente por los siguientes motivos:

  • Navegación con filtros e identificadores de sesión
  • Contenido duplicado dentro de la página
  • Soft errors
  • Páginas hackeadas
  • Espacios infinitos y proxies
  • Contenido de baja calidad y spam

La tasa de rastreo (Crawl Rate) no es un factor del ranking. Una tasa de rastreo elevada no significa necesariamente mejores posiciones en los resultados. Google usa cientos de factores en sus rankings, y mientras el rastreo es necesario para aparecer, no es un factor.

Con esto parecen despejadas las dudas y mitos alrededor de este tema. Pero como punto de partida, si ves en la consola de búsqueda de Google un descenso en el rastreo (en general), considera que algo puede estar fallando.

Matt Cutts deja Google de forma oficial


Matt Cutts, uno de los 100 primeros empleados de Google y cabeza visible del buscador durante muchos años para los webmasters por ser el responsable máximo de la calidad de búsqueda de Google – más familiarmente como el encargado del spam -, deja Google de forma oficial para trabajar como director de ingeniería para el servicio postal digital de EEUU (US Digital Service).

Cutts se tomó un descanso de Google en 2014, que fue ampliando, hasta que el 31 de diciembre de 2016 dejara definitivamente de ser empleado del buscador. Empezó a trabajar para el servicio postal americano a mediados del 2016 y ha decidido seguir, quizá influído por un reciente ascenso.

Según sus propias palabras:

Working for the government doesn’t pay as well as a big company in Silicon Valley. We don’t get any free lunches. Many days are incredibly frustrating. All I can tell you is that the work is deeply important and inspiring, and you have a chance to work on things that genuinely make peoples’ lives better. A friend who started working in this space several years ago told me “These last five years have been the hardest and worst and best and most rewarding I think I will ever have.”

Matt Cutts marca el fin de una era, de alguna forma, para los seo que buscábamos en sus vídeos de YouTube respuesta a muchas preguntas y dudas que existían por aquellos tiempos. Quizá vuelva un día, pero parece difícil.

Marissa Mayer deja Yahoo

Por otra parte, Marissa Mayer, una de las personas favoritas de Google por esta web, deja Yahoo, que pasará a llamarse Altaba.

Marissa Mayer dejó Google en 2012 para encargarse de Yahoo después de que varios CEO fracasaran en su intento de revivir el buscador. Si bien el objetivo de dar más relevancia a Yahoo búsquedas ha fracasado, parece que ha dejado a la empresa en una situación buena desde el punto de vista económico tras varias ventas y cambios diversos.

Claramente las cosas cambian, no se si termina una era o hace tiempo que terminó, pero este 2017 promete en cuanto a Google.

Google intenta lanzar simultáneamente en todas las regiones sus actualizaciones del algoritmo

Hasta no hace mucho Google aplicaba primero las actualizaciones de su algoritmo en unas regiones y después las iba extendiendo a otras. Generalmente empezaban en EEUU y se iban extendiendo al resto de países. En ocasiones se basaba en los idiomas del buscador, en función del tipo de actualización, si se centraba en el contenido o en los enlaces.

Según Gary Illyes, ahora Google intenta lanzar todos estos cambios de forma simultánea en todos los sitios:

El tema está en saber qué significa «intentar» y si tiene algún efecto nuevo o si siempre ha sido más o menos así.

El comando «site:» muestra los resultados sin ningún orden concreto, según Google

El comando site: (por ejemplo, las páginas indexadas en google de adseok site:adseok.com) para mostrar las páginas indexadas de un dominio no muestra los resultados en ningún orden concreto, según Google, aunque suele mostrar primero el nombre de dominio y después las categorías y demás secciones antes de las páginas y posts individuales.

En el 2011, Matt Cutts comentó que primero se mostraba el index y después había ciento orden en los resultados, pero ahora John Mueller dice en Google Hangouts que np hay ningún orden específico ya que se trata de una «búsqueda artificial». En el vídeo en el minuto 39:

Transcripción de la pregunta:

– Cuando uso el comando site: ¿muestra Google los resultados en algún orden en particular?

-No, realmente.

Solemos mostrar la portada del dominio en primer lugar. Pero esta búsqueda es muy artificial y no existe un orden bien definido a la hora de mostrar los resultados de la petición. Pero si añades algún término al comando site entonces es más fácil porque existe algo que tioene que ver con los rankings. Pero el operador por si solo, yo no sacaría ninguna conclusión del orden mostrado.