Cómo migrar de Framer a un sitio estático en Vercel asistido por IA

Sacar una web de Framer no consiste principalmente en volver a dibujar rectángulos con CSS. La parte difícil es conservar el sistema invisible alrededor de esos rectángulos: URLs, contenido, metadatos, imágenes, relaciones entre idiomas, redirecciones, analítica y todas las pequeñas suposiciones acumuladas mientras el sitio estaba publicado.

Migré mi portfolio a un proyecto React exportado de forma estática, guardé el blog como archivos, incorporé IA para acelerar la implementación y la revisión, y desplegué el resultado en Vercel. Esta guía explica el proceso que volvería a utilizar.

Si antes quieres entender la decisión y la comparación real de costes, lee Por qué dejé Framer por un sitio estático en Vercel asistido por IA.

La arquitectura de destino

content/articles/       contenido versionado del blog
public/images/          imágenes estáticas
public/audio/           narraciones generadas previamente
app/                    rutas y componentes
lib/content.ts          cargador de contenido
scripts/                migración y generación de metadatos
tests/                  verificaciones del resultado renderizado
dist/client/            sitio estático desplegable

El navegador recibe archivos estáticos. Git conserva la fuente de verdad. Vercel compila el repositorio y publica dist/client. Puede seguir existiendo comportamiento dinámico en el navegador, pero no hace falta un servidor para renderizar un artículo.

Paso 1: inventaría la web publicada antes de tocar código

Crea una lista de todas las URLs importantes. Incluye:

• páginas principales y versiones localizadas;

• todos los slugs del CMS;

• URLs canónicas y metadatos;

• imágenes, descargas, audio y recursos externos;

• formularios e integraciones;

• analítica, etiquetas de verificación y consentimiento;

• redirecciones existentes;

• páginas que ya reciben impresiones o enlaces.

Exporta la colección del CMS de Framer a CSV y conserva intacta la exportación original dentro de una carpeta de backup. Toma capturas de página completa de las rutas importantes en escritorio y móvil. Una captura no es código fuente, pero funciona muy bien como evidencia para detectar regresiones.

Hazlo antes de rediseñar. Migración y rediseño pueden ocurrir juntos, pero necesitas saber si cada diferencia es intencionada.

Paso 2: elige un stack capaz de exportar estático

No necesitas usar mis dependencias exactas. Astro, Eleventy, la exportación estática de Next.js u otro framework pueden funcionar. Los requisitos importantes son:

• una salida determinista por cada ruta pública;

• soporte para metadatos y rutas localizadas;

• un comando de build que falle de forma visible;

• contenido independiente de un editor propietario;

• un directorio final que pueda desplegarse.

Mi implementación utiliza React, Vite y vinext:

npm install
npm run dev
npm run build
npm test

La exportación de producción se activa en next.config.ts:

const nextConfig = {
  output: "export",
};

export default nextConfig;

Como vinext compila mediante Vite, la salida final del cliente queda en dist/client. Ese directorio, no el repositorio fuente, es lo que sirve el hosting.

Paso 3: convierte el CMS en archivos portátiles

Cada artículo de esta web vive en:

content/articles/<slug>/en.md
content/articles/<slug>/es.md

El archivo comienza con front matter estricto y continúa con el cuerpo:

---
slug: "articulo-de-ejemplo"
locale: "es"
title: "Artículo de ejemplo"
description: "Un resumen útil."
date: "2026-08-28T00:00:00.000Z"
draft: false
type: "Blog"
cluster: "framer-cms-technical-seo"
tags: ["Migración", "Sitio estático"]
audio: ""
image: "/images/blog/default-cover.png"
canonical: ""
featured: false
---

<p>El artículo comienza aquí.</p>

Escribí un script de migración para el CSV en lugar de copiar decenas de artículos a mano. El script normaliza slugs, transforma metadatos, conserva drafts, elimina scripts inseguros y eventos inline, y asigna una portada local provisional cuando todavía no existe una imagen migrada.

La regla importante es sencilla: el importador nunca debe ser destructivo. Conserva el CSV original, escribe el contenido generado en otra estructura y procura que ejecutar el proceso varias veces produzca el mismo resultado.

Paso 4: construye un único cargador de contenido

El cargador lee el front matter, devuelve el cuerpo, filtra borradores, ordena por fecha y acepta un idioma. Todos los consumidores deben utilizarlo: índice, páginas de detalle, navegación entre artículos, RSS y sitemap.

Centralizar esta lógica evita un fallo frecuente: que un draft desaparezca del listado pero siga siendo descubrible mediante una ruta generada o el sitemap.

getAllArticles({ locale: "es" })
  .filter(article => !article.draft)
  .sort((a, b) => Date.parse(b.date) - Date.parse(a.date));

La ruta individual debe repetir la comprobación del draft y devolver not found cuando el contenido no sea público.

Paso 5: conserva primero las URLs; ya las mejorarás después

Si el artículo de Framer vivía en /blog/mi-articulo, conserva esa URL salvo que exista un motivo de peso para cambiarla. Una ruta ligeramente más bonita rara vez compensa perder enlaces, menciones e historial de búsqueda.

Si una ruta debe cambiar, añade una redirección permanente en el mismo despliegue:

{
  "source": "/writing/:slug",
  "destination": "/blog/:slug",
  "permanent": true
}

Haz lo mismo al consolidar posts solapados. Mueve el contenido útil al artículo más fuerte, convierte el débil en draft y redirige su URL antigua hacia la página canónica superviviente. No pidas a Google que elimine una URL que debería transferir sus señales mediante una redirección.

Paso 6: reconstruye los metadatos como salida, no como decoración

Una migración visualmente correcta puede ser una regresión de SEO. El build debe producir y verificar:

• títulos y descripciones únicos;

• URLs canónicas autorreferentes;

• atributos de idioma y alternancias recíprocas donde existan traducciones;

• metadatos Open Graph;

• datos estructurados coherentes con el contenido visible;

• robots.txt;

• sitemap.xml;

• rss.xml.

En mi proyecto, un script posterior al build escribe los archivos de metadatos desplegables después de exportar las rutas. Los borradores quedan fuera de las tres fuentes.

Paso 7: trata cada idioma como contenido independiente

Una ruta traducida solo debe existir cuando hay una traducción real. No publiques texto inglés debajo de /es/ esperando que una etiqueta de idioma lo convierta en español.

Este proyecto utiliza una regla explícita:

existe en.md  → publica /blog/slug
existe es.md  → publica /es/blog/slug
falta es.md   → no declara traducción española

El sitemap añade alternancias únicamente a pares reales. Una prueba cuenta las páginas traducidas y confirma que su HTML declara español.

Paso 8: saca los assets de la plataforma con cuidado

Descarga las imágenes con la mejor calidad disponible y guarda los originales en una carpeta de backup en la raíz. Genera versiones públicas optimizadas por separado. Nunca resuelvas un problema de rendimiento eliminando la única fuente en alta resolución.

backup/original-images/article-hero.png
public/images/blog/article-hero.webp

Actualiza los textos alternativos durante la migración sin inventar descripciones ajenas a la imagen. Al terminar, busca URLs antiguas del CDN de Framer en el contenido exportado; los recursos remotos son fáciles de pasar por alto porque siguen funcionando hasta que dejan de hacerlo.

Paso 9: incorpora IA sin entregarle el volante

La IA resulta especialmente útil como colaboradora rápida en tareas delimitadas:

• convertir patrones repetidos de Framer en componentes reutilizables;

• escribir scripts de migración y validaciones;

• detectar CSS duplicado y tokens inconsistentes;

• comparar capturas con una referencia;

• proponer metadatos y alt text para revisión;

• encontrar enlaces internos hacia rutas retiradas;

• crear pruebas a partir de errores que ya ocurrieron.

El proceso no es “pídele a una IA que reconstruya la web”. Es:

1. definir un resultado concreto;

2. permitir que el asistente inspeccione el repositorio real;

3. revisar archivos y supuestos;

4. ejecutar build y pruebas;

5. abrir el resultado en breakpoints reales;

6. guardar un cambio lo bastante pequeño como para entenderlo.

La IA acelera el ciclo. Git lo hace recuperable. Las pruebas lo hacen confiable.

Paso 10: configura Vercel como host estático

Conecta el repositorio Git a Vercel y describe el build de forma explícita:

{
  "framework": null,
  "buildCommand": "npm run build",
  "outputDirectory": "dist/client",
  "cleanUrls": true
}

Cada push puede crear un despliegue. Las previews permiten revisar con seguridad y producción sigue correspondiendo a un estado concreto de Git.

Vercel Hobby cuesta actualmente $0, pero está destinado expresamente a uso personal y no comercial. Revisa las condiciones oficiales del plan antes de considerarlo el hosting definitivo para una web comercial. Pro es la referencia adecuada cuando el proyecto cruza ese límite.

Paso 11: prueba la exportación, no solo el modo de desarrollo

El servidor local puede ocultar errores de exportación. Mi comando de pruebas genera el build de producción y después inspecciona los archivos que realmente se desplegarán.

Las comprobaciones mínimas son:

• las páginas canónicas existen como HTML estático;

• robots, sitemap y RSS aparecen en la salida;

• los drafts están ausentes;

• solo las traducciones reales aparecen bajo rutas localizadas;

• las redirecciones antiguas siguen configuradas;

• los enlaces internos no apuntan a artículos retirados.

npm test

Una suite verde no sustituye la revisión visual. Todavía compruebo homepage, índice del blog, un artículo largo, navegación, footer, móvil, teclado y movimiento reducido en un navegador.

Paso 12: cambia el dominio sin improvisar

1. Reduce el TTL del DNS con antelación si el proveedor lo permite.

2. Añade el dominio a Vercel y anota los registros necesarios.

3. Despliega y prueba primero con el dominio de preview.

4. Confirma que las canónicas siguen señalando al dominio real.

5. Actualiza el DNS en el registrador.

6. Verifica HTTPS, la redirección de www, sitemap, robots y artículos clave.

7. Vuelve a enviar el sitemap en Google Search Console y vigila la indexación.

No canceles la plataforma anterior antes de comprobar el dominio nuevo, las redirecciones y las páginas críticas. Unos días de solapamiento cuestan menos que una caída evitable.

Checklist de migración

• Exportación original del CMS respaldada.

• Imágenes de alta calidad preservadas.

• Cada URL pública de Framer tiene destino.

• Artículos importados con slugs estables.

• Drafts excluidos de todos los outputs.

• Traducciones reales separadas de fallbacks.

• Canónicas, schema, sitemap, robots y RSS generados.

• Redirecciones configuradas antes del lanzamiento.

• Build de producción probado.

• Capturas de escritorio y móvil revisadas.

• Dominio y HTTPS verificados.

• Sitemap reenviado a Search Console.

Cuándo este modelo no es la elección correcta

No migres solo para ahorrar si nadie quiere mantener código. Un repositorio estático sustituye mal a un CMS visual cuando un equipo no técnico publica a diario, los experimentos requieren una plataforma de marketing integrada o los layouts deben cambiar sin revisión técnica.

Funciona especialmente bien para portfolios, documentación, sitios editoriales y contenido relativamente estable donde la propiedad, el rendimiento y el comportamiento personalizado importan más que publicar mediante drag-and-drop.

El resultado no es “una web gratuita hecha por IA”. Es un pequeño proyecto de software con costes bajos de infraestructura, contenido versionado, trade-offs explícitos y un flujo de mantenimiento asistido por IA.

Esa descripción es menos mágica. También es la razón por la que confío en el sistema.