Hace tres años un cliente me llamó un jueves por la tarde en pánico absoluto. Había entregado una migración de Drupal a WordPress a una agencia dev barata, el sitio se lanzó un viernes, y el lunes su tráfico orgánico había caído un 67%. Desaparecido. Seis años de autoridad SEO, simplemente... evaporados. Sin redirecciones. Miles de URLs rotas. El presupuesto de rastreo de Google quemado.
Punto clave: las migraciones de Drupal a WordPress fallan en mapeo de URLs y traducción de taxonomías, no en el cambio de CMS; implementa un mapa de redirecciones completo y transporta metadatos para mantener los rankings.
He reconstruido ese tipo de desastres más veces de las que me gustaría contar. Después de más de 12,000 migraciones en Seahawk Media, puedo decirte con cierta confianza: el cambio técnico de Drupal a WordPress es en realidad la parte fácil. La preservación de SEO es donde todo se complica, y es donde absolutamente no tiene que ser así.
Esta es la guía que sigo. Siempre.
---
Por qué las migraciones de Drupal a WordPress son un campo minado SEO
Drupal y WordPress generan URLs de manera diferente. El sistema de rutas predeterminado de Drupal, combinado con módulos como Pathauto, a menudo produce estructuras de URL que no tienen ninguna coincidencia con lo que WordPress genera de fábrica. Un nodo de Drupal en /content/our-services/web-design se convierte en /our-services/web-design o incluso /web-design en WordPress, dependiendo de cómo configures los permalinks. Esas son URLs diferentes. Google las ve como páginas diferentes. Sin una redirección, la antigua está muerta.
Y no se trata solo de URLs. El sistema de taxonomía de Drupal se mapea a categorías y etiquetas de WordPress, pero no perfectamente. Los tipos de contenido personalizados en Drupal se convierten en Custom Post Types en WordPress, y si no construyes esos CPTs antes de migrar, tu contenido termina en el lugar equivocado completamente. He visto un sitio de noticias impulsado por Drupal donde 800 nodos "article" se importaron como Posts estándar de WordPress, sobrescribiendo la estructura de archivo personalizada en la que se basaba su enlazado interno.
Aquí está lo que la mayoría de los desarrolladores pasan por alto: cada decisión estructural que tomas en WordPress antes de la migración afecta directamente qué redirecciones necesitarás después. Consigue primero la arquitectura correcta. Las redirecciones son un parche, no un plan.
---
Paso 1: Auditoría previa a la migración, conoce qué estás moviendo antes de moverlo
No toques la instalación de Drupal hasta que tengas un rastreo completo del sitio en vivo. Uso Screaming Frog configurado para rastrear hasta 500,000 URLs (la versión de pago). Exporta todo: URLs, códigos de estado, títulos, metadescripciones, H1s, etiquetas canónicas, enlaces internos entrantes, conteos de palabras.
También extrae tus datos de Google Search Console. Filtra por clics en los últimos 16 meses (no 3, no 6-16, porque quieres captar contenido estacional). Exporta cada URL que haya recibido al menos un clic. Estas son tus URLs protegidas. Pierde posiciones en cualquiera de estas y el cliente lo notará.
Lo que estoy buscando específicamente:
- Contenido duplicado que ya existe en el sitio de Drupal (corregirlo antes de migrar, no después)
- Páginas de contenido delgado menores a 200 palabras que no posicionan para nada, estas pueden consolidarse o eliminarse en lugar de migrarse
- Patrones de URL no estándar como /node/1234 URLs que Drupal a veces expone incluso cuando Pathauto está activo
- Páginas de archivo de taxonomía que posicionan, rutas /tags/, /category/, /topic/ que tienen impresiones reales en Search Console
Ese último punto atrapa a la gente constantemente. Las páginas de términos de taxonomía de Drupal a menudo se posicionan para consultas de cola larga. Si no recreas archivos de taxonomía de WordPress equivalentes y redirige las rutas antiguas, acabas de tirar a la basura tráfico pasivo.
---
Paso 2: Mapeo de URLs, la hoja de cálculo que nadie quiere construir
¿Aburrido? Sí. ¿Innegociable? También sí.
Construye un mapa de URLs en Google Sheets (o Airtable si lo prefieres, he usado ambos). La columna A contiene cada URL de Drupal. La columna B es la URL de WordPress correspondiente a la que se resolverá. La columna C es un estado: coincidencia exacta, redirección necesaria, consolidar o eliminar.
Para un sitio de 300 páginas, esto toma media jornada. Para un sitio de 8,000 páginas, que Seahawk manejó para un cliente de educación superior en 2021, un equipo de tres personas tarda alrededor de cuatro días laborales más una noche de viernes muy tediosa. Vale la pena cada vez.
Algunas reglas que sigo:
- Preserva slugs siempre que sea posible. Si Drupal tiene /blog/how-to-fix-crawl-errors, haz que WordPress use el mismo slug. La mayoría de las veces puedes. Los ajustes de enlace permanente en WordPress Ajustes → Enlaces permanentes te permiten coincidir con cualquier patrón que Drupal estuviera usando.
- Nunca redirijas a la página de inicio. Los desarrolladores perezosos hacen esto. Mata el link equity y confunde a los usuarios. Cada URL antigua debe tener un destino específico.
- Ten cuidado con las URLs paginadas. La paginación de Drupal se ve como ?page=1. WordPress usa /page/2/. Mapéalas o déjalas como 404s (lo que generalmente está bien, las páginas paginadas rara vez tienen equity de enlace significativo, pero confirma primero en GSC).
- Consulta las cadenas de consulta por separado. Cosas como /search?keys=wordpress no necesitan redirecciones. /events?date=2023-06 tal vez sí, dependiendo de si esas páginas tienen posicionamiento.
---
Paso 3: Migración de contenido, FG Drupal to WordPress y qué sucede realmente
El plugin FG Drupal to WordPress hace el trabajo pesado en la mayoría de migraciones. Se conecta directamente a tu base de datos de Drupal, extrae nodos, usuarios, términos de taxonomía y medios. Para Drupal 7, funciona de maravilla. Para Drupal 9/10, necesitarás la versión premium, que cuesta alrededor de €99 la última vez que revisé. Vale cada euro comparado con una migración manual.
Lo que el plugin maneja bien:
- Contenido de cuerpo de nodos (incluyendo imágenes incrustadas si configuras correctamente la ruta de medios)
- Términos de taxonomía mapeados a categorías/etiquetas de WordPress
- Campos personalizados básicos si estás en el nivel premium
Lo que no manejará y tendrás que corregir manualmente:
- Drupal Views, estos son diseños/consultas de página personalizados. Los reconstruirás en WordPress usando plugins como WPGridBuilder o simplemente bucles WP_Query personalizados
- Formularios web, mapéalos a Gravity Forms o WPForms manualmente; la lógica no se transfiere
- Grupos de campos complejos, la Field API de Drupal soporta algunas estructuras de datos genuinamente raras. Tendrás que exportar estas a CSV e importar vía WP All Import
- Regiones de contenido en bloques, el sistema de bloques de Drupal no se parece en nada a los widgets de WordPress o bloques FSE. Decisión de diseño, no una tarea de migración
Una cosa que siempre hago después de que FG Drupal to WordPress termina: ejecuto un conteo de filas. ¿Cuántos nodos había en Drupal? ¿Cuántas entradas de posts/CPT hay ahora en WordPress? Deberían coincidir (menos todo lo que excluiste deliberadamente). Una discrepancia del 3% en un sitio de 5,000 nodos son 150 páginas faltantes. Ve a buscarlas.
---
Paso 4: Implementando Redirecciones Sin Destruir Tu Servidor
Una vez que el mapa de URLs está construido y el contenido está en vivo en el entorno de staging de WordPress, es hora de las redirecciones. Dos herramientas: el plugin Redirection para sitios más pequeños (menos de ~1,000 redirecciones) y reglas .htaccess para cualquier cosa más grande en Apache, o bloques nginx.conf en Nginx.
¿Por qué esta división? El plugin Redirection procesa redirecciones vía PHP, lo que significa un golpe al servidor por cada verificación de redirección. Con 5,000 redirecciones y 50,000 vistas de página diarias, ese es un overhead real. Las redirecciones a nivel de servidor son más rápidas por un orden de magnitud.
Para migraciones grandes, exporto el mapa de URLs desde Google Sheets, escribo un script rápido para generar los bloques RewriteRule, y los pongo en .htaccess antes del go-live. Toma 20 minutos. Ahorra horas de debugging en un sitio lento después del lanzamiento.
Una cosa en la que la gente no piensa: cadenas de redirecciones. Si Drupal ya tenía redirecciones en lugar (muchos sitios Drupal maduros las tienen, a través del módulo Redirect), necesitas encontrarlas y colapsar la cadena. A → B → C necesita convertirse en A → C. La propia documentación de Google es bastante clara en que las cadenas ralentizan la transferencia de PageRank, incluso si no la eliminan.
---
Paso 5: Post-Lanzamiento, la Ventana de 72 Horas
Lanza en martes o miércoles. Nunca viernes. Aprendí esto por las malas con un cliente en 2018, lanzamos una migración de 1,200 páginas un viernes por la tarde y descubrimos una estructura de permalinks mal configurada a las 6pm. Para el lunes, Google ya había rastreado e indexado una onda de URLs rotas.
Esto es lo que monitoreo en las primeras 72 horas:
- Informe de cobertura GSC, vigila un pico en 404s. Algunos son esperados (rutas antiguas del sistema Drupal). Un pico en tus páginas de dinero no lo es.
- Re-rastreo de Screaming Frog, rastrea el sitio WordPress en vivo la mañana después del lanzamiento. Compara el conteo de URLs con tu línea base pre-migración.
- Verificaciones spot de redirecciones, prueba manualmente tus 20 URLs de Drupal con mayor tráfico desde GSC. Pégalas en un navegador. ¿Aterrizan donde deberían?
- Etiquetas canónicas, confirma que WordPress está sacando el canónico correcto en cada página. Yoast y Rank Math lo hacen automáticamente, pero verifica de todos modos.
- Envío de sitemap XML, envía el nuevo sitemap en GSC inmediatamente. No esperes a que Google lo encuentre.
Una cosa que hago y que la mayoría de las personas omite: envía también el antiguo sitemap XML de Drupal en GSC después del lanzamiento, apuntando al dominio antiguo o subdominio si lo mantuviste activo temporalmente. Esto le dice a Google exactamente cuáles URLs antiguas rastrear, seguir las redirecciones y actualizar su índice más rápido.
---
Paso 6: La revisión de salud SEO de 30 días
Una migración no termina en el lanzamiento. El índice tarda tiempo en actualizarse. Esto es lo que reviso en el marcador de 30 días:
- Cambios en posición de ranking: usa Ahrefs o Semrush para comparar posiciones de palabras clave 30 días antes de la migración vs. 30 días después. Espera fluctuaciones menores (5-10 posiciones) en algunos términos. Una caída de 30+ posiciones en una palabra clave principal requiere investigación.
- Objetivos de backlinks: si tenías backlinks externos apuntando a URLs específicas de Drupal, verifica que esas URLs estén redireccionando correctamente. El reporte Lost Backlinks de Ahrefs expone esto. Los objetivos de backlinks rotos son equity de enlaces que estás perdiendo activamente.
- Regresión de velocidad de página: los sitios WordPress a veces son más lentos que sitios Drupal bien ajustados. Ejecuta una auditoría de Lighthouse en tus 5 páginas más importantes y compara con tu línea base pre-migración.
- Tasa de indexación: ¿cuántas de tus URLs enviadas están indexadas? A los 30 días, quieres al menos 80% de tus páginas de contenido principal indexadas. Cualquier cosa por debajo de 60% sugiere un problema de rastreabilidad (revisa robots.txt y asegúrate de que no bloqueaste accidentalmente a Googlebot en WordPress Configuración → Lectura).
Seahawk tuvo un cliente fintech el año pasado donde la revisión de 30 días reveló que 340 páginas de producto habían sido accidentalmente configuradas como noindex por una acción masiva de Yoast mal configurada durante la migración. Detectado a los 30 días: reparable en una tarde. Detectado a los 6 meses: probablemente un agujero de posicionamiento que aún estás intentando llenar.
---
FAQ
¿Cuánto tiempo lleva realmente una migración de Drupal a WordPress?
Depende enteramente del tamaño del sitio y complejidad del contenido. Un sitio brochura de 50 páginas: 2-3 días incluyendo QA. Un archivo de noticias de 5,000 páginas con tipos de contenido personalizados: 6-10 semanas. El trabajo SEO, auditoría, mapeo de URLs, implementación de redirecciones, monitoreo post-lanzamiento, típicamente suma 30-40% a cualquier estimación de desarrollo base. No dejes que nadie te diga lo contrario.
¿Perderé posiciones en los resultados después de migrar de Drupal a WordPress?
La fluctuación a corto plazo es normal e inevitable. Si has hecho el mapeo de URLs, redirecciones y etiquetas canónicas correctamente, la mayoría de rankings se estabilizan dentro de 6-12 semanas. Los sitios que he visto sufrir pérdidas permanentes todos tenían el mismo problema: sin redirecciones, o redirecciones en masa apuntando a la página de inicio. Haz el trabajo. Los rankings vuelven.
¿Debo migrar todo el contenido de Drupal o empezar de cero?
Depende de lo que el contenido está haciendo por ti. Extrae tus datos de GSC. Cualquier contenido con cero clicks en 16 meses y sin backlinks es candidato para eliminación en lugar de migración. Migrar contenido delgado y de bajo valor infla tu sitio WordPress y puede diluir el crawl budget. Sé implacable. Dicho esto, nunca elimines una URL que tenga algún backlink externo, incluso si la página en sí es basura, redirecciónala a algo relevante.
¿Cuál es el mejor tema de WordPress para usar después de una migración de Drupal?
Honestamente, la elección del tema tiene casi ningún impacto en SEO si estás usando HTML bien estructurado y manteniendo la velocidad de página bajo control. Por defecto elijo GeneratePress por su markup limpio y overhead mínimo, o Kadence si el cliente quiere más flexibilidad de diseño. Evita temas con page builder pesado que generan 400KB de CSS no utilizado en cada carga de página.
¿Necesito un desarrollador o puedo hacerlo yo mismo?
¿Un sitio pequeño de menos de 50 páginas con contenido simple y sin tipos de post personalizados? Probablemente puedas manejarlo con FG Drupal to WordPress y el plugin Redirection, siguiendo los pasos anteriores. Para cualquier cosa más grande, o cualquier cosa con CPTs, taxonomías complejas, o una huella SEO existente significativa, contrata a un developer. El costo de arreglar una migración fallida siempre es mayor que el costo de hacerlo correctamente la primera vez.
---
La migración en sí es quizás 40% del trabajo. El otro 60% es la infraestructura SEO que construyes alrededor de ella, el mapeo, las redirecciones, el monitoreo, la paciencia para observar los datos durante 30 días antes de declarar victoria. He visto sitios WordPress hermosamente construidos hundirse en búsqueda porque el trabajo de redirecciones fue descuidado, y he visto instalaciones WordPress desaliñadas y apenas temáticas mantener cada ranking porque el mapa de URLs fue meticuloso.
Haz las cosas aburridas correctamente. El resto tiende a seguir.