Scraper de tol.ar — estado y hoja de ruta

Comparado con lo que hoy hace clone-store.ts (verificado leyendo el código, no supuesto) y con lo que ofrecen los scrapers comerciales más usados del mercado.

1 Lo que ya tiene (verificado en el código)

Cada ítem acá abajo se confirmó leyendo /var/www/scraping.tol.ar/server/clone-store.ts y los cron jobs en /root/agentes/ — nada de esta lista es supuesto.

Motor híbrido: HTML estático + navegador con JSTiene

Usa cheerio para HTML plano y un navegador headless (Puppeteer vía getBrowser()) cuando la página necesita JavaScript ejecutado — por ejemplo para sacar variantes de TiendaNube que solo aparecen en window.LS.variants después de renderizar.

clone-store.ts:180-202

Detección de bloqueo por el sitio de origenTiene

Si el sitio devuelve 401/403/429/503 lo marca como BlockedError, cuenta cuántos pedidos fueron bloqueados y si es demasiado, avisa en vez de guardar un catálogo a medias como si estuviera completo.

clone-store.ts:136-162, 2684-2732

Cola de reintentos con backoffTiene

Si un clonado falla, queda anotado y un cron (cada 2hs) lo reintenta solo, con espera creciente (2hs, 4hs, 8hs...) hasta 5 intentos. Si se agotan, avisa por WhatsApp en vez de quedar fallado en silencio.

clone-store.ts:1420-1447 · reintentar-clones-fallidos.js (cron cada 2hs)

Escritura incremental en base de datosTiene

Antes de escribir en Supabase compara si el producto es exactamente igual al ya guardado (sameProductData). Si no cambió nada, no hace el PATCH ni ensucia el historial de precios con una entrada falsa.

clone-store.ts:1638-1650

Historial de precio/stock por productoTiene

Cada cambio real de precio o stock queda registrado en product_price_history, no se pisa el dato viejo sin dejar rastro.

clone-store.ts:1655-1665

Baja automática de productos discontinuadosTiene

Si un producto ya no está en el catálogo de origen, se borra de la tienda clonada — pero solo cuando la corrida vio el catálogo completo (si se truncó por un límite de cantidad, no borra nada para no confundir "no lo vi" con "no existe más").

clone-store.ts:1758-1762, 2823-2836

Aviso de WhatsApp con detalle por productoTiene

Resuelto el 20/07 por el Agente Scraping — no necesitó ninguna decisión ni gasto de Ariel, era código puro. Antes el aviso diario era solo un contador ("N actualizados"). Ahora insertProduct devuelve el detalle de cada cambio real de precio/stock, y rescrapear-tiendas-diario.js arma con eso una lista producto por producto en el mensaje de WhatsApp (tope de 25 líneas para no mandar un mensaje gigante). De paso se corrigió un bug real que estaba de antes: el script del cron hacía JSON.parse de toda la respuesta del scraper como si fuera un solo JSON, pero el endpoint manda varias líneas (ndjson) — eso rompía con "Respuesta inválida del scraper" en algunas corridas aunque el clonado hubiera salido bien (se ve en el log real del 19/7). Ahora se parsea línea por línea.

clone-store.ts: insertProduct, priceStockChanges · rescrapear-tiendas-diario.js: llamarCloneStore

2 Lo que le falta — vamos marcando a medida que lo resolvemos

Ordenado por impacto real. Tildá el checkbox cuando lo terminemos — queda guardado en este navegador.

Incrementalidad de red (usa lastmod del sitemap)Alto impacto / bajo esfuerzo

El sitemap.xml de la tienda madre ya trae <lastmod> por producto, pero el código lo lee y lo descarta (solo usa <loc>). Hoy cada re-escrapeo diario visita el catálogo completo aunque no haya cambiado nada. Guardando el lastmod visto la última vez, se podría saltear directamente los productos sin cambios y solo visitar los que de verdad se tocaron.

clone-store.ts: discoverProductUrls no guarda lastmod

Sin rotación de proxies / IPsAlto impacto

El código ya soporta un plan B: si el sitio de origen bloquea un pedido (401/403/429/503), reintenta una sola vez por un proxy antes de contarlo como bloqueo real (variable SCRAPING_PROXY_URL en .env). Pero hoy esa variable está vacía — no hay ningún proveedor de proxy contratado, así que en la práctica seguimos saliendo solo por la IP del VPS. Falta decidir y pagar un servicio de proxy y cargar la URL con usuario/clave.

clone-store.ts: PROXY_URL/proxyAgent (junto a FETCH_HEADERS) y fetchTextForProductViaProxy

Sin resolución de CAPTCHAImpacto medio

Antes, si el sitio de origen tiraba un CAPTCHA (que casi siempre responde HTTP 200, no un código de bloqueo), el scraper no lo distinguía de "esta URL no tiene un producto real" — quedaban mezclados en el mismo mensaje genérico. Ahora sí lo detecta y lo cuenta aparte ("El sitio de origen tiró un CAPTCHA en N de M pedidos"), pero sigue sin resolverlo: no hay integración con un servicio pago de resolución (ej. 2Captcha, Anti-Captcha) ni navegador que complete el desafío. Hoy no es grave porque las tiendas madre que clonamos no suelen usar CAPTCHA, pero limita a qué tipo de tienda le podemos ofrecer el clonado.

clone-store.ts: isCaptchaPage/CaptchaError (detección) — falta el solver

Cobertura de plataformas angostaImpacto medio

Hay selectores dedicados y probados para TiendaNube y WooCommerce. Para otras plataformas (Shopify, VTEX, Magento, MercadoShops) depende de que la página tenga JSON-LD de schema.org bien puesto — si no lo tiene, la extracción es más débil.

clone-store.ts: selectores específicos TiendaNube/WooCommerce

Sin alerta de "la tienda madre cambió de diseño"Impacto medio

Si el sitio de origen rediseña su tema y los selectores dejan de encontrar precio, categoría o imágenes, el scraper no lo detecta como anomalía — simplemente extrae menos datos o datos vacíos, sin avisar que "esto está raro comparado con ayer".

no encontrado en el código

Frecuencia de re-escrapeo fija para todas las tiendasImpacto bajo

Todas las tiendas clonadas se re-escrapean una vez al día a la misma hora. No hay forma de pedir "esta tienda cambia mucho, revisala cada 6hs" o "esta no cambia nunca, revisala una vez por semana".

crontab: un solo horario fijo para todas

Sin builder visual (no-code)No aplica a nuestro caso, pero lo tienen los líderes

Los selectores están escritos a mano en TypeScript por plataforma. No hay una herramienta de "señalá con el mouse qué campo es el precio" para agregar soporte a una plataforma nueva sin programar.

n/a

Extracción basada en selectores, no en IAImpacto bajo hoy, crece con más plataformas

Toda la extracción depende de selectores CSS/JSON-LD fijos. Herramientas como Diffbot usan modelos que "entienden" la página aunque cambie el HTML. Acá, un cambio de HTML rompe el selector hasta que alguien lo actualiza a mano.

clone-store.ts: extractCategory, extractImages, etc. — todo selector-based

No respeta robots.txt ni se identifica como botRiesgo legal / reputacional

El scraper se hace pasar por un navegador Chrome normal (mismo User-Agent que una persona) y nunca lee el robots.txt de la tienda madre antes de clonarla. Los scrapers comerciales serios lo respetan por default (con opción de saltearlo a propósito). Hoy, si una tienda pusiera "no me escrapees" en su robots.txt, no nos enteraríamos ni lo respetaríamos.

clone-store.ts:35-38 (FETCH_HEADERS) — sin ninguna mención a robots.txt en todo el archivo

Ritmo de pedidos fijo e igual para todas las tiendasImpacto bajo hoy, techo para escalar

La espera entre pedido y pedido a la tienda madre es siempre 400ms, sea una tienda chica y sensible o una grande que aguanta más ritmo. No hay forma de ajustarlo por tienda.

clone-store.ts:3258 (MIN_REQUEST_GAP_MS = 400, valor único global)

2b No resueltos — necesitan que vos decidas o pagues algo

Estos no los podemos resolver solos programando: falta que Ariel contrate un servicio, pruebe algo, o apruebe un cambio de riesgo. Cada uno dice exactamente qué hacer y adónde va el resultado.

Proxies / rotación de IPNecesita contratar un servicio

El código del plan B ya está listo (reintenta por proxy si el sitio de origen bloquea), pero no hay ningún proxy contratado.

Qué hacer: crear una cuenta en un proveedor de proxy (ya vimos opciones: Webshare gratis para probar, DataImpulse para uso real barato) y conseguir la URL con usuario/clave.

Dónde va: pegarla como variable SCRAPING_PROXY_URL en /var/www/scraping.tol.ar/.env — pasámela a mí (por chat) y yo la cargo y reinicio, no hace falta que toques nada del servidor.

Resolución de CAPTCHANecesita contratar un servicio

El scraper ya detecta cuándo un sitio le tira un CAPTCHA, pero no lo resuelve — solo lo cuenta aparte.

Qué hacer: crear una cuenta en 2Captcha o Anti-Captcha (centavos de dólar por CAPTCHA resuelto) y conseguir la clave de API.

Dónde va: me pasás la clave, yo agrego una variable nueva al .env (ej. CAPTCHA_API_KEY) y conecto el servicio al código que ya detecta el CAPTCHA.

Cobertura de plataformas angosta (Shopify, VTEX, Magento, MercadoShops)Necesita una tienda real para probar

No cuesta plata, pero escribir selectores para una plataforma nueva a ciegas (sin una tienda real de esa plataforma para probar) da un resultado que no puedo garantizar.

Qué hacer: pasame la URL de una tienda real que use Shopify, VTEX, Magento o MercadoShops que te interese poder clonar.

Dónde va: nada que cargar — con la URL yo escribo y pruebo los selectores directo contra esa tienda.

Extracción por IA en vez de selectores fijosNecesita decisión de presupuesto

Cambiaría la extracción para que "entienda" la página en vez de depender de selectores que se rompen con un rediseño — pero tiene costo corriente (se paga por uso de IA en cada producto escrapeado, no es un pago único).

Qué hacer: decidir si vale la pena ese gasto recurrente para la cantidad de tiendas que clonamos hoy — no es algo para prender sin que lo charlemos primero.

Dónde va: nada todavía — está frenado hasta esa decisión.

Respetar robots.txt e identificarse como botNecesita tu OK (riesgo, no plata)

Esto sí lo puedo programar sin que gastes nada, pero es un cambio de riesgo: hoy el scraper se hace pasar por un navegador Chrome normal. Si empieza a identificarse como bot y a respetar robots.txt, alguna tienda que hoy clonamos bien podría empezar a bloquearnos (si su robots.txt dice "no bots", cosa que hoy ignoramos).

Qué hacer: darme el OK para programarlo y probarlo primero contra una tienda de prueba, antes de prenderlo para las tiendas ya clonadas en producción.

Dónde va: nada que cargues vos — solo tu confirmación de que querés que lo prenda.

3 Comparación con los scrapers comerciales más usados

Basado en conocimiento general de estos productos (documentación pública), no en una consulta hecha ahora mismo a sus sitios — a diferencia de la sección 1 y 2, que son 100% código verificado. Tratalo como orientativo, no como dato exacto.

Capacidad	tol.ar (hoy)	Octoparse	Apify	Bright Data	Zyte	Diffbot
Rotación de proxies / IPs	No tiene	Con plan pago	Sí	Sí (su producto principal)	Sí	Sí
Resolución de CAPTCHA	No	Parcial	Vía addons	Sí	Sí	Sí
Incrementalidad (saltear lo que no cambió)	No (lastmod ignorado)	Según config	Según config	Según config	Sí (auto-throttle + caché)	Sí
Resiste rediseños de la página (IA vs. selectores)	No, selectores fijos	No, selectores fijos	Depende del actor	Depende del setup	Parcial	Sí, extracción por IA
Historial de precio/stock por producto	Sí	No nativo	Si el actor lo implementa	No es su foco	Vía Scrapy Cloud custom	No nativo
Reintentos automáticos con backoff	Sí	Sí	Sí	Sí	Sí	Sí
Checkpoint / reanudar corte a la mitad	Sí	Parcial	Sí	Depende del setup	Sí	n/d
Cache propio de imágenes (independiza del sitio de origen)	Sí	No es su foco	Si el actor lo hace	No es su foco	No es su foco	No es su foco
Validación de precio sospechoso antes de publicar	Sí	No nativo	No nativo	No nativo	No nativo	No nativo
Builder visual sin programar (no-code)	No	Sí (su producto principal)	Marketplace de "actors" prearmados	No, es infraestructura	No, es infraestructura	API, no visual
Cobertura multi-plataforma out-of-the-box	TiendaNube fuerte, resto genérico	Templates por sitio popular	Marketplace enorme de actors	Infraestructura, no templates	Infraestructura, no templates	Cualquier página, IA genérica

Nuestro scraper es el único de esta lista pensado específicamente para "clonar una tienda online completa y mantenerla sincronizada con precio/stock/fotos todos los días" — los demás son herramientas generales de extracción de datos web, no soluciones de e-commerce. Por eso gana en historial de precios, cache de imágenes y validación de precio, y pierde en proxies/CAPTCHA/no-code, que no son su enfoque.

4 Qué haría un "scraper perfecto" para lo que hace tol.ar

No es copiar Bright Data ni Octoparse enteros — es tomar de cada uno solo lo que resuelve un problema real que ya vimos (bloqueos, catálogos grandes, rediseños silenciosos):

1. Lee el lastmod del sitemap y solo visita productos que cambiaron de verdad (gap #1, ya identificado).

2. Tiene un segundo proxy/IP como plan B cuando el sitio de origen bloquea la IP principal, en vez de esperar a que el bloqueo se levante solo (gap #2).

3. Se da cuenta solo cuando una tienda cambió de diseño — por ejemplo, si de repente 0 productos traen categoría cuando ayer el 95% la traía, frena y avisa en vez de guardar datos rotos (gap #5).

4. Mantiene todo lo que ya tiene: historial de precios, cache de imágenes, checkpoint, validación de precio sospechoso, baja de discontinuados — eso ya está al nivel de cualquier solución comercial, y en algunos puntos por encima porque está hecho a medida para esto.

Scraper de tol.ar — estado real y hoja de ruta

1 Lo que ya tiene (verificado en el código)

2 Lo que le falta — vamos marcando a medida que lo resolvemos

2b No resueltos — necesitan que vos decidas o pagues algo

3 Comparación con los scrapers comerciales más usados

4 Qué haría un "scraper perfecto" para lo que hace tol.ar