Migración Next.js / Astro en Hamburg

Una empresa de Hamburg que pasa su web de WordPress, Joomla, Drupal o un framework antiguo a Astro o Next.js gana o pierde tráfico por un detalle: qué ocurre con cada URL antigua el día del corte. Aquí describo el trabajo técnico que hago, qué cambia al vender en el mercado alemán y qué compruebo antes y después del lanzamiento.

#¿Qué conviene saber del mercado de Hamburg antes de migrar?

Hamburg es la segunda ciudad más poblada de Alemania, con 1 857 727 habitantes en el dato de noviembre de 2020 que recoge Wikipedia, y sus lenguas oficiales son el alemán y el bajo alemán. La Behörde für Wirtschaft, Arbeit und Innovation, la consejería de economía de la ciudad, organiza su trabajo en torno al puerto, la aviación, la logística, la industria y la artesanía.

Para una web eso se traduce en requisitos concretos. El comprador busca y lee en alemán, así que el alemán es la lengua del contenido y no una traducción de última hora. Un operador logístico o un proveedor del sector aeronáutico suele tener catálogos técnicos, fichas en PDF y páginas de servicio por región: muchas URL con poco tráfico cada una, que juntas sostienen la visibilidad. Son justo las que se pierden cuando una migración solo mapea el menú.

#¿Cómo paso las URL antiguas a las nuevas sin perder posiciones?

Empiezo con un inventario completo de las URL que existen hoy. Cruzo tres fuentes: el sitemap del CMS, el informe de páginas de Search Console y un rastreo del propio sitio. Las páginas que reciben enlaces externos o clics entran en una lista prioritaria.

Después construyo el mapa de redirecciones 301, una línea por URL antigua, con el destino decidido por escrito. Las reglas que aplico:

• Cada URL antigua con valor apunta a su página equivalente, nunca a la portada.
• Las cadenas de redirecciones se colapsan: la URL antigua apunta directamente al destino final.
• Las variantes (barra final, mayúsculas, ?page=2, index.php, parámetros de campaña) se tratan de forma explícita.
• Las páginas sin equivalente devuelven 410 o pasan a un archivo, y la decisión queda anotada.

#¿Qué pasa con el modelo de contenido y los datos estructurados?

En Astro el contenido vive en colecciones con un esquema validado (Markdown, MDX o un CMS headless). Cada campo que hoy existe en WordPress, como título, descripción, fecha, autor, categorías e imagen destacada, necesita un destino. Los campos de ACF y las taxonomías propias son lo que más falla en una migración con prisas, así que los exporto y comparo recuentos: entradas por tipo en el CMS antiguo frente a páginas generadas en el nuevo.

Los datos estructurados (JSON-LD) se generan desde el contenido, no se copian a mano. Valido una muestra por tipo de página con la prueba de resultados enriquecidos de Google y con el validador de schema.org, y compruebo que el canonical coincide con mainEntityOfPage. Si la web tiene versión alemana, inglesa o española, el hreflang tiene que ser recíproco: si la página alemana apunta a la española, la española apunta de vuelta.

#¿Astro o Next.js para una empresa de Hamburg?

Astro para sitios con mucho contenido (webs corporativas, blogs, documentación, catálogos técnicos), porque solo envía JavaScript donde lo pides. Next.js cuando hay un área con inicio de sesión, precios que dependen del cliente o renderizado en servidor conectado a sistemas internos, como un portal de seguimiento de envíos. Dejo la recomendación por escrito, con el motivo, para poder revisarla dentro de un año.

#¿Qué normas afectan a la web nueva si vendes en Alemania y desde España?

Protección de datos en Hamburg. La autoridad competente es Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit (HmbBfDI), que en su web ofrece formularios para reclamaciones y para notificar brechas de datos.

Cookies. Si tu empresa opera también desde España, el artículo 22.2 de la Ley 34/2002 de servicios de la sociedad de la información y de comercio electrónico (LSSI) exige consentimiento, con información clara y completa, para guardar o leer datos en el equipo del usuario. Exceptúa lo técnico y lo estrictamente necesario para prestar el servicio que el usuario ha pedido. En la práctica, analítica, píxeles y vídeos incrustados solo cargan tras el consentimiento, y lo compruebo en el navegador, con la pestaña de red abierta, antes del lanzamiento.

Accesibilidad. La Directiva (UE) 2019/882 sobre requisitos de accesibilidad de productos y servicios se transpone en España mediante la Ley 11/2023, de 8 de mayo. En Alemania la transpone la BFSG, cuyo § 1 incluye los servicios de comercio electrónico prestados a consumidores después del 28 de junio de 2025. Si vendes a consumidores en Alemania, confirma el encuadre con un abogado. En la parte técnica, el frontend nuevo lleva HTML semántico, contraste suficiente, navegación por teclado y etiquetas en los formularios, y lo reviso con un lector de pantalla y una herramienta automática.

#¿Cómo hago el corte y qué compruebo después?

1. Entorno de pruebas con el mapa 301 y paridad de metadatos (title, description, canonical, robots), comparada con el sitio antiguo mediante un rastreo.
2. Ensayo del corte: un script recorre todas las URL antiguas y confirma el código de respuesta y el destino final.
3. Corte por secciones en sitios grandes; en uno pequeño, en un solo día de poco tráfico.
4. Envío del nuevo sitemap a Search Console y revisión de robots.txt, para que el entorno de pruebas nunca quede indexado ni el sitio real bloqueado por error.
5. En las semanas siguientes leo los informes de indexación, los errores 404 y los Core Web Vitals, y corrijo las caídas antes de que una campaña pierda tráfico.

Lo que puede salir mal y cómo lo detecto: redirecciones a la portada (Search Console las marca como soft 404), un noindex heredado del entorno de pruebas (rastreo tras el lanzamiento), imágenes con rutas nuevas (comparo el rastreo de imágenes) y formularios que dejan de enviar (prueba de envío real).

El método general está en migración a Astro y Next.js. Si tu web es una tienda, mira también migración de WooCommerce a headless.

#¿Pierde posiciones en Google un sitio migrado a Astro o Next.js?

Puede perderlas si las URL cambian sin un mapa de redirecciones. Por eso el 301 uno a uno y la paridad de metadatos van antes que cualquier decisión visual, y tras el corte sigo Search Console hasta que las páginas principales se estabilizan.

#¿Necesito la web en alemán para vender en Hamburg?

El alemán es la lengua oficial de la ciudad, junto al bajo alemán. Una web solo en español o inglés llega a menos compradores. Si el contenido existe en varios idiomas, configuro hreflang recíproco para que cada versión aparezca en su mercado.

#¿Cambia el banner de cookies al pasar a Astro o Next.js?

La obligación no cambia: lo que no es estrictamente necesario sigue necesitando consentimiento. Cambia la implementación, que pasa a estar escrita en el código en lugar de depender de un plugin.

#¿Cómo empiezo?

Envíame la URL actual, el CMS que usas y tus principales fuentes de tráfico. Te respondo con un alcance por escrito y los riesgos que veo en el mapa de URL.

#Marco regulatorio que condiciona el proyecto en Hamburg

Hamburg opera bajo DSGVO y orientación práctica del BSI para operadores. En briefs de Medios y logística marítima 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.

Hamburgo articula medios, logística marítima y comercio internacional, con un cluster digital significativo en Hafencity. Implementamos WordPress empresarial preparado para integraciones con sistemas portuarios, estructuras editoriales complejas y la exigencia documental alemana. El hub Hamburg Digital Hub & MediaCity 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. Media industry platforms, logistics & maritime sector portals, and publishing house systems.