Migración Next.js / Astro en Ginebra

#¿Cuándo tiene sentido migrar una web de Ginebra a Astro o Next.js?

Cuando el CMS actual frena el rendimiento, la seguridad o la edición, y no cuando bastaría con ordenar plugins y caché. Señales que mido antes de proponer nada: un TTFB alto en las páginas que reciben tráfico, un panel de administración más lento que la web, actualizaciones que nadie se atreve a instalar y editores que evitan publicar. Si el diagnóstico dice que arreglar el sitio actual sale más barato, te lo digo y no migramos.

Ginebra es la capital de la República y Cantón de Ginebra, en el suroeste de Suiza, donde el Ródano sale del lago Lemán. Según Wikipedia, la ciudad tenía 203.856 habitantes en diciembre de 2020 y el cantón 506.343, repartidos en 45 municipios. Esa escala importa: son webs de empresas, asociaciones y organizaciones que atienden a un público internacional y a uno local a la vez.

#¿Qué contiene una migración bien hecha, paso a paso?

1. Inventario. Rastreo el sitio actual, exporto de Search Console las URL con clics e impresiones y cruzo ambas listas con los logs del servidor. El resultado es una hoja con cada URL, su tráfico, su tipo de contenido y su destino. Lo que no recibe tráfico ni enlaces se decide aparte: unificar, redirigir o eliminar.

2. Mapa de redirecciones 301. Cada URL antigua con valor apunta a una sola URL nueva, sin cadenas. Cuido las variantes que suelen romperse: barra final, mayúsculas, parámetros de consulta, URL de adjuntos de WordPress, rutas de paginación y de categorías. Las reglas se aplican en el servidor o en el edge, nunca con JavaScript en el cliente.

3. Modelo de contenido. Entradas, páginas y tipos personalizados pasan a colecciones tipadas (Markdown o MDX en Astro, o una API si los editores necesitan un panel). Cada campo del contenido actual tiene un destino: título, descripción, imagen destacada, autor, fecha, categorías, bloques de texto. Lo que se queda en WordPress como backend headless se consume por REST o GraphQL.

4. Metadatos y datos estructurados. Reproduzco title, meta description, canonical y Open Graph página por página, y comparo el HTML antiguo con el nuevo con un script. Los datos estructurados (Organization, BreadcrumbList, Article, FAQ cuando existe una sección de preguntas visible) se generan desde el mismo contenido para que no se desincronicen.

5. Idiomas y hreflang. Si el sitio sirve en más de una lengua, cada versión declara todas las demás y a sí misma. Google ignora las anotaciones que no son recíprocas. Un código de región no puede ir solo: la lengua va primero, de modo que fr-CH apunta a hablantes de francés en Suiza. Añado x-default solo si hay una página de selección de idioma.

6. Entorno de pruebas. El staging va con noindex y autenticación, y verifico en el HTML publicado que ese noindex desaparece al lanzar. Es uno de los fallos más repetidos: un sitio nuevo que sale con la directiva de pruebas.

7. Corte por fases. Una sección cada vez, con el proxy repartiendo tráfico entre el sistema antiguo y el nuevo. Después de cada fase compruebo estado HTTP, canonical y sitemap de esa sección antes de pasar a la siguiente.

8. Seguimiento en Search Console. Envío el sitemap nuevo, inspecciono una muestra de URL clave, reviso el informe de páginas por si aparecen excluidas por noindex, duplicadas o con error 404, y comparo clics por grupo de URL contra la línea base del inventario. Si un grupo cae, corrijo la causa y no espero a que la campaña pierda tráfico.

#¿Qué puede salir mal y cómo lo compruebo?

• Redirecciones que no cubren URL con tráfico. Lo detecto cruzando el rastreo, los logs y Search Console contra el mapa; las que faltan aparecen como 404 en la inspección posterior.
• Cadenas y bucles de 301. Un script recorre todas las URL antiguas y exige un único salto hasta un 200.
• Contenido que no llega al HTML. Compruebo el HTML servido, no solo lo que muestra el navegador, porque los buscadores leen primero el primero.
• Formularios y búsqueda interna. WordPress hacía parte de ese trabajo con plugins. En el nuevo stack hay que decidir dónde vive cada función antes del corte.

#¿Qué idioma y qué normas importan en el mercado de Ginebra?

Según Wikipedia, el francés es la lengua oficial de la ciudad y del cantón. Una web dirigida a clientes locales parte del francés; si además atiende a organizaciones internacionales, se añaden otras lenguas con hreflang y no con un selector que redirija por IP. Ginebra figura en esa misma fuente como sede del mayor número de organizaciones internacionales del mundo, entre ellas el Comité Internacional de la Cruz Roja. Su economía de servicios incluye, según la misma página del cantón, el comercio de materias primas y la banca privada, junto con la relojería tradicional. Esos sectores suelen exigir páginas claras sobre quién trata los datos y dónde.

En protección de datos, la autoridad federal es el Préposé fédéral à la protection des données et à la transparence (PFPDT, en inglés FDPIC), que se describe a sí mismo como autoridad federal independiente responsable de protección de datos y de transparencia. La Ley federal de protección de datos (LPD, versión consolidada de 1 de septiembre de 2023) fija, según su texto en Fedlex, obligaciones que tocan directamente una web:

• Art. 19: informar al interesado de forma adecuada al recopilar datos personales, incluyendo identidad y contacto del responsable, finalidad y destinatarios.
• Art. 16: la comunicación de datos al extranjero requiere una decisión de adecuación del Consejo Federal o garantías específicas.
• Art. 24: las brechas de seguridad con probable riesgo elevado se notifican al PFPDT.
• Art. 60: multa de hasta 250.000 francos a personas privadas, previa denuncia, por incumplir deberes de información y cooperación.

No sustituye a un asesor jurídico. Lo que hago en la migración es dejar por escrito qué datos recogen los formularios, qué terceros cargan scripts y a qué servidores van, para que tu asesor decida con datos reales.

#¿Qué cambia con el hosting y la residencia de datos?

Un sitio estático en Astro no guarda datos personales en la página. Los puntos sensibles son el endpoint del formulario, la analítica, el correo transaccional y cualquier widget embebido. Los documento uno por uno con su proveedor y su ubicación de tratamiento, porque el art. 16 de la LPD depende de a dónde viajan los datos. Si la política de tu organización exige un proveedor concreto, lo elijo en la fase de inventario y no al final.

#¿Qué recibes al terminar?

Repositorio, variables de entorno, pipeline de despliegue y una guía operativa breve quedan en tus manos. El detalle general del servicio está en migración a Astro y Next.js, y si buscas solo el frontend, en desarrollador Astro.

#¿Cómo empezamos?

Envíame la URL actual, el CMS que usas y de dónde viene el tráfico (Search Console, analítica o ambos). Te respondo por escrito con un alcance: qué se migra, qué se redirige, qué se descarta y qué riesgos veo.