> ## Documentation Index > Fetch the complete documentation index at: https://docs.firecrawl.dev/llms.txt > Use this file to discover all available pages before exploring further. # Monitorización a escala de toda la web > Ejecuta búsquedas web siempre activas y envía alertas cuando aparezcan nuevos resultados coincidentes La monitorización a escala de toda la web es una búsqueda siempre activa que vigila la web y te avisa a ti o a tu agente en cuanto algo se publica. Los monitores de páginas y sitios web supervisan las URL que indicas. Un monitor a escala web vigila toda la web. En lugar de comparar cambios en páginas que ya conoces, le das `queries` para ejecutar junto con un `goal`, y Firecrawl ejecuta las consultas en cada check y envía alertas sobre los resultados **nuevos** que el evaluador considera relevantes para el objetivo. Es descubrimiento, no diffing. Cada check ejecuta el mismo ciclo: toma el objetivo y sus `queries`, aplica una ventana de recencia, ejecuta la búsqueda, deduplica los resultados por URL canónica, deja que el evaluador de IA opcional decida qué resultados nuevos son relevantes para el objetivo y envía alertas a través de los mismos canales de webhook y correo electrónico que los monitores de scraping y crawl. La programación, los objetivos, la evaluación y las notificaciones funcionan exactamente como se describe en la [Descripción general de la monitorización](/es/features/monitoring). Los monitores de páginas y crawl comparan cambios en el content de las URL que indicas; los monitores a escala web descubren resultados nuevos en toda la web. Por debajo, usan la misma programación, evaluador y notificaciones.
## Objetivo de búsqueda
Un objetivo de búsqueda usa `type: "search"` y reemplaza `urls` por las consultas que se deben ejecutar y cómo puntuar los resultados: ```json Search target theme={null} { "type": "search", "queries": ["open source AI coding assistant launch"], "searchWindow": "24h", "maxResults": 10, "includeDomains": ["news.ycombinator.com"] } ``` | Campo | Tipo | Descripción | | ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | `"search"` | Selecciona el objetivo de búsqueda. | | `queries` | `string[]` | Consultas de búsqueda que se ejecutan en cada comprobación. De 1 a 12 consultas, cada una de hasta 256 caracteres. Obligatorio. | | `searchWindow` | `"5m" \| "15m" \| "1h" \| "6h" \| "24h" \| "7d"` | Filtro de antigüedad. Solo se consideran los resultados publicados dentro de esta ventana. El valor predeterminado es `24h`. | | `maxResults` | `number` | Total de resultados que se evalúan por comprobación, `1`–`50`. El valor predeterminado es `10`. Este es un límite combinado para todas las `queries` (los resultados primero se combinan y se deduplican), no un límite por consulta. Una consulta individual puede aportar menos resultados, o ninguno, si otras consultas llenan antes el límite. | | `includeDomains` | `string[]` | Opcional. Restringe los resultados a estos dominios (hasta 50). Mutuamente excluyente con `excludeDomains`. | | `excludeDomains` | `string[]` | Opcional. Excluye los resultados de estos dominios (hasta 50). Mutuamente excluyente con `includeDomains`. | Un objetivo de búsqueda requiere un `goal` no vacío a nivel del monitor, a menos que configures `judgeEnabled: false`. `queries` es obligatorio; el `goal` es el criterio con el que el evaluador puntúa cada resultado nuevo. No genera las consultas. Consulta [Objetivos y evaluación](/es/features/monitoring#goals-and-judging). **Los créditos escalan con las consultas.** Cada consulta obtiene hasta `maxResults` resultados, y los créditos de búsqueda se facturan según los resultados brutos de todas las consultas *antes* de combinarlos y deduplicarlos. Agregar consultas aumenta el costo real de la búsqueda, no solo la estimación inicial. Después de combinar y deduplicar, Firecrawl evalúa como máximo `maxResults` candidatos seleccionados, por lo que los créditos del evaluador siguen limitados por los resultados seleccionados/evaluados.
## Crear un monitor a escala web
Un monitor a escala web se crea de la misma forma que un monitor de página. Las únicas diferencias son el objetivo (`type: "search"` con `queries`, `searchWindow`, `maxResults` y filtros de dominio opcionales) y que no hay URL: ```python Python theme={null} from firecrawl import Firecrawl firecrawl = Firecrawl( # Los endpoints de monitorización requieren una clave de API: api_key="fc-YOUR-API-KEY", ) monitor = firecrawl.create_monitor( name="AI coding assistant launches", schedule={"text": "every 30 minutes", "timezone": "UTC"}, goal="Alert when a new open-source AI coding assistant is announced. Ignore funding rounds and unrelated AI news.", targets=[ { "type": "search", "queries": ["open source AI coding assistant launch"], "searchWindow": "24h", "maxResults": 10, } ], notification={ "email": { "enabled": True, "recipients": ["alerts@example.com"], "includeDiffs": True, } }, ) print(monitor.id) ``` ```js Node theme={null} import Firecrawl from "@mendable/firecrawl-js"; const firecrawl = new Firecrawl({ // Los endpoints de monitorización requieren una clave de API: apiKey: "fc-YOUR-API-KEY", }); const monitor = await firecrawl.createMonitor({ name: "AI coding assistant launches", schedule: { text: "every 30 minutes", timezone: "UTC" }, goal: "Alert when a new open-source AI coding assistant is announced. Ignore funding rounds and unrelated AI news.", notification: { email: { enabled: true, recipients: ["alerts@example.com"], includeDiffs: true, }, }, targets: [ { type: "search", queries: ["open source AI coding assistant launch"], searchWindow: "24h", maxResults: 10, }, ], }); console.log(monitor.id); ``` ```bash cURL theme={null} curl -s -X POST "https://api.firecrawl.dev/v2/monitor" \ -H "Authorization: Bearer $FIRECRAWL_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "AI coding assistant launches", "schedule": { "text": "every 30 minutes", "timezone": "UTC" }, "goal": "Alert when a new open-source AI coding assistant is announced. Ignore funding rounds and unrelated AI news.", "notification": { "email": { "enabled": true, "recipients": ["alerts@example.com"], "includeDiffs": true } }, "targets": [ { "type": "search", "queries": ["open source AI coding assistant launch"], "searchWindow": "24h", "maxResults": 10 } ] }' ``` ```bash CLI theme={null} firecrawl monitor create \ --name "AI coding assistant launches" \ --schedule "every 30 minutes" \ --queries "open source AI coding assistant launch" \ --goal "Alert when a new open-source AI coding assistant is announced. Ignore funding rounds and unrelated AI news." ``` ```json MCP: firecrawl_monitor_create theme={null} { "queries": ["open source AI coding assistant launch"], "goal": "Alert when a new open-source AI coding assistant is announced. Ignore funding rounds and unrelated AI news.", "searchWindow": "24h", "maxResults": 10, "scheduleText": "every 30 minutes" } ``` Cuando se detecta un nuevo resultado coincidente, el webhook `monitor.page` lo informa con el estado `new` y, si se ejecutó la evaluación, un `judgment` que describe por qué es relevante: ```json monitor.page theme={null} { "success": true, "type": "monitor.page", "id": "019df960-5f2a-75fb-a98b-bd2d32ca67d4", "webhookId": "f1e2d3c4-0000-0000-0000-000000000000", "data": [ { "monitorId": "019df960-06e7-7383-9d89-82c0113dc31a", "checkId": "019df960-5f2a-75fb-a98b-bd2d32ca67d4", "url": "https://news.ycombinator.com/item?id=40000000", "status": "new", "error": null, "isMeaningful": true, "judgment": { "meaningful": true, "confidence": "high", "reason": "A new open-source AI coding assistant was announced, which matches the monitor goal." } } ], "metadata": { "environment": "production" } } ```
## Cómo redactar buenos objetivos y queries
La calidad de un monitor a escala web depende de dos factores que cumplen funciones distintas: * **`queries` controlan el recall**: qué recupera cada búsqueda. Si son demasiado limitadas, los eventos reales nunca afloran; si son demasiado amplias, el evaluador gasta créditos filtrando ruido. * **`goal` controla la precisión**: qué resultados recuperados realmente generan una alerta. El evaluador evalúa cada resultado nuevo en función del objetivo, así que el objetivo es lo que separa una coincidencia real de otra relacionada con el tema, pero irrelevante. Ajusta ambos. Un objetivo perfecto no puede alertar sobre un resultado que las queries nunca recuperaron, y unas queries amplias combinadas con un objetivo vago producen alertas constantes de poco valor. **Las buenas queries se leen como términos de búsqueda, no como frases completas:** * Usa palabras clave, no prosa: `OpenAI new model release`, no `tell me when OpenAI releases a new model`. * Pon entre comillas las entidades de varias palabras (`"Llama 4"`) y agrupa sinónimos con `OR` (`launch OR release OR announcement`). * Mantén cada query acotada (aproximadamente entre 2 y 6 términos). Una query amplia suele funcionar mejor que varias limitadas, porque las queries adicionales dividen el presupuesto de `maxResults` sin aumentar la cobertura. * Usa una query por *tema* distinto. Un mismo tema con varias facetas ("launches, benchmarks, docs") sigue siendo una sola query; divídelo solo cuando el objetivo mencione entidades realmente separadas (por ejemplo, "OpenAI, Anthropic, and Google"). * No uses los operadores `site:` / `-site:` dentro de las queries. Usa `includeDomains` / `excludeDomains` en su lugar. **Los buenos objetivos expresan la coincidencia en lenguaje claro y solo añaden exclusiones cuando forman parte de la intención:** * Nombra el tema y qué cuenta como coincidencia: *"Alert when OpenAI announces a brand-new model."* * Desambigua términos ambiguos: *"Firecrawl (the web scraping API)"* evita que el evaluador se desvíe hacia equipos contra incendios. * Añade `Ignore ...` solo para no coincidencias específicas de la intención: *"Ignore opinion pieces, tutorials, and unrelated AI news."* No repitas ruido genérico. El evaluador ya maneja el formato, los parámetros de seguimiento y los cambios por reindexación. * Si la intención es amplia, mantenla así. Los objetivos demasiado restrictivos hacen que se pierdan coincidencias reales. **Cómo se ve un monitor bien ajustado.** Un monitor a escala web bien ajustado casi siempre no reporta nada. La mayoría de las comprobaciones devuelven `new: 0`, y las alertas solo se activan cuando aparece algo realmente nuevo y alineado con el objetivo. Lee el resumen de la comprobación y el `searchStatus` de cada resultado (consulta [Statuses and dedup](#statuses-and-dedup)) para saber si está bien ajustado: * Un flujo constante de resultados `ignored` significa que las queries recuperan ruido que luego el objetivo rechaza. Ajusta las queries (o reduce `searchWindow`) para dejar de pagar por evaluar resultados que nunca generarán alertas. * Un `watching` frecuente significa que el objetivo es ambiguo. Afina los criterios de coincidencia para que el evaluador pueda decidir. * Períodos largos sin resultados en un tema activo significan que las queries son demasiado limitadas o que `searchWindow` es demasiado estrecha. Amplía los términos o ensancha la ventana. * Las alertas que el usuario descarta significan que el objetivo es demasiado amplio. Añade un `Ignore ...` específico para esa intención. El objetivo es lograr una alta precisión con suficiente recall: que cada alerta merezca atención y que no se pase por alto nada importante.
## Evaluación
La cantidad de trabajo que realiza cada comprobación por resultado está controlada por `judgeEnabled` del monitor, el mismo indicador descrito en [Objetivos y evaluación](/es/features/monitoring#goals-and-judging). Con la evaluación activada, Firecrawl hace scraping de cada resultado coincidente y evalúa su contenido en función del objetivo; se factura 1 crédito por cada resultado evaluado, además de la llamada de búsqueda. Con `judgeEnabled: false`, un monitor a escala web devuelve los resultados de búsqueda deduplicados sin ninguna evaluación de IA, solo los nuevos resultados de la SERP, y paga únicamente los créditos de la llamada de búsqueda (2 créditos por cada 10 resultados).
## Estados y deduplicación
Los resultados de búsqueda usan el **mismo enum `status` a nivel de página** que los monitores de scraping y crawl, por lo que los consumidores existentes de webhooks y resultados de checks funcionan sin cambios. Un resultado de búsqueda se corresponde con: * `new`: un resultado que coincidió con el objetivo por primera vez. Esto es lo que genera alertas. * `same`: un resultado ya visto en un check anterior (sin nueva alerta). * `error`: un resultado que no pudo evaluarse (por ejemplo, se omitió el scraping para la evaluación). El estado de búsqueda más detallado se expone en `metadata.searchStatus` de cada página, y puede ser uno de estos valores: | `searchStatus` | `status` de la página | Significado | | -------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------- | | `alert` | `new` | Nuevo resultado que el evaluador considera significativo; envía una notificación. | | `already_seen` | `same` | La huella digital coincidió con un resultado de un check anterior. | | `watching` | `same` | Nuevo resultado sobre el que el evaluador aún no tiene suficiente confianza; se registra, pero no genera alerta. | | `ignored` | `same` | Nuevo resultado que el evaluador clasificó como no significativo para el objetivo. | | `skipped` | `error` | El resultado no pudo evaluarse en este check (por ejemplo, por un fallo de scraping o una evaluación degradada). | Un resultado genera una alerta una sola vez, cuando aparece por primera vez como `new`. La deduplicación se basa únicamente en la URL canónica (el título y el fragmento se excluyen deliberadamente de la huella digital, por lo que un cambio en el título o el fragmento no vuelve a disparar la alerta). Como la clave es la URL, un mismo evento del mundo real reportado en muchas URL de artículos genera una alerta una vez por URL, no una vez por evento. Editar el `goal` o las `queries` del monitor incrementa su `goalVersion`, lo que invalida los veredictos previos del evaluador. La reevaluación es diferida, no una reevaluación masiva: no se vuelven a evaluar todos los resultados a la vez. En su lugar, cada resultado se vuelve a evaluar la próxima vez que reaparece en un check, y entonces adopta la nueva `goalVersion`. Los resultados que no reaparecen conservan su veredicto anterior y su `goalVersion` hasta que vuelvan a aparecer.
## Configuración compartida
* [Programación](/es/features/monitoring#schedules): cadencia con cron o en lenguaje natural, mínimo 5 minutos. * [Objetivos y evaluación](/es/features/monitoring#goals-and-judging): obligatorio para objetivos de búsqueda, salvo que `judgeEnabled: false`. * [Notificaciones](/es/features/monitoring#notifications): entrega por webhook y correo electrónico. * [Resultados de las comprobaciones](/es/features/monitoring#check-results): inspecciona cada comprobación y sus resultados. * [Precios](/es/features/monitoring#pricing): 2 créditos por cada 10 resultados en cada comprobación, más 1 crédito por cada resultado evaluado.