Comprobar estado HTTP
Un enlace roto casi nunca avisa; simplemente se queda ahí devolviendo un 404 o agotando el tiempo de espera mientras nadie lo está viendo. Esta API para comprobar el estado HTTP recibe una lista de URLs, consulta cada una y reporta el código de estado y la latencia de respuesta de todas y cada una, convirtiendo una revisión manual clic a clic en una tarea por lotes que ya no tiene que recordar ejecutar.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
El problema de escala al revisar enlaces a mano
Hacer clic en diez enlaces para confirmar que cargan es una tarea de cinco minutos; hacer lo mismo con un mapa del sitio de mil URLs, o con cada enlace saliente de una página de recursos que distintas personas editan a lo largo del tiempo, no es algo que nadie repita a mano de forma confiable más de una vez. Los enlaces se descomponen en silencio —un sitio aliado se reestructura, un recurso se mueve, una página se elimina— y la única forma de detectarlo de forma consistente es preguntar de verdad.
Qué devuelve el endpoint para cada URL
Envíe una lista de URLs a POST /web/status y la tarea consulta cada una de forma independiente, devolviendo el código de estado HTTP recibido y cuánto tardó la respuesta, por URL, en un único resultado estructurado. Eso significa tener un 200 con 180 milisegundos junto a un 404 sin cuerpo y un 500 con cinco segundos de retraso, todo en el mismo reporte, listo para filtrar y ordenar por código o por velocidad.
Por qué vale la pena leer los códigos de estado con precisión
La clasificación de códigos de estado se ha mantenido notablemente estable desde que se formalizó hace décadas justamente porque las categorías son útiles: 2xx significa que funcionó, 3xx significa que se movió a otro lugar, 4xx significa que el problema estaba en la solicitud, 5xx significa que el servidor falló al procesarla. Una página que antes devolvía 200 y ahora devuelve 500 bajo carga es un problema muy distinto a una que silenciosamente devuelve 404 porque la borraron, y agruparlas a todas como simplemente 'rota' oculta qué equipo tiene que arreglar qué.
Cómo encaja en el monitoreo continuo
Como la comprobación corre de forma asíncrona y reporta por webhook firmado, está pensada para ejecutarse en un horario —cada noche sobre un mapa del sitio, cada hora sobre un conjunto de páginas críticas, o bajo demanda justo después de una migración de contenido— sin que una persona esté vigilando una hoja de cálculo. Su naturaleza por lotes hace que revisar una URL o mil cueste el mismo esfuerzo de configurar.
Leer la latencia junto al estado
Una respuesta 200 solo cuenta la mitad de la historia si tardó seis segundos en llegar; combinar el código de estado con el tiempo de respuesta en el mismo reporte detecta la degradación lenta que precede a una caída total, algo que una comprobación de solo estado pasaría por alto hasta que ya fuera demasiado tarde.
Qué puede hacer con ella
Auditorías de mapa del sitio y enlaces rotos
Escanee un mapa del sitio completo con regularidad para detectar errores 404 y de servidor antes de que los buscadores o los visitantes los encuentren primero.
Verificación tras una migración de contenido
Después de mover páginas a una nueva plataforma, confirme que cada URL antigua resuelve correctamente o redirige, en vez de morir en silencio.
Chequeos puntuales de disponibilidad
Revise un conjunto de endpoints críticos bajo demanda cuando algo se siente mal, sin montar una plataforma completa de monitoreo.
Higiene de enlaces en directorios y recursos
Verifique periódicamente que los enlaces salientes de una página de recursos curada o un directorio sigan apuntando a páginas vivas y que responden.
Preguntas frecuentes
¿Qué devuelve la API para comprobar el estado HTTP?
Para cada URL enviada, devuelve el código de estado HTTP recibido y la latencia de respuesta, entregado como un único resultado estructurado y firmado que cubre toda la lista.
¿Cuántas URLs puedo revisar en un solo lote?
Envíe tantas URLs como necesite como tareas asíncronas individuales; el modelo está pensado para escalar desde una sola comprobación hasta un mapa del sitio completo.
¿Me dice si una URL redirige?
Reporta el código de estado devuelto, incluyendo códigos de redirección 3xx; para el recorrido completo salto a salto de una redirección, el comprobador de cadena de redirecciones dedicado profundiza más.
¿Existe un plan gratuito?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Cómo recibo los resultados?
Mediante un webhook firmado cuando la tarea se completa, recomendado para flujos automatizados, o un enlace firmado válido por 24 horas.
¿Se me cobra si una comprobación falla?
No. Una tarea fallida se reintenta automáticamente hasta tres veces sin costo; solo se cobran las comprobaciones completadas.
¿Cuánto cuesta cada solicitud?
$0.002 por solicitud, un precio fijo tanto si la respuesta es instantánea como si agota el tiempo de espera.
¿Puedo programarla para que corra automáticamente?
Sí, dispárela desde una tarea programada o un pipeline con la frecuencia que necesite y deje que el webhook firmado entregue los resultados sin consultar manualmente.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/status \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/status", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/status",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/status", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/status", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"url": "https://ejemplo.com"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.status",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |