Ilustración de una migración web a WordPress con un mapa de URLs y redirecciones 301.

Trasladar una web a un nuevo CMS no tiene por qué implicar perder las direcciones que ya conocen los usuarios y los buscadores. Para entender cómo trasladar un sitio web a WordPress manteniendo sus URL, conviene tratar la migración como un proyecto de arquitectura web: primero se inventarian las rutas actuales, después se reproducen o redirigen con criterio y, por último, se valida cada respuesta del servidor.

Una migración bien planteada puede conservar el dominio, las rutas de páginas y entradas, los enlaces internos y buena parte de las señales SEO acumuladas. El riesgo aparece cuando se publica una nueva web sin haber decidido qué ocurrirá con cada URL anterior. Un diseño nuevo puede estar listo; una estructura de enlaces rota, no.

Tabla De Contenidos

  1. Puntos Clave Antes De Migrar
  2. Planificar El Mapa De URL Y La Estructura De WordPress
  3. Ejecutar, Probar Y Supervisar La Migración
  4. Preguntas Frecuentes
  5. Fuentes Y Referencias

Puntos Clave Antes De Migrar

La regla principal es simple: si una URL puede mantenerse idéntica, normalmente es preferible conservarla. Si debe cambiar, la URL antigua necesita un destino permanente que responda a la misma intención del usuario. No basta con enviar todas las páginas eliminadas a la portada.

Una migración segura no consiste solo en mover contenido. Consiste en preservar las rutas que conectan a usuarios, buscadores, marcadores y enlaces externos con ese contenido.

Situación Durante La MigraciónAcción RecomendadaRiesgo Si Se Ignora
Misma URL, nuevo WordPressRecrear la ruta exacta en WordPressErrores 404 innecesarios
URL antigua con equivalente nuevoCrear una redirección 301 directaPérdida de señales y mala experiencia
Página eliminada sin alternativa realMantener un 404 o devolver 410 si procedeRedirección irrelevante a la portada
Cambio de dominio temporal a definitivoSustituir enlaces internos antes de publicarEnlaces que apuntan al dominio provisional
Cambio de protocolo HTTP a HTTPSRevisar redirecciones, canonicals y recursosContenido mixto y cadenas de redirección

Diferenciar El Tipo De Cambio Evita Errores

Antes de tocar WordPress, separo los cambios en cuatro grupos. Esta clasificación aclara cuánto trabajo de redirección será necesario.

  1. Cambio de alojamiento: el dominio, el protocolo y las rutas se mantienen. En teoría, no deberían hacer falta redirecciones por cambio de URL, aunque sí pruebas completas.
  2. Cambio de CMS: se pasa desde otra plataforma a WordPress, pero se intenta mantener el mismo dominio y la misma estructura de enlaces.
  3. Cambio de estructura: cambian directorios, categorías, slugs, barras finales o formatos de fecha. Aquí se necesita un mapa de redirecciones detallado.
  4. Cambio de dominio o protocolo: se modifica el dominio, se pasa de HTTP a HTTPS o se combinan ambos cambios. Es una operación distinta y exige revisar todas las variantes de acceso.

Por ejemplo, trasladar https://ejemplo.es/servicios/diseno-web/ a WordPress manteniendo exactamente esa dirección es muy diferente de sustituirla por https://ejemplo.es/diseno-web/. El contenido puede ser el mismo, pero la segunda opción requiere una redirección 301 desde la ruta antigua.

La documentación de Google recomienda que una migración con cambios de URL se planifique con un mapa de equivalencias y redirecciones permanentes entre las direcciones antiguas y sus destinos nuevos. Esa equivalencia debe ser semántica: una guía concreta debería llevar a su versión actualizada, no a una categoría genérica ni a la página de inicio.

Qué Debe Mantenerse Para Que Una URL Sea Idéntica

Una URL no depende solo del texto visible de una página. Para conservarla sin cambios hay que revisar varios elementos a la vez:

• El protocolo: https:// en lugar de http://.

• El subdominio: www.ejemplo.es no es técnicamente igual que ejemplo.es.

• La ruta: /blog/consejos/ debe coincidir letra por letra con la ruta anterior.

• La barra final: algunos servidores tratan de forma distinta /servicios y /servicios/.

• Las mayúsculas y minúsculas: en muchos entornos Linux, /Blog/ y /blog/ pueden ser recursos diferentes.

• Los parámetros relevantes: una URL de campaña no suele requerir una página distinta, pero ciertos parámetros funcionales sí pueden necesitar una regla específica.

WordPress permite adaptar los enlaces permanentes, pero no siempre reproduce de forma nativa una estructura heredada compleja. Si el sitio anterior usa rutas como /noticias/2022/titulo-del-articulo.html, puede ser necesario combinar ajustes de enlaces permanentes, slugs manuales y reglas de redirección.

Para comprender cómo se organiza el contenido, las plantillas y las rutas antes de reconstruirlo, resulta útil revisar WordPress como CMS. La decisión no debería basarse solo en que una URL “se vea bien”; debe permitir publicar y mantener el sitio sin crear una estructura difícil de administrar.

Inventario: El Documento Que Evita Decisiones A Ciegas

No conviene usar únicamente el sitemap XML como inventario. Un sitemap puede omitir URLs históricas, páginas no indexables, documentos descargables o rutas que siguen recibiendo enlaces externos. Es más prudente combinar distintas fuentes:

• Sitemap XML actual.

• Datos de analítica web, especialmente páginas de destino con visitas.

• Google Search Console, para revisar URLs indexadas, errores y rendimiento.

• Herramientas de rastreo del sitio antiguo.

• Registros del servidor, si están disponibles.

• Listado de enlaces externos relevantes.

El resultado debe ser una hoja de cálculo con una fila por URL. No es un trámite administrativo: será la base de las pruebas antes y después del lanzamiento.

Campo Del Mapa De URLEjemploPara Qué Sirve
URL antigua/blog/guia-seo.htmlIdentificar el recurso publicado
Tipo de contenidoArtículoAplicar la regla adecuada
URL nueva/blog/guia-seo/Definir el destino final
AcciónMantener o 301Indicar la respuesta esperada
Estado previsto200, 301, 404 o 410Validar el resultado técnico
PrioridadAltaRevisar primero páginas críticas

Planificar El Mapa De URL Y La Estructura De WordPress

La fase de planificación es donde se decide si la nueva instalación respetará el historial del sitio o lo borrará accidentalmente. Aquí no hace falta publicar todavía. Hace falta definir reglas claras.

Crear Equivalencias Reales, No Redirecciones Masivas

Cada URL antigua debería recibir una de estas decisiones:

  1. Se mantiene: la URL existe en WordPress y devuelve un estado 200.
  2. Se redirige a un equivalente: la URL antigua devuelve un 301 hacia una página nueva con la misma finalidad.
  3. Se retira sin sustituto: devuelve 404 o, en casos justificados, 410.
  4. Se consolida: varias URLs muy similares se dirigen a una única página nueva y relevante.

La diferencia entre una consolidación y una redirección indiscriminada es importante. Supongamos que se elimina una página sobre “mantenimiento de tiendas online”. Redirigirla a una página específica de mantenimiento puede tener sentido. Redirigirla a la portada solo porque “no hay otra página” puede frustrar a quien llega desde un enlace guardado.

Una cadena de redirecciones también debe evitarse. El recorrido ideal es:

URL antigua → URL final

No conviene crear este otro recorrido:

URL antigua → URL temporal → URL nueva → URL final

Cada salto añade tiempo, complica el rastreo y hace más difícil detectar fallos. Si ya existe una redirección antigua, hay que actualizarla para que vaya directamente al destino final.

Configurar WordPress Sin Alterar Las Rutas Necesarias

En WordPress, las URL de entradas y páginas dependen principalmente de los enlaces permanentes, los slugs y las reglas de reescritura del servidor. Antes de importar contenido, conviene decidir qué estructura necesita el proyecto.

Por ejemplo, si la web anterior publica artículos en /blog/nombre-del-articulo/, la configuración y la organización del contenido deben reproducir esa ruta. Si las categorías deben aparecer en la URL, hay que valorar si esa estructura resulta sostenible. Cambiarla después obligaría a crear nuevas redirecciones.

El traslado técnico de WordPress requiere revisar la configuración del sitio, las constantes WP_HOME y WP_SITEURL, los enlaces permanentes, .htaccess y las reglas de reescritura. La guía de migración técnica de WordPress Developer Resources también aconseja hacer una copia del archivo .htaccess antes de modificarlo y probar las redirecciones después.

Esto es especialmente relevante si se usan reglas personalizadas de Apache. Un .htaccess nuevo generado por WordPress puede funcionar para las entradas estándar, pero no necesariamente conservará reglas antiguas para PDFs, directorios especiales o rutas heredadas.

La reconstrucción debe incluir, como mínimo:

• Páginas, entradas y tipos de contenido personalizados.

• Categorías, etiquetas y archivos cuando sus URLs sean públicas.

• Imágenes, documentos y otros archivos enlazados desde contenido antiguo.

• Títulos SEO, metadescripciones, canonicals y datos estructurados que sigan siendo pertinentes.

• Enlaces internos, menús, llamadas a la acción y referencias a recursos descargables.

Para proyectos en los que el diseño, la estructura editorial y la configuración técnica deben avanzar coordinados, esta guía sobre desarrollo y diseño web con WordPress amplía el enfoque de construcción de una web mantenible.

Tratar Las URL Secundarias Como Parte Del Proyecto

Muchas migraciones validan las páginas principales y olvidan rutas que también pueden recibir tráfico o enlaces. No siempre será necesario conservarlas todas, pero sí decidir qué debe ocurrir con ellas.

Tipo De URLDecisión HabitualComprobación Necesaria
Archivos multimediaMantener o redirigir si están enlazadosRevisar imágenes y documentos antiguos
Categorías y etiquetasMantener si aportan navegación o tráficoEvitar archivos vacíos o duplicados
PaginaciónRecrear si tiene contenido indexable útilVerificar enlaces next y prev internos
FeedsMantener si existen suscriptores o integracionesComprobar la respuesta del feed
Búsquedas internasNormalmente no indexarEvitar generar miles de URLs rastreables
URLs con parámetrosEvaluar según función y tráficoNo redirigir campañas sin necesidad

No hay una regla universal para todos estos tipos. Una tienda con enlaces externos a fichas de producto necesita revisar cada producto retirado con mucho más detalle que una web corporativa con pocas páginas. La decisión depende de la función de la URL, su tráfico, sus enlaces y la posibilidad de ofrecer un sustituto útil.

Gestionar Dominios Temporales Y Enlaces Internos

Un error habitual ocurre cuando la web se construye en un dominio temporal, como proyecto.servidor.com, y luego se asigna el dominio definitivo. Cambiar el dominio principal no corrige automáticamente los enlaces escritos dentro de páginas, botones, imágenes o campos personalizados.

WordPress.com advierte que establecer el dominio principal no sustituye por sí solo los enlaces que aún apuntan a un dominio temporal. Por eso, antes de abrir la nueva versión al público, hay que buscar y sustituir esas referencias de manera controlada, incluidos recursos multimedia y enlaces insertados manualmente.

Ejecutar, Probar Y Supervisar La Migración

La publicación no debería ser la primera vez que se prueba el sitio. Una migración fiable se valida en tres estados: antes del cambio de DNS, durante la transición y después de que la nueva versión sea pública.

Ilustración del proceso de prueba local de un dominio antes de cambiar el DNS durante una migración.

Probar El Dominio Real Antes Del Cambio De DNS

Un entorno de staging permite revisar contenidos y funciones, pero también interesa comprobar cómo responde el dominio real contra el nuevo servidor. Para ello puede utilizarse el archivo hosts del equipo de prueba. Esta técnica hace que solo ese ordenador resuelva el dominio hacia la IP nueva, sin cambiar el DNS público para el resto de usuarios.

La guía de WordPress.com explica que el archivo hosts permite probar localmente un dominio contra el servidor nuevo. Es útil para detectar recursos cargados desde el servidor anterior, certificados mal configurados o redirecciones que solo fallan al usar el dominio definitivo.

Una secuencia razonable de pruebas sería:

  1. Guardar una copia verificable del sitio anterior, sus archivos, su base de datos y su configuración.
  2. Migrar contenido y archivos a WordPress en un entorno aislado.
  3. Configurar slugs, enlaces permanentes y redirecciones según el mapa de URL.
  4. Probar la web con el dominio real mediante el archivo hosts.
  5. Revisar una muestra representativa y todas las URLs prioritarias.
  6. Cambiar el DNS cuando las pruebas sean satisfactorias.
  7. Supervisar respuestas, rastreo y tráfico durante los días posteriores.

Validar Estados HTTP, Enlaces Y Recursos

No basta con ver que la portada carga. Hay que comprobar qué devuelve el servidor cuando se solicita cada dirección antigua y nueva.

PruebaResultado CorrectoSeñal De Problema
URL conservadaEstado 200404 o redirección inesperada
URL modificada301 directo a la URL finalCadena de varios saltos
Página retirada404 o 410 cuando no existe equivalente301 genérico a la portada
URL HTTPSCarga segura sin avisosRecursos HTTP o certificado erróneo
Enlace internoLleva a una URL final válidaDominio temporal o enlace roto

También conviene revisar las barras finales. Si WordPress añade una barra y el servidor obliga a quitarla, puede crearse un bucle. El síntoma suele ser que el navegador informa de demasiadas redirecciones. La solución no es añadir más reglas al azar: hay que identificar qué capa está forzando cada versión, ya sea WordPress, .htaccess, el servidor web, una CDN o una configuración del hosting.

Después del lanzamiento, el sitemap XML ayuda a comunicar las URLs actuales, pero no sustituye al mapa de migración. Conviene enviar el sitemap actualizado en Search Console y vigilar errores de cobertura, páginas no encontradas, cambios de indexación y evolución del tráfico hacia las URLs prioritarias.

La revisión posterior encaja dentro de un trabajo más amplio de SEO técnico para mejorar el rendimiento, especialmente cuando hay que analizar rastreo, canonicals, tiempos de respuesta y errores de servidor.

Mantener Las Redirecciones Y Corregir Incidencias

No existe un plazo único, respaldado de forma universal, para retirar redirecciones. Mantenerlas durante un periodo prolongado suele ser prudente, sobre todo si reciben visitas, enlaces externos o solicitudes de rastreadores. La decisión de eliminarlas debería basarse en datos: tráfico registrado, enlaces activos, frecuencia de rastreo y ausencia sostenida de solicitudes.

Si una URL antigua sigue apareciendo en registros o recibe visitas desde enlaces externos, retirarla puede crear un 404 evitable. En cambio, una regla sin solicitudes durante mucho tiempo y sin enlaces conocidos puede reevaluarse con más tranquilidad. La clave es no eliminar redirecciones por calendario sin revisar su uso real.

Preguntas Frecuentes

¿Se Puede Pasar Una Web De Otro CMS A WordPress Manteniendo Exactamente Las Mismas URL?

Sí, siempre que WordPress pueda reproducir el dominio, la ruta y el slug antiguos. Si la estructura anterior contiene elementos que WordPress no puede generar de forma nativa, pueden ser necesarios ajustes adicionales o redirecciones 301. Lo importante es decidirlo URL por URL, no asumir que el cambio de CMS conserva automáticamente las direcciones.

¿Cuándo Necesito Una Redirección 301 Y Cuándo No?

No necesitas una 301 cuando la URL antigua sigue existiendo y devuelve un 200 correcto. La necesitas cuando la dirección cambia y existe una página nueva equivalente. Si el contenido desaparece sin sustituto útil, un 404 o 410 puede ser más honesto que redirigir a una página irrelevante.

¿Cómo Debo Trasladar Las URLs De Categorías, Etiquetas E Imágenes?

Primero hay que comprobar si esas URLs reciben visitas, tienen enlaces o forman parte de la navegación. Las categorías y etiquetas útiles pueden reproducirse en WordPress. Las imágenes y documentos deben conservar sus rutas o redirigirse si están enlazados desde contenido antiguo. No conviene decidir solo por estética: una URL de imagen puede estar incrustada en una web externa.

¿Qué Hago Si WordPress Añade O Quita La Barra Final?

Define una versión canónica y asegúrate de que WordPress, el servidor y cualquier CDN aplican la misma regla. Después prueba ambas variantes. Si una URL redirige repetidamente entre la versión con barra y sin barra, existe un conflicto de configuración que debe corregirse antes de publicar.

¿Cómo Detecto Cadenas O Bucles De Redirección?

Prueba las URLs antiguas y observa cada salto hasta la página final. Una cadena ocurre cuando hay varios redireccionamientos consecutivos. Un bucle ocurre cuando una regla devuelve al usuario a una URL ya visitada. Las herramientas de rastreo y las cabeceras HTTP ayudan a identificarlo, pero una muestra manual de URLs prioritarias sigue siendo útil.

¿Debo Redirigir Todas Las Páginas Eliminadas A La Portada?

No. Redirige solo cuando exista un destino claramente relacionado. Una página de servicio retirada puede dirigirse a un servicio equivalente; una guía obsoleta puede ir a una versión actualizada. Si no hay alternativa real, es preferible que el servidor comunique que el recurso ya no existe.

¿Qué Debo Revisar En Google Search Console Después Del Cambio?

Revisa la indexación, los errores de páginas no encontradas, las URLs excluidas, los sitemaps enviados y el rendimiento de las páginas que antes atraían tráfico. También conviene comparar las URLs antiguas y nuevas durante las primeras semanas para detectar destinos que no se estén rastreando o redirecciones que no funcionen como se esperaba.

Fuentes Y Referencias

  1. Google Search Central — Site Moves and Migrations: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
  2. WordPress Developer Resources — Migrating WordPress: https://developer.wordpress.org/advanced-administration/upgrade/migrating/
  3. WordPress.com — Cómo migrar tu web de WordPress a otro host: guía completa: https://wordpress.com/es/go/tutoriales/migrar-sitio-web-de-wordpress/
  4. WordPress.com — Migrar un sitio de WordPress al hosting de WordPress.com: https://wordpress.com/es/support/importar/pasar-de-wordpress-autoalojado-a-wordpress-com/
  5. WordPress.org España — Migrar mi web a WordPress: https://es.wordpress.org/support/topic/migrar-mi-web-a-wordpress/