Freshness: precio y stock como parte de la indexación

Abres tres pestañas en tu navegador. Mismo SKU de botas de seguridad de tu ecommerce.

La ficha (la que ve el navegador) lleva availability: InStock en el JSON-LD. El feed de Merchant, el que subió Ads anoche a las 4:10, dice in_stock. Parece en roden.

El ERP, el de verdad, lleva a cero desde el martes. Ops.

Nadie ha “roto” nada. El cron del feed se lanza de madrugada. La plantilla mete el schema al generar la página. El albarán entra cuando entra. Tres ritmos distintos.

Pero Google no mira ritmos: mira si las tres afirmaciones cuadran. Si no, desaprueba el producto.

La entrega anterior iba del desacuerdo hacia fuera (tu web, tus distribuidores, los medios). Esto está todo dentro de tu casa: mismas superficies tuyas, mismo minuto.

Si tienes un ecommerce a mano, coge un SKU cuyo precio hayas cambiado esta semana. Apunta la hora del cambio en el ERP.

Ahora comprueba los tiempos de otros dos elementos: la del último feed procesado en Merchant y la de la última vez que se regeneró esa ficha (despliegue o purga de caché). La diferencia entre la primera y las otras dos es el número del que va este post. Si te sale en días y no en minutos, sigue leyendo, porque tienes un buen marrón.

En SEO, llevamos años midiendo la frescura editorial: cuándo publicas, cuándo pasó el rastreador, qué pone en datePublished y en dateModified. Google explica cómo estima esa fecha con bastante (y desacostumbrada) claridad: no hay un único factor y la fecha describe la página, no los hechos del párrafo. Actualizar el byline sin tocar el contenido es ruido, no estrategia.

Eso lo sabemos auditar: suele tener su propia columna en cualquier herramienta y hay reuniones enteras dedicadas a decidir si el post de 2023 se reescribe para actualizar la fecha o si se poda. Este es un clasicazo no tan trivial como parece.

Lo otro (precio, stock, plazo de envío, si la tarifa del trimestre es la que está publicada) no tiene su propio panel en Search Console. Su unidad de medida es en minutos: desde que cambia el sistema de gestión hasta que ese cambio se ve en el HTML que sirves y en la ruta del feed. Pero es más importante que tu ratio de indexación vs rastreo.

He visto fichas con dateModified de esta mañana y un priceValidUntil de la campaña de Black Friday del año pasado. El primero te da sensación de control. El segundo te puede dejar sin ficha enriquecida y no avisa.

Y llegamos al GEO. Que sí, que esto es importante, deja el debate de los nombres, anda. Qué cansino todo, de verdad.

El clic nos ha salvado siempre: el índice puede ir atrasado, pero el usuario acaba en tu página tal y como la generas en ese momento. Si el precio ha cambiado a las nueve de la mañana, lo ve bien aunque Google guarde una copia de hace tres semanas.

Y en ese modelo, cuánto pesa la frescura lo decide la consulta y no tú. Google lo dice claramente cuando explica que en temas de actualidad cuenta mucho más que en una definición de diccionario.

En una respuesta generada esa última corrección no existe. El sistema recupera, extrae la afirmación (precio, disponibilidad, plazo de entrega, tarifa) y la mete dentro del texto, sin que nadie pase por tu ficha. Dos caminos y ninguno te devuelve el clic:

• Con recuperación en el momento: entra lo que ya tengas publicado, en el HTML o en el feed. La doc de Google define grounding como “vincular la salida a fuentes verificables” precisamente para que el modelo no rellene por su cuenta. Si tu superficie no contesta a tiempo, contesta otra superficie diferente.

• Sin recuperación para ese pasaje: el modelo responde con lo que ya traía dentro, que puede ser de hace meses.

Las dos frescuras del apartado anterior tampoco se comportan igual aquí:

• La editorial sigue funcionando como señal sobre la página (fechas, cadencia, si tu documento merece ser leído).

• La de estado se convierte en el contenido de la respuesta: en GEO la unidad que se recupera es la afirmación, no el documento.

• Un dato tuyo mal actualizado no se queda en tu HTML esperando a que alguien lo vea; se copia y se presenta como si lo hubieras dicho tú hoy.

Ahí desaparece también la respuesta leída. El agente no te cita: te compra, te reserva o te pide presupuesto con el estado que haya recuperado.

• Sin clic que corrija en la ficha.

• Sin lector humano que diga “esto no cuadra” antes de pagar.

• La frescura de estado deja de ser el contenido de un texto y pasa a ser el input de una transacción.

El UCP de Google ya monta parte de eso sobre feeds de Merchant. El desfase de minutos del principio deja de ser un problema de ranking: es un pedido mal hecho o un pedido que se va a otra cuenta.

Por eso el resto del post va de superficies (HTML servido, JSON-LD, feed) y no de fechas.

Merchant Center no improvisa sus datos o los criterios que aplica sobre ellos. En requisitos de landing dice que coteja la fuente de datos con lo que muestra el sitio. En desajustes de disponibilidad concreta cuatro sitios: landing, checkout, structured data y fuente de datos. Fallas uno, se cae el producto.

En la práctica, el reparto de quién toca qué suele ser este (cámbialo si el tuyo es peor):

• Feed: Ads o e-commerce. En más de una cuenta lo sube alguien de paid los martes y a SEO no le llega ni un ping en Slack.

• Checkout: producto / tienda.

• ERP o PIM: sistemas.

• HTML servido + JSON-LD: tú. O deberías.

Si el precio no va en el HTML inicial, el resto del cotilleo entre departamentos da igual.

Se comprueba en un comando:

curl -sL https://tu-dominio/p/SKU | grep -i Offer

Si el bloque Offer solo aparece después de hidratar (la hidratación es el momento en que el JavaScript rellena en el navegador un HTML que llegó incompleto), para ese rastreo no existía: los rastreadores automáticos capturan la página tras la carga inicial y se quedan con eso.

Y el marcado generado solo con JavaScript hace los rastreos de Shopping menos frecuentes y menos fiables justo donde el dato cambia cada pocas horas. Es el argumento que uso cuando front no quiere tocar la plantilla de producto. A veces gano a la tercera desaprobación.

Las actualizaciones automáticas de producto rastrean la landing, leen tus datos estructurados (o tiran de extractores si no hay marcado) y parchean precio, disponibilidad y condición en el feed. Están pensadas para un porcentaje pequeño de productos y para líos temporales. Suenan a red de seguridad. Lo son... a medias.

Tres cosas que me han estropeado auditorías reales:

1. El cotejo es laxo. in_stock, preorder y backorder se tratan como compatibles. Panel en verde, ficha mintiendo con permiso.

2. Sin marcado fiable, extractores. Modelos leyendo tu HTML. A veces clavan. A veces inventan un estado que nadie ha puesto en el PIM.

3. Si tu schema no es preciso, pueden dejar de consultarlo. Duele más que una penalización con cartelito: has montado JSON-LD para que te ignoren con elegancia.

Lo del punto 3 me jode especialmente: te pasas el sprint defendiendo structured data en backlog y el sistema, en silencio, deja de leerlo. Desde entonces compruebo si el precio que Merchant tiene en ficha sale de mi JSON-LD o lo está sacando por su cuenta.

Cliente B2B industrial, catálogo de piezas. El comparador (humano con quince pestañas o agente; cada vez me importa menos el disfraz) pone tres proveedores en fila y descarta al más caro. El más caro somos nosotros, con la tarifa del trimestre bien puesta. Los otros dos arrastran precio viejo en el feed. Gana el desactualizado.

Con comerciales eso se arreglaba en una llamada. Si un agente filtra antes de enseñarle nada a nadie, esa llamada no llega a existir.

Y el fichero que “era de Ads” ya es superficie de recuperación: la guía de optimización para IA recomienda Merchant Center para respuestas generativas. Suele llegar al backlog de SEO con medio año de retraso.

Diez URLs de producto al azar. Al azar de verdad, no las que ya miraste el mes pasado. Cuatro columnas:

1. Sistema de gestión.

2. HTML servido curl, sin JS).

3. JSON-LD de esa misma respuesta.

4. Feed de anoche.

Si más de un 10% de filas no cuadran, tienes un problema de arquitectura de publicación. Se va a hacer notar con la desaprobación de productos o como una recomendación en Merchant.

Automatizar la comparación es un script de un par de tardes. Yo tardé tres: el primero mezclaba precios con IVA y sin IVA y me pasé la mañana convencido de haber descubierto el apocalipsis.

Para el informe, separaría las dos frescuras. Una: dateModified y cadencia editorial. Otra: SLA de estado en minutos (p95) desde el cambio en origen hasta que se ve en HTML servido y en la ruta del feed. Mientras las metamos bajo la misma etiqueta en la misma reunión, la segunda pierde siempre.

Además de las cuatro columnas: mira si priceValidUntil arrastra fechas muertas, y comprueba que al cambiar un precio la invalidación de caché alcance también la ruta del feed. Esa última se queda fuera casi siempre.

La semana que viene lo ordeno en un checklist conjunto de SEO y PPC para búsqueda con IA. Hoy me vale con que alguien me diga si ese 10% es un umbral razonable o una ingenuidad.

¿Has puesto alguna vez JSON-LD y feed en la misma tabla? ¿Qué % te salió? Respóndeme al correo.

Si quieres que revisemos la paridad entre capa rastreable, feed y sistema de gestión, es uno de los análisis que hacemos en bigmomo. Puedes escribirme.