Google quiere saber qué tipo de información existe, cómo acceder a ella y cómo presentar esa información en una variedad de dispositivos (movil, PC, tablets, TV, etc) y en una variedad de formatos, y Google no quiere limitarse solo a la presentación visual en un navegador como lo hemos conocido hasta ahora.
Los buscadores (Google, Bing, Yahoo…) tienen problemas a la hora de rastrear la web para indexar y clasificar el contenido es una tarea mucho más grande de lo que pensamos.
El Javascript puede estar afectando tu clasificación orgánica en Google
Creo que muchas webs tienen una desventaja en confiar en la indexación JS.
Uno de los problemas a los que se enfrenta un rastreador actualmente es: el código JavaScript, aunque ha evolucionado como veremos, algunos estudios recientes verifican que existen ciertas “desventajas” a nivel de SEO.
Google ha estado hablando sobre la representación de JavaScript y la indexación del DOM resultante durante algún tiempo. Y esto es lo que podemos leer en sus páginas para desarrolladores:
Actualmente, es difícil procesar JavaScript y no todos los rastreadores de buscadores pueden procesarlo con éxito o de inmediato. En adelante, esperamos que se pueda solucionar este problema, pero mientras tanto, recomendamos usar el renderizado dinámico como solución alternativa. El renderizado dinámico significa cambiar entre contenido renderizado y previamente renderizado del cliente a determinados tipos de user-agent.
Según el propio Google, el renderizado dinámico lo tratan así:
Este es el proceso de rastreo que realiza Google cuando se encuentra con una página que utiliza JavaScript :
Google tiene un proceso de indexación de dos fases, donde inicialmente rastrean e indexan el HTML estático, y luego regresan más tarde cuando hay recursos disponibles para representar la página y rastrear e indexar contenido y enlaces en el HTML representado.
El propio Google admite que tiene “ciertas dificultades” aún con el código JavaScript.
El robot de Google pone todas las páginas en la cola de renderizado, a menos que en el encabezado o la metaetiqueta robots de una página se indique que no debe indexarse. Las páginas suelen permanecer en esta cola durante unos segundos, aunque a veces podrían estarse algo más de tiempo. Una vez que los recursos del robot de Google lo permiten, un Chromium sin interfaz gráfica renderiza la página y ejecuta el JavaScript.
Debes saber que Google ejecuta JavaScript siempre con la versión más reciente de Chromium.
También existe el riesgo de que una página tarde demasiado en procesarse debido a la carga excesiva de JS, y por tanto, los elementos la página no se verán ni se indexarán.
Herramienta para comprobar si tu web carga correctamente los JavScript:
Utiliza la herramienta de renderizado de Google dentro de la Consola de Búsqueda.
- Introduce la url que deseas testear.
- Haz clic en “Ver detalles”
- Baja hacia abajo en esa página hasta ” Mensajes de la consola de JavaScript”
- Haz clic en “Mostrar detalles” y ahí comprobarás los JS que Google tiene problemas.
Google te dará una serie de advertencias, como por ejemplo si estás bloqueando algún recurso que impide el renderizado de la url. Es bueno conocerlo porque podría incidir de manera considerable sobre cómo Google entiende la página.
Algún estudio realizado en los últimos dos años indica que los tiempos de espera para cargar el JavaScript de una página están determinados mediante programación (presumiblemente en función de la importancia de la página y la dependencia de JavaScript) y que pueden estar vinculados al código fuente exacto de una función HMAC.
Sin querer alargar mucho más este tema sobre el JavaScript, solo termino con una cuestión:
Si Google rastrea enlaces generados por JS, ¿sabemos si esos enlaces pasan PageRank?
Sabemos que el rastreo de JavaScript es MUCHO más costoso para Google, en comparación con el rastreo de sitios web HTML / CSS simples.
Solo puedo adivinar que descargar JavaScript externo es un coste adicional para Googlebot.
Cuando las webs agregan contenido nuevo a sus sitios web, no eliminan contenido antiguo.
El propio Google nos ha condicionado a desconfiar en eliminar el contenido de nuestros sitios web, presumiblemente porque mantener un archivo antiguo puede ser útil aún o la mejor opción para los usuarios, pero también en el caso de que ese contenido antiguo tenga enlaces, acciones sociales u otras señales que lo ayuden a continuar impulsando tráfico.
Para mantenerse al día de todo el contenido que se genera en Internet, Google deberá ser más eficiente en sus procesos de rastreo, renderización e indexación de urls.
En estos últimos meses han indicado una fuerte preferencia por clasificar señales como Schema y otros micro-formatos porque:
- Simplifica el rastreo
- Disminuye el esfuerzo algorítmico
- Minimiza los gastos generales que Google necesita para continuar indexando y clasificando contenido.
Ahora, con el modelo Mobile-First Indexing, factores como estos serán aún más importantes para Google.
Mobile-First Indexing alude a un futuro que depende menos de las URL como mecanismo de organización para el índice de Google.
Debes comprender que los índices son esencialmente solo bases de datos.
Google ha usado URL y estructura de URL, junto con metadatos y enlaces para organizar el contenido en su índice, por lo que los SEO siempre han aconsejado
trabajar máximo una URL para cada pieza de contenido.
Internet está cambiando: es mucho más grande que un navegador
Internet es en realidad mucho más grande y contiene mucha más información que no se puede presentar en un solo navegador.
El “Internet de las cosas” contiene enormes cantidades de datos y Google quiere poder aprovechar esta información en su algoritmo.
Por ejemplo:
Google Now , el contenido lo proporciona en feeds y API, sin incluir necesariamente una página web o URL .
Si obviamos el tema de URL, el contenido de las aplicaciones (apps)puede competir con los sitios web, lo que brinda una experiencia de usuario mucho mejor que tiene mucha más flexibilidad en términos de cómo y dónde se puede presentar la información a los usuarios.
La indexación móvil primero permite a Google más cosas
Muchas de las nuevas técnicas de desarrollo orientadas a dispositivos móviles que Google ha estado promoviendo en realidad restan importancia a las URL, la estructura del sitio y los enlaces.
Cosas como aplicaciones nativas, aplicaciones web, PWA o AMP oscurecen el acceso de Google a URL y datos de enlace.
El contenido de AMP
El contenido AMP que muchas webs están mostrando a través de los dispositivos móviles, no tiene URL tradicionales, sino que vive en una URL que Google genera y aloja.
Y se espera que Android Instant Apps, que acaba de salir de la versión beta, sea la misma.
Google anunció inicialmente aplicaciones instantáneas en la conferencia anual de desarrolladores de E / S de la compañía en mayo de 2016.
En la misma conferencia del año siguiente, Google puso a disposición aplicaciones instantáneas para todos los desarrolladores de Android.
La indexación en la aplicación, los URI vinculados (Identificador de Recursos Uniforme) son básicamente solo marcadores en el flujo de usuario de una aplicación.
Del mismo modo, las PWA (Aplicación Web Progresiva)aprovechan la comunicación continua con el servidor para entregar contenido cuando se solicita, y no se necesitan diferentes URL para activar contenido diferente.
Parece que Google ahora está trantando de evitar que se confíe en las URL como el principal principio de organización en su índice.
Schema, marcado estructurado de páginas y feeds XML
Desde la actualización de Hummingbird, Google se ha centrado en entidades, la búsqueda por voz y la comprensión semántica del contenido.
El marcado de esquema es mucho más fácil de rastrear y comprender para Google que el HTML normal, y con la transición a JSON-LD, se ha vuelto aún más rápido porque está separado del código de la página y está disponible directamente desde el servidor.
Google está muy interesado en Schema que ahora incluso solicitan que se agreguen ciertos tipos de Schema en el marcado de las aplicaciones.
Esto por sí solo ya es bastante revelador sobre el futuro.
JSON-LD
JSON-LD es importante para que Google comprenda mejor el mundo.
El ‘LD’ en ‘JSON-LD’ significa ‘Datos vinculados‘ porque JSON-LD no se trata de piezas individuales de metadatos, sino que se trata de metadatos en el contexto de otros metadatos.
JSON-LD.org explica que:
“Los datos vinculados capacitan a las personas que publican y usan información en la Web. Es una forma de crear una red de datos legibles por máquina basados en estándares en todos los sitios web. Permite que una aplicación comience con una pieza de Datos vinculados y siga enlaces incrustados a otras piezas de Datos vinculados que se alojan en diferentes sitios en la Web ”.
Así es como Google planea construir una comprensión más profunda del contenido y las relaciones de contenido sin depender tanto de los enlaces y URLs.
Los snippes enriquecidos que vemos cuando hacemos una consulta sobre el tiempo, los vuelos , los hoteles o los productos que se muestran de Google Shopping son fuentes de información directas a las que Google ha pedido esa colaboración, y por supuesto, estas se benefician.
Los resultados de estas fuentes parecen mostrarse favorables en los resultados de búsqueda móvil, ya que proporcionan una buena experiencia de usuario, pero también porque son fáciles de analizar y mostrar rápidamente por Google.
Mobile cloud-first a largo plazo
Parece que Google Play está alentando activamente a los desarrolladores de aplicaciones de Android a probar el alojamiento de sus aplicaciones en Google Cloud Platform para que los usuarios puedan beneficiarse de una experiencia de aplicación nativa más rápida.
Es posible esperar que el alojamiento en la nube con Google sea fuertemente incentivado o incluso requerido en el futuro.
Ahora mismo puedes crear una web en WordPress y alojarla directamente el Google Cloud Platform y aprovecharte de “estar ya en Google”.
Puedes crear desde una web corporativa hasta una tienda online que espera generar mucho tráfico.
Google empujará más y más usuarios a su nube porque les permite disminuir su dependencia del rastreo y aumentar su comprensión de cómo los usuarios interactúan con el contenido.
Creo que este es un gran movimiento estratégico de Google para ahorrar tasa de rastreo y optimizar sus recursos entre otras ventajas.
Una vez que el contenido está alojado en la nube de Google, y sin depender de las URL para la indexación, el contenido indexable puede ser:
- texto
- vídeo
- audio
- imagen
- cualquier otra cosa
Beneficios de Google Cloud Hosting para el buscador
- Menor rastreo: el alojamiento es mucho más eficiente y efectivo que el rastreo. Si Google aloja el contenido en la nube, no tiene que rastrearlo de forma tan agresiva, y puede saber de inmediato cuando se realizan las actualizaciones de las páginas o se crea contenido nuevo. Incluso a través de las solicitudes pueden saber qué contenido es más popular, ¿interesante verdad?
- La recopilación de datos es más eficiente: Si el contenido está en la nube de Google, puede ser súper rápido entregarlo. Pueden utilizar mejor la compresión el almacenamiento en caché para ofrecer el contenido más rápido y adaptado a cualquier dispositivo.
- Flexibilidad del contenido: el desarrollo y almacenamiento en la nube, permite a los desarrolladores mayor flexibilidad a la hora de crear interfaces personalizadas sin tener que pensar en el tipo de dispositivo y evitando replicar el trabajo.
Si Google tuviera que rastrear e indexar contenido que esta vinculado a dispositivos específicos una y otra vez para cada dispositivo, indexando y clasificando todo, sería una pesadilla.
Conclusión
A medida que más dispositivos diarios se conectan, se vuelven menos dependientes de las pantallas, los navegadores y los teclados de entrada directa, y en su lugar, todos se operan de forma remota desde la nube.
Tanto Amazon Echo como Google Home permiten controlar los elementos de una casa conectados a la web y realizar búsquedas simples utilizando solo la voz, y todos responden en función de la transmisión de datos desde la nube.
Estos dispositivos pueden y funcionan sin el uso de URL, por lo que Google también debe comenzar a trabajar de una manera más independiente a lo que estamos viendo ahora.
Nuestros dispositivos dejan de necesitar navegadores, por lo que en un futuro el índice de Google no debe organizarse en función de las URL.
Los datos estructurados, el JSON-LD, los XML feeds y la API de Google, son claves para que el gran buscador comprenda mejor al mundo y sea más eficaz. ?Estas trabajando con ellos?
Te puede interesar saber:
- Como implementar la búsqueda por voz en tu web
- Como diseñar una página web siguiendo las reglas de Google
Acerca del autor
SEO Mánager en ginesmayol.com . Ayudo a empresas y marcas a posicionarse en Google. Presidente de la Asociación de MKT Digital de la Región de Murcia. Creo estrategias de Adquisición de tráfico para empresas y marcas nuevas. Hago deporte a diario y me gusta todo lo relacionado con el medio ambiente y el estilo de vida sencillo y saludable.
