Redirecciones comodín: cómo funcionan y cómo configurarlas

Una redirección comodín es una sola regla que coincide con muchas URL por patrón y las envía a otro lugar. En lugar de enumerar 4,000 direcciones antiguas una por una, escribes algo como «todo lo que esté bajo /blog/ va a la misma ruta en el nuevo dominio» y dejas que el servidor haga el resto. Esta guía cubre los dos significados que la gente confunde (comodines de DNS y redirecciones HTTP), patrones de trabajo para Apache y NGINX, los errores de SEO que cuestan posiciones y cuándo una capa de redirección gestionada es la mejor opción.

Qué es realmente una redirección comodín#

La palabra «comodín» abarca tres cosas distintas, y los resultados de búsqueda las mezclan libremente.

Redirecciones comodín (por patrón). Una regla con un marcador de posición. El marcador puede significar «cualquier carácter después de este punto» (una coincidencia de prefijo), «cualquier carácter antes de este punto» (una coincidencia de sufijo) o un segmento capturado que se reutiliza en el destino. Ejemplos típicos: /old-blog/* a /blog/*, o *.olddomain.com a newdomain.com.

Registros DNS comodín. Un registro con un asterisco en la etiqueta más a la izquierda, como *.example.com, responde a consultas de subdominios que no tienen su propio registro. AWS documenta cómo funcionan los asteriscos en los nombres de registro^[1], y el punto clave para este tema es que DNS solo decide qué servidor responde. La redirección en sí es una operación HTTP que ocurre después de la resolución DNS, en el servidor que recibe la solicitud.

Prohibición de comodines a nivel de registro. El tercer uso se refiere a los registros de dominios de nivel superior: los operadores no pueden sintetizar respuestas para dominios inexistentes. Esa es una regla para los registros, no algo que configures en tu propio sitio.

Así que una configuración completa de comodín para subdominios normalmente necesita ambas capas: un registro DNS comodín para que cada subdominio llegue a tu servidor y una regla del lado del servidor que decida a dónde debe ir cada solicitud.

Los patrones que realmente usarás#

La mayoría de las necesidades del mundo real se ajustan a seis patrones.

La diferencia entre las dos primeras filas es la que más importa. Conservar la ruta mantiene la relevancia uno a uno, que es lo que quieres cuando el nuevo sitio refleja al antiguo. Omitir la ruta solo es correcto cuando no existen páginas equivalentes.

Redirecciones comodín en Apache (.htaccess)#

Una pregunta común es cómo redirigir todo lo que viene después de una determinada ruta a través de .htaccess. En Apache, esa es la tarea de mod_rewrite. La documentación de Apache mod_rewrite^[2] describe RewriteRule y las banderas que lo acompañan, incluida R para redirección.

Una redirección de prefijo que conserva el resto de la ruta:

<code class="language-apache">RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]
</code>

Los paréntesis capturan todo lo que sigue a old-section/, y $1 lo inserta en el destino. L detiene el procesamiento de reglas posteriores, lo que evita coincidencias dobles accidentales.

Una redirección de todo el dominio que conserva las rutas y las cadenas de consulta:

<code class="language-apache">RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</code>

Hay varias cosas que suelen confundir a la gente:

• El orden importa. Las reglas se ejecutan de arriba abajo. Coloca las reglas específicas por encima de las generales, o la regla comodín capturará todo.
• Escapa los puntos. Un . sin escapar en una expresión regular coincide con cualquier carácter.
• Prueba primero con un 302. Los navegadores almacenan en caché los 301 de forma agresiva. Usa R=302 mientras haces pruebas y luego cambia a 301 cuando la regla funcione correctamente.
• Cuidado con el servidor. .htaccess funciona solo en Apache. Si tu proveedor usa NGINX, el archivo se ignora.

Redirecciones comodín en NGINX#

NGINX gestiona los nombres de host mediante server_name. La guía del servidor web NGINX^[3] explica que un nombre de servidor puede ser un nombre exacto, un comodín con un asterisco al principio o al final, o una expresión regular, y que los nombres exactos prevalecen sobre los comodines cuando coinciden varios.

Redirige todos los subdominios de un dominio antiguo al nuevo:

<code class="language-nginx">server {
    listen 80;
    server_name .old-domain.com;
    return 301 https://new-domain.com$request_uri;
}
</code>

El punto inicial coincide tanto con old-domain.com como con cualquier subdominio. $request_uri conserva la ruta y la cadena de consulta originales, por lo que los enlaces profundos se mantienen.

Para un prefijo de ruta dentro de un sitio:

<code class="language-nginx">location ~ ^/old-section/(.*)$ {
    return 301 /new-section/$1;
}
</code>

Prefiere return en lugar de rewrite para redirecciones simples. Es más claro y más eficiente de evaluar.

Elegir el código de estado#

El código que devuelves indica a los navegadores y motores de búsqueda cómo tratar el cambio.

• 301 (Movido permanentemente) y 308 (Redirección permanente) indican que el recurso tiene una nueva dirección permanente. La referencia de MDN para 301^[4] describe cómo los navegadores siguen automáticamente el encabezado Location.
• 302 y 307 son temporales. Úsalos para pruebas A/B, promociones cortas o páginas de mantenimiento.

La guía de Google indica que las redirecciones permanentes ayudan a consolidar URL duplicadas y señalan que la nueva URL debe indexarse^[5], mientras que las redirecciones temporales conservan la prioridad de indexación de la página de origen. Si el cambio es a largo plazo, usa un código permanente. Una regla comodín dejada en 302 después de una migración es un error común y silencioso.

Lo que muestra el tráfico de RedirHub sobre los códigos permanentes y temporales#

En una muestra de seis horas de las solicitudes de redirección que la infraestructura de RedirHub atendió el 22 de octubre de 2026, el 42.2% procedía de bots. De las solicitudes de personas, el 82.3% recibió un 301 o 308, el 1.3% un 302 o 307, y menos del 0.03% un error (4xx o 5xx).

Los códigos permanentes dominan, así que una regla comodín que sigue usando un código temporal después de una migración destaca como la excepción que hay que auditar. Las proporciones cuentan solo a las personas (bots excluidos), proceden del registro de acceso de redirecciones en lugar de una encuesta, y excluyen las cuentas más grandes para que ningún cliente individual las sesgue. En RedirHub, las redirecciones de dominio con 301, 302, 307 y 308 están incluidas en Core, Pro y Enterprise, mientras que las redirecciones de subdominio comodín están incluidas solo en Pro y Enterprise.

Errores de SEO que las reglas comodín facilitan#

Como una sola regla toca miles de URL, una regla incorrecta daña miles de páginas a la vez.

Enviar todo a la página de inicio#

La captura general perezosa, /* a /, parece limpia y pierde relevancia. Un visitante que hizo clic en un enlace a una guía específica llega a una página de inicio genérica y se va. Los motores de búsqueda también pueden tratar los redireccionamientos masivos a una página irrelevante como un soft 404. Redirige a la equivalencia más cercana y utiliza una categoría principal más amplia solo cuando no exista una equivalencia.

Crear cadenas#

Supongamos que http://old.com/page redirige a https://old.com/page, que redirige a https://www.old.com/page, que redirige a https://new.com/page. Eso son tres saltos. La documentación de Google señala que Googlebot puede seguir un número limitado de saltos, y que se prefieren los redireccionamientos directos^[5] porque las cadenas añaden latencia y pueden ralentizar la indexación. Escribe la regla para que la primera respuesta ya apunte a la URL final, corrigiendo a la vez protocolo, host y ruta.

Olvidar la cadena de consulta y los fragmentos#

Los parámetros de campaña, como las etiquetas UTM, a menudo acompañan a los enlaces antiguos. Comprueba si tu regla conserva la cadena de consulta cuando quieres que lo haga. En Apache, un redireccionamiento a una URL absoluta lleva la cadena de consulta original, a menos que le indiques lo contrario, como explica la documentación de Apache. En NGINX, $request_uri la incluye, mientras que $uri no.

Confundir www y no-www#

Elige un host canónico y redirige el otro hacia él. La guía de Google sobre la consolidación de URL duplicadas^[6] enumera los redireccionamientos como una señal sólida de tu versión preferida, y cualquiera de las dos opciones está bien siempre que seas coherente. Si necesitas una guía paso a paso, nuestra nota sobre redirigir de no-www a www lo cubre.

Eliminar las reglas demasiado pronto#

Google dice que las redirecciones pueden ser tratadas como una señal de canonicalización, no como una orden absoluta, y que aún puede elegir una canonical diferente en función de otros factores, como explica su documentación sobre canonicalización^[7]. En la práctica, mantén las redirecciones permanentes durante al menos un año después de un cambio, y más tiempo para las URLs que sigan recibiendo enlaces externos.

Un proceso seguro para una migración con comodines#

1. Inventaría las URLs antiguas. Extráelas de tu sitemap, los registros del servidor, la analítica y un rastreo. La documentación de Google sobre cambios de sitio^[8] subraya la importancia de mapear cada URL antigua a su nueva ubicación.
2. Agrúpalas por patrón. La mayoría de los sitios se reducen a un puñado de reglas con comodines, más una lista menor de excepciones puntuales.
3. Escribe primero las excepciones. Las asignaciones individuales van por encima de las reglas con comodines para que prevalezcan.
4. Prueba con URLs reales. Ejecuta una muestra de varios cientos de URLs antiguas, incluidas las más raras, y comprueba el código de estado, el destino final y el número de saltos. Un comprobador de redirecciones muestra cada salto y su código de estado para una sola URL.
5. Lánzalo con códigos permanentes. Cambia de 302 a 301 una vez que pasen las pruebas.
6. Haz seguimiento. Vigila durante semanas los errores de rastreo, los 404 y el tráfico por sección. Corrige los huecos con nuevas reglas, no editando apresuradamente las antiguas.

Google también señala que los sitios grandes pueden moverse por secciones para probar el efecto, mientras que los sitios más pequeños suelen funcionar mejor trasladándolo todo a la vez. Para planificar la parte del dominio, nuestra guía sobre cambios de dominio para SEO cubre lo que debes revisar antes y después del cambio.

Donde los archivos del servidor dejan de ser prácticos#

Editar .htaccess o una configuración de NGINX está bien para un sitio que controlas. Se vuelve engorroso cuando:

• Posees docenas de dominios, algunos aparcados, otros heredados, otros comprados para una campaña.
• Marketing necesita cambiar un destino, pero los cambios requieren un desarrollador y un despliegue.
• Tu sitio funciona sobre una plataforma sin acceso a la configuración del servidor.
• Las reglas de redirección viven en cuatro lugares (CMS, CDN, servidor, registrador) y nadie sabe cuál prevalece.

El orden también importa. Como explica MDN^[9], la redirección se activa cuando el servidor envía una respuesta 3xx con un encabezado Location, por lo que ocurre antes de que se envíe cualquier contenido de la página. Los trucos del lado del cliente, como JavaScript o meta refresh, son el último recurso cuando no puedes acceder a la capa del servidor. Una capa dedicada de redirecciones te mantiene en el nivel adecuado sin requerir acceso al servidor.

La velocidad es el otro costo de salir de la capa del servidor, y es pequeño: el tiempo medio hasta el primer byte de RedirHub fue de 18 ms, frente a 11 ms para el más rápido de 26 proveedores, medido desde Washington, D. C., Fráncfort y Tokio (benchmark de velocidad de redirección de RedirHub, 18–25 de octubre de 2026^[10]).

Nuestra perspectiva#

La mayor parte de los problemas de redirección que vemos no tienen que ver con la sintaxis. Tienen que ver con la propiedad. Una regla la escribe una sola vez quienquiera que estaba en el proyecto, queda en un archivo de configuración y, años después, nadie recuerda por qué /promo/* apunta a donde apunta. Luego un dominio caduca, un folleto impreso o un código QR sigue enviando a la gente a una página muerta, y la solución necesita un ticket.

Construimos RedirHub a partir de la idea de que los enlaces y las redirecciones deben residir en tu propio dominio y permanecer bajo tu control, con SSL gestionado por ti, en lugar de depender de un acortador compartido o de un montón de archivos del servidor. Nuestro consejo para las reglas comodín es el mismo uses la herramienta que uses: escribe el patrón más específico que haga el trabajo, apúntalo directamente a la URL final, mantén una lista de excepciones y revisa las reglas con regularidad. Trata las redirecciones como activos a largo plazo, porque los enlaces en circulación sobrevivirán al diseño actual de tu sitio.

Gestionar redirecciones comodín y de dominio sin archivos de configuración#

RedirHub te permite gestionar redirecciones de dominio y enlaces de marca en tus propios dominios, con SSL y analíticas, y cambiar destinos sin tocar materiales impresos. Si estás migrando un sitio, nuestro servicio de migración web y servicio de redirecciones 301 para migraciones SEO están pensados para ese trabajo. Los planes se publican en la página de precios: Core cuesta 49 $ al mes y Pro cuesta 119 $ al mes. Enterprise se establece por contrato. Las redirecciones comodín de subdominio (redirecciones comodín de subdominio para capturar todo) solo están incluidas en Pro y Enterprise, mientras que las redirecciones de dominio, el reenvío de rutas y el reenvío de parámetros de consulta vienen con Core, Pro y Enterprise.

Referencia rápida: DNS comodín frente a redirección comodín#

Otro detalle de DNS para configuraciones de varios dominios: un CNAME no puede estar en el apex de la zona (el example.com sin prefijo), mientras que algunos proveedores ofrecen registros de tipo alias que sí pueden hacerlo. AWS lo describe en su comparación de registros alias y no alias^[11]. Si apuntas dominios sin prefijo a un servicio de redirección, comprueba qué tipo de registro admite tu proveedor de DNS en el apex.

Ejemplo práctico: un cambio de marca con tres subdominios#

Imagina una empresa que pasa de acme-tools.com a acme.com. Tiene un blog, un sitio de soporte en help.acme-tools.com y algunos subdominios regionales como uk.acme-tools.com.

Un plan limpio se ve así:

1. Añade un registro DNS comodín en el dominio antiguo para que cualquier subdominio, incluso los que nadie recuerda, llegue a la capa de redirección.
2. Crea primero reglas explícitas: help.acme-tools.com/* a support.acme.com/*, y uk.acme-tools.com/* a acme.com/uk/*.
3. Añade una regla general: *.acme-tools.com/* a acme.com/*, como respaldo.
4. Añade la regla raíz: acme-tools.com/* a acme.com/*.
5. Devuelve 301 para todas ellas, con HTTPS en el destino para que haya un solo salto.
6. Prueba 200 URL antiguas del sitemap y de analytics, y luego vuelve a comprobarlas después de una semana.

Las reglas explícitas protegen las secciones con estructuras diferentes, y el respaldo atrapa los casos sueltos. Sin el orden, el respaldo aplanaría el sitio de soporte dentro de las rutas del dominio principal, donde nada coincide.