Escribe el nombre de un protocolo en Google. El primer resultado es el sitio de marketing, nunca la app.
No es casualidad. Los wallet gates y el renderizado del lado del cliente mantienen el producto invisible para los crawlers.
Puliste el copy de marketing. La app, el producto real, sigue sin rankear para nada.
Trata la app y el sitio de marketing como un solo sistema de indexación, y ambos empiezan a rankear. Uniswap, Aave y Curve ya operan con esta división.
Este texto cubre qué pertenece a app.* versus www.*, el contenido detrás de wallet gate, y por qué las páginas de pool y par son el verdadero punto de entrada. También cubre el desorden de URLs de deep link que crean las páginas programáticas.
Es la capa de app-frontend de la guía definitiva de SEO y AEO para Web3. No cubre el pipeline de renderizado de todo el sitio. el texto de SEO Técnico para Web3.
Por qué las dApps son invisibles para la búsqueda por defecto
Una dApp es invisible para la búsqueda por defecto porque su interfaz principal se renderiza después de que se conecta una wallet, y los crawlers de búsqueda no conectan wallets.
La mayoría de los frontends de dApp son single-page apps. El payload de HTML inicial es una cáscara vacía. Todo lo que le importa al usuario carga después de que se ejecuta el JavaScript, y muchas veces después de que una wallet firma una solicitud.
!El sistema de indexación de la dApp: app vs www vs docs
Googlebot no sostiene una wallet ni espera una llamada RPC lenta. Ve lo que se renderiza en el estado desconectado, y nada más. Web3 empeora esto de tres formas:
- El wallet gate aparece antes que un muro de autenticación típico, muchas veces ya en la propia pantalla de entrada de la app.
- El dato es el contenido. El APY de una pool, el TVL de un vault, una funding rate son exactamente lo que buscan los motores de búsqueda, y exactamente lo que queda encerrado detrás de llamadas del lado del cliente atadas a la wallet.
- Los equipos no separan el producto del discurso de venta. El sitio de marketing se queda genérico ("el futuro de X descentralizado") porque el equipo asume que la app eventualmente será encontrada. No lo será, sin una arquitectura deliberada.
Insight clave
La cáscara de la dApp nunca va a rankear. La tarea no es hacer indexable la app, es hacer indexables partes específicas de sus datos en algún lugar que el crawler pueda alcanzar.
La división app/marketing: qué pertenece a cada lado, y cómo fluye la autoridad
Todo protocolo con tracción real termina operando dos propiedades: app.proyecto.xyz (el producto) y www.proyecto.xyz (el sitio de marketing). Tratarlas como un solo sistema de indexación significa ser explícito sobre quién es dueño de qué.
El www.* debe ser dueño de: la homepage y el posicionamiento, páginas de funciones para alguien que no conectó una wallet, y el contenido de docs y blog. También es dueño de cualquier página programática que muestre datos del producto para usuarios sin sesión.
El app.* debe ser dueño de: la interfaz de transacción, todo lo que solo tiene sentido con una wallet, y el estado en tiempo real demasiado rápido para indexar.
El error que comete la mayoría de los equipos es poner todo en app.*, o dejar el www.* con nada más que adjetivos, asumiendo que la app va a hablar por sí sola. Ambos dejan al sitio de marketing sin nada lo bastante específico para rankear en una búsqueda real.
Uniswap opera marketing y docs en uniswap.org, con la interfaz de swap en app.uniswap.org. Aave hace lo mismo: aave.com lleva el posicionamiento y el contenido de gobernanza, mientras que la interfaz de transacción está en app.aave.com.
Curve mantiene su sitio principal en curve.fi, con la interfaz de la app accesible por sus propias rutas. Observaciones estructurales, no afirmaciones de ranking.
La autoridad fluye de www.* a app.* mediante enlaces internos y, más importante, backlinks que caen en el sitio de marketing. Esa es la propiedad sobre la que la gente escribe y a la que cita. Una homepage genérica, sin nada que valga la pena enlazar, deja esa autoridad sobre la mesa.
Atención
Una división en subdominios no comparte automáticamente las señales de ranking como lo harían las subcarpetas. Los enlaces internos deliberados entre `app.*` y `www.*` importan más, no menos.
Contenido detrás de wallet gate: qué ven realmente los crawlers
El muro de conectar wallet no es el problema. No saber qué hay a cada lado sí lo es.
Abre la app en una pestaña de incógnito sin conectar una wallet, y mira qué se renderiza. Eso es lo que ve Googlebot: para muchas dApps, un botón de conectar wallet y nada más. No hay razón para que un crawler asocie esa URL con ninguna búsqueda.
La solución no es desbloquear la app para los crawlers. Es prerrenderizar el estado sin sesión con contenido real en lugar de un muro.
La solución de prerrenderizado, no la de desbloqueo
Nada de esto compromete el wallet gate. Nadie está proponiendo que la app deje a un crawler anónimo ejecutar un swap. El dato que describe lo disponible no debería quedar invisible hasta después de la conexión, porque eso es exactamente lo que la gente busca.
Superficies programáticas: páginas de pool, par y vault como el verdadero punto de entrada
Para la mayoría de los protocolos DeFi y DEX, el tráfico orgánico no llega a la homepage. Llega a una página de pool específica, un par de trading o un vault. Eso es lo que la gente realmente escribe en Google: un par de tokens, el nombre de una chain, una cifra de rendimiento.
Estas páginas programáticas, una por pool, par, vault o mercado, son el verdadero punto de entrada orgánico de la dApp, no la homepage. Un protocolo con 400 pools tiene 400 páginas de destino potenciales, cada una apuntando a una búsqueda de cola larga que pocos competidores están construyendo.
Construir esto bien significa resolver el problema de contenido duplicado que enfrenta cualquier conjunto grande de páginas programáticas. Las páginas comparten una plantilla y difieren solo en los datos, con riesgo de leerse como contenido superficial.
La mecánica de un conjunto de páginas a prueba de contenido duplicado se cubre en el texto de SEO para protocolos DeFi de este clúster. el texto de SEO para Protocolos DeFi.
Lo que importa aquí es más simple: decide temprano si estas páginas viven en app.* o www.*, y prerrenderízalas sin importar cuál gane. Una página de pool que solo se resuelve después de conectar una wallet tiene cero posibilidades de rankear para la búsqueda para la que fue construida.
Deep links al estado de la app: manejo canónico para el caos de parámetros
El estado de la app enlazable por deep link es una ventaja para los usuarios y un problema de canonicalización para la búsqueda. Una URL como app.proyecto.xyz/swap?chain=arbitrum&pool=usdc-eth&ref=abc123 permite compartir una configuración específica. Pero el mismo contenido, la pool USDC/ETH en Arbitrum, se vuelve accesible a través de decenas de permutaciones de parámetros: orden de la chain, tags de referido, parámetros UTM, estados de orden.
Sin control, un crawler puede dividir la señal de ranking entre duplicados, o descartar todo el clúster como de bajo valor.
Tres soluciones cubren la mayor parte de esto:
Canonicalizando el caos de deep links
Esto es una parte de una cuestión más amplia de renderizado y schema. Pertenece al lado de SEO técnico de este clúster, no al texto de app-frontend. el texto de SEO Técnico para Web3.
Qué medir: qué segmentos de GSC realmente reflejan el descubrimiento de la dApp
Una vez que la división está construida y las páginas prerrenderizadas, la pregunta es si está funcionando. GSC es la herramienta principal, y la trampa es mirar el segmento equivocado.
Los clics e impresiones agregados mezclan la homepage, el blog, los docs y cada página de pool en un solo número, que no va a decir si el descubrimiento de la dApp está funcionando. Dos segmentos importan más:
Los dos segmentos de GSC que realmente lo dicen
Un protocolo que solo mira el tráfico de la homepage va a concluir que el esfuerzo no funciona, cuando la señal real está en un segmento que nadie filtró.
El caso de lanzamiento: por qué esto importa también antes del TGE
Todo lo anterior asume un protocolo activo con pools existentes. Las mismas decisiones, app.* versus www.*, prerrenderizar el estado sin sesión, importan igual antes del TGE. La única diferencia: una interfaz de testnet y una lista de espera en lugar de pools activos.
Insight clave
Acertar la división app/marketing antes del lanzamiento significa que el sitio de marketing ya carga la autoridad que necesita en el momento en que las páginas de pool reales salen al aire.
Preguntas frecuentes
¿La interfaz de una dApp puede rankear alguna vez en Google?
Rara vez, y no es el objetivo correcto. La meta realista son las superficies sin sesión y prerrenderizadas a su alrededor: páginas de pool, páginas de mercado y el sitio de marketing.
¿La app y el sitio de marketing deberían estar en el mismo dominio o en subdominios separados?
Ambos funcionan, pero los subdominios son más comunes, ya que los equipos pueden lanzar actualizaciones de la app sin tocar el código del sitio de marketing. La contrapartida: la autoridad no fluye tan libremente entre subdominios como entre subcarpetas, así que los enlaces internos tienen que ser deliberados.
¿Por qué las páginas detrás de wallet gate perjudican el SEO específicamente?
Los crawlers de búsqueda no conectan wallets. Si el contenido relevante, precios, tasas, datos de pool, solo aparece después de conectarse, el crawler indexa una cáscara vacía en lugar del contenido que alguien realmente buscó.
¿Cuántas páginas programáticas de pool o par son demasiadas?
No hay un tope fijo, pero el riesgo sube cuando el número de páginas supera al dato real. Una pool con volumen y datos de tasa genuinos se lee como contenido distinto. Una pool con actividad casi nula y solo una plantilla compartida se lee como contenido superficial y duplicado.
¿Qué debe revisar primero un equipo si el SEO de su dApp no está funcionando?
Abre la app en una pestaña de incógnito sin conectar una wallet, y mira qué se renderiza. Si es un aviso de conectar wallet y nada más, eso es lo que ve también cada crawler, y es la causa raíz detrás de la mayoría de los problemas de descubrimiento de dApps.
Dónde queda la brecha de descubrimiento
Una dApp no necesita volverse rastreable para ser encontrable. Necesita que su equipo deje de tratar la app y el sitio de marketing como problemas separados. El posicionamiento y los datos programáticos pertenecen a www.*, la interfaz de transacción a app.*, y las vistas sin sesión prerrenderizadas donde apuntan las búsquedas reales.
Lee el marco completo en el que se inserta este satélite. La guía definitiva de SEO y AEO para Web3 cubre cómo esta capa de app-frontend encaja junto al stack técnico y la estrategia de contenido por tipo de protocolo.
La auditoría de 6 pilares cubre el pilar de dApp junto con Sitio Web, Social, Comunidad, SEO y PR. Es una lectura asíncrona y acotada sobre dónde está la brecha de descubrimiento de tu equipo: Web3 Growth Audit.