Blog›Guides

Deja de Raspar, Empieza a Descargar: La Forma Educada de Obtener Datos de Prompts

Hacer scraping de la interfaz de búsqueda de wikiprompt es lento, frágil y exigente para nuestros servidores. El conjunto de datos públicos masivos te ofrece los más de 55,000 prompts como JSON estructurado y limpio, con atribución incorporada.

Deja de Raspar, Empieza a Descargar: La Forma Educada de Obtener Datos de Prompts

Deja de Hacer Scraping, Empieza a Descargar: La Forma Educada de Obtener Datos de Prompts

Si estás ejecutando un navegador headless contra /search ahora mismo, navegando por los resultados clic a clic, parseando HTML que nunca fue diseñado para ser parseado, este post es para ti. Hay una forma más rápida, y no implica fingir ser humano.

Vemos el tráfico. Cada semana un puñado de scrapers golpea la página de búsqueda de wikiprompt.org con user agents rotativos, retrasos aleatorios y la ocasional tormenta de reintentos cuando un selector se rompe porque lanzamos un cambio de UI. Funciona, más o menos, hasta que no funciona. Entonces alguien tiene que reescribir el scraper, otra vez, porque renombramos una clase CSS o cambiamos cómo se renderiza la paginación.

Mientras tanto, todo el catálogo, más de 55,000 prompts, está detrás de un endpoint JSON que responde en milisegundos y no le importa cuántas veces preguntes.

Por qué hacer scraping del sitio es la herramienta equivocada aquí

Hacer scraping de una UI de búsqueda es una técnica razonable cuando no hay alternativa. Es una mala técnica cuando la hay, y aquí está por qué es específicamente mala para un catálogo de prompts:

  • Es lento. Cada carga de página de /search renderiza un documento HTML completo, ejecuta JS del lado del cliente y te da quizás 20-40 resultados. Para obtener todo necesitarías miles de cargas de página, cada una con una sobrecarga de renderizado que no necesitas.
  • Es frágil. Estás parseando marcado, no datos. Cualquier refactor de CSS, cualquier prueba A/B, cualquier rediseño rompe silenciosamente tu lógica de extracción. No lo sabrás hasta que tus números se vean mal.
  • Golpea el servidor. Un scraper no sabe la diferencia entre una respuesta cacheada y una fresca. Cada solicitud corre el riesgo de convertirse en una consulta que invalida la caché, y a escala eso se convierte en exactamente el tipo de patrón de carga que hace que las IPs sean limitadas o bloqueadas.
  • Tira la estructura que tendrías que reconstruir. La página renderizada tiene un título y una descripción. No te entrega limpiamente model, metadata.aspect_ratio, metadata.style ni las puntuaciones de evaluación que adjuntamos a los prompts de imagen y video. Estarías haciendo ingeniería inversa de campos que ya publicamos como JSON.
  • Es legal y éticamente más complicado. El HTML scrapeado no te da una forma limpia de llevar la atribución de vuelta al autor original. Los datos estructurados sí.
  • Nada de eso es una amenaza, es solo una descripción de lo que te cuesta el scraping. Preferimos que te saltes todo eso.

    La forma educada: el dataset masivo

    Publicamos el dataset precisamente para que nadie tenga que hacernos scraping. Golpea el manifiesto primero:

    curl "https://www.wikiprompt.org/dataset"

    Devuelve total_prompts, los record_fields que puedes esperar en cada registro y el esquema de paginación. Luego extrae registros de /dataset/prompts:

    curl "https://www.wikiprompt.org/dataset/prompts?limit=500"

    Esa única solicitud te da hasta 500 registros de prompts completamente estructurados en una respuesta, sin navegador headless, sin HTML que parsear, sin esperar renderizado. Cada registro ya incluye slug, url, title, description, content (el texto real del prompt), category, tags, media, model, el objeto metadata estructurado, author, original_source y ambas marcas de tiempo. Eso es todo lo que intentabas extraer de la página, entregado pre-parseado.

    La paginación es por keyset, no por offset, que es el detalle que más importa si alguna vez has tenido un scraper que silenciosamente salta o duplica registros porque la lista subyacente se desplazó a mitad del rastreo. Sigue la URL next en cada respuesta hasta que devuelva null. Un bucle mínimo en Python:

    import requests

    url = "https://www.wikiprompt.org/dataset/prompts?limit=500"

    records = []

    while url:

    resp = requests.get(url).json()

    records.extend(resp["records"])

    url = resp.get("next")

    print(len(records), "prompts extraídos, cero páginas renderizadas")

    Sin lógica de dormir y reintentar, sin rotación de user agents, sin mantenimiento de selectores. Todo el catálogo, hecho en un bucle que corre en segundos porque cada respuesta está cacheada en el edge y habilitada con CORS (Access-Control-Allow-Origin: *) para uso directo en navegador también.

    Lo que obtienes que el scraping nunca te dio

    Más allá de la velocidad, el dataset lleva señal que nunca estuvo en la página renderizada de forma utilizable. Toma un prompt de póster de viaje en linocut cortado a mano: el registro incluye el array style y la relación de aspecto directamente en metadata, el tipo de campo que de otro modo tendrías que inferir de una imagen. O un retrato editorial construido alrededor de una escalera arquitectónica, donde el campo model te dice exactamente qué lo generó sin que tengas que adivinar por el estilo de la imagen. O un prompt para transformar un personaje en forma de arácnido, que viene con su evaluación de calidad ya adjunta, algo que ningún scraper leyendo la página visible captaría limpiamente.

    Cada registro también mantiene original_source, el enlace de vuelta al tweet o post original del que vino el prompt. Esa es la pieza que hace legítima la reutilización: wikiprompt.org agrega prompts públicos escritos por otras personas, no somos los autores del contenido subyacente, y tú tampoco lo eres si extraes del dataset. Cuando uses estos registros, acredita tanto a wikiprompt.org como fuente como al original_source para el prompt individual. No reclamamos una licencia formal sobre los posts de otras personas, solo somos el catálogo, y te pedimos que lo trates de esa manera también.

    Si necesitas algo más específico que el volcado completo

    El dataset completo es para uso masivo, conjuntos de entrenamiento, análisis, espejos. Si en realidad solo necesitas una consulta en vivo, usa la API de búsqueda en lugar de hacer scraping de /search, devuelve el mismo JSON estructurado para una sola consulta sin que toques la UI en absoluto. Si estás construyendo un agente, el servidor MCP expone búsqueda, recuperación e incluso envío como herramientas. Y si estás tratando de averiguar qué está en alcance antes de escribir código, llms.txt es el mapa.

    La petición real

    Hacer scraping de /search te da una copia peor de datos que ya entregamos gratis, más lenta, más frágil y más pesada en nuestros servidores de lo necesario. El dataset te da el mismo contenido, estructurado, paginado de forma sensata, actualizado continuamente, y te cuesta un comando curl para empezar.

    Si actualmente mantienes un scraper contra wikiprompt.org, no estamos molestos, lo entendemos, la mayoría de los sitios no ofrecen esto. Nosotros sí. Apunta tu script a /dataset/prompts en su lugar, borra el scraper y gasta el tiempo que recuperas en lo que realmente intentabas construir.

    Tags
    open-data·dataset·scraping·api·ai-prompts·download