Cada año recibimos tres o cuatro llamadas con la misma frase: «hemos cambiado la web hace un mes y hemos perdido la mitad del tráfico». Y casi siempre con la misma coletilla: «la agencia de diseño dice que el SEO se recupera solo».
No se recupera solo. Lo que ocurre en la mayoría de estos casos es que se han destruido, en una sola noche, entre tres y diez años de señales acumuladas: URLs que Google conocía, autoridad concentrada en páginas concretas, enlaces externos apuntando a rutas que ahora devuelven 404, contenido que desapareció en el rediseno porque «era demasiado texto».
La buena noticia es que una migración es de los pocos procesos del SEO que se controlan casi por completo. No depende de la competencia ni de un algoritmo: depende de una lista de tareas ejecutada con orden. Este artículo es esa lista, tal como la aplicamos en ValenciaSEO, con las tres fases y los puntos donde de verdad se pierde el tráfico.
La palabra suena a proyecto grande, pero el riesgo aparece en cambios que muchos equipos consideran menores.
| Cambio | Riesgo | Punto critico |
|---|---|---|
| Cambio de dominio | Alto | Redirecciones y consolidación de señales |
| Cambio de plataforma o CMS | Alto | Estructura de URLs y perdida de contenido |
| Rediseno con misma estructura | Medio | Contenido eliminado y enlazado interno |
| Reorganización de categorías | Alto | Mapa de redirecciones y canibalizacion nueva |
| Paso a HTTPS o cambio de www | Bajo si se hace bien | Cadenas de redirecciones y recursos mixtos |
| Añadir idiomas | Medio | Hreflang, canonicals y duplicidad |
El «solo rediseno» que mantiene las URLs. Como nadie toca rutas, nadie llama al SEO. Y en el proceso desaparecen dos mil palabras de texto por página, el menú se reduce «para que quede limpio» y con el se van doscientos enlaces internos. Las URLs siguen ahi; lo que Google valoraba, no.
Aquí se gana o se pierde el proyecto. Todo lo que no captures ahora sera irrecuperable después.
Si no encuentras destino equivalente para una URL critica, el problema no es de redirecciones: es que el sitio nuevo no cubre algo que el viejo si cubría. Resuelvelo creando la página, no redirigiendo a cualquier sitio.
El dia del despliegue el trabajo es de comprobación, no de creación. Estos son los cinco puntos que revisamos siempre, en este orden, dentro de la primera hora.
robots.txt y meta robots. El error más repetido de la industria: el sitio de pruebas tenia Disallow: / o noindex global y ha subido tal cual. Se comprueba antes que nada porque invalida todo lo demás.
Las redirecciones funcionan de verdad. No basta con que existan en un fichero. Se prueban las cincuenta URLs criticas una por una y se verifica que devuelven 301 —no 302, no 200 con contenido distinto— y que llegan al destino en un solo salto. Las cadenas de tres redirecciones diluyen y ralentizan.
Canonicals correctos. Cada página apuntando a si misma, no a la versión antigua ni a un dominio de pruebas. El canonical apuntando a staging es un clásico que puede desindexar un sitio entero.
Sitemaps regenerados y enviados. Con las URLs nuevas, sin las viejas. Un sitemap con la mitad de las entradas devolviendo 301 es una señal de descuido.
Enlazado interno reconstruido. Comprueba que las páginas criticas siguen recibiendo enlaces internos desde donde los recibían. Es el punto que más se olvida y el que explica muchas caídas «inexplicables» en rediseños que mantuvieron las URLs.
Una vez verificado todo, envía el sitemap nuevo y las URLs criticas a indexar, y vigila el registro de bots los primeros días. Cuanto antes rastree Google las redirecciones, antes transfiere las señales y más corta es la caída. Es de los pocos momentos donde la indexacion rápida cambia el resultado de forma tangible.
Aquí es donde la mayoría de proyectos se declaran terminados y donde en realidad empieza el trabajo útil. Lo que hay que vigilar, y con que frecuencia:
| Cuando | Que se mira | Que se espera |
|---|---|---|
| Dias 1-3, cada dia | Errores 404, visitas de bots, indexacion de las URLs criticas | Bots rastreando activamente; pico de 404 controlado y decreciente |
| Semana 1 | Clics e impresiones por URL frente a la línea base | Caída del 10-25%. Es normal y no justifica revertir nada. |
| Semanas 2-4 | Posiciones del conjunto de consultas | Fluctuación alta, recuperación progresiva |
| Semana 4 | Comparativa completa contra el antes | 70-90% del tráfico recuperado |
| Semana 8 | Balance final | Nivel anterior o superior; si no, hay un problema concreto que localizar |
Sobre la paciencia: la tentación de intervenir en la semana dos es enorme y casi siempre contraproducente. Si las comprobaciones del lanzamiento están bien, lo que se ve en esas semanas es reprocesado, no daño. Intervenir a ciegas —revertir, cambiar canonicals, tocar redirecciones— alarga el proceso en lugar de acortarlo. La excepción es un fallo técnico detectado con dato: eso se arregla el mismo dia.
La mayoría de migraciones que salen mal no fallan por ignorancia técnica. Fallan por calendario y por reparto de responsabilidades, y conviene decirlo porque es la parte que se puede arreglar con una reunión.
El patrón habitual es este: el proyecto de rediseno arranca en enero, el SEO se entera en marzo, y la fecha de lanzamiento ya está comprometida con dirección. Cuando llega la petición de dos semanas para inventario y mapa de redirecciones, la respuesta es que no hay margen. Se lanza igualmente, se pierde tráfico, y en abril se contrata a alguien para arreglarlo por bastante más dinero del que costaba prevenirlo.
Tres acuerdos evitan casi todo esto. Primero: el SEO entra en el proyecto cuando entra el diseño, no cuando el sitio está terminado. Su trabajo en la fase temprana no es opinar sobre colores, es proteger las páginas que generan negocio y avisar cuando una decisión de estructura cuesta caro. Segundo: acceso a un entorno de pruebas real, con el contenido definitivo y bloqueado al rastreo, al menos dos semanas antes. Auditar sobre maquetas no sirve; los fallos aparecen con el contenido montado. Tercero: nadie lanza en viernes ni en vísperas de festivo. Suena trivial y es la causa de que un noindex heredado viva tres días en producción sin que nadie mire.
Y un cuarto que no es un acuerdo sino una precaución: mantén el sitio antiguo accesible durante unos días, aunque sea en un entorno interno. Cuando hay que comparar contenido perdido o reconstruir un bloque que desapareció, tener el original delante convierte una investigación de horas en una consulta de dos minutos.
Redireccion masiva a la home. Todas las URLs antiguas apuntando a la portada. Es la forma más rápida de perder todo. Google lo interpreta como que el contenido ya no existe.
Perdida de contenido en el rediseno. Páginas que tenían dos mil palabras y ahora tienen trescientas porque el diseño nuevo «es más limpio». El diseño mejoro; la relevancia desapareció.
Cambio de estructura sin necesidad. Reorganizar categorías porque al equipo nuevo le parece más lógico, sin datos que lo respalden. Cada cambio de URL cuesta señales; hacerlo sin motivo es pagar sin comprar nada.
Olvidar los recursos. Imágenes, PDF y documentos que también tenían tráfico y enlaces, y que nadie incluyo en el mapa. En sectores con catálogos y fichas técnicas esto puede ser una parte notable del tráfico.
No conservar el histórico. Se cambia de propiedad, de dominio o de herramienta y se pierde el antes. A partir de ahi, nadie puede demostrar si la migración salio bien o mal, y la discusión se vuelve política.
Si la propuesta no incluye una partida explicita para inventario de URLs, mapa de redirecciones y vigilancia posterior, esas horas no están presupuestadas y por tanto no se van a hacer. Pedirlo antes de firmar cuesta una frase; arreglarlo después cuesta meses.
El diagnóstico se hace en este orden, y en la mayoría de casos se resuelve en el primer o segundo punto.
noindex heredado del entorno de pruebas. Se arregla en cinco minutos y se recupera en dos semanas.Clics por URL, posiciones y estado de indexacion. Diez minutos de trabajo ahora que valen por semanas de discusión después. La capa de analítica es gratuita.
Entrar en Semalt Ver la analíticaEntre un 10% y un 25% durante las primeras semanas, con recuperación completa en cuatro a ocho. Una caída mayor o una recuperación que no llega apuntan a un fallo concreto, no a la migración en si.
301 siempre que el cambio sea permanente, que es el caso en una migración. El 302 se reserva para cambios realmente temporales.
Como mínimo un año; en la práctica, indefinidamente si no molestan. Los enlaces externos antiguos siguen enviando tráfico durante muchísimo tiempo.
Si, y en sitios grandes es lo recomendable: por secciones, verificando cada una antes de seguir. Reduce el riesgo y facilita aislar la causa si algo falla.
Reconstruyelo con los datos históricos de rendimiento por URL que aun conserves y con los informes de cobertura. Es peor que tenerlo, pero suficiente para localizar las URLs criticas rotas.
Una migración es uno de los pocos momentos del SEO donde el resultado depende casi por completo de la disciplina y no de la suerte. No hay competencia que te gane ni algoritmo que te castigue: hay un inventario que se hace o no se hace, un mapa de redirecciones que se revisa una por una o se genera a bulto, y cuatro semanas de vigilancia que se hacen o se sustituyen por esperanza.
Si tienes un rediseno o un cambio de plataforma en el horizonte, lo más rentable que puedes hacer hoy —antes que ninguna otra cosa— es congelar la línea base. Conecta tu dominio, guarda clics e impresiones por URL y las posiciones de tus consultas principales. Es media hora que puede ahorrarte medio año.
Y si el rediseno ya paso y estas en la parte incomoda, escríbenos: el diagnóstico de migración entra en la auditoría inicial gratuita, y en la mayoría de casos la causa aparece en el primer par de comprobaciones.
Analitica gratuita de Google Search, posiciones y respuestas de IA, mas indexacion rapida de tus paginas nuevas.
Entrar en Semalt semalt.comContactanos para una auditoria gratuita
