Rediseño web: las 7 etapas para hacerlo sin perder tráfico

Un rediseño web es la reconstrucción de un sitio existente: su estructura, sus contenidos, su interfaz y a menudo su base técnica, normalmente en el mismo dominio y con un plan de redirecciones que conserva el posicionamiento ya ganado. Esa última parte es donde se tuercen casi todos los proyectos.

La parte visual es la que todo el mundo prevé. Las que deciden si el proyecto se paga solo son bastante menos vistosas: por qué búsquedas aparece el sitio actual, qué páginas generan solicitudes de verdad, adónde irá a parar cada dirección antigua y quién valida antes de cambiar el interruptor.

Esta guía recorre el ciclo completo en 7 etapas y responde primero a las tres preguntas que se hacen antes de contratar: qué cubre un rediseño, qué presupuesto manejan las agencias en 2026 y cuánto tarda.

Un rediseño toca cuatro capas a la vez: la arquitectura de la información, los contenidos, la interfaz y la base técnica. Reconstruir una sola capa y llamarlo rediseño produce un sitio más bonito con exactamente los mismos resultados que el anterior. El alcance lo definen las capas que tocas, no la distancia visual entre la portada antigua y la nueva.

Arquitectura de la información. El inventario de páginas, la navegación, la estructura de URL y las relaciones entre páginas. Es la capa que mueve el posicionamiento, y la que más se olvida en los briefings.

Contenidos. No es copiar los textos antiguos en plantillas nuevas. Un rediseño es el momento lógico para retirar páginas que nadie lee, fusionar tres páginas de servicio que se solapan y reescribir una propuesta de valor que ha ido derivando.

Interfaz. Maquetación, tipografía, biblioteca de componentes, comportamiento responsive, accesibilidad. La capa visible, por la que el cliente juzga el proyecto.

Base técnica. Alojamiento, gestor de contenidos, renderizado, presupuesto de rendimiento, analítica, gestión de formularios. Cambiar esta capa convierte el rediseño en una migración técnica, con otro perfil de riesgo.

Tres trabajos se llaman rediseño sin serlo. El cambio de plantilla afecta solo a la interfaz. La actualización de textos afecta solo al contenido. El cambio de gestor mueve la base técnica conservando el diseño. Los tres son trabajos legítimos, pero ninguno arregla un sitio que pierde clientes por razones estructurales.

El rediseño hace falta cuando el problema es estructural, y un lavado de cara basta cuando es cosmético. La prueba práctica: escribe qué está fallando y pregúntate si arreglarlo obliga a cambiar el inventario de páginas o la navegación. Si es así, es un rediseño. Si con fotos nuevas y textos más afilados se cerraría la brecha, un lavado de cara lo consigue en una fracción del tiempo y del presupuesto.

Señales que apuntan a un rediseño completo: el sitio no admite las páginas que ahora necesitas para vender, la navegación ha crecido por acumulación y ya nadie encuentra nada, el móvil se parchea en lugar de diseñarse, el gestor impide publicar al equipo de marketing, o la base técnica hace imposible cualquier trabajo de rendimiento. Señales que apuntan a un lavado de cara: visuales anticuados, textos envejecidos, llamadas a la acción débiles, páginas de servicio demasiado escuetas.

El error sale caro en ambas direcciones. Rediseñar cuando bastaba un lavado de cara consume presupuesto y reinicia sin motivo el posicionamiento acumulado. Lavar la cara cuando el problema es la estructura da el resultado conocido: un sitio más atractivo durante un trimestre que convierte igual que antes.

Los presupuestos de rediseño se agrupan en tres tramos, y la horquilla dentro de cada tramo es lo bastante ancha como para que un precio medio único no sirva de nada. Las cifras siguientes son referencias europeas observadas en propuestas de agencias en julio de 2026, no una tarifa de Vezert. Lo que mueve un presupuesto dentro de su tramo es el número de páginas, cuánto contenido hay que redactar en lugar de migrar y si hay integraciones.

Un rediseño corporativo pequeño, entre diez y veinte páginas sobre un gestor existente y con los contenidos reaprovechados, suele situarse entre €6.000 y €15.000. Un rediseño B2B intermedio, con estructura nueva, textos comerciales nuevos y plan de migración, suele situarse entre €15.000 y €35.000. Un rediseño complejo, con cambio de gestor, varios idiomas o integración con un CRM, arranca en torno a €35.000 y supera con frecuencia los €80.000.

Cuatro partidas explican casi toda la diferencia entre dos presupuestos de lo que parece el mismo proyecto:

• Producción de contenido. Migrar textos existentes es barato. Redactar cuarenta páginas es un proyecto en sí mismo y suele facturarse aparte o directamente no incluirse.
• Trabajo de migración. El mapa de URL, la implantación de las redirecciones y su verificación posterior son horas reales de desarrollo. Un presupuesto que no las menciona o las ha absorbido en silencio o las ha excluido.
• Integraciones. Cada sistema conectado, CRM, ERP, reservas o pagos, añade análisis, desarrollo y pruebas.
• Número de idiomas. Cada idioma adicional multiplica contenidos, control de calidad y mapa de redirecciones.

Para el desglose partida por partida, nuestro artículo sobre el presupuesto de una página web cubre el mismo terreno para proyectos nuevos, y nuestros precios publican los puntos de partida con los que trabajamos.

Un rediseño web tarda entre 4 y 20 semanas según el alcance, y la variable que más mueve el calendario no es el diseño ni el desarrollo. Es el contenido. Los proyectos que se retrasan se retrasan casi siempre porque los textos, las fotografías o los datos de producto llegaron tarde, no porque la construcción se alargara.

La tabla siguiente recoge plazos observados, no compromisos. Toma el extremo alto como cifra realista si los contenidos no están escritos al arrancar el proyecto.

La etapa 1 decide qué debe cambiar el rediseño en el negocio, en números. La etapa 2 averigua qué hace ya bien el sitio actual, para no destruirlo sin querer. Ambas ocurren antes de que nadie abra una herramienta de diseño, y saltárselas es el atajo más caro de todo el proceso.

Etapa 1: objetivos. Un objetivo utilizable nombra una métrica y una dirección: solicitudes cualificadas desde la web, coste por contacto, porcentaje de visitantes que llegan a una página de servicio, tiempo que tarda marketing en publicar una página nueva. Un objetivo del tipo imagen más moderna no puede comprobarse tras la publicación, lo que impide declarar el proyecto un éxito o un fracaso.

Anota el valor actual de cada métrica antes de empezar. Lo que hoy no mides, el rediseño no podrá mejorarlo, y entonces la primera tarea es la medición y no el diseño.

Etapa 2: la auditoría. Tres inventarios, todos reutilizados más adelante:

• Búsqueda. Qué URL están indexadas, por qué consultas aparecen, qué páginas reciben entradas orgánicas. Esta exportación se convierte en el mapa de redirecciones de la etapa 7, así que hazla ahora y no cuando el sitio antiguo ya no exista.
• Comportamiento. Qué páginas reciben tráfico, cuáles convierten, dónde terminan las sesiones. Las páginas que convierten se protegen, opine lo que opine el equipo de diseño.
• Técnica. Rendimiento medido con las Core Web Vitals, accesibilidad, comportamiento en móvil, enlaces rotos, páginas indexadas de más.

Nuestra guía para hacer una auditoría web detalla el procedimiento. Según la documentación de Google sobre las Core Web Vitals, estas métricas reflejan la experiencia real de los usuarios y no condiciones de laboratorio, y por eso conviene registrarlas antes y después en lugar de confiar en una puntuación sintética.

Contenido y estructura deciden si el sitio nuevo vende, y son las dos etapas que más se intentan solapar con el diseño. No se puede. Un diseñador que construye plantillas sin inventario de páginas está adivinando qué tendrán que albergar, y la adivinanza se descubre durante el desarrollo, en el peor momento posible.

Etapa 3: contenido. Parte del inventario de la auditoría y asigna a cada página una de cuatro decisiones: conservar tal cual, reescribir, fusionar con otra o retirar. Retirar es la decisión que se evita, y suele ser la más rentable. Un sitio de sesenta páginas donde doce lo generan todo resulta más navegable, más barato de mantener y más claro para los buscadores en cuanto las otras cuarenta y ocho se consolidan.

Después escribe lo que falta. La mayoría de los proyectos descubre aquí que las páginas de servicio nunca han hablado de precios, que no hay más prueba que una fila de logotipos y que la propuesta de valor de la portada describe a la empresa en lugar del problema del cliente.

Etapa 4: estructura. El inventario se convierte en un árbol de navegación y un esquema de URL. Dos reglas ahorran mucho dolor: conservar la URL existente allí donde la página sobrevive sin cambios, y decidir la URL de cada página nueva antes de construir plantillas, no después. Nuestra guía de estructura web explica cómo construir el árbol, y el artículo sobre arquitectura web y visibilidad explica por qué su forma decide qué posiciona.

Diseño y desarrollo hacen visible el rediseño, y ahí las etapas anteriores o se rentabilizan o pasan factura en voz alta. Si el contenido está escrito y la estructura acordada, esta fase es ejecución. Si no lo están, es la fase donde el proyecto lo descubre, y cada hallazgo cuesta aquí bastante más de lo que habría costado en la etapa 3.

Etapa 5: diseño y prototipo. Se diseñan plantillas, no páginas. Un sitio corporativo suele necesitar entre seis y diez: portada, página de servicio, caso de éxito, artículo, listado, contacto, aviso legal y lo que el negocio requiera. Cada plantilla se diseña una vez y se reutiliza, que es lo que mantiene previsible la construcción.

Prototipa los recorridos que importan antes de empezar a desarrollar. El camino desde una página de servicio hasta una solicitud enviada merece probarse con personas reales mientras cambiarlo aún es barato. La navegación móvil también, porque ahí es donde la mayoría de sitios corporativos pierde gente en silencio.

Etapa 6: desarrollo. Construcción sobre las plantillas aprobadas, contenidos cargados, formularios y medición conectados, presupuesto de rendimiento respetado mientras se construye en lugar de auditado al final. La accesibilidad pertenece también a esta fase: recuperar contrastes, estados de foco y estructura semántica después de publicar cuesta varias veces lo que integrarlos desde el principio.

Una decisión de esta fase tiene consecuencias mucho más allá del desarrollo. Según Google Search Central, Googlebot ejecuta JavaScript, pero el renderizado es diferido y depende de los recursos disponibles, de modo que el contenido que solo existe tras ejecutarse en el navegador corre más riesgo de no indexarse. Si el rediseño adopta un framework JavaScript, el renderizado en servidor para las páginas de contenido deja de ser una preferencia y pasa a ser un requisito.

Publicar es un acontecimiento de posicionamiento, no solo un despliegue. Cada URL que cambia tiene que apuntar a algún sitio de forma deliberada, y esa correspondencia se construye antes del día del cambio en lugar de reconstruirse después a partir de los informes de error 404. Es la etapa donde la diferencia entre un rediseño cuidadoso y uno descuidado se ve en el tráfico en cuestión de semanas.

El orden que funciona:

1. Congela el inventario de URL. URL indexadas en Search Console, rastreo completo del sitio actual, sitemaps vigentes, páginas con entradas orgánicas o conversiones y páginas con enlaces externos apuntando hacia ellas.
2. Asigna destino a cada una. Cada URL antigua recibe una decisión: conservar, redirigir, consolidar en otra página o eliminar deliberadamente.
3. Implanta redirecciones permanentes en un solo salto. Según Google Search Central, una redirección permanente indica que el traslado es definitivo, y las cadenas de redirecciones consumen presupuesto de rastreo. La antigua apunta directamente a la nueva, nunca a través de una dirección intermedia.
4. Regenera las etiquetas de idioma. En un sitio multilingüe, las anotaciones hreflang deben apuntar a las nuevas URL canónicas y referenciarse entre sí en ambos sentidos. La documentación de Google sobre versiones localizadas fija los requisitos.
5. Verifica en preproducción y otra vez en producción. La preproducción debe estar bloqueada a la indexación antes de empezar y desbloquearse al publicar. Invertir esos dos interruptores es una de las formas más habituales de perder un mes.
6. Conserva las redirecciones. Google recomienda mantenerlas al menos un año, y no hay motivo para retirarlas después si las direcciones antiguas siguen recibiendo tráfico o sosteniendo enlaces.

Dos aclaraciones, porque la mayoría de listas de comprobación las dan mal. Una redirección temporal sí transmite señales: la razón para usar la permanente es que declara el traslado definitivo, no que la otra pierda valor por el camino. Y Google no publica ninguna cifra sobre cuánto dura una caída tras un traslado, solo que hay que esperar fluctuaciones mientras las señales se consolidan. Cualquier artículo que dé un plazo fijo está citando la experiencia de un proveedor, no una documentación.

El procedimiento completo, con la tabla de correspondencias y el seguimiento posterior, está en nuestra guía de migración web.

Los rediseños fracasan por un número reducido de razones que se repiten, y casi todas se deciden antes de publicar. El patrón que observamos es constante: los proyectos que salen mal son aquellos donde el diseño empezó antes de que existieran los contenidos y el inventario de URL, de modo que cada etapa posterior heredó una decisión sin cerrar.

Cuatro modos de fracaso que conviene nombrar:

• El diseño dirigió el proyecto. Se aprobaron plantillas antes de saber qué iría dentro, y el texto se comprimió para encajar en la maqueta en lugar de lo contrario.
• Se trató el sitio antiguo como si no valiera nada. Se retiraron páginas que traían solicitudes porque parecían anticuadas, sin mirar antes la analítica.
• La migración se planificó al final. El mapa de redirecciones se montó la última semana, a partir de una lista incompleta y por quien estuviera libre.
• No se midió nada antes. Sin punto de partida no hay forma de saber si el sitio nuevo es mejor, y el siguiente rediseño arrancará de las mismas suposiciones.

Lista de comprobación previa a la publicación. Ningún punto debería marcarse el mismo día del cambio:

1. Cada URL indexada figura en la tabla de correspondencias con una decisión registrada.
2. Las redirecciones están implantadas, se resuelven en un solo salto y se han probado contra la lista real.
3. Los enlaces internos apuntan a las URL finales, no a través de una redirección. Revisa tanto el cuerpo de los contenidos como la navegación y los botones: se guardan por separado, y la segunda pasada es la que se olvida.
4. Las etiquetas canónicas apuntan a las URL nuevas y las anotaciones hreflang se referencian entre sí.
5. La preproducción está en noindex y la producción no. Comprueba ambas después del despliegue, no antes.
6. Sitemaps regenerados y enviados, con fechas de modificación correctas.
7. Analítica, objetivos y seguimiento de formularios se disparan en las plantillas nuevas. Prueba un envío real.
8. Rendimiento y accesibilidad medidos en las páginas nuevas frente al registro inicial.
9. Los títulos y encabezados conservan el sentido que hacía posicionar a las páginas: reescribirlos todos de golpe cambia para qué consultas resulta relevante cada página.
10. Existe un plan de seguimiento para las semanas posteriores, con un responsable con nombre y apellidos.

Después de publicar el trabajo no termina, cambia de forma. Nuestro artículo sobre optimización posterior al lanzamiento detalla qué vigilar y en qué orden. Si prefieres encargar el ciclo completo a un equipo que lo hace con regularidad, en eso consiste nuestro trabajo de sitios web corporativos.