Rediseña por una razón de negocio, no solo porque pasó el tiempo
Necesitas evaluar un rediseño cuando tu web ya no explica la oferta actual, dificulta acciones importantes o hace demasiado costoso mantener y ampliar el contenido. Que tenga varios años no demuestra por sí solo que deba reemplazarse. Una página con buen contenido y funcionamiento puede necesitar ajustes puntuales.
La decisión empieza con evidencia: páginas útiles, consultas, fallas, costos de operación y tareas que hoy no puedes realizar. Con esa información se define qué conservar, qué mejorar y qué reconstruir. El objetivo no es estrenar por estrenar, sino que el sitio vuelva a servir a tu negocio.
Ponerlo en prácticaExplora el ejemplo o pliega este espacio para seguir leyendo.
Haz el inventario de lo que no quieres perder
Antes de cambiar la portada, marca lo que ya tienes documentado. Descarga los pendientes para conversar con tu proveedor.
0 de 6 tareas marcadas como revisadas.
Pendiente para revisar: Páginas y URLs actuales inventariadas.
Marcar una tarea no valida una migración ni autoriza borrar URLs. Cada cambio necesita comprobación.
Señales que merecen una revisión
Un precio desactualizado se corrige; una arquitectura que mezcla servicios incompatibles puede requerir repensarse. Un formulario roto es urgente, pero no significa que debas rehacer toda la web. Distinguir magnitud y causa protege el presupuesto.
Registra ejemplos concretos. «No me gusta» puede iniciar una conversación visual; «los clientes no encuentran este servicio» permite revisar navegación, contenido y enlaces. Cuantas más decisiones se apoyen en hechos, más fácil será acordar el alcance.
| Síntoma | Primera acción | Cuándo considerar rediseño |
|---|---|---|
| Textos o teléfonos viejos | Actualizar contenidos | La oferta completa cambió |
| Una función falla | Diagnosticar y corregir | La base impide mantenerla |
| No se encuentran servicios | Revisar arquitectura y enlaces | El menú refleja una organización obsoleta |
| Publicar exige mucho esfuerzo | Revisar flujo editorial | Las plantillas o el CMS ya no cubren la operación |
| No se conoce el aporte comercial | Instrumentar y revisar | El recorrido necesita cambiar en varias capas |
Qué no deberías perder al cambiar de sitio
Conserva contenido útil, URLs que reciben visitas o enlaces, recursos descargables relevantes y aprendizajes del equipo comercial. Reúne también formularios, integraciones, correos de recepción, datos de analítica y accesos. El proyecto anterior contiene activos aunque su aspecto deba cambiar.
Un inventario permite asignar una acción a cada URL: conservar, actualizar, unir con una página equivalente o retirar cuando ya no existe contenido útil. Cambiar todos los slugs porque comienza una nueva tecnología no es una necesidad. Las direcciones públicas y el sistema que administra contenido pueden evolucionar por separado.
Qué significa cuidar el SEO durante una migración
Cuando una URL debe cambiar, conviene mapearla hacia su equivalente y probar una redirección permanente directa. Las páginas nuevas necesitan enlaces internos, canonical e indexabilidad coherentes. El sitemap debe representar el sitio nuevo, no conservar páginas retiradas por costumbre.
Google recomienda planificar la correspondencia entre URLs, probar las redirecciones y evitar enviar indiscriminadamente las páginas antiguas a la home. Una migración puede tener fluctuaciones de visibilidad; ningún proveedor puede prometer que cambiar tecnología evitará por completo ese proceso.
Cómo se convierte el diagnóstico en un proyecto
La propuesta debería separar cambios de mensaje, diseño, contenido, funciones y tecnología. Así puedes ver si necesitas un ajuste de páginas prioritarias, una nueva plantilla o una reconstrucción mayor. Cada bloque debe explicar su motivo y qué se entregará.
El caso de Escuela Pekes de Temuco es una referencia para pensar claridad institucional y contacto local. Ochoa Herramientas sirve para observar catálogo y compra. Elegir un caso parecido por operación aporta más que trasladar una pantalla bonita que no corresponde a tu público.
Antes de autorizar un rediseño
Define qué mejora esperas y cómo la comprobarás. Algunas comprobaciones son inmediatas, como que funcione un formulario o que una persona encuentre un servicio. Otras requieren observar un período de uso, como cambios en consultas calificadas. No uses una sola métrica para evaluar todo.
Pide el plan de publicación, respaldo, verificación y responsables. También aclara qué errores se corrigen dentro de garantía y qué nuevas solicitudes se cotizan aparte. Un rediseño bien planteado deja menos incertidumbre tanto antes como después del lanzamiento.
- Inventario de URLs, contenido y funciones.
- Problemas prioritarios y evidencia disponible.
- Alcance con plantillas, revisiones y exclusiones.
- Mapa de redirecciones cuando cambian direcciones.
- Pruebas de contacto, compra y medición.
- Responsable de mantener y evaluar el nuevo sitio.
Un rediseño necesita una salida reversible
Antes de cambiar el sitio público se prueban en un entorno de revisión las páginas principales, las redirecciones, la recepción de formularios y los cambios de DNS realmente necesarios. El correo puede estar alojado aparte: cambiar de web no autoriza a reemplazar toda la configuración del dominio.
Acordar cómo volver al estado anterior no significa revertir a ciegas. Hay que considerar pedidos o consultas creados después del cambio para no perder datos nuevos. La decisión de continuar, corregir o volver debe tener un responsable y evidencia.
| Antes | Al publicar | Después |
|---|---|---|
| Inventario de URLs y destinos equivalentes | Redirecciones permanentes probadas | Errores, tráfico y consultas observados. |
| Respaldo y procedimiento de recuperación | Prueba del formulario y del correo | Recepción real y funcionamiento móvil. |
| Referencia de rendimiento y medición | Etiquetas y preferencias comprobadas | Comparación con períodos y contexto equivalentes. |