Migración Next.js / Astro en Zürich

Esta página describe cómo hago una migración a Astro o Next.js para una empresa con sede en Zürich: qué se mueve, en qué orden, cómo compruebo que Google sigue viendo lo mismo y qué obligaciones de protección de datos suizas entran en el trabajo.

#¿Qué pasa en una migración de WordPress, Joomla o Drupal a Astro o Next.js?

Se cambia la capa de presentación y, según el caso, el backend de contenido. El resultado debe ser un sitio con las mismas URLs indexadas, el mismo contenido y mejores tiempos de carga.

Astro encaja cuando el sitio es sobre todo contenido: servicios, blog, fichas, documentación. Genera HTML estático y envía JavaScript solo donde hay interacción. Next.js encaja cuando hay área de cliente, autenticación, personalización o renderizado en servidor por petición.

#¿Cómo evito perder el posicionamiento al cambiar de CMS?

Con un mapa de URLs hecho antes de escribir una línea del frontend. El proceso:

1. Exporto todas las URLs del sitio actual: sitemap, rastreo propio y las URLs con impresiones en Search Console de los últimos meses. Las dos listas rara vez coinciden, y la unión es la que importa.
2. Para cada URL decido una de tres cosas: se queda igual, pasa a una nueva con redirección 301, o se retira con 410 o 301 a la página más cercana. Cada decisión queda en una tabla que revisas tú.
3. Reproduzco title, meta description, canonical, datos estructurados y enlaces internos. Si la página actual tiene JSON-LD, la nueva lo emite equivalente, no peor.
4. Pruebo el mapa contra el entorno de pruebas con una herramienta de rastreo: cada URL antigua debe responder 301 directo al destino, sin cadenas, y el destino debe responder 200.

Los dos fallos típicos son una cadena de redirecciones y un noindex heredado del entorno de pruebas. Esa etiqueta es lo primero que reviso el día del corte.

#¿Cómo se configura hreflang en una web de Zürich?

Zürich es la capital del cantón de Zürich y su lengua oficial es el alemán; la forma escrita estándar es el alemán estándar suizo, y la hablada más extendida, el alemán de Zürich (Wikipedia, “Zürich”). Para una web de una empresa de allí lo normal es contenido principal en alemán. Si además publicas en inglés u otras lenguas, hreflang tiene que ser recíproco: cada versión enlaza a todas las demás y a sí misma, y cada una declara su canonical propio.

Dos puntos técnicos. El código: de-CH si el contenido es explícitamente para Suiza, de si una versión sirve a varios países. Y el selector de idioma no debe redirigir por Accept-Language, porque un rastreador no envía esa cabecera y solo vería una versión.

Si el sitio actual ya tiene varias lenguas, el inventario incluye la comprobación de que cada grupo de traducciones se mapea completo.

#¿Qué exige la ley suiza de protección de datos a una web migrada?

La Ley federal de protección de datos revisada (nLPD, en inglés FADP) se aplica al tratamiento de datos personales por personas privadas y órganos federales (art. 2). El Comisionado Federal de Protección de Datos y Transparencia (FDPIC) indica en su web que el sector privado debe adaptar su tratamiento de datos a la ley revisada. No soy abogado y no sustituyo a uno. Lo que sí hago es convertir los puntos que afectan a una web en tareas comprobables:

• Deber de información (art. 19). Quien recoge datos personales debe informar de su identidad y datos de contacto, de la finalidad y de los destinatarios; si los datos salen al extranjero, de qué país y con qué garantías. En una web esto vive en la política de privacidad y en el texto junto a cada formulario. Durante la migración reviso que cada formulario, la newsletter y la analítica tengan su texto y que el enlace a la política siga funcionando en todas las lenguas.
• Notificación de brechas (art. 24). Las brechas de seguridad con probable alto riesgo se comunican al FDPIC lo antes posible, y el encargado del tratamiento debe avisar al responsable. Por eso el traspaso incluye quién tiene acceso al repositorio, a las variables de entorno y al panel de hosting, y cómo se rotan las claves.
• Sanciones (art. 60). Dar información falsa o incompleta, o no darla, conforme a los artículos 19, 21 y 25 a 27, puede acarrear multa de hasta 250.000 francos suizos para la persona privada, y solo se persigue a instancia de parte.

Si la web se dirige también a usuarios en la UE, el RGPD puede aplicar en paralelo. Esa valoración es de tu asesor legal. Yo documento qué servicios de terceros carga el sitio (analítica, mapas, tipografías, vídeo, chat) para que tenga la lista completa. Un frontend estático permite sacar muchos de esos recursos del propio dominio, y eso reduce el número de destinatarios que hay que declarar.

#¿Dónde se aloja el sitio y qué cambia con los datos?

Un sitio Astro estático son archivos servidos desde una red de distribución, sin PHP ni base de datos expuestos. Siguen necesitando decisión los formularios, la búsqueda y cualquier API: dónde corren y dónde se guardan los envíos. Como el art. 19 de la nLPD obliga a informar del país de destino, ese lugar es una decisión de alcance y lo dejo escrito antes de elegir proveedor.

#¿Cómo es el corte por fases y qué compruebo después?

1. Entorno de pruebas con noindex, autenticación y copia del contenido. Se revisan paridad de contenido, enlaces rotos, formularios y datos estructurados.
2. Corte de una sección (por ejemplo el blog) cuando el sitio es grande, o corte completo si es pequeño. El DNS y las redirecciones se cambian en una ventana acordada contigo.
3. Día del corte. Compruebo robots.txt, ausencia de noindex, sitemap nuevo enviado, canonical correcto en una muestra de plantillas y respuesta 301 de las URLs más importantes por tráfico.
4. Primeras semanas. Informe de cobertura y de rastreo en Search Console, comparación de clics e impresiones por grupo de páginas con el periodo anterior, y revisión de los Core Web Vitals con datos de campo. Los 404 que aparezcan se resuelven con redirección o se justifican.

La mejora de rendimiento no se promete de antemano. Se mide antes de migrar con las URLs que más tráfico reciben y se compara después con las mismas URLs.

#¿Qué puede salir mal?

Contenido que vivía en plugins o en el constructor visual y no sale en la exportación (campos personalizados, shortcodes, formularios), redirecciones de servidor que nadie documentó, imágenes indexadas que cambian de ruta y formularios que dejan de enviar correo en el nuevo entorno. Cada uno tiene su comprobación en la lista de aceptación del corte, que te entrego por escrito.

#¿Cuál es el siguiente paso?

Envíame la URL actual, el CMS con su versión, las fuentes de tráfico principales y las lenguas del sitio. Te devuelvo un alcance escrito con el inventario previsto, el enfoque (Astro o Next.js), los riesgos y el orden del corte. Antes de decidir puedes leer la guía general de migración a Astro y Next.js o mi página de desarrollo con Astro.

#Heredar una instalación en Zürich

Switzerland Innovation Park & ETH Zürich aparece a menudo como contexto de partners; el trabajo sobre el tema y los plugins sigue siendo del repositorio del cliente.

Zúrich concentra banca, farmacéutica y sedes corporativas globales con un nivel de exigencia regulatoria entre los más altos de Europa. Entregamos soluciones WordPress dimensionadas a la formalidad operativa que el mercado suizo asume como base. Perfil típico: Banca y farmacéutica. Marco: nDSG suizo y facturación con UID/MWST.