React SEO: Las mejores prácticas para que sea SEO-Friendly

React y otras bibliotecas similares (como Vue.js) se están convirtiendo en la opción preferente para empresas más grandes que demandan un desarrollo complejo. Aquellas empresas donde un enfoque más simple (como usar un tema de WordPress) no satisface los requisitos básicos.

A pesar de ello, los SEOs inicialmente no adoptaron bibliotecas como React, ya que los motores de búsqueda luchan por representar JavaScript de forma efectiva, siendo la preferencia el contenido disponible dentro de la fuente HTML.

Sin embargo, los desarrollos tanto en Google como en React pueden renderizar en JavaScript. Es decir, se han simplificado estas complejidades, lo que resulta en que el SEO ya no obstaculiza el uso de React.

Aún así, quedan algunas complejidades que analizaremos en esta guía.

En este post cubriremos:

React es una biblioteca JavaScript open-source desarrollada por Meta (anteriormente Facebook) para crear aplicaciones web y móviles. Las principales características de React son que (1) es declarativa, (2) está basada en componentes y (3) permite una manipulación más sencilla del DOM.

La forma más sencilla de entender los componentes es pensar en ellos como plugins, como por ejemplo de WordPress. Permiten a los desarrolladores crear rápidamente un diseño y agregar funcionalidad a una página usando bibliotecas de componentes como MUI o Tailwind UI.

Si quieres saber por qué los desarrolladores prefieren React, empieza con estas lecturas:

React implementa un App Shell Model, lo que significa que la gran mayoría del contenido (si no todo) se representará en el lado del cliente (CSR, por sus siglas en inglés Client-side Rendered) de forma predeterminada.

CSR significa que el código HTML contiene principalmente la biblioteca React JS, en vez de que el servidor envíe el contenido completo de la página dentro de la respuesta HTTP inicial del servidor (la fuente HTML).

También incluirá código JavaScript que contenga datos JSON, o enlaces a archivos JS, que contengan componentes React. Puedes saber rápidamente si una web está renderizando del lado del cliente comprobando su código fuente HTML. Para ello, haz clic con el botón derecho en un página web y selecciona “Ver código fuente” (o CTRL/CMD + U).

Si no ves muchas líneas de HTML, lo más probable es que la aplicación esté renderizada del lado del cliente.

Sin embargo, cuando inspeccionas el elemento haciendo clic con el botón derecho y seleccionando “Inspeccionar elemento” (o F12 / CMD + ⌥ + I), verás el DOM generado por el navegador (el sitio donde el navegador ha renderizado el código JavaScript).

Ahí verás que la página tiene mucho código HTML:

Observa el ID appMountPoint en el primer <div>. Comúnmente verás un elemento como ese en una aplicación de una sola página (SPA, por sus siglas en inglés single-page application), por lo que una biblioteca como React sabe dónde debe inyectar HTML. Las herramientas de detección de tecnología, por ejemplo, Wappalyzer, también son muy buenas para detectar la biblioteca.

Las webs creadas con React se diferencian del enfoque más tradicional de dejar el trabajo pesado de renderizar el contenido en el servidor utilizando lenguajes como PHP, llamado Server-side Rendering (SSR).

Antes del SSR, los desarrolladores lo tenían aún más fácil.

Creaban documentos HTML estáticos que no cambiaban, los alojaban en un servidor y los enviaban inmediatamente. El servidor no necesitaba renderizar nada, y el navegador, normalmente, tenía muy poco que renderizar.

Las SPA (las single-side applications, incluidas las que utiliza React) están volviendo a este enfoque estático. Ahora están pre-renderizando JavaScript en HTML antes de que un navegador solicite la URL. Este enfoque se denomina Static Site Generation (SSG), también conocido como Static Rendering.

En la práctica, SSR y SSG son muy parecidos.

La diferencia clave es que con el SSR el contenido se renderiza cuando el navegador solicita una URL, mientras que con el SSG el contenido se pre-renderiza en tiempo de compilación (cuando los desarrolladores despliegan código nuevo o un administrador web cambia el contenido de la web).

SSR puede ser más dinámico, pero más lento debido al tiempo adicional requerido por parte del servidor al renderizar el contenido antes de enviarlo al navegador del usuario.

SSG es más rápido, ya que el contenido ya ha sido renderizado. Lo que significa que se puede entregar al usuario inmediatamente (lo que se traduce como un TTFB, Time to First Byte, más rápido).

Para entender por qué el enfoque de renderizado del lado del cliente por defecto de React causa problemas de SEO, primero hay que entender cómo Google rastrea, procesa e indexa las páginas.

Podemos resumir los conceptos básicos de cómo funciona esto en los siguientes pasos:

Históricamente, los problemas con React y otras librerías JavaScript se han debido a que Google no maneja demasiado bien el paso del renderizado.

Algunos ejemplos son:

Afortunadamente, Google ha resuelto la mayoría de estos problemas. Googlebot ha mejorado. Por lo que ya es siempre compatible con las últimas funciones de Chromium.

Además, ahora el retraso de renderización son cinco segundos, como anunció Martin Splitt en la Cumbre de Desarrolladores de Chrome en noviembre de 2019:

Todo esto suena muy bien, pero, ¿utilizar el renderizado del lado del cliente y dejar que Googlebot muestre el contenido es la estrategia correcta?

Lo más probable es que la respuesta siga siendo no.

En los últimos cinco años, Google ha innovado su gestión del contenido JavaScript, pero las webs renderizadas completamente del lado del cliente introducen otros problemas que tienes que tener en cuenta.

Es importante saber que se pueden superar todos los problemas con React y SEO.

React JS es una herramienta de desarrollo. React no es distinta a cualquier otra herramienta dentro de un stack de desarrollo, ya sea un plugin de WordPress o la CDN que elijas. La forma en que lo configures determinará si perjudica o mejora el SEO.

Al fin y al cabo, React es bueno para el SEO, ya que mejora la experiencia del usuario. Solo tienes que asegurarte de tener en cuenta estos problemas que suelen ocurrir:

La cuestión más importante que tendrás que abordar con React es cómo renderiza el contenido.

Como hemos mencionado, hoy en día Google renderiza muy bien JavaScript. Pero, no es el caso con otros motores de búsqueda. Bing tiene algo de soporte con el renderizado de JavaScript, aunque su eficiencia es desconocida. Otros motores de búsqueda como Baidu, Yandex y otros ofrecen un soporte limitado.

Introducir esta incógnita constituye un buen argumento para optar por una solución de renderizado en el servidor que garantice que todos los rastreadores puedan ver el contenido de la web.

Además, renderizar el contenido en el servidor tiene otra ventaja muy importante: los tiempos de carga.

La renderización de JavaScript es intensiva para la CPU, lo que hace que las grandes bibliotecas como React tarden más en cargarse y volverse interactivas para los usuarios. Por lo general, los valores de Core Web Vitals, como el tiempo de interactividad (TTI, por sus siglas en inglés Time to Interactive), son mucho más altos para las SPAs, especialmente en smartphones, el dispositivo que más usa la gente para consumir contenido online.

Sin embargo, tras la renderización inicial por parte del navegador, los tiempos de carga posteriores tienden a ser más rápidos debido a lo siguiente:

En función del número de páginas vistas por visita, los datos pueden ser globalmente positivos:

Sin embargo, si tu web tiene un número bajo de páginas vistas por visita, te costará obtener datos positivos para todos los Core Web Vitals.

La mejor opción es optar por SSR o SSG debido principalmente a:

Implementar SSR dentro de React es posible a través del ReactDOMServer. Pero recomiendo usar un framework de React que se llama Next.js y usar sus opciones SSG y SSR. También puedes implementar CSR con Next.js, pero el framework empuja a los usuarios hacia SSR/SSG por su velocidad.

Next.js admite lo que llama “Optimización estática automática”. En la práctica, esto significa que puedes tener algunas páginas en una web que usen SSR (como una página de cuenta) y otras páginas que usen SSG (como un blog).

El resultado: SSG y TTFB rápido para páginas no dinámicas, y SSR como estrategia de representación de respaldo para contenido dinámico.

Es importante mencionar que Next.js optimiza la ruta de renderización crítica para aplicaciones React con características como:

La velocidad y los Core Web Vitals positivos son un factor de posicionamiento, aunque menor. Las funciones de Next.js facilitan la creación de experiencias web muy buenas que te darán una ventaja competitiva.

Un problema común con la mayoría de los SPAs es que no reportan correctamente los códigos de estado. Esto se debe a que el servidor no está cargando la página, sino el navegador. Por lo general, verás problemas con:

A continuación puedes ver que he realizado una prueba en una web que usa React con httpstatus.io. Esta página, obviamente, debería ser un 404 pero devuelve un código de estado 200. Esto se llama un soft 404.

El riesgo que nos encontramos es que Google puede decidir indexar esta página (dependiendo de su contenido). Google podría servirla a los usuarios, o se podría utilizar para evaluar una web.

Además, informar de los 404 ayuda a los SEOs a auditar una web. Si de forma accidental enlazas internamente a una página 404 y ésta devuelve un 200, detectar rápidamente la zona con una herramienta de auditoría puede resultar mucho más complicado.

Hay un par de formas de resolver este problema. Si estás renderizando del lado del cliente:

Si estás utilizando SSR, Next.js lo simplifica con ayudantes de respuesta que te permiten establecer cualquier código de estado que quieras, incluidas las redirecciones 3xx o un código de estado 4xx. El enfoque que describí usando React Router también se puede poner en práctica usando Next.js, pero si usas Next.js, es probable que también estés implementando SSR/SSG.

Este problema no es tan común en React, pero es esencial evitar URLs con hash como las siguientes:

Por norma general Google no verá nada después del hash. Todas estas páginas se verán como https://reactspa.com/.

Las SPAs con enrutamiento del lado del cliente deberían implementar la API History para cambiar de página.

Puedes hacerlo con relativa facilidad tanto con React Router como con Next.js.

Un error común con SPAs es usar un <div> o un <button> para cambiar la URL. Esto no es un problema con React en sí, sino cómo se utiliza la biblioteca.

Hacer esto presenta un problema con los motores de búsqueda. Como hemos mencionado anteriormente, cuando Google procesa una URL busca URLs adicionales para rastrear dentro de los elementos <a href>.

Si falta el elemento <a href>, Google no rastreará las URL ni transmitirá PageRank.

La solución es incluir enlaces <a href> a las URLs que quieras que Google descubra.

Comprobar si estás enlazando correctamente a una URL es fácil. Inspecciona el elemento que enlaza internamente y comprueba el HTML para asegurarte de que has incluido enlaces <a href>.

Como en el ejemplo arriba, puedes tener un problema si no lo están.

Hay que hacer hincapié en que la falta de enlaces <a href> no siempre es un problema. Una de las ventajas de la CSR es que, cuando el contenido es útil para los usuarios pero no para los motores de búsqueda, puedes cambiar el contenido del lado del cliente y no incluir el enlace <a href>.

En el ejemplo anterior, el sitio utiliza una navegación por facetas que enlaza con millones de combinaciones de filtros que no son útiles para que un motor de búsqueda los rastree o indexe.

Cargar estos filtros del lado del cliente tiene sentido en este caso, ya que el sitio conservará crawl budget al no agregar enlaces <a href> para que Google los rastree.

Next.js te lo pone fácil con su componente de enlace, que lo puedes configurar para permitir la navegación del lado del cliente.

Si te has decidido por implementar una aplicación completa de CSR, puedes cambiar las URLs con React Router usando onClick y el History API.

Es habitual que las webs desarrolladas con React inyecten contenido en el DOM cuando el usuario hace clic o pasa el ratón por encima de un elemento, simplemente porque la librería lo facilita.

No es algo necesariamente malo, pero el contenido añadido al DOM de esta forma no será visto por los motores de búsqueda. Si el contenido inyectado incluye contenido textual importante o enlaces internos, puede llegar a tener un impacto negativo:

Tomemos un ejemplo de una web con React JS que he auditado hace poco. Es un ecommerce de una marca conocida con enlaces internos importantes dentro de su navegación facetada.

Sin embargo, se inyectaba en el DOM un modal que mostraba la navegación en móvil al pulsar un botón “Filtrar”. Observa el segundo <!----> dentro del HTML de abajo:

Detectar estos problemas no es fácil. Hasta donde sé, ninguna herramienta te informará directamente sobre ellos.

En su lugar, tienes que buscar elementos comunes tipo:

A continuación, tendrás que inspeccionar el elemento y ver lo que ocurre con el HTML al abrirlos/cerrarlos, haciendo clic o pasando el ratón por encima (como he hecho en el GIF de arriba).

Supongamos que te das cuenta de que JavaScript está añadiendo HTML a la página. En este caso, tendrás que trabajar con los desarrolladores. Esto es para que en vez de inyectar el contenido en el DOM, se incluya dentro del HTML por defecto y se oculte y muestre mediante CSS utilizando propiedades como visibility: hidden; o display: none;.

Aunque hay consideraciones adicionales de SEO con las aplicaciones React, esto no significa que no se apliquen otros fundamentals.

Tendrás que asegurarte de que tus aplicaciones React siguen las mejores prácticas:

Desafortunadamente, trabajar con aplicaciones React se añade a una lista de problemas bastante larga que un SEO técnico tiene que comprobar. Pero gracias a frameworks como Next.js, el trabajo de un SEO se ha hecho mucho más fácil que antes.

Esperamos que esta guía te haya ayudado a entender mejor lo que tienes que tener en cuenta como SEO a la hora de trabajar con aplicaciones React.

¿Tienes alguna pregunta sobre cómo trabajar con React? Escríbenos por Twitter.