Si llevas tiempo monitorizando tus rankings, es posible que hayas notado un patrón inquietante desde mediados de este año (especialmente visible desde junio/julio). 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á leyendo tu contenido, pero no lo está procesando.
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 mouse.
- 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 (el rastreador principal de Google hoy en día) es un visitante pasivo. No hace scroll, no hace clic y no mueve el mouse. 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. Y a Google no le gusta eso.
El problema del render budget y la profundidad del DOM
No es solo que Google no vea el JS. Es un problema de recursos. Desde mediados de año, parece que Google ha ajustado su Render Budget (la cantidad de tiempo y recursos de CPU que dedica a «pintar» tu página).
Maquetadores como Elementor generan una estructura DOM muy profunda (muchos «nodos» o capas: div > sección > columna > widget).
- 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. Tu versión de escritorio (que Google rastrea menos) aún recuerda que tu sitio es bueno. Te mantiene 4º.
- La Realidad Móvil: El índice principal (móvil) intenta renderizar tu página. Falla por el JS Delay o se queda a medias por falta de presupuesto de renderizado. Te coloca en la posición 35 porque, para sus ojos, tu página es pobre.
- La Consolidación: Como ya no existen dos índices separados, la señal de «página pobre» del rastreo móvil acaba sobrescribiendo la señal histórica de escritorio.
- El Desplome: Tu ranking de escritorio cae para coincidir con la realidad 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 interacción (Malo para SEO si es agresivo).
- Defer (Aplazar-diferida): Carga el JS al final de la carga de la página, sin bloquear el renderizado, pero se ejecuta 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 WPRocket
En este caso, ya que se está utilizando Elementor sería interesante añadirle una orden al plugin para que cargue Elementor de inmediato. Para que el Googlebot pueda renderizar correctamente la web. Esto puede suponer sacrificar algo de WPO y deshabilitar esta funcionalidad del plugin. (Ojo hacer las comprobaciones correspondientes).
Pero nos podemos asegurar que cargue todos los scripts correspondientes en la web + todo el código HTML correspondiente. Os dejo por aquí el enlace de WPRocket que lo comenta al detalle. Es interesante pegarle 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).
En Elementor por ejemplo lo que añade la documentación de WPRocket, es añadir esto como exclusión.
\/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 pega un vistazo a mi página de servicios WPO, estaré encantado de ayudarte.
