Saltar al contenido
Doctor SEO

SEO con IA: la IA como herramienta de trabajo

Entrar en el índice de Brave: el Web Discovery Project

Los siete filtros de elegibilidad del cliente del Web Discovery Project de Brave, con un diagnóstico ejecutable y mediciones propias fechadas.

Actualizado el 3 octubre 2026 27 min de lectura

Al terminar esta lección podrás pasar tus URL por la lista de filtros que aplica el cliente del Web Discovery Project de Brave y saber cuáles entrarían en el índice y cuáles se descartan antes de enviar nada. Es una comprobación de infraestructura: se ejecuta contra tus cabeceras HTTP y tu HTML de origen.

El dato que sorprende a casi todo el mundo: según la lectura del código que publicó MERJ en junio de 2026, ese cliente no ejecuta JavaScript nunca y solo respeta noindex y canonical cuando viajan en el HTML, ignorando las cabeceras X-Robots-Tag. Si excluiste una sección con una cabecera HTTP, Google te hizo caso y este cliente no llegó a leerla.

Conviene decir desde la primera línea de dónde sale todo lo que viene después, porque es una sola fuente. Cada umbral de esta página procede de la lectura que hizo MERJ del cliente de código abierto del Web Discovery Project, en el commit f25eb3d, en junio de 2026. MERJ no publica tamaño de muestra porque no es un estudio: es una lectura de código fuente. Eso establece qué hace ese commit y no establece qué hace hoy la infraestructura de producción de Brave.

Esta lección pertenece al nivel 8 del curso, SEO con IA, sobre usar los modelos como herramienta de trabajo; cómo te citan los buscadores con IA se enseña en el nivel 4, GEO y AIO. Está aquí por lo que anotó el estudio que originó el nivel: es una restricción de SEO técnico, no un consejo de GEO; cambia lo que construyes, no lo que escribes. Si el GEO es una disciplina propia o SEO con otro nombre es una discusión abierta en el sector, y esta lección no la resuelve: solo describe cómo está organizado este curso.

Lo que vas a aprender

  • Por qué el índice de Brave es la vía por la que Claude alcanza la web, y desde qué fecha está documentado.
  • Las dos rutas por las que una URL llega al Web Discovery Project: el umbral de 20 usuarios y el atajo del resultado de búsqueda.
  • Los siete filtros de elegibilidad, con su umbral exacto y lo que los rompe en un sitio real.
  • Un diagnóstico ejecutable que pasa una URL por los siete filtros, más dos comprobaciones propias, sin tocar la red.
  • Qué establece una lectura de código fuente y qué medición sigue sin publicarse.

Por qué el índice de Brave decide si Claude puede citarte

Claude alcanza la web a través de Brave Search, y esa dependencia está documentada con fecha: el Trust Center de Anthropic lista Brave Search como subprocesador desde el 19 de marzo de 2025, y turbopuffer desde el 6 de mayo de 2026. La recopilación con esas dos fechas la publicó Xponent21 y la verificó de nuevo el 2 de julio de 2026; no se pudo verificar en vivo el 25 de septiembre de 2026, así que se cita por publicación, autor y fecha, sin enlace.

La consecuencia operativa cabe en una frase: si el índice de Brave no conoce tu URL, Claude no tiene de dónde sacarla. No hay formulario de alta ni una Search Console de Brave donde inspeccionar nada.

Cuánto se parecen las citas de Claude a los resultados de Brave es otra pregunta, con sus propios tamaños de muestra, y se trata en la lección siguiente de este nivel, «Que Claude te cite: la dependencia de Brave». Aquí no aparece ni una cifra de solape, a propósito. Y no conviene confundir este mecanismo con el rastreo (crawling) de Anthropic: que ClaudeBot, Claude-User o Claude-SearchBot aparezcan en tus logs no dice nada sobre tu presencia en Brave. Son los tres agentes del artículo de soporte de Anthropic sobre su rastreo, que no imprime fecha absoluta.

Qué es el Web Discovery Project y de dónde sale lo que sabemos de él

El Web Discovery Project es el mecanismo con el que Brave Search descubre páginas a partir de lo que visitan los usuarios dados de alta en el programa, en lugar de con un rastreo propio que recorra enlaces. El componente que hace ese trabajo es un cliente de código abierto, y por eso se puede leer en vez de deducirlo.

Todo lo que este curso afirma sobre ese cliente viene de un único sitio: MERJ leyó el código en el commit f25eb3d y publicó su lectura en junio de 2026. Ese trabajo no lleva tamaño de muestra, y la razón no es un descuido: una lectura de código fuente no muestrea nada, describe un artefacto concreto en un estado concreto. Decirlo importa porque la costumbre del sector es repetir estos umbrales como si salieran de una medición de campo.

Las dos rutas de descubrimiento: veinte usuarios o un resultado de búsqueda

Según la lectura de MERJ del commit f25eb3d (junio de 2026), una URL llega al Web Discovery Project por dos caminos muy desiguales en coste para quien publica. La primera ruta es la visita directa: hacen falta del orden de 20 usuarios del programa, en redes distintas, visitando la misma página. MERJ describe un esquema de cifrado llamado STAR con un umbral de 20 fragmentos: hasta que no se acumulan esos envíos desde redes diferentes, ninguno es legible. Para una página nueva de un sitio pequeño, ese umbral es inalcanzable.

La segunda ruta es mucho más barata y es la que conviene entender. Basta con que un solo usuario del programa vea tu página en un resultado de Google, Bing, Yahoo o DuckDuckGo: el cliente vuelve a pedir esa URL por su cuenta, tras un retardo aleatorio de entre 1 y 20 minutos, y es esa segunda petición la que se somete a los filtros.

Las dos rutas al índice de Brave y los siete filtros que juzgan la segunda peticiónDiagrama de tres pasos sobre la ruta barata por la que una URL entra en el índice de Brave. Uno, el resultado: basta con que un solo usuario del programa vea tu URL en un resultado de Google, Bing, Yahoo o DuckDuckGo, y si no tienes posiciones en los buscadores clásicos nadie del programa llega a verla. Dos, la segunda petición: el cliente vuelve a pedir esa URL por su cuenta, tras un retardo aleatorio de entre 1 y 20 minutos, y una redirección la descarta ahí mismo porque el cliente no la sigue. Tres, los filtros: es esa segunda petición, y no la visita del usuario, la que pasa los siete filtros de elegibilidad, solo HTTP 200, ninguna redirección, JavaScript nunca ejecutado, directivas leídas solo en el HTML, 10 segundos, 2 MB y 22 caracteres de cadena de consulta, y superarlos no indexa nada por sí solo. La otra ruta exige del orden de 20 usuarios del programa en redes distintas. Todo procede de la lectura que hizo MERJ del cliente de código abierto en el commit f25eb3d, junio de 2026, que no lleva tamaño de muestra porque es una lectura de código fuente y no un estudio.La vía barata al índice de Brave empieza en unresultado de GoogleLa ruta del resultado de búsqueda, frente a los 20 usuarios en redes distintas que exige la otra.1El resultadoUn usuario del programa ve tuURL en un resultado de Google,Bing o DuckDuckGo.QUÉ LA DESCARTASin posiciones en los buscadoresclásicos nadie del programa llega averla.2Segunda peticiónEl cliente vuelve a pedir esa URLpor su cuenta tras un retardo de1 a 20 minutos.QUÉ LA DESCARTAUna redirección: el cliente no lasigue y descarta la URL en el salto.3Los filtrosEsa petición pasa los siete filtros:solo 200, 10 segundos, 2 MB, 22caracteres.QUÉ LA DESCARTACualquiera de los siete. Pasarlos noindexa nada; solo evita el descarte.Nadie ha publicado una medición que contraste este cliente con resultados de indexación observados.Nivel 8 del curso de SEO gratuito. MERJ, lectura del cliente del Web Discovery Project, commit f25eb3d, junio de 2026.doctor-seo.net
La ruta de descubrimiento barata del Web Discovery Project de Brave, y los siete filtros que juzgan la segunda petición del cliente, no la visita del usuario. Fuente única: la lectura que hizo MERJ del cliente de código abierto en el commit f25eb3d, junio de 2026, sin tamaño de muestra porque es una lectura de código fuente y no un estudio.

La conclusión es incómoda para quien esperaba un atajo: estar posicionado en los buscadores clásicos es la rampa de entrada al índice de Brave, y no hay una optimización específica para Brave que se salte ese paso. Dicho de otro modo, el requisito previo es el oficio de siempre, el que define qué es el SEO y qué no es en 2026. Lo que sí está en tus manos es la lista de motivos técnicos por los que esa segunda petición se descarta. El trabajo de base es el del nivel 2, SEO técnico, y el mecanismo general está en cómo funciona Google.

Los siete filtros de elegibilidad, con su umbral exacto

El cliente descarta una URL antes de enviar nada si falla cualquiera de los filtros que MERJ documentó en el commit f25eb3d (junio de 2026). La tabla recoge los siete con su umbral literal.

Filtro Umbral publicado Qué lo rompe en la práctica
Código de respuesta Solo HTTP 200 Un 301 o un 302 en la URL que el usuario vio: el cliente no sigue la redirección, descarta la URL.
Redirecciones Ninguna Versiones sin barra final, http sin migrar a https, o www frente a dominio desnudo.
JavaScript No se ejecuta nunca Cualquier contenido renderizado en el cliente: el HTML de origen llega vacío de texto.
noindex y canonical Solo se leen en el HTML Directivas enviadas por cabecera X-Robots-Tag o por cabecera Link: no se leen.
Tiempo de respuesta 10 segundos Primera visita sin caché en hora punta, o una plantilla que monta la página en el servidor bajo carga.
Tamaño 2 MB HTML con datos incrustados: catálogos completos en JSON, imágenes en base64 dentro del documento.
Cadena de consulta Más de 22 caracteres, rechazada Parámetros de campaña o de filtrado, salvo que el HTML declare un canonical del mismo host.

Los siete umbrales proceden de la misma fuente y la misma fecha, así que envejecen juntos: si el cliente cambia, esta página queda obsoleta en bloque. Y superarlos no indexa nada por sí solo; solo evita que te descarten antes de tiempo.

El diagnóstico: los siete filtros de MERJ y dos comprobaciones propias

Este script comprueba una URL contra los siete filtros que publicó MERJ y, por separado, contra dos comprobaciones propias de doctor-seo.net, y devuelve apta o no apta con el motivo. No accede a la red: trabaja sobre dos ficheros que descargas tú, las cabeceras y el HTML de origen, así que es reproducible sobre una copia guardada semanas atrás. Las constantes de MERJ —2 MB, 10 segundos y 22 caracteres— están arriba del todo.

La separación en dos bloques, con dos encabezados en la salida, es deliberada y conviene entender por qué. Siete de las nueve comprobaciones salen del commit f25eb3d y cualquiera puede contrastarlas abriéndolo. Las otras dos no: el tipo de contenido servido no aparece en la lectura de MERJ, y el umbral de 500 caracteres de texto visible es una invención de este curso que sirve de aproximación práctica a «el cliente no ejecuta JavaScript», porque MERJ no publica ningún umbral de texto. Mezclarlas en una sola lista prestaría a un criterio propio la autoridad de la fuente, que es justo lo que esta lección le reprocha al resto del sector. Ajusta MIN_TEXTO a lo que tenga sentido en tus plantillas: es tuyo, no de nadie más.

Descarga la página con curl, incluidas las redirecciones, y anota el tiempo:

curl -sSL -D cabeceras.txt -o pagina.html -w '%{time_total}\n' \
  "https://tudominio.com/una-url/"

Después ejecuta el diagnóstico sobre esos dos ficheros:

python3 wdp-check.py "https://tudominio.com/una-url/" cabeceras.txt pagina.html --segundos 1.52

Devuelve cuatro clases de resultado. FALLA es una comprobación de bloqueo: el cliente descartaría la URL. DIVERGE señala una directiva que Google respeta y este cliente no lee, así que la URL es apta pero no hace lo que creías. AVISO es informativo. Y N/A aparece en todo lo que depende del cuerpo del documento cuando la URL ya ha fallado por redirección, porque en ese caso el cliente nunca llega a pedir ese cuerpo y medir su peso o su texto sería medir una página que no se descargó.

#!/usr/bin/env python3
# wdp-check.py - dos bloques de comprobaciones sobre una URL. El primero son los siete
# filtros de elegibilidad del cliente del Web Discovery Project de Brave segun la lectura
# de MERJ (commit f25eb3d, jun 2026). El segundo son dos comprobaciones propias de
# doctor-seo.net que MERJ no publica. No accede a la red: trabaja con ficheros locales.
import sys, re, os
from urllib.parse import urlparse

MB2, SEG10, QS22 = 2 * 1024 * 1024, 10.0, 22
MIN_TEXTO = 500  # umbral PROPIO, no de MERJ: aproximacion a "no ejecuta JavaScript"
R = []  # clase: bloqueo | divergencia | aviso | na   ·   fuente: merj | propia

def regla(nombre, ok, detalle, clase='bloqueo', fuente='merj'):
    R.append({'n': nombre, 'ok': ok, 'd': detalle, 'c': clase, 'f': fuente})

def saltos_http(bruto):
    saltos, act = [], None
    for l in bruto.decode('utf-8', 'replace').splitlines():
        if re.match(r'^HTTP/', l):
            act = {'s': l.strip(), 'h': {}}
            saltos.append(act)
        elif act and ':' in l:
            k, v = l.split(':', 1)
            act['h'].setdefault(k.strip().lower(), []).append(v.strip())
    return saltos

def codigo(s):
    m = re.match(r'^HTTP/\S+\s+(\d{3})', s['s'])
    return int(m.group(1)) if m else 0

def texto_visible(h):
    h = re.sub(r'(?is)<(script|style|template|noscript)\b.*?</\1>', ' ', h)
    h = re.sub(r'(?s)<!--.*?-->|<[^>]+>', ' ', h)
    return re.sub(r'\s+', ' ', h).strip()

def analizar(url, ruta_cab, ruta_html, seg=None):
    saltos = saltos_http(open(ruta_cab, 'rb').read())
    html = open(ruta_html, 'rb').read().decode('utf-8', 'replace')
    n = os.path.getsize(ruta_html)
    redirs = [s for s in saltos if 300 <= codigo(s) < 400]
    corte = False

    if redirs:
        regla('200 sin redirecciones', False, '%d hacia %s; se descarta en el salto, no se sigue'
              % (codigo(redirs[0]), redirs[0]['h'].get('location', ['?'])[0]))
        corte = True
    elif not saltos or codigo(saltos[-1]) != 200:
        regla('200 sin redirecciones', False, 'respuesta final %s, solo se acepta 200'
              % (codigo(saltos[-1]) if saltos else 'ausente'))
        corte = True
    else:
        regla('200 sin redirecciones', True, '200 directo, sin saltos intermedios')

    def chk(nombre, ok, detalle, clase='bloqueo', fuente='merj'):
        # tras un corte, el cliente nunca llega a pedir el cuerpo: lo demas no aplica
        if corte:
            regla(nombre, None, 'no aplica: el cliente no llega a pedir el cuerpo', 'na', fuente)
        else:
            regla(nombre, ok, detalle, clase, fuente)

    ult = saltos[-1]['h'] if saltos else {}
    chk('Tamano <= 2 MB', n <= MB2, '%d bytes (%.1f%% del tope)' % (n, n / MB2 * 100))
    if seg is None:
        chk('Respuesta <= 10 s', True, 'no medido: pasa --segundos con %{time_total}', 'aviso')
    else:
        chk('Respuesta <= 10 s', seg <= SEG10, '%.2f s' % seg)

    q = urlparse(url).query
    can = re.search(r"(?is)<link[^>]+rel=['\"]?canonical['\"]?[^>]*>", html)
    href = re.search(r"""(?is)href=['"]([^'"]+)['"]""", can.group(0)) if can else None
    can_url = href.group(1) if href else None
    mismo = bool(can_url) and urlparse(can_url).netloc in ('', urlparse(url).netloc)
    if len(q) <= QS22:
        chk('Cadena de consulta', True, '%d caracteres, por debajo de %d' % (len(q), QS22))
    elif mismo:
        chk('Cadena de consulta', True, '%d caracteres, rescatada por el canonical del mismo host: %s'
            % (len(q), can_url))
    else:
        chk('Cadena de consulta', False, '%d caracteres y sin canonical del mismo host en el HTML' % len(q))

    metas = re.findall(r"(?is)<meta[^>]+name=['\"]?robots['\"]?[^>]*>", html)
    cont = ' '.join(metas).lower()
    chk('Sin noindex en el HTML', 'noindex' not in cont, metas[0][:110] if metas else 'sin meta robots')

    xrt = ult.get('x-robots-tag') or []
    if not xrt:
        chk('Coherencia X-Robots-Tag', True, 'sin cabecera X-Robots-Tag', 'aviso')
    elif 'noindex' in ' '.join(xrt).lower() and 'noindex' not in cont:
        chk('Coherencia X-Robots-Tag', False,
            'noindex solo en cabecera (%s): Google lo respeta, este cliente no' % xrt[0], 'divergencia')
    else:
        chk('Coherencia X-Robots-Tag', True, 'cabecera presente, sin divergencia: %s' % xrt[0], 'aviso')

    if [l for l in (ult.get('link') or []) if 'canonical' in l] and not can:
        chk('Canonical en el HTML', False,
            'canonical solo en la cabecera Link; este cliente solo lee el <link> del HTML', 'divergencia')
    else:
        chk('Canonical en el HTML', True, can_url or 'sin canonical declarado', 'aviso')

    # --- a partir de aqui, criterios propios de doctor-seo.net, no de MERJ ---
    ct = (ult.get('content-type') or [''])[0]
    chk('Content-Type HTML', 'html' in ct.lower(), ct or 'sin Content-Type', 'bloqueo', 'propia')

    raiz = re.search(r"(?is)<div[^>]+id=['\"]?(root|app|__next|__nuxt)['\"]?[^>]*>\s*</div>", html)
    t = texto_visible(html)
    if raiz:
        chk('Texto sin JavaScript', False, 'contenedor de aplicacion vacio: %s' % raiz.group(0)[:70],
            'bloqueo', 'propia')
    else:
        chk('Texto sin JavaScript', len(t) >= MIN_TEXTO,
            '%d caracteres de texto visible en el HTML (minimo propio %d)' % (len(t), MIN_TEXTO),
            'bloqueo', 'propia')

MARCAS = {'bloqueo': 'FALLA', 'divergencia': 'DIVERGE', 'aviso': 'AVISO', 'na': 'N/A'}

def imprimir(fuente, banner):
    print(banner)
    for x in [x for x in R if x['f'] == fuente]:
        print('  [%-7s] %-26s %s' % ('PASA' if x['ok'] else MARCAS[x['c']], x['n'], x['d']))
    print()

def main():
    args = [a for a in sys.argv[1:] if not a.startswith('--')]
    seg = float(sys.argv[sys.argv.index('--segundos') + 1]) if '--segundos' in sys.argv else None
    if len(args) < 3:
        sys.exit('uso: python3 wdp-check.py <url> <cabeceras.txt> <pagina.html> [--segundos N]')
    analizar(args[0], args[1], args[2], seg)
    print('\nURL: %s\n' % args[0])
    imprimir('merj', 'Criterios de MERJ: lectura del cliente del Web Discovery Project de Brave,\n'
                     'commit f25eb3d, junio de 2026. Son los siete filtros publicados.')
    imprimir('propia', 'Criterios propios de doctor-seo.net, NO de MERJ: el tipo de contenido servido y\n'
                       'un minimo de %d caracteres de texto visible como aproximacion a "el cliente no\n'
                       'ejecuta JavaScript". MERJ no publica ningun umbral de texto.' % MIN_TEXTO)
    bloq = sum(1 for x in R if x['ok'] is False and x['c'] == 'bloqueo')
    div = sum(1 for x in R if x['ok'] is False and x['c'] == 'divergencia')
    print('NO APTA: %d comprobacion(es) de bloqueo fallan; la URL se descarta.' % bloq if bloq
          else 'APTA: supera las comprobaciones de bloqueo. No garantiza indexacion: hace falta\n'
               'ademas una de las dos rutas de descubrimiento.')
    if div:
        print('DIVERGENCIA: %d directiva(s) que Google respeta y este cliente no lee.' % div)
    sys.exit(1 if bloq else 0)

if __name__ == '__main__':
    main()

Lo ejecuté el 25 de septiembre de 2026 sobre tres URL de este sitio, el único host del que puedo publicar mediciones de primera mano. La página del nivel 8 pasó los siete filtros de MERJ y las dos comprobaciones propias: 200 directo, 56.962 bytes, un 2,7% del tope de 2 MB, 1,52 segundos frente a los 10 permitidos, canonical en el HTML y 14.175 caracteres de texto visible.

La misma página sin la barra final falló el primer filtro: devuelve un 301 hacia la versión con barra, y el cliente descarta la URL en el salto en lugar de seguirlo. Las otras ocho comprobaciones salieron entonces como N/A, que es lo correcto: el cuerpo que descargó curl es el del destino, no el de la URL que se estaba juzgando. Una redirección de normalización es buena práctica en todas partes menos aquí, y es el caso que más sitios van a encontrarse.

JavaScript, X-Robots-Tag y la redirección 301 ante Google y ante el cliente de BraveTabla de tres prácticas que Google perdona y el cliente del Web Discovery Project de Brave no. Una, el contenido renderizado en el cliente: Google renderiza, con su calendario y sus colas, y acaba viendo el texto, mientras que este cliente no ejecuta JavaScript en ningún momento, de modo que el HTML de origen llega sin texto y la URL se bloquea. Dos, el noindex enviado por cabecera: Google respeta X-Robots-Tag y deja la página fuera de su índice, mientras que este cliente solo lee el meta robots del HTML, así que entras cuando creías haberte excluido, y lo mismo ocurre con el canonical enviado por cabecera Link. Tres, la redirección 301 de normalización, como la de la barra final o la de www: Google la sigue hasta el destino y es el destino lo que indexa, mientras que este cliente no la sigue, descarta la URL en el salto y ya no pide el cuerpo del documento. Todo procede de la lectura que hizo MERJ del cliente en el commit f25eb3d, junio de 2026, una lectura de código fuente sin tamaño de muestra.Tres prácticas que Google perdona y este cliente noLo que respeta Google frente a lo que lee el cliente del Web Discovery Project de Brave.QUÉ HAY EN TU SITIOQUÉ HACE GOOGLEQUÉ HACE ESTE CLIENTE1JavaScript enclienteRenderiza, con su calendario y sus colas, yacaba viendo el texto.No lo ejecuta nunca: el HTML de origen llega sintexto y la URL se bloquea.2noindex porcabeceraRespeta X-Robots-Tag y deja la página fuera desu índice.Solo lee el meta robots del HTML: entras cuandocreías haberte excluido.3Redirección301La sigue hasta el destino y es el destino lo queindexa.No la sigue: descarta la URL en el salto y ya no pideel cuerpo.Los siete umbrales envejecen juntos: si el cliente cambia, esta lista queda obsoleta en bloque.Nivel 8 del curso de SEO gratuito. MERJ, commit f25eb3d, junio de 2026: lectura de código, sin muestra.doctor-seo.net
Tres prácticas correctas en todas partes menos ante este cliente, según la misma lectura de MERJ del commit f25eb3d (junio de 2026). Esa lectura establece qué hace ese commit en esa fecha, y no qué hace hoy la infraestructura de producción de Brave: nadie ha publicado una medición que la contraste con resultados de indexación observados.

El tercer caso fue el índice del curso con ?utm_source=boletin&utm_medium=email: 35 caracteres de cadena de consulta, muy por encima del límite de 22. Pasó igualmente, porque el HTML declara un canonical del mismo host hacia la URL limpia: la excepción que documenta la fuente, comprobada sobre una página real.

Las dos divergencias que salen caras: JavaScript y X-Robots-Tag

De los siete filtros, dos rompen suposiciones que casi todos los equipos de SEO dan por ciertas, y ambos salen de la lectura de MERJ del commit f25eb3d, junio de 2026.

El primero es JavaScript. Google renderiza —con su calendario y sus colas, pero renderiza—, y el sector ha construido una década de prácticas sobre esa base. El cliente del Web Discovery Project, según esa lectura, no ejecuta JavaScript en ningún momento. Para una aplicación de una sola página el HTML de origen es un contenedor vacío: el diagnóstico de arriba, sobre un documento con un <div id="root"></div> y nada más, bloquea la URL por contenido cero. Un sitio que funciona en Google y es invisible en Brave por esta razón no dispara ninguna alarma.

Ese fallo tiene precedente al producir páginas con modelos: Will Scott describió en Search Engine Land, el 28 de agosto de 2026, páginas generadas con Claude que dependían de renderizado en cliente y no llegaban a rendir. Son casos observados, sin muestra ni control, y esa página de Search Engine Land no se pudo verificar en vivo el 25 de septiembre de 2026, así que se cita por publicación, autor y fecha, sin enlace.

La segunda divergencia es la de las directivas por cabecera. X-Robots-Tag: noindex es la forma correcta de excluir un PDF o una exportación que no genera HTML, y Google la respeta. El cliente del Web Discovery Project, según la misma lectura, solo mira el <meta name='robots'> del HTML, y lo mismo ocurre con el canonical enviado por cabecera Link. El efecto es el contrario del que asusta: no es que te quedes fuera, es que entras cuando creías haberte excluido. En las tres URL de este sitio medidas el 25 de septiembre de 2026 no hay cabecera X-Robots-Tag y el canonical viaja en el HTML: aquí no hay divergencia.

Qué no establece esta evidencia

Toda esta lección se apoya en una sola fuente, y repetirlo es la diferencia entre un umbral verificable y un rumor con cifra. Es la lectura de MERJ del cliente del Web Discovery Project en el commit f25eb3d, junio de 2026, y no lleva tamaño de muestra porque es una lectura de código fuente y no un estudio.

Lo que ese método sí establece: que en ese commit, en esa fecha, el cliente comprueba el código de respuesta, rechaza redirecciones, no invoca ningún motor de JavaScript, lee las directivas solo del HTML y corta a 10 segundos, 2 MB y 22 caracteres de cadena de consulta. Lo comprueba cualquiera que abra el mismo commit.

Lo que no establece: qué versión corre hoy en los navegadores de los usuarios del programa, si la infraestructura de producción de Brave aplica esos criterios aguas abajo, qué proporción de URL cae por cada filtro, ni qué efecto tiene pasar o no pasar cada uno sobre la indexación real. Nadie ha publicado una medición que contraste el comportamiento de este cliente con resultados de indexación observados, y esa ausencia es hoy el hueco más grande del tema.

Hay además un asunto que la lectura de MERJ no toca y que esta lección tampoco resuelve: el tratamiento de robots.txt y, detrás de él, si conviene bloquear a los rastreadores de IA. El sector está partido. Una parte sostiene que permitir a los agentes de respuesta es la única forma de aparecer en ellos; otra, que alimentar respuestas sin recibir visitas es una transferencia de valor que hay que negociar o cortar. Ninguna tiene detrás una medición que zanje la discusión, y este curso no dicta sentencia. Ese debate va además de rastreadores identificados por su agente de usuario, que es un mecanismo distinto del descubrimiento por usuarios que describe esta página.

De ahí la única recomendación metodológica de esta página: trata los siete umbrales como hipótesis comprobables sobre tu sitio, no como leyes. Si encuentras una URL indexada en Brave que falla uno de los filtros, esa observación vale más que cualquier repetición del umbral, porque es la medición que falta. Cómo montar ese seguimiento es material del nivel 5, analítica y medición.

Qué cambiar esta semana

Las decisiones que salen de los siete filtros del cliente del Web Discovery Project de Brave son de construcción: buenas prácticas técnicas que, frente a ese cliente, pasan de recomendables a bloqueantes.

  1. Sirve el contenido en el HTML de origen. El cliente de Brave no ejecuta JavaScript: descarga la página con curl y busca un párrafo que veas en pantalla.
  2. Declara canonical y robots en el HTML. Brave solo las lee ahí. Mantén las cabeceras si las necesitas, pero que no sean el único sitio con la directiva.
  3. Difunde la URL que devuelve 200 directo. El cliente no sigue redirecciones, y la URL que vea el usuario del programa es la que se comprueba.
  4. Revisa las URL con parámetros. Cualquier enlace de campaña supera los 22 caracteres. Si tu plantilla emite el canonical correcto estás cubierto; la sección que no lo emita se arregla primero.
  5. Mide peso y tiempo en frío. Los topes de Brave son 2 MB y 10 segundos, medidos sin caché y en hora punta.

Nada de esto es nuevo: es el trabajo del nivel 2 de SEO técnico, salvo que aquí no hay margen, porque un cliente que no renderiza y no sigue redirecciones no perdona lo que Google sí perdona. Qué tareas de este tipo puedes delegar en un modelo se trata en qué puede y qué no puede hacer Claude en SEO.

Errores comunes

  1. Tratar los siete umbrales como hechos permanentes. Salen de la lectura que hizo MERJ del commit f25eb3d del cliente de Brave, en junio de 2026, no de una especificación publicada por Brave. El arreglo: guarda la fecha junto al umbral y vuelve a leer el código antes de rehacer una arquitectura.
  2. Excluir contenido solo con X-Robots-Tag. Google lo respeta y este cliente no lo lee, así que puedes acabar con material en un índice del que creías haberlo sacado. El arreglo: duplica la directiva en el <meta name='robots'> del HTML.
  3. Dar por buena una URL porque «abre bien en el navegador». El navegador sigue redirecciones y ejecuta JavaScript; el cliente no hace ninguna de las dos cosas. El arreglo: curl y el diagnóstico de esta lección.

Resumen

  • Claude alcanza la web a través de Brave Search, subprocesador en el Trust Center de Anthropic desde el 19 de marzo de 2025 (Xponent21, verificado de nuevo el 2 de julio de 2026).
  • Dos rutas de descubrimiento: unos 20 usuarios del programa en redes distintas visitando la página (umbral STAR de 20 fragmentos), o uno solo que la vea en un resultado de Google, Bing, Yahoo o DuckDuckGo, tras lo cual el cliente la vuelve a pedir con un retardo aleatorio de 1 a 20 minutos.
  • Siete filtros descartan la URL antes de enviar nada: solo HTTP 200, ninguna redirección, JavaScript nunca ejecutado, noindex y canonical leídos solo en el HTML (X-Robots-Tag y Link se ignoran), 10 segundos, 2 MB y 22 caracteres de cadena de consulta.
  • Todos proceden de una sola fuente: la lectura de MERJ del cliente en el commit f25eb3d, junio de 2026, sin tamaño de muestra porque es una lectura de código fuente, no un estudio. Nadie ha publicado una medición que la contraste con resultados de indexación observados.
  • Es una restricción de SEO técnico: cambia lo que construyes, no lo que escribes.
  • Medición propia del 25 de septiembre de 2026 sobre tres URL de doctor-seo.net: la del nivel 8 pasa los siete filtros de MERJ y las dos comprobaciones propias con 56.962 bytes (2,7% del tope) y 1,52 segundos; la misma sin barra final falla por un 301; y una con 35 caracteres de parámetros pasa por el canonical del mismo host.

Preguntas frecuentes

Mi sitio es una aplicación de una sola página, ¿me deja fuera?

Según la lectura de MERJ del código del cliente (commit f25eb3d, junio de 2026), el Web Discovery Project no ejecuta JavaScript en ningún momento, así que lo que llega al índice es el HTML de origen tal cual, y una aplicación que monta el contenido en el navegador entrega un documento sin texto. El arreglo es renderizado en servidor o generación estática; no hay una configuración que active el renderizado.

Si pongo X-Robots-Tag: noindex, ¿queda la página fuera del índice de Brave?

Según la lectura de MERJ, no: ese cliente solo respeta noindex y canonical del HTML e ignora las cabeceras HTTP, así que una página excluida únicamente por cabecera sigue siendo apta para él. Declara también el <meta name='robots'> en el HTML.

¿Cuánto tarda una página nueva en aparecer en Brave?

No hay dato publicado que lo responda. La lectura de MERJ documenta un retardo aleatorio de 1 a 20 minutos entre que un usuario del programa ve la URL en un resultado y el cliente vuelve a pedirla, pero eso es el tiempo de esa petición, no el de la indexación. Cualquier cifra que circule no tiene fuente primaria detrás.

Fuentes

Las marcadas (sin enlace) no se pudieron verificar en vivo el 25 de septiembre de 2026; se citan por publicación, autor y fecha.

  • MERJ, lectura del cliente de código abierto del Web Discovery Project de Brave, commit f25eb3d — junio de 2026. Sin tamaño de muestra: es una lectura de código fuente, no un estudio. (sin enlace)
  • Anthropic, Trust Center: Brave Search como subprocesador desde el 19 de marzo de 2025 y turbopuffer desde el 6 de mayo de 2026 — recopilado por Xponent21, verificado de nuevo el 2 de julio de 2026. (sin enlace)
  • Anthropic, «Does Anthropic crawl data from the web…» — ClaudeBot, Claude-User y Claude-SearchBot; la página solo muestra marca de tiempo relativa, sin fecha absoluta.
  • Will Scott, «Use Claude for SEO. Don’t let Claude do SEO.», Search Engine Land — 28 de agosto de 2026. Casos observados, sin muestra ni control. (sin enlace)
  • Medición propia sobre doctor-seo.net — 25 de septiembre de 2026, tres URL, cabeceras y HTML descargados con curl y evaluados con el script de esta página.

Continuar el curso