MeshLine
¿Debería aplicar carga diferida al contenido para SEO? La regla del viewport que mantiene las páginas visibles
Conoce la regla del viewport que decide cuándo la carga diferida es segura para el SEO, cómo corregir el scroll infinito y cómo verificar que Google ve tu contenido renderizado.
La carga diferida (lazy loading) pospone la carga de imágenes, videos y secciones de la página hasta que un visitante las necesita.
Bien implementada, acelera las páginas y reduce el ancho de banda desperdiciado.
Mal implementada, oculta contenido de Google por completo.
La diferencia se reduce a una regla: el contenido debe cargarse cuando entra en el viewport, no cuando el usuario hace scroll, hace clic o toca la pantalla.
Por qué la carga diferida puede ocultar contenido de Google
La Búsqueda de Google no interactúa con tu página.
No hace scroll, no hace clic en botones ni toca acordeones.
Googlebot obtiene la página y su Web Rendering Service la renderiza, pero todo lo que solo aparece después de una acción humana nunca se muestra durante ese renderizado.
La guía de Google sobre carga diferida es explícita: no dependas de acciones del usuario, como scroll o clic, para cargar el contenido (Google, Fix lazy-loaded content).
Eso significa que una galería que carga imágenes solo cuando alguien desliza, o una descripción de producto que aparece solo después de un clic, es invisible para el rastreador.
La página puede verse bien para ti en un navegador.
En el HTML renderizado que Google ve, el contenido simplemente no está ahí.
La regla del viewport
El patrón seguro es sencillo: carga el contenido relevante siempre que se vuelva visible en el viewport.
La carga basada en el viewport funciona porque el servicio de renderizado posiciona el contenido igual que lo hace un navegador.
Cuando una sección estaría en pantalla, se carga, ya sea que esté mirando una persona o un rastreador.
Google enumera tres métodos que cumplen este estándar (Google, Fix lazy-loaded content):
- Carga diferida integrada del navegador para imágenes e iframes.
- La API IntersectionObserver, con un polyfill para navegadores antiguos.
- Una biblioteca de JavaScript que permita cargar datos cuando entran en el viewport.
Los tres se activan por posición, no por interacción.
Si tu implementación actual espera un controlador de eventos de scroll, un clic en un botón de 'cargar más' o un toque para expandir una sección, no pasa esta prueba.
No apliques carga diferida a la primera pantalla
Hay una segunda regla que importa para los usuarios, no solo para los rastreadores.
Google desaconseja añadir carga diferida al contenido que probablemente sea visible de inmediato al abrir una página (Google, Fix lazy-loaded content).
Posponer el contenido de la parte superior de la página retrasa lo que el visitante vino a buscar, y ese retraso es muy notorio.
En la práctica, esto significa que tu imagen principal, titular, foto de producto principal o párrafo inicial deben cargarse con normalidad.
Reserva la carga diferida para el contenido más abajo de la página: videos incrustados, secciones con muchas imágenes, hilos de comentarios, carruseles de elementos relacionados.
El compromiso es real.
Aplicar carga diferida a todo maximiza el peso diferido, pero arriesga tanto la experiencia del usuario como la indexación.
No aplicar carga diferida a nada es seguro, pero desperdicia mejoras de rendimiento.
La regla del viewport te da la línea divisoria: debajo del primer pliegue, cargar al hacerse visible; en la parte superior, cargar de inmediato.
El scroll infinito necesita URLs reales
El scroll infinito es donde la carga diferida rompe la indexación con más frecuencia.
Si un artículo largo o un listado carga más fragmentos al hacer scroll, Google solo puede indexarlos si cada fragmento tiene su propia dirección.
Los requisitos de Google para un scroll infinito indexable son específicos (Google, Fix lazy-loaded content):
- Dale a cada fragmento una URL persistente y única, como ?page=12.
- Mantén el contenido de cada URL igual cada vez que se carga. Evita valores relativos como ?date=yesterday.
- Enlaza de forma secuencial a las URLs individuales para que los buscadores puedan descubrir todo el conjunto paginado.
- Cuando un nuevo fragmento se convierte en el elemento visible principal, actualiza la URL mostrada con la History API para que los usuarios puedan actualizar, compartir y enlazar a ella.
Si tu scroll infinito no tiene nada de esto, los fragmentos más allá de la primera pantalla son efectivamente no indexables.
Convertirlos a URLs paginadas es la solución, y también mejora el uso compartido y la analítica, ya que cada fragmento se convierte en una página distinta y direccionable.
Cómo verificar si Google ve tu contenido
No tienes que adivinar.
Google ofrece dos herramientas para ver la versión renderizada de una página: la Prueba de resultados enriquecidos y la inspección de URLs en Search Console (Google).
Estas herramientas muestran los recursos cargados, la salida de la consola de JavaScript y el DOM renderizado.
La verificación práctica para la carga diferida es simple.
Ejecuta una URL en la Herramienta de inspección de URLs y revisa el HTML renderizado.
Si las URLs de tus imágenes o videos aparecen en el atributo src de los elementos img o video del HTML renderizado, tu configuración funciona (Google, Fix lazy-loaded content).
Si los marcadores de posición siguen ahí y faltan las fuentes reales, Google no puede ver ese contenido.
Ejecuta esta verificación en tus plantillas más importantes, no solo en una página: un artículo, un listado con scroll infinito y una página de producto con galería en pestañas.
Una página que pasa la prueba no demuestra que el patrón se cumpla en todas partes.
Riesgos de JavaScript relacionados que conviene conocer
Los problemas de carga diferida suelen enmarcarse en un panorama más amplio de renderizado de JavaScript.
Algunos comportamientos documentados en la guía de solución de problemas de JavaScript de Google vale la pena tener en mente (Google, Fix Search-related JavaScript problems):
- Googlebot puede omitir la obtención de recursos que ha identificado como no contribuyentes al contenido esencial de la página, por lo que los scripts y solicitudes no esenciales pueden comportarse de forma distinta a tu contenido principal.
- El servicio de renderizado no conserva el estado entre cargas de página. El almacenamiento local, el almacenamiento de sesión y las cookies se borran, por lo que cualquier contenido que dependa de un estado almacenado no aparecerá en un renderizado nuevo.
- Los fragmentos de URL como #/products no se pueden considerar confiables para cargar contenido diferente ante Googlebot. Usa la History API con URLs reales en su lugar.
- Las aplicaciones de una sola página que devuelven un estado 200 para contenido inexistente arriesgan que se indexen errores soft 404. Redirige a una URL real con estado 404 o añade una metaetiqueta robots noindex cuando el contenido no exista.
No son errores de carga diferida, pero comparten causa: contenido que solo existe tras un comportamiento del cliente que el rastreador no realiza.
Si estás auditando la carga diferida, vale la pena revisar estos puntos al mismo tiempo.
Un orden práctico de implementación
Para un equipo que coordina sistemas de marketing y ventas, la secuencia que funciona es:
- Inventariar qué plantillas usan carga diferida y qué la activa: observación del viewport, eventos de scroll, clics o toques.
- Reemplazar los activadores basados en interacción por otros basados en el viewport, o usar la carga integrada del navegador para imágenes e iframes.
- Eliminar la carga diferida del contenido de la parte superior de la página.
- Convertir el scroll infinito en URLs paginadas y enlazadas de forma secuencial.
- Verificar cada plantilla con la Herramienta de inspección de URLs y confirmar que el contenido aparece en el HTML renderizado.
Trata el paso de verificación como parte de tu control de calidad de contenido, no como un proyecto único.
Las plantillas cambian, las bibliotecas se actualizan, y un patrón que pasó el trimestre pasado puede regresar silenciosamente.
Incorporar una verificación del HTML renderizado en tu regla de decisión de control de calidad de contenido mantiene la solución duradera.
Si varios equipos publican en el mismo sitio, escribe la regla del viewport en tu regla de gobernanza de contenido para que las nuevas plantillas la hereden.
Cuando la respuesta es no
A veces la decisión correcta es no aplicar carga diferida en absoluto.
Si la página es corta, sus imágenes pequeñas o el costo de una implementación correcta supera el beneficio, carga todo con normalidad.
La carga diferida es una herramienta de rendimiento, no una obligación.
La única obligación, desde la perspectiva de búsqueda, es que todo lo que publiques esté presente en el HTML renderizado que Google ve.
Para los equipos de contenido que planifican flujos de publicación, el mismo principio aplica aguas arriba: decide qué debe mostrar cada página antes de decidir cómo se carga.
Para mecánicas de publicación más amplias, nuestra guía sobre programar entradas o publicar ahora (en inglés) cubre un compromiso similar entre comodidad y control.
Para páginas con muchas imágenes, revisa qué extensiones de sitemap activar según el tipo de contenido para que videos e imágenes se descubran junto con sus páginas.
La carga diferida es segura para el SEO cuando el contenido se carga al hacerse visible en el viewport, el contenido de la parte superior se carga de inmediato, los fragmentos del scroll infinito tienen URLs persistentes, y verificas el HTML renderizado en la Herramienta de inspección de URLs.
Cómo puede ayudar Meshline.
Conecta automatización, Marketing Orgánico (generación de demanda) y gestión del ciclo de vida del cliente (Inteligencia de Ingresos).
Integra la planificación de temas, la publicación de contenido y la retroalimentación de rendimiento en la conversación sobre tu flujo de trabajo. Reserva una demo de Meshline.