API de redirecciones y reglas como código: CI/CD para cambios de URL más seguros

Una redirección casi siempre empieza como un arreglo chico. Cambia una URL de producto. Se mueve un artículo de ayuda. Una landing de campaña recibe otro slug. Alguien agrega una línea en next.config.js, una regla en Cloudflare, un plugin del CMS o una configuración de Nginx.

El problema aparece cuando las redirecciones dejan de ser arreglos sueltos y empiezan a formar parte del lanzamiento.

En una migración, un ecommerce regional, una campaña con partners o un sitio de documentación, una regla define dónde terminan los backlinks, los QR impresos, los anuncios, los emails, los links de afiliados y las páginas indexadas. Eso ya es configuración de tráfico en producción.

El modelo más seguro es tratar las redirecciones como configuración desplegable: reglas estructuradas, validación en CI, staging con comportamiento real, publicación de snapshots y rollback listo antes de mover tráfico.

Por qué las redirecciones deben pasar por release

Los equipos ya revisan variables de entorno, migraciones de base de datos, feature flags y middleware. Una redirección que afecta SEO, paid media o soporte merece el mismo cuidado.

El flujo frágil suele verse así:

• SEO mantiene una hoja de cálculo
• engineering copia filas a la configuración de la app
• marketing cambia destinos de campaña en otra herramienta
• el CMS crea redirecciones sin mucha visibilidad
• el CDN normaliza hosts
• cuando algo falla, nadie sabe qué capa respondió

Las reglas como código convierten el redirect map en un artefacto revisable. Puede ser YAML, JSON, Terraform, CSV o un payload interno. Lo importante es que la regla tenga dueño, prueba y vuelta atrás.

Una regla necesita más que origen y destino

old_url y new_url alcanzan para crear una redirección. No alcanzan para operarla bien.

Un contrato útil explica la intención:

{
  "source": "/precios-viejos",
  "destination": "/precios",
  "status": 301,
  "match": "exact",
  "queryPolicy": "preserve_allowlist",
  "preserveQuery": ["utm_source", "utm_medium", "utm_campaign", "gclid"],
  "owner": "growth",
  "reason": "consolidacion de pagina de precios",
  "expiresAt": null
}

Para migraciones y ecommerce, agrega prioridad, locale, país, dispositivo, lote, estado de revisión y fallback.

La guía de Google para redirecciones parte de la intención: cuánto tiempo existirá el cambio y qué URL debe aparecer en búsqueda. CI no decide eso por el equipo, pero sí puede bloquear errores obvios.

API sync reduce la copia manual

Las redirecciones nacen en muchos lugares. Un CMS cambia slugs. Un catálogo de Shopify, WooCommerce o una plataforma local retira productos. Un equipo de documentación cambia rutas. Una agencia SEO entrega un mapa de migración. Un partner necesita links con marca.

Si todo termina copiándose a mano, las reglas se desordenan.

Una API de redirecciones crea una frontera más limpia:

Cloudflare permite crear reglas de redirección desde su Rulesets API. Next.js y Vercel también soportan redirects por configuración. Esas capas ejecutan. La parte difícil es el gobierno alrededor: validación, dueño, staging, analytics y rollback.

Qué debería validar CI

Un job de CI para redirects debe probar comportamiento, no solo sintaxis.

Checks útiles:

• rutas de origen duplicadas
• destinos mal formados
• falta de owner, motivo o status
• wildcard o regex que tapa reglas exactas
• status permanente en una campaña con fecha de fin
• destino con 404, 410, 5xx o redirect inesperado
• chains demasiado largas
• loops
• pérdida de UTM, click ID, cupón o partner ID
• reglas por país, dispositivo, header o query sin fallback
• conflictos con otro lote

Para URLs de alto riesgo, usa una matriz de requests:

source=/precios-viejos
country=MX
device=desktop
query=?utm_source=google&gclid=test
expectedStatus=301
expectedDestination=/precios?utm_source=google&gclid=test

El objetivo es saber qué pasará antes de que llegue tráfico real.

Staging debe mostrar la ruta final

Un staging de redirecciones debe responder una pregunta simple: con esta URL y este contexto, ¿qué pasaría en producción?

Muestra:

• regla aplicada
• status code
• destino final
• manejo de query
• resultado de condiciones
• reglas competidoras
• largo de la cadena
• owner y lote
• diferencia contra el snapshot publicado

GitHub Actions permite ambientes con reglas de protección y reviewers. El mismo patrón sirve para redirects: CI valida, staging muestra evidencia y producción espera la aprobación correcta.

Rollback no puede depender de redeploy

Revertir una redirección no debería exigir redeploy de la app de origen en plena campaña.

Guarda snapshots publicados. Etiqueta importaciones. Separa reglas temporales de campaña de migraciones permanentes. Haz visibles los overrides de emergencia.

Si la regla toca SEO, paid media, soporte o ventas, rollback es parte del requisito.

Dónde encaja UrlEdge

UrlEdge sirve cuando el equipo quiere automatizar redirects sin convertir cada cambio de URL en un deploy de la aplicación.

• API para dominios, reglas, publicación y automatización
• Redirect Management para ownership, analytics, snapshots y rollback
• Bulk URL Management para mapas de migración e imports grandes
• Advanced Redirect Rules para wildcard, regex, query y condiciones
• Redirect Checker para QA de ruta y status
• Collaboration para approvals entre SEO, marketing, plataforma y agencias

Deja en la app las redirecciones pequeñas que pertenecen al producto. Deja en CDN la normalización simple. Usa API y reglas como código cuando necesitas revisión, evidencia, automatización y recuperación rápida.

FAQ

¿Qué significa redirecciones como código?

Que las reglas viven en un formato estructurado y revisable, y pasan por validación, staging, publicación y rollback como otra configuración de producción.

¿Todas las redirecciones deben vivir en Git?

No. Git sirve para reglas estables y migraciones. API sync sirve mejor cuando las reglas vienen de CMS, ecommerce, partners o herramientas internas.

¿CI/CD puede publicar redirects directamente?

Sí, si hay validación, staging, permisos, aprobación para cambios riesgosos y rollback.

Referencias

• Google Search Central: Redirects and Google Search
• Cloudflare Rules docs: Create a redirect rule via API
• Next.js docs: next.config.js redirects
• GitHub Docs: Managing environments for deployment