Solucionar problemas de SEO tras una migración de WordPress: empieza con la URL real

TL;DR: Es muy probable que tu migración de WordPress no “arruinara el SEO”. Lo que se rompió fue la ruta entre las URL antiguas, las nuevas, las redirecciones, las etiquetas canónicas, los sitemaps, los enlaces internos y, ahora, las citas de IA. La solución empieza validando las URL, no lanzando otra auditoría de plugins.

La migración no mató tu SEO. La historia rota de URL sí.

La mayoría diagnostica los problemas de wordpress migration seo desde el extremo equivocado. Preguntan si la caída la provocó WordPress, el nuevo tema, el hosting o el plugin SEO. A veces alguno participó, casi siempre porque interrumpió la continuidad de las URL.

En mindnow he visto migraciones donde el contenido estaba intacto y, aun así, las posiciones cayeron porque 600 URL antiguas apuntaban silenciosamente a la home. Compruebo eso antes de abrir seojuice.io o vadimkravcenko.com.

Las victorias más rápidas suelen ser aburridas: URL antigua, URL nueva, código de estado, canónica, indexabilidad, inclusión en sitemap y enlaces internos. Ese es el orden — no títulos, no schema, no Core Web Vitals.

Joost de Valk, fundador de Yoast SEO, definió una migración de dominio exitosa como “90 % preparación y 10 % ejecución”. Esa frase sirve también tras un mal lanzamiento: si la preparación no se hizo antes del corte, la reparación es esa preparación en diferido.

El trabajo consiste en demostrar que Google aún puede conectar la demanda antigua con los nuevos destinos. Si no puede, reescribir textos es puro teatro.

Primero clasifica la caída antes de arreglar nada

No todos los descensos de tráfico post-migración tienen la misma causa. Un cambio de hosting, dominio, permalinks, tema, importación de CMS o reemplazo de plugin SEO pueden generar el mismo gráfico: sesiones orgánicas abajo y todos nerviosos.

El primer desvío diagnóstico es simple. ¿Google perdió la URL, desconfía de la nueva URL o entendió mal la relación entre ambas?

No reescribas contenido hasta saber si Google puede acceder, entender y confiar en la nueva URL. Un post con noindex no necesita mejor titular. Una categoría canónica al dominio antiguo no necesita más texto. Una landing redirigida que termina en la home no necesita schema.

Clasifica primero. Luego repara.

Reconstruye el mapa de URL, aunque la migración ya haya ocurrido

John Mueller dio la versión más clara en una sesión de Google SEO Office Hours citada por Search Engine Journal:

“Creo que lo más importante es rastrear las URL individuales, de modo que tengas un mapa claro de lo que existía y lo que debería existir en el futuro.”

“URL individuales” importa en WordPress. No se trata solo de posts y páginas. WordPress crea superficies a través de temas, plugins, archivos, comportamiento de medios, filtros y viejos permalinks de respaldo. Si migraste solo la estructura visible del menú, probablemente dejaste medio sitio atrás.

Superficies de URL en WordPress que la gente olvida

• Entradas y páginas
• URLs de productos WooCommerce, categorías de producto y la base /shop
• Categorías, etiquetas y taxonomías personalizadas
• Archivos de autor
• Archivos por fecha si eran indexables
• Páginas de adjuntos y URLs de medios
• Archivos de tipos de contenido personalizados
• Archivos paginados
• URLs de feeds
• Viejos permalinks ?p=123 (sí, aún resuelven en instalaciones antiguas)
• Variantes con y sin barra final
• Variantes HTTP a HTTPS
• Variantes www y sin www
• URLs de staging o hosts temporales que se filtraron

Empieza con evidencias, no con memoria. Exporta landing pages de Analytics. Exporta páginas principales de Search Console. Rastrea el sitio actual. Recupera cualquier rastreo previo a la migración, si existe. Añade URLs con backlinks desde tu índice de enlaces. Luego fusiona todo en un único mapa viejo-a-nuevo.

Sí, esta es la parte aburrida de la hoja de cálculo — también donde inician la mayoría de las recuperaciones (las auditorías que rescaté en mindnow siempre se reducían a una columna ausente en la hoja anterior de otro). Usa columnas para URL antigua, URL nueva, estado HTTP, destino de redirección, destino canónico, indexabilidad, inclusión en sitemap y notas. Si no hay destino equivalente, indícalo. No lo escondas tras un fallback a la home.

En sitios grandes, prioriza URL con backlinks, ingresos, clics orgánicos, conversiones o citas de IA. Un archivo de etiquetas muerto de 2017 puede esperar. Una categoría de producto que generaba ventas non-brand no.

Arregla las redirecciones antes de tocar títulos, copys o schema

La documentación oficial de Google para cambios de sitio dice:

“Mantén las redirecciones el mayor tiempo posible, generalmente al menos 1 año.”

Esa línea debería imprimirse sobre cada checklist de migración WordPress. Las redirecciones desaparecen de forma aburrida: alguien borra el bloque .htaccess, se desactiva un plugin de redirección durante la limpieza, un cambio de hosting elimina reglas Nginx, Cloudflare sustituye page rules, expira el dominio antiguo, se borra el dominio de staging. Nadie lo nota hasta que Search Console parece la escena de un crimen.

Una redirección solo sirve si el destino responde a la misma intención. Post antiguo → post nuevo. Producto antiguo → producto equivalente. Categoría antigua → categoría equivalente. Página de servicio antigua → página de servicio superviviente más cercana. Si el destino es irrelevante, el 301 técnico no conserva el valor SEO.

Si necesitas un proceso, usa este:

1. Rastrea tu lista de URL antiguas y registra cada código de estado.
2. Marca cada cadena 3xx de más de un salto.
3. Marca cada URL antigua que aterrice en la home.
4. Comprueba si el destino final es indexable.
5. Confirma que la página final se autocanibaliza o apunta a la canónica prevista.
6. Mueve las redirecciones de alto valor a reglas de servidor o edge, fuera de plugins frágiles cuando sea posible.

Si usas un plugin, exporta sus reglas antes de tocar nada. Redirection, Rank Math, Yoast Premium y los paneles de redirección del hosting funcionan. El problema suele ser la propiedad: nadie sabe qué capa manda.

La redirección a la home no es una red de seguridad

La guía de Google advierte contra redirigir muchas URL a un destino irrelevante, como la home, porque puede tratarse como un Soft 404. En WordPress es habitual: un administrador ve cientos de 404 en un plugin y crea un fallback global a /. El dashboard queda limpio — el tráfico de búsqueda empeora.

La solución es más lenta pero más segura. Empareja URL antiguas con el destino equivalente más cercano. Si no hay equivalente, devuelve un 404 o 410 real. Deja morir honestamente las URL muertas. Protege las importantes con redirecciones uno-a-uno.

Esto duele especialmente en migraciones de ecommerce. Un producto descatalogado quizá merezca redirigir a su sustituto o a la categoría madre. Un producto eliminado sin sustituto puede merecer un 410. Redirigirlo a la home no enseña nada a Google.

Vigila la ventana de 180 días del Change of Address

La herramienta Change of Address en Search Console ayuda a Google a procesar un traslado, pero no sustituye las redirecciones. La ayuda oficial dice que la herramienta procesa señales durante 180 días tras iniciar la migración (no para siempre).

Pasado ese periodo, Google no considera los sitios relacionados si el antiguo sigue online y rastreable. La lección práctica es simple: las redirecciones deben sobrevivir al Change of Address. Si el antiguo hosting se apaga en el mes 5, creas un precipicio.

Revisa los ajustes de WordPress que bloquean en silencio la recuperación

WordPress rara vez rompe una página aislada. Rompe plantillas. Diagnostica por tipo de página, no por muestreo aleatorio de URL.

Empieza con el ajuste obvio porque aún causa estragos: Ajustes → Lectura → Disuade a los motores de búsqueda de indexar este sitio. Los sitios de staging lo tienen activado. Un lanzamiento apresurado puede arrastrarlo a producción. Lo mismo con reglas de noindex en plugins SEO heredadas del staging.

Luego revisa las canónicas. Una reconstrucción de tema o importación de plugin puede dejar etiquetas canónicas apuntando al dominio antiguo, al host temporal o al idioma equivocado. Inspecciona el HTML renderizado, no solo el campo del plugin. La caché puede servir etiquetas obsoletas tras “arreglarse” en el admin.

Sitemaps merecen la misma sospecha. Los plugins SEO de WordPress dividen sitemaps por tipo de post y taxonomía. Tras la migración, quizá tengas URLs limpias de posts en un sitemap y URLs de categorías del dominio antiguo en otro. Envía el índice de sitemaps y luego abre cada hijo manualmente.

Robots.txt es otro asesino silencioso. Bloquear /wp-content/ puede impedir que Google cargue CSS, JS o imágenes necesarios para entender la página. Bloquear una ruta de plantilla puede dañar grupos enteros. Bloquear todo el sitio aún sucede tras lanzar staging: lo he visto más de una vez.

Los permalinks son peores porque parecen decisión de contenido. Pasar de /%postname%/ a /blog/%postname%/ sin redirecciones crea una migración de URL dentro de la migración. Cambiar la base de categorías, quitar la barra final o alterar la base de productos de WooCommerce hace lo mismo.

Revisa también el orden de reglas de redirección, reglas de CDN, salida de plugins multilingües, objetivos hreflang, URLs de filtros de WooCommerce, comportamiento de páginas de adjuntos, paginación, migas de pan y archivos de CPT. Una plantilla rota puede suprimir cientos de URL.

Si esto suena a checklist de auditoría SEO técnica, bien. La recuperación post-migración es una auditoría técnica con fecha y lista de sospechosos.

Recupera páginas que desaparecieron del índice de Google

Elige una página valiosa que perdió tráfico. No veinte. Una.

Inspecciona primero la URL antigua. ¿Devuelve 301? ¿Hay cadena? ¿Aterriza en la URL nueva correcta? ¿El destino carga para Googlebot? Luego inspecciona la URL nueva. Confirma código de estado, canónica, directivas robots, HTML renderizado, enlaces internos, inclusión en sitemap y última fecha de rastreo.

Usa la herramienta de Inspección de URL de Search Console en la versión en vivo, no solo la indexada. La versión indexada muestra lo último que almacenó Google. La prueba en vivo muestra lo que ahora puede obtener.

Después escala por plantilla. Si un post migrado tiene la canónica incorrecta, quizá todos los posts migrados la tengan. Si una categoría de producto está noindex, quizá todas lo estén. Si un archivo de autor vuelve a ser indexable, cada archivo de autor puede estar creando thin content de nuevo.

La validación en Search Console es lenta (días o semanas, no horas). La mejor señal temprana es el comportamiento de rastreo. Revisa logs si los tienes. ¿Se siguen solicitando URL heredadas redirigidas? ¿Llega Googlebot a los destinos finales? ¿Caen los 404 de URL antiguas de alto valor?

Las posiciones suelen recuperarse por grupos. Si las categorías de producto reparadas vuelven a rastrearse y las impresiones regresan, aplica la misma solución al resto del set. No sigas cambiando cosas no relacionadas mientras el primer arreglo aún se procesa.

Las citas de IA añaden un segundo problema de migración

Joost de Valk lo resumió bien:

“No existe un Change of Address para un modelo que terminó de entrenar un año antes de tu traslado.”

Google puede rastrear redirecciones. Search Console procesa migraciones. Los LLM y motores de respuesta con IA pueden seguir almacenando dominios o URL antiguas en datos de entrenamiento, índices de recuperación, índices de partners o capas de citación en caché. Un 301 limpio ayuda a Google, pero no reescribe cada cita antigua guardada en otro sitio.

No hay magia: mantén vivas las redirecciones. Haz que las URL antiguas resuelvan en el mejor destino nuevo. Actualiza perfiles de alta autoridad, páginas canónicas fuente, schema de organización, referencias sameAs, sitemaps XML y enlaces internos. Cuando sea posible, actualiza citas en plataformas que los sistemas de IA suelen ingerir.

Esto importa más para WordPress de lo que se admite (yo mismo lo subestimé años). Muchas migraciones dependen de plugins o reglas de hosting que se limpian tras tres meses. Si las citas de IA siguen apuntando a URL antiguas, esas redirecciones son el puente. Si lo rompes, la cita queda en un callejón sin salida.

Para más limpieza, revisa las guías de SEOJuice sobre cadenas de redirección y 301, buenas prácticas de sitemaps XML y errores de etiquetas canónicas.

Plan de reparación de 14 días para el SEO tras la migración de WordPress

Puedes recuperar una migración desordenada sin intentar arreglarlo todo a la vez. El orden importa más que la pila de herramientas.

Día 0 a 1: corta la hemorragia

• Confirma la propiedad del dominio antiguo, hosting antiguo, DNS, CDN y propiedades de Search Console.
• Restaura el control de redirecciones antes de editar contenido.
• Desactiva redirecciones catchall a la home.
• Elimina etiquetas noindex y bloqueos en robots accidentales.
• Envía sitemaps limpios del nuevo sitio.
• Prueba manualmente una muestra de URL antiguas de alto valor.

Si ya no controlas el dominio antiguo, la recuperación se complica rápido. Recupéralo antes de debatir títulos.

Día 2 a 4: reconstruye el mapa

• Crea la tabla de URL antiguas → nuevas.
• Prioriza URL con backlinks, clics orgánicos, ingresos, conversiones y citas de IA.
• Separa por tipo: posts, páginas, productos, categorías, etiquetas, medios, archivos, feeds.
• Corrige redirecciones por lotes, empezando por los grupos de más alto valor.
• Vuelve a probar cada lote tras publicarlo.

No confíes en “todas las redirecciones se importaron”. Rastrea la lista.

Día 5 a 7: repara plantillas

• Audita canónicas por tipo de página.
• Revisa directivas robots y reglas noindex.
• Comprueba títulos, headings, schema, migas de pan y enlaces internos.
• Revisa paginación y plantillas de archivos.
• Confirma objetivos hreflang si aplica.
• Prueba categorías, productos y filtros de WooCommerce.

Aquí una revisión técnica de WordPress se paga sola. Buscas fallos de plantilla, no rarezas puntuales.

Día 8 a 14: demuestra la recuperación

• Monitorea cobertura y estadísticas de rastreo en Search Console.
• Revisa logs para ver actividad de Googlebot en redirecciones heredadas.
• Controla rankings por grupo de URL, no solo por keyword.
• Compara landing pages en Analytics antes y después de la reparación.
• Mantén notas de cada cambio en redirecciones, plantillas y sitemaps.

Si el tráfico mejora en los grupos reparados, aplica la misma solución. Si nada cambia, deja de hacer ajustes aleatorios y revisa el mapa.

Qué no hacer tras una mala migración de WordPress

No instales tres plugins SEO más. Crearás canónicas superpuestas, sitemaps duplicados y reglas de redirección sin dueño.

No redirijas cada 404 a la home. Google ha sido claro: las redirecciones masivas irrelevantes pueden convertirse en Soft 404.

No cambies la estructura de permalinks otra vez porque la actual “se ve más limpia”. Las URL limpias no sirven si siguen cambiando.

No reescribas contenido antes de arreglar acceso, redirecciones, canónicas e indexabilidad. La calidad de contenido no compensa una ruta rota.

No elimines redirecciones antiguas porque “Google ya lo habrá entendido”. La guía de Google dice mantenerlas tanto como sea posible, al menos un año.

No tomes el ranking de la home como prueba de que la migración está bien. La recuperación de marca puede ocultar el colapso de plantillas. Revisa las landing que atraían tráfico non-brand.

Si las URL antiguas no pueden explicar adónde fueron, Google no tiene por qué adivinar.

FAQ

¿Cuánto tarda la recuperación SEO tras una migración de WordPress?

Arreglos pequeños pueden mostrar cambios de rastreo e impresiones en días. La recuperación de rankings suele tardar más porque Google debe volver a rastrear URL antiguas, procesar redirecciones, actualizar canónicas y reconstruir la confianza en el nuevo conjunto de URL. En sitios grandes, piensa en semanas, no horas.

¿Debo volver a enviar mi sitemap después de una migración de WordPress?

Sí, pero solo cuando el sitemap esté limpio. Enviar un sitemap lleno de URL del dominio antiguo, URL con noindex o canónicas discordantes puede ralentizar el diagnóstico. Abre el índice y los sitemaps hijos manualmente antes de enviarlos.

¿Bastan los 301 para conservar rankings?

Son necesarios, pero no lo son todo. El destino debe ser relevante, indexable, enlazado internamente, canónico correcto y estar en sitemaps limpios. Un 301 hacia una página débil o irrelevante aún puede perder tráfico.

¿Qué pasa si cambié la estructura de permalinks en WordPress?

Trátalo como una migración de URL. Crea un mapa de cada permalink antiguo a su nuevo destino. Incluye bases de categoría, barra final, bases de producto, paginación y fallbacks ?p=123 si resuelven.

¿Puedo borrar el hosting antiguo tras la migración?

Solo si las redirecciones están gestionadas en otro sitio y probadas. Muchos sitios pierden tráfico porque el hosting antiguo era el único lugar con redirecciones. Antes de desmantelar nada, rastrea URL antiguas y confirma que aún resuelven bien.

Conclusión: el manual de reparación debió ser la checklist de lanzamiento

La recuperación de una migración WordPress no es glamourosa. Es contabilidad de URL, disciplina de redirecciones, chequeos de plantillas y paciencia. La misma checklist que repara la caída debió existir antes del lanzamiento.

En seojuice.io rige la misma regla. La continuidad aburrida de URL supera la limpieza heroica. Usa este artículo dos veces: ahora para reparar la migración actual y, de nuevo, antes de la próxima.

¿Necesitas ayuda para encontrar la rotura?

Si tu migración de WordPress bajó el tráfico orgánico y aún no ves la causa, empieza con el mapa de URL y la auditoría de redirecciones. SEOJuice puede convertir el pánico en una cola de reparaciones y luego en la checklist de lanzamiento de la próxima migración.