La agenda de una sala de conciertos, el catálogo de una tienda, la página de adopciones de una protectora. Parecen páginas, pero detrás de muchas hay una lista que la web guarda en algún sitio y que a menudo le da a quien se la pida.
Queríamos saber cuántas, así que cogimos las 51 páginas de listados que hay detrás de nuestras hojas de prueba (conciertos y teatro en Madrid, cursos de cocina en Barcelona, perros en adopción, exposiciones, festivales) y las miramos una a una, sin ningún modelo. Entre todas enseñaban 1.323 elementos.
| Qué daba la web | Webs | % de los elementos |
|---|---|---|
| La lista entera como datos (el 90 % o más de lo que enseña la página) | 24 | 66 % |
| Una parte | 8 | 15 % |
| Nada, solo el texto de la página | 18 | 19 % |
| Nos bloqueó | 1 | 0 % |
Dos tercios de los elementos estaban ahí, como datos. Que un modelo los saque del texto de la página cuesta más y se pierden algunos.
Dónde están los datos
Ninguna de estas vías es cosa de una web concreta. Vienen con la plataforma con la que está hecha la web:
- La API de WordPress (
/wp-json/wp/v2/…), en 8 webs. Cada tipo de entrada que tiene la web (espectáculos, perros, cursos) es una lista que se puede leer. - La API de tienda de WooCommerce, en 6. Las escuelas de cocina venden sus cursos como productos, y alguna protectora publica así a sus perros. Nombre, precio, foto y enlace.
- La API de The Events Calendar, en 4. Nombre, fecha, foto y enlace de cada evento.
- El JSON que pide la propia página mientras carga, en 4. Es la vía más completa, y en cada web es distinta.
- Sitemaps en 4, solo con enlaces. Datos de eventos marcados para los buscadores en 2, calendarios iCal en 2 y un RSS.
Detrás de 19 de las 24 webs que lo daban todo hay un WordPress. Las 18 que no daban nada no tienen una plataforma en común, y muchas venden sus entradas a través de otra empresa.
Dos ejemplos
La agenda de la Sala Riviera enseña 51 conciertos. Su API de eventos devuelve 106, porque guarda también eventos que la agenda no muestra. Así que jurl no se lo queda todo: elige la lista cuyos elementos enlazan a las mismas páginas que enlaza la agenda, y la recorta con los filtros de la propia web (una categoría que tienen todos los que se ven, o la fecha del más antiguo).
La Sala Galileo Galilei mete sus 75 conciertos en el listado como datos de eventos, con nombre, fecha, foto, enlace y, en casi todos, el precio.
Qué hace jurl con esto
Desde el 19 de octubre, cuando jurl lee una lista, primero mira si la web está hecha con WordPress, y si tiene WooCommerce o The Events Calendar. Lo sabe por la propia página: WordPress enlaza su API en la cabecera, y los plugins dejan su nombre en el código. Si es así, coge la lista de ahí, con el nombre, la fecha, el precio, la foto y el enlace de cada elemento tal como los guarda la web. Leer el texto de la página queda para las webs que no publican nada.
La lista no es la fila entera. La API de WordPress casi nunca trae la fecha ni el precio, así que eso sigue saliendo de la página de cada elemento.
También cambia lo que cuesta tener una hoja al día. Que un modelo lea cien eventos del texto de la página cuesta unos euros. Leer esos mismos cien de los datos de la web cuesta céntimos, y da siempre el mismo resultado, que es justo lo que quieres de algo que se repite cada mañana.