Tasa de captura de instantáneas

Tasa de Captura de Snapshot (SCR) es una métrica de fiabilidad del renderizado: el porcentaje de intentos de rastreo que generan un snapshot completo y indexable de una URL. En términos sencillos, te indica con qué frecuencia los bots obtienen la página que crees que deberían obtener. Esto importa porque los sitios con mucho JavaScript pueden verse bien para los usuarios y, aun así, fallar para los rastreadores.

La fórmula de trabajo es simple: snapshots renderizados correctamente / intentos de rastreo totales x 100. Si la SCR baja de 99% a 92%, no es un simple ajuste por redondeo. En un ecommerce con 500,000 URLs, puede significar que decenas de miles de páginas no se pueden rastrear de forma intermitente o que solo se renderizan parcialmente.

Por qué los equipos de SEO la rastrean

La SCR es, básicamente, la “disponibilidad del renderizado” para la búsqueda. Ayuda a explicar pérdidas de posicionamiento que las comprobaciones técnicas estándar suelen pasar por alto: bloqueos de archivos JS, fallos de hidratación, timeouts en el edge, desafíos del WAF, APIs inestables y problemas de CDN. Screaming Frog puede detectar recursos bloqueados y diferencias en el HTML renderizado. GSC puede mostrar anomalías de rastreo y cambios en el estado indexado. Los logs del servidor te dicen si a los bots se les sirvieron respuestas 200 que aun así terminaron renderizándose en basura.

Aquí es donde muchos equipos se vuelven descuidados. Monitorizan códigos de estado, no el resultado renderizado. Una respuesta 200 no es éxito si nunca carga la cuadrícula de productos.

Cómo medirla en la práctica

No existe una métrica nativa de Google llamada Snapshot Capture Rate. Esto es una métrica operativa de SEO, no un factor de ranking oficial. Debes construirla a partir de múltiples fuentes:

• Google Search Console: Estadísticas de rastreo para la dirección de la tendencia, estado del host y patrones de respuesta.
• Logs del servidor: BigQuery, ELK, Splunk o Datadog para aislar el comportamiento de obtención de Googlebot y Bingbot.
• Rastreos renderizados: Screaming Frog en modo JavaScript, Chrome sin interfaz (headless) o pruebas personalizadas con Puppeteer.
• Monitoreo de terceros: Ahrefs y Semrush ayudan a validar el impacto posteriormente mediante cambios de visibilidad y descubrimiento de páginas, no a través del evento de renderizado en sí.

Un punto de referencia práctico: una SCR saludable a nivel de plantilla normalmente debería situarse por encima del 97% en sitios estables. Por debajo del 95%, investiga. Por debajo del 90%, trátalo como un incidente. Las páginas de detalle de producto, las plantillas de artículos y las páginas de categorías con facetas deben rastrearse por separado, porque un único componente roto puede afectar solo una sección.

Dónde se rompe la métrica

La advertencia es esta: la SCR solo es tan buena como tu definición de un “snapshot exitoso”. Si tu prueba headless indica que la página se renderizó, pero falta el canónico, falló el esquema o el contenido principal se cargó después de tu timeout, tu métrica está mintiendo. Es común caer en una falsa sensación de seguridad.

Además, Googlebot no se comporta exactamente como tu renderizador basado en Chrome. John Mueller de Google ha dicho repetidamente que las herramientas externas pueden aproximar el renderizado, no replicarlo de forma perfecta. Usa la SCR como métrica de control de ingeniería, no como sustituto directo para la indexación o el posicionamiento.

Qué hacen los buenos equipos con ella

Los buenos equipos configuran alertas por caídas de 2 a 3 puntos porcentuales a nivel de plantilla, día a día. Comparan el HTML sin procesar frente al HTML renderizado en Screaming Frog, validan en GSC los recursos bloqueados y comprueban si la visibilidad cae en Ahrefs o Semrush días o semanas después del problema de renderizado. Si ejecutas React, Vue o Next.js a gran escala, esta métrica no es opcional. Es una de las pocas formas de detectar regresiones silenciosas de renderizado antes de que Finanzas lo note.