Migrar de WordPress a Drupal sin perder posicionamiento

Cambiar el CMS de un sitio que ya rankea bien en Google España da vértigo, y con razón. Una migración mal ejecutada puede borrar de un plumazo años de autoridad acumulada: URLs que dejan de existir, metadatos que se pierden, una arquitectura de enlaces que se desmorona. Pero migrar de WordPress a Drupal sin perder posicionamiento es perfectamente factible cuando el proceso se trata como un proyecto SEO tanto como técnico. La clave no está en el día del lanzamiento, sino en las semanas de auditoría previa y en la disciplina con las redirecciones.

En Tangram Consulting hemos acompañado a empresas españolas en este salto precisamente porque Drupal resuelve problemas que WordPress, llegado cierto tamaño, empieza a arrastrar. A continuación detallamos por qué tiene sentido el cambio, qué riesgos SEO acechan y cómo planificar una migración que conserve —e incluso mejore— las posiciones orgánicas.

Por qué migrar de WordPress a Drupal

WordPress es excelente para arrancar rápido y para proyectos editoriales sencillos. El problema aparece cuando el sitio crece: catálogos extensos, varios idiomas, flujos editoriales con roles, integraciones a medida. Ahí Drupal juega en otra liga.

Escalabilidad y rendimiento

Drupal está diseñado para manejar volúmenes altos de contenido y de tráfico sin convertirse en un castillo de plugins que se pisan entre sí. Su sistema de caché nativo (con BigPipe, Dynamic Page Cache e integración directa con Varnish) responde mejor bajo carga que una instalación de WordPress repleta de extensiones de terceros. Para el SEO esto importa de forma directa: el Core Web Vitals (LCP, INP, CLS) pesa en el ranking, y un Time to First Byte bajo y estable ayuda a que Googlebot rastree más páginas en cada visita. Un sitio que responde en milisegundos consume mejor el crawl budget.

Seguridad y mantenimiento

El equipo de seguridad de Drupal publica avisos coordinados y la arquitectura del núcleo reduce la superficie de ataque que en WordPress suelen abrir los plugins sin mantenimiento. Para una empresa española sujeta al RGPD y, en muchos casos, al Esquema Nacional de Seguridad, esto no es un detalle menor. Un sitio comprometido (spam inyectado, redirecciones maliciosas) puede acabar penalizado o desindexado, así que la robustez del CMS también es una cuestión de protección del posicionamiento.

Contenido estructurado y multilingüe

Aquí está la ventaja diferencial. Drupal modela el contenido mediante tipos, campos y taxonomías de forma nativa. Eso permite definir entidades ricas (productos, servicios, casos de éxito, fichas) con datos limpios y reutilizables, ideales para generar datos estructurados Schema.org coherentes. El multilingüe forma parte del núcleo: gestionar español, catalán, euskera, gallego o inglés con URLs y metadatos independientes por idioma es mucho más sólido que la pila de plugins multilingüe típica de WordPress. Para sitios que compiten en varias comunidades autónomas o en mercados internacionales, esto se traduce en un hreflang bien gobernado y sin duplicidades.

Los riesgos SEO de una migración

Toda migración mueve piezas que Google tiene memorizadas. Si no se controlan, el resultado es una caída de visibilidad que puede tardar meses en recuperarse. Los riesgos más habituales:

• URLs huérfanas: páginas antiguas que rankeaban y que, tras el cambio, devuelven 404 sin redirección. Es la causa número uno de pérdida de tráfico.
• Cadenas y bucles de redirección: redirecciones que apuntan a otra redirección, diluyendo autoridad y ralentizando el rastreo.
• Pérdida de metadatos: títulos y descripciones que se regeneran automáticamente y borran un trabajo de optimización previo.
• Cambios en la arquitectura de enlazado interno: si el nuevo sitio reorganiza menús y enlaces, la distribución de PageRank interno cambia y algunas páginas pierden fuerza.
• Datos estructurados rotos o ausentes: schema que no se migra y hace desaparecer los rich snippets.
• Bloqueos accidentales: un robots.txt o una etiqueta noindex del entorno de staging que se cuela en producción y desindexa el sitio entero.

Cada uno de estos riesgos tiene una contramedida concreta dentro del plan que describimos a continuación.

Plan paso a paso para migrar sin perder posicionamiento

1. Auditoría e inventario completo de URLs

Antes de tocar nada, hay que saber qué tenemos. Se rastrea el sitio WordPress actual con Screaming Frog SEO Spider y se cruza con el sitemap.xml existente y, sobre todo, con los datos de Google Search Console (informe de Rendimiento y de Cobertura/Páginas). El objetivo es obtener un inventario maestro de todas las URLs indexadas, ordenadas por:

• Clics e impresiones reales en Google España (las que más tráfico aportan son prioritarias).
• Backlinks entrantes (con una herramienta como Ahrefs o Semrush) para no perder enlaces externos.
• Tipo de contenido (entradas, páginas, categorías, etiquetas, archivos de medios).

De esta auditoría sale la lista que gobernará todo lo demás. Una página con cien enlaces entrantes y miles de clics mensuales no puede tratarse igual que una etiqueta vacía.

2. Mapa de redirecciones 301

Este es el corazón de la migración. Por cada URL antigua que cambie de dirección se crea una redirección 301 (permanente) hacia su equivalente exacto en el nuevo sitio. La regla de oro es 1:1: cada URL antigua a la URL nueva más específica y relevante, nunca todas al home, porque una redirección masiva a la portada Google la interpreta como un soft 404 y no transfiere autoridad.

En Drupal esto se gestiona con el módulo Redirect, que permite crear redirecciones individuales y verificar que no se generan cadenas. Si la estructura de URLs se conserva idéntica (mismo patrón de slugs), muchas páginas no necesitarán redirección, lo cual es el escenario ideal. Cuando sí cambian, conviene:

• Documentar el mapa en una hoja de cálculo (origen → destino → código).
• Evitar cadenas: la 301 debe apuntar al destino final, no a otra redirección.
• Conservar la coherencia con o sin barra final y con o sin www.

3. Preservar metadatos y estructura de alias

El posicionamiento descansa en gran medida sobre los títulos, descripciones y URLs limpias. En Drupal:

• Metatag replica y gestiona los <title>, meta descripciones, Open Graph y etiquetas canónicas. Se migran los valores optimizados que ya tenía cada entrada de WordPress, no se dejan en automático.
• Pathauto genera alias de URL legibles y consistentes (por ejemplo /servicios/consultoria-drupal), replicando los patrones que ya funcionaban. Si las URLs de WordPress eran limpias, se reproduce ese mismo esquema para minimizar redirecciones.

Preservar la etiqueta canónica de cada página evita problemas de contenido duplicado durante la transición.

4. Migración de contenido con Migrate API

Mover el contenido a mano en un sitio grande es inviable y propenso a errores. Drupal incorpora la Migrate API en el núcleo, y con los módulos migrate_plus y migrate_tools (más conectores específicos de WordPress) se automatiza el traspaso de entradas, páginas, categorías, etiquetas, autores y medios desde la base de datos o el export XML de WordPress. Esto garantiza que:

• Los identificadores y las relaciones (autor, taxonomía) se conservan.
• Las fechas de publicación originales se mantienen, lo que importa para la frescura percibida.
• El contenido se mapea a los tipos y campos correctos de Drupal.

Una migración programática es además repetible: se puede ejecutar en staging tantas veces como haga falta hasta que el resultado sea perfecto.

5. Conservar la jerarquía y el enlazado interno

La arquitectura de la información transmite señales de relevancia. Hay que reproducir la jerarquía de categorías y la estructura de menús del sitio antiguo, y revisar que los enlaces internos dentro del cuerpo de los artículos sigan apuntando a destinos válidos (idealmente a las URLs nuevas directas, no pasando por redirecciones). Un buen reparto de enlazado interno concentra autoridad en las páginas que más interesa posicionar.

6. Datos estructurados y Schema.org

Si el sitio de WordPress mostraba rich snippets (FAQ, breadcrumbs, artículos, productos), esos datos estructurados deben recrearse en Drupal. Gracias al contenido estructurado nativo, generar JSON-LD coherente con Schema.org resulta más limpio: se mapean los campos de cada tipo de contenido a las propiedades del marcado. Conviene validar el resultado con la prueba de resultados enriquecidos de Google antes del lanzamiento.

7. Sitemap XML y robots.txt

Con el módulo Simple XML Sitemap se genera un nuevo sitemap.xml que refleje exclusivamente las URLs definitivas y canónicas (sin las redirigidas). El robots.txt debe permitir el rastreo de lo que importa y —punto crítico— no arrastrar ninguna directiva Disallow: / ni noindex heredada del entorno de pruebas. Este error, banal en apariencia, ha desindexado sitios enteros.

8. Pruebas en staging

Nada se publica sin validar primero en un entorno de staging idéntico a producción. Allí se comprueba con Screaming Frog que:

• Todas las redirecciones 301 del mapa funcionan y devuelven 200 en el destino final.
• No hay cadenas ni bucles de redirección.
• Los metadatos están en su sitio y no hay noindex de más.
• El sitemap es correcto y los datos estructurados validan.

El staging debe estar protegido (autenticación HTTP o bloqueo por IP) para que Google no lo indexe por accidente y genere duplicados.

9. Lanzamiento y verificación inmediata

El día del cambio, idealmente en una franja de bajo tráfico, se publica el sitio, se activan las redirecciones en producción y se vuelve a rastrear todo. Acto seguido se envía el nuevo sitemap a Google Search Console y se solicita la indexación de las páginas clave. Una verificación en las primeras horas confirma que las URLs prioritarias responden 200 y que las antiguas redirigen correctamente.

Tabla de elementos a preservar

Elemento	Herramienta en Drupal	Qué se conserva
URLs y alias	Pathauto + Redirect	Mismos slugs o 301 1:1
Títulos y descripciones	Metatag	Meta optimizada existente
Etiqueta canónica	Metatag	Señal anti-duplicado
Contenido y taxonomías	Migrate API / migrate_plus	Entradas, categorías, autores, fechas
Enlazado interno	Revisión manual + body	Distribución de autoridad
Datos estructurados	JSON-LD / Schema.org	Rich snippets
Sitemap XML	Simple XML Sitemap	Solo URLs canónicas
Reglas de rastreo	robots.txt	Sin bloqueos heredados

Checklist de migración SEO

• [ ] Inventario maestro de URLs cruzando Screaming Frog, sitemap y Search Console.
• [ ] Lista priorizada por clics, impresiones y backlinks (Google España).
• [ ] Mapa de redirecciones 301 documentado, 1:1 y sin cadenas.
• [ ] Módulo Redirect configurado y verificado en staging.
• [ ] Metadatos migrados con Metatag (títulos, descripciones, canónicas).
• [ ] Alias limpios reproducidos con Pathauto.
• [ ] Contenido migrado con Migrate API conservando fechas y relaciones.
• [ ] Jerarquía de menús y enlazado interno revisados.
• [ ] Datos estructurados Schema.org recreados y validados.
• [ ] Sitemap XML regenerado solo con URLs canónicas.
• [ ] robots.txt limpio, sin noindex ni Disallow: / de staging.
• [ ] Rastreo completo en staging sin 404 ni bucles.
• [ ] Lanzamiento, nuevo sitemap enviado a Search Console e indexación solicitada.
• [ ] Monitorización post-lanzamiento programada para varias semanas.

Monitorización post-migración en Search Console

El trabajo no termina con el lanzamiento; empieza una fase de vigilancia que conviene mantener durante al menos seis a ocho semanas. En Google Search Console se revisan:

• Cobertura / Indexación de páginas: vigilar que las nuevas URLs entran en el índice y que las antiguas salen progresivamente. Picos de páginas excluidas o errores de servidor son señal de alarma.
• Errores 404 y soft 404: cualquier 404 que aparezca indica una URL antigua sin redirección; se corrige al instante añadiendo la 301 que falte.
• Rendimiento: comparar clics, impresiones y posición media frente a las semanas previas a la migración. Una caída pequeña y transitoria los primeros días es normal mientras Google reprocesa; una caída sostenida exige investigación.
• Estado de las redirecciones e Inspección de URL: usar la herramienta de inspección para confirmar cómo ve Google las páginas clave y forzar el recrawl de las prioritarias.

Acompañar estos datos con un nuevo rastreo periódico de Screaming Frog permite detectar problemas antes de que afecten al tráfico. Con un mapa de redirecciones riguroso, metadatos preservados y una arquitectura de contenido bien estructurada, la mayoría de migraciones recuperan su posición en pocas semanas y, gracias a la mejora de rendimiento y de datos estructurados que aporta Drupal, no es raro que terminen rankeando mejor que antes.

¿Estás planteándote dar el salto y quieres una migración auditada que proteja tu posicionamiento? Habla con nuestro equipo de consultoría Drupal.

Artículos relacionados

• Cómo migrar tu sitio web de WordPress a Drupal sin perder SEO ni contenido
• Migrar de WordPress a Drupal: guía completa con costes y pasos
• Migrar web de WordPress a Drupal: ventajas y guía