Cuándo rediseñar una web y cuándo optimizar la que ya existe

Que una web parezca antigua no basta para rediseñarla. Puede bastarle un retoque visual; otra parece moderna y esconde contenido duplicado, medición rota o un gestor de contenidos en el que nadie se atreve a publicar.

Escribe primero qué tiene que facilitar la web: explicar una oferta compleja, captar una demanda concreta, recibir solicitudes válidas o publicar sin romper nada. Sin ese objetivo, «rediseño» se vuelve una preferencia estética y «optimización», una lista interminable de retoques. El objetivo es la vara con la que se mide cada opción, también la de no tocar nada.

Con el objetivo escrito, reúne cuatro datos: la evidencia de qué falla, la deuda técnica que frena cada cambio, quién controla el dominio, el código y las cuentas, y lo que arriesgas en Google si cambian las direcciones.

Antes de rediseñar, una web con problemas admite cuatro respuestas de alcance creciente.

Corregir

Resolver fallos claros: un formulario que no entrega, enlaces rotos, un foco de teclado invisible, un agujero de seguridad o un dato incorrecto. Un fallo conocido se corrige antes de cualquier experimento.

Optimizar

Mejorar una ruta que funciona con cambios proporcionados y una señal fijada de antemano para saber si mejoró. La base sigue valiendo.

Refactorizar

Cambiar cómo está hecha la web sin tocar la experiencia: componentes, estilos, plantillas o el flujo de publicación. Reduce la deuda técnica, el trabajo pendiente que encarece cada cambio.

Rediseñar y migrar

Replantear arquitectura, contenido, sistema visual o plataforma. Es la opción con más superficie de cambio: necesita inventario, equivalencias, pruebas y una forma de volver atrás.

Rediseñar se justifica cuando el problema está en el modelo y no en una pieza. Entonces cada parche añade otra excepción.

La oferta ya no cabe en la arquitectura

Servicios y audiencias se mezclan, el menú reproduce el organigrama, las plantillas impiden explicar el servicio, o la empresa cambió de propuesta y una capa visual nueva mantendría el mensaje viejo.

La base técnica impide cambios seguros

No hay copia de pruebas, las actualizaciones rompen estilos, el código depende de un constructor abandonado o no hay forma de volver atrás. Antes de culpar a la tecnología, documenta versiones y causas.

La accesibilidad pide cambios de estructura

Un contraste puntual se corrige; un orden incoherente del código, menús que no se manejan con el teclado o controles que un lector de pantalla no identifica pueden exigir rehacer componentes. Una auditoría con las pautas WCAG 2.2 del W3C delimita el alcance.

La propiedad es inaceptable

Sin código fuente, licencias, credenciales ni documentación, cada retoque te ata a quien los tiene. Recupéralos primero, con la guía sobre propiedad de la web, las cuentas y los datos.

La lentitud justifica rediseñar una web solo si viene de la base, y eso se mide. Según la guía web.dev de Google, hay buena experiencia si el mayor elemento con contenido se pinta en 2,5 segundos o menos (LCP), la página responde a un toque o un clic en 200 milisegundos o menos (INP) y el contenido se mueve poco al cargar, con un CLS de 0,1 o menos. Son las Core Web Vitals, y una página aprueba si las cumple en el percentil 75 de las cargas (al menos tres de cada cuatro), por separado en móvil y en ordenador.

Si fallan dos o tres plantillas, se corrigen esas. Si fallan todas las plantillas por la misma causa, como el tema o el constructor, es señal de refactorizar o rediseñar. Cómo priorizar el rendimiento por plantilla y tarea lo explica otra guía.

La Ley 11/2023 hace obligatoria la accesibilidad de la web para parte de las empresas desde el 28 de junio de 2025, cuando entró en vigor su título I, que traspone la Directiva (UE) 2019/882.

Obliga a los nueve servicios de su lista que se prestan a consumidores: el comercio electrónico (contratar a distancia con consumidores, por web o aplicación), la banca, los libros electrónicos, las comunicaciones electrónicas, el acceso a servicios de comunicación audiovisual, partes del transporte de viajeros, las webs y aplicaciones de suministro eléctrico, agua y gas y las de agencias de viajes y turoperadores, y las redes sociales. Están exentas las microempresas que prestan servicios: menos de 10 personas y un volumen de negocio anual o un balance de 2 millones de euros o menos.

Una web que solo presenta los servicios de una empresa de otros sectores, sin contratar en ella con consumidores, no figura en la lista de la ley. Quien está obligado solo puede, por excepción, dejar de cumplir un requisito que cambie la naturaleza del servicio o le suponga una carga desproporcionada: tiene que evaluarlo con los criterios del anexo V, documentarlo e informar a la autoridad y, en el segundo caso, hacerlo lo más accesible posible (artículo 16).

Si la web nueva cambia las URL, para Google es un traslado. Su guía advierte de que las posiciones pueden moverse mientras vuelve a rastrear e indexar, y de que en sitios medianos pueden pasar varias semanas o más hasta que empiece a mostrar, poco a poco, las direcciones nuevas en vez de las viejas. Con un sitio grande, propone trasladar primero una sección que cambie poco, para probar el efecto. Una optimización que conserva las direcciones se ahorra ese traslado.

Una redirección permanente hace que Google muestre el destino nuevo en sus resultados; la URL canónica es la que elige como la más representativa de un grupo de páginas duplicadas. No se sustituyen. El mapa de redirecciones y el inventario los detalla la guía sobre cómo encargar la web nueva sin perder lo ganado en Google.

Un prototipo de la web nueva con contenido real dice si el problema era la estructura o el mensaje antes de pagarla entera. Pruébalo con tareas: elegir entre dos servicios, usarlo con teclado y en el móvil, enviar el formulario con errores y publicar un cambio.

Si pruebas versiones en la web publicada, Google pide enseñar a su robot las mismas URL que a los usuarios. Lo contrario es encubrimiento. Las variantes llevan una etiqueta canónica hacia la original y la redirección a una variante es un 302, temporal, no un 301, permanente. Al acabar, se retira todo: Google puede tomar un experimento más largo de lo necesario como un intento de engañar.

El árbol y los controles ordenan cuándo rediseñar u optimizar; no estiman coste, plazo ni efecto en ventas o en posiciones.

Lo que dicen Google y la ley es lo vigente el 9 de octubre de 2026: compruébalo en la fuente oficial.

De accesibilidad resume solo la Ley 11/2023, y no es asesoramiento jurídico: si dudas de si te aplica, consúltalo con un abogado.

Escribe el objetivo de la web y reúne los cuatro datos del primer apartado: evidencia, deuda técnica, propiedad y riesgo de migración.

Después recorre el árbol en orden y corrige lo crítico antes de pedir presupuestos: una web nueva aprobada sobre un formulario roto arrastra el fallo.

La página de diseño y desarrollo web explica el servicio si prefieres revisarlo con nosotros; empezar por ella no implica que rediseñar sea la respuesta. El presupuesto se cierra por alcance, una vez conocido el caso.

Publicado el 1 de septiembre de 2026.

Actualizado el 9 de octubre de 2026.

Reescrito y ampliado: respuesta inicial nueva; se añaden lo que dice Google de los cambios de URL y de las pruebas, los umbrales de Core Web Vitals, a quién obliga la ley de accesibilidad y dos esquemas; el ejemplo inventado reparte ahora sus horas por tarea.