¡Y funcionó! Hay un identificador de trabajo (d8e52hhvjngc73ant800, por si alguien quiere comprobarlo) que demuestra que el circuito corrió en un chip de IBM y no en una simulación.

Antes que pierdas el tiempo aquí te aviso ya... para SEO no sirve de nada. Pero si eres un nerd, seguro que querrás seguir leyendo.

A continuación explico de dónde sale la idea, qué hice exactamente y por qué Google no haría esto ni queriendo.

No hace falta saber física porque voy a explicarlo todo para que se entienda.

El PageRank simula un navegante que va dando tumbos aleatorios por Internet...

La definición original de PageRank (Brin y Page, 1998) es recursiva y un poco circular, es decir, que una página es importante si la enlazan páginas importantes, que a su vez lo son si las enlazan otras importantes, y así hasta el infinito. Lo cual tiene un problema gordo, ya que eso es imposible de calcular.

Para que eso fuera calculable, Brin y Page lo explicaron con un modelo que acabó siendo hasta más famoso que la propia fórmula: el del random surfer (el navegante aleatorio).

Imagina a alguien navegando sin rumbo que entra en una página, pincha un enlace al azar, llega a otra, pincha otro, y así durante horas. De vez en cuando se aburre y, en lugar de seguir un enlace, salta a una página cualquiera del sitio (ese es el famoso damping factor de 0,85, es decir, el 85% de las veces sigue un enlace, el 15% salta). El PageRank de una página es la fracción de tiempo que el navegante pasa ahí.

Lo que mola de esto es que los dos caminos dan exactamente el mismo resultado. La definición recursiva y el tiempo que pasa el navegante coinciden hasta el último decimal.

Quédate con lo del navegante aleatorio porque esto con la versión cuántica del PageRank va a cambiar. En matemáticas el navegante es una cadena de Markov y lo único que decide el siguiente paso es dónde estás ahora y no cómo llegaste. Un ordenador normal esto se resuelve en un momento, incluso para la web entera es trivial y eficiente. Yo lo implementé en 2011, después de una discusión en Twitter, y el código me cabía en media pantalla.

...y la versión cuántica cambia el dado por una onda

En 2012, dos físicos (Giuseppe Paparo y Miguel Ángel Martín-Delgado) publicaron en Scientific Reports un artículo titulado Google in a Quantum Network. Se preguntaron: ¿y si en vez de un navegante que tira un dado en cada paso, pones uno que se comporta como una onda?

El navegante clásico está siempre en una página concreta, pero el navegante cuántico está repartido por muchas páginas a la vez, en lo que se llama una superposición. Y los distintos caminos que podría tomar interfieren entre sí, como las olas en el agua, que en unos puntos se suman y en otros se cancelan. Esa interferencia hace que la "probabilidad" de acabar en cada página se reparta de una forma distinta a la clásica.

Y esto se vuelve SUPER pesado de calcular porque el estado del navegante cuántico es de qué página vengo y a cuál voy. Es decir, si tu sitio tiene N páginas, los pares posibles son N por N, o sea N². Para las 123 páginas de mi blog eso son unos 15.000 estados posibles.

El motor de todo este invento se llama walk de Szegedy. Vamos, que el algoritmo no es mío, lo único que hago yo es aplicarlo a mi blog. Lo que sí es nuevo, es haberlo ejecutado en un ordenador cuántico de verdad, porque Paparo y compañía lo simularon en ordenadores normales. Nadie, hasta donde he podido ver, había metido el quantum walk de una web real en un chip cuántico físico.

Antes de empezar, repliqué el ejemplo que ellos publican en el paper, un arbolito de 7 nodos en 3 niveles, con unos valores concretos en una tabla y el código tenía que devolver esos mismos números y los devolvió, con cuatro decimales de acuerdo. A partir de ahí supe que íbamos por el buen camino.

Sobre mis datos también reaparecen los hallazgos que ellos describen en su paper: el ranking se reordena, emergen "hubs secundarios" que el clásico no destacaba, la cola de páginas poco enlazadas se redistribuye. Hay una afirmación suya que no logré reproducir bien, la mayor estabilidad frente al damping, pero es que esa propiedad necesita promediar sobre muchos grafos distintos y yo tengo uno solo. Lo digo para no venderte algo que no vi.

Calculando el Quantum PageRank de mi blog en el ordenador cuántico de IBM

Cogí un trozo pequeño del blog (luego entenderás la razón), solo 4 páginas que se enlazan entre sí (la home, el índice de artículos y dos posts), y mandé el circuito al ibm_marrakesh, con un procesador de 156 qubits.

El resultado es curioso, el PageRank clásico de ese grupito corona el índice de artículos por encima de la home. La versión cuántica le da la vuelta y pone la home primero. Y he comprobado que no se trata de un error, porque el cálculo ideal simulado lo predice y el chip, con su ruido y todo, lo respeta. Así que la home gana.

La barra de la home en el chip sale más alta de lo que debería. Resulta que un qubit, si lo dejas quieto, pierde energía y cae a su estado de reposo, el que etiquetamos como |0⟩ (se lee "ket cero" y es un qubit a cero). Es como una peonza que, según se va frenando, tiende a pararse siempre en la misma posición. A eso se le llama relajación, y como estos circuitos son largos, a muchos qubits les da tiempo a dormirse hacia el 0 antes de que midamos. El resultado se sesga hacia la cadena de todo ceros, el |00⟩ ("ket cero cero" = dos qubits en cero).

¿Y por qué le toca justo a la home? Porque por cómo numeré las páginas, la home es la número 0, que en binario es justo |00⟩. La tendencia natural del chip a caer en |00⟩ se confunde entonces con que el navegante terminó en la home. Parte de esa barra alta es lícita, porque el cálculo ideal también pone la home primera, pero otra parte es este artefacto ya que el chip mezcla haberse relajado al |00⟩ con que haya ganado la home.

Para limpiarlo usé dos técnicas estándar. La primera, dynamical decoupling, mete pulsos rápidos en los ratos en que un qubit está esperando sin hacer nada, para que no se duerma (es como ir dando toquecitos a la peonza para que no se pare). La segunda, twirling, repite el experimento muchas veces cambiando al azar pequeños detalles de cómo se aplican las puertas, de modo que un error que siempre tira hacia el mismo lado se vuelve ruido aleatorio que se cancela al promediar. En vez de equivocarte igual siempre, te equivocas distinto cada vez y la media sale más limpia.

Con las dos, la diferencia entre lo que da el chip y el cálculo ideal se redujo a la mitad, y la barra de la home bajó hacia donde tenía que estar. Aun así, que quede claro... sigue siendo un experimento de juguete de 4 nodos.

¿Y por qué no puedo correr el blog entero?

Por el muro. Para ejecutar el walk de Szegedy en un chip cuántico hay que traducirlo a "puertas" que son las operaciones elementales del procesador. Las que fastidian son las de 2 qubits, porque cada una añade un poco de ruido. Y el número de puertas crece de forma brutal con el tamaño del grafo:

Con 4 páginas son unas 180 puertas de 2 qubits sobre el chip y aún se distingue algo. Pero con 8 páginas saltas a unas 3.700 puertas, y a esa profundidad la probabilidad de que el circuito sobreviva sin un error es de aproximadamente 0,99 elevado a 3.700, que es prácticamente cero. El resultado es pura basura uniforme. Podéis ver que el cálculo ideal de esas 8 páginas tiene una estructura clara, pero lo que escupe el chip es indistinguible de tirar un dado.

Para el blog completo, 123 páginas, harían falta del orden de 270 millones de puertas, o lo que es lo mismo, ciencia ficción. Y ojo porque aquí yo creía que es por un problema de qubits pero no. Para 123 páginas bastarían unos 14 qubits y los chips de hoy tienen cientos. El problema es la profundidad del circuito y el ruido que acumula el mismo. Así que ahora entiendo porqué los propios inventores de la fórmula nunca lo han acabado metiendo en hardware, ahora incluso que es posible, y se limitaron a simularlo en una CPU, donde todo esto es trivial.

Para curiosos, este es el circuito que ha habido que montar para 4 urls:

Desplázate en horizontal para recorrer el circuito completo.

¿Cambia el ranking? Sí, pero no para mejor

Así que he hecho lo mismo que realizaron los inventores, hacer una simulación de PR cuántico usando el blog entero. Así podremos ver si computo el PageRank cuántico de las 123 páginas me dice algo que el clásico no.

Por un lado, veo que los dos rankings se parecen bastante en conjunto. La correlación de Spearman entre ambos es de 0,85, lo cual es alto. Pero por otro lado, lo que veo que cambia es el "head" de mi blog, es decir las 10 primeras páginas del ranking clásico, solo 4 siguen en el top 10 cuántico, y la 1 cambia. Más de la mitad de las páginas se mueven 10 puestos o más.

¿Y qué hago con eso como SEO? Nada. Es otra medida de centralidad, distinta y matemáticamente legítima. Pero no hay ninguna razón para pensar que su orden sea el "bueno", el que importa para posicionar. Es simplemente diferente, no mejor.

¿Tendría sentido que Google hiciera esto?

No. Y vale la pena entender por qué y así entendemos para qué sirve de verdad un ordenador cuántico:

1. Primero: El PageRank ya se calcula rapidísimo en ordenadores normales. Es lo que en informática llamamos un problema "fácil", de coste polinómico, donde no hay nada que acelerar.
2. Segundo: la versión cuántica tampoco es más rápida. Suena raro después de todo el rollo del espacio de N², pero resulta que toda la acción ocurre en un rincón pequeño de ese espacio (de tamaño proporcional a N, no a N²), así que un ordenador normal solo necesita seguir ese rincón. No da ventaja de velocidad, es tan solo un ranking distinto.
3. Y tercero: ejecutarlo en un chip cuántico a escala web es imposible por el muro que acabo de contar.

Un ordenador cuántico es una herramienta para problemas muy concretos donde se ha demostrado que gana como factorizar números enormes (lo que rompería parte de la criptografía actual), simular el comportamiento de moléculas y materiales, ciertos tipos de búsqueda y optimización.

PageRank no es uno de esos. Es barato computacionalmente y meterlo en una máquina cuántica es traer un instrumento carísimo y frágil a una tarea que un portátil ya hacía en un momento.

Llevo años leyendo mucho sobre cuántica, y la lección que he sacado es que la mayoría de los problemas que tenemos actualmente no son del tipo que un cuántico resuelve mejor. A continuación os cuento la razón.

La historia de descuantizar

En 2018, una estudiante de grado de 17 años, Ewin Tang, hacía su tesis con Scott Aaronson (super fan de este señor) en la Universidad de Texas en Austin. Le pusieron demostrar que cierto algoritmo cuántico de moda, uno de sistemas de recomendación (el de Kerenidis y Prakash, el tipo de motor que hay detrás de "productos que también te pueden gustar"), no se podía igualar con un ordenador normal. Se pasó meses intentando probar esa imposibilidad, hasta que empezó a sospechar justo lo contrario. Acabó construyendo un algoritmo clásico que igualaba al cuántico y que era exponencialmente más rápido que cualquier intento clásico anterior. Así que el supuesto superpoder cuántico no estaba donde se pensaba.

A esa maniobra ahora se la llama ahora descuantizar. Consiste en coger un algoritmo cuántico que presume de ir exponencialmente más rápido y encontrar uno clásico que hace lo mismo. Desde el trabajo de Tang han caído unos cuantos, entre ellos versiones cuánticas de recomendación, de análisis de componentes principales, de resolución de sistemas lineales o de máquinas de vectores soporte. Vamos, que la "ventaja cuántica" salía de compararse contra un método clásico mediocre, no contra el mejor que había. En cuanto alguien se molestaba en buscar el mejor clásico, la ventaja se evaporaba.

El Quantum PageRank es lo mismo, un invento caro.

Para qué ha servido esto

Como experimento está muy bien. Es investigación de verdad, ejecutada por primera vez en hardware cuántico, y sobre el grafo de mi web. He visto cómo se traduce un algoritmo a "puertas", el problema del muro del ruido y por qué los qubits no son el cuello de botella.

Como herramienta SEO no vale nada, aviso por si algún GEO bro le da por venderte un "Prompt Tracker Cuántico", aunque bueno... devolviendo visibility scores de Schrödinger, algo cuánticos sí que lo son.

Consejo: Si quieres trastear con un ordenador cúantico, IMB te da 10 minutos gratis de cómputo al mes. Aprende a factorizar números enormes o simula una molécula. Para rankear páginas, sigue bastando el navegante que va dando tumbos de forma random.

Lo único útil que saqué fue por accidente

En la primera pasada, el cálculo cuántico me rescató del fondo del ranking a 2 páginas que el clásico tenía enterradas. Me emocioné un segundo pensando que había encontrado algo. Fui a mirar qué páginas eran y resultó que una era una redirección 301 y la otra un enlace interno roto, un 404, que se me habían colado como nodos del grafo. El "hallazgo cuántico" eran mis propios fallos de enlazado...

O sea que lo más accionable de todo el experimento fue que me obligó a limpiar dos enlaces rotos. Usar un ordenador cuántico para esto no tiene precio

Metodología y datos

El grafo sale de un rastreo con Screaming Frog (el informe All Inlinks). Los nodos son las URLs internas y las aristas son los enlaces internos. Filtré a enlaces de tipo Hyperlink, con atributo follow y respuesta 200, sin duplicados, y de ahí salen 1.091 aristas. Para el análisis del post me quedo solo con los enlaces que viven en el contenido (503 aristas), no en el menú, la cabecera o el pie, porque el sitewide reparte autoridad de una forma que no dice nada sobre la importancia editorial de cada página. Damping de 0,85 y teletransporte uniforme, tal y como lo plantea Paparo.

El código, por si quieres reproducirlo

Dejo las dos piezas de código listas para copiar. La primera es el motor del Quantum PageRank y solo necesita NumPy. Ya trae de ejemplo el árbol de Paparo, así que al ejecutarla deberías ver sus números de la Tabla 1. La segunda ejecuta el walk en un ordenador cuántico de IBM con Qiskit (necesitas una cuenta gratuita y haber guardado tus credenciales con QiskitRuntimeService.save_account(...)).

import numpy as np

def quantum_pagerank(G, steps=2000):
    """Quantum PageRank de Paparo (walk de Szegedy, 2012).
    G = matriz de Google column-stochastic (sus columnas suman 1).
    Devuelve (media, desviacion) de I_q por nodo."""
    N = G.shape[0]
    A = np.zeros((N*N, N)); sq = np.sqrt(G)        # columnas |psi_j> = |j> x sum_i sqrt(G_ij)|i>
    for j in range(N):
        A[j*N:(j+1)*N, j] = sq[:, j]
    def U(x):                                       # paso del walk: U = S (2 A A^T - I)
        Rx = 2*(A @ (A.T @ x)) - x                  # reflexion
        return Rx.reshape(N, N).T.reshape(-1)       # swap
    psi = A @ (np.ones(N)/np.sqrt(N))               # estado inicial
    serie = np.empty((steps, N))
    for m in range(steps):
        serie[m] = (np.abs(psi.reshape(N, N))**2).sum(axis=0)   # marginal del 2do registro
        psi = U(U(psi))                             # avanza U^2 (se mide en pasos pares)
    return serie.mean(0), serie.std(0)

def google_matrix(edges, N, alpha=0.85):
    """G column-stochastic desde aristas (origen, destino). Dangling -> teletransporte uniforme."""
    S = np.zeros((N, N))
    for src, dst in edges:
        S[dst, src] += 1                            # la columna es el nodo de origen
    out = S.sum(axis=0)
    for j in range(N):
        S[:, j] = S[:, j]/out[j] if out[j] else 1.0/N
    return alpha*S + (1-alpha)/N

# Ejemplo: el arbol binario de Paparo (7 nodos, aristas hijo->padre).
# Reproduce su Tabla 1 -> cuantico por nivel ~ [0.356, 0.151, 0.085].
edges = [(1,0),(2,0),(3,1),(4,1),(5,2),(6,2)]
media, desv = quantum_pagerank(google_matrix(edges, N=7))
print(media.round(3))

import numpy as np
from qiskit import QuantumCircuit, ClassicalRegister, transpile
from qiskit.circuit.library import UnitaryGate
from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2

def walk_operator(G):
    """U = S (2 A A^T - I) como matriz densa N^2 x N^2 (solo N pequeno: 4-8 nodos)."""
    N = G.shape[0]
    A = np.zeros((N*N, N)); sq = np.sqrt(G)
    for j in range(N): A[j*N:(j+1)*N, j] = sq[:, j]
    R = 2*(A @ A.T) - np.eye(N*N)
    idx = np.arange(N*N); a, b = idx//N, idx % N
    S = np.zeros((N*N, N*N)); S[b*N + a, idx] = 1.0
    return S @ R

def run_on_ibm(G, t=1, shots=8192, mitigate=True):
    """Ejecuta U^t en el QPU menos ocupado. Devuelve la distribucion del 2do registro y las puertas.
    Requisito: guardar antes la cuenta con
    QiskitRuntimeService.save_account(channel='ibm_quantum_platform', token=..., instance=...)."""
    N = G.shape[0]; k = int(round(np.log2(N)))          # qubits por registro
    Ut = np.linalg.matrix_power(walk_operator(G), t)
    qc = QuantumCircuit(2*k)
    qc.append(UnitaryGate(Ut), range(2*k))              # el walk entero como una sola puerta
    creg = ClassicalRegister(k, "meas")
    qc.add_register(creg); qc.measure(range(k), creg)   # medimos solo el 2do registro (qubits bajos)
    backend = QiskitRuntimeService().least_busy(operational=True, simulator=False)
    tqc = transpile(qc, backend=backend, optimization_level=3)
    sampler = SamplerV2(mode=backend)
    if mitigate:                                        # supresion de ruido
        sampler.options.dynamical_decoupling.enable = True
        sampler.options.dynamical_decoupling.sequence_type = "XY4"
        sampler.options.twirling.enable_gates = True
        sampler.options.twirling.enable_measure = True
    counts = sampler.run([tqc], shots=shots).result()[0].data.meas.get_counts()
    m = np.zeros(N)
    for bits, c in counts.items(): m[int(bits, 2)] += c
    return m/m.sum(), tqc.count_ops()

# G es la misma matriz de Google del bloque anterior (usa 4 u 8 nodos para que quepa).
# dist, puertas = run_on_ibm(G, t=1)

La entrada Cómo calcular el Quantum PageRank en el ordenador cuántico de IBM se publicó primero en Natzir Turrado.

Cuando leí el anuncio pensé en la charla que di en septiembre de 2025 en un evento de SISTRIX (la siguiente imagen es una slide de la misma). Allí ya hablaba de la búsqueda agentic como una nueva forma de expandir queries, un paradigma distinto al Query Fan-Out (aunque se nutra de él), y Google por fin se ha atrevido a sacarlo a producción.

Lo ha empaquetado como Search Agents, en vez del Agentic Search con el que la industria lleva tiempo refiriéndose a esto, pero la dirección técnica era evidente para cualquiera que llevara siguiendo la tecnología de los últimos años.

El Query Fan-Out no era nuevo en 2023, los SEOs llevamos lidiando con esto desde los 2000 y el Agentic Search no es una sorpresa en 2026... vamos, es la culminación de 25 años de evolución del Query Augmentation.

Este post es la continuación natural de mi artículo sobre búsqueda híbrida. Si aún no lo has leído, te recomiendo empezar por ahí.

1. ¿Qué es el Query Augmentation y por qué existe?

Un buscador es un sistema con varias capas que trabajan en equipo: una parte busca por palabras exactas, otra interpreta significados, y luego hay varios módulos que deciden qué merece estar arriba. Todo eso lo expliqué en el post de búsqueda híbrida.

Pero antes de que el motor pueda buscar algo, tiene que entender lo que le has pedido. Y aquí está parte de la magia: tu query, tal y como la escribes, casi nunca se usa literalmente. Se reescribe, se expande, se traduce, se generaliza, se especifica. A eso es a lo que se llama Query Augmentation.

La razón es porque el usuario es ambiguo, perezoso e imperfecto. Escribe mal, usa sinónimos, omite contexto, mezcla idiomas. Y el motor necesita transformar esa caja de Pandora en algo que sus índices puedan responder con precisión.

El Query Augmentation es la capa que convierte lo que tú escribes en lo que el motor busca.

Esa capa ha pasado por varias generaciones, cada una corrigiendo las limitaciones de la anterior. Vamos a verlas.

2. La evolución, año a año

2000 - Query Expansion: el corrector ortográfico

Al principio era todo muy literal. Si escribías mal, no encontraba nada. Así que lo primero que metió Google fue corrección ortográfica, stemming/lematización, sinónimos básicos con WordNet y co-ocurrencias. El famoso "¿Querías decir…?".

Hay un ejemplo precioso que Google compartió hace más de una década: una tabla con todas las formas en que la gente escribía mal "Britney Spears". Más de 600 variaciones. Brittany spears, britny, briteny, britney, brytney, brritney… Es divertido verlo ahora, pero ese era el estado del arte, tablas literales con misspellings

Y aquí va una curiosidad que sigo usando años después: el footprint del doble tilde (~~) para desactivar el sistema de sinónimos de Google. ¡Y todavía funciona! En los 2000, añadir un caret (^) activaba el matching de sinónimos. Después Google lo hizo behavior por defecto. Pero si quieres desactivarlo, todavía puedes escribir ~~viajes y verás cómo cambia la SERP. Pruébalo.

• Impacto: encontrabas resultados aunque escribieras mal o usaras otra palabra.
• Limitación: no entendía nada de la intención. Solo igualaba tokens.

2013 - Hummingbird: el primer salto semántico

Hummingbird es cuando Google empieza a jugar en serio con la semántica. Aquí entra el Knowledge Graph y empieza a usarse contexto conversacional. Ya no solo busca palabras, entiende entidades e intenciones.

Si preguntabas "¿quién ganó ayer?", no te devolvía páginas con esas palabras, te devolvía directamente el resultado del partido del equipo que solías seguir, basado en tu contexto anterior.

• Impacto: te entendía aunque no usaras las palabras exactas.
• Limitación: seguía dependiendo de que el concepto estuviera en el Knowledge Graph.

2015 - RankBrain: la entrada del deep learning

RankBrain fue la entrada real de lo neuronal en el ranking. Usando embeddings consigue mapear consultas raras a equivalentes más frecuentes. Si alguien busca "médico del corazón", RankBrain entiende que lo que quiere es un cardiólogo.

Es el momento en que Google empieza a cubrir la long-tail de verdad. Y, técnicamente, es cuando Google se convierte en un sistema híbrido donde junta lo mejor de ambos mundos: la búsqueda léxica (BM25) con una capa densa de significado semántico por encima.

• Impacto: cobertura real de queries nunca vistas.
• Limitación: traduce queries raras a frecuentes, pero no entiende contexto fino.

2018 - Neural Matching: los super-sinónimos

Neural Matching, lo que Google llamó "super-sinónimos". Aquí el buscador ya puede conectar conceptos sin compartir ni una palabra.

Ejemplo: "cómo aliviar el estómago revuelto" lo alinea con documentos que hablan de "náuseas", aunque esa palabra no aparezca en tu query. Esto va más allá de la expansión léxica, es alineamiento de intención a nivel neuronal.

• Impacto: encuentra contenido relevante sin solapamiento de vocabulario.
• Limitación: no es contextual palabra a palabra. Sigue tratando la query como un blob de intención.

2019 - BERT: contexto palabra a palabra

Con BERT el salto es aún más potente porque el buscador ya entiende el contexto palabra a palabra. Entiende preposiciones, negaciones, el orden de las frases.

Antes Google confundía "viajes a Nueva York desde Madrid" con "viajes desde Nueva York a Madrid". Con BERT deja de equivocarse en esas cosas. La desambiguación sintáctico-semántica se hace dentro del propio modelo.

• Impacto: matices, negaciones, preposiciones. Menos malentendidos.
• Limitación: monolingüe en su mayor parte y solo texto.

2021 - MUM: multitarea, multilingüe, multimodal

MUM es un BERT con esteroides: multitarea, multilingüe y multimodal.

Puede usar lo que sabe en un idioma para responder en otro, y combinar texto con imágenes o vídeos. Si preguntas "consejos para subir el Fuji", puede sacar información de guías en japonés o de fotos, aunque tú lo hayas preguntado en español.

Google luego matizó que MUM solo lo usa para featured snippets, Google Lens, topics relacionados de YouTube y poco más. Pero conceptualmente abrió la puerta que el conocimiento ya no esté atado al idioma de la query ni a un documento de texto.

• Impacto: cobertura más allá de idioma y formato.
• Limitación: muy costoso, uso restringido a casos específicos.

2023 - Query Fan-Out: query augmentation en esteroides

Y en 2023 empieza el Query Fan-Out. Aquí el buscador ya no se conforma con tu query tal cual, sino que genera múltiples sub-queries en paralelo: equivalentes, especificaciones, generalizaciones, traducciones, clarificaciones.

Es como si lanzara un abanico de preguntas para asegurarse de cubrir todos los ángulos, y luego selecciona las mejores. Lo explicaré con más detalle en la siguiente sección porque la base de lo que Google acaba de anunciar.

2024 - Agentic Search: el siguiente nivel

Aquí el sistema genera queries, mira resultados, evalúa si le valen, reescribe, vuelve a buscar. Es un bucle iterativo, casi como si tuviera un pequeño investigador dentro que sabe cuándo profundizar más o cuándo cambiar de enfoque. Esto le permite resolver preguntas mucho más complejas, paso a paso.

Cuando di mi charla en septiembre de 2025, ya estaba claro que esto venía. Lo que no sabía era que Google le iba a poner de nombre oficial "Search Agents".

3. Query Fan-Out: el retrieval de los chatbots LLM

En la patente es US20230281193A1 de Google: "Generating query variants using a trained generative model" se describe cómo un sistema con un Variant Engine, un Controller Engine y un Generative Model toma tu query y produce un árbol de variantes.

Las variantes son al menos ocho:

Cada una de esas variantes se lanza en paralelo. Cada una tiene su propio retrieval (léxico + vectorial, fusionado con RRF, como expliqué aquí). Cada una devuelve sus candidatos. Y luego un controlador dinámico (probablemente entrenado con Reinforcement Learning) decide qué variantes han aportado señal útil, cuáles descartar, y si necesita lanzar más.

Es importante entender que el fan-out no es determinista. Si haces la misma query dos veces, no obtienes exactamente las mismas variantes. Eso es lo que rompe la mayoría de las herramientas de "AI visibility tracking" que se venden por ahí, como ya conté en mi artículo sobre prompt trackers.

Y oye, esto es algo que no puedes replicar. La razón es que Google tiene piezas a las que nosotros no tenemos acceso:

• Señales internas: scores, clics y answer quality de cada variante. Sin ese feedback el loop se rompe.
• Controlador con RL: una política que decide cuántas variantes lanzar y cuándo parar, entrenada con recompensas invisibles para nosotros.
• Multitarea: ocho tipos de variantes y un modelo que sabe cuándo aplicar cada una. Podemos copiar el patrón, no la decisión.
• Histórico masivo: millones de queries y clics reales etiquetando implícitamente qué funciona. Ese dataset no existe fuera de Google.
• Selección dinámica de modelo: cambia de modelo según intención, dispositivo o cohorte y nosotros no usaríamos el suyo.
• Recompensas basadas en answer quality: el sistema para cuando la respuesta es suficientemente buena, no por número de variantes. No tenemos esa métrica.
• Personalización: historial, ubicación, contexto reciente y, ahora, Gmail/Photos/Calendar vía Personal Intelligence.

Vamos, imposible de replicar desde fuera, por mucho Dunning-Kruger que lo intente:

Es como querer montar un F1 con piezas de Lego... puedes imitar la forma, pero nunca la velocidad. Pero tampoco importa. Y aquí está el matiz que se les escapa a los GEO Bros porque la respuesta SEO al fan-out no es simularlo o incorporarlo de facto, es darle crear páginas robustas que cubran léxica y semánticamente tanto la query original como sus expansiones. El proceso que los SEOs llevamos haciendo históricamente. Lo expliqué en detalle en el artículo sobre por qué trocear tu contenido es malo para tu SEO y para la IA.

La genealogía del Fan-Out

El Query Fan-Out no aparece de la nada en 2023. Como comenté en la charla,  es la culminación de años de investigación en cómo generar consultas sintéticas:

• doc2query / Document Expansion (2019-2020): generar queries sintéticas desde documentos para entrenar al sistema a recuperarlos.
• Adolphs et al. (2022, ETH/Google): Latent Space Decoding. Decodificar directamente desde el espacio de embeddings. El puente entre doc2query y fan-out.
• HyDE (2022-2023): Hypothetical Document Embeddings. Generar documentos hipotéticos desde una query y usar sus embeddings para buscar.
• WO2024064249A1 (2024): formaliza el Synthetic Query Training, generar queries desde docs para entrenar retrievers offline.

Así que el Fan-Out no surge de la nada, es la culminación de años de investigación en cómo generar consultas sintéticas. Lo nuevo es que ahora no se queda en el training y lo hace en vivo, cada vez que preguntamos.

4. Search Agents: lo que Google acaba de anunciar

Vamos a lo que ha pasado esta semana. Liz Reid lo dijo así en el post de Search I/O 2026:

"We're entering the era of Search agents, where you can easily create, customize and manage multiple AI agents for your many tasks, right in Search."

• Information agents que operan 24/7 en background. Le dejas un brief tipo "avísame cuando salga un piso en Majadahonda con 4 habitaciones por menos de X", y un agente escanea continuamente todo... blogs, news sites, social posts y los datos frescos de finance, shopping y deportes de Google para detectar cambios. Cuando encuentra algo, te manda una notificación con una síntesis y la posibilidad de tomar acción.
• Esto es el bucle iterativo de la búsqueda agentic, pero ahora persistente en el tiempo. La query se convierte en una suscripción a un problema. 
• Agentic booking en categorías nuevas. Locales, servicios, experiencias. "Encuéntrame una sala de karaoke privada para seis personas un viernes por la noche que sirva comida tarde". Google trae precios y disponibilidad y te lanza directo a reservar. Y en categorías como reparaciones del hogar, beauty o pet care, Google puede llamar al negocio en tu nombre. Esto último ya lo probé el año pasado cuando tuve acceso al a beta.
• Generative UI en la respuesta. Google trae a Search por fin la capacidad de Antigravity y de agentic coding de Gemini 3.5 Flash. Digo por fin porque lo anunciaron en noviembre. Ahora la respuesta puede ser una UI generada al vuelo, con visualizaciones, simulaciones, tablas, gráficos. Prompt Tracker gonna hate. Y para tareas continuas como planificar una boda, gestionar una mudanza, Search te construye un dashboard persistente, como una especie de mini-app que vives volviendo a usar.
• Personal Intelligence en 200 países y 98 idiomas. Conectas Gmail, Photos y pronto Calendar, y AI Mode los usa como contexto y sin suscripción. Las IAs conectadas a tools van a personalizar la respuesta tanto que ningún prompt tracker tendrá sentido.

5. Qué significa esto para tu SEO

Bien, ya sabemos cómo ha evolucionado el Query Augmentation desde "did you mean…" hasta agentes 24/7. Ahora te preguntarás: ¿y yo qué hago con esto? LO DE SIEMPRE. 

1. Posicionarte en Google

Este es un estudio que llevo haciendo desde noviembre del 24' y se cumple siempre. La correlación entre el número de citaciones y estar posicionado en el top-3 de Google es altísima. No solo hay correlación de Spearman, si no también de Pearson, o lo que es lo mismo, que hay correlación lineal y de magnitud.

2. Ser accesible

Estar en Google y ser fuente de grounding no basta si el bot no entra. Puedes estar en el top 1, formar parte del grounding interno del modelo, ser citado como fuente, y aun así desaparecer en la respuesta visible. Si el bot no puede entrar a evaluar tu contenido, todo lo anterior se cae.

He observado que una de la causas más frecuentes de ghost citation es por motivos técnicos. A veces no es un problema de marca o de tu contenido. Es un problema de que la IA no puede leerte cuando va a buscarte.

Dos formas habituales de romper este último eslabón es bloqueos del WAF y cuando tu contenido se renderiza con JavaScript y el bot solo ve el shell.

3. Trabajar la entidad

Los LLMs no potencian a las marcas por casualidad. Se entrenan con el corpus del conocimiento humano.

La razón es que los modelos de IA trabajan en lo que llaman monosemanticidad. Hay “neuronas” que se activan cuando el modelo detecta un concepto muy concreto, por ejemplo, “dirección de correo electrónico” o “nombres de ciudades.” La idea la explica un estudio reciente de Anthropic y se asemeja de nuevo al viejo concepto SEO semántico de “entidades” y “desambiguación”.

A su vez, los modelos almacenan “hechos” en sus capas internas. Típico ejemplo: Michael Jordan → Basketball. Esa asociación se graba en la red,  específicamente en los multi-layer perceptrons (MLPs).

El SEO lleva toda la vida trabajando entidades... ¡y menciones! ¿Cómo se construye una entidad? Lo resumo aquí:

• Mediante owned content: tu contenido tiene que ser claro, valioso, con autoría y datos que cubran el árbol de variantes posibles. Y creo que la autoridad temática se vuelve más importante y más decisiva por funcionamiento del RRF.
• Mediante earned content: que terceros te citen en contextos de recomendación. Esto es lo que mueve el prior del modelo.
• Mediante una capa técnica: Explicar claramente lo que haces, ser coherente con las señales y ayudar a nutrir el KG de Google.

Siempre digo que las marcas son atajos mentales que nos reducen el tiempo y la molestia de buscar. Los LLM han heredado ese sesgo.

 4. Los Search Agents SOLO cambian el modelo de visita

Si un agente está monitorizando 24/7 para un usuario entonces ya no estás compitiendo por que el usuario haga clic ahora. Estás compitiendo por que el agente te elija como fuente de monitorización fiable y constante. Entiendo que esto premiará la frescura, fiabilidad y machine-readability de tu contenido a lo largo del tiempo, es lo que decidirá si cambiará de fuente o use la misma. Como decía antes, ahora las personas se "suscribirán" a una query.

La entrada La evolución del Query Augmentation: Del Query Expansion al Agentic Search se publicó primero en Natzir Turrado.

Grounding QueryPage Mapping dentro del AI Performance report de su Webmaster Tools,

• Citations: cuántas veces tu contenido es referenciado por AI systems.
• Grounding queries: Son las queries que el AI utilizó internamente para hacer retrieval, no necesariamente lo que el usuario escribió. El AI reescribe, expande y normaliza la consulta antes de buscar.

El problema es que si quieres sacar las grounding queries de cada página, o al revés, tienes que ir de una en una y en los exports esta info no está mapeada. Y para sitios con cientos de queries y miles de páginas, eso es inservible.

En su día me construí un workaround haciendo el matching por similitud semántica, pero no es lo mismo.

He construido un bookmarklet que extrae todo el mapping y lo descarga como 3 CSVs listos para Excel o Sheets. Se ejecuta en tu navegador con tu sesión, sin enviar datos a ningún servidor externo. Si la cuenta se topa con el rate-limit de Bing, espera y reintenta sola, así que no te preocupes, hay que tener paciencia. Puedes dejar la pestaña abierta y sigue haciendo tus cosas en otra.

Instalación del bookmarklet

Arrastra este botón a tu barra de favoritos:

Bing AI Performance Exporter

Arrastra el botón a la barra de favoritos. Si haces click aquí no hace nada (los bookmarklets solo funcionan sobre la página objetivo).

Si tu barra de favoritos no se ve, actívala con Cmd+Shift+B (Mac) o Ctrl+Shift+B (Windows).

Cómo usarlo

1. Entra en Bing Webmaster Tools y abre el report de AI Performance de la propiedad que quieras analizar.
2. Elige el rango temporal: 7 días, 30 días, 3 meses o Custom. El bookmarklet detecta automáticamente cuál tienes activo.
3. Haz click en el bookmark de la barra de favoritos.
4. Verás un panel con spinner y progreso en vivo. Cuando termine, te ofrece 3 CSVs.
5. Si Bing te rate-limita en mitad del proceso, el bookmarklet espera 5 min y reintenta solo. No tienes que hacer nada.

Tiempos esperados:

Qué hace si Bing te rate-limita

Cuando Bing detecta demasiadas peticiones, el bookmarklet:

1. Muestra "Bing throttled. Auto-resuming in 5m 0s. Keep this tab open."
2. Espera exactamente 5 minutos.
3. Hace un probe ligero al API.
4. Si el API responde OK, continúa desde donde se quedó.
5. Si sigue throttled, espera otros 5 minutos y vuelve a probar. Repite hasta 12 ciclos (1 hora máxima de espera).

Todo lo que llevas mapeado queda guardado en localStorage del navegador. Si por lo que sea cierras la pestaña o recargas, al volver a clicar el bookmark hace resume automático con lo que llevabas. Nunca pierdes la data

Lo único que tienes que hacer es no recargar la pestaña mientras está esperando. Si recargas y Bing está fuerte con el rate-limit, puede que veas una página con un mensaje JSON de "too many requests": eso es normal... recargas en 10 min y la web vuelve y puedes seguir con el proceso, pero mejor no hacerlo.

Qué obtienes

Tres CSVs con prefijo bing-aip_<dominio>_<fecha>_:

mapping.csv

El mapping completo en formato largo. Una fila por combinación query+URL con sus citations. Sirve tanto para pivot "queries por página" como "páginas por query" en Excel o Sheets sin tener que hacer joins.

queries-summary.csv

Una fila por query: total de citations y cuántas páginas tiene mapeadas.

pages-summary.csv

Una fila por página con citations totales, mapeadas, sin mapear y número de queries asociadas. Esta es la tabla más interesante porque expone el sample-bias de Bing en la columna unmapped_citations: páginas con citations totales pero sin queries identificadas en el mapping (la API no las expone).

El sampling de Bing

La propia UI de Bing avisa que no es toda la data, es un sampling de la misma, o lo que es lo mismo, qu el mapping querypage que Bing expone es parcial.  Para cada URL puedes ver el total de citations que tiene asociadas (cuántas veces fue referenciada por AI systems en total), pero solo una parte de esas citations Bing puede atribuirlas a una grounding query concreta vía el sample. El resto queda como "citations sin query identificada". A esta porción con query asociada la llamo citations mapeadas.

He probado en 6 sitios con perfiles muy distintos:

Conclusiones del cruce de cobertura:

• El coverage va del 24% al 97% según el sitio. No hay patrón evidente de "más/menos volumen = mejor coverage": el sitio E (1.8M citations) tiene 46% mientras el sitio F (9.6M) tiene 97%. El comportamiento es parece errático, pero luego comparto algunas hipótesis en hallazgos.
• El % de páginas que tienen alguna query mapeada es aún más bajo: típicamente entre 10% y 25% en sitios medianos/grandes. La mayoría de URLs citadas no tienen ninguna query asociada en el sample.
• Para sitios pequeños (menos de 200 citations totales) el dato es prácticamente inservible. Solo se mapean las queries top.

El CSV pages-summary.csv te da esa información explícita en la columna unmapped_citations. Si una URL tiene 28 citations pero 0 queries mapeadas, esa página tiene tráfico generativo "fantasma" que Bing no te enseña de dónde viene.

¿Las grounding queries corresponden a demanda real de búsqueda?

Una pregunta que siempre he querido responder es si ¿esas queries existen como búsqueda real, o el AI grounding está generando unas queries que un humano no busca?

Para responderlo crucé los datos de grounding con dos fuentes:

• Bing Webmaster Tools API: clicks e impressions de búsqueda en Bing por query, mismo rango temporal. La API capa a 6.700 records por llamada agregada, así que para sitios con miles de queries hay que hacer lookup query-por-query con GetQueryPageStats(query), una llamada por cada grounding query.
• Google Search Console: impressions por query del mismo período, exportado a CSV.

¿Qué % de queries de grounding puedo encontrar en mi Search Console o Webmaster Tools? ¿Y cuántas son únicas del grounding, invisibles en mis informes habituales?

Para cada query que aparece en el reporte de grounding, miro si esa misma query también recibe impressions en Google Search Console (búsqueda normal de Google) y en Bing Webmaster Tools (búsqueda normal de Bing):

% de queries recuperables (con presencia en al menos un buscador): A 67%, B 93%, C 67%, D 75%, E 76%, F 82%. Mediana ~76%. Entre el 7% y el 33% de las queries que disparan grounding no se ven ni en Bing ni en Google.

Por peso de citations el cuadro cambia

La tabla anterior cuenta queries (cada una vale 1). Si ponderamos por citations (cuánto pesa cada query en el total de referencias de tu URL en respuestas AI), las queries "solo grounding" se reducen porque suelen ser cola larga con pocas citations cada una:

Hallazgos observados

1. La cola larga de grounding es invisible para los analytics normales. Por número de queries, entre el 7% y el 33% de lo que dispara citations AI no aparece en Bing search ni en GSC. Si tu plan era "auditar las queries AI mirando solo Bing Webmaster Tools normal y Search Console", te estás perdiendo entre un séptimo y un tercio del fenómeno.
2. Pero esas queries invisibles pesan poco en citations. La misma cola larga aglutina muchas queries con pocas citations cada una. Por eso, ponderando por citations, "solo grounding" baja al 1%-26%. Dependiendo de qué quieras medir (descubrir queries nuevas vs entender qué impulsa tu volumen AI), una métrica u otra cuenta.
3. Google captura más intent de grounding que Bing search. En todos los sitios medianos/grandes, "solo Google" añade entre 34% y 63% de queries (por count) mientras "solo Bing" se queda en 0.9%-4.4%. Bing search tiene poca cuota en español, pero Bing AI/Copilot sirve un público global que sí ve sus citations, creo que este puede ser ele motivo principal de discrepancia.
4. Google captura más intent de grounding que Bing search. En todos los sitios medianos/grandes, "solo Google" añade entre 42% y 66% de queries (por count) mientras "solo Bing" se queda en 1.1%-4.4%. Bing search tiene poca cuota en España, pero el grounding de Microsoft alimenta a múltiples AI systems globales y captura intent que su buscador propio no. 
5.  Hay dos casos donde "solo Bing" pesa fuerte en citations: sitios E (10.1%) y C (11.8%). No me arriesgo a explicar por qué. Posibles factores: audiencias más afines a Microsoft (Edge users), mercados internacionales que el GSC del usuario no recoge bien, o queries que el AI reescribe internamente y resultan más cerca del índice de Bing que del de Google. En esos sitios sé que son productos con tirón fuera de España y que son buscados en español en mercados del otro lado del charco. Lo dejo como observación, no como conclusión.

El bucket "solo grounding" tiene queries raras de varias clases

Nota: las queries de los ejemplos son inventadas para no exponer datos de cliente, pero los patrones son fieles a lo que aparece en los logs reales.

Cuando filtras las queries que SOLO aparecen en grounding (no en Bing search ni en Google), las clases que veo:

• Truncadas o fragmentadas. Bing expone grounding queries cortadas como si fueran completas: zapatillas running mujer talla pequeñ, zapatillas running mujer tal, zapatillas running muje. No se si es que usa las del user que ha dado enter sin completar o ha usado algón autocompeltado.
• Brand-augmented por prior del modelo. El usuario probablemente preguntó "mejor robot aspirador para pelo de mascotas", pero la query que Bing reporta como source es roomba pelo mascotas opiniones, xiaomi robot aspirador mascotas, cecotec conga pelo perro. El modelo añade marcas conocidas del vertical (que él asume) y eso queda en el log como si fuera la query original. Aparecen citaciones a tu sitio aunque el user nunca tecleó la marca competidora.
• Multi-idioma cuando el sitio sirve multi-mercado. En sitios globales aparecen queries en idiomas que el GSC del mercado local no recoge: how to descale a coffee machine en inglés, como limpar máquina de café en portugués, come decalcificare macchina caffè en italiano. Ya se sabe que el grounding lo puede hacer la IA en otro idioma para expandir el corpus.
• Variaciones regionales muy específicas. Por ejemplo en servicios profesionales: abogado herencias internacionales la rioja / melilla / ceuta / teruel. Long-tail informacional pero haciendo una expansión con poco sentido.

Esto explicaría el motivo de que no existan en Google, son cosas que ningún usuario buscaría y exclusivo del funcionamiento del fan-out.

¿Y a nivel URL? ¿Hay URLs citadas por AI que Google o Bing orgánico no sirve?

Misma idea pero ponderando por URL citada. Para que el cruce sea correcto hay que crawlear cada URL grounding, seguir redirects 301 y canonicals, status final, y comparar el destino final contra GSC. La URL exacta no vale ya AI memoriza slugs viejos y cita variantes con canonical, noindex, 404...

Como vemos quedan algunas urls AI-only pero en mi caso el motivo es puramente técnico. No tengo acceso a la data completa de BigQuery y/o no tengo varias propiedades de Search Console para evitar el sampling. Tampoco tengo acceso de más de 3 meses a los logs.

Aun así, tras filtrar artefactos técnicos, sampling, equivalencias cross-language y presencia en Bing, el AI-only verdadero (URLs invisibles en Google y Bing simultáneamente) queda en 0.004%-0.9% de las citations. El gap entre AI y motores de búsqueda es residual y la mayor parte de lo que parecía "descubrimiento" eran legacy URLs, páginas borradas, duplicados con canonical, datos suprimidos por el muestreo y variantes de idioma de páginas que Google sí indexa en otra locale.

Privacidad

• El script se ejecuta en tu navegador, sobre la página de BWT, con tus cookies de sesión.
• No envía nada a ningún servidor externo.
• No usa analytics.
• Los datos parciales se guardan en localStorage del propio Bing, solo para hacer resume tras un rate-limit. Caduca a las 24h.
• El código fuente es legible y minificado. Puedes auditarlo antes de instalarlo.

Cómo funciona por dentro

Bing usa internamente dos endpoints REST que ya están autenticados por tu sesión:

• POST /webmasters/api/aiperformance/searchqueries/stats devuelve queries
• POST /webmasters/api/aiperformance/pages/stats devuelve páginas

El bookmarklet:

1. Pide el CSRF token a /webmasters/auth/token.
2. Lista todas las queries y todas las pages (paginado).
3. Para cada query, llama a pages/stats con Query: X y guarda las páginas citadas con su número de citations.
4. Aplica cooldown preemptivo cada 150 queries (45 segundos) para no agotar la cuota de rate-limit.
5. Si llega un 429 o un body con "too many requests", pausa 5 minutos, hace probe del API, reintenta. Loop hasta resolver o llegar al límite de 1 hora.
6. El pages-summary se deriva del mapping anterior: unmapped_citations = total - mapped.
7. Genera 3 CSVs en memoria y los ofrece como descargas.

Cuando Bing devuelve 404 NoDataFound significa "esa página/query no tiene mapping en el sample", no es un error.

Nota técnica: es redundante sacar la data al revés page -> query, es la misma y de esta forma se tarda menos.

Solución de problemas

"Open this on the AI Performance page" error. Has ejecutado el bookmarklet desde otra página. El propio mensaje te da un link directo al report del sitio que tenías abierto.

Solo se descarga 1 CSV. Chrome a veces bloquea descargas múltiples. Permite el aviso que aparece en la barra de direcciones, o usa los botones individuales del panel.

"403 / 401" o errores en auth/token. Tu sesión de Bing ha expirado. Recarga la página y vuelve a ejecutar el bookmarklet.

Veo "Bing throttled. Auto-resuming in 5m 0s". Tranquilo, es normal. No recargues. Deja la pestaña abierta y vuelve en 5-10 min. El bookmarklet sigue solo desde donde estaba.

Próximos pasos

• Cease and Desist de Microsoft

Si lo usas y te ayuda, cuéntamelo. Si te explota algo, también.

La entrada AI Performance: Cómo exportar el mapping completo de queries y páginas citadas de Bing Webmaster Tools (bookmarklet) se publicó primero en Natzir Turrado.

Alto · Medio · Bajo · Nulo

1. Crawlers de training y search/RAG

Bots que indexan tu sitio, no ejecutan JS y solo son visibles en server logs. Una nota importante, AIO y AI Mode no hacen fetch en tiempo real tras una consulta, sino que tiran del índice de Google ya cacheado por Googlebot, así que no verás un hit en logs correlacionado con una búsqueda concreta ni puedes forzar un fetch en una conversación con AI Mode.

Servicio	Nivel	Huella
Google Search / AIO / AI Mode		UA Googlebot + JSON oficial + rDNS *.googlebot.com. El mismo crawler alimenta Search e índice para AIO/AI Mode
Google Gemini training + grounding		Google-Extended no es un UA, solo token de robots.txt. El crawling lo hace con UAs Googlebot existentes
OpenAI training + search		UAs GPTBot, OAI-SearchBot + JSON oficial de IPs
Anthropic training + search		UAs ClaudeBot, Claude-SearchBot. Sin JSON oficial de IPs
Perplexity (indexación declarada)		UA PerplexityBot. Cloudflare lo deslistó de Verified Bots (ago 2025)
Apple training		UA Applebot. Verificación estable
Amazon training		UA Amazonbot. Verificación estable
Meta training		UA Meta-ExternalAgent. Verificación estable
Common Crawl		UA CCBot. Verificación estable. Dataset abierto usado por múltiples modelos
ByteDance training		UA Bytespider, pero ignora robots.txt sistemáticamente y hay reportes de spoofing. Volúmenes agresivos (1.4M hits/día reportados). Requiere bloqueo a nivel server/CDN
Perplexity stealth crawler		UA Chrome 124 falsificado cuando se bloquea el oficial
xAI Grok crawler		UA falsificado sistemáticamente, "impossible to block" según Cloudflare

2. Fetchers on-demand (disparados por usuario o grounding)

Se disparan cuando un humano pide algo o cuando un LLM hace grounding/web search en vivo. Aquí sí verás hits en logs correlacionados con consultas concretas, a diferencia de AIO/AI Mode.

Servicio	Nivel	Huella
ChatGPT (browsing + agent fetch)		UAs ChatGPT-User, ChatGPT Agent + JSON oficial + Web Bot Auth (HTTP Message Signatures) desde ago 2025
Vertex AI Agents		UA Google-CloudVertexBot
Gemini grounding / URL Context tool		Sin UA específico documentado. El fetch lo hace la infra Google y se observa como UA escueto Google
Claude (fetch para grounding)		UA Claude-User. Sin JSON oficial
Perplexity (fetch para grounding)		UA Perplexity-User. Mismo paquete deslistado por Cloudflare
Amazon (fetch on-demand)		UA Amzn-User
Mistral (fetch on-demand)		UA MistralAI-User

3. Clicks humanos desde citas en chatbots

Cómo se ve un click humano que llega desde una cita en un chatbot, tanto en server logs como en tu herramienta de analytics.

Origen	Nivel	Huella
Perplexity web		perplexity.ai / referral, Referer consistente
ChatGPT web, citation links (todos los planes)		utm_source=chatgpt.com desde jun 2025
ChatGPT web, inline links (Plus / Pro / Team)		Referer preservado, aparece como chatgpt.com / referral
Copilot (copilot.microsoft.com)		copilot.microsoft.com / referral
Gemini web (gemini.google.com)		gemini.google.com / referral
Claude web		Path con fecha claude.ai/referral/YYYY-MM-DD, requiere regex para agrupar
Gemini app iOS		UA GeminiiOS/x.x.x con GoogleWv/1.0 (WKWebView) identificable en logs. Referer stripped, cae en Direct en GA4. Descubierto por mí en logs (oct 2025).
Gemini, UA Google genérico (resto de superficies)		Gemini usa UA escueto Google para gran parte de su tráfico, sin documentación oficial. Imposible distinguir origen (app, web, grounding, etc.)
Apps móviles ChatGPT, Claude, Perplexity		Comportamiento no documentado oficialmente por los proveedores. Reportado consistentemente por la industria, los clicks desde apps móviles strippean Referer y la mayoría no llevan UTM. Estimaciones de 20-40% del tráfico IA mal atribuido a Direct por este motivo
ChatGPT web, inline links (plan Free)		Referer stripped, cae en Direct
Gemini app Android		Sin UA propio documentado. Cae bajo Google genérico o Direct

4. Experiencias generativas integradas en SERP

AIO y AI Mode dentro de google.com, Copilot Search dentro de bing.com. Mezcladas con orgánico clásico en GA4 en ambos casos. Bing es bastante más transparente que Google en su panel para webmasters.

Origen	Nivel	Huella
AI Overviews (Google)		Clicks e impresiones incluidos en totales de Search Console, pero sin filtro para aislarlos (google / organic en GA4)
AI Mode (Google)		Clicks e impresiones agregados al "Web" search type de Search Console desde 17 jun 2025, sin filtro dedicado
Copilot Search + Bing AI summaries		Mezclado con bing / organic en GA4, pero el AI Performance report de Bing Webmaster Tools (feb 2026) sí muestra citations, grounding queries, páginas citadas y mapping querypágina. Solo visibilidad de citation, no clicks al sitio. Pero, en Microsoft Clarity tenemos además share of authority y AI referral traffic.

5. Navegadores agénticos

Browsers Chromium pilotados por LLM. Visibles en GA4 como humanos. UA Chrome estándar, ninguno tiene UA propio dedicado salvo Google-Agent. La única señal fiable cuando ejecutan tareas agénticas es Web Bot Auth, si la firman.

Browser / Agent	Nivel	Huella
Google-Agent (Gemini Agent + Chrome Auto-Browse)		UA propio con string compatible; Google-Agent + JSON oficial (user-triggered-agents.json) + Web Bot Auth (identidad agent.bot.goog) desde mar 2026. Heredó de Project Mariner (cerrado 4 may 2026). Único agente con UA propio
ChatGPT Atlas (modo agent)		Sin UA propio, pero firma con Web Bot Auth cuando opera en modo agent (registrado como signed agent chatgpt-agent en Cloudflare). Navegación humana normal indistinguible
Perplexity Comet		Sin UA propio. Algunas peticiones del asistente incluyen "Perplexity" en UA. Sin Web Bot Auth documentado
Claude for Chrome (extensión)		UA Chrome del usuario, indistinguible. Sin Web Bot Auth
Dia (The Browser Company)		UA Chromium estándar, indistinguible. Sin Web Bot Auth

Conclusiones

Citas con clicks en chatbots desde desktop

Es el tramo más limpio. Perplexity pasa Referer consistente, ChatGPT incluye utm_source=chatgpt.com en las citation links de todos los planes desde junio 2025, Copilot y Gemini web pasan Referer estándar, y Claude requiere agrupar paths por fecha con regex pero se hace. Adobe Analytics lanzó la dimensión "Conversational AI tools" en agosto de 2025, Amplitude también identifica LLMs en sus default channel rules, y GA4 sacó su canal nativo "AI Assistant" el 13 de mayo de 2026. En Plausible, Matomo o cualquier sistema con reglas de canal personalizadas puedes montártelo manualmente.

Citas con clicks en chatbots desde móvil

Android cae en Direct casi sin excepciones e iOS solo deja huella en logs vía GeminiiOS (UA descubierto por mi). Las apps de ChatGPT, Claude y Perplexity strippean Referer y no llevan UTM, con estimaciones de industria del 20-40% del tráfico IA misatribuido a Direct por este motivo, y los canales nativos de las herramientas de analytics no resuelven esto.

Cubren los grandes proveedores con referrer detectable (ChatGPT, Gemini, Claude, en algunos casos Perplexity y Copilot) pero no lo que llega sin referrer ni UTM, que es exactamente donde está el agujero del móvil. Si solo miras a estos canales, el tráfico de las apps móviles te queda fuera.

Citas sin clicks

El último problema, y el más difícil de resolver, son las citaciones sin click, esto es, la marca mencionada en respuestas IA sin que el usuario clique. Más allá del impacto en CTR orgánico, suficientemente documentado, el dato relevante es el click dentro del propio AIO. Pew Research midió un 1% en julio de 2025, lo que significa que aunque tu marca aparezca citada en el AIO, solo un usuario de cada cien clica la fuente y el resto se queda en Google o cierra la pestaña.

Search Console agrega clicks e impresiones de AIO y AI Mode al total sin filtro para aislarlos, y las impresiones entre mayo 2025 y abril 2026 estuvieron infladas por un bug que Google reconoció oficialmente.

Bing va por delante de Google en transparencia ya que el AI Performance report en Bing Webmaster Tools, lanzado en febrero 2026, muestra citations, grounding queries, páginas citadas y desde marzo el mapping querypágina. Lo único que no da son clicks al sitio, solo visibilidad de citation. Fuera de la SERP el problema se repite en los chatbots.

Los prompt trackers rotan unos pocos prompts predefinidos sobre LLMs no deterministas que cambian de respuesta hora a hora. Dan la punta, de la punta, del iceberg. Los de escala masiva como Sistrix o Ahrefs, dan un poquito más. El volumen de menciones que recibe una marca en las conversaciones de millones de usuarios no se puede observar, y no parece que vaya a cambiar a corto plazo porque las APIs de los LLMs no exponen esos datos.

Agentes navegando

Los agentic browsers tipo Atlas, Comet, Claude for Chrome o Dia se ven en GA4 como humanos normales porque, técnicamente, lo son, con UA Chrome estándar, cookies y navegación humana. Aquí demostré que no eran identificados como bots y ejecutaban Google Analytics.

Ninguno tiene un UA dedicado propio, lo cual es un problema para el tráfico agéntico. La excepción es Google, que con Google-Agent, el UA lanzado el 20 de marzo de 2026 para Project Mariner y heredado por Gemini Agent y Chrome Auto-Browse tras el cierre de Mariner el 4 de mayo de 2026, es el único agente navegacional mainstream que se identifica explícitamente en logs. Tiene su propio fichero de IPs (user-triggered-agents.json) y está experimentando con Web Bot Auth, el estándar IETF de firma criptográfica. ChatGPT Atlas también firma con Web Bot Auth cuando entra en modo agent pero sin UA propio, mientras que Comet, Claude for Chrome y Dia son indistinguibles.

Web Bot Auth es hoy la única señal fiable para distinguir un agente legítimo de un spoofer, dado que el UA es trivial de falsificar y la firma criptográfica requiere acceso a la clave privada del agente.

Qué fuente sirve para qué

La medición de visibilidad en LLMs sale de combinar varias fuentes parciales ya que cada fuente cubre una parte distinta del problema:

• Server logs (cruzados con datos de CDN o WAF): identificación de crawlers, fetchers y agentes con UA propio. Te dice quién entra a leer y con qué frecuencia (bots o users).
• Herramientas de analytics (Adobe Analytics, GA4, Amplitude, Plausible, Matomo, Piwik PRO o la que uses): clicks humanos desde citas en chatbot web, con sus canales nativos o personalizados. Con esto mides sesiones, conversiones y revenue generado por tráfico IA. Asume que aquí no está todo, un porcentaje considerable es Direct.
• Search Console: agrega AIO y AI Mode al total pero no los separa. Puedes inferir algún prompt mediante RegEx, no es fiable.
• Bing Webmaster Tools (AI Performance report): única fuente que muestra citations dentro de Copilot y Bing AI summaries, con grounding queries y páginas citadas. Te da visibilidad de citation, no de los clicks. Aquí te enseño a descargarte toda la data sin ir página a página.
• Microsoft Clarity (Citations dashboard): grounding queries, cited pages y share of authority dentro de Copilot y experiencias AI de partners de Microsoft, más AI referral traffic medido desde el propio script de Clarity. Como lo que hay en BWT en la parte de citations pero añade la sesión y el share of authority como KPI
• Prompt trackers: aproximación ínfima de las citations en LLMs. Para mi son el negocio de la certidumbre prefabricada.

La entrada Estado de medibilidad del tráfico IA se publicó primero en Natzir Turrado.

Por eso un mercado donde la señal técnica es débil, como ya documenté con detalle aquí, factura cientos de millones al año con márgenes brutos del 85 al 95% según los datos que recogí en aquel análisis a partir de los pricings públicos de las tools y estimaciones de costes operativos.

El cerebro humano y la incertidumbre

La aversión a la ambigüedad lleva estudiándose en economía y psicología desde la paradoja que formuló Daniel Ellsberg en 1961. Su experimento, basado en apuestas sobre urnas con distinto grado de información sobre su contenido, mostraba que la gente prefiere apostar por opciones cuya probabilidad conoce frente a opciones cuya probabilidad es desconocida, aunque matemáticamente sean equivalentes. Una cosa es la aversión al riesgo (saber que hay un 30% de probabilidades de algo) y otra distinta es la aversión a la ambigüedad (no saber siquiera cuáles son esas probabilidades). El cerebro trata ambas situaciones de manera distinta y prefiere sistemáticamente la primera, según recoge la revisión de Marciano Siniscalchi sobre ambigüedad y aversión a la ambigüedad.

Eso sí, con matices. Heath y Tversky propusieron en 1991 la hipótesis de competencia, que muestra que cuando una persona se siente experta en un dominio, el patrón se invierte y empieza a buscar ambigüedad en lugar de evitarla. Esto importa porque el comprador de martech no se ve como un sujeto neutral metido en una urna abstracta, se ve como experto en lo suyo. La aversión a la ambigüedad actúa en él de forma menos directa de lo que sugeriría Ellsberg. Aun así, en el momento de comprar una tool cuya metodología no entiende del todo, vuelve a estar fuera de su zona de competencia, y el sesgo reaparece.

Un estudio publicado en PMC en 2020 sobre intervenciones para reducir la aversión a la ambigüedad encontró que después de enseñarle a la gente la paradoja y mostrarle por qué su elección era subóptima, la aversión bajaba pero no desaparecía (y además producía un efecto colateral de reducir la aversión al riesgo en otros contextos no relacionados).

Junto a esto opera la ilusión de control que describió Ellen Langer en los años 70, que es esa tendencia a creer que controlamos cosas que en realidad están dominadas por el azar. Una revisión publicada en Analytical Chemistry sobre sesgos en el juicio experto añade que cuando los expertos creen que pueden superar sus sesgos por fuerza de voluntad, el intento puede acabar haciéndolos más fuertes. Lo único que sí parece reducir la ilusión de control es tener perfiles distintos en el equipo que decide, según un estudio experimental de Meissner y Wulf publicado en European Management Journal en 2017.

El efecto farola y la falacia de McNamara

Seguro que conoces esta historia del efecto farola. Un policía encuentra a un borracho buscando algo bajo una farola por la noche. Le pregunta qué busca. Sus llaves. ¿Las perdió ahí? No, las perdí allí, en aquel parque oscuro. ¿Y por qué busca aquí entonces? Porque aquí hay luz.

Columbia Business School publicó un análisis del profesor Oded Netzer sobre por qué, a pesar de inversiones crecientes en marketing analytics, la contribución medida de esa analítica al rendimiento corporativo seguía siendo baja. La explicación que ofrecen los autores es que las empresas miden lo que es fácil de medir y lo que de verdad cuenta suele quedar fuera del foco.

Esto ha evolucionado en nuestro sector como la falacia de McNamara, formalizada por el sociólogo Daniel Yankelovich. Tiene cuatro pasos según el resumen de Sketchplanations.

1. Medir lo que es fácil de medir.
2. Descartar lo que no se puede medir.
3. Asumir que lo que no se puede medir no es importante.
4. Concluir que lo que no se puede medir no existe.

McNamara aplicó esa lógica en Vietnam usando el body count como métrica principal. Big Think tiene un artículo divulgativo sobre cómo este patrón aparece hoy en decisiones cotidianas.

Goodhart y los KPIs que dejan de medir

A esto creo que hay que sumarle un tercer mecanismo, la ley de Goodhart, formulada por el economista británico Charles Goodhart en 1975 y popularizada por la antropóloga Marilyn Strathern. Dice que cuando una medida se convierte en objetivo, deja de ser una buena medida. La entrada de Wikipedia sobre la ley recoge la cita exacta de Goodhart, "any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes".

Existe una anécdota que se cita en muchos libros como ejemplo, la del programa colonial británico en Delhi que ofreció una recompensa por cobras muertas y acabó incentivando que la gente criara cobras para cobrarla. Posiblemente es una anécdota es inventada, nunca lo sabremos.

En marketing pasa lo mismo. Si el equipo se evalúa por número de leads, se generan leads que no convierten. Si el SEO se evalúa por keywords en top 10, se persiguen keywords sin volumen ni intención comercial. Si el email marketing se evalúa por open rate, las líneas de asunto se vuelven clickbait.

KPI Tree tiene una guía sobre Goodhart y el diseño de métricas donde argumenta que el problema se agrava cuando las métricas se aíslan. Una métrica conectada a sus parents y childs en un árbol crea una red de relaciones donde manipular un nodo produce distorsiones visibles en los nodos vecinos. Una métrica aislada no tiene esa protección. La industria de prompt tracking lo sabe, por eso casi todas las tools venden un score único en una gráfica que sube y baja en vez de un sistema con guardrails.

El argumento más fuerte a favor de los prompt trackers

Para ser justos, toca hacer el ejercicio inverso, porque el caso a favor de medir visibilidad en LLMs no es trivial y descartarlo no sería honesto por mi parte. El argumento más sólido tiene tres componentes.

1. El primero es la diferencia entre valor direccional y valor absoluto. Aunque un visibility score de 42 no signifique nada en términos absolutos, una caída del 40% mes a mes puede señalar un cambio real en cómo el modelo está representando la marca, sobre todo si la metodología de la herramienta se mantiene constante. Hay un montón de sistemas con mucho azar que se miden todo el rato (meteorología, mercados financieros, encuestas). Que los LLMs no sean deterministas no significa que no se puedan medir. Significa que hay que hacer muchas más repeticiones de las que la mayoría de tools hacen y no confundir señal con ruido en muestras pequeñas. Pero esto a tu prompt tracker favorito no lo sabe o si lo sabe no lo hace bien porque perdería sus márgenes. Felipe Concha, fundador de Bison, ingeniero civil y PhD en IA me dijo lo siguiente a través de LinkedIn (he pedido permiso para hacerlo público), después de leerse mi artículos sobre el prompt tracking:
2. El segundo es el uso como sistema de alarma. Hay clientes y consultores que compran trackers sabiendo sus limitaciones, y los usan como tripwire para detectar cambios bruscos. Una tool que detecta que tu marca ha desaparecido del 80% de los prompts donde antes aparecía tiene valor diagnóstico aunque el score absoluto sea ruidoso. Pero hay que hacerlo bien porque si no es muy fácil de manipular.
3. El tercero es la mental availability. Si lo que cuenta para el crecimiento de marca es estar presente en la mente del consumidor en el momento de compra, y los LLMs están sustituyendo cada vez más a la búsqueda, entonces estar presente en las respuestas de los LLMs sí afecta a esa disponibilidad mental.

Pero ¿dónde se rompe? Yo lo veo en otros tres puntos.

1. El valor direccional solo se sostiene si la metodología se mantiene constante, y las tools cambian modelos, prompts y APIs constantemente. Eso rompe la base sobre la que estás comparando. Yo he trakeado los mismos prompts en 3 tools distintas y los trends no eran consistentes.
2. El uso como sistema de alarma solo funciona si el comprador sabe ignorar los scores absolutos y mirar solo cambios bruscos. Pero la mayoría del mercado no compra así, porque estas tools se venden prometiendo justo lo contrario, medición precisa de tu visibilidad y el que puedas hacer algo accionable con esa información.
3. ¿Las herramientas actuales miden mental availability o miden algo mucho más estrecho, como presencia en N prompts sintéticos sin contexto de usuario real? Que la mental availability cuenta nadie lo discute. La crítica es a cómo se está midiendo y a cómo se vende lo medido.

El SaaS martech está diseñado para vender certidumbre

MarTech publicó en febrero de 2026 un análisis de por qué las empresas malgastan 2 millones de dólares en herramientas mal compradas. Las causas que identificaron son: compras impulsadas por FOMO, decisiones siladas, y demos diseñadas para que la urgencia supere a la claridad operacional. Una guía sobre la psicología de venta de SaaS describe cómo se usan promociones limitadas, accesos beta y mensajes de "los líderes ya están ahí" para activar el FOMO en compradores corporativos.

Quiero pensar que estos mercados no se sostienen porque el comprador sea irracional. Se sostienen porque el comprador saca algo real de la compra (defensa ante el board, narrativa para el cliente, menos ansiedad) aunque la señal técnica sea débil. Funciona así porque el mercado opera dentro de sus límites. La crítica es que esa utilidad subjetiva tiene un gasto escondido, que es el de la mala asignación de presupuesto.

A esto se suma un incentivo que oigo mucho internamente. En muchas empresas el bonus anual depende de haber lanzado iniciativas de IA, incluida la contratación de tools, para mejorar eficiencia y procesos. El comprador también está presionado desde arriba, y una tool de prompt tracking marca esa casilla rápido.

El funnel como historia que nos contamos

El funnel lineal awareness-consideration-decision tampoco existe en la realidad. McKinsey publicó hace más de una década su consumer decision journey mostrando que el viaje real funciona como un bucle. Los consumidores entran, salen, vuelven, comparan, abandonan y reanudan.

Un análisis reciente de AI Digital recoge las posiciones de BCG y Edelman, que describen el comportamiento de compra como demasiado dinámico para un modelo lineal y la compra como el inicio de una relación, no su final. Salesforce reporta que el 73% de los compradores B2B esperan que el vendedor entienda sus necesidades antes de la primera conversación.

El funnel sobrevive en las organizaciones porque cumple una función política. Es un lenguaje compartido entre departamentos. Es una forma de repartir presupuesto y es una manera de dividir KPIs entre equipos. Cuando desmontas el funnel, desmontas la estructura organizativa que se monta encima, y eso cuesta más que mantener la historia.

La paradoja de la abundancia de datos

Más datos no implica mejores decisiones, y está documentado en la literatura: parálisis por análisis.

Logarithmic Perspectives publicó en febrero de 2026 un análisis donde argumenta que la era de la abundancia de medición ha producido decisiones más lentas y más debate. Una investigación citada por Moosend sobre analysis paralysis muestra que el 78% de las personas se sienten abrumadas por la cantidad de fuentes de datos.

El estudio que llevo citando 14 años en mis clases de CRO es de la mermelada de Iyengar y Lepper, citado en un análisis de CMSWire sobre saturación de datos, que mostró que cuando se ofrecían 24 sabores de mermelada solo el 3% compraba, pero cuando se ofrecían 6 sabores el 30% compraba.

La formación como reproductor del problema

El problema empieza antes del marketing. La educación general sigue funcionando con un modelo bastante taylorista, que nos programa para entornos predecibles donde hay una respuesta correcta. Es otro melón que no voy a abrir aquí. Pero la formación reglada en marketing y comunicación viene del mismo sitio y sigue enseñando ese mismo modelo de mundo predecible. Y a esto se suma que en marketing falta conocimiento técnico de base, lo que deja al profesional sin herramientas para auditar la metodología de las tools que compra.

Mark Ritson lleva años hablando de "tactification" como problema de la disciplina. En una entrevista con Marketing Week junto a Byron Sharp describe la obsesión con la ejecución sin entender lo estratégico. En su aparición en The CMO Show dijo: "you can actually have too much measurement and not enough insight".

Sharp ataca directamente a las métricas pequeñas que no tienen impacto demostrable. En su intervención de 2025 al recoger el Sir Charles McGrath Award dijo que los marketers están obsesionados con medir cosas pequeñas que no tienen casi ningún impacto.

Además, Sharp y Ritson critican el performance marketing en favor de reach y mental availability, y el prompt tracking no es exactamente lo que tienen en el punto de mira, pero estas tools podrían aprender mucho de esto.

El sector SEO viene de 20 años donde el rank tracker era la métrica reina para muchos. Search Engine Journal publicó en noviembre de 2025 un análisis sobre repositioning del SEO donde argumenta que las definiciones tradicionales ya no son suficientes. La inercia aquí es enorme y la razón es que rehacer el reporting es rehacer la formación, los contratos y la identidad profesional. No basta con cambiar un dashboard.

Cómo encajan los prompt trackers en este contexto

Si juntas las piezas, el modelo de negocio del prompt tracker se entiende bastante bien. Una herramienta puede venderse incluso cuando su validez técnica es débil, siempre que cumpla tres condiciones. Que el número sea lo suficientemente estable para que parezca señal. Que la metodología sea lo suficientemente técnica para que el comprador no pueda cuestionarla. Y que la narrativa de venta active el FOMO suficiente para que decir que no parezca arriesgado profesionalmente.

Hay aproximaciones más sofisticadas, que son las que yo hago con mis propios pipelines. El problema es que o falta el conocimiento técnico para construirlas, o las tools que podrían aplicarlas no lo hacen porque les rompería el margen. El resultado es que la mayoría del dinero se mueve en la zona donde la promesa de medición está más alejada de la realidad técnica.

¿Qué cambiaría esta dinámica?

¿Qué pasará con prompt trackers cuando los datos de primera parte se generalicen? Cuando Google extienda Search Console a AI Overviews y AI Mode, el visibility score modelado va a tener que dar otra cosa, ORM, sentimiento de marca, panel de brand marketing. Algo más cercano a un dashboard de gestión de reputación que a un indicador de visibilidad irreal.

Cuando llegó Google Search Console en 2015, las herramientas de tercera parte no desaparecieron, pasaron a tener que justificarse contra el dato real y aportar valor más allá del mismo.

Pero si bien es cierto que estas tools daban datos que correlacionaban con los ingresos. Si estas tools se compran tal cual es, en parte, porque NO hay perfiles técnicos en el proceso de decisión.

Para mejorar la decisión individual de una compra influye la diversidad cognitiva en la sala donde se decide. El estudio de Meissner y Wulf en European Management Journal en 2017 muestra que tener perfiles distintos en el equipo de decisión sí reduce la ilusión de control. Si en la mesa hay alguien que entiende estadística, alguien que entiende el negocio, y alguien que entiende cómo funcionan los LLMs por dentro, la conversación cambia.

El CFO se cita a menudo como el mecanismo de corrección. Posiblemente no va a fulminar el prompt tracking, pero con los presupuestos más apretados desde 2023, va a empezar a pedirle lo mismo que le pide al resto de tools del stack.

Lo que queda

La tool en sí no es el problema. Lo que ha hecho la IA es subir la incertidumbre, y la industria que vive de ofrecer reducción de incertidumbre se ha frotado las manos. Las tools de prompt tracking son la respuesta perfecta a un problema que ya existía antes. El ecosistema está en una fase temprana donde la promesa de medición va por delante de la metodología real, y el dinero fluye hacia donde la promesa es más pomposa. Y ver el muro de LinkedIn plagado de publicaciones pagadas a influencers que cuentan mentiras no ayuda. Si pagas a un influencer, lo callas. Es por ello que yo no tengo contratos con ninguna herramienta. Hasta 8 prompt tackers me han ofrecido dinero por hablar bien de ellos, los he rechazado a todos.

No sólo eso, herramientas como Profound parece ser que pagan hasta 250€ por una review positiva en G2:

Mientras tanto, el trabajo del consultor honesto consiste en no fingir certezas que no tiene, en distinguir entre lo que se puede medir y lo que se está midiendo, y en preguntarse, antes de comprar o recomendar una tool, qué decisión concreta de negocio va a cambiar con ese dato. Si la respuesta es "ninguna", la tool es humo. Si la respuesta es algo concreto, conviene comprobar si el dato que entrega tiene la calidad necesaria para sostener esa decisión. Es analítica básica aplicada a una industria que se está construyendo más rápido de lo que se está entendiendo.

La entrada El negocio de la certidumbre prefabricada se publicó primero en Natzir Turrado.

Era técnicamente posible, pero también sabía que me iba a meter en un marrón, hace años ya hice proyectos con la Raspberry, con ESP32 e incluso me he hecho mods para el Flipper, pero eran un dolor de cabeza. Así que la idea se quedó en el cajón durante años, cogiendo polvo junto con esos juguetitos.

Hasta que empecé a trabajar con Claude Code en noviembre.

En este tutorial, os cuento el proceso de desarrollo y montaje del panel LED Waveshare con la Raspberry Pi. El proyecto lo he hecho open source y el código lo tenéis aquí.

Qué hace el panel

Un panel LED RGB de 64x32 píxeles controlado por una Raspberry Pi 4, que se conecta a la API de SISTRIX y va rotando dominios mostrando: label, valor de visibilidad, cambio porcentual, país, modo (weekly/daily) y una sparkline con la evolución. Además de una brand card personalizable con logo en pixel art y mensaje con scroll animado.

Todo se gestiona desde un panel web accesible en tu red local. El panel incluye un simulador LED que replica exactamente lo que se ve en la pantalla física, así que puedes probarlo todo sin hardware.

Algunas cosas que me gustan:

• Editor visual de layout: arrastra y redimensiona cada elemento directamente sobre el simulador
• Caché inteligente: minimiza créditos API consultando solo cuando hay datos nuevos (daily tras medianoche, weekly tras el lunes)
• Sincronización web <-> LED: slide actual y estado on/off sincronizados en tiempo real
• Botón físico para encender/apagar sin sacar el móvil
• 6 idiomas, responsive, accesible (WCAG 2.1 AA)
• Colores: hex, rainbow y degradados de dos colores — todo configurable

Todo el código va en dos archivos Python: display.py (driver LED, ~1.000 líneas) y web_panel.py (panel web con simulador, ~3.700 líneas). Sin frameworks, sin npm, es vanilla JS puro. El frontend va inline dentro del Flask. Si el proyecto fuera más grande ya me lo replantearía por mantenimiento.

El hardware: Raspberry Pi + LED Matrix Panel

Llevan enlaces son de afiliado de Amazon, si compras a través de ellos me llevo una pequeña comisión, que me lo he currado

Imprescindible

• Raspberry Pi 4 4GB Starter Kit - Importante: la Pi 5 no es compatible con el Adafruit Bonnet. Tiene que ser Pi 4 o anterior (quizás habría que tocar --led-slowdown-gpio por temas de rendimiento).
• Panel LED Waveshare 64x32 P3 - 192x96mm, pitch 3mm (P3 = 3mm entre cada LED).
• Adafruit RGB Matrix Bonnet - HAT que conecta la Pi al panel LED vía GPIO. Se enchufa directamente, sin soldar.

Opcional (pero recomendado)

• Botón pulsador Gebildet 12mm - Acero inoxidable con LED azul. Encender/apagar sin tocar el móvil.
• Kit de soldador 60W- Para soldar los cables del botón a los pines GPIO.
• Broca escalonada Flintronic - Para agujeros limpios en la carcasa sin partir el plástico.
• Carcasa impresa en 3D - Pedí a un amigo que me imprimiera una a medida (192x96mm, profundidad 13-15mm). Si no tienes impresora, busca en Etsy "64x32 P3 LED panel case".
• Juego de tornillos M3 (560 piezas) - Viene de todo: varios largos, tuercas y arandelas. Así que da igual la profundidad de tu caja, seguro que hay alguno que encaja.
• Fuente de alimentación 5V 3A - Con conector barrel jack 5.5x2.1mm. Es opcional si usas brillo bajo (<50%), pero recomendada. Sin ella, el panel se alimenta por los GPIO de la Pi, que aguantan hasta ~1.2A. A brillo alto o pantallas muy claras puede causar reinicios. En esta configuración he probado que no es necesario.

Montaje paso a paso

1. Prepara la carcasa: usa la broca escalonada para los agujeros. Yo hice uno de 12mm para el botón y otro más pequeño para el cable flat y la alimentación. La escalonada para mí es clave porque una broca normal parte el plástico, esta va ajustando el diámetro poco a poco. También se podría hacer con un hierro caliente o un soldador, pero no es lo mismo.

2. Encaja el Bonnet en la Pi: presiona hasta que encaje en los pines GPIO.

3. Cablea el botón (opcional): un terminal a GPIO 19 (pin 35), el otro a cualquier GND. No importa la polaridad. Yo lo puse en el pin 39 después de 2 fallos como se puede observar (resulta que la matrix tiene ocupados casi todos los pins).

4. Conecta el cable flat: del panel al conector HUB75 del Bonnet. Solo hay una orientación (tiene muesca).

5. Conecta la alimentación del panel (opcional): fuente 5V al barrel jack del Bonnet. Yo no tenía adaptador barrel jack de la potencia que necesita el panel, así que me monté uno con un cargador USB de un Meizu antiguo de 5V 3A, un cable barrel jack 5.5x2.1mm que corté de otra fuente de 12V que no usaba, y un cable USB <-> micro USB que también corté y soldé. Funciona perfecto y me ahorré el dinero y esperar al envío. Si no te va hacer el MacGyver, compra la fuente directamente. UPDATE: He visto que funciona sin peligro y sin necesidad de esta fuente extra, así que mejor, un cable menos.

6. Enciende la Pi: USB-C. Si todo está bien, el panel se enciende en segundos.

7. Fija el panel a la caja: una vez todo funciona desconecta los cables y pásalos por los agujeros. Atornilla con tornillos M3 por las esquinas.

Cómo instalarlo

El proyecto lo he hecho open source y está en GitHub. Si quieres montarlo:

1. Instala Raspberry Pi OS Lite 64-bit en tu Pi 4
2. Clona el repositorio y ejecuta bash setup.sh
3. Instala el driver LED desde hzeller/rpi-rgb-led-matrix
4. Abre http://raspberrypi.local:5001 desde cualquier dispositivo en tu red
5. Configura tu API key de SISTRIX, añade dominios, y ya está

Sin hardware, puedes probar solo el simulador:

pip install flask pillow requests
python3 web_panel.py

Abre http://localhost:5001 y listo.

Problemas que me encontré

El drama del botón y los GPIO

Conecté el botón al GPIO 26. Sin el panel LED funcionaba perfecto. Pero en cuanto arranqué el driver del panel... dejó de funcionar. El Bonnet usa casi todos los GPIO, y el 26 es una línea del multiplexor. Probé el 25 y mismo problema.

Al final, el GPIO 19 (pin 35) estaba libre. Pero no acabó ahí... el botón apagaba y encendía inmediatamente, o solo funcionaba una vez. El problema era la detección por nivel y la solución fue detección por flanco de subida (transición LOW->HIGH al soltar), que genera exactamente un evento por pulsación.

El blanco que salía naranja

En el simulador web los textos se veían blancos puros. En el LED, anaranjados. Los LEDs rojos y verdes de estos paneles tienen más brillo que los azules. La solución que apliqué fue la corrección de color selectiva solo para blancos y grises (reduce R un 10%, G un 8%). Mientras que los colores saturados no se tocan.

El brillo y los PWM

Con brillo a 60, muchos píxeles del mismo número se veían más brillantes y un shimmer visible en dígitos grandes. El punto ideal que he encontrado es brillo 42, PWM bits 8 (pwm_lsb_nanoseconds 300). Degradados suaves, sin shimmer, y suficiente brillo de día sin deslumbrar de noche. Quizás con un panel más profesional habría que cambiar estos ajustes.

El SSH que se rompió solo

Un día el SSH se colgaba al conectar y el .bashrc imprimía texto en sesiones no interactivas, rompiendo SCP/SFTP. Tuve que conectar monitor y teclado a la Pi para ver que ocurría. Así que lo mejor es envolver los echos de tu .bashrc en if [[ $- == *i* ]].

La sincronización

Esto parece trivial pero fue lo más difícil de resolver. Hay dos procesos independientes: el display.py que controla el panel LED (corre como root para acceder a GPIO) y el web_panel.py que sirve el simulador en el browser. Cada uno tiene su propio loop de rotación, su propio estado, su propia idea de qué slide está mostrando. Los problemas fueron apareciendo uno a uno:

• Cambios que tardaban 60 minutos: quitabas un dominio en la web y el LED no se enteraba hasta el siguiente refresco API. Ahora detecta cambios en la lista de dominios en cada ciclo y recarga desde caché al instante.
• Fetch bloqueante: cuando el display hacía una llamada API a SISTRIX, el panel se congelaba durante varios segundos en el último frame (normalmente la brand card). Lo movimos a un thread en background.
• Rotación desincronizada: el panel web tenía su propio timer de rotación independiente del LED. Ahora el web es "esclavo" del LED cuando el servicio está activo y sigue su slide en tiempo real (3 secs de delay) via un fichero de estado compartido.
• Edición interrumpida: estabas editando la brand card en el web y de repente el slide cambiaba porque el LED seguía rotando. Ahora el modo edición pausa toda la sincronización.
• Encendido desincronizado: le dabas a ON y cada uno empezaba por un slide diferente. Ahora ambos arrancan desde el slide 0.
• Botón muerto en brand card: el botón físico GPIO no respondía mientras se mostraba la brand card, porque el loop de scroll no lo estaba comprobando.

Cada uno de estos bugs parecía simple, pero requería entender el flujo completo entre dos procesos, un fichero de config compartido, un state file, timers de JavaScript, un loop de Python, y un botón físico. La IA resolvía cada bug individualmente, pero no veía el sistema y era como jugar al Whac-A-Mole. Yo tenía que detectar los problemas probando en el hardware real y explicarle qué estaba pasando.

Los bugs de seguridad

Esto me preocupó especialmente porque el código generado por la IA tenía MUCHOS agujeros:

• API key expuesta: el endpoint /api/config devolvía la clave de SISTRIX al frontend en texto plano.
• XSS: los nombres de dominio se insertaban sin escapar. Un <script> en el label se ejecutaba.
• Sin cabeceras de seguridad: ni X-Content-Type-Options, ni X-Frame-Options, ni CSP.
• Sin validación de entrada: un label podía ser cualquier cosa sin sanitización.

La IA genera código funcional rápido, pero la seguridad NO está en sus prioridades por defecto. ¡Hay que auditarlo todo!

Los caracteres que faltaban (y mi hija)

El panel usa fuentes bitmap propias donde cada carácter es una rejilla de píxeles definida a mano. Claude generó el alfabeto y los números. Todo bien hasta que mi hija mayor (7) quiso poner el nombre de su hermana y ella en la tarjeta personalizada tal que así: "Chloe & Lía".

Con eso vimos que faltaban acentos y $, %,&, (, ), =, #, @... Nos pusimos los dos con papel cuadriculado a diseñar los caracteres de 3x5 y 5x7 píxeles. Ella rellenaba cuadraditos, yo los traducía a bits y al final acabó haciéndolo ella también. Además, corregimos letras como la S, la X y la W que en 5x7 le quedaban horribles a Claude y los corregimos a mano sobre papel. Esta parte la podría haber delegado a Claude, pero entonces habría perdido una oportunidad de enseñarle a mi peque cómo funciona una pantalla.

También fue idea suya lo del color rainbow y de ahí salieron también los degradados de dos colores configurables.

Desarrollar con IA: lo que he aprendido

Llevo usando IA generativa desde que tuve acceso a la beta de GPT-3 en 2020. Este panel lo he desarrollado íntegramente con Claude Code. Es decir, esto no es un experimento ni mi primera vez, es mi forma de trabajar desde hace años. Pero lo que hizo Anthropic con Opus en noviembre del año pasado es un antes y un después. Así que no me habría embarcado este proyecto sin ese salto.

En febrero de 2025, Andrej Karpathy acuñó el término "vibe coding" que significa "aceptar todo lo que genera el modelo sin leer los diffs y olvidarte de que el código existe". Un año después él mismo se desdijo y ahora prefiere "agentic engineering". Normal... porque lo de dejarte llevar por las vibes funciona para proyectos de usar y tirar de fin de semana, no para producción.

A mí el término nunca me gustó. Lo que hago se parece más a lo que Kent Beck llama "augmented coding". En vibe coding te da igual el código, solo quieres que funcione; en augmented coding te importa el código, los tests, la cobertura. La IA amplifica tu visión y tu capacidad de descomponer problemas, pero no reemplaza tu criterio.

Simon Willison, cocreador de Django, lo clava cuando dice que revisar código generado por IA muchas veces es más difícil que escribirlo tú. Tienes que reconstruir la intención y pillar lo que el modelo ha ignorado. Pasas de escritor a supervisor y eso exige de mucho más criterio. Y es justamente lo que ha pasado con este proyecto.

Lo que funciona bien

Claude Code maneja todo el flujo desde la terminal en lenguaje natural. "Sube display.py a la Pi y reinicia el servicio" -> SCP, SSH, systemctl restart. "Haz commit" ->  analiza el diff, escribe un mensaje coherente, ejecuta. "El botón no funciona, mira el log" -> se conecta a la Pi por SSH, lee los logs, identifica el problema, propone solución.

Así resolvimos el GPIO, el debounce, la detección por flancos... Yo no sabía qué pines del Bonnet estaban ocupados y él analizó el pinout y los encontró. Sin IA esto habría sido un verdadero infierno.

Lo que falla

CSS y diseño responsive: cada cambio en la interfaz rompía algo. Movía un padding y se descuadraba el mobile. Cambiaba un color y dejaba ilegible un botón. No tenía manera de ver lo que hacía.

La solución que se me ocurrió hace unos meses para no gastar tokens de Computer Use fue meterle un Puppeteer a Claude Code. Un script para hacer capturas en desktop (1280x900) y mobile (390x844), y que Claude hacía con cada subida y que revisaba a cada cambio visual antes de subirlo. Las intervenciones por mi parte se redujeron un 80%.

Design system: el panel tiene tokens CSS (espaciado, colores, bordes) y Claude por defecto metía valores mágicos en línea como margin-top: 13px, color: #3a7fc2 ... en vez de usar las variables y cada botón era de su padre y de su madre. Tenía que estar encima constantemente aunque se lo guardara en memoria o un skill.

Cambios no pedidos: le dices "cambia el color del texto" y de paso te mueve los números, te cambia un layout que funcionaba, o te "optimiza" algo que no estaba roto.

Usabilidad: la IA desarrolla funcionalidades, pero no piensa en la persona que las va a usar. Control de estados, mensajes de confirmación, flujos lógicos... nada de eso le sale solo. Si un botón debería deshabilitarse mientras se carga, no lo hace. Si una acción destructiva necesita confirmación, no la pone. Si el orden de los pasos no tiene sentido para un usuario, no lo detecta. Touch targets de 24px, modales que no caben en pantalla, formularios que se
tapan con el teclado virtual... Todo eso lo pillé probando desde el móvil. Tienes que ser tú quien piense en la experiencia.

El desastre del francés: el i18n va en un objeto JavaScript enorme con las cadenas de 6 idiomas que pusimos al final. Al añadir las traducciones francesas, un acento mal escapado reventó las 3.700 líneas del archivo. Pantalla en blanco, sin errores claros y a Claude no se le ocurre otra que tabular todo el código con una RegEx inutilizando todo proyecto. Suerte que teníamos git y vuelta al estado anterior.

Cuánto habría costado este proyecto sin IA asistida

Usé la calculadora COCOMO de la NASA, el modelo estándar de estimación de esfuerzo en ingeniería de software, para medirlo:

• 4.883 líneas de código (driver de hardware, renderizado bitmap, caché, GPIO, panel web completo con simulador, editor visual, 6 idiomas, WCAG 2.1 AA)
• Esfuerzo: 12,3 persona-mes
• Solo a tiempo completo: ~12 meses
• Coste equivalente: €100.000–140.000 a tarifa de mercado europeo

Pero COCOMO en realidad está pensado para otra cosa. Sirve para equipos, documentación formal, fases de diseño, QA, gestión de proyecto. Asume que hay coordinación entre personas, reuniones, especificaciones... Nada de eso aplica aquí. Además, buena parte de las líneas son HTML/CSS/JS inline del panel web y no es lo mismo que código de sistemas. Para un proyecto personal de un solo dev, COCOMO lo sobreestima salvajemente.

Una estimación más realista de un desarrollador full-stack con experiencia en hardware, LEDs y Flask tardaría quizás 2-3 meses a tiempo completo sin apoyo de la IA. Yo solo soy un consultor SEO, sé algo de código pero no me dedico a ello, sin experiencia con paneles LED ni GPIO, así que probablemente 4-6 meses si pudiera dedicarme 100% a ello. Al 20-30% de dedicación, más de un año. Así que en la práctica, nunca lo habría terminado. Por eso nunca lo empecé

Con Claude Code lo he hecho en 3 jornadas. Con bugs, con idas y venidas, con cosas que ha roto y que hemos tenido que arreglar. Pero funciona y creo que es bastante robusto. Pero quizás salte alguna movida que no me ha dado tiempo a ver cuando más gente lo use.

No es que la IA haga el trabajo por ti, es que proyectos que antes no merecían la pena por la relación esfuerzo/resultado, ahora sí la merecen. El umbral de lo que puedes permitirte construir ha bajado drásticamente. Pero tienes que ser tú el control de calidad, revisando cada cambio, tener git al día, auditar la seguridad, y no confiar a ciegas. Para mi esto no es vibe coding. Es ingeniería con un copiloto muy rápido al que no puedes soltar el volante, por lo menos por ahora.

El proyecto es open source. Si lo montas, ¡cuéntamelo! me haría ilusión ver más paneles LED de SISTRIX por ahí.

La entrada Sistrix Led Ticker - Montaje de Raspberry Pi + LED Matrix Panel [Tutorial] se publicó primero en Natzir Turrado.

Este informe técnico examina por qué medir la visibilidad en IA es técnicamente problemático, qué dice la evidencia disponible y cómo evaluar las herramientas del mercado.

Mi objetivo es tratar reducir la asimetría de información, es decir, equilibrar la balanza y que sepas lo mismo que saben (o deberían saber) quienes te venden estas herramientas y agencias que ofrecen "GEO/AEO".

Índice del artículo

• 1. Qué es la visibilidad en IA y qué miden los prompt trackers
• 2. La evidencia científica
• 3. Cómo deciden los LLMs qué información mostrar
• 4. Por qué no puedes replicar la experiencia del usuario
• 5. Prompt Trackers: Herramientas para medir visibilidad en IA
• 6. Por qué las métricas de visibilidad en la IA actuales no funcionan
• 7. Mi apuesta: El tracking de prompts masivo
• 8. Conclusión

Qué es la visibilidad en IA y qué miden los prompt trackers

La visibilidad en IA es la frecuencia y prominencia con la que una marca aparece en las respuestas de modelos de lenguaje (ChatGPT, Perplexity, DeepSeek, AI Overviews de Google, Grok, Copilot...) cuando los usuarios hacen preguntas relacionadas con su sector.

Los prompt trackers son herramientas que ejecutan prompts predefinidos contra estos modelos y miden si tu marca aparece, en qué posición, y con qué frecuencia comparada con competidores. Prometen responder preguntas como: ¿Me recomienda ChatGPT cuando alguien pregunta por "mejores herramientas de email marketing"? ¿Con qué frecuencia? ¿Por encima o por debajo de mi competencia?

El problema es que estas preguntas asumen un nivel de consistencia y replicabilidad que los LLMs, por diseño, no tienen.

Algo que el propio Jesse Dwyer, CCO de Perplexity, confirma en el WSJ: la búsqueda IA personaliza los resultados según el usuario que pregunta, lo que los hace difíciles de predecir y de medir.

La evidencia científica

Los LLMs son inconsistentes por diseño

La investigación académica ha demostrado que los modelos de lenguaje son intrínsecamente no determinísticos, incluso con configuraciones supuestamente "determinísticas":

• Un paper de enero 2025 en ACM Transactions encontró que en el 75,76% de tareas de CodeContests, ChatGPT no produjo dos outputs idénticos con temperature=0, que muchos creen erróneamente que garantiza determinismo. Algo que demostré en esta charla el año pasado.
• El estudio de Wang y Wang (septiembre 2025) analizó 3.4 millones de outputs a través de 50 ejecuciones independientes por tarea. Los modelos más avanzados no son más consistentes: GPT-4o produjo respuestas exactamente iguales solo el 3% del tiempo, mientras que GPT-3.5 Turbo alcanzó el 97%. La recomendación de los autores es ejecutar 3-5 ejecuciones para mejorar la consistencia estadística. Ninguna herramienta del mercado habla de esto.
• El paper de Anthropic (noviembre 2024) reveló un problema estadístico que afecta directamente a las herramientas de AI visibility: cuando ejecutas muchos prompts sobre temas relacionados los errores no son independientes. Si el modelo tiene un sesgo hacia o contra tu marca en el tema "software CRM", fallará sistemáticamente en todos los prompts sobre CRM de forma no aleatoria. Anthropic encontró correlaciones de 0.3 a 0.7 entre preguntas relacionadas, lo que significa que 30 prompts sobre temas similares no equivalen a 30 datos independientes, sino quizás a 5-10. Hay muy poca transparencia en el método/proceso exacto que usan los llm trackers para obtener las respuestas, por lo que no sabemos si esto podría ser un problema o no.
• La variabilidad no solo viene de la aleatoriedad inherente del modelo, sino también del formato del prompt. En la revisión que hice recientemente de la literatura científica documenté diferencias de hasta 76 puntos de precisión por cambios menores como espacios, puntuación o mayúsculas (FormatSpread, Sclar et al.).

Volatilidad medida: 40-60% de cambio mensual

El estudio de Profound (julio 2025) analizó ~80.000 prompts por plataforma comparando junio con julio:

• Google AI Overviews: 59,3% de los dominios citados cambiaron
• ChatGPT: 54,1%
• Microsoft Copilot: 53,4%
• Perplexity: 40,5%

En periodos de 6 meses, la volatilidad se dispara al 70-90%.

Estudios sobre consistencia de marcas

El estudio de SparkToro (enero 2026) ejecutó 2.961 prompts a través de 600 voluntarios usando ChatGPT, Claude y Google AI en 12 categorías. Resultados:

• Menos de 1 en 100 probabilidades de obtener la misma lista de marcas dos veces
• Menos de 1 en 1.000 probabilidades de obtener la misma lista en el mismo orden

La variabilidad depende del tamaño del espacio de consideración. Para queries con pocas opciones (concesionarios Volvo en Los Ángeles), la correlación es alta. Para espacios amplios (novelas de ciencia ficción), la variabilidad es extrema.

Rand Fishkin dice que que aunque las listas y rankings son aleatorios, el porcentaje de visibilidad (cuántas veces aparece una marca en múltiples ejecuciones) puede ser una métrica válida. "City of Hope hospital" apareció en el 97% de las respuestas sobre hospitales oncológicos en la costa oeste, aunque su posición variaba constantemente.

Mi opinión es que una métrica sea "menos aleatoria" no la convierte en útil. El porcentaje de visibilidad te da una foto borrosa de algo que no puedes controlar, porque está basada en prompts que no son los que hacen tus usuarios reales, ejecutados en condiciones que no reflejan su experiencia. Es el menos malo de los indicadores, pero sigue siendo un indicador de valor limitado.

Hay otro problema y es que la visiblidad tiene un sesgo estructural hacia las marcas ya establecidas. Las marcas conocidas (Booking, Amazon, MediaMarkt) muestran métricas más estables porque están sobrerrepresentadas en los datos de entrenamiento porque aparecen en miles de contextos diferentes, creando asociaciones robustas en los pesos del modelo. Para marcas emergentes o de nicho, el mismo % de visibility fluctúa tanto entre ejecuciones que es prácticamente ruido estadístico. Esto es una paradoja porque las herramientas son más "fiables" precisamente para quienes menos las necesitan (las marcas que ya saben que son visibles), y menos fiables para quienes más las necesitarían (marcas intentando ganar visibilidad).

Para tener una visibilidad "fiable" necesitas ejecutar cientos o miles de prompts múltiples veces. El coste computacional (y económico) de eso para conseguir un dato direccional que no correlaciona con tráfico ni conversiones es difícil de justificar.

El estudio de Mike Sonders (febrero 2026) analizó 1.200 interacciones con ChatGPT (12 prompts × 100 ejecuciones cada uno, con IP diferente por sesión) centrado en recomendaciones de software B2B y encontró lo siguiente:

• Cuanto más de nicho es una categoría, más fácil es aparecer de forma consistente en las respuestas de IA.
• Solo el ~11% de las marcas que un LLM menciona en una categoría aparecen de forma consistente. El resto rota de forma casi aleatoria entre respuestas.
• Cuanto más específico es el prompt (con rol, contexto o caso de uso), más difícil es entrar en el grupo de marcas dominantes, porque el modelo se compromete más con menos opciones. Esto genera más ruido en las mediciones, y es un problema para los trackers porque los usuarios reales hacen prompts complejos y contextuales, no las preguntas genéricas tipo "best X software" que usan la mayoría de herramientas. Una única ejecución por prompt es casi inútil dada la variabilidad. Sonders recomienda un mínimo de ~5 ejecuciones por prompt en la sesión, algo que las herramientas de tracking no hacen, por desconocimiento y, de saberlo, no lo harán porque se les multiplicaría por x5 el coste.

Cómo deciden los LLMs qué información mostrar

El sistema QDF de los modelos

La filtración del system prompt de GPT-5 revela que ChatGPT usa un sistema QDF (Query Deserves Freshness) con escala de 0 a 5:

• 0: Histórico, no importa que esté actualizado
• 1: Relevante si es de los últimos 18 meses
• 2: Relevante si es de los últimos 6 meses
• 3: Relevante si es de los últimos 90 días
• 4: Relevante si es de los últimos 60 días
• 5: Lo más reciente de este mes

No todas las queries activan búsqueda web. En ChatGPT Existe un parámetro use_freshness_scoring_profile evalúa para cada query si necesita información externa. Además, descubrí que ChatGPT ejecuta un clasificador probabilístico llamado Sonic que calcula una search_prob (la probabilidad de que la query necesite datos frescos) y la compara contra un umbral (force_search_threshold), actualmente en torno al 65%.

Los leaks de Claude Sonnet 4.5 muestran un patrón similar donde el modelo categoriza consultas en "nunca buscar" (hechos estables, definiciones), "single search" (términos desconocidos), y "research" (2-20 llamadas con contraste multi-fuente).

Reranking y señales de contexto

El sistema de reranking de ChatGPT (ret-rr-skysight-v3) aplica señales adicionales de detección de intención, terminología de dominio, filtrado por tipo de fuente. Si hay herramientas internas disponibles (Google Drive, Slack, CRM), los modelos las priorizan sobre búsqueda web. Todo esto depende del contexto de tu conversación.

Las patentes de Google: por qué los prompts sintéticos no funcionan

Estas dos patentes demuestran por qué las herramientas externas no pueden replicar cómo Google genera query fan-out y organiza resultados.

• Query Fan-Out (US20230281193A1): Cuando alguien busca algo Google no se limita a esa query literal, lo que hace es generar variantes usando modelos entrenados con el comportamiento real de millones de usuarios (qué buscaron, en qué hicieron clic, qué reformulaciones hicieron después). Además, tiene en cuenta cosas que una herramienta externa simplemente no puede saber como dónde está el usuario, qué estaba haciendo antes o su historial de sesión. Todo esto se procesa en tiempo real, adaptándose al contexto de cada búsqueda individual.
• Thematic Search (US12158907B1): Google analiza los documentos que considera relevantes para una búsqueda, genera resúmenes internos de cada uno, los agrupa en clusters temáticos y luego los ordena según criterios como calidad, autoridad o popularidad. El problema es que esas señales de ranking son completamente opacas desde fuera, es decir, no sabemos exactamente cómo pondera cada factor ni qué documentos considera relevantes antes de mostrarnos nada.
• SAGE de Google (enero 2026): los agentes de Google de deep search están siendo entrenados para ejecutar entre 2 y 10 hops de razonamiento por query, usando estrategias como resolución de conflictos entre fuentes, generación de hipótesis y razonamiento temporal. Todo esto ocurre internamente antes de que veas la respuesta. Los prompts sintéticos de las herramientas externas ni siquiera se aproximan a esta complejidad.

Los datos empíricos confirman esto. El estudio de Ahrefs (marzo 2026) analizó 863.000 SERPs y 4 millones de URLs citadas en AI Overviews y encontró que solo el 38% de las páginas citadas en AI Overviews también aparecen en el top 10 orgánico para esa misma query. El 62% restante proviene de páginas que rankean más abajo o directamente no aparecen en los resultados orgánicos de la query original. En julio de 2025, esa cifra era del ~76%. Es decir, con Gemini 3, Google está tirando cada vez más del fan-out interno para seleccionar fuentes, no de los resultados directos. Si ni siquiera rankeando en el top 10 tienes garantía de ser citado, imagina lo que puede capturar un prompt tracker lanzando queries desde fuera sin acceso a las sub-queries internas.

El propio artículo de Ahrefs reconoce que los AI Overviews son probabilísticos, y su contenido, citaciones, entidades y fan-outs cambian con cada consulta.

Por qué no puedes replicar la experiencia del usuario

Memoria del modelo vs búsqueda web

Hay un problema que creo que ninguna herramienta de prompt tracking resuelve y es que no te dicen si el LLM buscó en la web o respondió desde su conocimiento interno.

*Update 01/02/2026: He encontrado que Wikay.io sí que lo hace.
*Update 02/2026: Bing Webmaster Tools ha lanzado AI Performance, que resuelve parcialmente este problema al reportar solo citaciones visibles en respuestas de Copilot y Bing AI. Si tu URL aparece ahí, sabes que fue retrieval, no conocimiento paramétrico. Es el primer dato de primera parte que confirma esta distinción.

Esta decisión depende de la configuración del modelo (versión, temperatura, system prompts, si tiene search habilitado), de la volatilidad del tema y cómo se formula el prompt (para precios o noticias busca siempre, para definiciones o conceptos estables responde de memoria), del umbral de confianza interno (si el modelo "cree" que sabe la respuesta, no busca), y del método de acceso, porque API e interfaz web tienen comportamientos de búsqueda distintos.

Y cuando sí busca, hay otra capa de opacidad porque el modelo no ejecuta tu prompt literal. Como vimos antes, genera múltiples subqueries internas (fan-out), busca en paralelo, y sintetiza. Tu marca puede aparecer en el resultado final, pero no sabes qué subquery fue responsable. No puedes optimizar para algo que desconoces.

Esto cambia completamente la accionabilidad:

• Si la respuesta viene de búsqueda web: puedes crear y optimizar contenido, digital PR... pero sin saber para qué subquery exacta.
• Si la respuesta viene del conocimiento paramétrico: no hay nada que hacer a corto plazo. Dependes del próximo ciclo de entrenamiento y de cambiar la narrativa del corpus general sobre tu marca.

Es como saber que tu cartera subió un 5% sin saber qué activo lo causó...

Y no solo desconoces la subquery porque ni siquiera sabes en qué idioma se hizo. Un estudio de Peec AI (febrero 2026) analizó más de 10 millones de prompts y 20 millones de query fan-outs y encontró que el 43% de las subqueries internas de ChatGPT para prompts no-inglés se ejecutan en inglés. En el 78% de sesiones no-inglés, ChatGPT complementa con búsquedas en inglés. Un usuario español preguntando en español desde España recibe resultados influenciados por fuentes anglófonas. Los prompt trackers que lanzan prompts en español no capturan esta capa de opacidad adicional.

Personalización por contexto

ChatGPT implementa dos sistemas de memoria (Saved Memories y Chat History) que influyen en cada respuesta. Experimentos del AEO Agency Team demostraron que incluso bajo "condiciones de testing absolutamente idénticas, las respuestas a veces difirieron".

Para queries geo-dependientes, ChatGPT convierte internamente los prompts. Un usuario en Nueva York que pregunta "mejores tiendas de electrónica" recibe una consulta procesada como "trusted electronics brands NYC store". Usuarios de pago reciben además respuestas "significativamente mejores" que los gratuitos.

Google ahora lleva las preguntas de seguimiento de AI Overviews directamente a AI Mode, manteniendo el contexto de la conversación. La búsqueda ya no es una query aislada, es una conversación donde cada pregunta influye en la siguiente.

Integración con datos privados

Robby Stein (VP de Producto en Google) anunció que usarán datos de Gmail, Drive y Calendar para personalizar respuestas. Una búsqueda de "mejores hoteles en Londres" tendrá en cuenta reuniones en Calendar, vuelos en Gmail, presupuestos en Sheets.

Google lanzó Personal Intelligence (enero 2026), que conecta Gemini con Gmail, Photos, YouTube y Search history. La función usa "context packing" para analizar repositorios de usuarios que superan el millón de tokens. Un ejemplo de Google: preguntar por neumáticos para tu coche y Gemini extrae la matrícula de una foto en Google Photos, busca especificaciones en emails de Gmail, y sugiere opciones basándose en fotos de viajes anteriores.

MCPs y herramientas instaladas

Claude, ChatGPT y otros LLMs permiten conectar herramientas externas (MCPs) que modifican el comportamiento del modelo. Un usuario con MCP de su CRM instalado recibirá respuestas completamente diferentes. Las herramientas de visibility no pueden saber qué MCPs ni qué contexto tiene cada usuario.

Esto, sumado a AI Mode generando interfaces al vuelo, los chats grupales en ChatGPT, y las memorias en todas las IAs... Si ya no tenían sentido los LLM trackers de 50 prompts, ahora menos.

Un pequeño cambio en system prompt, memorias o herramientas cambia completamente el resultado. No hay forma confiable de trackear la experiencia real de usuarios de LLM.

Prompt Trackers: Herramientas para medir visibilidad en IA

Las herramientas del mercado difieren en cuatro dimensiones: escala (cuántos prompts ejecutan), fuente de prompts (demanda real vs sintéticos), método de acceso (API vs scraping), y modelo de negocio.

Escala de datos

Escala masiva (millones de prompts):

• SISTRIX: 10 millones de prompts por idioma × 5 idiomas = 50M prompts totales. Google AI (AI Overviews & AI Mode), Perplexity, ChatGPT, DeepSeek.
• Ahrefs Brand Radar: ~190 millones de prompts/mes. ChatGPT (10,6M), Perplexity (13,1M), Gemini (7,2M), Copilot (13,3M), AI Overviews (134M), AI Mode (13,5M).
• Semrush AI Visibility: 100+ millones de prompts globales, incluyendo 90M+ en EEUU y 29M+ específicos de ChatGPT. ChatGPT, Perplexity, Gemini, Google AI Overviews/AI Mode.

Escala pequeña (decenas a cientos de prompts):

• Otterly AI: 10-100 prompts según plan
• Peec AI: 25 prompts en plan básico
• Promptwatch: 50-350 prompts según plan
• Profound: 50+ prompts según plan
• Waikay: 120+ prompts según plan

Fuente de los prompts

Demanda real (derivados de búsquedas web):

• SISTRIX: sugerencias de prompts de ChatGPT + "People Also Ask"
• Ahrefs: base de 28,7 mil millones de keywords + "People Also Ask"
• Semrush: compra clickstream data de paneles de terceros (quizás mediante data de prompts substraida de extensiones de Google o Microsoft), agrupa los prompts en topics, anonimiza y simplifica, así que técnicamente es sintético porque no son los prompts exactos

Sintéticos (inventados por el cliente o la herramienta):

• Conductor, Gumshoe, Otterly, Peec, Promptwatch, Profound, Wikay: el cliente define sus propios prompts (por ejemplo, usan queries long tail de Search Console) o la herramienta los genera algorítmicamente (prompts sintéticos, simulaciones de query fan-out)

Aunque Ahrefs llama a todo sintético: "Todas las herramientas usan prompts sintéticos ya que los datos de queries reales de usuarios no están disponibles." La diferencia es si esos prompts sintéticos derivan de señales de demanda real (PAA, keywords con volumen) o son completamente inventados.

Configuración de sesiones: La mayoría de herramientas ejecutan prompts en sesiones "limpias" (sin cookies, historial ni memoria). Gumshoe documenta explícitamente: "cada conversación empieza fresca, sin cookies ni historial, para asegurar resultados libres de sesgo". Esto es bueno para consistencia y replicabilidad, pero no refleja la realidad de usuarios con historial acumulado, memorias guardadas y contexto personalizado.

Personas/perfiles: Gumshoe usa un "enfoque persona-first", modelando cómo distintos segmentos de usuarios (roles, objetivos, pain points) formularían los prompts. El resto de herramientas trata todos los queries igual, ignorando que un CTO pregunta diferente que un marketing manager. Sin embargo, añadir personas introduce otra variable: o bien no cambian significativamente los resultados (según el estudio de Surfer que probó con system prompts filtrados), o bien añaden otra capa de variabilidad que hace los datos menos comparables entre herramientas.

Método de acceso: API vs Scraping

El estudio de Surfer SEO (diciembre 2025) comparó ambos métodos con 1.000 prompts:

• ChatGPT vía API: promedio de 7 fuentes citadas
• ChatGPT vía scraping: promedio de 16 fuentes citadas
• Perplexity: coincidencia de fuentes entre métodos del 8%
• 8% de llamadas API fallan en detectar menciones que sí aparecen en la interfaz

Conclusión de Wojciech Korczyński: "Monitorear respuestas desde API como proxy de tu AI visibility es totalmente erróneo."

Herramientas que documentan usar interfaces web (scraping):

• Ahrefs: documentan que todas las solicitudes se ejecutan a través de las interfaces web gratuitas y disponibles públicamente de ChatGPT, Gemini, Perplexity y Copilot.
• Otterly: usa Firecrawl.dev y SerpApi como subprocesadores de scraping
• SISTRIX: usa exclusivamente web scraping via interfaces reales de navegador, no APIs. Confirmado con su CEO, Johannes Beus

Herramientas que priorizan API: Conductor, Gumshoe , Wikay.

Metodología no especificada (o encontrada por mi) públicamente: Semrush, Peec, Promptwatch, Profound. Entiendo también que se oculte por incumplimento de ToS, así que es probable que usen scraping.

El problema del desfase de versiones

Las herramientas testean versiones de modelos que difieren de las que usan los usuarios (la última disponible), mientras muchas herramientas siguen usando GPT-4o, cuando la realidad es que actualmente solo el 0,1% de usuarios lo elige a diario. Y los los estudios de Wang y Wang demostraron también que modelos más recientes son más variables.

SISTRIX documenta exactamente qué modelos testea: gpt-4o-mini, gpt-4.1-mini para ChatGPT; gemini-2.0-flash-lite, gemini-2.0-flash, gemini-2.5-flash para Gemini; v3 para DeepSeek. Actualizan sus datos cuando se lanza un nuevo foundation model, reconociendo que "consultar los modelos más frecuentemente no añade valor, ya que la información en estos foundation models es estática."

La mayoría de herramientas no documentan qué versión del modelo testean ni con qué frecuencia actualizan.

Umbrales de significancia: ¿cuántos prompts necesitas?

El estudio de Wang y Wang mencionado antes recomienda 3-5 ejecuciones por prompt para obtener consistencia estadística, pero esas ejecuciones deben ser simultáneas o en la misma sesión. Ejecutar un prompt una vez al día durante un mes no cumple este requisito: son 30 mediciones de 30 estados diferentes del sistema (modelo actualizado o estado del backend, contenidos diferentes recuperados en la inferencia, contexto temporal distinto), no 30 mediciones del mismo estado.

Si hay menos de 1 en 100 probabilidades de obtener la misma lista dos veces, una herramienta con 25 prompts no puede darte una imagen representativa de tu visibilidad real, independientemente de cuántas veces ejecute esos 25 prompts.

Aún así, el problema real no es tanto la frecuencia de ejecución, sino la escala y representatividad:

• 25 prompts ejecutados 30 veces cada uno siguen siendo 25 prompts. No representan el universo de queries que los usuarios reales hacen sobre tu sector.
• Los prompts sintéticos inventados por el cliente reflejan lo que el cliente cree que preguntan los usuarios, no lo que realmente preguntan.

SparkToro usó 2.961 prompts con 600 voluntarios para su estudio. Profound usó ~80.000 prompts por plataforma. SISTRIX usa 10 millones por idioma. La diferencia de escala determina si puedes detectar patrones reales o solo ruido estadístico.

Modelo de negocio y estructura de precios

La diferencia más relevante es si el tracking de IA es un producto independiente o una funcionalidad dentro de una suite más amplia.

Herramientas especializadas (tracking como producto principal):

• Otterly: desde $29/mes (15 prompts) hasta $489/mes (400 prompts)
• Peec AI: €89/mes por 25 prompts hasta $217/mes (100 prompts)
• Promptwatch: $89/mes (50 prompts), $199/mes (150 prompts), $499/mes (350 prompts)
• Waikay: desde $19,95/mes (120 prompts) hasta $444/mes (4.000 prompts)
• Profound: desde $99/mes
• SE Visible: desde $99/mes (150 prompts) hasta $355/mes (1.000 prompts)
• Gumshoe: $0,10 por conversación (pago por uso)

Suites con tracking incluido o como add-on:

• SISTRIX: desde $140/mes con AI Research incluido (50M prompts, 5 idiomas, 3 chatbots). Acceso a base de datos compartida y tracking de prompts personalizados.
• Ahrefs Brand Radar: desde $199/mes por plataforma individual o $699/mes por todas las plataformas (Google AI, ChatGPT, Perplexity, Copilot, Gemini). Incluye 271M queries/mes del dataset de Ahrefs + 2.500 custom prompts/mes (por un extra de $50).
• Semrush AI Visibility: $99/mes por dominio como add-on, o incluido en Semrush One desde $199/mes. Base de datos de 239M+ prompts; tracking personalizado de 25-50 prompts según plan.
• Conductor: estimado $10.000-50.000 anuales (orientado a Fortune 500)

El coste de ejecutar 100 prompts diarios con GPT-4o-mini es ~$2,04/mes. Los márgenes de las herramientas especializadas oscilan entre 85-95%.

Como dice Kevin Indig: "Tracking is a feature, not a company." Y su argumento no es que medir sea inútil, es que el tracking no es defendible como negocio porque se comoditiza. Amplitude ofrece monitoring en LLM gratis, Semrush lo añadió como checkbox, Sistrix lo incluye por defecto... Las plataformas establecidas absorben el tracking como feature y matan a los standalone. Eso es exactamente lo que está pasando.

Dirás: "pero Ahrefs también empezó como rank tracker." Sí, con dos diferencias. Primera: el rank tracking tradicional tenía un moat real y una correlación demostrada con tráfico orgánico y conversiones. Segunda: precisamente porque el rank tracking se commoditizó, esas empresas sobrevivieron convirtiéndose en suites completas.

Las herramientas que dependen únicamente del tracking de IA como producto tienen incentivos para exagerar su valor y para abusar del desconocimiento del cliente. Como he escrito antes, lanzar 50 prompts para "medir tu visibilidad en IA" es como hacer una encuesta electoral preguntando a tus amigos. Aunque estén bien escogidos y sean 50 prompts especializados en tu industria equivaldrían a 2-15 datos independientes según Anthropic. Necesitas millones de prompts para extraer patrones significativos. Eso solo pueden hacerlo herramientas como SISTRIX, Ahrefs o Semrush que operan a escala masiva.

Es más, Rand Fishkin calificó las respuestas de IA como "loterías estadísticas" y este mercado alcanzará los $200 millones en 2026, con "casi cero ROI".

En conversaciones privadas con varios founders de prompt trackers que me han pedido ayuda para desarrollar su tool y que no he citado aquí (algunos ya con inversiones millonarias), he encontrado un patrón preocupante y es que muchos desconocían problemas metodológicos básicos como la diferencia entre prompts sintéticos y derivados de demanda real, api vs interfaz, la posibilidad de comprar datos de prompts, o las limitaciones estadísticas que he documentado aquí, entre otras cosas. Algunos me reconocieron que "por algo hay que empezar". Otros ya han pivotado con su tool al darse cuenta de la magnitud del problema. Es decir, el mercado se está construyendo más rápido de lo que se está entendiendo.

Y, a día de hoy, cualquiera puede montar una herramienta de tracking en un fin de semana. Hasta puedes hacerte la tuya propia en un momento con FireGEO open-source. Creo que muchas tools de seguimiento de IA buscan aprovecharse del desconocimiento técnico, el FOMO y el hype para ganar dinero en este momento de incertidumbre.

First-party tools: Bing AI Performance

Todas las herramientas anteriores son third-party, es decir, ejecutan prompts desde fuera e intentan inferir lo que pasa dentro. Bing Webmaster Tools ha lanzado AI Performance, el Search Console de la IA, donde es el propio Microsoft diciéndote qué contenido citó Copilot y Bing AI en respuestas generadas para usuarios reales. Ofrece:

• Pages Cited: qué URLs de tu sitio fueron citadas en respuestas de IA, con frecuencia por página.
• Grounding Queries: las frases que el sistema usó al recuperar tu contenido. No son los prompts exactos del usuario, sino agrupaciones temáticas, pero son la primera aproximación real a saber para qué consultas te citan.

Esto elimina de golpe varios problemas que afectan a las herramientas externas: no hay desfase de versiones (mide el modelo que usan los usuarios reales), no hay problema de API vs scraping (son datos internos del sistema), no hay prompts sintéticos (refleja actividad real), y distingue citaciones visibles de grounding interno (solo reporta lo que el usuario ve). Datos reales, del sistema real, sobre usuarios reales.

Limitaciones importantes:

• Solo cubre Microsoft Copilot y Bing AI.
• Los datos son agregados y muestreados, no un log completo de cada citación, por lo que actividad muy baja puede no aparecer.
• Los grounding queries son frases generalizadas, no los prompts exactos que escribieron los usuarios.
• No mide tráfico, clicks ni conversiones. Una citación no implica que el usuario hiciera nada con tu enlace.
• No calcula rankings, authority ni visibility scores. Solo cuenta citaciones y ni tan mal.

La dirección lógica es que el resto de proveedores siga este camino. Google ya tiene infraestructura similar con Search Console y sería natural que extienda el informe de rendimiento a AI Overviews y AI Mode. OpenAI podría hacer lo mismo para ChatGPT para search ads. Hasta que eso ocurra, Bing AI Performance es el único dato de primera parte disponible para visibilidad en IA.

Por qué las métricas de visibilidad en la IA actuales no funcionan

Visibility score

Franco advierte que "no hay herramienta en el mercado con insight 100% preciso sobre lo que los usuarios escriben en herramientas de IA. Cualquier visibility score reportado es modelado, no medido."

El problema fundamental es que cada herramienta usa una fórmula diferente.

• Geneo calcula: presencia × 0,5 + prominencia × 0,3 + clicks esperados × 0,2
• Advanced Web Ranking asigna: posición 1 = 100%, posición 2 = 90%... posición 10 = 10%.
• Surfer usa menciones de marca ÷ respuestas IA analizadas.
• RankForLLM evalúa 7 categorías de 0-5 sobre un total de 35 puntos.

Cuatro fórmulas completamente diferentes. Un visibility score de 45 en una herramienta no significa nada comparado con un 45 en otra. Y ninguna te dice si ese número es "bueno" o "malo" porque no hay benchmark universal contra el que comparar. Dirás: "bueno, lo que importa es el trend y quedarte con una tool". He trabajado con varias herramientas y he obtenido trends distintos tanto para mi cliente como para los competidores. No hay correlación entre ellas.

Share of Voice

Cassie Clark documenta que esta métrica no asigna peso por posición o prominencia, no correlaciona con clicks o conversiones (las respuestas de IA satisfacen la intención sin requerir click), no combina múltiples prompts en un score compuesto. Es decir, mide presencia, no impacto.

Incluso LinkedIn, con acceso a datos propietarios de tráfico LLM hacia sus propias webs, reconoce que el reto está en el dark funnel y que no pueden cuantificar cómo la visibilidad dentro de respuestas LLM impacta el bottom line.

Pero hay un problema más básico y es que el cálculo depende de quién defines como competidor. La fórmula típica es: menciones de tu marca ÷ menciones totales (tu marca + competidores). Si añades un competidor nuevo a tu lista, tu Share of Voice baja automáticamente sin que haya cambiado nada real en el mercado. Si quitas uno, sube. El denominador es completamente arbitrario.

Además, el SoV varía significativamente entre plataformas porque una marca puede tener 20% en ChatGPT pero solo 10% en Copilot. ¿Cuál es tu "verdadero" Share of Voice? No hay respuesta.

En publicidad tradicional, el Share of Voice tiene una relación demostrada con cuota de mercado. En LLMs, esa correlación no se ha demostrado y menos la conexión con outcomes de negocio

Ranking position

El concepto de "posición" en una respuesta de IA carece de sentido. En una respuesta de 500 palabras que menciona 5 fuentes, ¿quién es "posición 1"? ¿La primera fuente mencionada? ¿La más citada? ¿La que aparece en el primer párrafo? SEO Testing confirma que "como los outputs de LLMs varían por sesión, modelo y formulación exacta del prompt, no hay un 'Posición 1' universal como había con el tracking de keywords."

Como vimos en el estudio de SparkToro, hay menos de 1 en 1.000 probabilidades de obtener la misma lista de marcas en el mismo orden. La posición es esencialmente aleatoria. Sin embargo, el porcentaje de aparición (cuántas veces aparece una marca en múltiples ejecuciones) puede ser más estable y potencialmente útil como métrica.

Prompt volume

Varias herramientas muestran métricas de "AI Search Volume" o "Prompt Volume" que dan apariencia de demanda real, pero esto es completamente modelado.

Semrush muestra "Related Topics AI Volume" que define como "estimated monthly AI search activity", es decir, una estimación, no datos reales. Ahrefs es más honesto: "No existen datos reales de demanda. Ninguna compañía tiene acceso a datos de volumen de búsqueda reales para ChatGPT."

Este problema del volumen de búsqueda es peor que en SEO tradicional porque:

• En Google, el volumen de búsqueda se basa en datos reales de queries (aunque agregados)
• En LLMs, nadie fuera de OpenAI, Google o Anthropic sabe qué preguntan los usuarios
• Los prompts trackeados suelen ser más específicos y de cola larga que las búsquedas tradicionales, así que incluso si hubiera datos, los volúmenes serían menores
• La propia monitorización cambia drásticamente el resultado: ejecutar el mismo prompt desde una cuenta de herramienta infla el volumen de forma desproporcionada.

Citations

Desambiguación

Hay un problema técnico que afecta a todas las métricas anteriores y es la detección de marca. "Stradivarius" puede ser la marca de ropa o el violín (o su creador). "Apple" la tecnológica o la fruta. "Corona" la cerveza, el virus, dental, solar, monárquica... ¿ves mi punto?

La mayoría de herramientas no hacen desambiguación de entidades, hacen simple string matching, es decir, buscan si aparece "Stradivarius" en la respuesta sin analizar el contexto. Esto genera falsos positivos que inflan artificialmente las métricas de visibilidad. Si tu marca comparte nombre con algo popular en otro dominio, tu visibility score puede incluir menciones que no tienen nada que ver contigo.
SISTRIX trabaja activamente en detección de marca contextual para resolver este problema, pero es una limitación que la mayoría de herramientas ni siquiera mencionan.

Hidden links

Existe otro problema técnico que afecta directamente a la fiabilidad de las métricas de citations. RESONEO identificó en el código de ChatGPT tres tipos distintos de URLs:

• Citations: enlaces visibles al final de las frases + panel de fuentes. Máxima visibilidad para el usuario.
• Other Sources: sección "Más" debajo de las citations. Visibilidad media.
• Hidden Links: URLs que ChatGPT usa internamente para grounding pero que nunca se muestran al usuario. Visibilidad cero.

Como comenta Olivier: "Los estudios que muestran Arxiv o YouTube como 'dominios más citados' probablemente no distinguieron entre citaciones reales y URLs de grounding interno invisibles."

Mi apuesta: El tracking de prompts masivo

Antes de nada quiero aclarar que incluso las herramientas con millones de prompts tienen un problema fundamental porque cada una usa un corpus diferente. SISTRIX trackea 10 millones de prompts por idioma, Ahrefs ~190 millones globales, Semrush 239 millones. Pero no son los mismos prompts.

Esto significa que la "visibilidad" de tu marca en SISTRIX no es comparable con la de Ahrefs o Semrush. Cada herramienta te dará un número diferente porque están midiendo universos distintos. No hay forma de saber cuál está "más cerca de la realidad" porque ninguna tiene acceso a los prompts reales de los usuarios.

Otro problema que tiene es que para clientes de nicho o marcas poco conocidas es muy probable que no encuentres nada en ellas.

GAPs por topics

Eso sí, estas herramientas de escala masiva para mi sí son útiles para algo concreto: detectar posibles gaps de visibilidad por topics. Si Ahrefs te muestra que tu competidor aparece en en un cluster de prompts sobre "software de contabilidad para autónomos" y tú no, eso es una señal que merece la pena investigar, independientemente del número exacto de visibilidad. La clusterización por temas permite identificar áreas donde tu contenido no está siendo citado, aunque el "score" absoluto sea arbitrario. En ocasiones he encontrado que el cluster realmente no estaba cubierto o, si lo estaba, tenía problemas accesibilidad o estructura. Puedes leer más sobre esto aquí:

1. Trocear contenido para IA y SEO
2. Agentes web y la importancia del HTML semántico y accesible
3. Extracción de contenido HTML en LLMs con search tool
4. Tráfico agéntico: así navegan los agentes de IA y qué tienes que saber tú
5. SEO para IA: Guía práctica para que tu PYME sea citada en los LLM
6. No es GEO ni AEO es sólo SEO: cómo hacer SEO para la IA

Pero también es cierto que, si ese topic no estaba cubierto, lo podrías habrías detectado haciendo un keyword GAP de toda la vida. Ahora bien, hay un caso donde estas herramientas sí aportan algo que el keyword gap tradicional no puede y es cuando la cita no proviene de tu dominio, sino de un tercero que te menciona.

Mira este ejemplo: para la query "mba abroad" desde India, IESE aparece mencionado en el AI Overview. Pero si revisas las 9 fuentes citadas, ninguna es iese.edu, son sitios de terceros que mencionan a IESE en sus rankings o comparativas.

Esto significa que la visibilidad de IESE en este contexto depende de su reputación en el ecosistema, no de su propio contenido. Un gap de keywords comparando iese.edu contra esade.edu nunca te mostraría esto, porque estás comparando URLs propias, no menciones externas.

En ese sentido, estas herramientas funcionan más como un monitoreo de menciones contextualizado por intent que como un análisis SEO clásico. Te permiten ver dónde tu marca aparece (o no) en el "grafo de conocimiento" que el LLM ha construido a partir de múltiples fuentes y no solo de tu sitio.

Herramientas como Sistrix o Ahrefs también permiten monitorizar tus propios prompts personalizados. A mí personalmente no me resulta útil por las razones que he explicado, pero seamos realistas: siempre hay clientes a los que el jefe del jefe les pide "el informe de visibilidad de X prompts". Aunque sepas que las métricas absolutas no son fiables, al menos con estas herramientas tienes esa necesidad cubierta sin tener que montar algo desde cero.

Además me gusta su honestidad:

• SISTRIX reconoce que "la situación de datos para análisis LLM/IA son actualmente incluso más desafiantes que en Google o Amazon." Comparan el momento con los "primeros días del análisis de Google". Ofrecen su módulo de IA en beta gratuita sin prometer resultados de optimización. De hecho, el CEO de SISTRIX me confirma que están alejándose del concepto de "single prompt rankings" por carecer de validez estadística por la alta volatilidad y que están trabajando en Prompt Clustering como enfoque estratégico
• Ahrefs Brand Radar documenta sus limitaciones: "No existen datos reales de demanda. Ninguna compañía tiene acceso a datos de volumen de búsqueda reales para ChatGPT." Admiten que "la atribución sigue siendo desafiante, trackear conversiones directas desde menciones de IA es casi imposible."

Datos de primera parte

Antes de Google Search Console, el mercado también dependía de herramientas externas que estimaban rankings y tráfico. La aparición de datos de primera parte no eliminó las herramientas externas, pero sí redefinió su rol porque pasaron de ser la fuente principal a ser complementos para análisis competitivo.

Si Google extiende Search Console a AI Overviews y AI Mode, y OpenAI ofrece algo similar para ChatGPT con search, el valor de las herramientas third-party de tracking se reducirá aún más a lo que ya he defendido, que es al análisis competitivo de gaps por topics a escala masiva, no medición de "tu" visibilidad con prompts sintéticos.

Conclusión

El mercado de herramientas de AI visibility tracking es una industria construida sobre fundamentos cuestionables. Las respuestas de LLMs son, por diseño, probabilísticas y personalizadas (lo opuesto de lo que se necesitaría para una medición precisa).

No argumento que no haya que medir. Argumento que hay que entender qué estás midiendo, con qué limitaciones y a qué escala tiene sentido.

Los rankings son esencialmente aleatorios. El porcentaje de visibilidad agregado puede tener cierta validez si ejecutas suficientes repeticiones, pero las APIs dan resultados diferentes a las interfaces reales, la personalización hace imposible replicar la experiencia del usuario, y ninguna herramienta tiene acceso a las búsquedas reales que hacen los usuarios en chatbots LLM. Los procesos internos de chatbots IA como el de Google (query fan-out, reranking, SAGE) son técnicamente imposibles de replicar desde fuera, la mayoría de herramientas no distinguen entre conocimiento interno y retrieval  (algo que determina si puedes actuar o no), y el % de visibility es paradójicamente más estable para las marcas que ya son conocidas y menos lo necesitan.

Con márgenes brutos del 85-95%, el valor que capturan los vendors supera con creces el que entregan a los clientes. Este mercado vende certidumbre donde solo existe incertidumbre. Quien compre estas herramientas debe saber que está adquiriendo indicadores débiles y para nada verdades absolutas.

La entrada Herramientas para medir visibilidad en IA: Lo que no te cuentan los Prompt Trackers se publicó primero en Natzir Turrado.

En concreto, expliqué que usar prompts en formatos estructurados como JSON o YAML ayudan a guiar al modelo con mayor precisión, porque en lugar de texto plano, se presentan claves y valores que establecen parámetros claros.

• Ventajas: Claridad (reduce ambigüedad), flexibilidad (múltiples parámetros), consistencia (formato uniforme) y escalabilidad (fácil integración en flujos automáticos o APIs).
• Limitaciones: Curva de aprendizaje y posible rigidez que reduce la creatividad del modelo en tareas abiertas.

Pero con el tiempo y con la evolución de los modelos, me he dado cuenta de que no siempre es mejor trabajar de esta manera para todas las tareas. Así que me he propuesto ver si es cosa mía o si existe literatura reciente al respecto y a qué conclusiones llega.

Aquí os comparto el análisis de los principales estudios.

Resumen ejecutivo

La evidencia científica muestra que el formato sí influye significativamente en el rendimiento de los LLMs, pero su impacto varía según el tipo de tarea, el modelo utilizado y el tipo de restricción aplicada.

Hallazgos principales

1. Does Prompt Formatting Have Any Impact on LLM Performance?

He et al., 2024 - arXiv:2411.10541

Metodología

Evaluaron cuatro formatos (texto plano, Markdown, JSON, YAML) en modelos GPT-3.5 y GPT-4 usando benchmarks de razonamiento en lenguaje natural, generación de código y traducción.

Resultados

• Variación de hasta 40%: GPT-3.5-turbo mostró variaciones de rendimiento de hasta 40% en tareas de traducción de código dependiendo del template utilizado.
• Robustez de modelos grandes: GPT-4 es significativamente más robusto a estas variaciones que GPT-3.5.
• Preferencias de formato: GPT-3.5-turbo prefiere JSON, mientras que GPT-4 favorece Markdown.
• No hay formato universal: Ningún formato es óptimo para todas las tareas y modelos.

2. Let Me Speak Freely? A Study on the Impact of
Format Restrictions on Performance of Large Language Models

Tam et al., 2024 - EMNLP Industry Track

Metodología

Compararon respuestas en formato libre vs. formatos estructurados (JSON, XML, YAML) en tareas de razonamiento y clasificación usando múltiples LLMs incluyendo GPT-4o, Claude, Gemini y LLaMA.

Resultados

• Degradación del razonamiento: Las restricciones de formato estructurado (especialmente JSON-mode) reducen significativamente las capacidades de razonamiento de los LLMs en un 10-15%.
• Restricciones más estrictas = Mayor degradación: Cuanto más estricta es la restricción de formato, mayor es la pérdida de rendimiento en tareas de razonamiento.
• Clasificación vs. Razonamiento: Las tareas de clasificación se benefician de formatos estructurados, pero las de razonamiento sufren.
• Solución propuesta: Usar un enfoque de dos pasos: primero generar respuesta libre, luego convertir a formato estructurado.

3. Which Nested Data Format Do LLMs Understand Best?

Improving Agents, 2025

Metodología

Evaluaron GPT-5 Nano, LLaMA 3.2 3B y Gemini 2.5 Flash Lite con datos anidados en JSON, YAML, XML y Markdown usando 1.000 preguntas con datos Terraform-like de 6-7 niveles de anidamiento.

Resultados

• YAML fue superior: Para GPT-5 Nano y Gemini, YAML produjo los mejores resultados. LLaMA mostró poca sensibilidad al formato.
• Markdown más eficiente: Markdown usó 34-38% menos tokens que JSON, siendo la opción más eficiente en costes.
• XML el peor rendimiento: XML requirió 80% más tokens que Markdown y tuvo peor precisión en la mayoría de modelos.
• JSON problemático: JSON tuvo rendimiento pobre con GPT-5 Nano y Gemini, sugiriendo evitarlo como formato por defecto.

4. Prompt Engineering for Structured Data

Elnashar, White & Schmidt, 2025 - Artif. Intell. Auton. Syst.

Metodología

Compararon seis estilos de prompt (JSON, YAML, CSV, Function Calling APIs, prefijos simples, híbrido CSV/Prefix) en ChatGPT-4o, Claude y Gemini midiendo precisión, coste de tokens y tiempo de generación.

Resultados

• Diferencias entre modelos: Claude logra mayor precisión consistentemente; ChatGPT-4o es el más eficiente en tokens y tiempo; Gemini ofrece un balance.
• Trade-offs: Formatos más simples reducen coste y tiempo con poca pérdida de precisión; formatos expresivos ofrecen más versatilidad para datos complejos.
• Limitación común: Todos los LLMs luchan con datos narrativos no estructurados (ej: historias personales) con precisión ~40%.

5. Estudios complementarios

5.1 FormatSpread (Sclar et al., ICLR 2024)

Propusieron una metodología para cuantificar la sensibilidad de LLMs a cambios de formato. Encontraron diferencias de hasta 76 puntos de precisión en LLaMA-2-13B por cambios menores como espacios, puntuación o mayúsculas.

5.2 Mind Your Format (Voronov et al., 2024)

Evaluaron 21 modelos (770M a 70B parámetros) en 4 datasets de clasificación. Demostraron que una mala elección de template puede reducir el rendimiento de los mejores modelos a nivel de adivinanza aleatoria. Propusieron Template Ensembles como solución.

5.3 TOON Format (2025)

TOON (Token-Oriented Object Notation) es un nuevo formato estructurado diseñado para eficiencia de tokens. En el benchmark original, TOON logró 73,9% de precisión vs 69,7% de JSON usando 39,6% menos tokens.

Pero ojo, porque estos datos provienen de los benchmarks propios del repositorio TOON, que presentan limitaciones metodológicas relevantes. Tests independientes de Improving Agents sitúan a TOON en posición 9 de 12 formatos (47,5% de precisión) con GPT-4.1-nano, por debajo de JSON (52,3%) y lejos de Markdown-KV (60,7%). Con datos anidados y GPT-5-nano, TOON quedó último (43,1%) frente a YAML (62,1%) y JSON (50,3%). Un análisis con datos reales de facturación confirma que el ahorro de tokens real ronda el 25% (no el 30-60% promocionado) y que TOON no mejora la precisión del modelo. En resumen: el ahorro de tokens existe pero es más modesto, la ventaja de precisión no se sostiene fuera de los benchmarks oficiales, y su utilidad se limita a arrays uniformes de objetos en pipelines de alto volumen. Para datos anidados o complejos, YAML y Markdown siguen siendo mejores opciones.

Síntesis: ¿Cuándo influye el formato?

Conclusiones

1. El formato SÍ importa: La evidencia científica es clara en que el formato del prompt tiene impacto significativo en el rendimiento, con variaciones de hasta 40-76% en precisión.
2. El impacto es contextual: No hay un formato universalmente óptimo. El mejor formato depende de tipo de tarea (razonamiento vs clasificación), modelo utilizado y requisitos de coste/latencia.
3. Trade-off razonamiento vs estructura: Existe una tensión fundamental entre obtener salidas estructuradas y preservar capacidades de razonamiento. Para tareas complejas, el enfoque de dos pasos mitiga este problema.
4. Los modelos grandes son más robustos: GPT-4 y modelos similares muestran menor sensibilidad a variaciones de formato que modelos más pequeños.
5. Recomendación práctica: Siempre probar múltiples formatos en tu caso de uso específico. Usar YAML o Markdown para datos anidados, CSV/TSV para tabular, y considerar el enfoque de dos pasos para tareas de razonamiento críticas.

Referencias

• He, J. et al. (2024). Does Prompt Formatting Have Any Impact on LLM Performance? arXiv:2411.10541
• Tam, Z.R. et al. (2024). Let Me Speak Freely? A Study on the Impact of Format Restrictions. EMNLP Industry Track.
• Improving Agents (2025). Which Nested Data Format Do LLMs Understand Best?
• Elnashar, A., White, J. & Schmidt, D. (2025). Prompt Engineering for Structured Data. Artif. Intell. Auton. Syst.
• Sclar, M. et al. (2024). Quantifying LLMs' Sensitivity to Spurious Features in Prompt Design. ICLR 2024.
• Voronov, A. et al. (2024). Mind Your Format: Towards Consistent Evaluation of In-Context Learning. arXiv:2401.06766
• Mizrahi, M. et al. (2024). State of What Art? A Call for Multi-Prompt LLM Evaluation. TACL.

La entrada ¿Influye el formato del prompt (JSON, YALM, TOON, Markdown, XML) en el rendimiento de los LLMs? se publicó primero en Natzir Turrado.

Su lógica es que "como los LLMs funcionan por fragmentos y vectores, vamos a crear URLs ultra específicas para cada posible pregunta para que la IA lo chunkee mejor"

El problema es que esa recomendación asume que Google funciona como una base de datos vectorial sencilla tipo ChromaDB o Pinecone... y no es así.

Hoy vamos a desmontar esta falacia y a explicar por qué el contenido consolidado en una URL sigue funcionando mejor (a menos que la SERP te pida especificidad como veremos al final).

Mito 1: "antes era ranking, ahora es generación"

Uno de los argumentos que más veo últimamente, y promovido en última ocasión por Joshua Budman, es que los buscadores han dejado de hacer ranking para pasar a hacer generación. Lo cual es falso.

El pipeline de un sistema RAG (AI Overviews, ChatGPT...) tiene tres fases. Primero, el buscador recupera documentos candidatos (Recuperación). Luego filtra los mejores según señales de autoridad y relevancia (Selección). Finalmente, el LLM usa esos documentos para construir la respuesta (Generación).

Si tu contenido queda fuera del conjunto de candidatos por falta de señales de ranking clásicas, el LLM nunca lo verá. Da igual lo bonito que sea tu chunk.

Es decir, el pipeline sigue siendo: Recuperación (Ranking/Retrieval) → Selección (Re-ranking/Filtering) → Generación. Si no pasas el filtro de ranking, no existes para la generación y si troceas mal, te llevas de regalo canibalización, duplicidad y señales diluidas.

Además, Budman, en su análisis, elimina las variables de ranking de la ecuación. Curiosamente, el paper original de RAG que él mismo enlaza sí las incluye. Y más curioso es que su propio ejemplo de Zapier (el único que ha usado para demostrar su argumento) muestra la pillar page en posición #1 orgánico, contradiciendo su tesis. Por lo menos él mismo admite que "el SEO clásico sigue ganando por ahora"... ¿entonces por qué hacer tanto ruido?

Mito 2: "penalización por longitud"

También se está argumentando que las páginas largas pierden relevancia matemática frente a las cortas. Vamos a ver qué hay de cierto.

Se está diciendo que BM25 penaliza los documentos largos. En realidad, BM25 (evolución de TF-IDF) introduce un término de normalización por longitud (1 − b + b · |D|/avgdl) cuyo objetivo es ajustar la frecuencia del término en función de la densidad del documento, no castigar documentos largos de forma arbitraria.

Además, Google lleva usando Passage Ranking desde 2020. Esto significa que evalúa y recupera pasajes individuales dentro de una página. No necesitas una página corta para ser recuperable porque el sistema ya extrae los fragmentos relevantes por ti.

Mito 3: "la mezcla semántica ensucia el embedding"

Otra simplificación típica que no para de aparecer es que "si mezclas subtemas en una página, el vector se vuelve impuro y el coseno de similitud (o producto escalar) baja".

En producción, los sistemas no representan una URL compleja como un único vector. Usan segmentación, agregación, múltiples etapas de ranking, y arquitecturas como Late Interaction (ColBERT) o sistemas propios de Google (RankEmbed, DeepRank) que se entrenan con datos de clics y evaluaciones humanas. Todas permiten manejar documentos complejos sin reducirlos a un único vector.

Mito 4: "tienes que chunkear tu contenido para la IA"

Y aquí viene la ironía porque los GEO Bros te dicen que trocees tu contenido para que encaje mejor en los chunks que hacen los LLMs. Pero no sabemos cómo lo hacen. ¿Cortes de 500 tokens? ¿1000? ¿Overlap del 20%? ¿Heurísticas semánticas o por estructura DOM? Nadie lo sabe. Estás optimizando para un algoritmo que desconoces.

Update (9 enero 2026): Danny Sullivan en Search Off the Record ha dicho exactamente esto: no trocees tu contenido en "bite-sized chunks" pensando que así le gusta a los LLMs. Y añade: aunque hoy te funcione, "tomorrow the systems may change". Estás invirtiendo esfuerzo en optimizar para un algoritmo que desconoces y que además va a evolucionar.

Update (26 enero 2026): Perplexity ha reconocido que su motor trocea los textos en fragmentos de apenas 7 tokens para alimentar a su IA, un tamaño tan minúsculo que intentar optimizar para eso es, directamente, perder el tiempo. También confirman que "las mejores prácticas de SEO tradicional siguen aplicando" y que usan una forma de PageRank. Nada nuevo bajo el sol. El SEO clásico sigue funcionando para la IA.

La realidad creo que es mucho más simple: si un humano puede entender un párrafo sin contexto adicional, cualquier sistema de chunking funcionará bien con él. Escribe claro y directo porque el mejor chunking es el que no tienes que pensar.

Qué sabemos del funcionamiento de los buscadores

Para entender por qué el contenido consolidado funciona, debemos de mirar lo que creemos que sabemos de la arquitectura de Google:

• • Navboost "penaliza" tus micro-páginas: Gracias a las filtraciones del juicio antimonopolio sabemos que Navboost es una señal basada en el comportamiento del usuario que se alimenta de clics satisfactorios y largos (long clicks). Si atomizas tu contenido, obligas al usuario a hacer pogo-sticking: entra, no encuentra la info completa, sale, busca otro resultado. Tu métrica de satisfacción se desploma y Navboost hunde tu ranking. El contenido consolidado retiene al usuario y acumula señales positivas.
  • RankBrain agrupa intenciones: RankBrain ayuda a Google a entender que distintas queries tienen la misma intención subyacente. Cuando creas páginas separadas para variaciones semánticas mínimas, estás luchando contra el agrupamiento de intención que hace RankBrain. Google preferirá una URL que satisfaga el centro de gravedad de esa intención agrupada. Yo deduzco además que QBST y Term Weighting son componentes de RankBrain.
  • Query Augmentation y el "Fan-Out": Un reciente estudio de Surfer SEO ha descubierto una correlación del +161% entre ser citado en AI Overviews y rankear para la main query más sus fan-out queries (sub-preguntas). La lectura que tenemos que hacer es que esto valida los Topic Clusters de toda la vida... Google usa Query Augmentation (expansión de consulta), por lo que si tienes una Pillar Page robusta, cubres léxica y semánticamente tanto la query original como sus expansiones. Al consolidar, maximizas tu puntuación en sistemas como RRF (Reciprocal Rank Fusion), que premia a los documentos fuertes tanto en vocabulario como en cobertura temática. Y oye, en ChatGPT y otras IAs que hacen fan-out esto también es así como explico aquí. Y otro dato del estudio es que el 54% de las citas visibles en AI Overviews (posiciones 1-3) rankean orgánicamente. Si quieres estar en las citas que importan, primero tienes que rankear.
  • Information Co-Location en agentes de deep search: El paper SAGE de Google (enero 2026) analiza cómo entrenan a sus agentes para tareas de búsqueda compleja. Identifican que en el 35% de los casos, cuando la información necesaria está co-localizada en el mismo documento, el agente resuelve en un solo hop lo que deberían ser múltiples búsquedas. Otro 21% de las veces, una query bien formulada colapsa varios pasos porque el documento cubre el tema de forma completa. Consolidar contenido semánticamente relacionado reduce la complejidad de búsqueda para los agentes y aumenta la probabilidad de que te usen como fuente.

Si mi análisis no te convence, escucha a lo que acaba de decir Microsoft. El equipo de Bing publicó recientemente un aviso sobre el contenido duplicado o "near-duplicate" en la era de la IA. Dicen que cuando existen varias versiones de la misma página, las señales se vuelven confusas/difusas. ¿Lo podríamos llamar Intent Signal Blurring (difuminado de señales de intención)? Es más fancy que dilución de señales

Cuando troceas un tema en cinco páginas con contenido solapado ("Qué es X", "Ventajas de X", "Cómo usar X"), los LLM tienden a agrupar URLs similares y elegir solo una para representarlas. A menudo eligen la equivocada. Mientras tanto, tus enlaces, clics y autoridad se dividen entre cinco URLs débiles en lugar de concentrarse en una fuerte.

Bing acaba diciendo en el artículo que "para el SEO y la IA, menos es más".

Entonces: ¿qué hacer a día de hoy?

No defiendo las Pillar Pages sin más, lo que defiendo consolidar cuando la SERP (tras ser ordenada por el usuario) lo piden.

Mi regla es analizar la SERP para la queries similares. ¿Google muestra resultados distintos que para la query general?

• Si sí, crea una página específica porque la intención es distinta.
• Si no, o se solapan mayoritariamente, consolida.

Ojo, porque consolidar sin UX es un suicidio. Defender el contenido consolidado no significa defender un "muro de texto" de 5.000 palabras imposible de navegar.

Si gracias a tu autoridad temática logras rankear para una query muy específica (ej: "cuál tiene mejor cámara telf X o telf Y"), pero el usuario aterriza en la cabecera de tu mega-guía y tiene que hacer scroll manual durante dos minutos para encontrar el dato, se va a ir. Y ahí Navboost te matará igual que si tuvieras una página pobre.

Para que la estrategia de consolidación venza a la especificidad de las micro-páginas, tu contenido debe tener una arquitectura de información impecable que permita la recuperación inmediata de la respuesta:

• Anclas HTML y ToC: Vitales. No solo para que el usuario navegue, sino para permitir que Google entienda la estructura y ejecute el Scroll-to-text-fragment (llevando al usuario directo al párrafo resaltado).
• Módulos visuales y semiótica: El usuario no lee, escanea. Si tu sección habla de "Cámaras", usa iconos de cámaras, gráficos de barras o comparativas visuales. El cerebro procesa la imagen 60.000 veces más rápido que el texto. Si el usuario ve una sección de vs., un icono de una cámara y una tabla con "Checks verdes", sabe que ahí está la conclusión sin necesidad de leer nada.
• Tablas y listas > párrafos: Si estás comparando especificaciones, una tabla es infinitamente más eficiente (para el humano y para la extracción de datos del LLM) que tres párrafos de prosa.
• Diseño de respuesta directa: Si una sección responde a una pregunta concreta, ve al grano. Coloca la respuesta en las primeras 2 líneas de la sección. No des rodeos.

Si haces esto bien, consigues lo mejor de los dos mundos y la resolución inmediata de intención del chunk sumará puntos a tu Pilar Page.

Así que deja de optimizar para una base de datos vectorial imaginaria y antigua. Los usuarios no quieren visitar cinco páginas para entender un concepto. Los buscadores no quieren gastar recursos rastreando duplicados. Y los sistemas RAG necesitan fuentes de autoridad que hayan pasado primero el filtro del ranking.

Optimiza para la realidad de los buscadores híbridos con señales fuertes, autoridad consolidada y satisfacción de usuario.

Relacionado:

Los algoritmos de Google al descubierto. Cómo funciona el buscador según documentos filtrados

No es GEO ni AEO es sólo SEO: cómo hacer SEO para la IA

Búsqueda híbrida y su importancia en AI Search: de Google a ChatGPT

Cómo Google define y calcula la Calidad (Q) y la Topicalidad (T) y su influencia en el ranking

Lo que los leaks de ChatGPT nos enseñan sobre SEO para la IA

La entrada Por qué trocear tu contenido es malo para tu SEO y para la IA se publicó primero en Natzir Turrado.

Se probaron 15 variantes de páginas HTML, cada una conteniendo información de productos (nombre, descripción y precio) pero estructuradas de formas radicalmente diferentes. Los resultados revelan patrones interesantes sobre cómo los sistemas de extracción interpretan el contenido web.

Cómo funciona la extracción de contenido en LLMs

Cuando los LLMs hacen scraping de páginas web a través de sus herramientas integradas (como web_fetch en Claude, web tool en ChatGPT...), normalmente no ejecutan JavaScript. Es una petición HTTP simple que descarga el HTML estático del servidor. Esto significa que:

• No se ejecutan scripts de JavaScript
• No se renderizan estilos CSS
• No hay contexto visual/renderizado
• Solo se obtiene el HTML crudo del servidor

Si el sistema usa un navegador sin UI (headless), sí se ejecuta JS y se puede renderizar el DOM dinámico (Puppeteer/Headless Chrome, Playwright). Algunos agentes y scrapers hacen esto explícitamente como Gemini con Googlebot.

Algunos pipelines usan extractores tipo Readability (usado por Firefox Reader View) para detectar el “main content” (basado en heurísticos) y a veces convierten a Markdown con librerías tipo Turndown.js. No obstante, no es universal. Otros (como los basados en APC de Blink, Chromium) generan una representación estructurada del árbol de layout (con texto, imágenes, formularios, geometrías, roles), y luego pueden ofrecer “vistas” como Markdown estructurado o “chunks” de pasajes. No es sólo un “reader mode” simplificado.

Los LLMs no ven el HTML completo. Las heurísticas de extracción filtran lo que consideran "ruido" antes de pasar el contenido al modelo. El proceso básicamente consiste en:

HTML crudo → Algoritmo de detección → Contenido "principal"

Los extractores tipo Readability usan heurísticas documentadas (densidad de texto, link-density, clases/IDs con señales positivas/negativas) y suelen de-priorizar boilerplate (nav/footer/aside), pero no hay una  Además, en pipelines estructurales (APC) la fuente es el layout tree, y el peso proviene de estructura/rol/visibilidad.

El comportamiento de Claude en el experimento es consistente con un extractor heurístico tipo Trafilatura/Readability (filtrado de boilerplate, sensibilidad a cohesión estructural, peso del H1). Anthropic no ha publicado qué librería concreta usa internamente, pero los patrones observados encajan con esa familia de pipelines. Además, he descubierto la abreviatura "traf" en el schema interno del extractor de Anthropic, lo que sugiere (pero no confirma) que sea Trafilatura.

Así que el sistema identifica qué es "contenido principal" usando heurísticas como:

• Densidad de texto en contenedores
• Eliminación de elementos "no-contenido".
• Se eliminan o ignoran elementos considerados "ruido":

// Elementos típicamente filtrados como boilerplate
<nav>, <footer>, <aside>, <script>, <style>, 
<iframe>, <meta>, comentarios HTML

Es uno de los motivos por los cuales ninguna web tool que hace fetch dentro de un LLM lee schema.

Nota: En APC, como decíamos antes, esto se hace a partir del layout tree, la presencia/ausencia depende de visibilidad, rol, y si el contenido es "user-visible", pero los scripts se excluyen explícitamente.

Metodología

Cada archivo HTML contenía la misma información básica de un producto ficticio, pero presentada con diferentes patrones de maquetación:

• Variaciones en el nivel de anidamiento de divs
• Uso de elementos semánticos vs no semánticos
• Diferentes posiciones del precio en el DOM
• Estructuras con listas, blockquotes y elementos de encabezado
• Texto plano con saltos de línea
• Estructuras HTML5 semánticas (article, section, header, footer)

El promp era el siguiente:

Entra en cada una de estas URLs, una detrás de otra, y extrae la información del producto. Responde con el nombre del producto, descripción y precio. Si no encuentras algún campo, pon "vacío":
URL1
URL2
...
Por favor, formatea tu respuesta así para cada URL:
URL: [URLN]
- Nombre del producto: [lo que encuentres]
- Descripción: [lo que encuentres]
- Precio: [lo que encuentres]

Este experimento se ha realizado con Gemini, ChatGPT y Claude en todos sus modelos en producción, en modo de chat temporal (sin memoria persistente). Sin embargo, solo se documentan los resultados de Claude porque en las otras IAs la extracción fue exitosa independientemente de la estructura HTML utilizada.

Para evitar posibles alucinaciones y validar los resultados, se realizó una segunda ronda de pruebas revisando cada URL individualmente. En esta ocasión, se solicitó específicamente que devolviera todo el texto visible en la página. Los resultados fueron idénticos a la primera extracción, confirmando que las limitaciones observadas son consistentes y no producto de errores aleatorios del modelo.

Resultados

Categoría 1: DIVs Anidados

Ejemplo 1a: DIVs anidados básicos

<div>
    <div>
        <div>
            <div>
                <div>TechStore Premium</div>
                <div>Monitor UltraWide 34"</div>
                <div>Resolución 3440x1440, 144Hz, panel IPS con HDR400.</div>
                <div>
                    <div>$899.00</div>
                    <button>Comprar ahora</button>
                </div>
            </div>
        </div>
    </div>
</div>

Resultado:

• Nombre: Monitor UltraWide 34"
• Descripción: Resolución 3440x1440, 144Hz, panel IPS con HDR400.
• Precio: vacío

Ejemplo 1b: DIVs anidados con Schema en microdata

<body>
  <div itemscope itemtype="https://schema.org/Product">
    <div>
      <div>
        <div>
          <div>
            <div itemprop="brand" itemscope itemtype="https://schema.org/Brand">
              <span itemprop="name">TechStore Premium</span>
            </div>
            <div itemprop="name">Monitor UltraWide 34"</div>
            <div itemprop="description">
              Resolución 3440x1440, 144Hz, panel IPS con HDR400.
            </div>
            <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
              <div>
                <meta itemprop="priceCurrency" content="USD">
                <span itemprop="price" content="899.00">$899.00</span>
              </div>
              <button>Comprar ahora</button>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</body>

Resultado:

• Igual que el anterior.

Ejemplo 1c: DIVs más anidados

<div>
    <div>
        <div>
            <div>
                <div>
                    <div>TechStore Premium</div>
                    <div>Monitor UltraWide 34"</div>
                    <div>Resolución 3440x1440, 144Hz, panel IPS con HDR400.</div>
                    <div>
                        <div>
                            <div>$899.00</div>
                            <button>Comprar ahora</button>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

Resultado: Idéntico al anterior, el precio no se extrajo.

Ejemplo 1d: Precio fuera del contenedor principal

<div>
    <div>
        <div>
            <div>
                <div>TechStore Premium</div>
                <div>Monitor UltraWide 34"</div>
                <div>Resolución 3440x1440, 144Hz, panel IPS con HDR400.</div>
            </div>
        </div>
    </div>
    <div>$899.00</div>
    <button>Comprar ahora</button>
</div>

Resultado: Precio no extraído, a pesar de estar en el mismo nivel jerárquico que el contenedor principal.

Ejemplo 1f: Precio con símbolo al final

<div>
    <div>
        <div>
            <div>
                <div>TechStore Premium</div>
                <div>Monitor UltraWide 34"</div>
                <div>Resolución 3440x1440, 144Hz, panel IPS con HDR400.</div>
            </div>
        </div>
    </div>
    <div>899.00$</div>
    <button>Comprar ahora</button>
</div>

Resultado: Precio no extraído, independientemente del formato monetario.

Ejemplo 1e: Precio dentro del contenedor

<div>
    <div>
        <div>
            <div>
                <div>TechStore Premium</div>
                <div>Monitor UltraWide 34"</div>
                <div>Resolución 3440x1440, 144Hz, panel IPS con HDR400.</div>
                <div>$899.00</div>
            </div>
        </div>
    </div>
    <button>Comprar ahora</button>
</div>

Resultado:

• Nombre: Monitor UltraWide 34"
• Descripción: Resolución 3440x1440, 144Hz, panel IPS con HDR400.
• Precio: $899.00

Categoría 2: Elementos Semánticos

Ejemplo 2: Lista UL

<ul>
    <li>CameraWorld</li>
    <li>Cámara Mirrorless Z9</li>
    <li>Sensor full frame 45MP, video 8K, estabilización IBIS de 5 ejes.</li>
    <li>$4,599.99</li>
    <li><button>Añadir al carrito</button></li>
</ul>

Resultado: Extracción completa exitosa. Las listas proporcionan una estructura clara y secuencial.

Ejemplo 3: Blockquote

<blockquote>
    <cite>AudioTech Solutions</cite>
    <q>Micrófono Podcast Pro USB</q>
    <p>Patrón cardioide, filtro pop integrado, monitoreo zero-latency.</p>
    <strong>$229.90</strong>
    <button>Ordenar</button>
</blockquote>

Resultado: Extracción completa. Claude no filtra <blockquote> <cite> o <q>.

Ejemplo 4: Headers desordenados

<h6>SmartHome Express</h6>
<h3>Termostato Inteligente WiFi</h3>
<h5>Control desde app, programación automática, ahorro energético del 30%.</h5>
<h4>$179.00</h4>
<h2><button>Comprar producto</button></h2>

Resultado: Extracción completa, a pesar del orden no semántico de los encabezados. Los elementos de encabezado tienen peso suficiente para ser valorados.

Ejemplo 5: Texto plano con BR

<body>
    GamerPro Shop<br>
    Mouse Gaming RGB Elite<br>
    16000 DPI ajustable, 11 botones programables, peso personalizable.<br>
    $89.99<br>
    <button>Agregar</button>
</body>

Resultado: Extracción completa. El texto plano con saltos de línea es fácilmente interpretable como contenido secuencial.

Categoría 3: HTML5 Semántico

Ejemplo 6: Article-Section caótico

<section>
    <article>
        <section>FitTech Wearables</section>
        <article>Banda Fitness Pro 6</article>
    </section>
    <aside>Medición SpO2, sueño, 120 modos deportivos, batería 14 días.</aside>
    <article>
        <section>$149.50</section>
        <button>Adquirir ahora</button>
    </article>
</section>

Resultado:

• Nombre: Banda Fitness Pro 6
• Descripción: vacío
• Precio: $149.50

La descripción estaba en un elemento aside, que parece haberse filtrado.

Ejemplo 7: Article con header y footer

<article>
    <header>
        <p>ElectroGaming Store</p>
        <h1>Consola Retro Arcade Plus</h1>
    </header>
    <p>Emulador con 10,000 juegos clásicos, HDMI 4K, 2 controles inalámbricos incluidos.</p>
    <footer>
        <span>$349.99</span>
        <button>Comprar ahora</button>
    </footer>
</article>

Resultado:

• Nombre: Consola Retro Arcade Plus
• Descripción: Emulador con 10,000 juegos clásicos, HDMI 4K, 2 controles inalámbricos incluidos.
• Precio: vacío

El precio dentro del footer no fue extraído aún siendo válido en esa posición.

Ejemplo 8: Article simple

<article>
    <h1>Tablet Pro Max 12.9"</h1>
    <p>TechDigital Corporation</p>
    <p>Pantalla OLED 120Hz, chip M2, 8GB RAM, compatible con stylus, teclado magnético.</p>
    <p>Precio: <strong>$1,199.00</strong></p>
    <button>Añadir al carrito</button>
</article>

Resultado: Extracción completa exitosa. Estructura simple y clara dentro de un article.

Categoría 4: HTML Tradicional

Ejemplo 9a: HTML tradicional con H3

<div>
    <h3>Smartphone Galaxy Ultra 5G</h3>
    <p><strong>Marca:</strong> PhoneTech Global</p>
    <p><strong>Descripción:</strong> Cámara 200MP con zoom 10x, batería 5000mAh, pantalla AMOLED 6.8", procesador Snapdragon 8 Gen 3.</p>
    <p><strong>Precio:</strong> $999.00</p>
    <button type="button">Comprar ahora</button>
</div>

Resultado:

• Nombre: vacío
• Descripción: Cámara 200MP con zoom 10x, batería 5000mAh, pantalla AMOLED 6.8", procesador Snapdragon 8 Gen 3.
• Precio: $999.00

El nombre del producto en H3 no fue identificado como tal, posiblemente su heurística ignore el H3 dentro de un div.

Ejemplo 9b: HTML Tradicional con H2

<div>
    <p>SportTech Equipment</p>
    <h2>Bicicleta Eléctrica Mountain Pro</h2>
    <p>Motor 750W, batería 48V, autonomía 80km, suspensión delantera, frenos hidráulicos.</p>
    <p>Precio: $2,299.00</p>
    <button>Comprar ahora</button>
</div>

Resultado:

• Nombre: vacío
• Descripción: Motor 750W, batería 48V, autonomía 80km, suspensión delantera, frenos hidráulicos.
• Precio: $2,299.00

Similar al caso anterior, el H2 no fue identificado como nombre del producto posiblemente por el motivo anterior.

Ejemplo 9c: HTML tradicional con H1

<div>
    <p>HomeComfort Store</p>
    <h1>Robot Aspiradora Smart Clean X9</h1>
    <p>Navegación láser LiDAR, mopa integrada, vaciado automático, control por app.</p>
    <span>$649.99</span>
    <button>Añadir al carrito</button>
</div>

Resultado: Extracción completa.

Análisis de patrones y conclusiones

Este análisis tiene implicaciones importantes para desarrolladores web que desean que su contenido sea correctamente interpretado por sistemas automatizados. Se han revelado varios patrones sobre qué estructuras HTML facilitan la extracción de contenido:

1. Cohesión en el contenedor: El contenido relacionado debe mantener el mismo nivel de anidamiento dentro de un contenedor común. Cuando elementos como el precio se colocan en niveles de anidamiento adicionales o fuera del contenedor principal, el sistema de extracción no los asocia correctamente con el resto del producto. La extracción falla no por estar en un div, sino por la ruptura de la cohesión estructural.
2. Jerarquía semántica: Los elementos con mayor peso semántico (H1, article, listas) son reconocidos más fácilmente. El H1 fue identificado como nombre de producto, mientras que H2 y H3 no lo fueron. Esto sugiere que el sistema prioriza los elementos de mayor jerarquía en el documento.
3. Simplicidad estructural: Las estructuras simples y directas (texto plano con BR, listas lineales) tuvieron extracción exitosa.
4. Elementos semánticos específicos: Ciertos elementos HTML5 parecen tener un tratamiento especial:
   • footer: Su contenido no se extrae, probablemente porque se considera metainformación o contenido secundario aunque esté dentro de un article.
   • aside: También parece filtrarse, tratándose como contenido tangencial.
   • header: Su contenido sí se procesa.

Aunque otras IAs como Gemini y ChatGPT no presentaron problemas de extracción en este experimento, esto no significa que podamos ignorar la estructura HTML. La forma en que el "reader mode" convierte el contenido a texto plano tiene un significado semántico que se deriva directamente del DOM. Una página bien estructurada facilita el contexto y la comprensión del contenido, independientemente del modelo que lo procese.

El hecho de que algunos modelos compensen mejor las deficiencias estructurales no elimina la responsabilidad de escribir HTML correcto. Una estructura semántica clara:

• Reduce la ambigüedad interpretativa
• Facilita el contexto para todos los sistemas de extracción
• Mejora la accesibilidad para usuarios con lectores de pantalla
• Garantiza una extracción más consistente y predecible por cualquier sistema de extracción, ya sea un LLM o un buscador.

En definitiva, que tu contenido "funcione" con algunas herramientas no significa que esté bien estructurado. El HTML semántico correcto es una inversión en robustez y compatibilidad futura.

Relacionado

Agentes web y la importancia del HTML semántico y accesible

Tráfico agéntico: así navegan los agentes de IA y qué tienes que saber tú

La entrada Extracción de contenido HTML en LLMs con search tool se publicó primero en Natzir Turrado.