Este artículo es un resumen que hemos hecho Christian Oliveira y yo de la charla que dimos en el Congreso Web (consigue aquí las diapositivas), donde pretendemos explicar esta tecnología (PWA) y cómo tenemos que lidiar con ella SEOs y desarrolladores para hacerla accesible a los buscadores. Nos basamos en la experiencia con clientes que usan frameworks y librerías JavaScript como Angular o React, en sitios JS de conocidos que se han cedido a que analicemos sus casos y en experimentos que hemos hecho para ver cómo los tratan los buscadores.
A día de hoy existen diversas soluciones para resolver las necesidades de los usuarios en móviles. Por ejemplo, en elmundo.es, si quieren ofrecer una experiencia satisfactoria a todos los usuarios que consumen sus noticias, tienen que asegurarse de poder servir cada página correctamente en diferentes ecosistemas: versión mobile y desktop (con Dynamic Serving), APP (para navegación offline, notificaciones push y navegaciones más fluidas), AMP (por el requisito de aparecer el carrusel) y Facebook Instant Articles (el AMP de Facebook).
Como veis, son muchos ecosistemas que se han de mantener a parte de la web y esto es costoso y poco escalable para todos los negocios. Si hablamos de las APP nativas, éstas son las que más dolores de cabeza ocasionan en todos los aspectos:
Otro tipo de solución que existe a día de hoy para resolver las necesidades complejas y con una carga de interacción más fuerte en móvil, son las Web APP Mobile (en un m. por ejemplo). Estas tienen una serie de inconvenientes:
Por suerte, a día de hoy existe una nueva solución de desarrollo propuesta por Google, que tiene lo mejor de todos los mundos, las Progressive Web APPs (PWA).
Una PWA es una página web que funciona para todos los usuarios y todos los dispositivos, pero manteniendo la experiencia fluida de una APP. Esto es una gran ventaja en webs con interacciones complejas. Por ejemplo, Twitter e Instagram, si entráis desde el móvil, en realidad estáis entrando en una PWA y no en su web. Ya no tiene sentido tener instalada estas aplicaciones consumiéndote recursos y datos en segundo plano, puedes añadirte la página al escritorio de tu móvil y tendrás Twitter o Instagram totalmente funcional. Además, parece que Twitter está pensando en abandonar el desarrollo de su APP, así como Starbucks. Entiendo que esperarán a que más gente se la añada al escritorio y que los números le sigan yendo tan bien.
Entre las ventajas de las Progressive Web APPs a destacar se encuentran:
No digo que las PWA sean mejores que las APP nativas, pero tienen ventajas que harán que, en muchos casos, la gente no se decida por desarrollar una APP nativa.
Las PWA tienen un First Contentful Paint (FCP) más rápido que una web normal y siguientes interacciones más rápidas y fluidas como en una APP. Punto a tener muy en cuenta ya que la velocidad de carga es el elemento de UX más importante para el 75% de los usuarios conforme este estudio de Google. Resulta que, las webs lentas, estresan más que una película de miedo (liberan más cortisol según este estudio de Ericsson ConsumerLab) y esto hace que puedas llegar a perder el 53% de tus usuarios si tu web móvil tarda más de 3 segundos en cargar según este otro estudio de Google y SOASTA.
Las Progressive Web Apps están hechas con Frameworks y librerías JavaScript que se están estandarizando porque facilitan la tarea de creación de entornos web. Este enfoque de desarrollo tiene las siguientes ventajas:
Como consecuencia de sus ventajas, este nuevo paradigma ha llegado para quedarse, así que a los SEOs y a los buscadores nos toca amoldarnos a él, porque el crecimiento es imparable.
Según la encuesta anual de Stack Overflow que hicieron a 64.000 desarrolladores, JavaScript es el principal lenguajes de programación y Node JS, Angular y React JS se encuentran entre las cinco tecnologías de desarrollo más usadas a día de hoy.
Una PWA es una SPA (Single Page Aplication o Multiple Page Aplication) a la cual se le hacen dos añadidos que son los que les brindan todas sus virtudes, el service worker y el manifest.
El service worker es la magia de las PWA. Es el que permite la sincronización en segundo plano, la conectividad offline y las notificaciones push.
Funciona a nivel de controlador y se sitúa entre el cliente y navegador. Se encarga de decirle a la caché del navegador que guarde archivos a los que se ha accedido para que, luego, la caché los mande al cliente sin necesidad de pasar de nuevo esa petición por el servidor (por eso son offline).
El manifest es un fichero pequeñito en formato JSON que se declara en el head del documento HTML. Entre otras cosas, la funcionalidad principal de este fichero es la de permitir que la PWA se pueda instalar en el escritorio para que parezca una APP.
Con la herramienta PWA Builder de Microsoft podrás crear fácilmente un manifest y un service worker para tu web. Y si queréis saber más sobre cómo crear una PWA, en Google tienen un tutorial muy completo.
A día de hoy todos los navegadores soportan PWA, pero no todos los navegadores soportan todas las funcionalidades de las PWA. Por suerte, esto está cambiando rápidamente como podréis ir consultando en Can I use.
A día de hoy sólo Google y ASK renderizan JS en cualquier Framework de forma decente. Baidu ha anunciado que también lo hace, pero según las pruebas que hemos hecho, parece que tiene bastante menos éxito de momento. Con lo cual, si vuestro negocio está en EEUU, Rusia o China, no podemos depender de que Bing, Yahoo, Yandex o Baidu rendericen el JS y tendremos que, sí o sí, entregarles el contenido pre-renderizado y que ningún texto y/o link interno dependa de JS para ser visualizado.
Cuando hablamos de las habilidades de un buscador para renderizar JS, se suelen hacer este tipo de pruebas erróneas que veis en la imagen siguiente. Como veis, el número de páginas indexadas varía en cada uno de estos buscadores. Esto se hace con un «site:» sobre un sitio que depende de JS para poder ser visualizado y rastreado:
Que el buscador tenga un número X de URLs indexadas no demuestra que las haya descubierto al renderizarlas, ni que sea capaz de ver 100% el contenido que hay en ellas.
Si por ejemplo probáis a buscar algunas cadenas de texto de preactjs.com en los diferentes buscadores, veréis que en algunos casos sólo Google y ASK han sido capaz de verlo.
Entonces, si las PWA se están poniendo tan de moda y cada vez más sites utilizan JS, ¿por qué no todos los buscadores renderizan JS? Muy sencillo; porque es muy costoso (y por lo tanto, caro).
Según un estudio hecho sobre los top 500 sites de archive.org, el 50% de las webs tardan una media de 14s en permitir al usuario interactuar en mobile (TTI), lo cual es muchísimo.
Aquí es importante entender que por ejemplo 170 KB de JS no son lo mismo que 170 KB de una imagen; aunque el navegador tarde más o menos lo mismo en descargar ambos ficheros, la imagen se visualiza de forma súper rápida (en cuestión de milisegundos), mientras que el JS además de descargarse tiene que ser parseado, compilado y ejecutado por el navegador, consumiendo recursos y tardando más tiempo.
Para que os hagáis una idea del coste que puede tener para un crawler, aquí tenéis unos datos que ahrefs ha compartido. Cada 24 horas:
Si echáis cálculos por cada página que renderizan, crawlean unas 200. Según ellos mismos, si decidiesen crawlear y renderizar todas las URLs que tienen en su base de datos a este ritmo, estiman que necesitarían entre 10000 y 15000 servidores más (entre 20 y 30 veces más), así que imaginaos el gasto que puede suponer a nivel de empresa en máquinas, electricidad, mantenimiento…
Debido a ese alto coste que existe en renderizar JS, aquí entra otro factor: Google no puede esperar indefinidamente hasta que una página termine de renderizar.
Aunque ya han dicho en Twitter que no hay un tiempo máximo definido, a raíz de varios experimentos que hemos hecho lo ideal es que tarde menos de unos 5 segundos.
Esto lo descubrí porque tenía que ocultar un popup y un modal selector de idioma para que Google no los considerara intrusivos. Lo que hice fue cargarlos después del document ready para que no aparecieran en el DOM y les iba aplicando segundos de delay. Al final observé que con 5 segundos dejaron de aparecer en el render y en la caché de Google. Pero si te quieres asegurar, mejor que carguen tras una interacción del usuario, así te aseguras que no lo ejecute Google.
¡Ojo! Esto es un número orientativo, que puede variar por website y/o a lo largo del tiempo (Lino ha comprobado que puede ser más). Si queréis tener la certeza de que Google está siendo capaz de renderizar y ver todo vuestro contenido, además de comprobarlo a nivel de indexación, lo mejor es ver si es así en la Mobile-Friendly Test Tool, e intentar que la web renderice lo más rápido posible.
En el último Google I/O, Google confirmó lo que llevábamos bastante tiempo viendo (y que demostraremos de nuevo en un experimento al final del post), que los sitios en JavaScript los indexa en 2 fases.
Si sois frikis como nosotros del IR y la IE, os resultará curioso saber que antes de Percolator (del que ya os hablé aquí), Google hacía uso de MapReduce y Google File System (gracias a los cuales nació Hadoop). Simplificando mucho, antes de esta nueva arquitectura, Google funcionaba en batch y ahora lo hace al vuelo. Esto hace que las páginas crawleadas se indexen prácticamente de inmediato.
El problema viene con los sitios JS, porque tiene que renderizarlos para poder ver qué contenido y links existen para asignar queries a urls, si no, Google se estaría perdiendo una gran parte de la web. Como hemos visto antes, esto es costoso y no puede hacerlo al instante porque eso le haría consumir hasta 200 veces más de recursos tranquilamente. Por ello tiene que indexar los sitios JS en dos fases.
Así que incluyó en la arquitectura de Caffeine un subsistema de WRS basado en Chrome 41 (actualización 08/05/2019, Google ya usa Chrome 74), lo cual tiene implicaciones muy serias a tener en cuenta para nosotros como SEOs y desarrolladores.
Una de las cosas en las que nos afecta y que tenemos que conocer es que las etiquetas canonical, rel=amphtml y el status HTTP, en el fetch inicial y no les da una 2ª oportunidad en el render. Lo del rel=amphtml no tenía ni idea hasta que lo dijo John Mueller.
Sobre el canonical entramos en materia algo más complicada, porque aunque Google afirme con tanta rotundidad y en varias ocasiones que no les da una segunda oportunidad, en algunas circunstancias se está observando que puede llegar a dársela. Aquí otro ejemplo de ello de la mano del bueno de Eoghan Henn. Sinceramente, siempre he sido muy escéptico con el experimento que hizo Eoghan de añadir el canonical con GTM, porque pensé que era el propio Google el que encarpetaba los documentos similares por sí mismo y que lo otro eran coincidencias.
Las veces que lo he probado no me ha salido, y es que realizar experimentos con canonical es harto difícil por varias razones:
Y si llegase a funcionar en algunos casos, esto no quiere decir que esta meta no deba de estar sí o sí en el raw HTML, porque, es la única forma de asegurarnos que lo verá sin problemas (otra cosa es que quiera hacerle caso).
(Actualización 06/06/2018: Google acaba de decir que puede llegar a ocurrir pero que no lo hagamos. Con lo cual sí que les da una segunda oportunidad.)
Por otro lado, si el Noindex, Hreflang y rel=next/prev no están en el raw HTML, Google los leerá en la versión renderizada (les da una segunda oportunidad). Lo del noindex y el hreflang lo pude comprobar hace tiempo, pero no se me ocurrió mirar las metas rel=next/prev hasta que lo mencionó Robin Rozhon en su Twitter. Además lo del noindex, lo acaba de confirmar recientemente Google.
Aquí lo mismo de antes, nos tiene que ser indiferente que les dé una segunda oportunidad, porque el delay que existe entre renderizar e indexar puede llegar a ser muy largo, y durante un tiempo tendremos un montón de documentos que quizás no querríamos tener en el índice, lo que puede afectarnos de forma negativa temporalmente. Así que como buena práctica, a Google y otros bots siempre hay que darle las metas en el raw HTML.
Otro de los puntos en los que nos afecta que Google use Chrome 41, es que tiene dificultades para renderizar webs con funciones más avanzadas a las de esta versión de Chrome. En el caso de querer usar funciones modernas, debemos traducir esas funciones a otras soportadas por Chrome 41.
Saber qué tipos de eventos js y links sigue Google es importante porque las URLs indexadas son las que se tienen en cuenta para evaluar la calidad de un sitio web.
Sabemos que Google rastrea, indexa y pasa PageRank a los links HTML (<a href=…) como confirmó de nuevo en el Google I/O:
<a href="/este-link"> será rastreado </a>
<a href="/este-link" onclick="cambioPagina('este-link')"> será rastreado </a>
<a onclick="cambioPagina('este-link')"> *no será rastreado </a>
<span onclick="cambioPagina('este-link')"> *no será rastreado </span>
*Que no sea rastreado no quiere decir que si alguien enlaza su urls se nos indexe. La mayoría de errores de indexado de filtros viene por problemas de este tipo.
También sabemos que Google rastrea e indexa cualquier cosa que tenga forma de enlace porque quiere descubrir urls, pero no les pasará PageRank (no quiere decir que no aparezcan cuando los busques):
<a onclick="cambioPagina('/este-link')"> será rastreado </a>
<span onclick="cambioPagina('/este-link')"> será rastreado </span>
/este-link será rastreado
Creo que fue hace 7 años, cuando en el Search Console de un cliente se dispararon los 404 coincidiendo con una implementación de páginas virtuales de Google Analytics. Desde entonces, todo lo que tenga forma de URL en el DOM lo meto en el robots.txt, pero mejor es que se modifique el link en el código para que no tenga barra.
Existen otros tipos de eventos que son los onscroll y los onmouseover. Los eventos onscroll los sigue a veces y onmouseover no los sigue.
Si tienes una paginación con onscroll puede llegar a indexarse (sólo las primeras páginas). Otra de las cosas que descubres por casualidad y se agradece que Google lo confirme.
Para comprender las opciones existentes de renderizado, lo más fácil es entender que las PWA son el IKEA de internet.
Con este analogía, el cliente sería nuestro navegador web, e IKEA sería el servidor, y en base a esto tenemos 4 posibles escenarios a la hora elegir el sistema de renderizado:
Cuando hablamos de Client Side Rendering puro, el cliente (navegador web) recibe un HTML inicial en blanco, y es el navegador el que tiene que “crear” el HTML final en base a los recursos y el JS que recibe del servidor:
Esta opción es la que inicialmente utilizaban (y en muchos casos utilizan) los desarrolladores de PWA, y es la que más problemas genera para SEO ya que sin ejecutar el JS y renderizar la página, no hay nada (ni contenido, ni enlaces).
Debido a los problemas de SEO del CSR, y al igual que IKEA, los frameworks de PWA empezaron a desarrollar una nueva funcionalidad, para que sin dejar de tener todas esas funcionalidades de PWA, antes de enviar la información al cliente (navegador) el servidor ejecutase y renderizase el JavaScript desde su lado y se lo enviase al cliente.
De esta forma, el cliente (navegador) recibe un HTML final y que funciona sin necesidad de ejecutar y renderizar el JavaScript. Si tiene JavaScript activado, éste toma el control y el usuario puede seguir navegando/interactuando con la PWA con todas las funcionalidades. Si no tiene JavaScript activado, también, aunque sin todas las ventajas de las PWA.
La tercera opción de renderizado es una combinación de las dos anteriores: parte de la página se envía pre-renderizada desde el servidor, y otra parte se renderiza en cliente.
Un caso de uso muy común del Hybrid Rendering es el de pre-renderizar aquellas partes de la página que se utilizan en toda la PWA (por ejemplo, un menú), y dejar que sea el cliente el que renderice todo aquello que cambia según la página (el contenido específico). En el siguiente ejemplo, la “App Shell” (la zona superior, con azul de fondo) se entregaría pre-renderizada en el servidor (SSR) mientras que la parte de abajo (el contenido) no aparece inicialmente y se renderiza enteramente en el cliente (CSR).
Esta es la opción que veníamos usando los SEOs y que Google acaba de recomendar de forma oficial en su charla del Google IO. Consiste básicamente en… ¡hacer cloaking!
Sí, como lo lees. Lo que han comentado es que si tenemos una PWA cuya visualización depende de la ejecución de JS y su renderizado, si queremos evitar problemas tenemos que asegurarnos de que Googlebot (y otros bots) recibe una versión SSR, y el resto de User-Agents aquella que consideremos mejor (CSR o Hybrid Rendering). De esta forma, Googlebot va a poder ver el contenido y enlaces de cada página sin necesidad de ejecutar JS y renderizar la página. En el fondo, el contenido que ve Google será el mismo que el que verán los usuarios una vez el cliente renderice la página.
Un ejemplo de una web muy grande que está aplicando esto, y que es del propio Google, es Youtube y no le va nada mal. En las siguientes capturas (lo podéis probar directamente con esta tool) podéis ver que al acceder a la URL de un vídeo, si el que lo pide es Googlebot recibe la página con el contenido y enlaces, y si en cambio el que lo pide es un usuario normal, recibe un html incompleto, con un esqueleto pero sin ningún contenido ni enlace:
¿Qué estrategia es preferible entonces en cada caso? Para los usuarios, al menos en la primera interacción, lo mejor es el SSR:
¿Por qué? Muy sencillo. Repasamos cómo funcionan estas dos técnicas:
Esto ocasiona que:
Como podéis ver en esta imagen de las pruebas realizadas por Walmart, en SSR el cliente empieza a ver el contenido mucho antes, a pesar de que el servidor tarde algunos ms más en responder:
Entonces, si a los SEOs nos complica la vida el CSR (ya que dependemos de la capacidad del buscador a la hora de ejecutar JS y renderiza) y para los usuarios es más rápido SSR, ¿por qué se utiliza CSR? Pues por el mismo motivo por el que IKEA vende los muebles sin montar: por costes.
El mayor beneficiado de utilizar CSR es el departamento de sistemas: al delegar la “construcción” de las páginas en los clientes (navegadores), los servidores necesitan utilizar mucha menos potencia. Si hacemos SSR, vamos a tener que hacer todo ese trabajo de pre-renderizado en el servidor, el cual puede ser muy costoso como ya hemos visto.
Más información oficial y actualizada sobre sistemas de renderizado.
Comentábamos antes que la solución que Google ha propuesto si no queremos tener problemas, es utilizar Dynamic Rendering (es decir, SSR al menos para Googlebot), pero también ha especificado que en algunos casos ya siente capaz de rastrear e indexar webs creadas con CSR puro.
Específicamente, ha hablado de tres factores:
En función de eso, hemos montado esta tabla de lo que serían las recomendaciones de Google:
Cómo podéis ver, lo recomendado es utilizar siempre SSR (o Dynamic Rendering), excepto en sites pequeños y estáticos. Aún así, existe cierto riesgo incluso para este tipo de sites, así que lo ideal si vuestro proyecto depende del tráfico SEO es no jugársela y hacer un SSR / DR desde el principio.
Para que veais el tipo de problemas que puede generar un CSR, aquí tenéis un ejemplo que compartió en twitter Barry Adams:
En él, muestra la gráfica de evolución de URLs indexadas de un site que estaba hecho en CSR puro y que eventualmente cambió a SSR. Al hacerlo, el número de páginas indexadas aumentó sustancialmente (casi al doble), reflejando el cuello de botella que supone JS para Google y el motivo por el cual no lo recomienda para sites grandes.
A continuación, vamos a mostrar herramientas para comprobar que Google no tienen problemas con nuestro sitio.
La podéis hacer combinando el plugin Lighthouse de Chrome (ya era hora que hicieran el plugin, porque hasta entonces era nativo en Chrome Canary) y Sonar Whal.
Con el plugin de Chrome Service Worker Detector, podéis revisar rápidamente el service worker y el manifest de una PWA.
A día de hoy, el Mobile-Friendly Test de Google es la mejor manera de ver la página renderizada, ya que es más tolerante que el Fetch & Render de Search Console. En SC suelen aparecer muchos timeouts y no es un representativo de la realidad al 100%. El Mobile Friendly Test tampoco lo es, pero es una idea más aproximada, el problema de ésta es que no podemos hacer scroll.
También podemos usar esta tool para ver el HTML después de renderizar y ver si existen diferencias en ambos HTML con Diff Checker. Otra de las cosas que podemos analizar son los errores JavaScript y los assets bloqueados.
No por ello menos útil, la herramienta de Google nos permite comparar qué vería un buscador y un usuario de una vez, lo cual es muy cómodo.
También podemos hacer Fetch and Render de cualquier dominio para ver cómo lo hace la competencia, aunque no lo tengamos en nuestro SC. Por ejemplo, podéis ver cómo desde mi propio SC estoy renderizando Trivago gracias al código que ha compartido la gente de ScreamingFrog (acordaros de modificarlo como compartí en las diapos o la podréis liar):
Lo que hace este código es añadir la url que quieras en un iframe de una página de tu dominio.
También podéis hacer Fetch and Render con la herramienta de Google de un sitio en staging. Para ello ponéis todo staging con noindex y sólo dejáis que entre a staging Googlebot mediante Reverse DNS.
Existen otras herramientas como ScreamingFrog SEO Spider o esta herramienta online de Merkle SEO. Gracias a estas tools podéis modificar el tiempo de espera y los user agents. Lo que tenéis que intentar es que todo renderice por debajo de 5 segundos (ni mucho menos es un número de referencia, pero cuanto más rápido mejor).
Si estáis cambiando vuestra web a algún Framework JS como por ejemplo Angular, React, Polymer, Vue… con crawlers como FandangoSEO podéis crawlear vuestro sitio en staging y también en producción. La mayoría de problemas SEO en migraciones a Frameworks que hemos visto son porque se ha cambiado el layout y no porque se esté usando JavaScript.
Como en cualquier migración, hay que revisar que todas las URLs enlacen de la misma forma en pre y en pro, manteniendo los mismos niveles de profundidad. Así como que se mantenga el mismo contenido en ambas versiones. Esto es prioritario en cualquier migración, más aún que preocuparse porque las redirecciones sean dobles o simples. También es un error migrar plantilla, CMS y URLs a la vez, por mucho que mantengamos links y las redirecciones sean perfectas, son muchos cambios a procesar por Google y puede tardar en recuperarse tranquilamente de 6 a 12 meses como ha confirmado en más de una ocasión.
De ahí la necesidad de hacer cuantos menos cambios a la vez mejor y revisarlo todo concienzudamente en staging.
Ahora, con la llegada de mobile first indexing, tenemos que comprobar cómo ve Google nuestra web en mobile y revisar los puntos arriba mencionados. Con FandangoSEO también podemos comparar crawls y ver si mobile vs desktop es lo más parecido posible.
Aunque esto se puede comprobar también con crawlers, para hacer una comprobación a mano de las páginas principales uso los plugins meta seo inspector combinado con user-agent switcher. A este último le añado los user agent de Googlebot, Googlebot Mobile y los de Facebook y Twitter (para ver las opengraph y twitter cards):
También podéis usar el nuevo Rich Results Test de Google para validar el schema.org que además os dará HTML renderizado. Lo único que no me gusta es que todavía no acepta tantos tipos como la anterior herramienta de datos estructurados.
Esto se hace combinando de nuevo user-agent switcher, pero con el plugin Web Developer, donde se desactiva el JS para navegar.
Es imprescindible usar Chrome 41 74 para ver los errores de Javascript, de API o de CSS que da la consola del navegador. Veréis que hay errores que en el Chrome actual no aparecen, con lo cual, si están en la versión 41 74 son errores que Google podría tener para renderizar.
Otro elemento que tenemos que atender es si los links y menús son accesibles para Chrome 41 74, hay funciones modernas que tienen estos Frameworks que no permiten que lo sean. Aquí podéis ver qué funciones podéis usar y cuáles no.
Existen rumores que Google no va a tardar más de un año en actualizar su WRS con otra versión más moderna de Chrome, pero no hay una fecha concreta. Así que hasta entonces, Chrome 41 tiene que ser nuestra referencia. Actualizado a Chrome 74 a 07/05/2019.
Para acabar con las buenas prácticas, os compartimos una serie de checklist para tener en cuenta a revisar tanto si hacéis CSR, como Dynamic Rendering o con SSR o Hybrid Rendering.
Además os compartimos este checklist sacado de la página de Google, de cosas a revisar para PWA a nivel de experiencia de usuario y WPO.
Para poder probar en nuestras propias carnes cómo trata Google el JavaScript, hemos sacrificado nuestros blogs migrándolos de un WordPress “normal” a una PWA que funciona únicamente con JS (CSR).
Lo hemos hecho con Worona (ahora Frontity), que es una plataforma para convertir un WordPress en una PWA para usuarios móviles. En nuestro caso, hemos colaborado con ellos para hacer que la PWA se cargase tanto en mobile como en desktop modificando el código, y que cuando no tenemos JS activo se reciba una página en blanco, simulando así el CSR. Hicimos esto porque nuestros blogs todavía no están en mobile first indexing, y queríamos que la versión desktop fuera PWA también.
Como podéis ver si desactivamos JS todas las páginas del blog cargan únicamente esto que veis aquí: una página prácticamente en blanco, sin contenido ni enlaces para rastrear:
Una vez puesta la PWA en producción, hemos hecho diferentes pruebas. ¡Ojo! Como vais a ver, las pruebas han sido hechas en un blog pequeño, en un espacio corto de tiempo y a pequeña escala. No podemos garantizar que los resultados del propio experimento se vayan a mantenerse o a replicarse en otras situaciones.
La primera prueba era comprobar si Google era, efectivamente, capaz de renderizar e indexar las URLs del blog, que sólo funcionan con JavaScript. Para ello, comprobamos primero en la Mobile-Friendly Test Tool y en el Fetch and Render de Search Console, donde podemos ver que el contenido aparece. Utilizamos la opción de “Solicitar indexación” para forzar a Google a actualizar esa URL en su índice, y en menos de 15 minutos podemos comprobar que lo ha hecho:
Observaciones:
Una vez que sabemos que Google es capaz de renderizar el JS y ver nuestro contenido, la siguiente pregunta obvia es de si nos mantiene los rankings para ese post. Para ello, elegimos una keyword para la que el post lleva 6 meses posicionando entre posiciones 1 y 2:
Y comprobamos que una vez ha actualizado esta página en su índice, seguimos manteniendo la misma posición para esta búsqueda:
Además, hacemos una búsqueda extra combinando la keyword con un trozo de texto que aparece en la PWA y no aparecía en la versión anterior del blog, para asegurarnos de que Google está utilizando la versión PWA de la página:
Observaciones:
Para comprobar cuánto tarda Google en detectar, rastrear e indexar un post nuevo, publicamos uno:
Como no queremos forzar que lo rastree, lo que hacemos es un Fetch and render de la home del blog y solicitamos la indexación de la misma, en la que está presente un enlace a este nuevo post, para ver si Google lo indexa.
A pesar de que aparecía una visita de Googlebot a la URL en los logs, la página no apareció en el índice de Google hasta 5 días después:
Un pequeño error al hacer esta prueba es que el post no tenía apenas contenido, y el plugin utilizado (Worona) al hacer scroll pasa al siguiente post, así que Google al renderizar está recibiendo el contenido de otro post bajo esta URL:
Observaciones:
Por último, queríamos demostrar el sistema de dos olas de indexación que Google ha confirmado. Al igual que en el caso anterior, al hacer la prueba con una URL que tenía muy poco contenido, Google ha terminado cargando el siguiente post que sale al hacer scroll e indexando contenido de otro post asociado a esta URL.
Lo que hicimos fue lo siguiente:
Observaciones:
En este artículo nos adentramos en el funcionamiento interno de Google, una herramienta que todos usamos a diario pero que pocos comprendemos realmente. A raíz de la reciente filtración de documentos en un juicio antimonopolio contra Google, tenemos una gran oportunidad para explorar los algoritmos de Google. De algunos de ellos ya teníamos información, pero […]
Leer másTomar decisiones acertadas en el volátil mundo del SEO puede resultar complicado, especialmente al enfrentarse a situaciones complejas y desconocidas. En este escenario, el marco Cynefin puede guiarnos a gestionar proyectos SEO en un entorno cada vez más VUCA (Volátil, Incierto, Complejo y Ambiguo) o BANI (Frágil, Ansioso, No lineal e Incomprensible). Al final de […]
Leer más