En este artículo voy a hablar del posicionamiento web en buscadores (SEO) en aplicaciones y sitios web realizados con Web Components. Espero que sirvan de ayuda a los interesados, aunque advierto que es un artículo en base a impresiones y experiencias, así que encontrarás no solo datos objetivos y rigurosos, sino también opiniones y consejos diversos. Además, debes tener en cuenta que quizás con el tiempo algunas de las cosas que estoy comentando evolucionen de distintas maneras.

El presente texto viene como respuesta a un estudiante de los cursos de Polymer de EscuelaIT, que me preguntaba:

¿Existe alguna forma de que me indexen el contenido de una web hecha con el sistema de routing de polymer?

Lo primero es avisar que Google sí que indexa páginas que usan el sistema de routing de Polymer. Este punto lo trataré en último lugar en el presente artículo. Pero te recomiendo leer mi respuesta completa, en la que he ampliado algo el ámbito de la pregunta y hablaré sobre SEO en Polymer en general.

Web Components son "SEO Friendly"

Aunque se me preguntó específicamente por aplicaciones que usan el sistema de routing de Polymer, hay que aclarar primero para las personas que puedan leer este texto que el ámbito de los proyecos candidatos a acometer con Polymer es mucho más ámplio que las aplicaciones SPA que usan el sistema de routing.

Con Polymer puedes hacer custom elements de Web Components, como nueva etiquetas que extienden el HTML estándar que entienden los navegadores, que podrías usar en cualquier tipo de sitio. Por tanto, podrías perfectamente usar Polymer en un sitio común, basado en un CMS que posicione tan bien como WordPress, o cualquier tipo de sitio que esté optimizado para buscadores.

Esto quiere decir que la discusión sobre si Polymer es bueno o no para el SEO es un poco ambigua, pues depende de cómo sea el sitio donde estés aplicando Polymer y no de la librería en sí o de Web Components en general.

Lo ideal es el Server Side Rendering

En el tema de SEO lo ideal es que el sitio tenga “server side rendering”. O sea, construir la página del lado del servidor y entregar contenido original en cada URL. Server side rendering es como funciona una página creada con PHP o cualquier lenguaje del lado del servidor, en la que el HTML se construye en el servidor y se manda contenido específico de cada página al cliente. Así es como funciona un CMS por lo general y la mayoría de sitios de la Web, sobre todo los estáticos.

Sin embargo, las aplicaciones de gestión modernas, basadas en web, servicios, paneles de control, etc. cada vez están basándose más en el modelo de las páginas conocidas como SPA. En ellas se usa un sistema de routing basado en Javascript. El navegador se encarga de procesar la dirección a la que se está accediendo y traer los datos con los que construir por él mismo el HTML. En estos escenarios ya no tenemos el comportamiento ideal, el mencionado server side rendering.

Las páginas que usan el routing de Polymer, o cualquier sistema de routing de los frameworks Javascript con los que se suelen construir las SPA, son siempre en realidad el mismo index.html de la home, junto con un Javascript. Las rutas se tratan desde ese Javascript, para mostrar unos u otros componentes. Como no tienes el contenido original en cada ruta de tu sitio, sino que ese contenido viene generado desde Javascript, no es tan bueno para SEO.

Hay soluciones encaminadas a resolver este problema, implementadas en los frameworks Javascript más avanzados, como Angular, VueJS o los basados en la librería React. Gracias a una capa adicional que se ejecuta del lado del servidor, es posible construir en el lado del servidor una página con contenido original para cada ruta, de modo que Google encuentra contenido original y específico para cada ruta y es capaz de indexar mejor el sitio web.

A día de hoy, no he encontrado una solución oficial para facilitar el Server Side Rendering en una app hecha con el sistema de routing de Polymer. Pero quizás no lo necesites y además hay alternativas.

Usar Web Components en sitios clásicos

La primera sería usar una librería basada en Web Components en un sitio común, con programación del servidor, capaz de producir un HTML único para cada URL. Es justamente lo que comentaba en el punto anterior de este artículo.

Usar otro framework que te facilite el server side rendering

Otra alternativa sería usar con otro framework que sí tenga resuelto el tema del server side rendering (SSR), como los mencionados antes (Angular, React, etc).

Usar Angular u otro framework para poder implementar el SSR podría parecer un poco descabellado, ya que lo que soluciona Web Components se superpone en muchos de los casos al código específico introducido por Angular o React, por lo que puede parecer poco óptimo cargar dos librerías distintas que tienen funcionalidades solapadas. Sin embargo hoy resulta una posibilidad muy viable, ya que en navegadores modernos donde se implementa Web Components 1.0 el peso que tiene la librería no pasa de unos pocos KB (5KB aproximadamente en Lit o LitElement).

Por todo ello, no es un problema usar librerías de Web Components junto con otras no basadas en Web Components. Pero tampoco es algo que necesites, porque todo lo que puedes hacer con grandes frameworks lo puedes implementar con pequelas librerías o micro-librerías. Incluso en el caso de usar Lit, la propia librería tiene ya disponible la parte del SSR.

Usar herramientas de terceros

Puedes probar con herramientas de terceros. No las he probado, pero en este tema la comunidad está trabajando para hacer algunas soluciones. Por ejemplo tienes Server Components o artículos de blogs que analizan cómo puedes crear tú mismo el sistema de renderizado del lado del servidor para tus aplicaciones.

Me gustaría ver pronto soluciones oficiales del propio Google, ya que el propio Polymer es una apuesta de la empresa del buscador, entiendo que deberían aportar ellos mismos las mejores soluciones para que las aplicaciones Polymer posicionen de manera muy optimizada.

Google sí que indexa páginas con el sistema de routing de Polymer

Como conclusión de este artículo se ha de decir que en realidad Google sí que está indexando páginas de aplicaciones SPA realizadas usando el sistema de routing de Polymer. Y lo que es más maravilloso, está teniendo en cuenta incluso datos que llegan desde la base de datos Firebase.

No sé precisar desde cuándo estamos en esta situación, pero cualquiera de nosotros lo podría comprobar haciendo una búsqueda por "site:app.desarrolloweb.com".

Esa búsqueda te dará una serie de páginas que encuentras en el app.desarrolloweb.com. Esa web está basada en el sistema de routing de Polymer y todos los datos se encuentran en una base de datos Firebase, por lo que no hay apenas ningún contenido escrito "a pelo" en el HTML, sino todo viene desde Javascript y del acceso a servicios externos.

Lo que no sé es el valor que tenga en términos de posicionamiento el contenido detectado en los diferentes componentes de cada ruta, o el texto que venga desde Firebase. Es decir, no sé si Google "trata de manera generosa o rácana" a los contenidos que encuentra en el Javascript de estas aplicaciones, en comparación con el contenido que recibe en el HTML de sitios tradicionales. Me da que no es demasiado generoso en términos de posicionamiento, pero el caso es que sí que lo indexa, lo que ya es una buena noticia. Además, tenemos que considerar que las apps SPA generalmente no tienen la cantidad de texto ideal para que un artículo posicione correctamente. Según los expertos de SEO y el propio Google, un artículo se considera de calidad a partir de 700 a 1000 palabras, lo que dista mucho del contenido original que se sirve desde nuestra app Polymer para la descarga de manuales.

Con esto es todo. Creo que habré dado un poco de luz a las dudas de las personas que se interesan por el SEO en Polymer. Como decía, seguramente en los próximos meses o años encontremos novedades interesantes y relevantes en cuanto a este importante tema, así que habrá que estar atentos. Pero el hecho de que Google sí que indexe aplicaciones en Polymer es sin duda una realidad.