Rediseñar una web exige decidir qué cambia y qué valor debe sobrevivir al cambio. Una nueva presentación puede mejorar lectura y navegación mientras conserva páginas, respuestas y enlaces útiles.
No existe una garantía de mantener posiciones. Sí puedes reducir pérdidas evitables: contenido que desaparece sin motivo, enlaces que dejan de funcionar, URLs que apuntan a destinos incorrectos o bloqueos de rastreo olvidados.
Distingue diseño contenido y migración
Cambiar colores o composición no obliga a cambiar las URLs. Revisar el mensaje de un servicio no exige retirar todas sus explicaciones. Cambiar de CMS puede afectar rutas, contenido, medios e integraciones; conviene identificar esas dependencias antes de construir.
Escribe el problema del rediseño de forma concreta. Por ejemplo: “En móvil cuesta distinguir los tres servicios y el formulario pierde el servicio seleccionado”. Esto orienta una mejora comprobable.
“Queremos una web nueva” todavía no dice qué debe conservarse. Si no haces ese inventario, el diseño puede terminar decidiendo por accidente qué preguntas dejan de responderse.
Guarda una referencia antes de editar
Para las páginas relevantes, conserva contenido, títulos, secciones, enlaces, archivos y una captura útil de su presentación. Registra también la versión técnica y la configuración necesaria para volver atrás.
Añade datos de búsqueda y analítica con periodo y filtros. La ausencia de clics no demuestra por sí sola que una página carezca de valor: puede tener una función de apoyo, ser reciente o no tener suficiente exposición.
| Campo del inventario | Ejemplo de información que necesitas |
|---|---|
| URL actual | Dirección completa y variante preferida |
| Trabajo del lector | Qué pregunta resuelve o qué acción facilita |
| Contenido valioso | Respuestas, ejemplos, comparaciones y límites |
| Enlaces | Entrantes conocidos, salientes y archivos relacionados |
| Evidencia | Fuentes y claims que deben conservarse o corregirse |
| Uso observado | Consulta/página, periodo, filtro y límites |
| Estado técnico | Respuesta, canonical, indexabilidad y redirecciones |
| Decisión | Conservar, mejorar, integrar, redirigir o retirar con motivo |
| Destino | URL equivalente y contenido que recibe |
| Comprobación | Cómo sabrás que la función sigue disponible |
El inventario es una ayuda para decidir, no una cuota de páginas que haya que borrar. Antes de retirar algo, explica qué pierde la persona y dónde encontrará una respuesta equivalente.
Un mapa de cinco rutas
Este ejemplo utiliza Estudio Ladera, identidad ficticia del laboratorio, y cinco URLs antiguas hipotéticas. No representa una migración ejecutada ni resultados SEO observados.
| Ruta antigua del ejercicio | Decisión | Destino propuesto | Qué debe conservarse |
|---|---|---|---|
| /servicios/ | Mantener URL y mejorar organización | /servicios/ | Tres servicios y sus diferencias |
| /asesoria.html | Cambiar a una ruta descriptiva | /servicios/asesoria-de-una-estancia/ | Alcance, aportaciones, límites y acceso a contacto |
| /proyectos/salon-claro/ | Mantener URL si sigue siendo útil | /proyectos/salon-claro/ | Contexto, imágenes propias y explicación de decisiones |
| /como-trabajamos/ | Integrar con proceso sin perder respuestas | /estudio/proceso/ | Qué aporta la persona, revisiones y entrega |
| /contacto.php | Cambiar ruta preservando función | /contacto/ | Servicio seleccionado, etiquetas, validación y destino real |
Las rutas se han elegido para mostrar decisiones distintas, no porque todas deban cambiar. La fila de servicios conserva su dirección; la de asesoría necesita una redirección; la de proceso exige comprobar que las respuestas realmente llegaron al nuevo destino.
No redirijas todo a Inicio por comodidad. Una persona que buscaba cómo se revisa un proyecto necesita esa respuesta, no una portada genérica.
Google recomienda preparar el mapa de URL antigua a nueva, usar redirecciones permanentes adecuadas y comprobar los destinos. También advierte de fluctuaciones mientras vuelve a rastrear e interpretar el sitio. Consulta su guía de migraciones, revisada aquí el 10/09/2026.
Preserva respuestas además de direcciones
Una URL que responde correctamente puede haber perdido la información por la que era útil. Compara antes y después las preguntas, no solo el número de encabezados.
En la fila de asesoría, imagina que el diseño nuevo solo deja una frase y un botón. La página podría seguir cargando, pero ya no explica qué materiales aporta el cliente ni qué está fuera del servicio. Esa pérdida afecta a la comprensión y a la comparación de propuestas.
Puedes resumir una explicación o distribuirla mejor, siempre que siga respondiendo el trabajo del lector. Si una sección se mueve, deja una conexión clara con el lugar que la recibe.
Si una afirmación no está respaldada, corrige ese fragmento. No hace falta eliminar una comparación útil o todo un proceso para retirar un claim incorrecto.
Mantén coherencia técnica
La URL que enlazas desde la navegación, la que declaras como preferida y la que incluyes en el sitemap deberían responder al mismo plan.
Una anotación canonical expresa una preferencia sobre versiones duplicadas o muy parecidas; no es una redirección para personas ni una garantía de que Google elegirá esa versión. Evita declarar destinos contradictorios entre HTML y sitemap. Documentación de canonical de Google, consultada el 10/09/2026.
El sitemap debe contener las URLs que se quieren presentar como canónicas y que realmente están disponibles. Mantener un sitemap actualizado ayuda al descubrimiento, pero no asegura indexación. Guía de construcción de sitemaps, consultada el 10/09/2026.
Comprueba también medios y descargas. Un cambio que conserva el artículo pero rompe su plantilla descargable no ha conservado todo el recorrido.
Prueba antes de cambiar la web pública
El entorno de revisión debe permitir recorrer las páginas y comprobar los estados sin enviar mensajes o cobros reales por accidente. Acuerda quién puede acceder y qué datos son ficticios.
Para las cinco rutas del ejercicio, la comprobación podría ser:
- Abrir cada URL nueva y verificar contenido, título y navegación.
- Comprobar el destino exacto previsto para cada URL antigua.
- Confirmar que no hay bucles ni cadenas innecesarias de redirección.
- Revisar enlaces del menú, cuerpo, pie y archivos descargables.
- Probar contacto desde un servicio, incluidos vacío, error y resultado.
- Revisar móvil, teclado, foco y lectura de contenido.
- Comprobar canonical, sitemap y reglas de indexabilidad.
- Revisar qué protecciones del entorno de prueba deben cambiar al publicar.
No retires un bloqueo de desarrollo hasta saber qué entorno estás cambiando. Una previsualización pública o un formulario con destino real requieren una decisión de publicación y datos adecuada.
Define cuándo no publicar
Establece criterios de parada que tengan relación con el propósito. Por ejemplo:
- Un servicio importante ha perdido información imprescindible.
- Una URL prioritaria no tiene destino equivalente.
- El formulario confirma un envío que no se ha entregado.
- Hay un bloqueo de acceso o indexabilidad no explicado.
- Faltan cuentas, copias o una forma de recuperar la versión anterior.
- La persona responsable todavía no ha aprobado contenido o alcance.
Un cambio de diseño puede continuar mientras se corrigen partes independientes, pero no se presenta como terminado si su recorrido principal está roto.
Comprueba la URL final
Después de publicar, repite las comprobaciones afectadas en el dominio público. Una aceptación del despliegue o una vista previa no confirma por sí sola qué versión sirve esa URL.
Registra fecha, versión y resultado. Si falla una función crítica, utiliza la salida acordada: corrección acotada o reversión. Antes de volver atrás, revisa si se han creado datos nuevos que deban conservarse.
Una comprobación técnica correcta no prueba que Google ya haya procesado las nuevas páginas. La lectura de Search Console requiere su propio tiempo de actualización y debe mantener la relación entre URL antigua y nueva.
Observa sin atribuir causas demasiado pronto
Compara periodos equivalentes y separa páginas cambiadas, páginas conservadas y otros cambios de contexto. Mira consultas e intención, no solo un total de visitas.
Si aparecen errores, investiga el eslabón concreto: acceso, redirección, contenido, enlace, canonical o indexabilidad. Si los datos son pocos o incompletos, deja la conclusión abierta. Una variación de tráfico puede tener varias explicaciones.
El resultado útil del rediseño debe poder describirse hoy —contenido preservado, tarea completada, errores corregidos— sin prometer una posición futura.
Puedes incorporar inventario, migración y pruebas a tu briefing web. La guía para crear y encargar una web conecta estas decisiones con presupuesto, construcción y entrega.