Antes de rediseñar una web, guarda las páginas que la gente ya encuentra, conserva las direcciones útiles cuando sea posible y acuerda qué ocurrirá con cada URL que cambie. Después comprueba esas rutas en el dominio real. Una vista previa bonita no demuestra que un resultado de búsqueda antiguo siga llevando al servicio correcto.
Esta lista está pensada para una empresa en funcionamiento que va a sustituir su web. Sirve para acordar qué pruebas debe entregar el proveedor. Puede reducir problemas evitables; no garantiza mantener posiciones ni consultas. Google explica que los cambios importantes pueden provocar fluctuaciones temporales mientras vuelve a rastrear e indexar las páginas.
1. Guarda una referencia antes de retirar la web antigua
Pide una lista de las direcciones públicas actuales, incluidos los PDF y otros archivos útiles. Parte del sitemap y de un rastreo del sitio; compáralos con las páginas que reciben visitas desde Google en Search Console, las páginas de entrada en analítica y los enlaces usados en campañas. Una fuente puede encontrar páginas que otra no muestra.
Señala las páginas importantes para el negocio: un servicio por el que preguntan, un producto que los compradores identifican por código o una ubicación enlazada desde la ficha de empresa. Guarda el contenido, los títulos, las imágenes relevantes y las vías de contacto actuales. Anota las fechas y los filtros de los informes para poder comparar después.
Conserva una copia recuperable de la web y acuerda quién puede restaurarla. Si los pedidos o las consultas se guardan en otro sistema, inclúyelo en el plan de recuperación. Una carpeta de capturas no demuestra que se pueda restaurar el sitio.
2. Decide qué pasará con cada dirección antigua
Rediseñar no obliga a cambiar las URL. Si una página sigue respondiendo a la misma pregunta, conservar su dirección elimina una tarea de migración. Si cambia, pide una tabla de correspondencias antes de publicar.
| Dirección antigua — ejemplo ilustrativo | Decisión | Comprobación tras publicar |
|---|---|---|
/services/repair/ |
Conservar página y dirección | Abre con normalidad y muestra el servicio previsto |
/old-service/ |
Mover a /services/repair/ porque es el sustituto pertinente |
La redirección permanente llega a esa página final |
/obsolete-offer/ |
Eliminar; no hay sustituto pertinente | Devuelve una respuesta real 404 o 410 |
No envíes todas las páginas retiradas al inicio. La guía de Google sobre cambios de URL advierte contra redirigir muchas direcciones antiguas sin relación a un destino irrelevante. La redirección debe ayudar a quien siguió el enlace anterior.
Para cambios permanentes, Google recomienda redirecciones permanentes del servidor, como 301 o 308. Pide al desarrollador que compruebe la respuesta y el destino reales, incluidas las cadenas innecesarias y los bucles. Una página con un enlace a la nueva dirección ofrece una experiencia distinta.
Google recomienda, por lo general, mantener las redirecciones al menos un año. Algunos enlaces útiles pueden seguir circulando más tiempo; acuerda quién mantendrá esas rutas cuando se cancele el alojamiento anterior.
3. Conserva la respuesta, además de la dirección
Mantener una URL y quitar los detalles del servicio que la hacían útil también cambia lo que ofrece. Compara las páginas antiguas importantes con las propuestas. Comprueba que el comprador siga encontrando los productos, la zona de servicio, las limitaciones y el siguiente paso pertinentes.
El desarrollador también debe revisar los títulos, los encabezados principales, los enlaces internos, las direcciones canónicas y el sitemap. La dirección canónica indica cuál es la dirección preferida de una página; la nueva versión no debe apuntar por error al dominio de pruebas o a una URL antigua. Si hay traducciones, comprueba que los enlaces de idioma conecten las páginas equivalentes.
Esto no obliga a conservar contenido deficiente. Corrige lo inexacto o confuso y documenta los cambios sustanciales. Se trata de decidir con intención, en vez de perder información útil al cambiar la plantilla. La lista de contenido para el diseñador ayuda a ordenar los datos y las aprobaciones.
4. Define las condiciones de prueba y publicación
Prueba una versión separada antes de sustituir la web pública. Si contiene información privada, restringe el acceso. Una instrucción para excluir páginas de los buscadores no controla quién puede verlas.
La versión de prueba puede usar noindex para impedir su indexación. Google explica que el rastreador necesita acceder a la página para leer esa instrucción: bloquearla en robots.txt puede impedir que vea la regla.
Antes de publicar, pide al desarrollador que compruebe que las páginas destinadas a aparecer en búsquedas no tengan un noindex, una contraseña o un bloqueo de rastreo accidentales, y que sus direcciones canónicas usen el dominio definitivo. Conserva las restricciones deliberadas de páginas privadas o duplicadas. No elimines todas las restricciones sin revisar su propósito.
Pide una lista breve de problemas que impiden publicar: páginas importantes ausentes, destinos incorrectos, acciones del comprador rotas y exclusiones de búsqueda involuntarias. Asigna un responsable a cada problema. Acuerda quién decide publicar y quién se encarga de recuperar el servicio antes de que llegue la fecha límite.
5. Comprueba el dominio real el día de publicación
Abre directamente las direcciones antiguas importantes después de publicar. Sigue el recorrido completo: enlace antiguo, página final, información pertinente y acción de contacto o compra. Prueba en teléfono y ordenador. Coordina las pruebas de formularios o pagos reales para que el equipo pueda identificarlas; evita generar mensajes o pedidos involuntarios.
Pide al desarrollador que compruebe los códigos de respuesta, las redirecciones, el contenido, los enlaces internos, el sitemap y las instrucciones de búsqueda en el dominio público. Una carga correcta o una prueba satisfactoria en la vista previa no demuestra que todo funcione en producción.
Anota la hora de publicación, la versión, los fallos y las correcciones. Si falla una ruta crítica para el comprador, aplica el plan acordado. Restaurar una versión anterior puede afectar a pedidos o consultas nuevos, por lo que alguien debe responsabilizarse de esos datos.
6. Supervisa con las mismas preguntas y ajustes
Después, revisa las URL importantes en Search Console y supervisa la indexación, los clics de búsqueda y las páginas de entrada. Compara periodos y filtros equivalentes, teniendo en cuenta la estacionalidad. Si importan las consultas, verifica que tanto su medición como la vía de contacto sigan funcionando antes de interpretar un cambio en el total.
Investiga pronto una página ausente o un destino incorrecto. Un movimiento breve de la posición media no demuestra por sí solo que el rediseño haya funcionado o fracasado. Google debe volver a rastrear las páginas modificadas y los cambios de demanda o contenido también influyen. No existe una fecha universal de recuperación que se pueda prometer con rigor.
Pide una entrega con el inventario anterior, el mapa final de redirecciones, las comprobaciones de publicación, los problemas pendientes, las instrucciones de recuperación y un responsable de seguimiento. La guía de costos del rediseño ayuda a distinguir estas tareas al comparar alcances. Si vas a dejar un constructor alojado, consulta también qué puedes conservar al salir de Wix o GoDaddy.
Mi pregunta para aceptar el trabajo sería sencilla: ¿puede un comprador usar un enlace antiguo importante y completar la tarea prevista? Guarda las pruebas de esa respuesta junto al nuevo diseño.
