19/07/19

La guía definitiva para JavaScript SEO_

19/07/2019

ÍNDICE DEL ARTÍCULO

Desde hace ya un tiempo atrás y con la implementación de la tecnología, los motores de búsqueda como Google, Bing y otros han dado pasos importantes para poder rastrear e indexar correctamente los sitios web de JavaScript. 

El problema es que, los mismos aún no cuentan con los recursos necesarios para mantener el ritmo e inclusive hacerlo correctamente en muchos casos. Pues, aquí es donde entra en juego el tema del JavaScript SEO

En palabras concretas, el JavaScript SEO es la rama de SEO u optimización de sitios en resultados de motores de búsqueda, el cual se enfoca exclusivamente en la optimización de dichos sitios pero programados en JavaScript, para asegurarse de que los motores de búsqueda los rastreen e indexen de manera correcta, como ocurriría con lo demás sitios. 

Asimismo, los buscadores como Google siguen tratando de optimizar más sus motores respecto a este tema, siendo ejemplo el anuncio reciente sobre el cual expresan que finalmente actualizaron su servicio de representación web basado en la última versión de Chromium, ahora admitiendo muchas características modernas de JavaScript.

El JavaScript SEO en la actualidad

Guia javascript y SEO

Sin duda el JavaScript SEO es un tema muy candente en la actualidad, ya que cada vez más y más sitios web utilizan marcos y bibliotecas de JavaScript modernos como Polymer, Angular, React y Vue.js, gracias a sus posibilidades y aspectos innovadores respecto a la programación y herramientas.  

A pesar de eso, la realidad es que el SEO y los desarrolladores aún están en el comienzo de un viaje para hacer que los marcos de JavaScript modernos tengan éxito en la búsqueda, inclusive teniendo ya ese interés Google y demás buscadores desde años anteriores pero que se nota está lejos, al estar fallando en los buscadores sitios populares basados en esta tecnología y plataforma. 

En este artículo se tratará de explicar por qué esto podría estar sucediendo y, cuando sea posible, ofrecer las formas de evitarlo y soluciones necesarias para optimizar mejor los sitios de JavaScript en buscadores, especialmente haciendo enfoque en Google. Estos son los puntos principales a tratar: 

  • Cómo garantizar que Google y su algoritmo, rastreadores y robots puedan representar correctamente un sitio web.
  • Cómo ver un sitio web de la misma manera que Google lo ve.
  • Cuáles son los errores más comunes respecto al JavaScript SEO y por qué se dan.
  • ¿Qué significa que Google va a deshacerse del antiguo Esquema de Rastreo Ajax?
  • ¿Cuál es mejor opción: Pre-procesado, SPA o JavaScript isomórfico?
  • Si es correcto detectar Googlebot por un agente de usuario y entregarle contenido pre-procesado con HTML y CSS.
  • Si otros motores de búsqueda como Bing son capaces de llevar a cabo JavaScript.

¿Puede Google rastrear y procesar JavaScript?

Google ha afirmado que son bastante buenos en la representación de sitios web de JavaScript, al menos desde el año 2014 que publicaron el post haciendo tal afirmación. 

La cuestión es que a pesar de eso, los desarrolladores detrás del buscador han aconsejado precaución respecto a este “asunto” de las páginas en JavaScript, como se puede ver en el siguiente extracto con más detalle:  

«En ocasiones, las cosas no salen a la perfección durante el procesamiento, lo que puede tener un impacto negativo en los resultados de búsqueda de su sitio. JavaScript puede ser demasiado complejo o arcano para ser ejecutado, en cuyo caso no es posible mostrar la página de forma completa y precisa.”

En detalle, hay tres aspectos técnicos fundamentales que entran en juego al momento de que los buscadores indexen sitios en JavaScript: 

  • Rastreabilidad: Google debería ser capaz de rastrear un sitio con una estructura adecuada en todos los aspectos. 
  • Capacidad de procesamiento: Google no debería tener inconvenientes en el procesado y mostrado de un sitio web. 
  • Presupuesto de rastreo: el tiempo que le tomaría a Google como buscador rastrear, procesar y mostrar el sitio web.  

Procesado basado en cliente y procesado basado en servidor

SSR vs CSR

A medida que se analiza si Google puede rastrear y procesar sitios en JavaScript, de manera casi obligatoria se deben abordar dos conceptos muy importantes: procesado basado en cliente y procesado basado en servidor. 

Por eso, se hace necesario que todos los profesionales en SEO que se ocupan de JavaScript entiendan estas dos vertientes, si es que quieren tener éxito en la optimización de este tipo de plataformas en línea. 

Para empezar, en el enfoque tradicional que es el procesado basado en servidor, un navegador o Googlebot recibe un HTML que describe completamente la página, entonces la copia del contenido ya está allí, por lo que el navegador o Googlebot solamente necesita descargar el CSS y mostrar el contenido de la pantalla. 

Por lo general, los motores de búsqueda no tienen ningún problema con el contenido procesado basado en servidor, ya que es el tradicional y en que se ha basado casi toda la web y su funcionamiento. 

Por otra parte, el enfoque cada vez más popular de procesado basado en cliente es un poco diferente, y lamentablemente los motores de búsqueda luchan con tal tipo de orientación menos tradicional. 

Aquí, es bastante común que en la carga inicial, un navegador o Googlebot obtiene una página HTML en blanco o una copia con muy poco contenido. Entonces, en este punto ocurre «la magia» y JavaScript descarga de forma asíncrona la copia de contenido del servidor y actualiza su pantalla, siendo parte de las diferencias de la tecnología con otros lenguajes de programación de sitios web como HTML. 

Por lo tanto, si se tiene un sitio web con procesado basado en cliente, hay que asegurarse siempre que Google pueda rastrearlo y representarlo correctamente, ya que JavaScript es muy sensible a los errores.

Por ejemplo, las plataformas HTML y JavaScript son totalmente diferentes en cuanto al manejo de errores, y un solo error en su código puede hacer que Google no pueda mostrar su página, en ambos casos pero siempre siendo mucho más crítico en sitios construidos en JS. 

La posibilidad del desarrollador de cometer un error 

Bartosz Góralewicz, CEO de Onely, llevó a cabo un experimento no hace mucho, para ver si Google podía manejar sitios web creados con marcos comunes de JavaScript, el resultado fue más que curioso..

Al principio, resultó que los robots de Google o rastreadores no podían procesar Angular 2, lo cual era bastante extraño porque Angular fue creado por el equipo de Google, por lo que Bartosz se dispuso a descubrir cómo podría suceder esto, quien en sus propias palabras diría:

“Y resultó que hubo un error en el inicio rápido de Angular 2, un tipo de tutorial sobre cómo configurar proyectos basados ​​en Angular 2, que estaba vinculado en la documentación oficial. Toda esa investigación para descubrir que el equipo de Google Angular había cometido un error.”

Finalmente, resultó en una corrección a nivel de sistema que se llevó a cabo el 26 de abril de 2017, y luego de eso fue posible indexar el sitio web de prueba de Angular 2 con todo el contenido. Este ejemplo ilustra perfectamente la situación cuando un solo error puede hacer que Google u otros buscadores no puedan encontrar y procesar una página.

errores SEO con Javascript

Por si fuera poco, el error no fue cometido por desarrolladores principiantes, sino que fue cometido por los colaboradores de Angular, el segundo marco de JavaScript más popular y que tiene a cargo a programadores y desarrolladores veteranos, demostrando que un error siempre puede suceder o colarse. 

Otro ejemplo que involucra errores y también la plataforma Angular ocurrió en diciembre de 2017, cuando Google desindexó algunas páginas de Angular.io, un sitio web basado en cliente y hecho en JavaScript y Angular 2+.  

Pero, ¿qué fue lo que sucedió? Como se puede inferir, un solo error en su código hizo imposible que Google procesará la página y provocó una desindexación masiva. Lo más increíble es que el error se corrigió tiempo después. Igor Minar, desarrollador de Angular.io, explicó con sus palabras la falla de la siguiente manera: 

“Dado que no hemos cambiado el código problemático en 8 meses y que experimentamos una pérdida significativa de tráfico proveniente de los motores de búsqueda, concretamente a partir del 11 de diciembre de 2017, creo que algo ha cambiado en los rastreadores durante este período de tiempo que causó la mayoría del sitio que se desindexara, lo que resultó en una pérdida de tráfico «.

Corregir el error de representación mencionado en Angular.io fue posible gracias al experimentado equipo de desarrolladores de JavaScript, y también al hecho de que implementaron el registro de errores, y si eso no se hubiese hecho hubiera tomado demasiado tiempo y esfuerzo.  

Al corregir el error, las páginas problemáticas se vuelven a indexar de manera automática, afortunadamente. Esto fue lo que pasó con el sitio Angular.io, a pesar de durar tanto tiempo y las páginas indexadas tanto tiempo que generó pérdida de tráfico. 

La complejidad del rastreo de JavaScript

En el caso del HTML tradicional, todo es fácil y directo, gracias también a que fue el primer lenguaje de programación para páginas web, así como también a pesar de sus revisiones como HTML5 el proceso sigue siendo igual, con indexación similar y abordaje de errores también poco particular. 

Javascript y SEO

Así es como se busca, procesa y se muestra contenido en HTML por parte de Google, al menos explicado de manera sencilla y dejando atrás el apartado técnico:  

  • Googlebot descarga un archivo HTML.
  • Googlebot extrae los enlaces del código fuente y puede visitarlos simultáneamente.
  • Googlebot descarga los archivos CSS.
  • Googlebot envía todos los recursos descargados al indexador. 
  • El indexador indexa la página.

Como se puede ver, todo es bastante rápido y se reduce básicamente en los cincos pasos anteriores. No obstante, las cosas se complican bastante cuando se trata de un sitio web basado en JavaScript, como se puede ver a continuación respecto a los pasos que siguen los buscadores para mostrar finalmente el sitio:

  • Googlebot descarga un archivo HTML.
  • Googlebot descarga los archivos CSS y JavaScript.
  • Posteriormente, Googlebot tiene que usar el servicio de procesamiento web de Google, una parte del indexador para analizar, compilar y ejecutar un código JavaScript.
  • Luego, WRS recupera los datos de las API externas, de la base de datos, ETC. 
  • Finalmente, el indexador puede indexar el contenido.
  • Ahora Google puede descubrir nuevos enlaces y agregarlos a la cola de rastreo de Googlebot.

Agregando dos pasos más, todo el proceso de mostrar páginas en JavaScript por parte de los motores de búsqueda es mucho más complicado, al menos en comparación directa con el rastreo de HTML. Por ejemplo, los siguientes aspectos o características deben tenerse en cuenta cuando se trata de sitios construidos bajo este lenguaje

  • El análisis, compilación y ejecución de archivos JavaScript requiere mucho tiempo.
  • En el caso de un sitio web rico en JavaScript, Google tiene que esperar hasta que se realicen todos los pasos antes de poder indexar el contenido, y obviamente luego mostrarlo.
  • El procesado no es lo único que es más lento, sino que también hay que abordar un proceso de descubrimiento de nuevos enlaces, el cual tarda más. Con sitios web ricos en JavaScript, es común que Google no pueda descubrir nuevas dirección URL sin esperar antes hasta que se pueda procesar y mostrar una página.

Ahora, para ilustrar el problema de la complejidad de JavaScript con más propiedad, se pueden utilizar las métricas respecto a tiempo de descarga de páginas en dispositivos móviles, siendo utilizados por al menos el setenta por ciento de los usuarios hoy en día en línea. 

Por ejemplo, a un dispositivo de gama alta actual como un Samsung Galaxy S10 le toma 650 milisegundos analizar solamente 1 MB de datos en JavaScript, mientras que a uno de gama media le tomará el doble de ese tiempo, al menos 1 segundo por MB analizado. 

No sólo eso, luego del análisis viene la compilación y ejecución, por lo que cada segundo cuenta. Sin embargo, este tema ya tiene que ver más con aspecto de presupuesto de rastreo e indexación.  

Por otra parte, responsables detrás de Google declararon oficialmente hace poco que: el procesamiento y representación de los sitios web basados ​​en JavaScript en la búsqueda de Google se pausa, hasta que Googlebot cuente con los recursos disponibles para procesar ese contenido. 

En otras palabras Google espera recursos de hardware y software en primer lugar para indexar, procesar y mostrar contenido en JS, por lo que requiere más capacidad de procesamiento y dispositivos más rápidos para ofrecer una mejor experiencia.   

Entonces, en igualdad de condiciones se necesita mucho más tiempo para rastrear e indexar sitios web de JavaScript que los de HTML, y es que el proceso de procesamiento y representación lleva mucho tiempo y la página se pone automáticamente en ola de indexación y procesado.  

Respecto a este tema, hay dos olas de indexación con distintas características a mencionar. En la primera ola, Google indexa el código fuente de la página, aunque es común en los sitios web modernos de JavaScript que la fuente no contenga ninguna copia de contenido. En este caso, Google no indexa prácticamente nada porque técnicamente no puede, le es imposible.

Luego, cuando los recursos de procesamiento están disponibles, Google procesa la página y finalmente puede indexar el contenido real, dejando que el sitio web se clasifique en los resultados de búsqueda y se muestre a los usuarios para que pueda ser visitado.  

Esto tiene fuertes implicaciones desde todo punto de vista del tráfico de la página y cómo la aborda el motor de búsqueda y su clasificación. Si se tiene un sitio web en JavaScript grande y en constante cambio, Google puede tener dificultades para rastrearlo e indexarlo, lo que al mismo tiempo y de manera directa afecta su tráfico y métricas. 

Se puede poner un ejemplo. En una suposición un sitio web de venta de productos médicos por lo general publica el mismo anuncio en muchos sitios web. Entonces, si Google indexa las ofertas en los sitios web de los competidores del sitio en unas pocas horas, y las ofertas en el propio se indexan en una semana o más, se perdería bastante dinero, siendo superado por la competencia. 

En conclusión, no hay ningún punto en el contenido caducado de la indexación de Google y ningún punto para que los usuarios vean ese contenido, por lo que la rapidez en la indexación tiene que ser rápida para no caer en esos inconvenientes que significan en pérdida de dinero y tráfico, haciéndose primordial la optimización adecuada y más si es en JavaScript, por más compleja y particular que resulte.  

Limitaciones técnicas de Google

Un punto importante al momento de analizar el SEO enfocado en JavaScript son las limitaciones que tiene el motor de búsqueda de Google, el cual sí que las tiene aunque parezca increíble de saber. Y es que, dichas limitaciones son importante para saber por qué Google puede tener problemas con un sitio web en JavaScript concreto o plataformas en general. 

La mayoría de usuarios utilizan su navegador de preferencia completamente actualizado, ya sea Chrome, Mozilla, Edge, Opera, Safari y otros. 

Pues, la realidad es que Google como base de Googlebot o robot de rastreo no utiliza la última versión de navegador, sino que trabajó sobre Chrome 41 para procesar los sitios web. Esta versión del navegador oficial de la empresa de Mountain View tiene ya 4 años, y en ese tiempo JavaScript y otras tecnologías han avanzado y desarrollado de manera significativa. 

Entonces, no es sorpresa que haya muchas características modernas de plataformas como JS y otras que simplemente no son accesibles a Googlebot. Por ejemplo, algunas de las principales limitaciones que se presentan por el uso de este navegador sin actualizar son:

  • Chrome 41 admite la sintaxis moderna de JavaScript de ES6 solamente manera parcial. Por ejemplo, dicha versión de navegador no admite construcciones como «dejar» fuera del «modo estricto.» 
  • Las interfaces como IndexedDB y WebSQL están deshabilitadas de modo completo. 
  • Las cookies y el almacenamiento local y de sesión se borran en todas las cargas de página, sin importar cuantas veces se visiten, por lo que no cargarán más rápido así se usen repetidas veces. 
  • Y por si fuera poco, no hay que olvidar que es una versión de navegador de más de 4 años de antigüedad. 

Para no ir tan lejos, Google Chrome se encuentra en la actualidad en la versión 75 del software, lo que hace ver la antigüedad de la versión de la cual el motor de búsqueda hace uso como base para indexar, procesar y mostrar resultados. A día de hoy, no se sabe la razón por la cual esto sucede. 

Ahora que se sabe que Google usa Chrome 41 para procesar el contenido de páginas web e indexarlas, una recomendación es tomarse el tiempo para descargar tal versión de navegador y verificar que los sitios web de interés se pueden procesar correctamente. 

Si no es así, hay que revisar el registro de la consola en Chrome 41 para ver cuál puede ser la causa. Puede parecer tedioso, pero es la única de verificar el funcionamiento, al menos hasta que Google actualice el navegador. 

Usando características de JavaScript moderno y actualizado

Claro que es posible utilizar las características modernas de JavaScript y de los sitios programados con dicho lenguaje, sólo que debe hacerse manera manual y no tan intuitiva, pero sí que es realizable. 

JavaScript es una plataforma que ha crecido rápidamente y ahora es más rápida, optimizada y con recursos que nunca. Sin embargo, algunas funciones de JavaScript simplemente no están implementadas en los navegadores más antiguos, como es de esperarse ya que dichas funciones estaban en desarrollo al momento de estar vigentes esas versiones de navegador. 

Pues, Chrome 41 es un ejemplo de un navegador muy antiguo para los estándares tecnológicos, y como resultado el acceso a páginas, indexación y procesamiento se ven perjudicados y afectan naturalmente al sitio. 

Para eso los desarrolladores web pueden usar distintas estrategias y evitar la versión de navegador obsoleta y sus efectos, cómo hacer un degradado sutil del sitio web. 

Si se desean implementar algunas características modernas que solamente son compatibles con algunos navegadores, hay que asegurarse de que el sitio web se degrade sutilmente en un navegador antiguo. Hay que recordar: Googlebot definitivamente no es un navegador moderno, teniendo al menos 4 años de haberse lanzado la versión de Chrome 41. 

Por ejemplo, al realizar una detección de características, se puede verificar si el navegador admite una característica en cualquier momento.

Además, si se desea que el sitio web sea procesado por la búsqueda de Google, sin duda se debe hacer uso de la herramienta de transposición a ES5, que es traducir estos estatutos de JavaScript que Googlebot no puede entender a las que sí puede entender. 

Cuando un transpiler encuentra «let x = 5», que es un estatuto que muchos navegadores antiguos no pueden entender, se traduce a «var x = 5», que es lo mismo a una expresión que es totalmente comprensible para los navegadores más antiguos, incluido Chrome 41 que usa Google para procesar. 

Entonces, si se está utilizando las funciones modernas de JavaScript y es importante que Google muestre correctamente los sitios web en cuestión, definitivamente se debería usar una transpilación a ES5. Si algunos conceptos parecen extraños como transpilación o transpiler, los mismos son importantes y base de la jerga en inglés relacionada con JavaScript SEO. 

Googlebot realmente no actúa como un navegador genuino 

Cuando se está navegando por Internet, el navegador preferido del que hace uso el usuario como Chrome, Firefox, Opera, o cualquier otro, descarga todos los recursos como imágenes, scripts, hojas de estilo, entre otros materiales y contenido y lo muestra en vista procesada, o como pudiera llamarse de otra manera se muestra el sitio de manera organizada como un rompecabezas. 

No obstante, Googlebot actúa de manera completamente diferente a un navegador, ya que su objetivo es rastrear todo el Internet y obtener solo los recursos valiosos. 

Entonces, en realidad el motor de Google funciona como una gran navegador que necesita de muchos recursos para buscar en todo el ciberespacio, como si fuera un gran archivero del cual se seleccionan solo archivos que son importantes o que se corresponden con la búsqueda, cada segundo y funcionando por siempre.  

Pero claro, siendo la World Wide Web un lugar increíblemente grande donde se alojan miles de millones de sitios con contenido, Google optimiza sus rastreadores para el rendimiento, rapidez en la búsqueda y enfoque en parámetros concretos, que son luego los que arman la lista de resultados. 

Esta es la razón por la que los rastreadores de Google en ocasiones no visitan todas las páginas que desean los desarrolladores web, ya que o no están bien optimizadas o tienen problemas técnicos u otros que hacen que los rastreadores las descarten. 

Lo más importante aquí es que los algoritmos de Google intentan detectar si un recurso es necesario, desde un punto de vista de procesado y contenido. Si no es de eso modo, probablemente no será recuperado por Googlebot. 

Por lo tanto, es posible que Google no seleccione algunos de los archivos JavaScript, debido a que su algoritmo decidió que no son necesario desde el punto de vista del procesado, o simplemente debido a problemas de rendimiento, es decir, demoró demasiado en ejecutar un script o hubo otro inconveniente o hay páginas caídas. 

De acuerdo a estudios, hay algunos comportamientos interesantes de que tienen los rastreadores de Google. Un ejemplo es que cuando se utiliza la función de JavaScript setTimeout, se le indica a un navegador real que espere un tiempo determinado. 

En cambio, los rastreadores no esperan y todo se ejecuta de manera inmediata.  Tal realidad no debería de sorprender, ya que los robots de Google tienen que rastrear todo el internet, por lo que deberían estar optimizados para el rendimiento, rapidez y eficiencia. 

La regla de 5 segundos

Aunque no se especifica el tiempo de espera exacto, se dice que Google no puede esperar un script de más de 5 segundos, y de hecho hay experimentos y estudios que confirman esta regla a día de hoy. 

John Mueller; Jefe del Departamento de Desarrollo Web y Análisis de Google, como voz autorizada en el tema habló y dijo lo siguiente sobre el JavaScript SEO: 

“No definimos ningún valor de tiempo de espera específico, principalmente porque el tiempo necesario para recuperar los recursos no es determinístico o comparable a un navegador, debido al almacenamiento en caché, la carga del servidor, entre otros factores. 5 segundos es una buena cosa para apuntar, sospecho que a muchos sitios les resultará difícil llegar allí…” 

Hasta ahora, no se ha encontrado ningún buen recurso en los tiempos de espera de Google, ya que es extremadamente difícil de depurar. Probablemente, se tienen en cuenta los siguientes factores:

  • Importancia y autoridad de la página.
  • Los servidores actuales de Google se cargan.
  • Número de direcciones URL en la cola de procesado. 
  • Otras heurísticas avanzadas.

Si un sitio web se carga lento, aparte de perder visibilidad respecto a Google y sus rastreadores y desperdiciar tráfico, es más lo que se puede perder, haciendo crítica la optimización del sitio web en todos los aspectos, especialmente en JavaScript. Estas son las consecuencias de tener un sitio en línea lento: 

  • Los usuarios se sentirán irritados y podrán abandonar su sitio web, aumentando el rango de rebote que afecta las métricas y visibilidad del sitio. 
  • Google podría tener problemas relacionados con el procesado y posterior mostrado del contenido.
  • Puede ralentizar el proceso de rastreo. Si se tiene página es lenta, Googlebot puede notar que sus rastreadores están ralentizando el sitio web y decidirán disminuir la velocidad de rastreo, aunque esto tiene más que ver con el presupuesto de indexación y rastreo. 

Para evitar los inconvenientes anteriormente mencionados y sus graves consecuencias, lo que se recomienda es asegurarse que el sitio web sea liviano y de que su servidor responda rápido, así como de que tal servidor no falle cuando la carga aumente. 

En ese sentido, es importante contratar buenos servicios de web hosting, quizá no dedicados pero al menos compartido y optimizado basado en virtualización para asignación de recursos. Así se evita que el trabajo de los rastreadores de Google sea más difícil de lo que debería ser en primera instancia. 

Un error de rendimiento común cometido por los desarrolladores web es colocar todos los códigos de los componentes en un solo archivo. Si los usuarios navegan a una página de inicio, realmente no necesitan descargar el código utilizado solo en el área de administración o en otras secciones, loa cual acelera el proceso de carga y procesado. 

Como ver un sitio web como hace Google y optimizarlo

Para optimizar un sitio de buena manera, ya sea que se construya en JavaScript, HTML u otro lenguaje, para que tenga éxito respecto a SEO, sea visible y todas sus páginas sean indexadas para generar buen tráfico, lo que se debe hacer en primer lugar es tratar de ver un sitio como lo haría Google en sí mismo. Para lograr este cometido hay dos métodos que pueden llevarse a cabo:  

  • Usar la herramienta de búsqueda y procesamiento de la Consola de Búsqueda de Google, como herramientas obvias de las cuales sacar provecho. Aunque, no se aconseja fiarse al ciento por ciento de los datos. El Googlebot real puede tener diferentes tiempos de espera que Fetch y Render.
  • Usar Chrome 41 como se mencionó antes. Se confirma que Google usa este navegador para llevar a cabo el procesado. El uso de Chrome 41 tiene muchas ventajas sobre la búsqueda por parte de la Consola de Búsqueda de Google, como las siguientes:
  • Gracias a usar Chrome 41, se puede ver el registro de la consola. Entonces, si se observan errores en Chrome se puede estar casi seguro de que Googlebot también recibe los errores.
  • Fetch and Render no muestran el DOM procesado, pero Chrome 41 sí lo muestra. Al usar Chrome 41, es posible asegurarse de que Googlebot pueda ver los enlaces del sitios, el contenido de las pestañas, entre otros. 
  • Utilizar la herramienta de prueba de resultados ricos, ya que esta herramienta puede mostrar cómo interpretó Google el sitio web y sus páginas. De la misma manera, muestra el DOM procesado que es muy útil.  Google planea agregar la salida de DOM procesada a su herramienta Fetch and Render. Como aún no está terminado, John Mueller aconsejó usar la herramienta de Pruebas de Resultados Enriquecidos para ello. En este momento, no está claro si los Resultados Enriquecidos siguen las mismas reglas de procesado que el indexador de Google.
  • Usar la prueba de sitio optimizado para sitios móviles de Google, ya que la misma puede mostrar el DOM procesado y los errores que Google encontró al procesar la página. Afortunadamente, de acuerdo a John Mueller siguen las mismas reglas de procesado que el servicio web de Google/Chrome 41.

Aquí una comparación rápida de herramientas que puede utilizar para garantizar que Google pueda representar su sitio web.

La función Fetch and Render de la Consola de Búsqueda de Google solo puede indicar si Google es técnicamente capaz de procesar. Sin embargo, no hay que confiarse en los datos mostrados cuando se trata de tiempos de espera. 

Y es que, es común que suceda que Google Fetch and Render puede procesar e indexar una página, pero el indexador de Google no pudo indexar el contenido debido a los tiempos de espera que encontró. Lo anteriormente expuesto puede mostrarse con un pequeño experimento para dejar evidencia: 

  • El primer archivo JavaScript incluido en esta página se retrasó 120 segundos. No había opción técnica para omitir el retraso. El servidor Nginx recibió instrucciones de esperar 2 minutos. 

  • Resultó que Fetch y Render esperaron 120 segundos por un script y procesaron la página correctamente.
  • Pero el indexador fue menos paciente y no esperó por la carga del script o 120 segundos, lo cual es una eternidad respecto a una carga de sitio y búsqueda.

  • Aquí, el indexador de Google acaba de omitir el primer script que se retrasó 120 segundos y procesa y muestra el resto de la página.

Como se puede ver, la Consola de Búsqueda de Google es una gran herramienta, pero la misma debe usarse solamente para verificar si Google es técnicamente capaz de procesar y representar  una página. 

Por otro lado, no se recomienda su uso si lo que se busca es asegurarse de que Google esperará los scripts, ya que como confirmó el experimento esa información puede no ser segura en la práctica. 

No se recomienda analizar Google Cache al auditar sitios web ricos en JavaScript

Muchos profesionales en SEO solían observar de manera más rápida y simple problemas de procesado mediante el uso de Google Cache. 

Sin embargo, esta técnica no es válida para los sitios web ricos en JavaScript, porque la memoria caché de Google en sí es solo el HTML inicial sin formato, la cual recibieron los rastreadores de Google del servidor, como informaría John Mueller en línea frecuentes veces.  

Entonces, lo que se ve al hacer clic en la caché es cómo el navegador que se está utilizando en el momento interpreta el HTML recopilado por Googlebot, siendo totalmente ajeno a cómo Google representó el sitio.

Utilizar el comando «sitio» en lugar de Google Cache

Por el momento, una de las mejores opciones para verificar si Google indexa algún contenido es el comando «sitio». Para hacer esto, simplemente lo que hay que hacer es copiar un fragmento de texto de la página y escribir el siguiente comando en Google: site: {su sitio web} “{fragmento}”. En realidad es una fórmula simple y efectiva de escribir. 

Si al hacerlo aparece un fragmento con el fragmento del sitio utilizado, eso significa que el contenido está indexado por el motor de búsqueda de manera correcta. Aunque, se recomienda realizar una consulta de «sitio:» con un fragmento en modo incógnito utilizando el navegador preferido, los cuales la mayoría de los modernos tienen dicho modo disponible. 

Por otro lado, en algunos casos en los que los editores cambiaron el contenido, por alguna razón la consulta del comando «sitio» seguía «reclamando» que el contenido anterior todavía estaba allí. Después de cambiar al modo de incógnito en el navegador, la consulta del comando «sitio» estaba obteniendo los resultados correctos, y por eso es que se recomienda usar este modo en el navegador. 

Uso de la función “Ver origen de página” no es suficiente auditar sitios en JavaScript  

En detalle, HTML es un archivo que representa solo la información en bruto utilizada por el navegador para analizar la página, lo cual es de conocimiento común. Asimismo, tal archivo Contiene algunas marcas como párrafos, imágenes, enlaces y referencias a archivos JS y CSS.

Se puede ver el HTML inicial de una página de un sitio simplemente haciendo clic derecho -> Ver fuente de la página, es así de simple. Sin embargo, al verlo no se verá ningún contenido dinámico actualizado por JavaScript. 

Entonces, en su lugar se debe mirar el DOM, lo cual se puede hacer dando clic derecho -> Inspeccionar elemento. La diferencia entre el HTML inicial del servidor y DOM las dos principales que se observan a continuación: 

  • El HTML inicial de un servidor mediante clic derecho -> Ver fuente de la página es solo un archivo de referencia simple, ya que el mismo proporciona información sobre el sitio, pero de manera sencilla y no representa sus aspectos técnicos realmente.  
  • El archivo DOM que se genera mediante clic derecho -> inspeccionar elemento es el archivo completo del sitio. Al principio, es solo un archivo simple o un documento HTML y luego, después de un tiempo obtiene un formulario y se genera y procesa la página completa. 

Como nota final, si Google no puede procesar un sitio puede indexar solo el HTML inicial que no contiene contenido actualizado dinámicamente. Así, el sitio no se procesa pero hay posibilidades de indexarlo y no simplemente pasa desapercibido.

Errores comunes con los sitios web en JavaScript 

Cuando se construyen sitios en JavaScript se tienen a cometer ciertos errores que resultan comunes, tanto en aspecto técnico como también en lo que respecta a optimización en motores de búsqueda o SEO. A continuación, se muestra una lista de esos errores comunes para que sea mucho más sencillo evitarlo.

Bloqueo de archivos JavaScript y CSS para robots de Google 

Dado que los robots de Google pueden rastrear JavaScript y representar el contenido, hay que asegurarse que los recursos internos y externos necesarios para el procesado no estén bloqueados para tales robots. 

Usar la consola de búsqueda de google

La recomendación respecto a esta plataforma es que si se ve una caída significativa en el ranking en el caso de un sitio web robusto, se debe consultar la sección Fetch and Render para ver si Google todavía puede procesar e indexar el sitio web.

En general, es una buena práctica usar Fetch and Render en una muestra aleatoria de dirección URL de vez en cuando, con el propósito de asegurarse que un sitio web se muestre correctamente.

Enfoque en el evento “OnClick” – Googlebot no hace clic

Hay que recordar que Googlebot no es un usuario real de manera obvia, así que hay que dar por sentado que no hace clic, no llena los formularios ni lleva a cabo ningún tipo de proceso como lo haría un usuario real. En la realidad, esto tiene muchas implicaciones prácticas, aunque se enumeran solamente dos a continuación: 

  1. Si se tiene una tienda en línea y el contenido oculto bajo el botón «mostrar más» no aparece en el DOM antes de hacer clic, es una señal clara de que Google no lo va a ver. Nota importante: También se refiere a los enlaces del menú en páginas facetadas. 
  2. Todos los enlaces deben contener el parámetro «HREF» sin excepción. Si solamente se utiliza el evento OnClick, Google no recogerá estos enlaces y no los tomará para indexar y procesar. Si no se está seguro respecto a los enlaces y si los tomará Google o no, a continuación se muestra lo que dijo John Mueller al respecto. 

Inyectando etiquetas canónicas a través de JavaScript

Cuando se desea utilizar etiquetas canónicas, es mejor asegurarse de que estén colocadas en etiquetas HTML/X-robots simples. Por el contrario, las etiquetas canónicas inyectadas por JavaScript se consideran menos confiables y es muy probable que Google las ignore, entonces no tiene sentido utilizarlas en un sitio programado en SJ. 

John Mueller lo confirmó este problema mediante Twitter, por lo que la afirmación viene de palabra certificada y busca que los desarrolladores no pierdan el tiempo con tal estrategia perdida.

Como nota a tener en cuenta, aunque hay grandes experimentos SEO creados por Eoghan Henn que demuestran que es posible que Google respete los datos canónicos inyectados por JavaScript, al parecer Google de igual modo no tomaría esos datos en cuenta a la hora de indexar. 

John Mueller como voz autorizada tampoco lo recomendó, publicando un tweet donde lo explicaba de manera clara: 

«No me gustaría confiar en esto, sin embargo, si realmente desea una URL como canónica, haga el trabajo para obtener la señal desde el principio». 

Concretamente, la opinión de Mueller se basa en algunas observaciones internas realizadas en Google, las cuales demuestran que las etiquetas canónicas en HTML son más confiables que las inyectadas por JavaScript, como se expresó anteriormente. 

Utilizar guiones en direcciones URL

Aunque parezca mentira, todavía es común que muchos marcos de JavaScript generen direcciones URL con un hashtag. Así, existe el peligro real de que los rastreadores de Google no puedan rastrear dichas direcciones URL. A continuación, ejemplos de direcciones correctas e incorrectas:

  • Dirección URL incorrecta: ejemplo.com/#/home-page/
  • Dirección URL incorrecta: ejemplo.com # URL
  • Dirección URL correcta: example.com/home-page/

Se podría pensar, no debería ser importante en absoluto este tipo de aclaración, ya que es solo un único carácter adicional que se agrega a la dirección URL. Pues, en realidad sí que es importante para la indexación de los sitios y la visibilidad de los mismos. Aquí está John Mueller de nuevo con una de sus valiosas aclaratorias: 

«(…) Para nosotros (Google), si vemos el tipo de hashtag allí, entonces eso significa que el resto probablemente sea irrelevante. En su mayor parte, lo descartaremos cuando intentemos indexar el contenido (…). Cuando desee que el contenido sea realmente visible en la búsqueda, es importante que use las URL de aspecto más estático».

En otras palabras, eliminar los hashtag de las direcciones URL en la medida de lo posible es lo más recomendable. También, hay que asegurarse de que la dirección URL en el sitio no luzca así en ninguna página: ejemplo.com/recurso#dsfsd. 

Angular 1 por defecto es una tecnología que usa direcciones URL basadas en hashtag. Sin embargo, tal cuestión puede solucionarse configurando el parámetro $ locationProvider, aunque por supuesto debe hacerlo alguien que sepa o mediante tutoriales en línea. 

Afortunadamente, Angular 2 utiliza las URL compatibles con Google de forma predeterminada, por lo que sin duda es la plataforma a utilizar, respecto a evitar las molestias de los guiones y otros caracteres en las direcciones URL. 

Scripts lentos ocasionarán API lentas

Muchos sitios web basados ​​en JavaScript fallan porque Google tiene que esperar demasiado para una secuencia de comandos, tales como descarga, análisis y ejecución, teniéndolos que hacer de manera obligatoria para procesar e indexar los sitios. 

Así, esta es la razón por la que obviamente esperar que los robots de Google consuman presupuesto de rastreo es lo que sucede. Para evitar esto, hay que asegurarse que los scripts del sitio sean rápidos y que Google no tenga que esperar demasiado para obtenerlos. 

Mal SEO y SEO tradicional 

En este punto, es de valor un momento y abordar un problema que podría afectar incluso al mejor SEO, y es el hecho de que el SEO enfocado a JavaScript es distinto al SEO tradicional, con estrategias diferentes y que no deben ser considerados sinónimos, como se ha visto a lo largo de esta guía y las diferencias entre páginas construidas en HTML más clásicas, en comparación con aquellas hechas bajo JS.

Así, es importante recordar que de hecho el JavaScript SEO se realiza por encima del SEO tradicional, y es imposible ser bueno en el primero sin ser bueno en el segundo, ya que uno es la base primordial y general. 

De manera frecuente, cuando se encuentra un problema de naturaleza de SEO en cualquier plataforma respecto a tráfico, visibilidad y clasificación en lugares de búsqueda, el primer instinto podría ser que está relacionado con JavaScript si el sitio está hecho bajo ese lenguaje, cuando en realidad está relacionado con el SEO tradicional y es por eso hay que aclarar la diferencia. 

Gran cambio al Google ya no usar el esquema de rastreo AJAX desde 2018

Google anunció que ya no utilizará el esquema de rastreo de Ajax tradicional a partir del segundo trimestre de 2018. Pero, en detalle: ¿Significa esto que Google dejará de rastrear sitios web utilizando Ajax o JavaScript Asíncrono? No, en realidad no es eso para nada lo que significa. 

Para explicar rápidamente qué era el antiguo Esquema de Rastreo AJAX, Google se dio cuenta de que cada vez más sitios web estaban usando JavaScript. Pero, el inconveniente fue que en ese momento no pudieron procesar tal plataforma, al no contar con los medios técnicos o de recursos, aunque en realidad a día de hoy no está claro cuál fue la razón. 

Entonces, los ejecutivos y jefes detrás de la empresa le pidieron a los desarrolladores web que: “Por favor crearán una versión optimizada con arañas, sin JavaScript, de cada página que se ofrezca y háganlas accesibles para los usuarios, agregando _ = escaped_fragment_ =…” a la dirección URL. Esto es básicamente el esquema de rastreo Ajax. 

Entonces, cuando los usuarios estaban viendo cualquier sitio web y lo disfrutaban, los robots de Google estaban visitando su equivalente «feo»: example.com?_=escaped_fragment_=, sin que los visitantes lo notaran nunca. Así es como funciona: 

Con esto, los desarrolladores web pudieron matar dos pájaros de un tiro. Tanto los usuarios como los rastreadores estaban satisfechos, ya que los usuarios estaban recibiendo un sitio web rico en JavaScript, y los motores de búsqueda pudieron indexar correctamente el contenido al recibir HTML+CSS regular como lenguaje que ya conocían. 

Sin embargo, el antiguo Esquema de Rastreo Ajax no era una solución perfecta. Dado que los usuarios recibían una versión diferente de una página que las mismas arañas, detectar problemas técnicos relacionados era realmente difícil. Además, algunos desarrolladores web tuvieron algunos problemas con el procesado previo del contenido para los robots de Google. 

Por esta razón, Google anunció que en el segundo trimestre de 2018 los desarrolladores web ya no necesitarán construir dos versiones diferentes de un sitio web. Pero, ¿qué significa esto concretamente para un sitio en específico?:

  • Google procesará un sitio web en su extremo, lo que significa que hay que asegurarse obligatoriamente de que Google técnicamente podrá hacerlo.
  • Los robots de Google dejarán de visitar las direcciones URL «feas» o que contienen un fragmento escapado, y comenzará a solicitar la misma dirección URL que los usuarios, sin necesidad de que hayan dualidades. 
  • Además, habrá la necesidad de encontrar una manera de hacer que el sitio web sea rastreable y reproducible para Bing y otros motores de búsqueda que están muy por detrás de Google cuando se trata de la representación de JavaScript. 

Las posibles soluciones incluyen el procesado con base en servidor o un JavaScript universal, o sacar provecho de que inclusive se usa todavía el antiguo Esquema de rastreo Ajax para Bingbot. Se va a discutir este tema más adelante en el artículo.

Respondiendo si Google utilizará el navegador más reciente para procesar e indexar contenido

Por ahora, no está claro si Google planea actualizar su servicio de indexado y procesado para admitir las tecnologías más recientes. Sin embargo, es lo que se espera por todos aquellos profesionales SEO, desarrolladores y creadores de páginas, no solamente en JavaScript sino en otros lenguajes de programación. 

Lo que sucede si no se confía en que Google será capaz de procesar un sitio 

De acuerdo a John Mueller sobre si se puede detectar Googlebot por el agente de usuario y solo servir una versión pre-procesada para Googlebot, él respondería en el Foro de SEO de JavaScript: 

John Mueller está de acuerdo en que es posible detectar Googlebot al verificar el agente de usuario y entregarle una instantánea HTML pre-procesada. Además de eso, él aconsejó monitorear la versión pre-procesada regularmente para asegurarse de que el pre-procesado funcione correctamente.

También, durante la conferencia de Google I/O, John Mueller confirmó una vez más que se puede detectar Googlebot por agente de usuario y entregarle una versión pre-procesada, mientras que los usuarios obtienen un sitio web normal que se actualiza dinámicamente

Esto es lo mejor de ambos mundos para los usuarios y Googlebot. La experiencia del usuario sigue siendo la misma, mientras que Googlebot obtiene una instantánea procesada previamente que se puede rastrear e indexar de forma más fácil y rápida, optimizando el proceso y aumentando la eficiencia y velocidad.  

Indexacion javascript SEO

Bing: El otro navegador disponible en línea

Si se asume que los robots de Google procesan JavaScript perfectamente y no se tiene ningún problema con esto, tal situación dejaría el trabajo para Bing: el motor de búsqueda que ofrece Microsoft y que la mayoría olvida, pero que no significa que no sea valioso practicar SEO y SEO JavaScript en el mismo. 

De hecho, este buscador es utilizado por un tercio de los usuarios en línea actuales en los Estados Unidos, poco a poco expandiéndose y dando batalla a Google a pesar de que se encuentra algo lejano en la carrera por la supremacía de los motores de búsqueda que solo reina Google. 

Respecto JavaScript y Bing, por ahora es seguro asumir que el buscador no procesa este lenguaje de programación, aunque hay muchos rumores de que Bing está procesando JavaScript en páginas de alta autoridad, pero hasta ahora son solo eso, rumores que son difíciles de probar. 

A continuación, un caso interesante respecto a cómo Bing se comporta en relación a plataformas y sitios basados en JavaScript. 

Un ejemplo es la plataforma Angular.io que es el sitio web oficial de Angular 2+. Algunas páginas de Angular.Io se crean utilizando el enfoque de aplicación de una sola página. En palabras simples, eso significa que el HTML inicial no tiene contenido, y luego un archivo JS externo carga todo el contenido necesario. 

Al parecer, Bing no puede ver el contenido de Angular.io como muestra la imagen. Este sitio web ocupa el puesto número 2 para «Angular» en Bing. Si se cambia el ejemplo por «Angular4» nuevamente, se ubica en el segundo lugar, detrás de AngularJS.org que es un sitio web oficial de Angular 1.

Si se desean conocer más pruebas de que Bing no puede manejar Angular.io, con intentar encontrar cualquier fragmento relacionado con el sitio mediante el comando «sitio» se puede lograr, ya que es imposible aparezca uno. 

La verdad es que resulta un poco raro. Concretamente Bingbot no puede rastrear e indexar correctamente el sitio web oficial de Angular 2.

¿Pre-procesado o JavaScript Isomórfico? He ahí la cuestión

Cuando hay evidencia de que Google está teniendo problemas indexando y procesando un sitio, dos opciones a considerar son el pre-procesado o el JavaScript Isomórfico. Pero, ¿de qué se tratan exactamente estos métodos y cómo funcionan? Se explicará de manera breve a continuación: 

  • Pre-procesado: el pre-procesado es cuando los rastreadores de los motores de búsqueda no pueden rastrear un sitio web y, básicamente, el desarrollador lo hace por su cuenta. Cuando un rastreador visita un sitio web, simplemente toma una HTML instantánea sin JS.

Al mismo tiempo, los usuarios obtienen la versión rica en JavaScript de la página. La instantánea es utilizada sólo por los robots, no por los usuarios normales. También, se pueden usar servicios externos para el procesado previo como Prerender.io, o usar herramientas como PhantomJS o Chrome Headless en el servidor.

  • JavaScript Isomorfo es otro enfoque popular. Aquí, tanto el usuario como los motores de búsqueda reciben una página llena de contenido en la carga inicial. Luego, todas las características ricas en JavaScript se cargan encima de esto. 

Este método es bueno tanto para los usuarios como para los motores de búsqueda. Es la opción más recomendada, incluso por especialistas y profesionales en el tema de desarrollo web y para SEO

Sin embargo hay un problema: muchos desarrolladores luchan con la implementación de JavaScript isomorfo. Para esto, se recomienda verificar los documentos del marco del sitio para saber cómo hacer el procesado basado en servidor en el marco de JavaScript del sitio. En lo que respecta a la plataforma Angular, se puede usar Angular Universal.

Por otra parte, en noviembre de 2018 fue lanzada la plataforma React 16, la cual ha traído muchas mejoras con respecto a procesado basado en servidor. Una de las nuevas opciones en React 16 es la función «RenderToNodeStream» que facilita todo el procesado del lado del servidor (SSR).

Con respecto a los desarrolladores, si se desea que un sitio web se procese en el servidor, hay que evitar el uso de funciones que operan directamente en el DOM. Para esto se puede citar a Wassim Chegham, un experto en desarrollo de Google: «Una de las mejores prácticas y más importantes que recomendaría a continuación es: Nunca hay que tocar el DOM».

Interrogante: ¿Los robots de Google tratan igual a los sitios web en HTML y en JavaScript?

Varios expertos en SEO han realizado algunos experimentos, con el propósito de investigar qué tan profundo pueden moverse los robots de Google al descubrir y seguir enlaces en el caso de los sitios HTML, así como también programados en JavaScript.

Los resultados del experimento fueron sorprendentes en todo el sentido de la palabra. En el caso del sitio web HTML, Googlebot pudo llegar a todas las páginas. Sin embargo, en el caso del sitio web de JS, era común que Googlebot ni siquiera pudiera alcanzar el segundo nivel. Para estar seguro, se repitió el experimento en 5 dominios diferentes, pero los resultados fueron siempre los mismos.

De acuerdo a John Mueller, se confirmó que Google de hecho “ve” los enlaces JavaScript, pero Googlebot no tenía ganas de rastrearlos, por decirlo de alguna manera y con aspectos que tienen que ver con eficiencia, uso de recursos y prioridad.

Asimismo, Mueller Añadió: «No rastreamos todas las URL, ni las rastreamos todas rápidamente, especialmente cuando nuestros algoritmos no están seguros del valor de la dirección URL…”

Lo más importante a tomar en cuenta 

  • Google usa Chrome 41 para procesar sitios web. Esta versión de Chrome se lanzó en 2015, por lo que no es compatible con todas las funciones modernas de JavaScript. Entonces, se puede usar Chrome 41 para asegurarse de que Google pueda representar el contenido de un sitio. 
  • Por lo general, no es suficiente analizar solamente la página de origen (HTML) de un sitio web. En su lugar, se debe analizar el DOM mediante los pasos clic con el botón derecho -> herramienta de inspección.
  • Google es el único motor de búsqueda que muestra JavaScript a escala, a pesar de no hacerlo tan óptimamente como en los sitios en HTML. Aunque, buscadores competencia como Yandex o Bing simplemente no indexan ni procesan sitios en JS. 
  • No se debe usar el caché de Google para verificar cómo Google indexa el contenido. Solo le indica cómo el navegador usado en el momento interpretó el HTML recopilado por Googlebot. No tiene ninguna relación con la forma en que Google representó un contenido o sitio específico.
  • Usar la herramienta Fetch and Render a menudo es recomendable. No obstante, no hay que confiarse en los tiempos de espera mostrados por la herramienta. Los tiempos de espera de indexación pueden ser totalmente diferentes
  • El comando “sitio:” es ideal para usar.
  • Hay que asegurarse que aparezca un menú en el DOM antes de hacer clic en cualquier elemento del menú.
  • Los algoritmos de Google intentan detectar si un recurso es necesario desde un punto de vista de procesado. Si no, probablemente no será recuperado por Googlebot porque los mismos están diseñados para ser eficientes, rápidos y ahorrar recursos.
  • Se debe asegurar que los scripts de un sitio sean rápidos. Respecto a esto, muchos experimentos señalan que es poco probable que Google espere un script por más de 5 segundos. Asegurarse que el servidor utilizado no se ralentiza cuando aumenta la carga del mismo es necesario. Además, trata de optimizar los scripts.
  • Si Google no puede procesar un sitio, se puede recoger solo el HTML sin procesar para la indexación. Aunque, esto puede interrumpir su aplicación de una sola página (SPA), porque Google puede indexar sólo una página en blanco. 

En conclusión

La rama de SEO no está segura de sí Google trata y clasifica los sitios web basados en JavaScript, así como los sitios basados en HTML, con indicios e ideas que solamente ofrecen experimentos realizados. 

Con este conocimiento, está claro que el SEO y los desarrolladores están empezando a comprender cómo hacer que los marcos de JavaScript modernos sean rastreables. Por lo tanto, es importante recordar que no hay una regla única para todos. 

Cada sitio web es diferente, y si se planea crear una plataforma web rica en JavaScript, es mejor asegurarse de trabajar con desarrolladores y SEO que conozcan su trabajo, con pautas similares a las aquí mostradas para facilitar la indexación, procesado y rastreo de los sitios en JS para que generen tráfico, visitas y puedan servir al éxito de una empresa, negocio u organización.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acepto la política de privacidad *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

METODOLOGÍA QUE CONVIERTE Y MONETIZA

Si tienes un negocio online, un proyecto digital, estás planteando en montar un ecommerce y no sabes como monetizarlo, ponte en contacto conmigo. Llevo años monetizando casi todo tipo de webs. Juntos podemos desarrollar una metodología que se adapte a tu caso, sea escalable y te permita rentabilizarla.

¿Hablamos?

Casos de éxito nacionales