Esto no es una historia inventada. Es una puesta en producción que salió mal. El sitio cayó, las URLs antiguas desaparecieron en el aire, y nadie había planeado una estrategia de redirecciones. Cero. Nada. El tipo de situación donde miras la pantalla y te preguntas si reconvertirte en barista es realmente tan complicado.
El problema concreto: el nuevo sitio tenía una estructura de URLs completamente diferente. Todas las direcciones antiguas devolvían 404. Páginas de productos, artículos del blog, fichas de categorías… desaparecidos. Y desde el punto de vista del SEO, no es solo doloroso, es catastrófico.
Primero, respirar
El pánico no sirve de nada. Lo que está roto se puede arreglar, siempre que no cometas más errores bajo el estrés.
Lo primero es abrir Google Search Console. No para llorar ante los errores, sino para tener una lista limpia de todas las URLs indexadas por Google. Exportación en CSV, y se guarda.
Después, la Wayback Machine. Si el sitio antiguo fue crawleado (y probablemente lo fue), puedes encontrar allí URLs que ni siquiera habrías pensado en buscar. Es tu red de seguridad histórica.
El SQL que salva el día
La verdadera operación de rescate ocurrió en la base de datos.
El sitio antiguo funcionaba con WordPress. Todas las URLs de artículos, páginas, productos… están en la tabla wp_posts, en el campo guid y en post_name. Un SELECT bien dirigido y tienes tu lista completa en 30 segundos.
SELECT ID, post_title, post_name, guid, post_type, post_status
FROM wp_posts
WHERE post_status = 'publish'
AND post_type IN ('post', 'page', 'product')
ORDER BY post_type, post_name;Resultado: una tabla limpia con todos los slugs publicados. Exportas a CSV, abres en una hoja de cálculo, y empiezas a construir tu tabla de correspondencia slug antiguo > slug nuevo.
Si también tienes categorías o taxonomías que recuperar, las tablas wp_terms y wp_term_taxonomy son donde tienes que ir.
Montar las redirecciones sin ahogarse
Una vez que tienes la lista, hay que implementar los 301. Dos opciones según tu configuración.
Si estás en Apache, escribes las reglas directamente en el .htaccess. Una línea por redirección, limpio y rápido para volúmenes pequeños.
Si tienes cientos de redirecciones, usa un plugin dedicado como Redirection o Yoast (si ya lo tienes). La importación CSV está hecha para eso, no tienes que escribir todo a mano.
En cualquier caso, la regla de oro: no dejes una URL popular devolviendo 404 durante más de 24 horas. Cada hora que pasa, el jugo SEO se evapora.
Lo que se debería haber hecho antes
Seamos honestos, todo esto se puede evitar. No del todo, pero en gran parte.
Antes de cualquier migración o puesta en producción que toque las URLs, hay que crawlear el sitio antiguo con Screaming Frog o Sitebulb. Obtienes la lista completa de URLs activas, la cruzas con la nueva arquitectura, y preparas el archivo de redirecciones antes de hacer el cambio.
Son dos horas de trabajo. Dos horas que evitan una noche sin dormir recuperando una crisis.
Otro reflejo simple: hacer un dump SQL de la tabla wp_posts el día antes de la migración. Por si acaso. Tarda tres minutos y puede ahorrar horas.
La lección
Las redirecciones no son una opción post-migración. Son una etapa completa del proyecto, igual que las pruebas o las copias de seguridad.
Cuando un sitio cambia de estructura, Google no hace la conexión solo. Eres tú quien le explica adónde fueron las páginas. Si nadie lo hace, Google considera que esas páginas ya no existen. Y reconstruir la autoridad SEO perdida lleva meses.
La buena noticia: con las herramientas adecuadas y un poco de SQL, incluso una catástrofe de puesta en producción se puede recuperar. Llevó una noche. Pero se arregló.