Qué pasa después de migrar: 8 días de retornos compuestos
Migré mi blog a Next.js y pensé que lo más difícil había terminado. Luego comenzó el efecto compuesto — 6 megaguías, un asistente de IA más inteligente, newsletter nativo, protección contra bots y una revisión de SEO en 8 días.
Hace ocho días, reconstruí todo el backend de mi blog en 4 días. Migré 485 posts de WordPress a Next.js, volví a dar vida a Sydney (mi chatbot de IA) y lancé un sitio en producción.
Pensé que esa era la historia. Migración hecha, a celebrar y seguir adelante.
Estaba equivocado. La migración no era el destino — era la línea de salida.
Así es como se veía mi sitio el 5 de febrero vs hoy:
| Característica | 5 feb (Día de la migración) | 13 feb (Hoy) |
|---|---|---|
| Posts del blog | 485 (migrados de WordPress) | 492 (6 nuevas megaguías) |
| Sydney AI | RAG básico, calidad sin comprobar | Evaluado, optimizado, 81% de tasa de aciertos |
| Newsletter | Embed de Beehiiv (terceros) | Nativo con Supabase + Resend, basado en intereses |
| SEO | Sitemap básico + meta tags | Datos estructurados, esquema FAQ, llms.txt, AEO |
| Seguridad | Solo limitación de velocidad | Cloudflare Turnstile + limitación de velocidad |
| Rendimiento | Comprobaciones básicas de Lighthouse | Perfilado sistemático con Chrome DevTools MCP |
| Imágenes destacadas | Creación manual | Pipeline generado por IA (Gemini + auto-optimizar) |
Cada una de esas mejoras ocurrió porque la anterior la hizo más fácil. Ese es el efecto compuesto que no esperaba.
El desbloqueo: Tu blog es ahora código
Esto es lo que nadie te cuenta sobre migrar de WordPress a un stack basado en código: la migración en sí no es el punto. El punto es lo que se vuelve posible después.
Cuando tu blog son 492 archivos MDX en un repositorio Git en lugar de filas en una base de datos MySQL, todo cambia:
- Cada post es un archivo — Claude Code puede leerlos, buscarlos y modificarlos a escala
- Cada cambio es un diff — puedes revisar exactamente qué cambió, en 50 posts a la vez
- Cada característica es componible — tu sistema de newsletter puede leer los mismos metadatos de posts que tu chatbot de IA
- Cada despliegue es un comando —
pnpm build && vercel --prod, listo
Con WordPress, actualizar 12 posts del blog significaba iniciar sesión en wp-admin, hacer clic en cada uno, hacer cambios, actualizar, repetir. ¿Con archivos MDX y Claude Code? Podía decir "añade un enlace al post pilar de parques nacionales en las 12 guías de parques existentes" y leería cada archivo, añadiría el enlace cruzado correcto en el contexto adecuado y me mostraría el diff. Las 12 actualizaciones en minutos.
Este es el desbloqueo. No la migración. La velocidad que viene después.
Seis megaguías en 4 días
¿Lo primero que construí después de la migración? Contenido. Mucho.
Llevaba meses queriendo escribir guías completas para expats — el tipo de posts pilares de 2.000-4.000 palabras que realmente ayudan a la gente a navegar el caos de mudarse a EE. UU. WordPress lo hacía doloroso. Cada post requería formato manual, subida de imágenes, configuración del plugin de SEO, gestión de categorías.
¿Ahora? El pipeline se ve así:
- Lluvia de ideas sobre la estructura y el esquema del post
- Escribir el MDX completo con optimización SEO/AEO integrada
- Generar imagen destacada — Claude lee el post, escribe un prompt, lo envía a Gemini para generar la imagen
- Optimizar — script de Python convierte a WebP, comprime para web
- Subir a Vercel Blob
- Publicar —
git push,vercel --prod,pnpm db:publish - Sydney lo sabe de inmediato — el post se sincroniza con Supabase con embeddings
Esto es lo que salió en esos 4 días:
| Post | Tema | Palabras |
|---|---|---|
| Guía de Salud | HSA, FSA & HDHP explicados | ~3.200 |
| Construcción de crédito | De cero a puntuación 720+ | ~3.500 |
| Ahorro e inversión | T-Bills vs HYSA desglosado | ~2.800 |
| Recompensas de tarjetas de crédito | Estrategia de puntos, millas, cashback | ~3.000 |
| Guía de reubicación | Manual completo de mudanza a EE. UU. | ~3.800 |
| Parques nacionales | 26 parques, 4 viajes por carretera | ~4.200 |
Cada post sigue el mismo patrón AEO: aperturas con la respuesta primero, tablas comparativas, secciones de 120-180 palabras, definiciones en negrita, esquema FAQ al final. El tipo de estructura que obtiene un 340% más de citas de IA.
La guía de parques nacionales fue la más grande — un post pilar que enlaza de vuelta a 12 reseñas de parques existentes. También construí un componente PhotoGallery para ella, porque desplazarse por 20 imágenes individuales era agotador. Ahora es una cuadrícula limpia con un lightbox. Simple, pero efectivo.
Sydney se volvió más inteligente
Cuando volví a poner en marcha a Sydney durante la migración, funcionaba — y la probé manualmente antes del lanzamiento. Podía responder preguntas, encontrar posts relevantes, citar fuentes. Pero las pruebas manuales solo te dicen "esto parece bien". No te dicen qué tan bien, ni dónde están los vacíos, ni cómo mejorar.
No tenía una forma sistemática de medir la calidad — y sin medición, no tenía forma de mejorar.
Así que construí un framework de evaluación de RAG. 32 consultas de prueba en 12 categorías, cada una con resultados esperados que curé a mano. Preguntas como "¿Qué tarjetas de crédito deberían obtener los expats?" deberían devolver la guía de construcción de crédito. "Cuéntame sobre Yosemite" debería devolver el reporte del viaje a Yosemite.
Luego probé 30 combinaciones de configuración diferentes — 6 umbrales de similitud × 5 recuentos de resultados — y medí la tasa de aciertos, precisión y diversidad temporal.
Los resultados fueron reveladores:
| Métrica | Antes (Predeterminado) | Después (Optimizado) |
|---|---|---|
| Tasa de aciertos | ~30% | 81,2% |
| Consultas con cero aciertos | 6 de 30 | 0 de 30 |
| Distribución temporal | 1,2 años | 6,7 años |
La corrección más grande fue vergonzosa: el SDK de OpenAI estaba descartando silenciosamente el parámetro dimensions al ejecutarse bajo Next.js. Sydney generaba embeddings de 1.536 dimensiones pero buscaba en un índice de 384 dimensiones. Con razón los resultados eran malos. Cambiar a llamadas directas de fetch() lo arregló de la noche a la mañana.
También amplié el system prompt de Sydney para cubrir todos los más de 490 temas del blog — ahora sabe sobre parques nacionales, tarjetas de crédito, salud y toda la biblioteca de contenido para expats. No solo IA y marketing.
Dos comandos para probarlo tú mismo:
pnpm eval:rag # Probar contra Supabase local
pnpm eval:rag:prod # Probar contra producción
Ahora puedo medir realmente cuándo Sydney se vuelve más inteligente. Ese es el tipo de infraestructura que nunca construyes cuando estás usando WordPress.
SEO y AEO a escala
El SEO en 2026 no solo se trata de Google. Se trata de ser citado por ChatGPT, Perplexity y Claude cuando alguien hace una pregunta que tu contenido responde.
Implementé un stack completo de SEO/AEO en un solo fin de semana:
Para búsqueda tradicional:
- Sitemap dinámico (639 páginas indexadas)
- Datos estructurados — esquemas de Person, WebSite, Article, BreadcrumbList, FAQPage
- Feed RSS para sindicación
- Google Search Console verificado
Para motores de IA (AEO/GEO):
llms.txt— una guía de contenido prioritario para rastreadores de IA (GPTBot, Claude-Web, PerplexityBot todos permitidos enrobots.txt)- Patrón de respuesta-primero en cada apertura de sección (declaración clave en negrita en las primeras 150 palabras)
- H2s en formato de pregunta que coinciden con cómo la gente pregunta a los asistentes de IA
- Secciones FAQ detectadas automáticamente y renderizadas como esquema FAQPage
Para rendimiento:
Usé Chrome DevTools MCP para perfilar diferentes tipos de páginas — página de inicio, listado de blog, posts individuales, la página /ask — e identifiqué cuellos de botella. Poder ejecutar un rastreo de rendimiento, analizar los resultados y arreglar el problema en la misma sesión de Claude Code es... increíblemente eficiente.
¿El resultado? Cada nuevo post que escribo obtiene automáticamente datos estructurados, esquema FAQ (si tiene una sección de FAQ) y está formateado para extracción por IA. Sin plugins. Sin configuración manual. Así es como funciona el sitio ahora.
Beehiiv fuera, newsletter nativo dentro
Este me sorprendió. Tenía un newsletter funcionando en Beehiiv. Recolectaba emails. Enviaba actualizaciones. ¿Por qué reemplazarlo?
Tres razones:
- Control — Quería suscripciones basadas en intereses. Los suscriptores de "IA y Tecnología" no deberían recibir contenido de parques nacionales. El nivel gratuito de Beehiiv no lo soportaba.
- Integración — Los datos de mis suscriptores ahora viven en la misma base de datos de Supabase que el índice de búsqueda de Sydney. Una única fuente de verdad.
- Costo — Supabase (nivel gratuito) + Resend (nivel gratuito para bajo volumen) = $0/mes.
El sistema que construí:
- Double opt-in — suscribirse → email de verificación → confirmado → email de bienvenida con recomendaciones personalizadas
- 5 grupos de interés — IA, Vida de Expat, Liderazgo, Marketing, Viajes y Parques Nacionales
- Coincidencia inteligente — las categorías de los posts se asignan automáticamente a los intereses de los suscriptores. Cuando publico una guía de tarjetas de crédito, solo los suscriptores de "Vida de Expat" reciben la notificación.
- Cron diario — Vercel ejecuta un trabajo a las 11 AM PST, encuentra posts de las últimas 48 horas, envía notificaciones dirigidas
- Deduplicación — la tabla
notification_logpreviene emails duplicados, siempre
¿Lo mejor? El formulario de suscripción al final de cada post del blog selecciona automáticamente el interés relevante basándose en la categoría del post. ¿Leyendo un artículo de IA? La píldora de "IA y Tecnología" está preseleccionada cuando te desplazas hasta suscribirte.
Construir esto desde cero suena como mucho trabajo. Fue aproximadamente una tarde de trabajo enfocado. La migración de Supabase, las rutas de API, las plantillas de email y el cron job — Claude Code se encargó del andamiaje mientras yo me enfocaba en la lógica y el texto.
Seguridad: Invisible hasta que la necesitas
Con un chatbot de IA de cara al público y un formulario de suscripción al newsletter, tenía dos endpoints que los bots adoran abusar. La limitación de velocidad ya estaba en su lugar (Upstash Redis, 5 solicitudes por minuto), pero quería una segunda capa.
Aquí entra Cloudflare Turnstile — un CAPTCHA invisible que solo muestra un desafío si sospecha actividad sospechosa. Para el 99% de los visitantes reales, es completamente invisible. ¿Para los bots? Es una barrera.
Lo añadí primero al endpoint /ask (chat de Sydney), luego reutilicé el mismo patrón para /api/subscribe. Misma biblioteca de verificación, misma degradación elegante:
- Sin variables de entorno configuradas → saltar (el desarrollo local funciona sin él)
- La API de Cloudflare está caída → fallo-abierto (el limitador de velocidad es el respaldo)
- Token faltante pero la clave secreta está configurada → rechazar (captura bots que eluden el frontend)
La reutilización es lo que hace que esta sea una historia de efecto compuesto. La integración de Turnstile para el newsletter tardó minutos, no horas, porque la infraestructura ya estaba allí gracias a Sydney.
El efecto compuesto
Esto es lo que no planeé pero que ocurrió de forma natural:
Migración a Next.js (1-5 feb)
└─→ Los archivos MDX permiten a Claude Code leer/modificar contenido a escala
└─→ 6 megaguías escritas con optimización SEO/AEO (6-11 feb)
└─→ El nuevo contenido expone los problemas de calidad de búsqueda de Sydney
└─→ Framework de evaluación de RAG construido, Sydney optimizada (11 feb)
└─→ Más contenido necesita un newsletter (no Beehiiv)
└─→ Newsletter nativo construido en Supabase (12 feb)
└─→ Los endpoints públicos necesitan protección contra bots
└─→ Turnstile añadido a Sydney + suscripción (12-13 feb)
Ninguno de estos fue planificado como una secuencia. Cada uno reveló la siguiente necesidad. La migración hizo que la creación de contenido fuera rápida. La creación de contenido rápida expuso las brechas en la calidad de búsqueda. Arreglar la búsqueda me hizo querer una mejor distribución. Una mejor distribución necesitaba protección.
Ese es el efecto compuesto. Cada mejora no solo añade valor — multiplica el valor de todo lo que vino antes. :)
Y el hilo conductor a través de todo esto: cada pieza de mi sitio es ahora código que puede leerse, probarse y modificarse programáticamente. Ese es el verdadero desbloqueo.
Los números
Porque sé que te lo estás preguntando:
| Métrica | Valor |
|---|---|
| Días desde la migración | 8 |
| Nuevos posts del blog | 7 (incluido este) |
| Nuevas características lanzadas | 6 (newsletter, Turnstile ×2, evaluación de RAG, stack de SEO, PhotoGallery) |
| Posts del blog actualizados | 12+ (enlaces cruzados, correcciones de enlaces rotos) |
| Líneas de código añadidas | ~5.600 |
| Tablas de base de datos añadidas | 2 (subscribers, notification_log) |
| Endpoints de API añadidos | 4 (subscribe, verify, unsubscribe, cron) |
| Aumento de costos | $0/mes (todos los niveles gratuitos) |
Qué sigue
No he terminado. El efecto compuesto no se ha detenido:
- Más guías para expats — estrategia fiscal, cronogramas de visa, comparaciones bancarias. La serie tiene potencial.
- Sydney volviéndose más inteligente — ahora que puedo medir la calidad, quiero llevar la tasa de aciertos por encima del 90%.
- Más análisis profundos sobre construir con IA — las herramientas están evolucionando cada semana. Voy documentando sobre la marcha. (Lo último: construir una app nativa de iOS sin saber Swift y descubrir que la IA te lleva al 60% del camino — el último 40% es donde realmente vive el producto.)
Pero honestamente, lo que más me emociona es seguir escribiendo. Por primera vez en 17 años de blogging, publicar un nuevo post es genuinamente divertido — no una tarea de 45 minutos en WordPress. :D
¿Has experimentado este tipo de efecto compuesto después de una migración o una gran decisión técnica? Me genera curiosidad — ¿cuál fue el primer desbloqueo inesperado que te sorprendió?
Un abrazo,
Chandler
Preguntas frecuentes
¿Qué es el efecto compuesto en el desarrollo web?
El efecto compuesto es cuando cada mejora en tu sitio hace que la siguiente mejora sea más rápida y fácil. Por ejemplo, migrar a un stack basado en código habilitó la creación de contenido asistida por IA, lo que reveló problemas de calidad de búsqueda, lo que llevó a construir un framework de evaluación. Cada paso se construyó sobre el anterior.
¿Cómo optimizas los posts del blog para los motores de búsqueda de IA?
Los motores de búsqueda de IA prefieren contenido estructurado, con respuesta-primero, con encabezados claros y secciones concisas. Las técnicas clave incluyen: declaraciones definitivas en negrita en las primeras 150 palabras, encabezados H2 en formato de pregunta, tablas comparativas, secciones de 120-180 palabras y esquemas FAQ. Estos patrones obtienen hasta un 340% más de citas de IA.
¿Qué es un framework de evaluación de RAG?
Un framework de evaluación de RAG prueba qué tan bien tu asistente de IA encuentra y devuelve contenido relevante. Usa consultas predefinidas con resultados esperados (ground truth) y mide métricas como tasa de aciertos, precisión y diversidad temporal. Esto te permite optimizar sistemáticamente tu configuración de búsqueda en lugar de adivinar.
¿Por qué reemplazar Beehiiv con un sistema de newsletter personalizado?
Un sistema de newsletter personalizado te da control total sobre los datos de los suscriptores, la segmentación basada en intereses y la integración con tu base de datos existente. Al construir sobre Supabase + Resend, obtuve suscripciones basadas en intereses, notificaciones automatizadas y $0/mes de alojamiento — todo integrado con el índice de búsqueda de Sydney.
¿En qué se diferencia Cloudflare Turnstile de los CAPTCHAs tradicionales?
Cloudflare Turnstile es un sistema invisible de detección de bots que solo muestra desafíos a visitantes sospechosos. A diferencia de los CAPTCHAs tradicionales que hacen que cada usuario resuelva acertijos, Turnstile funciona silenciosamente para usuarios legítimos. Usa señales del navegador para detectar bots sin interrumpir la experiencia del usuario.
Todavía programando, todavía aprendiendo, todavía viendo crecer el interés compuesto.
