Migración Next.js / Astro en Viena

Si tu empresa en Viena tiene la web en WordPress, Joomla, Drupal o un framework antiguo y quieres pasarla a Astro o Next.js, lo difícil no es escribir el código nuevo. Lo difícil es no perder por el camino lo que ya funciona: URLs que Google conoce, datos estructurados, la relación entre la versión en alemán y la de otros idiomas, y los datos legales que una web comercial en Austria tiene que mostrar. Trabajo solo: quien hace el inventario es quien despliega y quien revisa Search Console después.

#¿Astro o Next.js para la web de una empresa vienesa?

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, páginas de servicios y sitios de turismo o cultura donde casi todo es contenido. Next.js tiene sentido cuando hay área de clientes con inicio de sesión, precios que dependen del usuario, búsqueda con filtros en el servidor o una aplicación que convive con la parte pública.

A veces lo razonable es combinar: contenido en Astro y un portal aparte en Next.js. Y a veces basta con ordenar plugins y caché en el WordPress actual. Lo decido después del inventario y te lo explico por escrito. El enfoque general está en la página de migración a Next.js y Astro; si prefieres conservar WordPress como panel de edición, mira la de desarrollador headless CMS.

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

1. Mapa de URLs. Rastreo el sitio actual, cruzo el resultado con el sitemap y con las páginas que reciben clics e impresiones en Search Console, y preparo una tabla con cada URL antigua y su destino. Las que no cambian se quedan igual. Las que cambian reciben una 301 a la página equivalente, nunca a la portada.
2. Modelo de contenido. Tipos de entrada, campos personalizados, taxonomías y bloques del CMS antiguo pasan a colecciones con un esquema validado. Si a un registro le falta un campo obligatorio, la compilación falla y lo veo antes de publicar.
3. Metadatos y datos estructurados. Títulos, descripciones, canónicos y 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.
4. Idiomas y hreflang. El alemán es el idioma oficial de Austria; si tu web publica también en inglés u otros idiomas, cada par de páginas tiene que apuntarse mutuamente con hreflang, y si una versión se redirige y la otra no, la relación se rompe. Si usas de-AT y de-DE por separado, compruebo que no compitan entre sí. Lo verifico en el HTML generado.
5. Entorno de pruebas. El sitio nuevo vive en una URL de staging bloqueada para buscadores. Ahí lanzo el mapa de redirecciones completo con peticiones reales y reviso Core Web Vitals en laboratorio.
6. Corte por fases. En sitios grandes publico por secciones: primero el blog, luego servicios, al final la tienda o el área de clientes. En sitios pequeños, un único cambio de DNS en una ventana tranquila.
7. Después del lanzamiento. Envío el sitemap nuevo y vigilo en Search Console la cobertura, los 404 y las páginas excluidas, y añado las redirecciones que falten.

Según la guía de Google sobre traslados con cambio de URL, la visibilidad puede fluctuar temporalmente mientras se indexa de nuevo el sitio. También recomienda mantener las redirecciones el mayor tiempo posible, en general al menos un año.

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

• Parámetros, paginación y archivos por fecha. URLs como ?page=2 o /2019/05/ que reciben enlaces externos. Las saco de los registros del servidor y de Search Console, no solo del rastreo.
• PDF e imágenes enlazados desde fuera. Fichas técnicas, menús, folletos o convocatorias cambian de ruta al migrar. Entran en el mismo mapa de redirecciones.
• Formularios. En un sitio estático el formulario necesita un destino: una función en el servidor, un servicio externo o la API del CRM. Pruebo cada uno con un envío real antes del corte.
• Editores que pierden su panel. Si tu equipo trabaja con WordPress desde hace años, mantenerlo como CMS headless y usar Astro solo como frontend suele ser mejor que obligar a todos a aprender otra herramienta.

#¿Qué exige la ley austriaca a la web nueva?

No sustituye asesoría jurídica, pero una migración toca todas las plantillas a la vez, así que compruebo esto en el código:

• Impressum. El § 5 de la E-Commerce-Gesetz (ECG) obliga al prestador a tener disponibles de forma permanente, fácil y directamente accesibles su nombre o razón social, la dirección geográfica de su establecimiento y datos de contacto rápido, incluido un correo electrónico. Cuando aplica, también el número y el tribunal del registro mercantil, la autoridad de supervisión o el colegio profesional y el número de IVA. Compruebo que el enlace esté en todas las plantillas, también en la 404 y en las páginas de agradecimiento.
• Consentimiento para cookies y similares. El § 165 apartado 3 de la Telekommunikationsgesetz 2021 (TKG 2021) solo permite obtener datos del dispositivo del usuario si este da su consentimiento activo, basado en información clara y completa. La excepción es lo estrictamente necesario para un servicio que el usuario ha pedido expresamente. Si el sitio nuevo carga etiquetas de marketing, verifico en la pestaña de red del navegador que no se disparan antes de aceptar.
• Accesibilidad. El Barrierefreiheitsgesetz (BaFG) se aplica a los servicios de comercio electrónico prestados a consumidores después del 28 de junio de 2025. Las microempresas que prestan servicios, con menos de diez personas empleadas y hasta 2 millones de euros de volumen de negocio o balance, están exentas. Vigila su cumplimiento el Sozialministeriumservice. Si tu tienda entra en el ámbito de la ley, aprovecho la reconstrucción para corregir contraste, navegación con teclado, textos alternativos y etiquetas de formularios.
• Protección de datos. La autoridad de control en Austria es la Datenschutzbehörde (DSB), con sede en Viena. Si al migrar cambias de proveedor de hosting, de formularios, de analítica o de fuentes, la política de privacidad tiene que reflejarlo el día del lanzamiento, no semanas después.

#¿Dónde se aloja el sitio nuevo?

Un frontend en Astro puede servirse desde un CDN o desde un servidor en la UE: las páginas estáticas no guardan datos de los visitantes. Los datos personales los tratan los formularios, el CRM, la analítica y la tienda, y ahí reviso dónde se procesan y qué contratos de encargo de tratamiento necesitas. Con Next.js y renderizado en servidor también cuenta la región del servidor.

#¿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 contenido. Si en tu empresa o en una agencia de confianza en Viena hay alguien técnico, puede seguir con el proyecto sin depender de mí.

#¿Cuál es el siguiente paso?

Envíame la URL actual, el CMS y su versión, los idiomas que publicas y de dónde viene hoy tu tráfico (búsqueda orgánica, campañas, referencias, newsletters). 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.

#Pagos, fiscalidad y formularios en Viena

En Organizaciones internacionales en Viena, el checkout y los formularios fallan antes que el diseño. Las pruebas usan importes de test; las tasas las fija el cliente en su pasarela.

Marco aplicable: DSGVO y FAGG en contratos a distancia. Drivers del brief: GDPR, NIS2, BaFG.

Viena combina sector público, organizaciones internacionales y un mercado corporativo conservador con exigencias regulatorias propias del eje DACH. Entregamos soluciones WordPress alineadas con la formalidad operativa que ese contexto exige.