Tu web lleva años funcionando. El diseño se ha quedado antiguo, cuesta editar algunas páginas y quizá ya no representa bien a la empresa. Quieres modernizarla, mejorar la navegación o incluso reconstruir WordPress desde cero.
Pero hay un problema: esa web antigua ya recibe visitas desde Google.
Algunas páginas aparecen bien posicionadas, generan solicitudes de información, llamadas, reservas o ventas. Y surge una duda razonable:
¿Podemos rediseñar la web sin perder todo lo que ya hemos conseguido en SEO?
Sí, es posible reducir mucho el riesgo, pero no existe una garantía de que las posiciones permanezcan exactamente iguales después de un cambio importante.
La clave está en entender qué se va a modificar.
Cambiar colores, tipografías y presentación manteniendo las mismas páginas no tiene el mismo riesgo que eliminar contenidos, cambiar todas las URLs, reorganizar la arquitectura, sustituir el CMS y trasladar además el dominio.
Google recomienda precisamente no acumular grandes cambios simultáneos cuando pueden separarse. En sus recomendaciones sobre migraciones indica que, si vas a cambiar dominio, CMS y diseño, es preferible realizar los cambios por etapas. También advierte de que los cambios significativos pueden provocar fluctuaciones temporales mientras vuelve a rastrear y procesar las páginas.
Por tanto, un rediseño seguro empieza mucho antes de elegir la nueva plantilla.
Empieza protegiendo lo que ya funciona.
No necesariamente.
Si mantienes el mismo dominio, las URLs importantes, el propósito de las páginas, el contenido que aporta valor, el enlazado interno y una configuración técnica correcta, puedes cambiar profundamente el aspecto visual sin que eso implique automáticamente perder el posicionamiento.
Pero conservar las URLs tampoco garantiza por sí solo que nada vaya a cambiar.
Durante un rediseño pueden modificarse accidentalmente:
noindex;robots.txt;El problema rara vez es que «Google no quiera las webs nuevas».
El riesgo está en cambiar sin saber qué elementos de la web antigua estaban contribuyendo a que funcionara.
Antes de valorar el riesgo SEO hay que saber qué proyecto estás haciendo.
Podemos dividirlo en tres situaciones.
Por ejemplo:
Este suele ser el escenario más sencillo desde el punto de vista SEO.
No significa que puedas ignorar la revisión técnica, pero existen muchas menos piezas que trasladar.
Aquí el cambio es mayor.
Puedes sustituir:
La nueva web puede parecerse a la anterior en contenidos y URLs, pero técnicamente ser completamente diferente.
Eso puede ser perfectamente razonable cuando una instalación acumula muchos años de dependencias, componentes abandonados o modificaciones difíciles de mantener.
Si ese es tu caso, antes de mezclar ambos proyectos conviene revisar [cómo actualizar un WordPress antiguo sin romper la web]. Cómo actualizar un WordPress antiguo sin romper la web
Una cosa es modernizar el diseño.
Otra diferente es recuperar una instalación técnicamente obsoleta.
Y otra, hacer ambas cosas simultáneamente.
El riesgo aumenta cuando además cambian elementos como:
En este escenario ya no estamos hablando únicamente de diseño.
Estamos trasladando señales de unas URLs a otras.
Google recomienda preparar un mapa entre las URLs antiguas y las nuevas, actualizar enlaces internos y canonicals, utilizar redirecciones permanentes cuando corresponda, probarlas y monitorizar posteriormente el tráfico y la indexación.
Uno de los errores más importantes en un rediseño es empezar desde una hoja en blanco.
El diseñador recibe el encargo, prepara una navegación nueva y decide qué páginas conservar en función de lo que parece más ordenado.
Pero una URL visualmente poco interesante puede ser precisamente la página que está captando clientes desde Google.
Por eso necesitas un inventario previo.
Como mínimo, deberías identificar:
No tienes que conservar indefinidamente todo lo que aparece en esa lista.
Necesitas conocerlo antes de decidir qué eliminar.
Google Search Console permite consultar rendimiento por páginas y consultas, incluyendo clics, impresiones, CTR y posición media. Google recomienda analizar especialmente las tendencias de clics e impresiones y permite comparar periodos.
Antes del rediseño resulta útil exportar, al menos:
Así tendrás una referencia real para comparar después del lanzamiento.
Sin esa fotografía previa, si el tráfico cambia después será mucho más difícil saber qué se ha perdido, cuándo empezó y qué páginas están implicadas.
No.
Pero una URL que funciona no debería cambiar simplemente porque la nueva estructura parezca más bonita.
Por ejemplo, si ya tienes:
/reparacion-wordpress/
y la nueva web propone:
/servicios/desarrollo-web/servicio-reparacion-web-wordpress/
conviene tener una razón clara para realizar ese cambio.
No es necesario introducir una nueva jerarquía únicamente porque estés estrenando web.
Cuando una página mantiene:
conservar su URL evita tener que trasladarla.
Esto no significa congelar la arquitectura para siempre.
Significa que un cambio de URL debería responder a una necesidad real.
Para cada dirección antigua debes decidir qué ocurrirá.
Por ejemplo:
| URL antigua | Decisión | URL nueva |
|---|---|---|
/servicio-antiguo/ |
Mantener | /servicio-antiguo/ |
/pagina-vieja/ |
Sustituir | /nuevo-servicio/ |
/servicio-a/ |
Consolidar | /servicio-principal/ |
/contenido-obsoleto/ |
Eliminar sin equivalente | 404/410 |
Google recomienda crear precisamente este mapa antes de ejecutar una migración.
Cuando una URL cambia de forma permanente y existe una nueva página equivalente, Google recomienda utilizar redirecciones HTTP permanentes del lado del servidor cuando sea posible, como 301 o 308.
La idea importante para el propietario de la web no es memorizar los códigos.
Es esta:
la URL antigua debe llevar directamente a la nueva página que realmente la sustituye.
También conviene evitar cadenas como:
A → B → C → D
si puedes hacer directamente:
A → D
Google recomienda minimizar estas cadenas y dirigir la URL antigua al destino final.
Es una solución tentadora:
«Esta página ya no existe, así que la mando a la home».
Si eliminas 40 páginas, rediriges las 40 a inicio y aparentemente no queda ningún error.
Pero no es una buena solución cuando la portada no responde a la misma necesidad.
Google advierte específicamente contra redirigir muchas URLs antiguas hacia un único destino irrelevante, como la página de inicio, porque puede tratar esas respuestas como soft 404.
Si dos o tres artículos se fusionan en una nueva guía que realmente los sustituye, una redirección hacia esa guía puede tener sentido.
Si una página desaparece y no existe ningún contenido equivalente, devolver correctamente un 404 o 410 puede ser más apropiado que inventar una redirección.
Sí, pero no conviene tratar todo el contenido antiguo como material descartable simplemente porque llega un rediseño.
Una página puede necesitar:
Eso puede mejorar la página.
Lo que conviene evitar es cambiar simultáneamente diseño, intención, contenido, URL y arquitectura sin saber cuál de esos elementos estaba funcionando.
Si una página recibe tráfico relevante para una determinada necesidad, la nueva versión debería seguir respondiendo adecuadamente a esa necesidad salvo que exista una decisión estratégica para cambiarla.
Un problema habitual de ciertos rediseños es sustituir contenido real por:
El resultado puede parecer más moderno y al mismo tiempo explicar mucho menos.
El diseño debería ayudar al usuario a comprender la información, no eliminarla.
En [diseño web WordPress corporativo: más allá de la plantilla] explicamos por qué una web empresarial debería partir de los objetivos, usuarios, contenidos y arquitectura antes de escoger su presentación visual. Diseño web WordPress corporativo: más allá de la plantilla
No existe una regla que diga que cualquier modificación de un title o un H1 provoque una pérdida de posiciones.
Pero tampoco conviene borrar elementos importantes únicamente porque la nueva plantilla utiliza otra estructura.
Antes de modificar una página que ya recibe tráfico, averigua:
Después decide qué merece conservarse y qué puede mejorarse.
Un rediseño no debería convertirse accidentalmente en una reescritura total de todas las páginas sin haber realizado antes una auditoría de contenidos.
Las páginas de una web no viven aisladas.
Los enlaces que existen entre ellas ayudan al usuario a navegar y permiten a los buscadores descubrir y relacionar contenidos.
Cuando cambia la arquitectura, pueden desaparecer enlaces que llevaban años presentes.
Por ejemplo:
Antes:
Inicio → Servicio principal → Servicio específico → Caso práctico
Después:
Inicio → Servicios
y las páginas específicas quedan prácticamente aisladas.
Aunque continúen existiendo bajo la misma URL, has cambiado su relación con el resto del sitio.
Si modificas URLs, Google recomienda actualizar los enlaces internos para que apunten directamente a las nuevas direcciones en lugar de depender permanentemente de las redirecciones.
Por eso el rediseño debería revisar:
No reconstruyas únicamente las páginas.
Reconstruye también sus relaciones.
Una etiqueta canonical ayuda a indicar qué URL se considera principal cuando existen versiones duplicadas o muy similares.
Un error durante una migración puede provocar que la nueva web:
Google utiliza varias señales para determinar la URL canónica, incluyendo redirecciones, sitemaps y anotaciones rel="canonical".
Si las URLs cambian, Google recomienda además que las páginas nuevas utilicen canonicals coherentes con las nuevas direcciones.
Es una comprobación pequeña que puede evitar un problema grande.
noindex al publicar el stagingDurante el desarrollo es habitual trabajar en un entorno de pruebas o staging.
Y es razonable evitar que Google indexe esas páginas provisionales.
El problema llega el día del lanzamiento.
La web se publica, parece funcionar y nadie recuerda retirar el noindex.
Google explica que una página que contiene correctamente una regla noindex puede ser eliminada de los resultados cuando Google la rastrea y procesa esa directiva.
En su documentación sobre migraciones recomienda explícitamente preparar una lista de las URLs a las que habrá que retirar las reglas noindex utilizadas durante el desarrollo.
Por tanto, antes de lanzar comprueba:
noindex;robots.txt;No basta con abrir la portada y comprobar que «se ve».
Antes de sustituir una web necesitas una forma realista de volver atrás.
Eso incluye normalmente:
En WordPress, además, hay que distinguir entre tener un backup y saber que ese backup puede restaurarse.
Lo explicamos con detalle en [copias de seguridad en WordPress: cómo saber si realmente funcionan]. Copias de seguridad WordPress: cómo saber si funcionan
La reversión tampoco debería improvisarse después de descubrir un problema.
Antes de publicar, conviene saber:
Esto es especialmente importante en tiendas, reservas, membresías o webs que reciben información continuamente.
Una web no está preparada para producción porque la home se vea correctamente.
Debería existir una revisión estructurada.
Comprueba:
robots.txt;200, 301, 404, etc.;Compara las páginas importantes con la versión antigua:
No significa que tengan que ser idénticas.
Significa que los cambios deben ser conscientes.
Prueba:
Una migración SEO perfecta sirve de poco si el nuevo formulario deja de generar clientes.
Un nuevo diseño también puede introducir:
Si la razón del rediseño incluye que «la web está muy lenta», conviene diagnosticar antes si el problema está realmente en el diseño, en WordPress o en el alojamiento. En [¿WordPress lento por el hosting? Cómo saberlo antes de migrar] explicamos cómo separar esas causas antes de pagar un traslado que podría conservar exactamente el mismo problema. ¿WordPress lento por el hosting? Cómo saberlo antes de migrar
Y para medir la experiencia de carga e interacción puedes revisar también nuestra explicación de [Core Web Vitals en WordPress]. Core Web Vitals en WordPress
Antes de pulsar el botón de publicar, una empresa debería poder responder «sí» a estas preguntas:
noindex utilizado en desarrollo?robots.txt de producción es el correcto?Si varias respuestas son «no lo sé», probablemente la web todavía no está preparada para salir.
No necesitas convertirte en especialista SEO para controlar el proyecto.
Pero sí puedes exigir respuestas concretas.
Antes de aprobar el rediseño pregunta:
¿Qué URLs van a cambiar?
La respuesta no debería ser «ya veremos al publicar».
¿Habéis analizado cuáles reciben tráfico antes de decidir eliminarlas?
Una página no debería desaparecer por accidente durante la limpieza del menú.
¿Quién prepara y comprueba las redirecciones?
Tiene que existir un responsable.
¿Cómo se van a revisar canonicals, robots y noindex?
Especialmente si existe staging.
¿Qué se va a medir antes y después?
Sin una referencia previa será difícil evaluar el resultado.
¿Qué ocurre si encontramos un problema después del lanzamiento?
Debe existir un plan de reversión o corrección.
¿Quién tendrá acceso a Search Console, analítica, hosting, dominio y WordPress después?
La empresa debe conservar control sobre su infraestructura digital. Si no tienes claro qué accesos deberían permanecer en manos del negocio, consulta [qué accesos de WordPress debe controlar tu empresa]. Qué accesos de WordPress debe controlar tu empresa
El lanzamiento no es el final del proyecto.
Es el comienzo de la fase de comprobación.
Busca:
404;noindex;La inspección de URLs permite revisar páginas concretas y detectar problemas de acceso o indexación.
Si ha habido una migración con cambios de URL, Google recomienda utilizar Search Console durante el proceso y comprobar tanto la migración como los sitemaps.
Cuando existe una migración de URLs, Google recomienda enviar el sitemap con las nuevas direcciones en Search Console.
Una posición media aislada puede resultar difícil de interpretar.
Compara:
Search Console permite analizar específicamente las páginas y consultas con mayores cambios entre periodos.
No te limites al SEO.
Después del lanzamiento compara:
Una web puede ganar tráfico y perder clientes porque el nuevo diseño dificulta contactar.
También puede ocurrir lo contrario: un pequeño cambio de tráfico acompañado de una mejora importante de la conversión puede tener un resultado empresarial positivo.
Puede ocurrir.
Google explica que en cambios significativos pueden producirse fluctuaciones temporales mientras vuelve a rastrear y procesar el sitio. En una migración con nuevas URLs, una web pequeña o mediana puede necesitar semanas para que la mayor parte del traslado sea procesado; una web grande puede tardar más.
Eso no significa que cualquier caída deba aceptarse como normal.
Si después del lanzamiento observas una reducción importante, investiga.
Comprueba primero:
noindex accidental;Decir simplemente «es normal, espera» puede hacerte perder tiempo si en realidad existe un error técnico.
No las retires inmediatamente después de ver las URLs nuevas en Google.
Para migraciones con cambios de URL, Google recomienda conservar las redirecciones durante el mayor tiempo posible y, como referencia general, al menos un año para permitir que las señales se transfieran a las nuevas direcciones. Desde el punto de vista del usuario, incluso puede tener sentido conservarlas indefinidamente en determinados casos.
También conviene actualizar los enlaces internos para que apunten directamente a las nuevas URLs y no obliguen a pasar siempre por la redirección.
Esta es probablemente la decisión más importante.
Imagina una web antigua que funciona bien en Google.
Durante el rediseño se decide al mismo tiempo:
Si después el tráfico cae, tendrás demasiadas variables para saber qué ha fallado.
Google recomienda precisamente realizar los grandes cambios de uno en uno cuando sea posible.
Si el problema es simplemente que la web parece antigua y resulta difícil de utilizar, quizá no necesitas transformar simultáneamente todo lo demás.
Y si WordPress sigue encajando con las necesidades del negocio, reconstruir la web tampoco obliga automáticamente a abandonar la plataforma. En [WordPress en 2026: ventajas y cuándo no elegirlo] analizamos en qué situaciones sigue teniendo sentido para una empresa y cuándo sería razonable estudiar alternativas. WordPress en 2026: ventajas y cuándo no elegirlo
La nueva web no debería volver a quedar abandonada durante otros diez años.
Después del lanzamiento habrá:
Todos ellos pueden afectar indirectamente a la salud SEO del sitio.
En [mantenimiento WordPress y SEO técnico] explicamos cómo indexación, errores, velocidad, seguridad y mantenimiento se relacionan y por qué proteger el tráfico conseguido requiere algo más que publicar una web nueva y olvidarse de ella. Mantenimiento WordPress y SEO técnico
Una web que lleva años posicionando no debería tratarse como un solar vacío.
Tiene historia.
Google conoce sus URLs. Algunas páginas reciben enlaces. Otras responden a búsquedas importantes. Los usuarios navegan por determinados recorridos. Existen contenidos, relaciones internas y señales que merece la pena conservar.
Eso no significa que tengas que mantener para siempre una web antigua por miedo a Google.
Significa que la modernización debe empezar con un diagnóstico.
Antes de rediseñar:
robots.txt, noindex y sitemap;Un buen rediseño no debería obligarte a elegir entre tener una web moderna y conservar el trabajo SEO acumulado.
El objetivo es modernizar lo que necesita cambiar sin destruir, por desconocimiento, aquello que ya estaba funcionando.
