En este artículo
Encontré un bug en mi propio sitio que ocultaba 87 de 108 páginas de los motores de búsqueda. El sitio se veía normal en el navegador todo el tiempo.
Seguramente ya publicaste algo que se ve bien y aun así los rastreadores lo ignoran.
Este texto recorre esa corrección, más otras cuatro fallas sacadas directo del stack en producción de mangabeira.net, no de una auditoría genérica.
Vas a ver el bug de renderizado, la allowlist de rastreadores de IA y las reglas de schema que evitan que los datos en vivo queden desactualizados. Mi guía de SEO para web3 cubre el resto del clúster.
Qué Significa el SEO Técnico Web3
El SEO técnico para Web3 hace que el contenido de un sitio cripto sea legible, indexable y citable por motores de búsqueda y rastreadores de IA. La mayoría de los frontends Web3 son aplicaciones del lado del cliente con conexión de wallet y datos on-chain en vivo. Las herramientas de SEO estándar nunca se diseñaron para eso.
Cuatro cosas importan más. Si los rastreadores pueden renderizar tus páginas. Si tu contenido vive en un solo lugar, o se dispersa entre un sitio de marketing, una app y un subdominio de documentación.
Si tus datos llevan marcado legible por máquina. Y si ya les dijiste a los rastreadores, incluidos los de IA, qué pueden hacer con lo que encuentran.
El SEO técnico estándar asume un sitio estático con un puñado de rastreadores a considerar. Web3 suma tres presiones: renderizado del lado del cliente, datos en vivo que cambian con cada bloque, y rastreadores de IA que no se comportan en nada como Googlebot.
El Problema de Renderizado: Lo Que Ve Googlebot vs. Lo Que Ven los Rastreadores de IA
Googlebot renderiza JavaScript. Encola tu página, ejecuta el JS e indexa lo que ve. Es más lento que el HTML estático, pero funciona.
GPTBot y ClaudeBot no hacen eso. Obtienen el HTML crudo y no ejecutan nada de JavaScript.
Si tu contenido solo existe después de un renderizado del lado del cliente, esos rastreadores ven una cáscara vacía. Eso es cierto sin importar qué tan bien se vea la página en el navegador.
Encontré esta falla exacta en mi propio sitio el 02/08/2026. Estaba auditando una afirmación de un post de LinkedIn sobre un bug de renderizado de otro proyecto. La auditoría se convirtió en un espejo.
mangabeira.net corre un Cloudflare Worker que entrega snapshots renderizados a rastreadores conocidos, incluyendo Googlebot, GPTBot, ClaudeBot y PerplexityBot. Se activa cuando una solicitud envía un header Accept: text/html. Probado contra las 108 URLs del sitemap, cada ruta pasó: títulos correctos, canonicals y el JSON-LD completo.
El header de la respuesta lo confirmó: x-render-source: cf-worker-snapshot.
Dónde estaba realmente escondido el bug
El Worker estaba enmascarando un defecto en el build de origen. vite.config.ts nunca llamaba a loadEnv(), así que el script de prerender del lado de Node leía process.env.VITE_SUPABASE_URL, siempre undefined en el momento del build. La consulta a Supabase fallaba en silencio, la lista de artículos volvía vacía, y 87 de las 108 rutas del sitemap caían de vuelta al shell de la homepage en el origen. El build pasaba en verde todo el tiempo, produciendo en silencio un sitio incompleto en cada despliegue.
Una revisión en el navegador nunca va a detectar eso. El bug se mantuvo invisible porque el Worker interceptaba el tráfico de rastreadores antes de que llegara al build roto. El build roto seguía siendo el punto único de falla del sistema.
Si el Worker se configuraba mal, o si un nuevo user agent de rastreador se colaba por la allowlist, ese rastreador llegaría al build roto. Vería una homepage con el título equivocado en 87 URLs distintas.
La corrección, publicada el 05/08/2026, fueron dos líneas. Integré loadEnv(mode, process.cwd(), "") en process.env antes de que se construyera el array de plugins de Vite. Lo verifiqué con un clon nuevo: el conteo de prerender pasó de 20 de 108 páginas a 108 de 108.
Una capa de mitigación no es lo mismo que una corrección. El Worker fue buena ingeniería. Pero dejó que un defecto real sobreviviera sin detectarse durante meses, porque nunca fallaba de forma ruidosa.
Si tu sitio es una single-page app, verifica dos cosas. ¿Tu paso de prerender corre contra las variables de entorno de producción? ¿Y tu capa de respaldo, si tienes una, falla de forma ruidosa cuando el origen que protege se rompe?
Arquitectura del Sitio: Sitio de Marketing, App y Subdominio de Documentación
La mayoría de los proyectos Web3 se dividen en al menos tres superficies: un sitio de marketing (proyecto.xyz), una aplicación (app.proyecto.xyz) y documentación (docs.proyecto.xyz). Los motores de búsqueda tratan los subdominios como propiedades relacionadas pero distintas, así que la autoridad de enlaces, la relevancia y el presupuesto de rastreo se dividen entre tres grafos de rastreo en lugar de uno solo.
Veo este patrón constantemente en auditorías de protocolos. Un subdominio termina posicionando en lugar del que el equipo realmente quería que ganara.
Fusionar subdominios no siempre es la solución. Es una decisión grande de infraestructura, con compensaciones reales.
La corrección real es una elección explícita. Decide qué subdominio debe posicionar para qué búsqueda, haz cross-linking de forma deliberada, y apunta las etiquetas canonical hacia la superficie que quieres que gane.
Cuidado con Esto
Un subdominio de documentación a menudo supera al sitio de marketing justo en los términos que marketing quería dominar, porque las páginas de docs son estáticas y densas en texto mientras el sitio de marketing es una app del lado del cliente más pesada. Esa división debe ser una elección deliberada, no un accidente.
El propio frontend de la app, detrás del flujo de conexión de wallet, es un problema diferente: contenido restringido, rutas dinámicas por dirección, estado dependiente de la sesión. No profundizo en eso aquí a propósito. Merece un recurso propio.
Schema para Web3: Estructurando Contenido y Datos en Vivo
El marcado de schema (JSON-LD) le dice a los motores de búsqueda y a los sistemas de IA qué es una página, no solo qué dice. Tres tipos cubren la mayor parte de lo que importa: Article para contenido editorial, FAQPage para secciones de preguntas y respuestas, y Organization para la entidad detrás del sitio.
Este artículo lleva los tres. El FAQ de más abajo está marcado como schema FAQPage, no es solo una lista con estilo.
La parte específica de Web3 son los datos en vivo. Una página que muestra el precio de un token, el TVL o el número de holders solo es precisa por un instante.
Sin una marca de tiempo, un rastreador o un modelo de IA no tiene forma de saber si los números están actualizados. Podrían tener seis meses de antigüedad.
Dos reglas corrigen eso. Marca cada página basada en datos con una fecha visible de "última actualización" cerca del contenido, no enterrada en el pie de página. Actualiza dateModified cada vez que cambian los datos subyacentes, no solo cuando editas el texto alrededor.
Insight clave
Para una máquina, una página de datos de un token sin señal de frescura es lo mismo que una página sin fecha alguna. La frescura tiene que declararse, no darse por sentada.
Control de Rastreo e Indexación: robots.txt, Allowlists de Bots de IA y Content-Signal
El robots.txt cumple dos funciones. Le dice a los rastreadores qué pueden acceder. Cada vez más, también le dice a los rastreadores de IA qué pueden hacer con lo que encuentran.
La mayoría de los proyectos falla en la primera función por accidente. Heredan una plantilla que bloquea rutas de staging, y de paso bloquea /docs o /whitepaper. Revisa el tuyo contra tus rutas reales en producción, y no des por hecho que está bien solo porque vino así de fábrica con el framework.
La segunda función es más nueva, y la mayoría de los sitios todavía no la ha tocado. El 31/08/2026, agregué Content-Signal: search=yes, ai-input=yes, ai-train=yes al robots.txt de mangabeira.net bajo User-agent: *, usando el estándar emergente de contentsignals.org.
ai-train=yes fue una elección deliberada, fuera del valor por defecto. Abre el sitio por completo al entrenamiento de IA, además de la entrada de IA y la indexación de búsqueda. Esa decisión debe seguir tu propia estrategia de citación, no tomarse por omisión.
Dos cosas que revisé y descarté, porque "hacer menos" a veces es la decisión correcta. Headers de respuesta de enlace para un recurso orientado a agentes: todavía no existe ninguno. Registros DNS-AID: requieren DNSSEC, que la zona no tiene.
Infraestructura para un estándar que nadie lee no es SEO técnico. Es ruido que aparenta diligencia.
| Elemento del robots.txt | Qué controla | Error común en Web3 |
|---|---|---|
Disallow |
Qué rutas pueden solicitar los rastreadores | Una plantilla heredada bloquea /docs o /whitepaper por accidente |
| Reglas nombradas para bots de IA (GPTBot, ClaudeBot, PerplexityBot) | Si los rastreadores de IA pueden acceder al sitio | Bloqueados sin revisión, matando la citación en respuestas de IA antes de empezar |
Content-Signal |
Qué pueden hacer los rastreadores con el contenido obtenido (búsqueda, entrada de IA, entrenamiento de IA) | No declarado en absoluto, dejando las preferencias de uso implícitas |
Rendimiento en Frontends con Mucha Wallet
Los Core Web Vitals son una señal de posicionamiento de Google. Los flujos de conexión de wallet perjudican los tres. Los bundles pesados de JavaScript para los SDK de wallet retrasan el largest contentful paint.
Los modales de conexión sin espacio de layout reservado causan layout shift. Los manejadores de eventos de wallet en el hilo principal bloquean la interacción hasta el next paint. No profundizo en corregir eso aquí, ya que es más un problema del frontend del dApp que algo que afecte a todo el sitio.
Aquí va el enfoque a nivel de todo el sitio. Si tus páginas de marketing comparten el bundle de JavaScript con tu app, el peso del SDK de wallet penaliza páginas que nunca tocan una wallet. La corrección está abajo.
Buena práctica
Separa el bundle para que las páginas de marketing y contenido carguen sin dependencias de wallet. Un rastreador esperando por código que no necesita es una corrección de SEO técnico, no solo de rendimiento.
Preguntas Frecuentes
¿Qué es el SEO técnico Web3?
El SEO técnico para Web3 hace que el contenido de un sitio cripto sea legible e indexable por motores de búsqueda y rastreadores de IA. Considera el renderizado del lado del cliente, subdominios divididos, datos on-chain en vivo que necesitan señales de frescura, y permisos explícitos de rastreo mediante robots.txt y declaraciones Content-Signal.
¿Por qué los rastreadores de IA no ven la misma página que ve Googlebot?
Googlebot ejecuta JavaScript antes de indexar una página. GPTBot, ClaudeBot y la mayoría de los demás rastreadores de IA obtienen el HTML crudo y no ejecutan nada de JavaScript. Una app del lado del cliente puede verse completa en el navegador y aun así estar vacía para esos rastreadores, a menos que el contenido exista ya en la respuesta inicial.
¿Necesito un Cloudflare Worker para corregir el renderizado para los rastreadores de IA?
Un Worker que entrega snapshots prerenderizados a rastreadores conocidos es un patrón que funciona, y es lo que corre mangabeira.net. Pero es una capa de mitigación, no un sustituto de un build que prerrenderiza correctamente en el origen. Trátalo como defensa en profundidad, no como la corrección principal, o un defecto de build puede pasar inadvertido durante meses.
¿Cuál es la diferencia entre el SEO técnico Web3 y el SEO para dApps?
El SEO técnico Web3 cubre todo el stack del sitio: renderizado, arquitectura de subdominios, schema, control de rastreo y rendimiento. El SEO para dApps es más específico: la propia interfaz de la aplicación, contenido restringido por wallet, rutas dinámicas por dirección e indexación del subdominio de la app, que necesita un tratamiento propio.
¿Debería abrir mi robots.txt a los rastreadores de IA?
Depende de tu estrategia de citación, pero dejarlo sin declarar es peor. Si quieres que citen tu proyecto en respuestas generadas por IA, GPTBot, ClaudeBot y PerplexityBot necesitan acceso explícito. Una declaración Content-Signal (search=yes, ai-input=yes, ai-train=yes, o una combinación más restringida) hace explícita tu preferencia en lugar de dejarla al comportamiento por defecto de cada rastreador.
Analyst in the Arena · Gabriel Mangabeira
Audita el SEO técnico de tu protocolo antes de que te cueste posicionamiento
¿No sabes qué recibe realmente un rastreador de tu sitio?
Eso es lo primero que pruebo. Mi Web3 Growth Audit cubre el renderizado, el control de rastreo y las correcciones de schema de este artículo, aplicadas contra tu stack en producción.
Conoce el Web3 Growth Audit →Esa es la lección real: el SEO técnico Web3 no es una checklist que resuelves una sola vez. Es un conjunto de supuestos, sobre variables de entorno, sobre qué rastreadores ejecutan JavaScript, sobre lo que dice tu robots.txt. Esos supuestos necesitan reverificarse cada vez que el stack cambia por debajo de ellos.
Para el contexto más profundo del clúster, la guía completa de SEO web3 conecta este texto de vuelta con la investigación de palabras clave, la construcción de enlaces y la citación en AI Overviews.