La Raya · backend (6): afinar la guía — búsqueda, cercanía de verdad y el día que Google News dejó de funcionar

Una guía que ya se llena sola y aguanta en producción todavía puede ser incómoda de usar. Esta entrada va de los detalles que separan "tiene datos" de "se usa a gusto" — y de cómo una fuente externa puede romperte algo de un día para otro.

Buscar y ordenar por cercanía

Dos mejoras que cambian la experiencia:

• Búsqueda de texto completo sobre eventos y noticias, para encontrar por título/contenido sin depender solo de filtros.
• Ordenar por cercanía. Y aquí hubo aprendizaje: mi primera versión usaba distancia euclídea sobre lat/lng, que en la Tierra está mal (un grado de longitud no mide lo mismo en el ecuador que en Cáceres). La cambié por la fórmula de Haversine y añadí un filtro de radio máximo (max_km). Después bajé el radio por defecto de 100 km a 30 km, porque "cerca" para un usuario no es "a hora y media en coche". Pequeño número, gran diferencia en lo que ve la gente.

También añadí deduplicación por URL normalizada (quitando parámetros de tracking) para que el mismo artículo, llegado por dos fuentes, no apareciera dos veces.

España y Portugal, sin mezclar churras con merinas

Al ampliar a fuentes portuguesas (medios y municipios del Alentejo/Beira) y poblar lat/lng, aparecieron problemas de "frontera": contenido que se asignaba a la localidad equivocada, traducciones cruzadas, categorías mal puestas. Hubo una tanda de limpieza regional, mejoras del clasificador (añadir palabras clave de ciclismo, arreglar que los festivales se clasificaran mal) y afinado de qué se traduce. Nada espectacular por separado; en conjunto, la guía dejó de tener ese tufillo de "datos en bruto".

Y entonces Google rompió los enlaces

El golpe de realidad. Muchas noticias se agregan vía Google News RSS. En mayo ya tuve que hacer un primer arreglo: Google no daba la URL del artículo directamente, así que la extraía del HTML del summary. Funcionaba… hasta que dejó de funcionar.

Semanas después, los enlaces de noticias "mayoritariamente no funcionaban". Investigando, eran dos problemas sumados:

1. Google dejó de exponer la URL real en ningún sitio del RSS: tanto el <link> como el <a> apuntan ya a una redirección opaca (news.google.com/rss/articles/CBMi…) que ya no es una redirección simple (un GET te lleva a la página de consentimiento).
2. Además, el campo url_fuente era un URLField de 200 caracteres y esas URLs codificadas medían más → se truncaban, quedando irrecuperables.

La solución fue escribir un decodificador propio que resuelve el ID del artículo a su URL real mediante el endpoint interno batchexecute de Google (con la cookie de consentimiento adecuada), ampliar el campo a 512 con índice, y decodificar solo lo nuevo (el ID del artículo, estable, va como external_id, así que se filtra antes de gastar peticiones). De paso, un comando de gestión repara las noticias antiguas ya guardadas sin duplicarlas, y consolidé las fuentes por medio para cubrir todas las localidades.

Lo que me llevo

• Las unidades importan. Distancia euclídea en coordenadas geográficas es un bug esperando a que alguien viaje. Haversine y un radio sensato.
• "Cerca" es un número que hay que calibrar con usuarios, no con la regla. 100 km sonaba bien en mi cabeza; 30 es lo que la gente entiende por cercano.
• Si dependes de una fuente externa, no es si se romperá, es cuándo. Guarda identificadores estables (no solo URLs) para poder reconstruir cuando cambie. Ese external_id fue lo que me permitió reparar las noticias viejas en vez de perderlas.

Con la guía afinada y los enlaces arreglados, me lancé al añadido más grande de esta etapa: una sección de gastronomía que no existía, combinando varias fuentes. Es la próxima entrada, y trae el regreso triunfal de mi vieja enemiga: la deduplicación.