Migración Next.js / Astro en Múnich

Si tu empresa en Múnich tiene la web en WordPress, Joomla, Drupal o un framework antiguo y quieres pasarla a Astro o Next.js, el riesgo real no está en el código nuevo, sino en lo que se pierde por el camino: URLs que Google ya conoce, datos estructurados, versiones en alemán e inglés que se enlazan entre sí y avisos legales que la ley alemana exige. Aquí explico cómo hago esa migración, paso a paso, y qué reviso específicamente para un sitio que opera en Alemania. Trabajo solo: quien hace el inventario es quien despliega y mira Search Console después.

#¿Astro o Next.js para una web corporativa en Múnich?

La elección depende de lo que hace el sitio, no de la moda. Astro genera HTML estático por defecto y solo envía JavaScript a los componentes que lo necesitan. Encaja con webs corporativas, blogs, catálogos y páginas de servicios donde casi todo es contenido. Next.js tiene sentido cuando hay áreas de cliente con inicio de sesión, precios que dependen del usuario, búsquedas con filtros en el servidor o una aplicación que convive con la parte pública.

A veces conviene combinar ambos: contenido estático en Astro y un portal aparte. Lo decido después del inventario y te explico el motivo por escrito. Si quieres ver el enfoque general, lo tengo en la página de migración a Next.js y Astro, y el trabajo de desarrollo puro en la de desarrollador Astro.

#¿Cómo se migra sin perder posiciones en Google?

El trabajo empieza con un inventario completo de lo que existe hoy:

1. Mapa de URLs. Rastreo el sitio actual, cruzo el resultado con el sitemap y con las páginas que reciben clics en Search Console, y saco una tabla con cada URL antigua y su destino nuevo. Las que no cambian se quedan igual. Las que cambian reciben una redirección 301 a la página equivalente, nunca a la portada.
2. Modelo de contenido. Los tipos de entrada, campos personalizados, taxonomías y bloques del CMS antiguo se convierten en colecciones con un esquema validado. Si un campo obligatorio falta en un registro, la compilación falla y lo veo antes de publicar, no después.
3. Metadatos y datos estructurados. Títulos, descripciones, canónicos y el JSON-LD (Organization, LocalBusiness, Product, FAQ, lo que tenga el sitio) se trasladan campo a campo. Comparo la versión antigua y la nueva de las mismas URLs con un script, no a ojo.
4. Idiomas y hreflang. Si publicas en alemán y en inglés, cada par de páginas tiene que apuntarse mutuamente con hreflang; si una versión se redirige y la otra no, la relación se rompe. Lo compruebo en el HTML generado, sobre todas las páginas.
5. Entorno de pruebas. El sitio nuevo vive en una URL de staging bloqueada para buscadores, donde pruebo el mapa de redirecciones completo con peticiones reales y reviso Core Web Vitals en laboratorio.
6. Corte por fases. En sitios grandes publico sección por sección (por ejemplo, primero el blog, luego servicios, al final la tienda). En sitios pequeños, un solo cambio de DNS en una ventana tranquila.
7. Después del lanzamiento. Envío el sitemap nuevo, vigilo en Search Console la cobertura, los errores 404 y las páginas excluidas, y corrijo redirecciones que falten.

Google indica en su guía sobre cambios de sitio con URLs nuevas que la visibilidad puede fluctuar temporalmente durante el traslado y que es normal. También recomienda mantener las redirecciones el mayor tiempo posible, en general al menos un año. En Astro las 301 viven en un archivo del hosting o del CDN, así que no hay motivo para quitarlas.

#¿Qué suele salir mal y cómo lo detecto?

• Parámetros y paginación olvidados. URLs como ?page=2 o archivos por fecha de WordPress que reciben enlaces externos. Los saco de los registros y de Search Console, no solo del rastreo.
• Imágenes y PDF. Los documentos enlazados desde fuera (fichas técnicas, catálogos) cambian de ruta con la migración. Entran en el mismo mapa de redirecciones.
• Formularios. En un sitio estático el formulario necesita un destino: una función del servidor, un servicio de terceros o la API del CRM. Pruebo cada formulario con un envío real antes del corte.
• Editores sin panel. Si tu equipo está acostumbrado a WordPress, la opción puede ser mantener WordPress como CMS headless y usar Astro solo como frontend. Lo hablamos antes de decidir el modelo de contenido.

#¿Qué exige la ley alemana a una web de empresa en Múnich?

Una migración cambia todas las plantillas a la vez. Esto no sustituye asesoría jurídica, pero son los puntos que compruebo en el código:

• Cookies y almacenamiento en el dispositivo. El § 25 de la TDDDG exige consentimiento, basado en información clara y completa, para guardar o leer información en el equipo del usuario. La excepción es lo estrictamente necesario para el servicio que el usuario ha pedido. Si el sitio nuevo prescinde de analítica con cookies, el banner puede sobrar; si carga etiquetas de marketing, el consentimiento tiene que bloquearlas de verdad hasta que el usuario acepte, y lo verifico en la pestaña de red del navegador.
• Impressum. El § 5 de la DDG obliga a quien ofrece servicios digitales con carácter comercial a mantener ciertos datos de identificación fácilmente reconocibles, directamente accesibles y disponibles de forma permanente. Compruebo que el enlace aparezca en todas las plantillas, también en la página 404.
• Accesibilidad. La BFSG (Barrierefreiheitsstärkungsgesetz) se aplica, entre otros, a servicios de comercio electrónico prestados a consumidores después del 28 de junio de 2025. Las microempresas que prestan servicios están exentas del requisito general. Si tu tienda entra en el ámbito de la ley, aprovecho la reconstrucción para corregir contraste, navegación por teclado, textos alternativos y etiquetas de formularios.
• Protección de datos. La autoridad competente para empresas privadas en Baviera es el BayLDA (Bayerisches Landesamt für Datenschutzaufsicht), que publica guías y listas de comprobación para pymes y comercio. Si el sitio nuevo cambia de proveedor de hosting, de formularios o de fuentes, la política de privacidad tiene que reflejarlo el día del lanzamiento.

#¿Dónde se aloja el sitio nuevo?

Un frontend en Astro puede servirse desde un CDN o desde un servidor en la UE; la decisión depende de dónde están tus datos personales, no del HTML. Las páginas estáticas no guardan datos de visitantes. Lo que sí trata datos personales son los formularios, el CRM, la analítica y la tienda, y es ahí donde reviso dónde se procesan y qué contratos de encargo de tratamiento necesitas. En Next.js con renderizado en servidor también cuenta la región.

#¿Qué recibes al terminar?

El repositorio, el mapa de redirecciones, las variables de entorno documentadas, el despliegue automático y una guía corta para publicar. Si en tu empresa o en tu agencia de confianza en Múnich hay alguien técnico, puede retomar el proyecto sin depender de mí.

#¿Cuál es el siguiente paso?

Envíame la URL actual, el CMS y la versión que usas, los idiomas publicados y de dónde viene hoy tu tráfico (búsqueda orgánica, campañas, referencias). Con eso preparo un alcance por escrito: qué se migra, qué se queda fuera, si recomiendo Astro, Next.js o una combinación, y cómo será el corte.

#Marco regulatorio que condiciona el proyecto en Múnich

Múnich opera bajo DSGVO y orientación práctica del BSI para operadores. En briefs de Automoción y software empresarial eso se traduce en contrato de encargado antes del primer acceso a datos personales, registro de finalidades en los formularios y retención acotada de logs.

Múnich concentra la industria automotriz alemana, software empresarial y una densidad alta de R&D corporativo (BMW, Siemens, MTU). Entregamos WordPress empresarial alineado con los procesos formales del mercado bávaro: contratos B2B, documentación rigurosa y SLAs medibles. El hub Munich Tech Hub & BMW Group IT concentra partners que ya preguntan por GDPR, NIS2, BFSG, EAA. La respuesta útil es un runbook escrito, no un eslogan de cumplimiento.

Para un encargo de migration, documentamos dónde vive el hosting, quién administra WordPress y qué queda fuera de alcance. Automotive industry integration, enterprise-grade German market solutions, and DSGVO-compliant platforms.