Si llevas tiempo monitorizando tus rankings, es posible que hayas notado un patrón inquietante, que yo empecé a ver con claridad en varias webs a mediados de 2025. El síntoma es claro y doloroso: revisas tu posición en escritorio y estás orgulloso, quizás en un Top 3 o Top 5. Sin embargo, sacas tu teléfono, buscas lo mismo y… sorpresa. Estás en la página 2, posición 35 o peor.
Y lo más grave: con el paso de las semanas, esa sólida posición de escritorio empieza a caer hasta igualarse con la del móvil, hundiéndote en la irrelevancia. Muchos culpan al «bloat» de Elementor, DIVI o Visual Composer. Otros culpan a una actualización del algoritmo. Pero mi análisis técnico apunta a algo más específico: Google está descargando tu contenido, pero no lo está procesando entero. Google no ha confirmado nada de esto oficialmente, así que tómalo como lo que es, una hipótesis de trabajo que he comprobado en webs reales y que se diagnostica fácil (te enseño cómo más abajo).
El culpable no es el maquetador en sí, sino cómo lo estamos optimizando: el abuso del JavaScript Delay en un entorno Mobile-First.
La trampa de la optimización de velocidad (WPO)
En nuestra obsesión por conseguir un 100/100 en PageSpeed Insights y mejorar las Core Web Vitals, hemos abusado de una funcionalidad que ofrecen plugins como WP Rocket, Perfmatters o SiteGround Optimizer: «Retrasar la ejecución de JavaScript» (Delay JavaScript Execution).
Sobre el papel, es genial. Esta función le dice al navegador: «No cargues ningún script pesado (como los de Elementor) hasta que el usuario interactúe».
La interacción se define como:
- Mover el ratón.
- Hacer scroll.
- Tocar la pantalla.
El usuario real entra, mueve el dedo y la web carga instantáneamente. Todos felices. ¿Pero quién entra a tu web y no interactúa? Exacto: Googlebot.
El «cloaking» involuntario
Googlebot Smartphone (desde julio de 2024, el único rastreador con el que Google indexa) es un visitante pasivo. No hace scroll, no hace clic y no mueve el ratón. Si tu contenido principal, tu menú de navegación o la estructura de tus enlaces internos dependen de un JavaScript que está «dormido» esperando un clic que nunca llegará, Googlebot ve una página rota o vacía.
Esto genera lo que yo llamo un "Cloaking Involuntario":
- El usuario ve una web rica, interactiva y completa.
- Google ve un HTML plano, a menudo desestructurado y sin los elementos clave que inyecta el maquetador.
Técnicamente, estás mostrando contenido diferente al usuario y al bot. No es que Google te vaya a castigar por cloaking (eso es para quien lo hace a propósito), pero el efecto es casi igual de malo: posiciona la versión pobre que ha visto, no la que ven tus clientes.
El problema del render budget y la profundidad del DOM
No es solo que Google no vea el JS. Es un problema de recursos. Google tiene que «pintar» millones de páginas, y no le dedica tiempo ilimitado a cada una (es lo que en el sector llamamos render budget). Google no publica ese límite, pero cuanto más pesada y compleja es la página, más fácil es que se quede a medias.
Maquetadores como Elementor generan una estructura DOM muy profunda (muchos «nodos» o capas: div > sección > columna > widget). Las versiones actuales de Elementor lo han mejorado con los contenedores flexbox, que quitan capas respecto a las antiguas secciones y columnas; si tu web sigue maquetada con secciones, convertirla a contenedores ya es una mejora.
- Si Google tiene que descargar el HTML.
- Luego esperar a ver si el JS carga.
- Y además lidiar con una estructura de nodos infinita…
A menudo, corta el proceso antes de terminar. Lee el código fuente (sabe que el texto está ahí), pero no lo procesa visualmente (renderizado). Si no lo renderiza, no entiende la jerarquía ni la relevancia del contenido.
La anatomía de la caída: de la página 1 a la 4
Lo que estás viendo en tus métricas sigue una lógica aplastante dentro del sistema Mobile-First Indexing:
- La discrepancia inicial: tienes autoridad histórica: enlaces, años de buen contenido, una versión antigua de la página que Google procesó bien. En escritorio, esas señales todavía te sostienen en el 4º puesto.
- La realidad móvil: el rastreador móvil vuelve a procesar tu página y falla por el JS Delay, o se queda a medias. Para sus ojos, ahora tu página es pobre, y en las búsquedas desde el móvil, donde además pesan más la experiencia y la velocidad, te vas a la posición 35.
- La consolidación: como solo hay un índice, y se alimenta de lo que ve el rastreador móvil, esa versión pobre acaba siendo la única que Google tiene de tu página.
- El desplome: tu posición en escritorio cae hasta coincidir con la del móvil. Adiós al tráfico.
Cómo confirmar si te está pasando (diagnóstico)
No hace falta adivinar. Google Search Console te dice la verdad:
- Ve a Inspección de URL.
- Introduce una URL de tu sitio y pulsa Enter.
- Haz clic en «Probar URL publicada» (botón arriba a la derecha).
- Espera a que termine y haz clic en «Ver página probada».
- Vete a la pestaña captura de pantalla.
¿Qué ves? Si ves la página en blanco, elementos superpuestos, falta el menú o el texto principal no aparece, eso es exactamente lo que Google está indexando. Tienes un problema de renderizado.
La solución: defer vs. delay
No tienes que dejar de usar Elementor, pero debes cambiar tu estrategia de WPO.
1. Cambia «delay» por «defer»
La mayoría de plugins de caché permiten elegir.
- Delay (retrasar): espera a que el usuario interactúe (malo para el SEO si es agresivo).
- Defer (aplazar): descarga el JS sin bloquear el renderizado y lo ejecuta cuando el HTML ya está listo, automáticamente, sin esperar a que nadie toque la pantalla.
Usa Defer para todo lo que sea estructural (maquetadores, menús, contenido). Deja el Delay solo para cosas prescindibles como el Chat de soporte, el Pixel de Facebook o comentarios de terceros.
Ejemplo en WP Rocket
Si la web está hecha con Elementor, lo interesante es decirle al plugin que cargue los scripts de Elementor de inmediato, para que Googlebot pueda renderizar bien la página. WP Rocket tiene «exclusiones con un clic» para Elementor y Elementor Pro. Puede que sacrifiques algo de puntuación en PageSpeed (ojo, haz siempre las comprobaciones después de cada cambio).
A cambio, te aseguras de que se cargan todos los scripts y todo el HTML que necesita la página. Os dejo por aquí la guía de WP Rocket que lo explica al detalle. Merece la pena echarle un vistazo.
Ejemplo LiteSpeed Cache
En LiteSpeed Cache, se ve la cosa más clara rápidamente, en los botones.
2. Exclusiones quirúrgicas
Si necesitas mantener el JS Delay para pasar las Core Web Vitals, debes excluir obligatoriamente los archivos del núcleo de tu web.
En la configuración de «Excluir archivos JS del retraso», asegúrate de añadir:
- jquery.min.js (Fundamental para WordPress).
- elementor-frontend (O los equivalentes de Divi/Visual Composer).
- /wp-content/themes/tu-tema/js/ (Scripts de navegación del tema).
Para Elementor, por ejemplo, la documentación de WP Rocket recomendaba añadir esto como exclusión (revisa la guía, porque las rutas cambian con las versiones):
/jquery(-migrate)?-?([0-9.]+)?(.min|.slim|.slim.min)?js(?(.*))?( |’|»|>|$)
/elementor-pro/assets/
lib/sticky/jquery.sticky.min.js
3. CSS crítico
Asegúrate de que tu plugin de caché esté generando correctamente el CSS Crítico. Esto permite que la página tenga «forma» y estilo visual instantáneo usando solo HTML y CSS, facilitando que Google entienda la estructura visual antes incluso de procesar el JavaScript.
Conclusión
El SEO técnico en 2025 y 2026 ya no va solo de palabras clave o enlaces. Va de garantizar que Google vea lo mismo que tus usuarios. Si tienes que elegir entre un 100 en PageSpeed con una web que Google ve en blanco, o un 85 en PageSpeed con una web totalmente renderizable, elige siempre lo segundo. De nada sirve ser el sitio más rápido de la web si Google piensa que estás vacío.
Si necesitas ayuda con todo esto echa un vistazo a mi servicio de SEO técnico y WPO; estaré encantado de ayudarte.
