Migración de WordPress a Next.js: cómo cambiar sin perder posiciones en Google

Vale la pena cuando WordPress se ha convertido en el problema, no simplemente porque sea antiguo. Los motivos habituales son una pila de plugins que nadie entiende del todo, actualizaciones que esperan meses y necesidades de inicio de sesión o de acceso para las que el núcleo de WordPress no fue diseñado. Si el sitio está actualizado, usa pocos plugins bien mantenidos y el equipo edita páginas a diario, reforzar WordPress suele costar menos y arriesgar menos que migrar.

• Se apilan muchos plugins para cubrir inicio de sesión, formularios, membresías o pagos, cada uno con su propio calendario de actualizaciones.
• Nadie se encarga de las actualizaciones, así que los parches del núcleo, del tema y de los plugins esperan semanas o meses.
• Necesita MFA, SSO o acceso por roles diseñados dentro del producto, no añadidos con plugins.
• El contenido cambia poco, o ya lo gestiona un equipo de desarrollo.
• El sitio se ha convertido en un portal o una aplicación que WordPress apenas consigue sostener.

Quédese y refuerce WordPress cuando ocurre lo contrario: elimine los plugins que no usa, elija un hosting gestionado de confianza, aplique parches en pocos días, mantenga copias de seguridad y ponga delante un firewall de aplicaciones web. Una vulnerabilidad por sí sola rara vez justifica una migración. Cuando aparece un fallo del núcleo como CVE-2026-87902, lo primero es actualizar; la migración es una decisión aparte que puede tomar con calma después. Nuestras guías sobre la seguridad de WordPress frente a un sitio a medida y sobre CVE-2026-87902 tratan ambos temas.

Hay dos caminos principales. En el primero, WordPress se queda como CMS headless: los editores conservan el panel de WordPress y un front end en Next.js obtiene el contenido y construye las páginas públicas. La propia documentación para desarrolladores de WordPress describe su REST API como una forma de llevar el contenido de WordPress a aplicaciones completamente independientes, utilizable desde cualquier lenguaje capaz de hacer peticiones HTTP y leer JSON. En el segundo camino, WordPress se retira y el contenido pasa a otro CMS headless o a un panel de administración a medida creado para su equipo.

El modelo headless suele ser el primer paso más pequeño, pero mantiene un panel de WordPress que hay que actualizar y proteger. Una reconstrucción total elimina WordPress por completo y cuesta más al principio. Elija según quién edita el contenido, con qué frecuencia y cuánto del sistema antiguo está dispuesto a seguir manteniendo.

Este es el proceso que seguimos en las migraciones de WordPress. Cada paso deja algo por escrito, para que nada dependa de la memoria el día del lanzamiento.

1. 1

   Auditar el sitio

   Listar cada página, tipo de contenido, formulario, rol de usuario y plugin, y anotar qué hace realmente cada plugin para el negocio. Reunir las URL actuales del sitemap, de un rastreo y de Search Console para no olvidar páginas con tráfico o enlaces entrantes.

2. 2

   Asignar las URL antiguas a las nuevas

   Dar a cada dirección antigua un destino en una sola hoja de cálculo: entradas, páginas, archivos de categorías y etiquetas, páginas de autor, feeds y archivos multimedia en /wp-content/uploads/. Cada línea se convierte en una redirección permanente.

3. 3

   Reconstruir y decidir cómo se edita el contenido

   Reconstruir las plantillas en Next.js y elegir entre WordPress headless, otro CMS headless o un panel a medida, según quién edita y con qué frecuencia.

4. 4

   Mover contenido, usuarios y datos

   Importar entradas, páginas, archivos multimedia y cuentas, comparar a mano una muestra con el sitio antiguo y reconstruir el inicio de sesión con el modelo de acceso que necesita, como acceso por roles, MFA o SSO.

5. 5

   Lanzar y supervisar

   Hacer el cambio, probar las redirecciones, enviar el nuevo sitemap y vigilar en Search Console los errores y las páginas que falten. Después del lanzamiento, las actualizaciones de dependencias y la supervisión continúan como parte del trabajo.

Google trata un cambio de plataforma que modifica las URL como un traslado de sitio. Su guía de Search Central sobre traslados de sitios con cambios de URL (actualizada el 20 de agosto de 2026) recomienda redirecciones permanentes del lado del servidor, como 301 o 308, un mapa completo de URL antiguas y nuevas, y mantener las redirecciones el mayor tiempo posible, como mínimo un año. También indica que, en un sitio mediano, pueden pasar unas semanas o más hasta que Google muestre las nuevas URL en lugar de las antiguas, así que es normal ver algo de movimiento tras el lanzamiento.

• Redirija cada URL antigua directamente a su página nueva más parecida. Evite las cadenas y no envíe muchas URL antiguas a la página de inicio.
• En Next.js, declare las redirecciones en next.config con permanent: true, que devuelve un 308. La documentación de Next.js advierte que las plataformas de hosting pueden limitar esta lista (Vercel permite 1.024) y sugiere un mapa de redirecciones leído por Proxy a partir de 1.000.
• Dé a cada página nueva una etiqueta canonical que apunte a sí misma. En Next.js se define con alternates.canonical en la Metadata API.
• Genere un sitemap de las nuevas URL con app/sitemap.ts y envíelo en Search Console; conserve el sitemap antiguo hasta haber enviado el nuevo.
• Use redirecciones del lado del servidor, no de JavaScript. La documentación de Google sobre redirecciones dice que solo se usen redirecciones de JavaScript cuando no sea posible hacerlas en el servidor ni con meta refresh.
• Mantenga el sitio verificado en Search Console, revise cada semana los informes de indexación y de sitemaps tras el lanzamiento y actualice los enlaces internos para que el sitio no dependa de sus propias redirecciones.

Conserve el mismo dominio si puede. Cambiar de plataforma y de dominio a la vez hace más difícil localizar los problemas. Si el dominio tiene que cambiar, la guía de Google añade a los pasos la herramienta de cambio de dirección de Search Console.

WordPress multisite ejecuta varios sitios desde una sola instalación. La documentación de WordPress describe redes basadas en rutas (subdirectorios) o en dominios (dominios o subdominios), en las que cada sitio conserva sus propias tablas de contenido y solo se comparte la tabla de usuarios. Eso condiciona el plan.

• Trate cada sitio como una migración propia, con su propio mapa de URL, su sitemap y sus comprobaciones en Search Console.
• Decida pronto si los usuarios compartidos se quedan en un único sistema de cuentas o se separan por sitio, y cómo gestionarán después todos los sitios los administradores de la red.
• Liste qué plugins y temas están activos en toda la red, porque un solo plugin puede sostener funciones en todos los sitios.
• Una sola aplicación Next.js puede servir varios dominios y sus redirecciones pueden filtrar por nombre de host, de modo que un único código puede contener los mapas de redirecciones de todos los sitios.
• Migre primero un sitio, observe su tráfico de búsqueda durante unas semanas y después migre el resto.

Tanto si contrata a un equipo local como a uno remoto, por ejemplo una empresa del Reino Unido que trabaja con una agencia de otro país, pida estas respuestas por escrito antes de firmar.

• ¿El mapa completo de redirecciones forma parte del alcance escrito y quién lo revisa tras el lanzamiento?
• ¿Cómo editará y publicará contenido nuestro equipo después del lanzamiento, y le darán formación?
• ¿Qué plugins se reconstruirán, cuáles se sustituirán por un servicio y cuáles se eliminarán?
• ¿Cómo se trasladan las cuentas de usuario y los inicios de sesión, y qué verán los usuarios la primera vez que entren?
• ¿Se mantendrán el dominio y las URL, y durante cuánto tiempo supervisarán la búsqueda tras el lanzamiento?
• ¿Quién es el titular del código, del hosting, del CMS y de las cuentas del dominio?
• ¿Qué horas de nuestra jornada coinciden con la suya y en cuánto tiempo responden?
• ¿Quién actualiza las dependencias tras el lanzamiento y figura eso en el contrato?
• ¿Podemos ver migraciones o plataformas de contenido que hayan construido?

El plazo y el coste dependen más del contenido y de las URL que del código. Los factores principales son:

• El número de plantillas de página distintas y de tipos de contenido personalizados.
• Cuántas URL necesitan redirección, incluidos los archivos y los ficheros multimedia.
• Formularios, pagos, membresías e integraciones con CRM o ERP que antes resolvían los plugins.
• Si WordPress se queda como CMS headless o se sustituye.
• Las cuentas de usuario y el modelo de inicio de sesión, sobre todo con MFA o SSO.
• Redes multisite e idiomas adicionales, cada uno con sus propias URL.

Las cifras publicadas varían mucho y proceden sobre todo de agencias. Por ejemplo, Kolonell, un estudio web remoto, publicó el 8 de octubre de 2026 una estimación para pequeñas empresas del Reino Unido: de 13.000 £ a 30.000 £ sin IVA por un traslado a Next.js headless, en 10–14 semanas (unas 2 semanas de auditoría y definición del alcance, 6–8 semanas de desarrollo y migración, y 2–4 semanas de pruebas y puesta en marcha por fases). Tómelo como la tarifa de una agencia, no como un precio de mercado. Algunas agencias venden un sprint de migración a precio cerrado; pregunte qué incluye, sobre todo en redirecciones y formación de editores.

No publicamos precios cerrados. Nuestra consulta gratuita empieza por los problemas que tiene hoy, no por una reconstrucción: una llamada de 30 minutos con un ingeniero, una revisión de su sitio WordPress con la recomendación de actualizar, reforzar o migrar, y una recomendación por escrito con una estimación aproximada de costes. Si quedarse en WordPress es la mejor respuesta, eso es lo que dirá la recomendación.

• Servicio de migración de WordPress a Next.js (en inglés)
• WordPress frente a un sitio a medida: ¿es más seguro migrar? (en inglés)
• CVE-2026-87902 de WordPress: qué hacer (en inglés)
• ¿Qué es un CMS headless?
• Reserve una consulta gratuita y una revisión de WordPress (en inglés)

• Google Search Central: Site moves with URL changes (updated 20 August 2026)
• Google Search Central: Redirects and Google Search (updated 14 April 2026)
• Next.js docs: redirects in next.config.js (updated 30 June 2026)
• Next.js docs: How to handle redirects in Next.js (updated 19 August 2026)
• Next.js docs: sitemap.xml file convention (updated 18 August 2026)
• Next.js docs: generateMetadata, alternates and canonical (updated 19 August 2026)
• WordPress Developer Resources: REST API Handbook (accessed 1 November 2026)
• WordPress Developer Resources: Multisite (accessed 1 November 2026)
• Kolonell: WordPress to Next.js migration cost for UK SMBs, agency estimate (8 October 2026)