Cómo OVR reconstruyó la arquitectura de schema y cuadruplicó el tráfico orgánico
Plataforma AR/VR + NFT con 200+ páginas corriendo schema Article por default. La mayoría de páginas de marketing eran CSR React, invisibles a los crawlers. La corrección fue estructural en schema, renderizado y profundidad de contenido.
Contexto del cliente
OVR es una plataforma de realidad aumentada y virtual que mapea el mundo en celdas hexagonales con propiedad NFT. Los usuarios compran, venden y construyen experiencias en estas celdas a través del marketplace de OVR. El equipo vino con un producto real, usuarios reales y revenue real pero un sitio web que Google no podía ver completamente.
El sitio estaba construido sobre un SPA React con renderizado del lado del cliente. Las páginas de marketing, páginas de colección NFT y listings de ecosistema todas renderizaban después de que ejecutara JavaScript. El crawler de Google puede renderizar JS pero lo hace en un presupuesto diferido; para un sitio pesado en contenido esto significó que la mayoría de páginas no estaban siendo indexadas confiablemente.
Encima de eso, cada página de contenido emitía schema Article por default. Las páginas de colección NFT (que describen productos digitales con precios floor) estaban marcadas como artículos. Las páginas explicativas a nivel de protocolo estaban marcadas como artículos. El schema estaba incorrecto por diseño en cientos de URLs.
El equipo había estado consiguiendo tráfico branded sólido pero perdiendo en cada consulta de comparación y categoría en su espacio. Búsquedas como "plataforma AR NFT", "NFTs de bienes raíces virtuales" y "marketplace de tierras del metaverso" estaban yendo a competidores con productos más débiles pero fundaciones SEO más fuertes.
El problema
Tres problemas estructurales se agravaban entre sí.
Primero, el modelo de renderizado. Alrededor del 70% de las páginas de marketing y contenido eran CSR React. El presupuesto de crawl de Google para renderizado JS diferido significó que las páginas recién publicadas tomaban semanas para ser indexadas. Los ciclos de actualización también se rompían: editar una descripción de colección NFT requería un re-crawl que a menudo no sucedía hasta el próximo paso mayor de Googlebot. Los sitios competidores corriendo SSR o SSG estaban siendo indexados en días mientras OVR estaba siendo indexado en semanas.
Segundo, el problema de schema. Yoast estaba instalado y emitía schema Article en cada post type por default. En el inventario encontramos:
- Páginas de colección NFT: marcadas como Article (deberían ser ItemList + Product)
- Páginas por celda: marcadas como Article (deberían ser Place + Cryptocurrency)
- Páginas de marketplace: marcadas como Article (deberían ser Service + Offer)
- Página de información de token: marcada como Article (debería ser Cryptocurrency + FinancialProduct)
- Páginas de build/develop: marcadas como Article (deberían ser Service)
Tercero, las páginas de colección NFT eran delgadas. La mayoría listaba bajo 500 palabras de copy genérico con el floor price hardcodeado como texto estático. Los floor prices cambian cada hora. Data obsoleta en páginas con schema incorrecto le decía a Google que el contenido era tanto no estructurado como obsoleto. Mala combinación.
El impacto combinado: el tráfico orgánico era una fracción de lo que la base real de usuarios del producto y el reconocimiento de marca deberían haber estado generando. El equipo sabía que algo estaba mal pero la naturaleza multi-capa del problema hacía difícil apuntar a una sola cosa.
La auditoría
La auditoría de TG3 tomó dos semanas y produjo una lista priorizada de 47 problemas en schema, renderizado, profundidad de contenido y enlazado interno.
Hallazgos de mayor impacto:
La migración de schema fue la mayor oportunidad única. Los templates en WordPrensa estaban emitiendo Article por default. Reemplazar esos templates con schemas apropiados al tipo (FinancialProduct para páginas de token, Servicio para marketplace, Place + Cryptocurrency para páginas de celda, ItemList + Producto para colecciones) habilitaría elegibilidad para rich results en cientos de páginas sin tocar una sola pieza de contenido.
El problema de renderizado CSR tenía dos caminos viables: reconstrucción completa SSR o migrar páginas de marketing/contenido a SSG manteniendo la aplicación real (el marketplace, el visor de celda) como CSR. Recomendamos el segundo camino porque preservaba toda la superficie de producto interactiva mientras corregía las páginas SEO-críticas.
Las páginas de colección NFT necesitaban expansión. Recomendamos un objetivo de 1,500-2,000 palabras por colección mayor con floor prices en vivo traídos de la API del marketplace de OVR y re-renderizados cada hora vía SSG con ISR (incremental static regeneration). El fallback estático siempre tendría un floor price reciente; la actualización dinámica lo mantendría fresco.
El enlazado interno era delgado. Las páginas de marketing no enlazaban a listings del ecosistema. Las páginas del ecosistema no enlazaban de vuelta. No había índice /ecosystem/. Construir uno con sub-páginas categorizadas (creadores, colecciones, ubicaciones) capturaría consultas long-tail que la arquitectura existente se perdía.
FREE WEB3 AUDIT
Consigue el mismo tipo de auditoría para tu sitio.
Ejecuta la misma auditoría Crawlux en tu dominio crypto. Primera auditoría gratis, informe PDF completo.
Primera auditoría gratis · Sin registro · 60 segundos · Full PDF report
El trabajo
Migración de schema en 200+ páginas
Construimos un documento de mapeo de schema cubriendo cada patrón de URL en el sitio. Cada patrón fue asignado a un tipo de schema target (FinancialProduct, Servicio, Place, Cryptocurrency, ItemList) y la migración corrió template por template a través del backend de WordPrensa.
La emisión Article default de Yoast fue sobrescrita vía el filtro wpseo_schema_graph_pieces para cada post type afectado. Inyección JSON-LD personalizada lo reemplazó con el tipo correcto. El wrapper @graph nos dejó apilar BreadcrumbList y FAQPage en cada página limpiamente. Construimos un filtro PHP por template afectado en lugar de un override general porque algunas páginas Article legítimas (los blog posts reales) necesitaban seguir emitiendo schema Article.
El documento de mapeo tenía cuatro columnas: patrón de URL, schema actual, schema target, complicaciones. La mayoría de filas eran directas. Páginas de colección → ItemList + Product. Información de token → FinancialProduct + Cryptocurrency. La columna de complicaciones capturó los casos edge: páginas de colección donde algunos items estaban ligados a ubicación del mundo físico (celdas) y otros eran puramente virtuales (avatares), páginas por celda donde las celdas no tenían NFT asociado todavía, colecciones archivadas que habían sido retiradas pero mantenidas indexadas por historial SEO.
Antes de la migración: solo una pequeña minoría de páginas tenía schema apropiado a su tipo de contenido. Después de la migración: la mayoría de páginas sí. El pase de validación atrapó una docena de casos edge que recibieron tratamiento a medida en lugar de tratamiento general. El Validador de Schema.org, Google Rich Resultados Test y Bing Markup Validator todos pasaron limpios dentro de la segunda iteración.
Migración CSR React → Next.js SSG
No reconstruimos el sitio entero. La aplicación de marketplace se quedó como CSR porque ahí es donde los usuarios interactúan con sus wallets y data en vivo. Migramos solo las páginas de marketing, las páginas de colección NFT, el directorio de ecosistema y las secciones de help/docs a Next.js con generación estática más ISR para las páginas de colección dependientes del floor price.
Esto mantuvo intacta la superficie real de producto del equipo de dev mientras movía el contenido SEO-crítico a un modelo de renderizado que los crawlers podían parsear en la primera request. ISR con una revalidación de una hora nos dio cargas iniciales static-fast con actualizaciones de floor price cada hora.
El contenido crawleable pasó de aproximadamente 30% de las páginas a efectivamente todas. La latencia de indexación de primer paso cayó de semanas a días.
Expansión de página de colección NFT
Cada colección mayor recibió un rewrite de contenido. El objetivo eran 1,500-2,000 palabras cubriendo: origen de la colección y creador, temas y estética, celdas notables incluidas, actividad de mercado secundario, enlaces a otro trabajo del creador y cómo adquirir.
El bloque de floor price en vivo se volvió una feature de structured data. Traído de la API del marketplace de OVR en build time, mostrado prominentemente con un timestamp "last updated". Schema-tagueamos el floor price como una oferta Producto con priceValidUntil configurado a la próxima ventana ISR.
Este único cambio causó el mayor cambio individual de ranking. Las páginas de colección que habían estado luchando para posicionar para su propio nombre de colección empezaron a posicionar para consultas a nivel de categoría ("NFTs de bienes raíces virtuales", "colecciones de celdas AR").
Construcción de directorio de ecosistema
Construimos /ecosystem/ como un índice categorizado de todo lo que sucede en OVR. Categorías: creadores, ubicaciones, experiencias, colecciones, infraestructura. Cada categoría recibió su propia página con comentario editorial más un grid filtrado. Páginas por creador y por colección apiladas encima.
El schema ItemList + Servicio a lo largo del directorio capturó un volumen sustancial de consultas long-tail que la arquitectura anterior se perdía completamente. Cosas como "experiencias AR en Milán", "creadores OVR para seguir", "eventos virtuales Berlín" todas empezaron a posicionar dentro de los primeros 90 días.
También construimos el flujo /ecosystem/submit/ para que nuevos creadores pudieran aplicar para inclusión. La revisión manual mantuvo la calidad alta mientras señalizaba a Google que el directorio estaba activo y creciendo.
Resultados
Dentro de 90 días de que la migración completa saliera en vivo, los resultados titulares:
El tráfico orgánico más que se cuadruplicó. El lift no estaba distribuido uniformemente. Las páginas de marketing vieron ganancias modestas. Las páginas de colección NFT y páginas del directorio de ecosistema generaron la mayoría del volumen nuevo.
La indexación se volvió confiable. Las páginas publicadas después de la migración fueron indexadas dentro de unos pocos días en lugar de semanas. La cola "Discovered, not indexed" de Search Console se encogió dramáticamente.
Las páginas elegibles para schema pasaron de una pequeña minoría a la mayoría. Las mejoras de rich result (Preguntas frecuentes, Sitelinks Search Box, BreadcrumbList) aparecieron en la nueva arquitectura.
La captura long-tail creció sustancialmente. Cientos de patrones de consulta nuevos empezaron a generar tráfico, mayormente del directorio de ecosistema y las páginas de colección expandidas.
La migración se pagó a sí misma dentro del primer trimestre solo en valor de tráfico. La conversión a signups de producto (la métrica que importaba al equipo de OVR) se levantó junto con el tráfico pero con un lag porque el funnel de compra toma semanas para compras NFT de alta consideración.
5 lecciones tácticas que puedes aplicar
Las migraciones de schema le ganan a los rewrites de contenido en ROI
En 200+ páginas, cambiar templates de schema tomó dos semanas de trabajo de dev. La misma capacidad de dev gastada en rewrites de contenido habría tocado tal vez 30 páginas. Las migraciones de schema escalan; los rewrites de contenido no. Cuando estás schema-roto a escala arquitectónica, corrige el schema primero.
El renderizado híbrido le gana al SSR puro para plataformas Web3
El SSR puro habría creado nuevos problemas con integraciones de wallet y display de data en vivo. El CSR puro era el problema original. SSG para contenido + CSR para aplicación es la arquitectura correcta para casi cualquier plataforma Web3 con una superficie de producto significativa.
ISR más API en vivo le gana al renderizado completamente dinámico
Los floor prices cambian cada hora. Actualizarlos vía ISR con una revalidación de 60 minutos nos dio cargas iniciales static-fast con freshness cada hora. Los crawlers ven HTML estático. Los usuarios ven precios actuales. El patrón de doble propósito funciona para cualquier data sensible al tiempo en un sitio estático.
Los directorios de ecosistema deben ser profundos en categorías no solo project-listed
Un directorio de ecosistema con 200 proyectos en una lista plana captura menos tráfico long-tail que los mismos 200 proyectos en 5 sub-páginas categorizadas con comentario editorial. La categorización captura consultas de categoría; las páginas por proyecto capturan consultas branded. Construye ambas.
Captura una baseline AEO antes de empezar el trabajo
Medimos citas AEO después de la migración y vimos mejora clara pero no pudimos atribuirla limpiamente a cambios específicos porque la baseline pre-migración faltaba. Siempre captura tasas de citas baseline en tus top 10-20 consultas antes de empezar cualquier proyecto SEO mayor.
El takeaway de AB
El engagement de OVR reforzó algo que ya creíamos: el schema es la palanca de mayor ROI en SEO Web3. La mayoría del otro trabajo SEO es incremental. La migración de schema es estructural. Cuando pasas de incorrecto a correcto en cientos de páginas, el lift compone en cada tipo de consulta tocando esas páginas.
La decisión CSR-a-SSG fue polémica. Algunos en el equipo de OVR querían una reconstrucción SSR completa para una arquitectura "más limpia". Empujamos de vuelta fuerte porque la aplicación marketplace genuinamente necesitaba CSR para interacciones de wallet y data en vivo. El renderizado híbrido (SSG para contenido, CSR para aplicación) es el patrón correcto para la mayoría de plataformas Web3. Ir SSR puro habría creado nuevos problemas mientras resolvía los viejos.
Si hubiéramos tenido que elegir una sola cosa para hacer primero con presupuesto limitado, habría sido schema. La migración CSR-a-SSG aceleró la indexación pero la migración de schema generó los rankings. El orden importa.
Lo que haríamos diferente
Dos cosas en retrospectiva.
Primero, habríamos corrido un test baseline de tasa de citas AEO antes de empezar. Medimos citas AEO después de la migración y habían mejorado claramente pero no pudimos atribuir limpiamente la mejora a cambios específicos porque no teníamos una baseline pre-migración. La medición AEO era más nueva entonces; ahora siempre la capturamos antes de que empiece cualquier proyecto.
Segundo, habríamos construido el directorio de ecosistema antes de la migración de schema en lugar de junto a ella. El directorio generó docenas de enlaces internos nuevos a páginas de producto. Hacerlo primero habría significado que la migración de schema saliera en vivo con señales de enlaces internos más fuertes ya apuntando a las páginas migradas. Las hicimos en paralelo lo que funcionó pero secuenciarlas diferente podría haber acelerado el impacto de ranking.
TG3 vino con una tesis clara y ejecutó contra ella. Solo la migración de schema valió el engagement; el directorio de ecosistema ha estado generando tráfico de descubrimiento calificado desde entonces. Entienden SEO crypto a un nivel que la mayoría de agencias no.
Ejecuta una auditoría Crawlux gratis en tu sitio
La auditoría identifica qué problemas de schema, técnicos y AEO están bloqueando tus rankings. El mismo framework de diagnóstico que usamos en OVR.
Ejecutar auditoría gratuita →Playbooks relacionados
Guías pilares
RUN YOUR OWN AUDIT
Mira lo que Crawlux encuentra en tu sitio.
Estos resultados vienen de la misma auditoría que puedes ejecutar gratis en tu propio dominio. Turnaround de 60 segundos.
Primera auditoría gratis · Sin registro · 60 segundos · Full PDF report