Sitios de ingresos
Mantén la tienda, el sitio de reservas, el producto de suscripción o la web de captación bajo comprobaciones externas recurrentes.
Monitorización de disponibilidad para sitios SEO y de ingresos
Supervisa la URL pública del proyecto, revisa disponibilidad y respuestas de 30 días e investiga controles HTTP fallidos. Mantén incidentes y avisos por correo que cumplan las condiciones junto a tu trabajo SEO.
Configura controles de disponibilidad
Activa controles periódicos para la URL pública guardada en tu proyecto Screpy. Elige un destino útil para los visitantes antes de definir la frecuencia.
- Cada proyecto supervisa una URL HTTP o HTTPS, no una lista independiente de endpoints.
- Los ajustes del proyecto controlan la activación, un intervalo de 1–60 minutos y un correo opcional.
- Los controles programados requieren un plan de pago activo y compatible; los intervalos predeterminados varían.
- La inactividad del equipo alarga los intervalos; tras 30 días sin actividad, los controles se detienen.
- Último control indica la vigencia; el intervalo configurado no garantiza una ejecución a una hora exacta.
example.com60 s
Entiende el porcentaje de disponibilidad
Comprueba qué proporción de controles respondió correctamente durante los últimos 30 días. Considera también el número de controles y la última fecha.
- El porcentaje divide los controles correctos entre todos los registrados y multiplica por 100.
- El estado actual corresponde al último control completado del período.
- Sin controles registrados, los datos no están disponibles; no se muestra un 100 %.
- El porcentaje se basa en muestras: no equivale directamente a minutos de caída ni a un SLA ponderado por tiempo.
Disponibilidad
93,8 %503200
Sigue los tiempos de respuesta
Localiza respuestas más lentas y fallos repetidos en la gráfica. Una URL accesible también puede responder lentamente.
- La gráfica utiliza hasta 160 controles recientes de 30 días; el ancho de pantalla determina cuántos se ven.
- La tendencia promedia cinco controles; la respuesta media usa los controles correctos de los 30 días completos.
- Los tiempos miden latencia HTTP, no carga completa, Core Web Vitals ni recorridos de visitantes.
Tiempo de respuesta
240 msRevisa los estados HTTP
Consulta los ocho últimos controles con estado, fecha, código HTTP y tiempo de respuesta. Compáralos con la respuesta esperada de la URL pública.
- HTTP 200–399 cuenta como disponible; otras respuestas HTTP, como caída. Tiempo de espera agotado y error se registran aparte.
- No se siguen redirecciones: un resultado 3xx no confirma que el destino funcione.
- Se usa HEAD y se reintenta con GET ante 405 o 501; un fallo de conexión puede no tener código HTTP.
- Un resultado disponible no valida contenido, formularios ni compras; una página de error con HTTP 200 también puede contar como disponible.
Estado HTTP
200GET /HTTP/2 200Revisa incidentes de caída
Sigue un incidente desde el primer control fallido hasta uno posterior correcto. Investiga la causa por separado.
- El primer fallo abre un incidente; los siguientes lo actualizan y el primer control correcto lo resuelve.
- El panel muestra recuentos históricos de incidentes abiertos y resueltos y los cinco últimos con estado, inicio y detalles.
- Los tiempos reflejan controles, no el inicio exacto entre muestras; algunas caídas breves pueden pasar inadvertidas.
Periodo
12 min503200
Recibe correos de caída
Envía avisos que cumplan las condiciones a los miembros del proyecto y a un correo adicional opcional. El incidente se registra antes de que pueda enviarse el correo.
- Un fallo posterior del mismo incidente puede generar correo con códigos admitidos como 404, 500 o 503.
- Los tiempos de espera, errores de conexión y códigos no admitidos se registran, pero no generan estos correos.
- Cada proyecto tiene límites separados de un correo de caída y uno de recuperación por 24 horas.
- La recuperación requiere un incidente previamente notificado y no suprimido; su duración registrada no demuestra la caída exacta experimentada por los visitantes.
!
Proyectoexample.com
RevisiónLee disponibilidad con SEO MCP
Pide a un asistente conectado que explique resultados guardados de un proyecto accesible. Usa la fecha para distinguir datos registrados de un control nuevo.
- SEO MCP devuelve estado de 30 días, porcentaje, media de controles correctos y último control.
- Hasta 160 registros recientes incluyen estado, respuesta y fecha; el resumen omite códigos HTTP e incidentes.
- La consulta de lectura no ejecuta controles ni identifica o corrige caídas; los resultados ausentes siguen sin estar disponibles.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Añade disponibilidad a informes SEO
Incluye datos de disponibilidad en un informe guardado para un cliente o equipo. La instantánea responde a una pregunta distinta de la supervisión en directo.
- El widget incluye estadísticas de 30 días, controles recientes e incidentes que coinciden con el período del informe.
- El recuento puede diferir del histórico del panel; los incidentes resueltos pueden incluir su duración registrada.
- El informe captura datos guardados al generarse y no envía alertas en directo.
Secciones
aACMEInformePDF
Puntuación de salud87/100
Posición+24
Habla de Monitorización de disponibilidad. Con SEO MCP.
Lee con SEO MCP disponibilidad guardada de 30 días y registros recientes de estado y respuesta. Revisa la fecha antes de interpretar el estado como disponibilidad actual; no incluye incidentes ni códigos HTTP.
- Screpy: ¡Hola! Veamos Monitorización de disponibilidad para example.com. ¿Qué quieres saber?
- Tú: Explica la disponibilidad guardada y la fecha del último control de example.com.
- Screpy: Ejemplo de resultado guardado: el control de las 10:18 UTC registró disponible y un 99,95 % de controles correctos en 30 días. El porcentaje se basa en muestras y no demuestra acceso ahora. Investiga caídas con los incidentes del panel y registros de alojamiento. Resumen guardado: Último control: 10:18 UTC. Disponibilidad de 30 días: 99,95 %.
- Tú: Conviértelo en un breve plan de acción.
- Screpy: Separaré los hallazgos de las recomendaciones. Revisa las pruebas, elige un cambio y comprueba después los resultados. Tus próximos pasos: Revisa: Comprueba la fuente y fecha de cada hallazgo.. Decide: Elige el primer cambio.. Verifica: Compara los resultados después del cambio..
- Tú: ¿Puedes explicar las pruebas con palabras sencillas?
- Screpy: Sí. Pregunta por un resultado compatible y explicaré qué muestra, de dónde viene y qué sigue siendo incierto. Los datos ausentes siguen sin estar disponibles; las recomendaciones no son correcciones automáticas.
Configura un ciclo útil de monitorización de disponibilidad.
Elige un destino público, activa la supervisión y configura un correo responsable. Ante un fallo, investiga los registros actuales y confirma un control posterior correcto.
-
Usa la URL pública del proyecto
Usa la URL pública prevista del proyecto. Evita rutas con inicio de sesión y verifica los destinos de redirección aparte, porque estos controles no siguen redirecciones.
-
Activa las comprobaciones y configura el intervalo
Activa la supervisión en ajustes, guarda el intervalo y el correo opcional; confirma acceso de pago compatible y controles recientes.
-
Investiga los últimos controles fallidos
Lee estado, último control, resultados HTTP y detalles del incidente. Investiga un fallo crítico ahora; el porcentaje de 30 días aporta contexto, no justifica esperar.
-
Investiga y confirma la recuperación
Compara el fallo con registros de despliegue, DNS, TLS, alojamiento y aplicación. Confirma un control correcto; resolver el incidente no verifica todos los recorridos de visitantes.
Prioriza sitios donde el tiempo de inactividad tiene un coste real.
Usa comprobaciones recurrentes en proyectos donde la disponibilidad afecta a ventas, leads, campañas, acceso de clientes o a la recuperación de contenido público por los rastreadores.
Propiedades de búsqueda orgánica
Vigila el sitio público que deben alcanzar rastreadores y visitantes orgánicos antes de que importen el contenido o el posicionamiento.
Sitios de lanzamientos y campañas
Sigue el sitio durante lanzamientos, migraciones, rediseños y campañas activas, cuando un problema de disponibilidad tiene un coste inmediato.
Carteras con varios proyectos
Revisa el uptime de cada proyecto de Screpy por separado para mantener sitios de clientes o marcas en un solo flujo.
Conoce los límites de un resultado de uptime.
Screpy ofrece evidencia HTTP externa e historial de incidentes para el sitio configurado. Usa infraestructura, registros, pruebas de transacciones y datos de búsqueda cuando la pregunta supere ese alcance.
Un sitio por proyecto
Uptime Monitoring comprueba la URL pública configurada para el proyecto Screpy; no es una lista general de monitores de endpoints independientes.
Comprobación externa, no telemetría de infraestructura
El resultado indica si respondió el destino público. No inspecciona CPU, memoria, contenedores, bases de datos, redes privadas ni registros del servidor.
Evidencia de incidente, no prueba de causa raíz
Estado HTTP, tiempos y marcas del incidente acotan la investigación, pero no prueban si la causa fue DNS, TLS, hosting, despliegue, firewall o código.
Disponibilidad no es garantía SEO
Una página pública funcional es necesaria para visitas y rastreo, pero un uptime alto no garantiza indexación, rankings, tráfico, ingresos ni conversiones.
Usa el flujo de salud web que corresponda al fallo.
Monitoriza accesibilidad con el tiempo, audita el sitio cuando se repitan fallos o patrones de rastreo, o revisa rendimiento después de estabilizar la disponibilidad.
Revisa disponibilidad de 30 días basada en controles, respuestas, resultados HTTP e incidentes de la URL pública del proyecto.
Rastrea el sitio para encontrar páginas fallidas repetidas, problemas de redirección, destinos rotos y patrones técnicos alrededor de una incidencia.
Ejecuta controles de rendimiento en laboratorio cuando el sitio es accesible pero el tiempo de carga o la respuesta aún requieren investigación.
Documentación de Screpy
Aprende a monitorizar la disponibilidad del sitio
Aprende a elegir un destino público, configurar supervisión y avisos, interpretar respuestas e investigar incidentes.
Preguntas sobre la monitorización de disponibilidad, respondidas.
Respuestas sobre muestreo, proyectos inactivos, redirecciones, controles ausentes, condiciones del correo y rendimiento de páginas.
¿Screpy envía alertas de caída?
Un fallo posterior de un incidente abierto puede generar correo ante 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 o 526. Lo reciben miembros y un correo opcional distinto. Caída y recuperación tienen límites separados de un correo por proyecto cada 24 horas. Un incidente suprimido no se notifica más tarde; la recuperación exige un aviso de caída previo no suprimido. Los tiempos de espera, errores sin código y otros códigos no cumplen las condiciones.
¿Con qué frecuencia comprueba Screpy el uptime?
Los ajustes aceptan 1–60 minutos y requieren acceso de pago. Durante el día posterior a la actividad del equipo se usa ese intervalo; después, al menos 10 minutos y tras siete días, al menos 60. Tras 30 días inactivos se detienen los controles programados. Revisa siempre la última fecha real.
¿Una caída puede afectar al rastreo o la indexación?
Los errores persistentes del servidor pueden ralentizar el rastreo e impedir recuperar contenido. Un resultado disponible no demuestra acceso de Googlebot, destino de redirección, indexación ni posiciones. Investiga también con datos de rastreo y búsqueda.
¿Cómo funcionan los incidentes de caída y recuperación?
El primer fallo abre un incidente; los siguientes lo mantienen abierto y un control correcto lo resuelve. El panel muestra estado, inicio y detalles; los correos de recuperación elegibles incluyen duración registrada. Las muestras no precisan el inicio entre controles ni detectan necesariamente toda caída breve.
¿Qué mide Screpy Uptime Monitoring?
Screpy registra estado, código HTTP cuando existe, respuesta y fecha de una URL pública del proyecto. El panel calcula porcentaje y medias con controles de 30 días, muestra ocho controles recientes y, aparte, recuentos históricos y cinco últimos incidentes.
¿Qué considera Screpy que está disponible o caído?
HTTP 200–399 cuenta como disponible y otras respuestas HTTP como caída; tiempo de espera y error son estados separados. No se siguen redirecciones ni se valida contenido: una redirección o página de error HTTP 200 puede estar disponible sin que funcione la página prevista.
¿Uptime Monitoring muestra el historial de respuesta?
Sí. Se cargan hasta 160 respuestas recientes de 30 días y se ven menos en pantallas pequeñas. La tendencia de cinco controles difiere de la media de 30 días de controles correctos. La respuesta HTTP no mide renderizado ni interacciones.
¿Uptime Monitoring sustituye la monitorización de servidores o transacciones?
No. Screpy controla un destino HTTP(S) público. No inspecciona infraestructura privada, ejecuta inicios de sesión o compras, valida contenido, demuestra disponibilidad geográfica ni diagnostica causas. Usa registros y pruebas específicas para esas preguntas.
Potente en SEO. Ligero para tu bolsillo.
Un conjunto completo de herramientas SEO a un precio realmente asequible.
- Auditorías técnicas, seguimiento de posiciones y visibilidad en IA
- Investigación de palabras clave, backlinks y supervisión de disponibilidad
- Un espacio de trabajo. Planes flexibles. Menos gastos.
Más dinero en tu bolsillo