Cómo verificar redirecciones al cambiar la URL de un servicio
Comprueba la URL anterior de un servicio, su redirección permanente, la página final, la canonical y los enlaces con una ficha de aceptación.
Read in English
Al cambiar la dirección de una página de servicio, pueden quedar enlaces antiguos en propuestas, marcadores o correos de clientes. El cambio está listo cuando quien sigue uno de esos enlaces llega al servicio previsto y puede continuar con la acción que necesita.
Para trasladar una sola página dentro del mismo sitio, prepara una ficha breve de aceptación: dirección anterior, sustituta prevista, respuesta observada, página final y responsable de revisión. Así resulta más fácil comprobar el cambio que con una afirmación general de que “la redirección funciona”.
Ilustración conceptual generada con IA; no es una captura de un cliente.
Acuerda el destino antes de cambiar la dirección
Imagina un negocio ficticio que mueve /servicios/herramientas-reservas a /servicios/software-citas. Anota por qué la nueva página satisface la misma necesidad. Su encabezado, alcance del servicio y acción de contacto deben seguir teniendo sentido para quien utiliza el enlace anterior.
En este ejercicio el servicio sigue existiendo; solo cambia su dirección. Si el negocio retira el servicio o lo sustituye por otro sustancialmente distinto, resuelve primero esa decisión de contenido. Una ruta de navegación que funciona no demuestra que dos servicios sean equivalentes.
Inspecciona la respuesta, además de la barra de direcciones
Pide a quien implemente el cambio que registre la primera respuesta HTTP de la dirección anterior. La documentación de Google sobre redirecciones identifica 301 y 308 como permanentes y recomienda una redirección permanente del servidor cuando el cambio de URL es definitivo.
La respuesta debe señalar el destino acordado. MDN explica que una redirección HTTP utiliza una respuesta 3xx y una cabecera Location para indicar al navegador adónde ir. Ver la página final no muestra, por sí solo, qué respuestas condujeron hasta ella.
En el cambio ficticio, un registro útil mostraría la ruta anterior devolviendo la redirección permanente elegida, el destino respondiendo HTTP 200 y ninguna página intermedia inesperada. Guarda la respuesta real de una solicitud nueva para que un resultado previamente almacenado por el navegador no sea la única evidencia.
Prueba un grupo pequeño de entradas reales
- Abre la dirección anterior exacta copiada de una propuesta o de un registro de enlaces.
- Abre directamente la dirección nueva y comprueba que funciona sin visitar antes la página antigua.
- Revisa variantes relevantes que el sitio haya utilizado, como una barra final.
- Prueba los parámetros de consulta que tengan una función en esa página y anota si deben conservarse.
- Abre una página de otro servicio que no deba verse afectada.
Usa valores de prueba inocuos al comprobar parámetros. No copies información privada de clientes en una ficha pública. Registra cualquier bucle, salto adicional o destino incorrecto como una diferencia concreta respecto del mapa acordado.
Comprueba qué recibe el visitante
En la página de destino, lee el encabezado y la descripción, abre la acción de contacto y verifica el idioma esperado. Una página de inicio genérica puede cargar correctamente y aun así obligar al visitante a buscar de nuevo el servicio.
La guía de Google para cambios de URL recomienda destinos directos, enlaces internos actualizados, una canonical que apunte a la propia página nueva y entradas de sitemap actualizadas. Comprueba cada punto: una redirección no actualiza automáticamente esas referencias.
En la ficha, identifica el elemento de navegación y un enlace contextual que hayas comprobado. Anota la dirección canonical encontrada y si el sitemap vigente incluye el destino. Así la evidencia queda asociada a lugares concretos, en vez de una casilla genérica de “SEO terminado”.
Cierra el cambio con una comprobación repetible
Conserva juntos el mapa, las respuestas observadas, la hora de revisión y la persona responsable de corregir problemas. Cuando el cambio llegue al alojamiento público, repite allí las pruebas del enlace anterior y del nuevo directo; pasar una prueba en desarrollo no demuestra que la configuración pública coincida.
Registra la indexación en buscadores por separado. Estas comprobaciones establecen adónde llega una solicitud y qué sirve la página; no prometen posiciones ni cambios inmediatos en los resultados de búsqueda. Las rutas del ejemplo son ficticias y no describen una migración realizada por Dynelink.
Contacta con Dynelink para planificar un cambio de URL de servicio con un mapa claro y pruebas de aceptación verificables.