Tu web se ha quedado obsoleta tecnológicamente — Qué migrar y qué dejar

Tu web tiene siete, diez, doce años. Lo sabes. Lo sabe quien la mira. Y lo sabe Google, aunque no te lo diga directamente. Pero rehacerla te suena a tirar dinero, perder URLs que sí están posicionadas y meterte en un fregado del que igual sales peor. Vamos a verlo con calma.

El error más común aquí es ir a los extremos. O no se toca nada porque «ya está mal pero al menos funciona». O se tira todo porque «necesita transformación digital». Las dos posturas son malas decisiones. Tu web vieja tiene activos que no se ven a primera vista — autoridad acumulada, URLs con tráfico residual, contenido que sigue siendo válido. Y tiene cosas que sí están frenando al negocio. La pregunta es separar unas de otras con criterio.

No te voy a hablar de «modernizar tu stack tecnológico». Te voy a dar la lista de comprobación con la que decido yo qué se migra y qué se queda en una web vieja, qué cosas tienen impacto real en negocio y cuáles son humo de creativo, y el plan paso a paso para hacer la migración sin que pierdas el SEO en el camino. Que es lo que más te asusta y donde más se mete la pata.

Primero, ¿hasta qué punto tu web está obsoleta de verdad?

Marca lo que se parezca a lo tuyo. Sin pensar mucho, lo primero que te suene.

Si has marcado tres o más, tu web pide intervención. Pero «intervención» no es lo mismo que «rehacer entera». Casi nunca lo es. Vamos a ver qué se toca y qué no.

Qué significa de verdad «obsoleto» en una web — y por qué nadie te lo explica bien

Hay tres capas de obsolescencia y conviene separarlas porque cada una se arregla de una forma muy distinta:

• Obsolescencia técnica. El CMS está en una versión vieja, los plugins están sin actualizar, el servidor usa una versión de PHP que ya no recibe parches de seguridad. Esto es real y tiene consecuencias: vulnerabilidades de seguridad, incompatibilidades, errores que aparecen sin avisar.
• Obsolescencia visual. El diseño huele a 2015. Tipografías serif raras, sliders gigantes, gradientes amarillos, fotos de stock con corbata. Esto afecta a la conversión, no al SEO directo. Importa, pero menos de lo que la gente piensa.
• Obsolescencia funcional. No carga bien en móvil, no es accesible, no tiene buenas Core Web Vitals, no se entiende en 5 segundos. Esto sí afecta al SEO directamente y al negocio. Es donde más impacto hay por euro invertido.

Qué hay que migrar sí o sí — y qué se puede dejar

1. Migrar: el CMS y el servidor (sí o sí, sin discusión)

Si tu WordPress está en versión 4.x y tu PHP está en 5.6, no estás «anticuado», estás en peligro. Hay vulnerabilidades públicas que cualquier bot escanea para hackearte. Esto se migra ya, sin pensarlo más. Subir a las versiones actuales de PHP, MySQL y CMS es la primera capa.

Y aquí ojo con un mito: actualizar el CMS no rompe el SEO. Lo que rompe el SEO es cambiar URLs sin redireccionarlas, cambiar contenido sin cuidado, o cambiar la estructura de plantillas sin saber lo que toca. La migración técnica pura, bien hecha, no mueve nada en buscadores.

2. Migrar: el frontend si no es responsive

El móvil es el 70-80% del tráfico de la mayoría de webs hoy. Si tu web no es responsive (no se adapta a móvil), Google ya está penalizándote desde 2019 — usa el «mobile-first indexing», o sea que mira la versión móvil para decidir tus posiciones. Si tu versión móvil es regular, tu SEO es regular, sin más vuelta.

Esto se migra. La forma depende de tu CMS: si es WordPress, suele bastar con un tema moderno bien elegido y reconfigurar. Si es a medida, hay que rehacer las plantillas en HTML/CSS responsive. Es una semana de trabajo en webs medianas, no un proyecto de 6 meses.

3. Migrar: la velocidad si está por debajo del estándar

PageSpeed por debajo de 50 en móvil no es «lento aceptable», es «Google te tiene marcado». Las Core Web Vitals (LCP, INP, CLS) son métricas que Google usa para rankear. Una web por encima de 70 en móvil tiene ventaja sobre una por debajo de 30, en igualdad del resto.

Cómo se mejora: hosting decente (no compartido barato), imágenes en formato moderno (WebP/AVIF), eliminar plugins que no se usan, lazy loading bien implementado, reducir CSS y JS innecesarios. Esto suele ser un proyecto de 1-2 semanas si la web no es enorme.

4. Migrar: el certificado SSL y las redirecciones HTTPS

Si tu web aún muestra «no segura» en el navegador, es lo primero. Hoy un certificado SSL es gratis (Let’s Encrypt) y se instala en minutos. La parte más sensible es asegurarse de que TODAS las URLs de http redirigen 301 a https para no tener contenido duplicado. Esto se hace una vez y bien — no se vuelve a tocar.

Qué se puede dejar — y por qué tirarlo es un error

1. Las URLs que tienen tráfico orgánico

Cada URL con tráfico orgánico es un activo. Tirarla te quita ingresos. Mantenerla con su URL exacta y mover el contenido a la nueva versión es lo correcto. Cambiar URL solo cuando hay un motivo real (estructura mejor, idioma, etc.) y siempre con redirección 301 desde la vieja a la nueva.

Te pongo un caso. Una clínica en Valencia migró su web con un diseñador que decidió cambiar todas las URLs «porque ahora son más bonitas». Tres meses después: tráfico -45%, leads -38%. Tuvieron que hacer redirecciones masivas a posteriori para recuperar parte. La migración costó 3.500 €. Recuperar SEO les costó 4 meses. Eso es lo que pasa cuando se migra sin separar lo que se puede tocar de lo que no.

El contenido que sigue siendo relevante

Mucho contenido viejo sigue siendo válido. Hay posts de hace 6 años que generan leads cada mes. Tirarlos por «antiguos» es perder esos leads. Lo que sí hay que hacer: revisar fecha visible (algunos lectores se fían más de fecha reciente), actualizar datos obsoletos puntuales, mejorar formato si está hecho para pantalla del 2014.

Los enlaces externos hacia URLs específicas

Si tu web tiene 50 backlinks de webs sectoriales apuntando a URLs concretas, esas URLs son activos. Tirarlas es perder esos backlinks. Si por alguna razón cambian de URL, hay que redirigir 301 cada una de las URLs viejas a la nueva equivalente, una a una. No vale «redirigir todo a la home» — es lo más fácil pero te tira el SEO.

Las funcionalidades concretas que el cliente usa

Si tu web tiene una calculadora, un buscador, un sistema de citas que usan tus clientes, eso vale dinero. Tirarlo en una migración para «simplificar» porque el diseñador no sabe replicarlo es lo peor que puede pasar. Hay que migrarlo o reconstruirlo, no quitarlo.

Cómo decidir tú solo qué migrar y qué no (sin contratar nada)

Si tienes paciencia y dos tardes, esto sale tú solo. Lo cuento sin atajos:

1. Inventario técnico. Anota: qué CMS y qué versión, qué versión de PHP, qué tema o plantilla. Tu hosting te puede decir las versiones de PHP y MySQL en minutos.
2. Inventario de URLs. Exporta el listado de URLs publicadas. Saca de Search Console las que tienen tráfico orgánico en los últimos 12 meses. Las que tienen más de 50 clics/año son intocables — esas viajan tal cual a la nueva web.
3. Inventario de backlinks. Con Ahrefs Free, Ubersuggest gratis o el plugin Link Whisper, ve qué URLs reciben enlaces externos. Las que reciben backlinks son intocables — esas viajan tal cual.
4. Auditoría móvil. Abre PageSpeed Insights, mete la URL principal y 3-4 URLs internas. Apunta los scores de móvil. Si están todas por debajo de 50, prioridad alta. Si están entre 50 y 70, prioridad media. Si están por encima de 70, no es urgente.
5. Auditoría visual. Pide a tres personas (un cliente, un familiar, un competidor) que entren en tu web desde el móvil y te digan tres cosas: qué les ha gustado, qué les ha confundido, qué les ha hecho querer salir. Es la mejor auditoría UX gratuita.
6. Auditoría de funcionalidades. Lista qué funcionalidades tiene tu web (formulario de contacto, blog, área cliente, calculadora, lo que sea). Marca cuáles se usan de verdad y cuáles llevan años sin tocarse. Las primeras viajan, las segundas se quitan.

Con eso ya sabes mucho. Sabes qué urge migrar (lo técnico, lo móvil, lo de velocidad), qué hay que conservar tal cual (URLs con tráfico, URLs con backlinks, funcionalidades en uso), y qué se puede aprovechar para hacer mejor (la parte visual, la experiencia móvil, las páginas viejas).

Si fuera tu consultor la próxima semana, esto es lo que haría

El orden es importante porque migrar mal cuesta tres veces más que migrar bien. Este sería el calendario realista:

Semana 1. Auditoría técnica completa. Inventario CMS, plugins, hosting, versiones, vulnerabilidades. Inventario URLs con tráfico, URLs con backlinks, URLs con conversiones. Inventario funcionalidades en uso. Sale un documento de 5-10 páginas con la foto entera. Esto es la base.

Semana 2. Plan de migración con prioridades. Tres bloques: bloque urgente (seguridad y técnico), bloque importante (móvil y velocidad), bloque opcional (rediseño visual). Cada uno con tareas, riesgos, presupuesto y tiempo estimado. Tú decides qué bloques entran y cuáles se posponen.

Semana 3-4. Entorno de pruebas (staging). Clonar la web a un entorno paralelo donde se hace todo sin tocar la web en producción. Esto es obligatorio en migraciones. Quien te diga que va a hacer cambios «directamente en la web actual» porque es más rápido — fuera, te va a romper algo.

Semana 5-6. Migración técnica en staging. Subir CMS, subir PHP, instalar tema/plantilla nueva, configurar plugins limpios, importar contenido. Probar todo: formularios, integraciones, área cliente. Aquí se pasa el 60% del tiempo del proyecto. Y es lo que más cuesta y menos se ve.

Semana 7. Mapa de redirecciones. Si alguna URL cambia (idealmente ninguna), hacer el mapa origen → destino una a una. Si no cambia ninguna URL, este paso desaparece. Implementarlas en .htaccess o plugin de redirecciones.

Semana 8. Despliegue a producción. Pasar el staging a la URL real. Pruebas finales. Re-envío de sitemap a Search Console. Monitorización diaria los primeros 14 días.

Semana 9-12. Monitorización post-migración. Mirar a diario: tráfico orgánico, ranking de keywords prioritarias, errores en Search Console, Core Web Vitals. Cualquier alarma se trata el mismo día. Pasados 30 días tranquilos, la migración se considera cerrada.

Total realista: 8-12 semanas para una web mediana. Quien te diga que migra una web compleja en 2 semanas, o miente o no va a hacer el staging y vas a tener problemas. Quien te diga 6 meses, está alargando para facturar más.

Lo que no voy a hacer — y lo digo aquí para que me lo pidas si lo intento

• No te voy a vender rehacer todo desde cero sin comprobar antes qué activos tienes. Eso solo lo justifica si la web está rotísima a nivel de código y de seguridad. La gran mayoría de veces se migra sobre lo existente.
• No te voy a cambiar URLs sin necesidad real. Cambiar URLs solo por estética cuesta SEO. Si hay que cambiarlas por arquitectura mejor, hablamos del coste/beneficio antes y nunca al revés.
• No te voy a hacer la migración directamente en producción. Staging obligatorio, sin discusión. Lo contrario es jugar a la ruleta rusa con tu negocio.
• No te voy a vender una web «moderna» sin pensar en SEO. Si el rediseño no respeta CLS bajo, LCP rápido, indexabilidad, no es moderno — es bonito y poco funcional. Diseño y SEO van juntos siempre.
• No te voy a meter en una tecnología cerrada que te ate. Migrar a Webflow, Wix Premium o cualquier plataforma propietaria solo si entiendes lo que pierdes. Yo prefiero WordPress bien hecho — es estándar y te puedes ir cuando quieras.

Antes de migrar nada, mira si te encaja un diagnóstico técnico

Sin pago, sin permanencia, sin email en quince formularios. Te explico cómo va.

Yo dedico una semana a tu web. Hago el inventario técnico, el de URLs con tráfico, el de backlinks, el de funcionalidades, y miro tus Core Web Vitals reales. Te entrego un diagnóstico técnico con tres cosas: qué hay que migrar sí o sí (con riesgo y prioridad), qué se puede aprovechar tal cual, y un plan en 3 fases con tiempos y orden — para que sepas exactamente qué pedir cuando hables con quien sea que vaya a migrar.

Te quedas el documento aunque no contrates nada. Si te encajo, hablamos del Sprint SEO o del Renting según el tamaño del proyecto. Si no, te quedas el plan y se lo pasas a otro. Yo me ahorro horas con clientes que no encajan, tú te ahorras malas decisiones.

Pídeme el diagnóstico técnico aquí — te respondo en menos de 24 horas.

Preguntas que me hace gente con tu mismo problema

Lo siguiente que puedes hacer, ordenado por pereza

De menos a más esfuerzo:

1. 3 minutos: abre tu web desde el móvil, con datos móviles. Mide cuánto tarda en cargar la home. Si pasa de 4-5 segundos, ya tienes localizada una de las urgencias.
2. 10 minutos: mete la URL en PageSpeed Insights. Apunta el score móvil. Si es menos de 40, necesitas trabajar Core Web Vitals sí o sí. Si es entre 40 y 70, hay margen pero no es urgente. Si es más de 70, esto no es lo tuyo.
3. 1 hora: haz el inventario técnico básico. Apunta CMS y versión, PHP del servidor, listado de plugins, qué temas usas. Con eso ya sabes lo que está obsoleto a nivel infraestructura.
4. Una semana de mi tiempo (gratis): me cuentas tu caso, te preparo el diagnóstico técnico completo con plan de migración por fases. Sin compromiso, sin permanencia. Si te encajo, hablamos. Si no, te llevas el plan.

Esta es de las decisiones más caras de equivocar y de las más rentables de acertar. No es modernizar por modernizar — es migrar lo que sí afecta al negocio y conservar lo que ya está dando dinero. Una web vieja bien gestionada le gana muchas veces a una web nueva mal hecha. Ese es el punto que casi nadie te quiere contar porque es más difícil de vender que un rediseño completo.

Paul Cris Consultor SEO freelance · Valencia

Llevo diez años posicionando webs, ahora también para las IAs generativas. Trabajo con pocos clientes a la vez, sin agencia en medio y sin permanencia.

Saber cómo trabajo →