El parser devuelve campos vacíos y los proxies no son el problema: solucionamos el deslizamiento del diseño

El parser ha estado funcionando durante seis meses, y hoy se han registrado líneas vacías en la base de datos. El primer pensamiento es: me han bloqueado, hay que cambiar el proxy. Cambias el pool, mejoras la calidad de las IP, pagas por residenciales en lugar de datacenter — y los campos siguen vacíos. Porque la razón no era el bloqueo: el sitio se ha mudado a un nuevo diseño, y tu selector CSS ya no está vinculado a nada.

Este es el tipo de fallo más costoso, porque permanece en silencio. El bloqueo se ve de inmediato: 403, captcha, redirección. El drift del diseño no derriba nada — HTTP 200, página recibida, tráfico pagado, y al final None. Vamos a ver cómo en cinco minutos distinguir una cosa de la otra y cómo dejar de reescribir selectores manualmente después de cada rediseño.

¿A quién le importa?

Guía para aquellos que mantienen un parser en producción durante más de un sprint: monitoreo de precios de competidores, recopilación de reseñas, agregación de ofertas de trabajo, descargas diarias para análisis. Si ejecutas el script una vez y lo descartas — el drift del diseño no te afecta. Si el script se ejecuta por cron durante meses, es tu principal gasto en soporte.

La magnitud del problema no es inventada. Según analistas de GroupBWT, los cambios estructurales incontrolados en los sitios generan aproximadamente 40–60% de costos recurrentes en el soporte de scrapers en grandes proyectos. En ciertas industrias, 10–15% de los crawlers requieren reparación semanalmente — debido a desplazamientos del DOM, fingerprinting y throttling de endpoints. Es decir, reparar selectores compite en costo con el eludir anti-bots, pero se le presta mucho menos atención.

El trasfondo es poco alentador: en el informe de Apify "State of Web Scraping 2026", 65,8% de los encuestados aumentaron el uso de proxies, 58,3% notaron un aumento en los gastos de proxies año tras año, y más de 62% — un aumento general en los costos de infraestructura, principalmente debido a la creciente protección contra bots. En este contexto, quemar tráfico pagado en páginas de las que no obtienes nada es doblemente frustrante.

Paso 1. Distinguir un bloqueo de un drift del diseño

El diagnóstico toma unos minutos y se realiza estrictamente en orden — de lo contrario, es fácil "arreglar" el fallo equivocado.

1. Mira el código de respuesta y el tamaño del cuerpo. 403, 429, 503, redirección a una página de verificación o un cuerpo de 2–5 KB — eso es anti-bots. HTTP 200 y una página completa de 200–800 KB — el sitio te ha dejado entrar, no es un problema de proxy.
2. Guarda el HTML crudo en disco y ábrelo con tus ojos. No en el depurador, sino en el navegador. Si el producto/reseña/precio están presentes, pero el parser no los ve — eso es un drift del diseño.
3. Busca el texto necesario en el archivo. Está en el HTML, pero no es accesible a través de tu selector — la estructura ha cambiado. No está en absoluto — el contenido se carga mediante un script, se necesita un motor de navegador, no una solicitud HTTP.
4. Compara con la descarga anterior exitosa. Haz un diff entre el HTML antiguo y nuevo de la misma URL: generalmente se ve de inmediato una nueva clase contenedora, un bloque que se ha movido o un cambio de id a data-*.
5. Verifica si el sitio ha entregado otra versión de la página. Esto se trata por separado más abajo, porque aquí el proxy tiene algo que ver.

Si después del tercer punto el diagnóstico es "la estructura se ha movido", cambiar el proxy es inútil. Se necesita un parser que pueda encontrar el elemento, incluso cuando el selector ha caducado.

Paso 2. Qué son los selectores adaptativos

La idea es simple: en lugar de atarse firmemente a la línea .product-card > h3.title, la biblioteca recuerda una vez el "retrato" del elemento necesario, y en la próxima ejecución busca el elemento más parecido a este retrato en la página.

Esto se ha implementado de manera más práctica en Scrapling — un marco de trabajo de Python de código abierto creado por Karim Shoair. El proyecto se lanzó en octubre de 2024 y para septiembre de 2026 había acumulado más de 78,000 estrellas en GitHub; la última versión al momento de escribir es v0.4.15 del 23 de agosto de 2026, con commits diarios. Se requiere Python 3.10+.

La mecánica de la búsqueda adaptativa funciona así. Cuando llamas al selector con auto_save=True, Scrapling guarda la huella del elemento:

• nombre de la etiqueta, texto y todos los atributos con sus valores;
• nombres de las etiquetas vecinas;
• ruta hasta el elemento — solo por los nombres de las etiquetas;
• etiqueta, atributos y texto del padre.

La huella se guarda en una base de datos local SQLite y se clavea con el par "dominio + identificador". El dominio se toma de la URL de la página (o se establece como parámetro adaptive_domain), el identificador por defecto es la propia línea del selector — o tu propio identificador, si se pasa identifier=.

Cuando el diseño cambia y el selector normal devuelve vacío, la llamada con adaptive=True levanta la huella guardada y la ejecuta sobre todos los elementos de la página, calculando una evaluación difusa de similitud — hasta el orden de los atributos. Se devuelve el elemento con la mayor coincidencia.

Esto es barato. Según los benchmarks oficiales del proyecto, el parsing toma 1,99 ms frente a 2,01 ms de Parsel/Scrapy, 22,93 ms de PyQuery, 80,57 ms de Selectolax y 1541 ms de BeautifulSoup con lxml. La búsqueda adaptativa del elemento similar toma 2,46 ms frente a 13,3 ms de AutoScraper. Es decir, el seguro contra rediseños añade aproximadamente dos milisegundos a la solicitud en medio de una latencia de red de cientos de milisegundos.

Paso 3. Instalación y activación

La instalación depende de si necesitas un navegador:

1. pip install scrapling — solo el parser, sin la parte de red. Es suficiente si obtienes el HTML con tu propio código.
2. pip install "scrapling[fetchers]", luego scrapling install — añade fetchers y descarga navegadores con dependencias.
3. Adicionalmente: [ai] — servidor MCP, [rag] — envoltura para RAG, [shell] — consola interactiva, [all] — todo de una vez. Hay una imagen lista pyd4vinci/scrapling.

A continuación, dos ejecuciones. La primera en un diseño de trabajo en vivo guarda la huella, la segunda ya puede sobrevivir a un rediseño:

1. Ejecución de referencia. Crea un objeto Selector con adaptive=True y asegúrate de pasar url — de lo contrario, el dominio se irá a la clave "default", y las huellas de diferentes sitios se mezclarán. Llama al selector necesario con auto_save=True.
2. Ejecución en producción. El mismo selector, pero con adaptive=True. Mientras la estructura esté intacta, funcionará el camino normal. Cuando falle — se activará la búsqueda de similitud.
3. Registra las discrepancias. El momento en que el selector normal devuelve vacío, mientras que el adaptativo encuentra algo, es una señal de "el sitio se ha mudado", debe ser visible en el monitoreo, no tragado en silencio.

Un detalle importante sobre la sobrescritura: la conservación no se acumula. Un auto_save repetido para el mismo par "dominio + identificador" sobrescribe la huella anterior. Por lo tanto, la referencia se toma de una página claramente correcta, y no en un ciclo a través de todo el pool de URL.

Paso 4. Proxies: ¿dónde encajan?

Comenzamos diciendo que el drift del diseño no se trata de proxies. Esto es cierto exactamente a la mitad, y la otra mitad cuesta dinero.

El sitio puede entregarte una estructura diferente debido a la salida del proxy. La localidad, el idioma y el país cambian el patrón de la página: diferente orden de bloques, diferentes clases, diferentes formatos de precios y fechas. Esto no es una hipótesis — en Scrapling hay una corrección ejemplar: en la versión 0.4.12 se eliminó la localidad forzada en-US, porque la localidad impuesta no coincidía con el geo real y rompía el comportamiento. De aquí surge la regla de trabajo: toma la huella de referencia desde el mismo geo desde el que luego recopilas datos. Una huella tomada a través de una IP alemana coincidirá peor con una página obtenida a través de una brasileña — y recibirás una falsa alarma de "el sitio ha cambiado el diseño".

Consecuencias prácticas:

• Si el pool es multilateral — separa las huellas a través de adaptive_domain, asignando allí una clave del tipo "dominio + país". De lo contrario, una entrada en SQLite será constantemente sobrescrita por versiones de diferentes geos.
• Para scripts largos, mantén un país y una sesión para toda la tarea. Cómo hacerlo se detalla en el material sobre sesiones pegajosas y cuándo usarlas.
• Las pruebas A/B y los despliegues graduales dan simultáneamente dos diseños vivos en un mismo dominio. Aquí la búsqueda adaptativa es especialmente útil: extraerá el elemento de ambas ramas, mientras que un selector rígido devolverá aleatoriamente vacío en la mitad de las solicitudes.

Configurar proxies en Scrapling se puede hacer en todos los niveles. Para solicitudes HTTP rápidas, Fetcher y AsyncFetcher tienen el parámetro proxies. Para sesiones existe ProxyRotator, al que se le pasa una lista de direcciones — se inserta en FetcherSession. Las sesiones de navegador DynamicSession y StealthySession aceptan proxies a nivel de sesión, para que la IP no cambie en medio del script.

Otra cosa que ahorra tanto el pool como los nervios, apareció en la versión 0.4.12 — AutoThrottle: la biblioteca ajusta automáticamente las pausas entre solicitudes según las respuestas del servidor, duplica la latencia en caso de bloqueo y respeta el encabezado Retry-After. Este es exactamente el comportamiento que distingue la recolección cuidadosa de la quema de bloqueos por intentos ingenuos.

Trampas

• No comites SQLite con huellas en git. La documentación advierte sobre esto directamente. Además, no uses auto_save en páginas con datos personales — el texto y los atributos del elemento se incluirán en la huella.
• La búsqueda adaptativa no reemplaza el monitoreo. Devolverá el "elemento más parecido", pero el más parecido no siempre es correcto. Si el sitio ha intercambiado el precio con descuento y el precio sin descuento, la similitud es alta, pero los datos son incorrectos. Mantén verificaciones sobre el rango de valores y la proporción de campos vacíos en la descarga.
• El fallo silencioso es más costoso que el ruidoso. Mientras el selector silenciosamente devuelve None, el pipeline sigue recorriendo las páginas y quemando tráfico pagado. Sobre lo que realmente cuesta un gigabyte del que no se extrajeron datos, hay un análisis separado — por qué el precio de los proxies por GB es engañoso.
• La huella envejece. Después de un rediseño confirmado, vuelve a tomar la referencia, de lo contrario, la siguiente modificación del sitio se considerará ya desde un retrato obsoleto, y la precisión caerá.
• Si no hay contenido en el HTML en absoluto — la adaptabilidad no ayudará, se necesita un fetcher de navegador. En 0.4.15, las pestañas del navegador comenzaron a reutilizarse entre solicitudes, y el método close_pages() las cierra forzosamente; allí también se solucionaron los bloqueos en modo headless y la solución Turnstile dejó de depender de la localidad del navegador.

Qué tipo de proxy elegir para esta tarea

La elección no la dicta el parser, sino el sitio objetivo:

• Proxies de datacenter — para sitios sin un anti-bots serio: documentación, registros gubernamentales, catálogos abiertos, feeds RSS y CSV (para los últimos, en 0.4.13 se añadieron XMLFeedSpider y CSVFeedSpider con descompresión automática gzip). Barato y rápido, y la estabilidad del diseño suele ser mayor aquí.
• Proxies residenciales — para marketplaces, agregadores y todo lo que personaliza la entrega según geo. Aquí es crítico tomar la referencia y recopilar datos de un solo país, de lo contrario, estarás reparando no un fallo, sino tu propia geografía.
• Proxies móviles — cuando el sitio entrega un diseño móvil y necesita ser parseado tal cual, o cuando la confianza en la IP es más importante que el precio por gigabyte.

En resumen

Los campos vacíos en la descarga son dos diagnósticos diferentes con tratamientos diferentes. Primero verifica el código de respuesta y el HTML crudo: si la página llegó completa, no es necesario cambiar el proxy, el diseño se ha movido. Los selectores adaptativos de Scrapling cierran esta clase de fallos en un par de milisegundos por solicitud — guarda la huella en un diseño de trabajo, activa adaptive=True en producción y registra los momentos de activación como señal de rediseño. Y mantén el geo estable: la mitad de los "rediseños repentinos" en la práctica resulta ser otra versión lingüística de la página, llegada por un cambio en el país de salida.

Si un geo estable y una sesión predecible son justo lo que le falta a tu parser, mira los proxies residenciales de ProxyCove: selección de país, sesiones pegajosas y pago por el tráfico realmente utilizado.