Cómo migrar de WordPress a una web a medida sin perder posicionamiento

Se migra de WordPress a una web a medida sin perder posicionamiento haciendo una cosa aburrida y sin atajos: inventariar todas las URL que tienen tráfico, montar una redirección 301 de cada URL antigua a su equivalente nueva, conservar los slugs que ya rankean, publicar un sitemap limpio y avisar a Google en Search Console. El SEO no se cae por cambiar de tecnología; se cae por perder las direcciones que Google ya tenía indexadas. Si esas direcciones siguen respondiendo, ahora con un 301 hacia el contenido correcto, la autoridad viaja con ellas. Esto no es teoría: es el mismo proceso que seguí para migrar este propio sitio fuera de WordPress, y lo cuento partida a partida.

Por qué se pierde SEO al migrar, y por qué casi siempre es evitable

El buscador no indexa tu web, indexa tus URL. Cada página que posiciona es una dirección concreta que Google ha visitado, ha entendido y ha decidido mostrar para ciertas búsquedas. El día que cambias de plataforma, si esa dirección deja de existir o cambia sin avisar, Google llega, se encuentra un 404 y, tras insistir un tiempo, la retira del índice. Ahí es donde desaparece el tráfico, no en el cambio de tecnología.

La causa número uno de una migración que hunde el posicionamiento es esta: las URL nuevas no coinciden con las viejas y nadie montó las redirecciones. WordPress genera direcciones con su propia estructura, /2021/07/mi-articulo/, /?p=345, /categoria/producto/, y una web a medida las genera a su manera. Si no construyes el puente entre ambas, cada enlace que otras webs te hicieron y cada resultado que Google guardaba apuntan al vacío.

La buena noticia: es evitable casi al cien por cien. Una redirección 301 le dice al buscador "esto se ha mudado permanentemente a esta otra dirección", y Google transfiere la señal de posicionamiento al destino. Bien hecho, el usuario ni se entera y el buscador tampoco lo penaliza. La caída que mucha gente da por inevitable es, casi siempre, trabajo que no se hizo.

Paso 1: inventario completo de URL antes de tocar nada

Antes de construir la web nueva, necesito saber exactamente qué direcciones tiene la vieja y cuáles importan. Este inventario es la columna vertebral de toda la migración: si una URL con tráfico no está en la lista, nadie la va a redirigir y se perderá.

Reúno las URL de varias fuentes, porque ninguna sola las tiene todas:

• Google Search Console. El informe de Rendimiento me da las páginas que reciben clics e impresiones reales. Estas son las intocables: las que de verdad traen tráfico.
• Un rastreo del sitio. Una herramienta de crawling recorre la web como lo haría Google y saca el listado completo de URL vivas, incluidas las que no aparecen en el menú.
• El sitemap actual de WordPress. Suele estar en /sitemap.xml o /sitemap_index.xml y lista lo que el propio WordPress considera indexable.
• Google Analytics. El histórico de páginas vistas destapa direcciones antiguas que aún reciben visitas desde enlaces externos o marcadores.

Con todo eso monto una hoja de cálculo con una columna clave: la URL antigua, sus impresiones y clics de los últimos doce meses, y una columna vacía para la URL nueva. Ordeno por tráfico de mayor a menor. Así veo de un vistazo cuáles son las diez o veinte páginas que sostienen tu posicionamiento y cuáles son ruido que puedo consolidar o dejar morir con dignidad.

Paso 2: conservar los slugs que ya rankean

Aquí tomo la decisión más rentable de toda la migración: qué slugs mantengo tal cual. El slug es la parte legible de la URL, /cuanto-cuesta-una-pagina-web frente a /?p=832. Si una página posiciona bien con su slug actual, mi criterio por defecto es no tocarlo. La regla es simple: no cambio lo que ya funciona solo por estrenar estructura.

Cuando construyo una web a medida tengo control total sobre cómo se generan las rutas, cosa que en WordPress vive escondida entre ajustes de enlaces permanentes y plugins. Ese control es precisamente lo que me permite hacer que la nueva /servicios/desarrollo conserve el slug con el que Google ya te conoce, en lugar de heredar una estructura arbitraria. Es una de las ventajas silenciosas del desarrollo de software a medida: decides tú la arquitectura de URL, no un tema comprado.

Ahora bien, migrar es también la ocasión de arreglar lo que WordPress dejó feo: fechas incrustadas en la URL, categorías duplicadas, direcciones interminables. Cuando decido mejorar un slug, no lo abandono: la vieja dirección tendrá su 301 hacia la nueva. Cambiar el slug con redirección conserva casi toda la señal; cambiarlo sin redirección la tira a la basura. La diferencia entre ambas cosas es una línea en el mapa de redirecciones.

Paso 3: el mapa de redirecciones 301, una a una

Esta es la parte que no admite atajos y donde se gana o se pierde la migración. Cada URL antigua con valor necesita su redirección 301 individual hacia la URL nueva que le corresponde en contenido. No sirve mandarlo todo a la home: eso Google lo interpreta como una redirección blanda, casi un 404, y no transfiere posicionamiento. El destino de cada 301 tiene que ser la página equivalente, la que responde a la misma intención de búsqueda.

Mi orden de trabajo es este:

1. Relleno la columna "URL nueva" de la hoja para cada dirección antigua, emparejando por contenido. Artículo con artículo, servicio con servicio, categoría con la página que la sustituye.
2. Para lo que desaparece sin sustituto claro, decido: o lo redirijo a la página temáticamente más cercana, o si es irrelevante y sin tráfico, lo dejo devolver un 410 (contenido eliminado a conciencia).
3. Implemento las 301 en el servidor, no con un plugin. En una web a medida las redirecciones viven en la configuración del servidor o en el router de la aplicación, que es más rápido y no depende de terceros.
4. Verifico cada redirección con una comprobación de cabeceras HTTP: la URL antigua debe devolver un código 301 y una cabecera Location apuntando exactamente a la nueva, sin saltos intermedios. Una cadena de tres redirecciones diluye la señal; busco siempre el salto directo.

Este mapa es un entregable en sí mismo. Cuando termino, ninguna dirección con valor de tu WordPress se queda sin destino.

Paso 4: sitemap nuevo y Search Console

Con la web nueva publicada y las 301 en su sitio, genero un sitemap XML limpio que liste solo las URL nuevas y canónicas, las que quiero que Google indexe. Nada de URL antiguas, nada de páginas redirigidas, nada de parámetros basura. Un sitemap sucio manda señales contradictorias; uno limpio es un mapa claro de tu web tal como quiero que se lea.

Después, el aviso formal al buscador en Search Console:

• Envío el nuevo sitemap en el informe de Sitemaps para que Google descubra la estructura nueva de una vez en lugar de a rastreos sueltos.
• Uso la Inspección de URL en las páginas más importantes, las diez o veinte de más tráfico del inventario, y solicito indexación manual. Esto acelera el reprocesado de lo que más te importa.
• Vigilo el informe de Cobertura las semanas siguientes. Ahí aparecen los 404 que se me hayan escapado. Cada error que salga es una URL que olvidé redirigir, y lo arreglo añadiendo su 301.

Si conservas el mismo dominio, no hace falta la herramienta de cambio de dirección de Search Console: esa es solo para mudanzas de dominio. Lo que sí mantengo es la misma propiedad verificada para no perder el histórico de datos.

Qué vigilar las semanas siguientes

Una migración no se acaba el día del deploy; se acaba cuando los números se estabilizan. Durante las cuatro a seis semanas posteriores es normal ver algo de fluctuación en las posiciones mientras Google reprocesa y consolida las señales de las 301. Eso no es una caída, es el buscador recalculando, y suele recuperarse solo si el trabajo de redirecciones está bien hecho.

Lo que reviso con lupa en ese periodo: el informe de Cobertura de Search Console por si aparecen 404 nuevos, la evolución de clics e impresiones de las páginas clave del inventario, y que ninguna redirección se haya roto o encadenado. Si el tráfico de una página concreta se hunde y no se recupera, casi siempre hay una 301 mal apuntada detrás; se localiza en el inventario y se corrige.

El plazo real de una migración así depende del tamaño del sitio, pero el bloque de inventario, mapa de redirecciones y verificación suele moverse en el rango de una jornada para webs pequeñas hasta varios días de trabajo en sitios con cientos de URL. Si quieres un orden de magnitud en euros, lo trato como trabajo puntual con estimación cerrada antes de empezar; los rangos y las condiciones están en la página de tarifas.

Conclusión

Migrar de WordPress a una web a medida sin perder posicionamiento no es cuestión de suerte ni de magia SEO: es método. Inventarías las URL con tráfico, conservas los slugs que rankean, montas una redirección 301 por cada dirección antigua hacia su equivalente exacta, publicas un sitemap limpio y avisas en Search Console. Hecho con ese orden, el buscador transfiere la autoridad y el usuario no nota el cambio salvo que ahora la web va más rápida y la controlas tú.

El error caro es dar el salto sin el mapa de redirecciones y descubrir la caída semanas después, cuando ya cuesta reconstruir qué apuntaba a dónde. Por eso el inventario se hace antes de tocar la web nueva, no después. Si tienes un WordPress que se te ha quedado corto y te frena el miedo a perder lo posicionado, ese miedo es legítimo pero gestionable: puedes ver quién va a hacer el trabajo y contarme tu proyecto para que revisemos juntos qué URL están en juego antes de mover nada.