Cómo raspar datos de productos de Walmart: por qué los proxies genéricos fallan y qué es lo que realmente funciona.

Conclusiones Clave:

• Una IP de EE. UU. no es lo mismo que una respuesta utilizable en Walmart. Walmart evalúa la reputación de la IP, la consistencia del comportamiento y la concentración del tráfico regional, no solo el país al que se resuelve una IP. Un proxy genérico de EE. UU. puede devolver un HTTP 200 y aún así mostrar una página de verificación de bots o CAPTCHA en el cuerpo.
• HTTP 200 ≠ datos de producto extraíbles. Los proxies genéricos de EE. UU. devuelven rutinariamente un 200 OK cuyo cuerpo es una página de verificación de bots o CAPTCHA en lugar de la cuadrícula de productos, y una parte de ellos nunca se conecta en absoluto. Los códigos de estado por sí solos no te dicen si una respuesta es real.
• Las IPs de centros de datos se degradan más rápido; solo la residencial no es suficiente. La salida residencial eleva el umbral, pero Walmart también verifica si una sesión se comporta como un navegador, ejecutando JavaScript, manteniendo cookies y presentando una huella digital consistente. Un proxy en bruto entrega bytes; no renderiza una página.
• Un navegador anti-detección renderizado cierra la brecha. El Scrapeless Scraping Browser combina proxies residenciales en más de 195 países con renderizado de JavaScript del lado de la nube y huellas digitales anti-detección, de modo que la página que se devuelve es la cuadrícula de productos real y no una shell de desafío.
• El render es observable. El Scrapeless Scraping Browser renderiza la URL de búsqueda de Walmart al título de la página laptop - Walmart.com, produciendo más de 160 anclas de producto (a[link-identifier]) y docenas de nodos [data-item-id] — una cuadrícula de productos real y paginada en lugar de una shell de desafío.
• Gratis para comenzar. Las nuevas cuentas de Scrapeless incluyen tiempo de ejecución del Scraping Browser gratuito; regístrate en app.scrapeless.com.

Introducción: un estado 200 no es luz verde

El catálogo público de Walmart es uno de los conjuntos de datos más observados en el comercio minorista de EE. UU. Los equipos de precios rastrean SKU de competidores, los propietarios de marcas supervisan el cumplimiento del MAP, los vendedores en el mercado observan el movimiento de la caja de compra, y los agentes de IA extraen atributos de producto a flujos de trabajo posteriores. Los datos son visibles públicamente en un navegador, que es exactamente por qué tantos equipos asumen que un proxy y un cliente HTTP son suficientes para recogerlo.

No lo son. El modo de fallo más común en Walmart es silencioso: se envía una solicitud a través de un proxy de EE. UU., regresa con un 200 OK, y la tubería registra un éxito; pero el cuerpo es una página de verificación de bots, una shell de React vacía o un aviso de CAPTCHA. La línea de estado dice que todo funcionó; el payload no contiene datos de producto. Un scraper que confía en el código de estado apunta a una victoria y no guarda nada utilizable.

Esta publicación explica por qué los proxies genéricos no son suficientes en Walmart, respalda la tasa de fallos con un benchmark público atribuido y describe un flujo de trabajo en Python sobre el Scrapeless Scraping Browser — un navegador en la nube anti-detección que renderiza la página, mantiene el estado de la sesión y se enrutará a través de la salida residencial, de modo que la respuesta que se devuelve es la cuadrícula de productos que realmente querías. El flujo de trabajo extrae registros de resultados de búsqueda (título, precio, enlace, id de artículo) y pasa de un resultado a su página de detalle de producto.

Lo Que Puedes Hacer Con Esto

• Seguimiento de precios competitivos. Recopila precios, precios de lista y banderas de descuento en SKU competitivos de Walmart de manera continua.
• Monitoreo de cumplimiento del MAP. Los propietarios de marcas supervisan los precios de vendedores de terceros y señalan listados por debajo del MAP.
• Ingeste del catálogo. Alimenta búsquedas y listados de categorías en flujos de trabajo posteriores con un esquema de producto normalizado (título, precio, enlace, id de artículo).
• Inteligencia sobre la caja de compra y los vendedores. Rastrea qué vendedor tiene un listado determinado y cómo rotan las ofertas con el tiempo.
• Disponibilidad y variedad. Monitorea qué productos aparecen ante una consulta y cómo el conjunto de resultados cambia entre regiones.
• Enriquecimiento de agentes de IA. Entrega una cuadrícula de productos renderizada a un agente que clasifica, elimina duplicados o resume el catálogo.

En Scrapeless, solo accedemos a datos disponibles públicamente mientras cumplimos estrictamente con las leyes, regulaciones y políticas de privacidad de los sitios web aplicables. El contenido de esta publicación es solo para fines de demostración.

Por Qué Fallan los Proxies Genéricos en Walmart

Un proxy genérico hace un trabajo: reenvía tu solicitud HTTP desde una IP diferente y devuelve los bytes que Walmart envía de vuelta. No ejecuta JavaScript, no mantiene una huella digital de navegador, ni mantiene el estado de la sesión a través de solicitudes. Las protecciones de Walmart están construidas precisamente para detectar lo que un proxy en bruto no puede falsificar.

Walmart verifica más que el país de la IP

La capa anti-bot de Walmart evalúa varias señales juntas:

• Reputación de la IP — los rangos de centros de datos y los grupos de proxies conocidos tienen baja confianza y generan desafíos rápidamente.
• Consistencia del comportamiento — si el cliente ejecuta scripts de página, reproduce cookies y presenta encabezados y tiempos que coinciden con un navegador real.
• Concentración de tráfico regional — no solo el país al que se resuelve una IP, sino si el tráfico de una región o subred parece distribuido de manera natural o concentrado de una manera que indica automatización.
  Un proxy a nivel de país en EE. UU. satisface exactamente una de esas verificaciones. No dice nada sobre si la solicitud ejecuta JavaScript o se comporta como un navegador, y un grupo de IPs de centros de datos de EE. UU. contra los mismos puntos finales concentra el tráfico de una manera que las verificaciones regionales de Walmart están diseñadas para detectar.

El código de estado miente

El síntoma más costoso es el que parece éxito. Ejecuta proxies genéricos de EE. UU. contra Walmart a gran volumen y las respuestas se dividen en tres categorías: una minoría que devuelve datos de productos utilizables, una gran parte que devuelve una página de verificación de bots o CAPTCHA a pesar de un estado 200 OK, y un remanente que nunca se conecta en absoluto. La categoría intermedia es la trampa: un pipeline que trata 200 OK como éxito absorberá silenciosamente las páginas de desafío en su conjunto de datos. La extracción válida se mantiene baja precisamente porque el código de estado y la carga útil no coinciden tan a menudo.

Los centros de datos se degradan rápido; la residencia sola no es suficiente

El enrutamiento a través de IPs residenciales eleva el mínimo: la salida residencial conlleva más confianza que los rangos de centros de datos. Pero los proxies residenciales por sí solos dejan abiertas las brechas de comportamiento y renderizado. Una IP residencial adjunta a un cliente HTTP simple aún no ejecuta los scripts de la página de Walmart, presenta una huella delgada y devuelve la estructura no hidratada. La IP es más confiable; la solicitud sigue siendo reconociblemente automatizada.

Lo que realmente cierra la brecha

El camino confiable contra Walmart combina tres cosas que un proxy bruto no puede proporcionar por sí solo:

1. Un verdadero navegador renderizado que ejecuta el JavaScript de Walmart, para que la cuadrícula de productos se hidrate en el DOM.
2. Salida residencial para que la IP lleve la confianza que falta a un rango de centros de datos.
3. Consistencia de comportamiento y huella digital: cookies sostenidas a través de solicitudes, una huella que coincide con el tráfico orgánico y un estado de sesión que persiste.

Esa combinación es lo que proporciona el Scrapeless Scraping Browser como una única superficie gestionada.

Proxy genérico vs navegador en la nube renderizado

Un proxy genérico responde a la pregunta "¿puedo enviar esta solicitud desde una IP de EE. UU.?" El Scrapeless Scraping Browser responde a la pregunta que realmente importa: "¿puedo obtener la cuadrícula de productos renderizada de vuelta?"

Por qué Scrapeless Scraping Browser

Scrapeless Scraping Browser es un navegador en la nube personalizable y anti-detección diseñado para crawlers web y agentes de IA. Para Walmart específicamente, trae:

• Proxies residenciales en más de 195 países, anclados a la salida de EE. UU. al crear la sesión, por lo que la IP conlleva confianza residencial en lugar de una firma de centro de datos.
• Renderizado de JavaScript del lado de la nube, para que la cuadrícula de React de Walmart se hidrate y los nodos de producto estén presentes en el DOM antes de la extracción.
• Persistencia de sesión, para que las cookies y el estado del navegador se mantengan consistentes a través del flujo búsqueda → detalle en lugar de reiniciarse en cada solicitud.
• Huella digital anti-detección en cada sesión, para que la página renderice como lo hace para el tráfico orgánico.
• Una única superficie programática: construye una URL de CDP con tu clave API, conéctate con Playwright y controla un navegador real sin tener que montar infraestructura.

El render es un comportamiento observable. El Scrapeless Scraping Browser renderiza https://www.walmart.com/search?q=laptop al título de la página laptop - Walmart.com, arrojando más de 160 anclas de producto (a[link-identifier]) y docenas de nodos [data-item-id] — una cuadrícula de productos real y paginada, en lugar de una estructura de desafío. Las URL de productos de Walmart tienen la forma https://www.walmart.com/ip/<slug>/<id>, y cada ancla de resultado se resuelve en una.

Obtén tu clave API en el plan gratuito en app.scrapeless.com. La página del producto del Scraping Browser y la página de Soluciones de Proxy cubren la red residencial que respalda el navegador en la nube.

Requisitos previos

• Python 3.10 o superior.
• Una cuenta de Scrapeless y clave API — regístrate en app.scrapeless.com. El SDK lee la clave de la variable de entorno SCRAPELESS_API_KEY.
• Familiaridad básica con la terminal y con Python.

Instalar

El flujo de trabajo utiliza un paquete: Playwright para Python, el cliente oficialmente soportado que se conecta a Scrapeless Scraping Browser a través de CDP y lee el DOM renderizado.

pip install playwright

connect_over_cdp de Playwright controla el navegador en la nube remoto, por lo que no necesitas playwright install ni ningún binario de navegador local: la renderización ocurre del lado de la nube. Luego, exporta tu clave API para que pueda acompañar la URL de conexión:

export SCRAPELESS_API_KEY=tu_token_api_aqui

El formato de conexión y las guías de la biblioteca están documentados en docs.scrapeless.com.

Paso 1 — Construir una URL de conexión de salida en EE. UU.

El Scrapeless Scraping Browser es un endpoint de CDP. Construye la URL de WebSocket con tu clave API como token y la salida en EE. UU. como proxyCountry: Walmart es un sitio de retail en EE. UU., y una sesión residencial en EE. UU. es la línea base para una respuesta utilizable.

import os
from urllib.parse import urlencode
from playwright.sync_api import sync_playwright

def scraping_browser_url(proxy_country="US", session_ttl=240):
    # La clave API se envía como `token`; la salida y la duración son parámetros de consulta.
    params = urlencode({
        "token": os.environ["SCRAPELESS_API_KEY"],
        "sessionTTL": session_ttl,
        "proxyCountry": proxy_country,
    })
    return f"wss://browser.scrapeless.com/api/v2/browser?{params}"

proxyCountry=US enruta la sesión a través de una IP residencial en EE. UU. sessionTTL=240 mantiene la sesión activa el tiempo suficiente para mantener las cookies entre la página de búsqueda y las páginas de detalles del producto a las que accedas a continuación.

Paso 2 — Conectar a través de CDP y abrir la página de búsqueda

Conéctate al endpoint de Scraping Browser con connect_over_cdp de Playwright y luego abre la URL de búsqueda de Walmart. Debido a que este es un navegador renderizado real, el JavaScript de Walmart se ejecuta y la cuadrícula de productos se hidrata en el DOM.

SEARCH_URL = "https://www.walmart.com/search?q=laptop"

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(scraping_browser_url("US"))
    page = browser.new_page()

    # Calienta la página de inicio primero, luego abre la búsqueda en la misma sesión.
    page.goto("https://www.walmart.com/", wait_until="domcontentloaded")
    page.wait_for_timeout(2500)
    page.goto(SEARCH_URL, wait_until="domcontentloaded")
    page.wait_for_timeout(4000)                     # deja que la cuadrícula de React se hidrate

    # Confirma que la respuesta es la verdadera cuadrícula de productos, no una página de desafío.
    title = page.title()                            # "laptop - Walmart.com" en un renderizado real
    cards = page.query_selector_all("a[link-identifier]")  # ~160+ anclas de producto cuando están hidratadas
    print(title, len(cards))

La breve espera después de la navegación permite que la cuadrícula de React termine de hidratarse antes de la extracción. Las dos comprobaciones anteriores — el título de la página y el conteo de anclajes a[link-identifier] — son cómo confirmas que una respuesta es real antes de confiar en ella. Una página de desafío no lleva el título del producto ni renderiza la cuadrícula; una página real hace ambas cosas.

Paso 3 — Extraer la cuadrícula de productos

Cada tarjeta de resultado de búsqueda está anclada en a[link-identifier], con nodos [data-item-id] que llevan el id del artículo de Walmart. Recorre los anclajes y obtiene un registro normalizado por producto: título, precio, enlace e id del artículo.

import re

def extract_products(page):
    products = []
    for card in page.query_selector_all("[data-item-id]"):
        link_el = card.query_selector("a[link-identifier]")
        if not link_el:
            continue

        href = link_el.get_attribute("href")
        item_id = card.get_attribute("data-item-id")

        # El título se encuentra en el texto del enlace / nombre accesible en la tarjeta de resultado.
        span = link_el.query_selector("span")
        title = span.inner_text() if span else link_el.get_attribute("link-identifier")

        # El precio se renderiza en la tarjeta después de la hidratación; lee el texto del precio visible.
        price_el = card.query_selector('[data-automation-id="product-price"]')
        price = None
        if price_el:
            m = re.search(r"\d[\d,]*\.?\d*", price_el.inner_text().replace(",", ""))
            price = float(m.group()) if m else None

        link = href if not href or href.startswith("http") else f"https://www.walmart.com{href}"

        products.append({
            "itemId": item_id,
            "title": (title or "").strip() or None,
            "price": price,
            "currency": "USD",
            "link": link,
        })
    return products

Los selectores anteriores (a[link-identifier], [data-item-id], [data-automation-id="product-price"]) son los anclajes estables en la cuadrícula de búsqueda. Inspecciona el DOM en vivo primero cuando una disposición cambia: lee el HTML renderizado, confirma los nombres de anclaje actuales y ajusta los selectores a lo que la página realmente entrega. Los nombres de clases utilitarias hasheadas rotan a lo largo de los despliegues; los anclajes semánticos data-* son la superficie duradera.
Obtén tu clave API en el plan gratuito: app.scrapeless.com

Paso 4 — Camina desde un resultado hasta su página de detalle del producto

Cada enlace de resultado se resuelve en una página de detalle del producto en la forma https://www.walmart.com/ip/<slug>/<id>. Ábrelo en la misma sesión: las cookies y la huella digital de la sesión se transfieren, por lo que la página de detalle se renderiza de la misma manera que lo hizo la página de búsqueda.

def text_of(page, selector):
    el = page.query_selector(selector)
    return el.inner_text().strip() if el else None

def fetch_detail(page, product_url):
    page.goto(product_url, wait_until="domcontentloaded")
    page.wait_for_timeout(3000)
    price_el = page.query_selector('[itemprop="price"]')
    return {
        "url": product_url,
        "title": text_of(page, "h1"),
        "price": (price_el.get_attribute("content") if price_el else None)
                 or text_of(page, '[data-automation-id="product-price"]'),
        "brand": text_of(page, '[itemprop="brand"]'),
        "availability": text_of(page, '[data-automation-id="fulfillment-section"]'),
    }

# Dentro de la misma sesión `with sync_playwright() as p:` del Paso 2:
products = extract_products(page)
if products and products[0]["link"]:
    detail = fetch_detail(page, products[0]["link"])
    print(detail)

Mantener el paso de búsqueda y el paso de detalle dentro de una sola sesión es lo que preserva la consistencia del comportamiento: la página de detalle ve las mismas cookies de confianza y la huella digital que renderizaron la cuadrícula de búsqueda, por lo que se hidrata de la misma manera. La página de detalle también expone campos más ricos: marca, especificaciones completas, vendedor, opciones de cumplimiento, que la tarjeta de búsqueda no tiene.

Lo que obtienes

El navegador de scraping devuelve un DOM renderizado en vivo; el esquema es lo que el extractor lee de él. Para el extractor de cuadrícula de búsqueda del Paso 3, un registro se ve así:

// El esquema refleja exactamente lo que emite el extractor del Paso 3.
// Los valores de los campos son muestras ilustrativas, no un instantáneo de ningún producto hoy.
{
  "query": "https://www.walmart.com/search?q=laptop",
  "resultCount": 60,
  "products": [
    {
      "itemId": "5689219329",
      "title": "Ejemplo de Laptop de 15,6 in., 16GB RAM, 512GB SSD",
      "price": 499.0,
      "currency": "USD",
      "link": "https://www.walmart.com/ip/Ejemplo-Laptop-15-6-in/5689219329"
    },
    {
      "itemId": "7741203355",
      "title": "Ejemplo de Laptop 2-en-1 con Pantalla Táctil, 8GB RAM, 256GB SSD",
      "price": 379.0,
      "currency": "USD",
      "link": "https://www.walmart.com/ip/Ejemplo-2-en-1-Laptop/7741203355"
    }
  ]
}

Algunas observaciones honestas sobre esta salida, que vale la pena conocer antes de ejecutar a gran escala:

• Tiempo de hidratación. La cuadrícula de búsqueda de Walmart monta primero un esqueleto, luego popula las tarjetas. Una corta espera después de la navegación antes de la extracción es lo que asegura una cuadrícula completa en lugar de una parcial. Si un paso devuelve muy pocas tarjetas, la cuadrícula no había terminado de hidratarse; lee el HTML renderizado nuevamente antes de ajustar selectores.
• Confirma que un 200 es real. La presencia del título del producto (laptop - Walmart.com) y un conteo poblado de anclajes a[link-identifier] es la señal de que la respuesta es la página real. Una cuadrícula vacía o un título faltante significa que el cuerpo es un desafío o un contenedor sin importar la línea de estado.
• Campos condicionales. No cada tarjeta lleva un precio visible (las disponibilidades agotadas o las colocaciones patrocinadas varían), y la página de detalle expone campos que la tarjeta de búsqueda no tiene. Trata los campos ausentes como null en lugar de eliminar la clave, para que los consumidores posteriores se mantengan estables.
• Estabilidad de selectores. a[link-identifier], [data-item-id], y [data-automation-id="product-price"] son los anclajes duraderos. Los nombres de clase con hash cambian con cada implementación; ancla en los atributos semánticos data-*.
• Variación regional. Los precios, la disponibilidad y el conjunto de resultados en sí varían según la región. Fija proxyCountry consistentemente para que una serie de historial de precios compare de manera uniforme.

Conclusión: escala tu pipeline de productos de Walmart

Scrapear Walmart de manera confiable se reduce a un principio: un código de estado no es una señal de éxito; una cuadrícula de productos renderizada lo es. Los proxies genéricos reenvían bytes desde una IP de EE. UU. y se detienen allí, razón por la cual un marcador público colocó la extracción válida con proxies genéricos por debajo del 40%, siendo el mayor fallo las páginas de bots servidas bajo un estado 200. La solución no es un mejor proxy; es un navegador real renderizado con salida residencial y comportamiento de sesión consistente.

El navegador de scraping Scrapeless proporciona eso como una superficie: crea una sesión residencial en EE. UU., conéctate a través de CDP, renderiza la URL de búsqueda, confirma que la cuadrícula de productos está presente, extrae los registros y camina hacia las páginas de detalle de producto dentro de la misma sesión. Fija la salida de EE. UU., mantiene los pasos de búsqueda y detalle dentro de una sola sesión, confirma que una respuesta lleva el título del producto y los anclajes de cuadrícula antes de confiar en ella, y trata los campos ausentes como anulables.
Para el mismo enfoque en otros sitios de comercio minorista y listas, consulte las guías hermanas Mejores Scrapers de Zillow en 2026 y Mejores Scrapers de Amazon en 2026.

¿Listo para construir tu canal de datos potenciado por IA?

Únete a nuestra comunidad para reclamar un plan gratuito y conectarte con desarrolladores que construyen canales de datos de comercio minorista: Discord · Telegram.

Regístrate en app.scrapeless.com para obtener tiempo de ejecución gratuito del Navegador de Scraping y adapta los patrones anteriores a las consultas, categorías y regiones que el canal necesita en Walmart. Consulta los planes actuales en la página de precios.

FAQ

P1: ¿Por qué un proxy de EE. UU. sigue siendo bloqueado en Walmart?

Porque Walmart evalúa más que el país al que se resuelve una IP. Verifica la reputación de la IP, la consistencia del comportamiento y la concentración de tráfico regional. Un proxy de EE. UU. a nivel de país solo cumple con la verificación de país; no ejecuta JavaScript ni mantiene el estado de la sesión. En la práctica, la mayoría de las respuestas de proxies genéricos en Walmart no son datos de productos utilizables.

P2: ¿Son suficientes los proxies residenciales por sí solos?

No. La salida residencial aumenta la confianza sobre los rangos de centros de datos, pero una IP residencial conectada a un cliente HTTP simple aún no renderiza la página ni mantiene una huella consistente del navegador. El camino confiable empareja la salida residencial con un navegador renderizado real y un estado de sesión persistente, que es lo que el Navegador de Scraping de Scrapeless combina en una sesión.

P3: ¿Cómo puedo confirmar que una respuesta 200 es real y no una página de CAPTCHA?

Verifica la carga útil, no la línea de estado. En un renderizado de búsqueda real de Walmart, el título de la página es laptop - Walmart.com y el DOM contiene anclas de producto (a[link-identifier]) y nodos [data-item-id]. Si falta el título y la cuadrícula está vacía, el cuerpo es un desafío o una shell no hidratada, independientemente del estado 200.

P4: ¿Cuántas solicitudes puedo ejecutar en paralelo?

Mantén la concurrencia moderada — alrededor de tres trabajadores por host — y fija la salida de EE. UU. en cada sesión. Para una mayor distribución, divide entre hosts en lugar de aumentar la concurrencia contra uno solo, para que el tráfico se mantenga naturalmente distribuido.

P5: Walmart cambió su DOM y mis selectores dejaron de funcionar. ¿Qué hago ahora?

Lee nuevamente el HTML renderizado en vivo, identifica los anclajes estables actuales (a[link-identifier], [data-item-id], atributos data-automation-id) y ajusta el extractor según lo que la página envía ahora. Ancla en los atributos semánticos data-* en lugar de nombres de clase hash, que rotan entre despliegues.

P6: ¿Puede esto funcionar sin un agente de IA?

Sí. El Python en los Pasos 1-4 se ejecuta de extremo a extremo por su cuenta: inicia la sesión, conecta a través de CDP, renderiza y extrae. Impulsarlo desde un agente de IA es una capa de conveniencia por encima, no un requisito.