Amazon y Google: por qué un HTTP 200 puede seguir siendo un fallo

Un HTTP 200 de Amazon o Google no es evidencia de que un scraping haya funcionado. Ambos sitios pueden responder a una petición con aspecto de bot con una página de desafío, un shell de búsqueda que necesita JavaScript para rellenarse o una página completa de marcado que aun así carece de los registros que un parser necesita, y los tres llegan con estado 200. Este artículo describe esos patrones de respuesta, por qué el estado por sí solo es una mala comprobación de éxito, y las reglas e interfaces oficiales que hay que revisar antes de recopilar nada. No reporta mediciones de ninguno de los dos sitios ni establece cómo se comportarían los proxies residenciales o móviles.

Cómo son estas respuestas en la práctica

Tres clases de respuesta explican la mayor parte de la confusión, y ninguna de ellas se distingue por el código de estado.

Una página de desafío. El estado es 200, el cuerpo es pequeño, el título está en blanco o es genérico, y el HTML consiste principalmente en JavaScript que dispara un interstitial o una comprobación de gestión de bots. El marcado de desafío de Amazon, por ejemplo, lleva una función de desafío y un marcador de verificación en lugar de contenido de la tienda. Un contador de éxitos basado solo en el estado acepta esta respuesta aunque el parser no encuentre nada.

Marcado de búsqueda. El estado es 200, el cuerpo es grande, el título repite la consulta, y los contenedores de resultados se repiten a lo largo de la página. Esto parece un éxito, pero contar el nombre de una clase de contenedor no es un conjunto de registros validado. Contar una cadena no es lo mismo que parsear cada tarjeta de producto y confirmar que su identificador, precio y título están presentes.

Un shell de página. El estado es 200, el cuerpo tiene un tamaño moderado, el título es el nombre genérico del sitio, y el HTML contiene un script que pide al navegador activar JavaScript junto a un bloque noscript. No existen encabezados de resultados con los que un parser pueda coincidir. Esto es coherente con un marcado que espera más procesamiento por parte del navegador, pero no te dice si un navegador tendría éxito ni si una dirección de salida distinta recibiría el mismo shell.

La misma dirección puede recibir distintas clases de respuesta en peticiones consecutivas a rutas diferentes. Por tanto, una dirección IP por sí sola no predice la respuesta: la ruta, los tiempos, las cabeceras, las cookies y las decisiones del lado del servidor contribuyen, y ninguno de esos factores se controla cambiando la salida.

La conclusión útil es estrecha: la línea de estado no le dice a un parser si tiene los datos que necesita. Trata el 200 como «llegó una respuesta», no como «el scraping tuvo éxito».

Comprueba el cuerpo, no el estado

Una comprobación de contenido necesita al menos cuatro preguntas respondidas por cada respuesta.

• ¿El título coincide con lo que debería ser la página, en lugar de estar en blanco, ser el nombre genérico del sitio o una página de verificación?
• ¿El cuerpo contiene un marcador de script de desafío o de gestión de bots? Si es así, clasifica la respuesta como desafío sin importar el estado.
• ¿Cuántos registros se parsearon, y cada uno lleva los campos que la aplicación necesita? Registra el recuento parseado, no el recuento de una cadena marcadora.
• ¿El HTML es un shell que espera que JavaScript lo rellene? Un bloque noscript o un script de «activa JavaScript» es una señal fuerte.

Registra las respuestas junto al estado HTTP, el código de salida de curl y los tiempos de la transferencia. Los campos de --write-out de curl como size_download y time_starttransfer están documentados en el manual de curl; describen la transferencia, no el resultado de la aplicación, y ambos deben registrarse uno junto al otro.

Robots.txt y reglas del servicio

El Protocolo de Exclusión de Robots describe instrucciones para rastreadores. La RFC 9309 distingue explícitamente esas instrucciones de la autorización de acceso. La ausencia de una regla disallow no es, por sí misma, permiso para recopilar o reutilizar contenido.

En la revisión del 11 de septiembre de 2026, el robots.txt de Google prohibía /search en su grupo general de user-agent, con excepciones específicas que incluían /search/about y /search/howsearchworks. Evalúa la ruta real y el grupo aplicable; un recuento de reglas o un número de línea no es una comprobación de permiso útil.

Para Amazon, revisa el robots.txt y las Condiciones de uso del marketplace aplicable, junto con cualquier acuerdo específico del programa. Este artículo no establece que ninguna ruta de búsqueda o de producto esté autorizada para una recopilación o reutilización concreta.

Los términos de Google vigentes desde el 30 de julio de 2026 restringen el acceso automatizado que viole sus instrucciones legibles por máquina. Su política de Search sobre tráfico generado por máquinas cubre por separado el acceso automatizado a Search sin permiso expreso, incluido el scraping de resultados para comprobar posiciones. Revisa los documentos vigentes para tu servicio y región; cambiar de dirección de salida no cambia esos requisitos.

Opciones oficiales de acceso a datos

Elige una interfaz según los datos y el uso permitido que tu aplicación necesite. La disponibilidad indicada abajo se revisó el 11 de septiembre de 2026.

• Amazon Creators API proporciona acceso al catálogo de productos para publishers y socios afiliados bajo los requisitos de su programa. Es el sucesor soportado de Product Advertising API 5. El aviso de retirada de Amazon dice que las llamadas continuadas a PA-API 5 reciben una respuesta 403 con AccessDeniedException. Empieza por la documentación de Creators API.
• Amazon Selling Partner API da soporte a aplicaciones autorizadas que trabajan con datos de socios vendedores, como listados y pedidos. Su visión general explica el alcance; el acceso depende de la aplicación, los permisos y el socio vendedor.
• Google Custom Search JSON API está cerrada a nuevos clientes. Los clientes existentes deben migrar a una alternativa antes del 1 de enero de 2027. La visión general de Google remite a Vertex AI Search para hasta 50 dominios y a una vía de consulta para necesidades de búsqueda en toda la web. Estas opciones requieren una comprobación aparte de idoneidad y disponibilidad; la API heredada no es un punto de partida disponible para un cliente nuevo.
• Google Search Console informa del rendimiento de búsqueda de tu propio sitio, incluidos clics, impresiones y posición media. Esas métricas pueden responder preguntas sobre tus propiedades verificadas, pero no proporcionan un feed completo de posiciones de la competencia.

Las interfaces oficiales tienen requisitos de elegibilidad, permisos, cuotas y condiciones de uso. Compara su cobertura con los campos, la frescura y los mercados reales que tu aplicación requiere. Una interfaz documentada sigue necesitando manejo de errores y no garantiza acceso ilimitado a los datos.

Cuándo puede ayudar una conexión desde una ubicación concreta

Una comprobación de ubicación autorizada podría investigar cómo aparece tu listado en otro mercado, si una campaña regional es visible o por qué un cliente ve contenido distinto. Son razones para evaluar una conexión desde la región correspondiente, sujeto a las reglas del servicio.

Una IP de salida es solo una de las entradas de una prueba así. Mantén constantes el navegador, el idioma, el estado de la cuenta y los ajustes de sesión, y registra qué cambiaste. Una sola petición o un volumen bajo no establecen por sí mismos un permiso, y una salida regional no reproduce la vista personalizada de cada cliente.

La guía de proxies rotativos vs persistentes explica las opciones de sesión. La comparación de proxies residenciales vs de datacenter describe cómo evaluar pools candidatos. Este artículo no mide ninguno de los dos tipos; elige entre ellos con una comparación autorizada de tu propia carga de trabajo.

Qué registrar en una comparación autorizada

Define el éxito de la aplicación antes de hacer peticiones. Para datos de producto, eso puede significar un identificador de producto coincidente y todos los campos requeridos; para datos de búsqueda, una estructura de resultados parseada y el contexto de consulta esperado. Un recuento de títulos o de marcadores puede ser un diagnóstico útil, pero no debería sustituir la validación de los registros que vas a usar.

Registra la URL pública de prueba y la consulta exactas, la marca de tiempo en UTC, la versión del cliente, los ajustes de la petición, la política de redirecciones, el gateway o la ruta directa, y el método de comprobación de contenido. Conserva los estados HTTP y CONNECT, el código de salida de curl y los tiempos junto al resultado de la aplicación. Retén suficiente evidencia de respuesta saneada para explicar un desafío, campos ausentes o un cambio en el resultado del parser.

Para una comparación justa, mantén constantes los ajustes del cliente y de la petición, muestrea varias direcciones de cada tipo de red candidato e intercala las peticiones durante la misma ventana de observación. Resultados distintos justifican una investigación; por sí solos no demuestran que el tipo de red causara la diferencia. Cualquier prueba sostenida necesita además una tasa de peticiones permitida y una condición de parada definida.

El método de benchmark ofrece un punto de partida para las mediciones de transporte y explica dónde hacen falta comprobaciones específicas de la aplicación. Si el CONNECT devuelve 407, investiga la autenticación del proxy con la guía del 407. La guía de configuración de curl muestra cómo registrar por separado el estado del CONNECT y el estado HTTP.

Qué no establece este artículo

Este artículo no compara respuestas entre salidas residenciales o móviles, no prueba el renderizado en navegador, no valida registros de producto completos ni mide tasas de desafío sostenidas. Ningún recuento de peticiones desde una sola dirección puede estimar la tasa de éxito de un proveedor ni predecir cómo se comportaría un volumen de peticiones distinto. Usa los patrones anteriores para diseñar una comprobación de contenido; basa la elección de proxy en una comparación autorizada e independiente de la carga de trabajo que necesitas ejecutar.

Etiquetas:ProxiesChoosing proxies