Redirecciones 301 en .htaccess durante una migración de dominio

Cuando alguien busca .htaccess redirección 301, normalmente tiene un problema muy concreto:

• una URL vieja debe apuntar a una nueva
• HTTP debe pasar a HTTPS
• un dominio viejo debe mudarse de forma permanente

Para unas pocas reglas, .htaccess puede bastar. El problema aparece cuando esa misma costumbre se estira hasta una migración completa.

La respuesta práctica suele ser:

• para unas pocas 301 estables, .htaccess todavía puede alcanzar
• para migraciones de dominio, relanzamientos, rebrands o mapas grandes, .htaccess se vuelve una fuente silenciosa de riesgo

Si ya estás en medio del proyecto, ten abierta también la checklist de migración web con redirecciones. Este artículo se enfoca en el punto de entrada que muchos equipos siguen usando: 301 en .htaccess.

La respuesta rápida

Una regla simple puede verse así:

Redirect 301 /pagina-vieja https://www.ejemplo.com/pagina-nueva

Y una migración de dominio con preservación de ruta suele terminar en mod_rewrite:

RewriteEngine On
 
RewriteCond %{HTTP_HOST} ^dominio-viejo\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.dominio-viejo\.com$
RewriteRule ^(.*)$ https://www.dominio-nuevo.com/$1 [R=301,L]

Eso responde la sintaxis. No responde la parte operativa:

[!TIP] ¿Sigues manejando unas pocas reglas o ya estás manejando una migración que necesita validación, ownership y rollback?

Cuándo .htaccess todavía funciona

Suele seguir siendo razonable cuando:

• hay pocas redirecciones
• Apache es la única capa activa
• no hay CDN, proxy ni middleware reescribiendo rutas también
• la lógica de path es simple
• ownership técnico es claro

Dónde empieza a romperse

1. Hay más de una capa de redirección

En proyectos reales, los redirects pueden venir de:

• .htaccess
• plugins de CMS
• Nginx o balanceadores
• Cloudflare
• middleware de app

Entonces una migración aparentemente simple termina así:

http://dominio-viejo.com/producto-a
  -> https://dominio-viejo.com/producto-a
  -> https://www.dominio-viejo.com/producto-a
  -> https://www.dominio-nuevo.com/tienda/producto-a

Tal vez todavía funcione. Igual es mala arquitectura de migración.

2. La lógica de rutas y parámetros se vuelve borrosa

Muchos equipos prueban solo el home y paran ahí. Más tarde descubren que deep links, docs o UTMs no llegan como esperaban.

Si una URL como:

dominio-viejo.com/precios?utm_source=email&utm_campaign=lanzamiento

cae en el home nuevo, la migración ya perdió contexto.

3. Los wildcards dejan de alcanzar

/blog/* -> /articulos/* suena limpio, hasta que:

• categorías se fusionaron
• productos se descontinuaron
• docs cambiaron de forma desigual
• algunas páginas requieren excepciones

Entonces ya no basta una regla amplia. Hace falta:

• mapeo explícito
• prioridades
• validación
• una redirect map revisable

4. Los cambios son difíciles de revisar

Un merge en un archivo de configuración no es una buena auditoría de migración.

En cuanto varias personas tocan los redirects, el equipo quiere saber:

• quién cambió qué
• qué reglas son nuevas
• cuáles se quitaron
• si hay destinos en conflicto
• cómo volver atrás

.htaccess solo no responde bien a esas preguntas.

Errores más comunes

Separar host, HTTPS y destino final en varios saltos

Malo:

http://dominio-viejo.com/docs/api
  -> https://dominio-viejo.com/docs/api
  -> https://www.dominio-viejo.com/docs/api
  -> https://www.dominio-nuevo.com/docs/api

Mejor:

http://dominio-viejo.com/docs/api
  -> https://www.dominio-nuevo.com/docs/api

Que el home funcione y lo importante no

La portada se ve bien, pero productos, artículos, docs y URLs antiguas terminan en 404 o en una página genérica.

Perder parámetros

Si el tracking de campañas depende de email, QR, paid social o partners, perder utm_ convierte la migración en un problema de SEO y de reporting a la vez.

Mantener la redirect map fuera de la capa que publica

Si la verdad del proyecto está en una hoja, pero las reglas vivas están enterradas en server config, aparecen puntos ciegos.

Cuándo pasar a otro workflow

Ese punto suele llegar cuando:

• hay cientos o miles de URLs
• varias personas o agencias cambian reglas
• necesitas importar CSV
• quieres validar conflictos antes del go-live
• rollback debe ser claro
• no quieres redeployar origen por cada cambio

Ahí es donde UrlEdge tiene sentido:

• bulk URL management para mapas grandes
• redirect management para ownership y rollout
• permanent 301 redirects para migraciones permanentes

Cierre

La pregunta real no es si .htaccess es buena o mala.

La pregunta real es:

¿Tu migración todavía cabe en reglas manuales de servidor o ya es un proyecto de routing con dependencias de SEO, campañas y varias áreas?

Si es lo segundo, el snippet ya no es la solución completa.