Redirecciones 301 en una migración web: mapa y comprobación

Una redirección 301 comunica un traslado permanente de una URL. Para migrar una web, necesitas decidir qué contenido recibe al visitante, enlazar directamente con ese destino y probarlo. Un código correcto con una página equivocada sigue siendo una migración defectuosa.

La hoja de redirecciones suele parecer un trabajo administrativo. Dos columnas, rutas viejas a la izquierda y rutas nuevas a la derecha. Después llega una petición desde un enlace guardado, un PDF distribuido hace años o una campaña todavía activa, y aquella fila se convierte en una decisión comercial. La persona puede encontrar el servicio que esperaba, una página vagamente parecida o un formulario que ya no entrega nada.

El objetivo de esta guía es convertir esa hoja en un contrato comprobable. No basta con decir que se han añadido las redirecciones. Hay que poder señalar qué URLs se han inventariado, cuáles conservarán su dirección, cuáles cambian, cuáles se retiran y qué prueba demuestra cada decisión. El mapa también debe explicar las excepciones. Dejar una fila vacía y llamarla pendiente es más honesto que asignarle la portada por defecto.

Aquí se trabaja sobre cambios de dirección, no sobre todo el rediseño. Si todavía estás decidiendo si conviene reconstruir la web, empieza por la guía para rediseñar sin perder posicionamiento ni contactos. Si el cambio ya está aprobado, utiliza este procedimiento para preparar la revisión técnica y comercial. Los dos ejemplos desarrollados son hipotéticos: sus dominios, cantidades y decisiones ilustran el método, no describen clientes de YAG ni resultados obtenidos.

Nuestra recomendación editorial es sencilla: conserva una URL útil cuando no existe una razón concreta para cambiarla. Una carpeta más elegante no compensa, por sí sola, el trabajo adicional de migración. Cuando sí hay motivo, separa la decisión editorial de la implementación y de su comprobación pública. Así puedes detectar si el error está en el destino elegido, en la regla que lo sirve o en la página que finalmente aparece.

Redirecciones 301 en una migración web: mapa y comprobación. Asigna destinos equivalentes y prueba cadenas, contenido y formularios antes del lanzamiento.

Trabaja en este orden: inventario de origen, inventario de destino, decisiones de equivalencia, reglas acotadas, pruebas previas, lanzamiento autorizado y comprobación pública. La secuencia evita una confusión frecuente: configurar reglas antes de saber qué páginas se van a publicar. El administrador puede escribir una redirección técnicamente válida; no puede decidir por su cuenta que un servicio concreto y una categoría general son intercambiables.

El paquete mínimo contiene un mapa aprobado, un registro de excepciones, una copia recuperable de la configuración anterior y una batería de pruebas. Añade una ficha para cada recorrido de negocio: contactar, reservar, pedir presupuesto, descargar o comprar. Esas fichas permiten probar desde una URL antigua hasta el efecto observable de la acción. Abrir la home nueva no cubre ese recorrido.

Las referencias oficiales sustentan las definiciones y los límites del proceso. El mapa, los criterios de equivalencia, los ejemplos y las fichas de prueba que siguen son una propuesta operativa original. No son una copia de una lista de Google ni un estándar de obligado cumplimiento para todas las webs. Adáptalos al tamaño del sitio, a su tecnología y al riesgo que tiene interrumpir su actividad.

1. Delimita la migración y escribe qué significa conservar una URL

Cambiar la tecnología no obliga a cambiar las direcciones

Una migración puede trasladar el alojamiento sin cambiar las URLs, sustituir el gestor de contenidos, modificar carpetas, cambiar el dominio o combinar varias cosas. Antes de exportar rutas, describe cuál de esos cambios está realmente aprobado. Una frase como "pasamos a la nueva web" no permite distinguirlos. Escribe, por ejemplo: "se conserva el dominio, cambian las rutas de servicios y se retiran dos ofertas antiguas". Esa frase ya indica dónde concentrar las pruebas.

Mantener una URL significa mantener su función, no solo la cadena de caracteres. Si /servicio-a/ sigue existiendo pero muestra un catálogo genérico, la ruta no se ha roto a nivel de HTTP y sí se ha alterado a nivel de contenido. La hoja debe separar identidad de dirección, identidad de página e intención. Esta distinción evita que una migración sin cambios visibles de URL se declare inocua antes de comparar los contenidos.

Yo prefiero que la primera revisión se haga con alguien que conoce la oferta. El equipo técnico ve plantillas, taxonomías y estructuras; la persona responsable del negocio sabe si un servicio ha cambiado de nombre, de alcance o de condiciones. Puede explicar que dos páginas aparentemente similares atienden a públicos distintos. El mapa será mejor si esa discrepancia aparece antes del lanzamiento y no en un correo de un visitante confundido.

No necesitas convertir cada URL en una reunión. Agrupa decisiones repetidas y reserva la revisión individual para las páginas que venden, reciben enlaces, atienden consultas específicas o contienen información delicada. Las demás también necesitan destino, pero pueden seguir una regla aprobada con muestras representativas. El error sería usar la prioridad como excusa para olvidar toda la cola larga. Priorizar decide el orden, no borra el inventario.

Fija alcance, responsables y condiciones de parada

Una ficha de migración útil incluye el dominio de origen, el de destino si cambia, las secciones afectadas, la fecha prevista, quién decide el contenido y quién puede publicar. También enumera exclusiones: correo, áreas privadas, pagos, integraciones o subdominios que no se trasladan. Esa lista impide que una regla global atrape servicios que pertenecen al mismo dominio pero no al mismo proyecto.

Escribe condiciones de parada concretas. Por ejemplo, no publicar si queda una página comercial sin decisión, si un destino aprobado devuelve un error inesperado o si el formulario principal no tiene una entrega de prueba confirmada. No hace falta fingir un umbral científico. Son acuerdos de aceptación del proyecto, elegidos por su riesgo. Una web informativa y una plataforma que procesa reservas no deben compartir el mismo criterio de salida.

Asigna también quién autoriza una retirada. El desarrollador no debería borrar una página porque no encuentra una plantilla equivalente. La ausencia de plantilla es un problema de implementación; la decisión de dejar de ofrecer algo corresponde a otra persona. Registra el motivo y su aprobación. Cuando varios participantes trabajan sobre la hoja, esta separación ahorra correcciones de último minuto y evita que "no estaba en el diseño" se convierta en política editorial.

El plan de vuelta atrás necesita algo más que una copia de archivos. Tiene que indicar qué versión de las reglas estaba activa, dónde se restaura, qué contenido debe acompañarla y cómo comprobar que el recorrido vuelve a funcionar. Si la web nueva ha recibido solicitudes o pedidos, recuperar una base antigua sin conciliación puede destruir información válida. Una vuelta atrás debe proteger también los datos generados después del cambio.

Define una cobertura que no pueda maquillarse

Divide el alcance en unidades contables: URLs, familias de reglas, plantillas y recorridos comerciales. Para cada grupo conserva numerador y denominador. "Destinos revisados: 42 de 45" dice algo que "migración casi lista" no dice. Explica cuáles son las tres excepciones y su riesgo. No mezcles URLs probadas automáticamente con páginas revisadas en navegador; ambas pruebas aportan evidencia distinta.

Evita un porcentaje general que esconda defectos dominantes. Puedes haber comprobado muchas páginas de archivo y tener roto el único formulario de presupuesto. El informe debe mostrar ese bloqueo sin compensarlo con pruebas menores. Mi criterio sería considerar el recorrido comercial afectado como una condición independiente de aceptación. No sustituye el resto del inventario, pero tampoco queda diluido entre cientos de respuestas correctas.

Conserva las URLs que no cambian como casos de control. Permiten detectar una regla demasiado amplia, una normalización nueva o una diferencia de plantilla que no debería existir. Si pruebas únicamente las rutas que sabes que van a redirigir, puedes no ver que una regla por prefijo también ha capturado páginas que debían continuar. La migración se valida contra lo que cambia y contra lo que debe permanecer estable.

2. Construye el inventario antiguo sin confundir una fuente con el sitio completo

Une fuentes y conserva su procedencia

El inventario no debería depender exclusivamente del sitemap actual. Ese archivo puede no contener documentos descargables, campañas viejas, páginas huérfanas o variantes que todavía reciben peticiones. Tampoco el menú representa el sitio completo. Reúne las fuentes que están disponibles y anota cuáles faltan: exportación del gestor, rastreo del sitio, sitemaps, registros del servidor y datos de entrada o enlaces cuando el acceso esté autorizado.

Cada fuente responde a una pregunta distinta. El gestor informa de contenidos registrados; el rastreo informa de lo que se alcanza desde sus puntos de partida; los registros muestran peticiones observadas en un periodo; los informes de búsqueda muestran datos de esa plataforma. Una URL ausente de una fuente no deja de existir automáticamente. La unión sirve para ampliar el alcance, no para declarar que la cobertura es absoluta sin conocer sus límites.

Guarda una columna fuente y otra periodo. Si una ruta aparece en un registro de servidor, no la describas como una página comercial sin abrirla. Puede ser un intento de acceso a una ruta inexistente. Si procede del gestor, comprueba si estaba publicada, archivada o en borrador. El inventario debe separar evidencia de existencia, evidencia de uso y evidencia de valor. Son tres decisiones relacionadas, pero no equivalentes.

No copies información personal a una hoja compartida para demostrar que tienes registros. Para el mapa suelen bastar ruta, fecha resumida, tipo de origen y agregados necesarios. Elimina tokens, correos y valores privados de las consultas. Si una URL contiene un identificador sensible, la revisión debe establecer cómo manejarlo en un entorno controlado; publicarlo dentro del documento de migración añade un problema que no ayuda a resolver el traslado.

Normaliza para comparar, no para borrar diferencias

Puedes crear una versión normalizada para eliminar duplicados de presentación, pero conserva siempre la URL original observada. No conviertas de forma indiscriminada todas las rutas a minúsculas ni elimines los parámetros antes de saber qué significan. Una comparación cómoda puede destruir la diferencia que precisamente necesitas migrar. Mantén url_observada y clave_comparacion como campos separados, con la transformación documentada.

Clasifica variantes de protocolo, host y barra final. Una persona puede acceder desde http, desde una versión con www o desde una ruta sin la barra que utiliza tu sitio. Decide cuál será la dirección final y prepara pruebas para las variantes. No presupongas que la plataforma nueva normaliza igual que la antigua. El mapa principal puede contener una ruta por contenido, mientras una tabla auxiliar conserva sus variantes de entrada.

Los parámetros merecen una clasificación propia. ?id=27 puede identificar un contenido antiguo; un parámetro de idioma puede cambiar el texto; una etiqueta de campaña puede servir para atribución. Tratarlos todos como ruido lleva a trasladar personas a la ficha equivocada o a borrar el contexto de medición. Documenta su finalidad antes de decidir la política. Cuando no conozcas el comportamiento, crea un caso de prueba y mantén la decisión pendiente.

Las imágenes, catálogos y otros documentos necesitan inventario cuando forman parte del recorrido. No todo archivo requiere una redirección individual: quizá se conserve la misma ruta. Pero hay que comprobarlo. Un catálogo enlazado desde un correo antiguo puede seguir siendo una entrada comercial aunque no figure en ninguna navegación actual. Si se retira, explica la retirada; si se sustituye, revisa el documento nuevo antes de asignarlo como equivalente.

Ordena el riesgo sin inventar métricas

La prioridad puede basarse en señales disponibles: relación con ventas, enlaces observados, tráfico documentado, uso en campañas o relevancia de contenido. Si no tienes datos, utiliza una clasificación editorial y márcala como tal. No rellenes la hoja con cifras estimadas que luego se interpretarán como una línea base. "Prioridad alta por decisión del negocio" es una descripción válida y mucho más clara que una puntuación opaca de valor SEO.

Revisa primero las páginas que sostienen acciones concretas, después las que resuelven consultas específicas y finalmente los grupos repetitivos. En una web de servicios, esa secuencia suele ser más útil que empezar alfabéticamente. Sin embargo, una página secundaria puede tener un enlace externo relevante o un documento todavía distribuido. La ordenación debe poder cambiar cuando aparece nueva evidencia; no es una jerarquía permanente del contenido.

Marca los registros dudosos con una acción siguiente: abrir, consultar gestor, revisar respuesta HTTP o pedir decisión editorial. "Pendiente" sin acción ni responsable se acumula hasta el día del lanzamiento. Si la duda no puede resolverse de forma segura, conserva la ruta anterior cuando sea viable o excluye el cambio de ese bloque. No la hagas desaparecer de la hoja para conseguir un porcentaje mejor.

Nuestra propuesta es conservar una fotografía fechada del inventario y no sobrescribirla con el listado nuevo. Después del lanzamiento sirve para investigar por qué una ruta faltaba o cómo se clasificó. La fotografía no garantiza que no existan URLs adicionales; prueba qué sabías cuando decidiste. Esa diferencia importa al explicar una incidencia sin inventar que el equipo había revisado algo que nunca apareció en sus fuentes.

3. Asigna destinos por intención y publica un mapa que pueda revisarse

La equivalencia exige leer ambas páginas

Un destino equivalente conserva la necesidad que motivó la visita. No exige repetir el texto palabra por palabra, pero sí resolver el mismo problema con una oferta compatible. Antes de aprobar una fila, abre el contenido antiguo y el nuevo. Comprueba qué servicio describen, para quién, en qué ámbito y con qué acción siguiente. La similitud del título ayuda a localizar candidatos; no basta para validar el traslado.

Una página de mantenimiento de tiendas no es equivalente a una página general de creación de tiendas aunque ambas contengan "tienda online". Una ficha de producto agotado tampoco tiene automáticamente como sustituto una categoría. Puede existir una alternativa razonable, pero hay que justificarla y comprobar que el visitante entiende la diferencia. Yo rechazaría una hoja basada únicamente en coincidencias de palabras: genera destinos plausibles y errores comerciales difíciles de detectar con HTTP.

En las fusiones, el destino debe incorporar la parte útil de las páginas absorbidas. Si juntas tres artículos, revisa sus preguntas distintivas y decide dónde aparecen en la pieza nueva. La redirección puede ser correcta técnicamente y borrar una explicación que atraía a un público concreto. El mapa debería señalar qué contenidos se han conservado y cuáles se han retirado conscientemente, no limitarse a la relación entre rutas.

Cuando una página se divide, una sola redirección no puede enviar a cada visitante a una de varias nuevas páginas según su intención desconocida. Elige un destino que permita orientarse de manera honesta, conserva la página como índice si tiene sentido o revisa la división. La solución debe responder al contenido original. No inventes un destino individual para cada posible consulta sin conocer qué pidió realmente la persona.

Un CSV de trabajo original

Este ejemplo utiliza dominios reservados para documentación y decisiones hipotéticas. La columna motivo es deliberadamente breve, pero debe bastar para que otro revisor entienda la relación. estado_revision distingue una propuesta de una decisión aprobada. El estado HTTP esperado se declara por fila; no todas las URLs antiguas tienen por qué producir una redirección.

url_origen,accion,url_destino,http_esperado,motivo,prioridad,responsable,estado_revision
https://origen.example/servicios/web/,redirigir,https://destino.example/diseno-web/,301,mismo servicio y alcance,alta,editorial,aprobado
https://origen.example/contacto/,conservar,https://origen.example/contacto/,200,ruta sin cambio,alta,tecnico,aprobado
https://origen.example/blog/guia-a/,fusionar,https://destino.example/blog/guia-unificada/,301,respuestas incorporadas al destino,media,editorial,aprobado
https://origen.example/oferta-retirada/,retirar,,410,oferta eliminada sin equivalente,media,negocio,aprobado
https://origen.example/servicio-dudoso/,revisar,,,falta decidir equivalencia,alta,negocio,pendiente

No mezcles en esa hoja credenciales ni nombres de visitantes. El responsable puede identificarse por función. En un proyecto real puedes añadir un identificador de decisión, la fecha de aprobación, una referencia a la captura anterior y la prueba posterior. Si necesitas columnas de tráfico o de ventas, indica su fuente y periodo. Un CSV no debería convertir números de procedencia distinta en una comparación aparentemente homogénea.

Conviene utilizar vocabulario cerrado en accion: conservar, redirigir, fusionar, retirar y revisar. Las expresiones libres como "más o menos igual" o "llevar a servicios" no sirven para generar reglas ni para auditar resultados. Si una decisión todavía necesita explicación, conserva el estado pendiente. Mi preferencia es una hoja con menos filas aprobadas y razones legibles antes que un listado completo fabricado por parecido de rutas.

Revisa conflictos antes de escribir reglas

Busca orígenes duplicados con destinos distintos. También destinos vacíos en filas aprobadas, orígenes que se redirigen a sí mismos y páginas nuevas que figuran simultáneamente como destino y como retirada. Estos conflictos pueden detectarse en la hoja sin tocar el servidor. No hace falta esperar a que produzcan un fallo público. Define qué conflictos bloquean la generación de configuración y conserva la salida del control.

Un destino repetido no es necesariamente un error. Puede representar una fusión editorial aprobada. Lo que necesita revisión es la razón de esa concentración. Si muchas páginas distintas terminan en una portada o una categoría apenas relacionada, vuelve a leerlas. Google desaconseja los destinos irrelevantes y advierte de posibles errores soft 404 en su documentación de migraciones con cambios de URL. No conviertas la fusión en una excusa para vaciar el contenido.

La aprobación debe vincularse a una versión. Si una página de destino cambia después de revisarla, la equivalencia puede dejar de ser válida. Registra la fecha o la versión del contenido comprobado. No es necesario crear un sistema complicado: una captura fechada y una identificación de la versión pueden bastar. Lo importante es no arrastrar una aprobación antigua a un texto que ya describe otra oferta.

Antes de entregar el mapa al administrador, distingue reglas exactas y reglas por familia. Una regla exacta mueve una entrada determinada; una familia transforma un patrón común. Las segundas requieren demostrar que sus excepciones están cubiertas. No envíes solo una lista de casos felices. Añade rutas parecidas que no deben redirigir, destinos que deben conservarse y parámetros que cambian el significado. Así la revisión técnica empieza con pruebas negativas.

4. Elige 301, 308, 302, 404 o 410 según lo que ha ocurrido

El estado es una decisión semántica

El código HTTP comunica qué ha sucedido con el recurso. No debería elegirse porque un complemento lo ofrece primero ni porque alguien lo considera "más SEO". La RFC 9110 define estos estados: 301 y 308 indican traslado permanente; 302 indica ubicación temporal; 404 informa de que no se encuentra una representación actual; 410 expresa una retirada probablemente permanente. Una 301 puede cambiar POST a GET por razones históricas; 308 permite conservar el método.

La tabla no asigna una solución automática a todos los sitios. Describe preguntas de revisión. Un servicio que cambia su nombre puede mantener la dirección; otro puede necesitar traslado; una campaña cerrada puede conservar información histórica. La decisión de contenido precede al código. No utilizaríamos un 410 como sustituto de preguntar si el negocio desea mantener una explicación de la oferta que ya no acepta solicitudes.

Las páginas y los endpoints tienen riesgos distintos

Un endpoint es una dirección a la que una aplicación envía o solicita datos. Aunque parezca otra URL del sitio, no se valida leyendo una página. Si el formulario antiguo enviaba datos a una ruta que cambia, hay que revisar el destino configurado y comprobar la operación. Una redirección que lleva al navegador a la página de contacto no demuestra que se haya conservado el mensaje enviado.

No añadiría una regla general para todos los métodos sin inventariar qué hace cada ruta. Las páginas públicas suelen revisarse con navegación normal, pero formularios, webhooks y API requieren pruebas específicas. Una respuesta permanente puede propagarse a clientes o cachés, de modo que una prueba improvisada sobre un endpoint real puede tener consecuencias. Trabaja con un entorno preparado y datos de prueba autorizados, sin repetir operaciones que ya han producido un efecto.

El método tampoco resuelve por sí solo la compatibilidad. Conservar un POST no demuestra que el destino acepte los mismos campos, entienda el mismo token o entregue al mismo buzón. Puede existir una incompatibilidad de esquema aunque el HTTP sea correcto. En esos casos, corrige la integración o mantén compatibilidad explícita; no presentes la elección entre 301 y 308 como una solución completa.

Mi recomendación es excluir de las reglas editoriales todo lo que procesa transacciones hasta que su propietario técnico lo revise. Eso no significa dejarlo fuera de la migración. Significa darle su propia ficha de prueba, con el efecto que debe observarse y la forma de revertirlo. Si una integración no puede probarse con seguridad, ese tramo queda sin verificar y debe reflejarse en la aceptación.

Qué hacer cuando no existe equivalente

La ausencia de equivalente exige una decisión, no una redirección de compromiso. Puedes conservar una página informativa, crear un destino que recoja realmente su contenido o retirarla. Considera quién llega, qué necesita saber y qué puede ofrecer el negocio. Una página sobre un servicio cancelado puede explicar que ya no está disponible y proponer una alternativa sin fingir que es lo mismo. Esa decisión editorial debe verse también en la interfaz.

Una página de error útil puede incluir navegación y un acceso a contacto, manteniendo el código de error que corresponda. Mostrar ayuda no obliga a responder con 200. Prueba el estado real, porque una plantilla visual de "no encontrado" puede servirse como si todo fuera correcto. También comprueba que no expone información interna y que se puede utilizar desde móvil. El error forma parte de la experiencia, aunque no sea una página comercial.

No conviertas las peticiones a rutas inventadas en destinos válidos solo para reducir el número de errores del informe. Un rastreo o un registro puede contener basura y ataques. La meta no es eliminar todo 404 del servidor. Es que las URLs conocidas y relevantes tengan un comportamiento aprobado, y que el resto no confunda a personas ni a herramientas. Un informe sin errores puede esconder una regla global que redirige indiscriminadamente.

La guía oficial de redirecciones de Google trata las permanentes como señales de que el destino debe ser canónico y recomienda redirecciones de servidor cuando son posibles. Ese fundamento no promete posiciones. Nosotros añadiríamos una revisión de contenido y de conversión porque son obligaciones del proyecto, no propiedades garantizadas por el código.

5. Elimina cadenas, bucles y normalizaciones contradictorias

Dibuja el recorrido observado

Una cadena pasa por direcciones intermedias antes del destino final. Un bucle vuelve a una dirección ya visitada. El dato que necesitamos es el recorrido completo: petición inicial, estado, cabecera Location, siguiente petición y respuesta final. Registrar únicamente la última URL puede esconder pasos innecesarios o reglas enfrentadas. También puede hacer que una herramienta anuncie éxito porque finalmente obtuvo una página, aunque el camino no coincida con el mapa.

Para cada origen aprobado, compara el recorrido con la expectativa. Si esperabas un salto y observas varios, identifica quién produce cada uno. Puede intervenir una regla de servidor, una capa de distribución, un complemento o la aplicación. No modifiques todas a la vez. Localiza la transformación que añade un intermediario y comprueba si puedes enviar directamente al destino final sin romper otros recorridos.

Yo trataría un bucle como bloqueo de lanzamiento en cualquier ruta que esté dentro del alcance. No es una cuestión de gusto: el usuario no llega al contenido. Conserva el caso exacto que lo reproduce, incluidos host, protocolo y parámetros necesarios. Una descripción como "a veces redirige mal" no permite corregirlo ni probar la corrección. La ficha debe incluir el origen y la secuencia repetida, sin valores sensibles.

Las cadenas deben revisarse también desde enlaces internos. Aunque los accesos antiguos necesiten redirección, la nueva web debería enlazar con sus destinos finales. Si el menú nuevo sigue utilizando rutas antiguas, has mantenido dependencia del mapa en el uso diario. Corrige esos enlaces y deja las redirecciones para compatibilidad de entradas anteriores, no como atajo para evitar actualizar el contenido nuevo.

Barra final, protocolo y host

Es frecuente que una capa añada barra final y otra la retire. El mismo conflicto puede aparecer entre www y la versión sin www, o entre protocolos. Define la forma final una vez y comprueba que todas las capas la respetan. La forma elegida debe coincidir con los enlaces y con la configuración de la aplicación. No basta con que cada equipo diga que su regla, por separado, funciona.

Una prueba de variantes puede partir de una página y revisar todas las entradas conocidas. No necesita inventar combinaciones infinitas, pero sí cubrir las que existen en el inventario y las generadas por las reglas nuevas. Si el dominio cambia, incluye las variantes antiguas que pueden recibir tráfico. Comprueba el certificado y la respuesta antes de esperar que una redirección resuelva la visita: el acceso inicial también debe poder establecerse.

No utilices una transformación de barra como primer paso obligado si puedes construir directamente el destino canónico. El diseño de la regla debe tener en cuenta el recorrido completo. Aun así, evita obsesionarte con reducir un salto a costa de una regla difícil de mantener o que cubra mal las excepciones. La decisión debe quedar respaldada por pruebas y por un propietario que entienda cómo modificarla.

Cuando compares respuestas, distingue el comportamiento del servidor de la navegación del navegador. Una herramienta puede observar un recorrido diferente si hay caché o una normalización previamente guardada. Repite el caso en un contexto limpio y conserva qué has probado. No interpretes esa repetición como una garantía de que todos los visitantes han descartado respuestas antiguas. La prueba acredita su contexto, no toda la población.

Parámetros y rutas que parecen iguales

Una regla por prefijo puede capturar /servicio-a-detalle/ cuando solo querías mover /servicio-a/. Una sustitución de carpeta puede afectar a descargas o a endpoints. Prepara casos que empiecen de forma parecida y deban quedarse intactos. También revisa caracteres escapados y rutas con diferencias que el sistema antiguo trataba de manera específica. No des por hecho que una normalización mantiene el mismo significado en otra plataforma.

La política de parámetros debe declarar cuáles se conservan, cuáles se transforman y cuáles se descartan. Si una antigua ficha usa un identificador en la consulta, el destino puede necesitar un mapa exacto. Si un parámetro aporta atribución, revisa su continuidad de acuerdo con la política de medición aprobada. Evita reenviar consultas privadas o arbitrarias sin control. La compatibilidad no justifica propagar datos que no deberían circular.

Una prueba negativa útil es solicitar una ruta inexistente que comparta prefijo con una válida. Si termina en un servicio real por una regla demasiado amplia, revisa la captura. Otra prueba consiste en cambiar un identificador que no existe. La salida debe responder a una decisión definida, no inventar una ficha equivalente. El mapa no solo sirve para los casos conocidos; también debe marcar dónde se detiene una familia de reglas.

Conserva un pequeño listado de regresión con estos casos. Cada vez que añadas un destino o modifiques una normalización, vuelve a ejecutarlo junto al mapa principal. Es una inversión más útil que una nota genérica de "revisar redirecciones". La prueba mantiene visible el error que quieres evitar. Sin ella, una corrección de barra final puede reintroducir el bucle que otro participante eliminó la semana anterior.

6. Prueba el mapa antes de publicar con controles positivos y negativos

Una batería de pruebas empieza por expectativas

Antes de ejecutar una comprobación automática, escribe qué debe pasar. Una herramienta puede recorrer URLs, pero no conoce la intención editorial si no se la proporcionas. Para una fila de traslado, declara el código inicial esperado, el destino final, los saltos admitidos y el contenido que identifica la página. Para una retirada, declara el error esperado. Para una ruta conservada, indica que no debe entrar en una regla de migración.

Divide las pruebas en cuatro grupos: mapa, respuesta HTTP, contenido e interacción. El mapa detecta conflictos sin peticiones; HTTP confirma reglas; contenido verifica que el destino responde a la necesidad; interacción comprueba la acción. No sustituyas un grupo por otro. La automatización puede comparar direcciones y estados, mientras una revisión de negocio decide si la información conserva el alcance aprobado. Un formulario necesita una comprobación adicional de entrega.

El entorno previo debe parecerse al final en los aspectos que estás probando. Si pruebas las reglas solo dentro de la aplicación pero se publicarán detrás de otra capa con normalizaciones propias, la evidencia es parcial. Documenta esa limitación y reserva una prueba pública posterior. No abras el entorno de pruebas a buscadores para facilitar una comprobación ni quites sus protecciones sin una razón autorizada. La verificación debe respetar el aislamiento.

Mi preferencia es ejecutar primero los conflictos del CSV. Son rápidos y evitan lanzar peticiones hacia destinos incoherentes. Comprueba que todas las filas aprobadas están completas, que los destinos pertenecen al alcance y que no hay ciclos dentro del propio mapa. Después ejecuta las respuestas. Si la herramienta observa un fallo de acceso, clasifícalo como tal; no lo conviertas automáticamente en una prueba de que la redirección está mal configurada.

Dos comprobaciones de lectura con curl

Estos comandos son ejemplos para un entorno autorizado y usan dominios de documentación. No implementan reglas ni se han ejecutado sobre una web real dentro de este artículo. La primera petición utiliza GET, descarta el cuerpo y muestra las cabeceras sin seguir redirecciones. La segunda sigue un máximo acotado de saltos y resume el resultado. La sintaxis del bloque es de Bash. En PowerShell puedes utilizar curl.exe, escribir cada comando en una sola línea y sustituir /dev/null por NUL.

curl --silent --show-error --dump-header - --output /dev/null \
  'https://origen.example/servicios/web/'

curl --silent --show-error --location --max-redirs 5 \
  --output /dev/null \
  --write-out 'final=%{url_effective} estado=%{http_code} saltos=%{num_redirects}\n' \
  'https://origen.example/servicios/web/'

La cifra de cinco saltos es un límite de prueba de este ejemplo, no una recomendación de diseño. Un recorrido que supere el límite necesita investigación; un recorrido por debajo puede seguir siendo incorrecto. Compara con la expectativa de la fila, que en una migración sencilla proponemos como destino directo. Conserva las cabeceras cuando debas identificar la capa que genera cada paso y no copies valores privados al informe.

No utilices únicamente una petición HEAD si la plataforma responde de forma distinta a GET. El caso principal debe reproducir la forma de acceso que quieres comprobar. Tampoco fuerces métodos o envíes formularios desde un listado de URLs sin saber cuáles tienen efectos. Una batería de lectura debe excluir operaciones transaccionales. Para estas prepara datos de prueba y una autorización concreta, con un registro que evite duplicaciones.

Ficha de resultados y reglas de aceptación

caso,url_entrada,esperado,observado,evidencia,decision
R001,https://origen.example/servicios/web/,301 a diseno-web en un salto,pendiente,pendiente,no evaluado
R002,https://origen.example/contacto/,200 sin redireccion,pendiente,pendiente,no evaluado
R003,https://origen.example/oferta-retirada/,410 y ayuda navegable,pendiente,pendiente,no evaluado
N001,https://origen.example/servicios/web-inexistente/,404 sin captura de prefijo,pendiente,pendiente,no evaluado
F001,recorrido presupuesto desde R001,solicitud de prueba recibida una vez,pendiente,pendiente,no evaluado

La tabla anterior no es un resultado: todas las observaciones están pendientes. En una ejecución real añade fecha, versión y contexto. Una captura debe identificar la página revisada; un resultado automático debe indicar el caso y la respuesta. Evita la palabra "correcto" sin evidencia. Si el destino final coincide pero el contenido no, marca fallo de equivalencia. Si el contenido está bien pero falta la recepción del formulario, marca interacción no verificada.

Añade pruebas negativas de límites. Una ruta similar no afectada, un parámetro desconocido, una dirección retirada y una página que debe mantenerse suelen descubrir fallos que no aparecen en el caso principal. Para familias grandes, justifica la selección de muestras y conserva el control automático del conjunto. Revisar algunas páginas en navegador no demuestra que todas se vean igual; declara la cobertura visual sin extrapolarla.

La aceptación se realiza por bloque y por defecto dominante. Una cadena en una página de archivo puede requerir corrección, pero un bucle en la entrada de presupuesto bloquea su recorrido completo. Asigna gravedad con una razón legible, no con un color sin definición. Deja preparada la repetición de la prueba fallida. El día de publicación tendrás menos tiempo para investigar y más necesidad de distinguir una incidencia nueva de una ya conocida.

7. Ejemplo hipotético: web de servicios que cambia carpetas y fusiona dos guías

Situación de partida y decisiones

Este caso es totalmente hipotético. Una empresa tiene una web con doce páginas de servicio, seis artículos, una página de contacto y un catálogo descargable. El equipo quiere sustituir /servicios/ por rutas directas y reunir dos guías que se solapan. Los veinte contenidos de este inventario ilustrativo no son una muestra de cliente ni una cifra de rendimiento. Los usaremos para explicar qué se conserva y qué se transforma.

La primera decisión es que el cambio de carpetas debe afectar únicamente a páginas cuyo contenido se ha revisado. Una página de mantenimiento conservará su alcance y cambiará la ruta; otra de diseño también. No se fusionarán porque compartan la palabra "web". La portada, contacto y catálogo mantendrán sus direcciones. Los artículos se revisarán uno por uno, porque la propuesta de fusión podría borrar una pregunta que solo responde una de las piezas.

Mi recomendación en este escenario sería cuestionar primero si hace falta cambiar la carpeta. Si el negocio aporta una razón concreta, seguimos con el mapa. Si solo prefiere rutas más cortas, puede conservar las existentes y concentrar el esfuerzo en contenido y navegación. El ejemplo continúa suponiendo que la decisión ya está aprobada. Esa premisa no convierte el cambio en una recomendación universal para otras webs.

La ficha de un servicio contiene texto anterior, texto nuevo, público, ámbito y acción principal. El revisor comprueba que la nueva página permite pedir el mismo tipo de presupuesto. Después asigna /servicios/mantenimiento/ a /mantenimiento-web/, con traslado permanente y destino directo. Si el diseño nuevo no explica mantenimiento, la fila vuelve a revisión; no se considera aprobada porque exista la ruta.

Fusión con comprobación de contenido

Las dos guías del ejemplo describen cómo preparar materiales antes de una reunión de diseño. Una aporta una lista de archivos y otra explica permisos y revisión de textos. El nuevo artículo puede recoger ambos contenidos, pero exige una revisión editorial. Escribimos en el mapa que las preguntas sobre archivos y permisos deben encontrarse en el destino. Así la equivalencia no depende solo de un título parecido.

La página fusionada debe tener una acción siguiente coherente con el nivel de decisión del lector. No sustituimos dos guías de preparación por una página de contratación que omite sus instrucciones. Esa redirección llevaría al mismo negocio, pero no a la misma respuesta. El mapa tampoco necesita garantizar que todas las consultas antiguas mantendrán su posición. Solo permite demostrar qué contenido se ha conservado y dónde puede leerlo el visitante.

El catálogo mantiene su ruta, pero el archivo cambia de versión. La prueba debe revisar que se abre, que sus enlaces son válidos y que no contiene oferta retirada. Mantener la URL no exime de comprobar el documento. Si el proyecto no incluye revisar documentos, se declara como exclusión y se mantiene la versión anterior hasta la decisión adecuada. No actualizamos una portada y damos por revisado todo el material comercial.

Las páginas de contacto se incluyen como control de estabilidad. Prueba desde una dirección vieja de servicio, llega al destino nuevo, abre contacto y completa una solicitud sintética autorizada. Comprueba el efecto de recepción, no solo el mensaje visual de éxito. También recorre la misma acción desde móvil. Un mapa perfectamente implementado puede desembocar en un botón inaccesible o un campo que impide continuar con el teclado.

Un fallo que obliga a volver a la regla

Supongamos que una regla por prefijo mueve todo /servicios/ a la nueva ruta de diseño. En el control automático, varias entradas terminan en una página válida con 200. Parece una mejora frente al error, pero la prueba editorial detecta que mantenimiento y asesoría también acaban en diseño. El problema está en la captura excesiva. La corrección es volver a las correspondencias aprobadas o a una familia que realmente conserve la identidad de cada servicio.

Añadimos como regresión una ruta inexistente dentro de la carpeta y una página de mantenimiento. La primera no debe convertirse en una oferta inventada; la segunda debe llegar a su propio destino. Después repetimos todos los orígenes afectados por la regla, no solo el que mostró el fallo. Una corrección local puede resolver una entrada y dejar otras mal. El conjunto de reglas comparte alcance y debe revisarse con esa dependencia.

El cierre hipotético se expresaría por capas: veinte decisiones revisadas, veinte respuestas comprobadas, las plantillas acordadas abiertas en escritorio y móvil, y el recorrido de contacto verificado. Si falta abrir una plantilla de artículo, ese tramo sigue pendiente aunque sus URLs respondan. Ninguna de estas cifras describe pruebas ejecutadas por YAG en un cliente. Son el formato de cobertura que proponemos para que un responsable pueda aceptar o rechazar un proyecto.

El aprendizaje del ejemplo es concreto: una regla amplia puede ocultar una pérdida de equivalencia. El control de 200 no la descubre. El mapa aprobado, la revisión de contenido y las pruebas negativas sí la hacen visible. No necesitamos inventar una subida o caída de tráfico para explicar el riesgo. El daño verificable dentro del escenario es que el visitante recibe otro servicio.

8. Ejemplo hipotético: catálogo con productos retirados y parámetros de identificación

Un identificador no es ruido

Este segundo caso también es hipotético. Un catálogo usa direcciones como /ficha.php?id=27 y se traslada a rutas legibles. Algunos productos continúan, otros han desaparecido y dos se han incorporado a una ficha conjunta. El número 27 es solo un identificador del ejemplo; no expresa popularidad ni ventas. La primera obligación es saber qué ficha representa cada identificador y qué información debe recibir quien llega por ese enlace.

No podemos resolver este traslado quitando todos los parámetros. Al hacerlo, varias fichas terminarían en la misma entrada genérica. La nueva dirección de un producto activo requiere una correspondencia explícita con su identificador antiguo. Si hay variantes con otros parámetros, se revisan por separado: algunos podrían cambiar una opción, otros aportar medición y otros no tener función válida. La política debe describir qué hace el catálogo, no una supuesta regla SEO general.

Antes de mapear, exportamos en el escenario una relación de identificadores y estado editorial. Separaríamos activo, sustituido, fusionado y retirado. El inventario puede contener identificadores desconocidos procedentes de peticiones observadas. No los asignamos a un producto por aproximación numérica. Los casos que el negocio no reconoce deben mantener una respuesta de ausencia definida. El mapa se construye a partir de identidad de contenido, no de continuidad de números.

Aquí considero más útil una prueba de producto que una revisión de diseño general. La persona debe ver el nombre correcto, sus características, su disponibilidad y una acción compatible. Si la ficha nueva muestra un producto distinto pero responde con 200, el traslado falla. Si muestra el correcto y permite pedir algo retirado, falla la información comercial. Las redirecciones no corrigen una decisión de catálogo incoherente.

Retiradas y alternativas honestas

Para un producto que ya no existe y no tiene sustituto, el negocio debe decidir si conserva información histórica o retira la ficha. Puede ser útil mantener especificaciones para personas que ya lo poseen. En ese caso la página debe decir que no se vende y evitar un botón de compra engañoso. Si se elimina, registra el motivo y el estado previsto; una categoría genérica no será equivalente solo porque aún tenga productos.

Cuando existe sustituto, compara sus diferencias. No basta con que sea el modelo más reciente. Puede cambiar medidas, compatibilidad o uso. Si el traslado está justificado, el destino debería explicar esas diferencias donde importen. En el mapa anotamos la aprobación editorial y la revisión del contenido. Si las diferencias son tan grandes que desorientan a quien busca el anterior, conservar una página de orientación puede ser mejor que una redirección directa.

Para una ficha conjunta, comprueba que las referencias de ambas antiguas aparecen de manera comprensible. El destino no puede asumir que todos conocen el nuevo nombre comercial. Añade una prueba que busque la referencia anterior y abra la información correspondiente. No se trata de insertar palabras para manipular búsquedas, sino de conservar el puente entre un enlace distribuido y la información que necesita su destinatario.

Un identificador inexistente merece un control negativo. Si /ficha.php?id=99999 termina en la ficha del producto activo por una regla de reserva, has convertido ausencia en identidad falsa. La corrección debe definir qué sucede fuera del mapa. Repite también el caso sin id, con un valor vacío y con un parámetro adicional permitido. Cada prueba debe tener una expectativa; una salida distinta no se resuelve escogiendo cualquier página que cargue.

Medición, carrito e integraciones

Si el catálogo permite comprar, separa las páginas de lectura de las rutas que modifican carrito o procesan pedidos. No ejecutes un barrido de URLs sobre operaciones desconocidas. Prepara un entorno y una secuencia de prueba con datos sintéticos. Comprueba referencia, cantidad, precio mostrado, estado del pedido y efecto observable según el alcance autorizado. Una migración editorial de fichas no concede permiso para hacer cobros reales.

Los parámetros de campaña requieren una decisión compatible con la política de privacidad y medición. Conserva solo lo necesario y permitido. Comprueba que la herramienta elegida identifica la entrada y la acción sin duplicar eventos. Si falta medición en el destino, una caída del informe puede no describir una caída de visitas. Antes de atribuirla a las redirecciones, revisa qué se registra y compara una visita de prueba controlada.

El recorrido se valida desde el enlace antiguo, no únicamente abriendo la ficha nueva. De lo contrario no pruebas la traducción del identificador ni la conservación de contexto. Revisa también enlaces de catálogo, confirmaciones y documentos que el proyecto incluye. Una regla puede funcionar al entrar desde búsqueda y fallar desde un enlace de correo con parámetros. La matriz de casos permite mostrar esas diferencias sin formular una promesa general.

El cierre del escenario separaría cuatro conclusiones: mapa de identidad aprobado, reglas verificadas, información comercial correcta y operación probada en el entorno autorizado. La observación de rendimiento quedaría después. No publicamos porcentajes de mejora inventados porque no hay un negocio real ni datos medidos detrás. El valor del ejemplo está en enseñar dónde una transformación aparentemente sencilla puede confundir productos, retirar información útil o romper una acción.

9. Comprueba canónicas, navegación, formularios y medición en el destino

Una señal coherente no garantiza una elección de Google

La documentación de canonicalización de Google describe las redirecciones y rel="canonical" como señales fuertes para proponer una URL canónica. Una señal fuerte no equivale a una garantía de que Google elegirá esa dirección o mantendrá una posición. En el proyecto debemos revisar que la preferencia declarada no contradiga el destino aprobado y que el contenido que se quiere publicar esté realmente disponible.

El control compara URL final, canónica declarada y enlaces que utiliza la página. Si el visitante llega a una ruta nueva pero el HTML señala la antigua, registra la contradicción y localiza su origen. Puede proceder de una configuración heredada o de una plantilla. No cambies metadatos en bloque sin comprobar si las páginas afectadas comparten la misma decisión. Una corrección global puede resolver el servicio principal y romper una variante que necesita otra política.

Revisa también las protecciones del entorno previo. La web pública debe tener la configuración de indexabilidad aprobada, mientras el entorno de pruebas mantiene la suya. No elimines restricciones indiscriminadamente de todo el alojamiento. En la ficha registra qué contenido debía ser accesible y qué cabeceras o etiquetas observaste. Si no puedes comprobarlo, no escribas "indexabilidad verificada" porque la página abre en tu navegador autenticado.

La canónica no sustituye a una redirección cuando el usuario necesita trasladarse. Una etiqueta no cambia su navegación de la misma manera. Tampoco debería utilizarse para justificar que una página con contenido distinto se agrupe arbitrariamente con otra. Nuestra recomendación es revisar primero la equivalencia y después las señales, con la misma versión de contenido. Así no intentas compensar una mala decisión editorial con una configuración técnica.

Navegación y recursos desde entradas reales

Abre destinos desde sus orígenes antiguos y desde enlaces internos nuevos. Comprueba menú, migas de navegación si existen, enlaces de contenido y recursos necesarios para entender la oferta. Revisa que el botón principal llega a una ruta válida y que la página no muestra un estado vacío por una integración rota. La prueba debe recorrer la pantalla que ve una persona, no limitarse al HTML recibido.

En móvil, prueba menús, campos, botones y mensajes de error. La migración puede llevar a una plantilla distinta aunque el contenido sea equivalente. Si el teclado tapa el botón de envío o un aviso bloquea la acción, el visitante no completa el recorrido. Conserva evidencia del tamaño de pantalla y del estado probado. Una captura del inicio de la página no acredita que se pueda usar el formulario situado al final.

Las descargas tienen su propia ficha. Comprueba que el archivo esperado se abre, que la versión es correcta y que sus enlaces incluidos están dentro de la revisión. No declares todos los documentos comprobados porque uno descargue. Para recursos repetitivos utiliza una prueba automática y una muestra justificada de contenido. Mantén las exclusiones visibles, especialmente cuando archivos antiguos siguen distribuidos fuera de la web.

Yo reservaría un recorrido por cada forma de entrada relevante que cambie el contexto: ruta antigua simple, variante conocida y enlace de campaña si está autorizado. No necesitas convertirlo en una matriz interminable de dispositivos. Elige los contextos por las dependencias del proyecto y explica la selección. Si una familia de páginas comparte plantilla, combina cobertura automática del conjunto y revisión visual de las variantes que pueden comportarse de otra manera.

Entrega de formularios y observación de negocio

Un mensaje de "gracias" acredita que la interfaz llegó a ese estado. No acredita que el negocio haya recibido la solicitud. Para probar entrega, utiliza un identificador sintético en un envío autorizado, comprueba el destino acordado y conserva la confirmación exacta sin exponer datos privados. Si el sistema tiene cola o integración intermedia, verifica el efecto observable correspondiente. No repitas el envío a ciegas cuando el resultado es incierto.

Comprueba que los datos llegan completos y al lugar correcto. Una migración puede conservar el buzón pero perder un campo que identifica el servicio, o enviar todo a una bandeja de pruebas. Valida también errores y recuperación: un campo obligatorio, una dirección inválida o una respuesta de fallo deben ser comprensibles. Esas pruebas no necesitan datos reales de clientes. De hecho, usar datos sintéticos bien etiquetados facilita separar la comprobación de la operación cotidiana.

La medición debe registrar la acción que realmente interesa, conforme a su configuración y consentimiento aprobados. No equipares pulsar enviar con recibir una solicitud válida si son eventos distintos. Usa una visita controlada para revisar qué aparece y si hay duplicación. Si no puedes observar el sistema de analítica, marca esa capa como no ejecutada. La ausencia de acceso no autoriza afirmar que el seguimiento continúa porque el código parece instalado.

El informe de aceptación combina estas capas sin confundirlas: respuesta, contenido, indexabilidad, interfaz, entrega y medición. Puede haber una página técnicamente preparada y una medición pendiente. Puede haber medición correcta y un formulario sin entrega. Mantén cada conclusión asociada a su prueba. Solo después compara datos de negocio entre periodos equivalentes, sin atribuir de inmediato todas las diferencias a la migración.

10. Lanza con control, vigila incidencias y conserva una salida recuperable

La comprobación pública empieza con el cambio autorizado

Publicar es una acción distinta de preparar y probar. Antes de ejecutarla, confirma que la autorización cubre destino, alcance y momento. Ten a mano mapa aprobado, versión anterior y pruebas de salida. No cambies contenido, dominio, medición y reglas al mismo tiempo por comodidad si puedes separar esas decisiones. Cuando el proyecto obliga a combinarlas, registra cada versión para investigar un fallo sin especular sobre qué cambió.

Después del cambio, repite los casos desde fuera del entorno de desarrollo. Comprueba rutas antiguas, destinos, páginas conservadas y controles negativos. Abre las plantillas acordadas en escritorio y móvil, y ejecuta los recorridos comerciales autorizados. La prueba previa reduce incertidumbre, pero no acredita la configuración pública. Puede existir una capa que no estaba en el ensayo o una versión de contenido distinta de la revisada.

Si aparece un fallo, decide con la evidencia disponible. Un destino incorrecto puede resolverse corrigiendo una correspondencia exacta; una regla que afecta a toda la web puede requerir desactivación o vuelta atrás. No alternes soluciones amplias sin registrar qué observación justifica cada cambio. Conserva el caso fallido y prueba su corrección, además de los casos que pueden compartir la causa. Una contención parcial no cierra la migración entera.

Mi criterio de salida es que el responsable pueda explicar qué se ha comprobado y qué queda fuera. "La web está online" no cumple esa función. Entrega una cobertura por capas, identifica incidencias abiertas y describe el riesgo residual. Si la página más importante no entrega solicitudes, dilo como bloqueo de su recorrido aunque el resto responda. Si faltan datos de búsqueda posteriores, no los sustituyas por una opinión sobre el aspecto del sitio.

Search Console informa de capas diferentes

La ayuda de Inspección de URLs distingue datos de la versión indexada y prueba en directo. Esta última no garantiza indexación ni predice la canónica elegida por Google. Úsala para la pregunta que puede responder y conserva la fecha de rastreo cuando interpretes datos anteriores. Un resultado antiguo no demuestra el comportamiento publicado hoy; una prueba actual tampoco demuestra que ya se haya incorporado al índice.

En cambios de dominio o subdominio, revisa si corresponde utilizar Cambio de dirección de Search Console. La herramienta no se utiliza por cambiar rutas dentro del mismo dominio, pasar de HTTP a HTTPS o trasladar alojamiento sin cambios visibles de URL. No la presentes como una acción obligatoria para toda migración. Su uso tampoco sustituye probar las correspondencias ni el contenido de destino.

Separa observación técnica y observación de rendimiento. Los errores de respuesta, bucles y destinos incorrectos pueden investigarse desde el lanzamiento. Las impresiones, clics y acciones de negocio necesitan una ventana comparable y datos disponibles. Anota fechas, filtros y cambios simultáneos. Si una campaña se detuvo o la oferta cambió, no atribuyas todas las diferencias a las redirecciones. El informe debe mostrar las limitaciones de la comparación.

Google recomienda mantener las redirecciones durante el tiempo suficiente y, en general, al menos un año en su documentación de migraciones. No uses esa referencia como fecha automática de borrado. El proyecto debe revisar enlaces que siguen entrando, utilidad para visitantes y obligaciones de mantenimiento. Documenta quién administra el dominio antiguo, su alojamiento y las reglas. Un mapa perfecto pierde su función si se abandona la infraestructura necesaria para responder.

Errores comunes que revisar antes de aceptar

El primer error es celebrar que desaparecen los 404 después de añadir una regla a la portada. Ese cambio puede ocultar rutas perdidas y destinos irrelevantes. El segundo es revisar únicamente URLs que se sabe que funcionan. Las pruebas negativas, las páginas conservadas y las retiradas necesitan su propio resultado. El tercero es cerrar al terminar el barrido automático, dejando sin abrir las páginas ni comprobar la acción comercial.

Otro fallo es sobrescribir la hoja original con resultados posteriores. Se pierde la explicación de lo que estaba aprobado y se mezcla una decisión antigua con una corrección nueva. Conserva versiones y añade observaciones. Tampoco utilices comentarios vagos como "arreglado" para cerrar incidencias: identifica regla, caso, prueba repetida y alcance cubierto. Un participante que llegue después debe poder entender el estado sin reconstruir conversaciones.

Las redirecciones temporales olvidadas requieren un motivo y una revisión. No conviertas todas en permanentes para limpiar una lista. Pregunta si el traslado realmente se ha consolidado y comprueba el contenido. Lo mismo ocurre con retiradas: una página no se recupera ni se elimina por intuición ante una fluctuación. Una nueva decisión necesita una evidencia o una autorización distinta de la anterior.

Mantén el seguimiento como un proceso finito, con responsables y condiciones de revisión. Los cambios de respuesta o de recorrido pueden justificar intervención inmediata; una variación aislada de rendimiento necesita contexto. La migración se acepta técnicamente cuando supera su alcance de pruebas, y su efecto se evalúa con datos posteriores. Mezclar ambas conclusiones genera promesas que ninguna comprobación puede respaldar.

Preguntas frecuentes sobre redirecciones y migraciones

¿Debo redirigir todas las URLs antiguas a la portada?

No. Una dirección antigua necesita un destino que responda a su necesidad, o una retirada documentada. La portada suele mezclar servicios y no demuestra equivalencia con una página específica. Si varias páginas se fusionan, comprueba que el destino recoge su contenido útil. Si no existe equivalente, revisa si conservar información, crear un destino adecuado o servir un error. No uses una regla global para conseguir un informe sin 404: puede esconder que el visitante ha perdido la respuesta que buscaba.

¿Qué diferencia hay entre una redirección 301 y una 308?

Ambas comunican un traslado permanente, pero la conservación del método importa cuando la petición no es una simple lectura. Una 301 permite cambiar POST a GET por compatibilidad histórica; una 308 conserva el método. Esa diferencia no valida por sí sola un formulario o una API. El destino debe aceptar datos, permisos y formato esperados, y producir el efecto correcto. Elige con el responsable técnico y prueba la operación en un contexto preparado, evitando envíos duplicados o transacciones reales no autorizadas.

¿Una redirección permanente garantiza conservar las posiciones?

No. La redirección expresa el traslado y contribuye a señalar el destino preferido, pero no acredita calidad del contenido, indexación o posiciones. Tampoco garantiza que el formulario funcione ni que la oferta siga siendo equivalente. Puedes reducir riesgos con un mapa revisado y pruebas por capas; el rendimiento se observa después. Al comparar, indica periodos, fuentes y cambios simultáneos. No conviertas una prueba de disponibilidad o una etiqueta canónica correcta en una promesa de tráfico o de solicitudes.

¿Qué hago si una página desaparece sin sustituto?

Documenta quién decide la retirada y por qué. Antes de borrar, considera si la página sigue ayudando a visitantes que conservan enlaces, documentos o referencias del servicio. Puede mantenerse como información histórica sin aceptar nuevas solicitudes, si eso corresponde al negocio. Si se elimina, sirve un estado de error adecuado, normalmente 404 o 410 según lo que conozcas de su permanencia. La pantalla puede ofrecer ayuda y navegación, pero no debe simular contenido existente ni enviar a una página irrelevante para esconder la ausencia.

¿Cómo detecto una cadena o un bucle?

Registra cada respuesta y cada Location, además de la URL final. Una cadena utiliza destinos intermedios; un bucle repite una dirección ya visitada. Prueba el origen exacto y variantes conocidas de protocolo, host, barra final o parámetros. Identifica qué capa produce cada paso antes de cambiar reglas. Después repite el caso fallido y los que comparten la misma transformación. Si únicamente miras que al final se obtiene un 200, puedes no detectar un camino innecesario o un destino que contradice el mapa aprobado.

¿Puedo borrar todos los parámetros al redirigir?

No sin saber para qué sirven. Un parámetro puede identificar una ficha, seleccionar idioma, cambiar una opción o aportar información de campaña. Clasifica grupos y decide qué conservar, transformar o descartar. Después prueba contenido, navegación y medición conforme a su configuración aprobada. No propagues datos privados por compatibilidad y no copies consultas sensibles al informe. Cuando falte conocimiento del comportamiento, deja la política pendiente y reproduce un caso seguro; eliminar por defecto puede convertir productos o contenidos distintos en una misma página genérica.

¿Necesito Cambio de dirección de Search Console si solo cambio rutas?

No. El cambio de rutas dentro del mismo dominio no utiliza esa herramienta. Su finalidad es comunicar determinados traslados entre dominios o subdominios, después de preparar la migración correspondiente. Mantén el trabajo de rutas centrado en mapa, respuestas, destinos, enlaces y sitemap. Comprueba los requisitos oficiales cuando sí cambie el dominio y no infieras permiso o acceso por tener una propiedad listada. La herramienta aporta una señal del traslado, pero no corrige una correspondencia equivocada ni prueba formularios o contenido.

¿Cuándo puedo dar por validada la migración?

Cuando el alcance acordado tiene decisiones aprobadas y supera sus pruebas de respuesta, destino, contenido, indexabilidad, navegación y conversión, con exclusiones e incidencias visibles. Expresa la cobertura por capas y no cierres con un porcentaje que esconda el defecto dominante. La aceptación técnica no demuestra que Google haya procesado todas las URLs ni que el negocio haya mantenido sus resultados. Esas conclusiones requieren observación posterior. Si una capa no se ha ejecutado, indícala y continúa con la siguiente comprobación segura antes de presentar la entrega como completa.

Una revisión de migración que empiece por el mapa

Si estás preparando un cambio, reúne dominio actual, alcance aprobado, inventario disponible y fecha prevista. Añade las páginas que sostienen contacto, reservas o ventas y explica qué seguirá igual. Con ese paquete se puede revisar la equivalencia antes de convertirla en reglas. No necesitas entregar contraseñas dentro de una hoja ni aceptar una promesa de posiciones para empezar.

Puedes consultar el servicio de diseño web en Madrid para un proyecto que incluya reconstrucción y la página de SEO en Madrid para el trabajo de búsqueda asociado. Para solicitar una revisión acotada, envía el dominio, el cambio previsto y el objetivo desde contacto de YAG. La primera decisión útil es definir qué debe conservarse y cómo probarlo; después se concreta el alcance, sin prometer resultados que todavía no se han medido.

Decide qué conservar antes de construir el mapa

Para dos páginas que parecen competir, el método de diagnóstico de canibalización SEO ayuda a distinguir intenciones antes de fusionar. En un ecommerce también necesitas decidir qué filtros y variantes deben quedar indexables; no redirijas una combinación solo porque no figure en el nuevo menú.

Fuentes y alcance de esta guía

Fuentes primarias consultadas el 1 de octubre de 2026. Las definiciones HTTP y las precisiones sobre Google se vinculan a sus documentos. El CSV, las fichas, el protocolo de revisión y los dos escenarios son material original de trabajo. Los escenarios son hipotéticos y no representan casos de cliente ni pruebas ejecutadas sobre producción.

• Google Search Central: migraciones con cambios de URL.
• Google Search Central: redirecciones y Búsqueda de Google.
• Google Search Central: consolidación de URLs duplicadas y canónicas.
• RFC Editor: RFC 9110, semántica HTTP.
• Search Console: herramienta Inspección de URLs.
• Search Console: herramienta Cambio de dirección.

Los comandos ilustran comprobaciones de lectura y deben adaptarse al entorno autorizado. No incluyen configuración de un servidor concreto, instrucciones para operar pagos ni una garantía de indexación, posiciones o rendimiento comercial.