Scraping 101 con n8n

Scrapear es sacar datos de un sitio web que no te da una API. Si el sitio tiene los datos que necesitás pero no hay endpoint público, scraping es la forma de acceder.

En n8n esto abre workflows que antes eran imposibles: monitorear precios de competidores, armar bases de datos de leads, seguir novedades de sitios que te importan, alimentar un dashboard con datos que viven repartidos en varios lugares.

Esta guía cubre dos formas simplificadas de scrapear desde n8n:

• Apify: Un marketplace de actors (scrapers ya hechos) para diferentes sitios y plataformas como Google Maps, Instagram o LinkedIn.
• Firecrawl: Un servicio que puede recibir cualquier URL, y con sus diversas formas de scrapear, recibir resultados. Firecrawl puede incluir el uso de AI para entender los sitios que tiene que visitar.

Esta guía va a asumir que vos (lector) ya sabes usar o crear workflows básicos de n8n. Se va a asumir que tenés nada o poco conocimiento de como scrapear.

Ejemplo 1: Apify con Google Maps

Caso: Una consultora quiere armar una lista de restaurantes en Palermo con nombre, dirección, teléfono y rating. ¿Que plataforma podría tener toda está información? Google Maps. Ahora, Google Maps tiene una API que permita la busqueda de este tipo de información? No. Es un buen caso de uso donde Scraping puede ser una opción.

En el Marketplace the Apify existen varias opciones para consultar y recibir información de locales publicados. En este ejemplo, vamos a usar el siguiente actor. Google Maps Apify

Cómo funciona

1. Crearte una cuenta en Apify y sacar tu API token desde Settings → Integrations.
2. En n8n, agregás un nodo HTTP Request apuntando al endpoint del actor:
   • URL: https://api.apify.com/v2/acts/compass~google-maps-extractor/run-sync-get-dataset-items
   • Method: POST
   • Authentication: Header Auth con Authorization: Bearer TU_TOKEN
   • Body (JSON):

{
  "searchStringsArray": ["restaurantes"],
  "locationQuery": "Palermo, Buenos Aires",
  "maxCrawledPlacesPerSearch": 20
}

3. El endpoint run-sync-get-dataset-items corre el actor y te devuelve los resultados en el mismo request. Para volúmenes grandes conviene el modo asíncrono (/runs + webhook), pero para arrancar el sync alcanza.
4. Lo que te llega es un array de objetos con title, address, phone, totalScore y muchos campos más. De ahí lo mandás a Google Sheets, Airtable, o donde te sirva.

Por qué acá Apify se justifica

Google Maps no es un sitio leíble. Es una single-page app pesada en JavaScript, con anti-bot activo. Si intentaras scrapearlo con un HTTP Request crudo te devolvería una página vacía o te bloquearía directo. Apify corre un browser headless, resuelve captchas, rota proxies y te entrega el resultado limpio.

Esto tiene un precio (unos centavos de dólar por corrida chica), pero el ahorro de trabajo es enorme comparado con armarlo vos.

Ejemplo 2: Firecrawl para monitorear precios de proveedores

Caso: una pyme gastronómica quiere seguir el precio de la harina 000 x 25kg en tres proveedores mayoristas distintos, todos los días. Cada proveedor tiene su propio sitio, con HTML distinto, y ninguno tiene un actor pre-hecho en Apify.

Acá es donde Firecrawl brilla. Le pasás una URL, un schema de JSON y un prompt describiendo qué querés extraer. El servicio scrapea la página, se la manda a un LLM con tu schema y prompt, y te devuelve JSON estructurado listo para usar.

Lo importante que tenés que saber

Firecrawl tiene varias opciones que definen cómo se comporta:

• formats — qué te devuelve. Podés pedir ["markdown"] (limpio, útil para LLMs), ["html"] (crudo), o ["json"] (estructurado según tu schema). Para extraer datos, json es lo que querés.
• jsonOptions.schema — el schema JSON del output. Le decís exactamente qué campos querés y de qué tipo. Firecrawl fuerza al LLM a devolverte eso.
• jsonOptions.prompt — instrucciones en lenguaje natural sobre qué extraer. Complementa al schema.
• onlyMainContent — si es true, Firecrawl limpia headers, footers, sidebars y menús antes de procesar. Casi siempre lo querés.
• waitFor — milisegundos a esperar antes de scrapear. Útil para sitios que cargan datos con JS después del render inicial.

El workflow

1. En n8n, arrancás con un Schedule Trigger (por ejemplo, todos los días a las 9 AM).
2. Un nodo Set con la lista de URLs de los tres proveedores.
3. Split Out para iterar una URL a la vez.
4. HTTP Request al endpoint https://api.firecrawl.dev/v1/scrape:
   • Method: POST
   • Auth: Bearer token
   • Body: la URL + formats: ["json"] + tu schema y prompt
5. El response trae data.json con los campos que definiste en el schema. De ahí a Sheets, base de datos, o alerta si el precio subió o bajó.

Ejemplo de schema

{
  "type": "object",
  "properties": {
    "producto": { "type": "string" },
    "precio": { "type": "number" },
    "moneda": { "type": "string" },
    "unidad": { "type": "string" },
    "stock_disponible": { "type": "boolean" }
  },
  "required": ["producto", "precio"]
}

Con ese schema, no importa que los tres proveedores tengan HTML distinto — Firecrawl y el LLM se encargan de encontrar el precio donde esté.

Cómo elegir entre las dos

Un cuadro mental rápido:

• ¿El sitio es famoso y ya existe un actor? → Apify. Google Maps, Instagram, TikTok, Booking, Airbnb, YouTube. Alguien más ya resolvió el problema y vos consumís el resultado.
• ¿Son varios sitios distintos, o un sitio raro sin actor? → Firecrawl. Le describís qué querés extraer y funciona con lo que le tires. Bueno para monitoreo de precios en N proveedores, lectura de blogs corporativos, extracción de datos de directorios sectoriales.
• ¿Volumen muy alto y presupuesto ajustado? → Ninguna de las dos te va a cerrar el número. Ahí tenés que ir a HTTP Request + parsing manual, o a escribir código. Lo cubrimos en otro guide.

La regla informal: empezá con la más mágica que resuelva tu problema. Si funciona y el costo es razonable, quedate ahí. Si el costo se dispara o la magia falla seguido, bajá un escalón.

Ventana al motor: qué está pasando abajo

Apify y Firecrawl te esconden todo el trabajo sucio. Vale la pena saber qué es ese trabajo sucio, aunque no lo hagas vos, porque cuando algo falle vas a entender por qué.

Cuando pedís una página web, el servidor te manda HTML: un texto estructurado como este, simplificado:

<div class="producto">
  <h2 class="nombre">Harina 000 x 25kg</h2>
  <span class="precio">$8.500</span>
  <span class="stock">Disponible</span>
</div>

Scrapear, en su forma más básica, es agarrar ese texto y sacarle los datos que te importan. Para hacerlo se usan selectores: expresiones que apuntan a un pedazo del HTML. Por ejemplo, .precio significa el elemento que tiene la clase precio. Con eso un parser saca $8.500 y lo guarda en una variable.

Eso es lo que Firecrawl hace por vos cuando le pasás un prompt: le da el HTML a un LLM que actúa como parser inteligente. Apify hace algo más profundo — corre un browser real que además ejecuta JavaScript.

Y ahí aparece el otro concepto clave: HTML server-side vs. HTML renderizado por JS.

Algunos sitios (los más simples, los viejos, los estáticos) mandan el HTML con los datos ya adentro. Un HTTP Request crudo funciona.

Otros sitios (Google Maps, Instagram, la mayoría de las apps modernas) mandan un HTML casi vacío y después el JavaScript del navegador va, trae los datos por API y los inyecta. Si scrapeás con HTTP crudo no ves nada — porque el JS no corrió.

Cuando Firecrawl te devuelve un JSON vacío o Apify te tira un error, casi siempre el problema es uno de estos tres:

1. El sitio carga con JS y la herramienta no lo esperó bien (usá waitFor en Firecrawl).
2. El sitio tiene anti-bot y bloqueó la request.
3. El HTML cambió y los selectores que el actor o el LLM usaban dejaron de matchear.

Con esa intuición ya podés debuggear el 80% de los problemas que te vas a encontrar.