Vue.js y SEO: cómo optimizar sitios web reactivos para motores de búsqueda y bots

 

 

 


Índice
  1. Algunos antecedentes sobre el problema
    1. Cómo funciona la indexación
    2. Un poquito de historia
  2. ¿Cómo indexa realmente Google las páginas creadas con frameworks front-end?
    1. El experimento
    2. Los resultados
    3. SEO competitivo
    4. Texto animado
    5. ¿Qué pasa con el renderizado previo?
  3. Otras Consideraciones
    1. Compatibilidad
    2. Errores de JavaScript
    3. Otros motores de búsqueda
    4. Otros robots
    5. Subpáginas
  4. Conclusiones

¿Google y otros motores de búsqueda indexan los sitios web creados con marcos reactivos? ¿Es obligatorio configurar el renderizado previo, como sugieren sus consultores de SEO? ¿O están equivocados?

 

Los marcos de JavaScript reactivos (como React , Vue.js y Angular ) están de moda últimamente, y no es de extrañar que se utilicen cada vez en más sitios web y aplicaciones debido a su flexibilidad, modularidad y facilidad de prueba automatizada.

Estos marcos permiten lograr cosas nuevas, antes impensables, en un sitio web o aplicación, pero ¿ cómo funcionan en términos de SEO? ¿Google indexa las páginas que se han creado con estos marcos? Dado que con estos marcos toda, o la mayor parte, la representación de la página se realiza en JavaScript (y el HTML que descargan los bots está prácticamente vacío), parece que no son posibles si desea que sus sitios web se indexen en motores de búsqueda o incluso analizados por bots en general.

 

En este artículo hablaré principalmente sobre Vue.js, ya que es el framework que más he usado y con el que tengo experiencia directa en términos de indexación por parte de los motores de búsqueda en proyectos importantes, pero puedo asumir que la mayoría de Lo que cubriré también es válido para otros marcos.

Reemplazo de jQuery con Vue.js

¿Sabías que puedes incorporar Vue a tu proyecto de la misma manera que incorporarías jQuery, sin necesidad de ningún paso de compilación?Leer un artículo relacionado →

Algunos antecedentes sobre el problema

Cómo funciona la indexación

Para que Google indexe su sitio web, el robot de Google (un software de indexación automatizado que visita su sitio web y guarda el contenido de las páginas en su índice) debe rastrearlo siguiendo los enlaces dentro de cada página. El robot de Google también busca archivos XML de mapas del sitio especiales en sitios web para encontrar páginas que podrían no estar vinculadas correctamente desde su sitio público y para recibir información adicional sobre la frecuencia con la que cambian las páginas del sitio web y cuándo cambiaron por última vez.

Un poquito de historia

Hasta hace unos años (antes de 2009), Google solía indexar el contenido HTML de un sitio web, excluyendo todo el contenido creado por JavaScript. Era conocimiento común de SEO que los enlaces y el contenido importantes no debían escribirse en JavaScript, ya que Google no los indexaría y podría causar una penalización para el sitio web porque Google podría considerarlo "contenido falso", como si el propietario del sitio web lo estuviera intentando. mostrar a los usuarios algo diferente a lo que se mostró a los motores de búsqueda e intentar engañar a estos últimos.

Era una práctica muy común por parte de los estafadores incluir una gran cantidad de contenido compatible con SEO en HTML y ocultarlo en JavaScript, por ejemplo. Google siempre ha advertido contra esta práctica :

"Ofrecer al robot de Google contenido diferente al que vería un usuario normal se considera encubrimiento y estaría en contra de nuestras Directrices para webmasters".

Podrías ser penalizado por esto. En algunos casos, podría ser penalizado por ofrecer contenido diferente a diferentes agentes de usuario en el lado del servidor, pero también por cambiar el contenido a través de JavaScript después de que la página se haya cargado. Creo que esto nos muestra que Google ha estado indexando sitios web que ejecutan JavaScript durante mucho tiempo, al menos para comparar el HTML final del sitio web (después de la ejecución de JavaScript) y el HTML sin procesar que estaba analizando para sus índices. Pero el robot de Google no ejecutaba JavaScript todo el tiempo y Google no utilizaba el contenido generado por JavaScript con fines de indexación.

 

Luego, dado el mayor uso de AJAX para ofrecer contenido dinámico en sitios web, Google propuso un " esquema de rastreo AJAX " para ayudar a los usuarios a indexar sitios web basados ​​en AJAX. Fue muy complicado; Básicamente, requería que el sitio web produjera una representación de páginas con contenido AJAX incluido. Cuando Google lo solicita, el servidor proporciona una versión de la página con todo (o la mayor parte) del contenido que se habría generado dinámicamente mediante JavaScript incluido en la página HTML, presentado previamente como una instantánea HTML del contenido. Este proceso de tener una solución del lado del servidor que entregue contenido que (para todos los demás fines) estaba destinado a ser generado en el lado del cliente, implicaba que aquellos que querían tener un sitio que dependiera en gran medida de JavaScript indexado en Google tenían que pasar por una gran cantidad de molestias técnicas.

Por ejemplo, si el contenido leído por AJAX procedía de un servicio web externo, era necesario duplicar las mismas llamadas al servicio web en el lado del servidor y producir, en el lado del servidor, el mismo HTML que se habría producido en el lado del cliente. JavaScript, o al menos uno muy similar. Esto era muy complicado porque, antes de la llegada de Node.js, era necesario duplicar al menos parcialmente la misma lógica de representación en dos lenguajes de programación diferentes: JavaScript para el frontend y PHP, Java, Python, Ruby, etc. el backend. Esto se llama " renderizado del lado del servidor " y podría llevar a un infierno de mantenimiento: si realizabas cambios importantes en la forma en que renderizabas el contenido en el frontend, tenías que duplicar esos cambios en el backend.

La única alternativa para evitar la duplicación de la lógica era analizar su propio sitio con un navegador que ejecutara JavaScript y guardar los resultados finales en su servidor y entregárselos al robot de Google. Esto es algo similar a lo que ahora se llama " pre-renderizado ".

Google (con su esquema de rastreo AJAX) también garantizó que evitarías sanciones debido al hecho de que en este caso estabas entregando contenido diferente al robot de Google y al usuario. Sin embargo, desde 2015, Google ha desaprobado esa práctica con una publicación de blog oficial que decía a los administradores de sitios web lo siguiente:

"Hoy en día, siempre que no impida que el robot de Google rastree sus archivos JavaScript o CSS, generalmente podemos representar y comprender sus páginas web como los navegadores modernos ".

Lo que esto nos dijo no fue que el robot de Google había adquirido repentinamente la capacidad de ejecutar JavaScript al indexar páginas web, ya que sabemos que lo había hecho durante mucho tiempo (al menos para comprobar si había contenido falso y estafas). En cambio, nos dijo que el resultado de la ejecución de JavaScript se indexaría y utilizaría en las SERP.

Esto parece implicar que ya no tenemos que preocuparnos por proporcionarle a Google HTML renderizado del lado del servidor. Sin embargo, vemos todo tipo de herramientas para renderizado previo y renderizado del lado del servidor disponibles para marcos de JavaScript, pero parece que este no es el caso. Además, cuando se trata de agencias de SEO en grandes proyectos, el renderizado previo parece considerarse obligatorio. ¿Cómo?

 

¿Cómo indexa realmente Google las páginas creadas con frameworks front-end?

El experimento

Para ver qué indexa realmente Google en los sitios web creados con un marco de interfaz de usuario, realicé un pequeño experimento. No cubre todos los casos de uso, pero al menos es un medio para saber más sobre el comportamiento de Google. Creé un pequeño sitio web con Vue.js y diferentes partes del texto se representaron de manera diferente.

El contenido del sitio web está tomado de la descripción del libro Infinite Jest de David Foster Wallace en Infinite Jest Wiki ( ¡gracias chicos! ). Hay un par de textos introductorios para todo el libro y una lista de personajes con su biografía individual:

  • Parte del texto en HTML estático, fuera del contenedor principal de Vue.js;
  • Vue.js procesa inmediatamente parte del texto porque está contenido en variables que ya están presentes en el código de la aplicación: están definidas en el dataobjeto del componente;
  • # Vue.js procesa parte del texto desde el dataobjeto, pero con un retraso de 300 ms;
  • Las biografías de los personajes provienen de un conjunto de API de resto, que he creado específicamente usando Sandbox . Como suponía que Google ejecutaría el código del sitio web y se detendría después de un tiempo para tomar una instantánea del estado actual de la página, configuré cada servicio web para que respondiera con un retraso incremental, el primero con 0 ms, el segundo con 300 ms, el tercero con 600ms y así hasta 2700ms.

La biografía de cada personaje se acorta y contiene un enlace a una subpágina, que está disponible solo a través de Vue.js (las URL las genera Vue.js usando la API de historial), pero no en el lado del servidor (si llama a la URL del página directamente, no obtiene respuesta del servidor), para verificar si también se indexaron. Supuse que estos no se indexarían, ya que no son enlaces adecuados que se muestren en el lado del servidor y no hay forma de que Google pueda dirigir a los usuarios a esos enlaces directamente. Pero sólo quería comprobarlo.

Publiqué este pequeño sitio de prueba en mis páginas de Github y solicité la indexación; eche un vistazo .

Los resultados

Los resultados del experimento (relativo a la página de inicio) son los siguientes:

  • Google indexa los contenidos que ya están en el contenido HTML estático (lo cual es bastante obvio);
  • Los contenidos generados por Vue en tiempo real siempre son indexados por Google;
  • Los contenidos generados por Vue, pero renderizados después de 300 ms también se indexan;
  • Los contenidos que provienen del servicio web, con cierto retraso, pueden ser indexados, pero no siempre. Revisé la indexación de la página por parte de Google en diferentes momentos, y el contenido que se insertó en último lugar (después de un par de segundos) a veces se indexó y otras no. El contenido que se procesa con bastante rapidez se indexa la mayor parte del tiempo, incluso si proviene de una llamada asincrónica a un servicio web externo. Esto depende de que Google tenga un presupuesto de procesamiento para cada página y sitio, que depende de sus algoritmos internos, y puede variar enormemente según la clasificación de su sitio y el estado actual de la cola de procesamiento del robot de Google. Por lo tanto, no puede confiar en que el contenido proveniente de servicios web externos sea indexado;
  • Las subpáginas (ya que no se puede acceder a ellas mediante un enlace directo) no se indexan como se esperaba.

¿Qué nos dice este experimento? Básicamente, Google sí indexa contenido generado dinámicamente, incluso si proviene de un servicio web externo, pero no garantiza que el contenido sea indexado si “llega demasiado tarde”. He tenido experiencias similares con otros sitios web de producción reales además de este experimento. Letras en Graffiti Gratis | Descubre Todos los Estilos

 

SEO competitivo

Bien, entonces el contenido se indexa , pero lo que este experimento no nos dice es: ¿ se clasificará el contenido de manera competitiva? ¿Preferirá Google un sitio web con contenido estático a un sitio web generado dinámicamente? Esta no es una pregunta fácil de responder.

Desde mi experiencia, puedo decir que el contenido generado dinámicamente puede ubicarse en las primeras posiciones de las SERPS. He trabajado en el sitio web para un nuevo modelo de una importante empresa de automóviles, lanzando un nuevo sitio web con un nuevo dominio de tercer nivel. El sitio se generó íntegramente con Vue.js, con muy poco contenido en HTML estático además de titleetiquetas y metadescripciones.

El sitio comenzó a clasificarse para búsquedas menores en los primeros días después de su publicación, y los fragmentos de texto en las SERP informaron palabras provenientes directamente del contenido dinámico.

En tres meses ocupaba el primer lugar en la mayoría de las búsquedas relacionadas con ese modelo de automóvil, lo cual era relativamente fácil ya que estaba alojado en un dominio oficial perteneciente al fabricante del automóvil y el dominio estaba fuertemente vinculado desde sitios web de buena reputación.

Pero teniendo en cuenta que tuvimos que enfrentarnos a una fuerte oposición de la empresa SEO que estaba a cargo del proyecto, creo que el resultado fue notable.

Debido a los plazos ajustados y la falta de tiempo asignado para el proyecto, íbamos a publicar el sitio sin renderizado previo.

Texto animado

Lo que Google no indexa es texto muy animado. El sitio de una de las empresas con las que trabajo, Rabbit Hole Consulting , contiene muchas animaciones de texto, que se realizan mientras el usuario se desplaza y requieren que el texto se divida en varios fragmentos con diferentes etiquetas.

Los textos principales de la página de inicio del sitio web no están destinados a la indexación en buscadores ya que no están optimizados para SEO. No están hechos de lenguaje técnico y no utilizan palabras clave: solo pretenden acompañar al usuario en un viaje conceptual sobre la empresa. El texto se inserta dinámicamente cuando el usuario ingresa a las distintas secciones de la página de inicio.

(Fuente de la imagen: Rabbit Hole Consulting ) ( Vista previa grande )

Ninguno de los textos de estas secciones del sitio web es indexado por Google. Para que Google muestre algo significativo en las SERP, agregamos texto estático en el pie de página debajo del formulario de contacto, y este contenido se muestra como parte del contenido de la página en las SERP.

 

El texto del pie de página se indexa y se muestra en las SERP, aunque los usuarios no lo pueden ver inmediatamente a menos que se desplacen hasta la parte inferior de la página y hagan clic en el botón "Preguntas" para abrir el formulario de contacto. Esto confirma mi opinión de que el contenido se indexa incluso si no se muestra inmediatamente al usuario, siempre y cuando se reproduzca pronto en HTML, en lugar de procesarse bajo demanda o después de un largo retraso.

¿Qué pasa con el renderizado previo?

Entonces, ¿por qué tanto alboroto por el pre-renderizado, ya sea en el lado del servidor o en el momento de la compilación del proyecto? ¿Es realmente necesario? Aunque algunos marcos, como Nuxt, lo hacen mucho más fácil de realizar, todavía no es fácil, por lo que la elección de configurarlo o no no es fácil.

Creo que no es obligatorio . Sin duda, es un requisito si gran parte del contenido que desea que Google indexe proviene de un servicio web externo y no está disponible inmediatamente en el momento de la renderización y, en algunos casos desafortunados, podría no estar disponible en absoluto debido, por ejemplo, a , tiempo de inactividad del servicio web. Si durante las visitas del robot de Google parte de su contenido llega demasiado lento, es posible que no se indexe . Si el robot de Google indexa tu página exactamente en el momento en el que estás realizando el mantenimiento de tus servicios web, es posible que no indexe ningún contenido dinámico.

Además, no tengo pruebas de diferencias de clasificación entre el contenido estático y el contenido generado dinámicamente. Eso podría requerir otro experimento. Creo que es muy probable que, si el contenido proviene de un servicio web externo y no se carga inmediatamente, pueda afectar la percepción que tiene Google del rendimiento de su sitio, que es un factor muy importante para la clasificación.

Lectura recomendada : Cómo el diseño web móvil afecta la búsqueda local (y qué hacer al respecto)

Otras Consideraciones

Compatibilidad

Hasta hace poco, el robot de Google utilizaba una versión bastante antigua de Chromium (el proyecto de código abierto en el que se basa Google Chrome), concretamente la versión 41. Esto significaba que Google no podía representar correctamente algunas funciones recientes de JavaScript o CSS (por ejemplo, IntersectionObserver, sintaxis ES6, etc.).

Google ha anunciado recientemente que ahora está ejecutando la última versión de Chromium (74, en el momento de escribir este artículo) en Googlebot, y que la versión se actualizará periódicamente. El hecho de que Google estuviera ejecutando Chromium 41 podría haber tenido grandes implicaciones para los sitios que decidieron ignorar la compatibilidad con IE11 y otros navegadores antiguos.

Puede ver una comparación de la compatibilidad de Chromium 41 y Chromium 74 con las funciones aquí ; sin embargo, si su sitio ya estaba completando las funciones faltantes para seguir siendo compatible con navegadores más antiguos, no debería haber habido ningún problema.

 

Utilice siempre polyfills, ya que nunca se sabe qué navegador no admite funciones que cree que son comunes. Por ejemplo, Safari no admitió una característica nueva importante y muy útil como IntersectionObserver hasta la versión 12.1, que salió en marzo de 2019 .

Errores de JavaScript

Si confía en que Googlebot ejecute su JavaScript para representar contenido vital, entonces se deben evitar a toda costa los errores importantes de JavaScript que podrían impedir que el contenido se reproduzca. Si bien los robots pueden analizar e indexar HTML que no es perfectamente válido (¡aunque siempre es preferible tener HTML válido en cualquier sitio!), si hay un error de JavaScript que impide la carga de algún contenido , entonces no hay forma de que Google indexe ese contenido.

En cualquier caso, si confía en JavaScript para presentar contenido vital a sus usuarios finales, es probable que ya tenga pruebas unitarias exhaustivas para verificar errores de bloqueo de cualquier tipo. Sin embargo, tenga en cuenta que los errores de Javascript pueden surgir de escenarios impredecibles, por ejemplo, en caso de un manejo inadecuado de los errores en las respuestas de la API.

Es mejor contar con algún software de verificación de errores en tiempo real (como Sentry o LogRocket) que lo alertará sobre cualquier error extremo que no detecte durante las pruebas unitarias o manuales. Esto se suma a la complejidad de depender de JavaScript para el contenido SEO.

Otros motores de búsqueda

Los otros motores de búsqueda no funcionan tan bien como Google con contenido dinámico. Bing no parece indexar contenido dinámico en absoluto, ni tampoco DuckDuckGo o Baidu. Probablemente esos motores de búsqueda carezcan de los recursos y la potencia informática que Google tiene en abundancia.

Analizar una página con un navegador sin cabeza y ejecutar JavaScript durante un par de segundos para analizar el contenido renderizado requiere ciertamente más recursos que simplemente leer HTML simple. O tal vez estos motores de búsqueda hayan optado por no escanear contenido dinámico por otras razones. Cualquiera que sea la causa de esto, si su proyecto necesita ser compatible con alguno de esos motores de búsqueda, debe configurar el renderizado previo.

Nota : Para obtener más información sobre las capacidades de renderizado de otros motores de búsqueda, puede consultar este artículo de Bartosz Góralewicz. Es un poco antiguo, pero según mi experiencia, sigue vigente.

Otros robots

Recuerde que su sitio también será visitado por otros bots. Los ejemplos más importantes son Twitter, Facebook y otros robots de redes sociales que necesitan obtener metainformación sobre sus páginas para mostrar una vista previa de su página cuando sus usuarios la vinculan. Estos bots no indexarán contenido dinámico y solo mostrarán la metainformación que encuentren en el HTML estático. Esto nos lleva a la siguiente consideración.

Subpáginas

Si su sitio es un "sitio web de una página" y todo el contenido relevante está ubicado en un HTML principal, no tendrá problemas para que Google indexe ese contenido. Sin embargo, si necesita que Google indexe y muestre cualquier página secundaria en el sitio web, aún necesitará crear HTML estático para cada una de ellas, incluso si confía en su marco JavaScript para verificar la URL actual y proporcionar el contenido relevante para colocar. en esa página. Mi consejo, en este caso, es crear páginas del lado del servidor (o estáticas) que al menos proporcionen la titleetiqueta y la meta descripción/información correctas.

Conclusiones

Las conclusiones a las que he llegado mientras investigaba este artículo son las siguientes:

  1. Sin embargo, si solo se orienta a Google, no es obligatorio utilizar el renderizado previo para que su sitio esté completamente indexado; sin embargo:
  2. No debe confiar en servicios web de terceros para el contenido que debe indexarse, especialmente si no responden rápidamente.
  3. El contenido que inserta en su HTML inmediatamente a través de la representación de Vue.js se indexa, pero no debe usar texto animado o texto que se inserta en el DOM después de acciones del usuario como desplazamiento, etc.
  4. Asegúrese de realizar pruebas para detectar errores de JavaScript, ya que podrían provocar que páginas/secciones enteras no se indexen, o que su sitio no se indexe en absoluto.
  5. Si su sitio tiene varias páginas , aún necesita tener algo de lógica para crear páginas que, si bien dependen del mismo sistema de representación frontal que la página de inicio, Google pueda indexarlas como URL individuales.
  6. Si necesita tener diferentes descripciones e imágenes de vista previa para las redes sociales entre diferentes páginas, deberá abordar esto también, ya sea en el lado del servidor o compilando páginas estáticas para cada URL.
  7. Si necesita que su sitio funcione en motores de búsqueda distintos de Google , definitivamente necesitará algún tipo de renderizado previo.

(dm, yk, il)

Agradecimientos: Muchas gracias a Sigrid Holzner de SEO Bavaria / Rabbit Hole Consulting por su revisión de este artículo.

Explora más en

  • vista
  • Reaccionar
  • SEO
  • javascript
  • Mejoramiento





Tal vez te puede interesar:

  1. ¿Deberían abrirse los enlaces en ventanas nuevas?
  2. 24 excelentes tutoriales de AJAX
  3. 70 técnicas nuevas y útiles de AJAX y JavaScript
  4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Vue.js y SEO: cómo optimizar sitios web reactivos para motores de búsqueda y bots

Vue.js y SEO: cómo optimizar sitios web reactivos para motores de búsqueda y bots

Índice Algunos antecedentes sobre el problema

programar

es

https://aprendeprogramando.es/static/images/programar-vue-985-0.jpg

2024-05-20

 

Vue.js y SEO: cómo optimizar sitios web reactivos para motores de búsqueda y bots
Vue.js y SEO: cómo optimizar sitios web reactivos para motores de búsqueda y bots

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Top 20