Gestiona redirecciones URL con WebBlocks Redirect Manager

Utiliza un sitio de prueba y una cuenta Super admin para la instalación. El catálogo oficial declara que Redirect Manager 0.1.28 es compatible con CMS ^1.100.0, PHP ^8.3 y Laravel ^13.0. Tu versión del CMS puede añadir otros requisitos; esta guía se ejecuta con PHP 8.4. Comprueba el resultado de compatibilidad de tu servidor en el catálogo oficial de Redirect Manager.

Prepara y publica primero la página de destino. En nuestro ejemplo, /workshops ya se abre correctamente. El plugin envía una respuesta de redirección; no crea el destino, no publica un borrador, no actualiza los enlaces existentes ni comprueba si un sitio remoto está disponible.

Antes de guardar, identifica la ruta antigua, el destino deseado y el sitio o dominio al que pertenece el enlace antiguo. Usa el ámbito de sitio para un cambio normal dentro de un único sitio web. Una regla global afecta a las solicitudes coincidentes de toda la instalación; selecciónala solo si quieres ese comportamiento amplio.

1. Abre System → Plugins como Super admin.
2. Usa Browse Plugin Catalog para localizar WebBlocks Redirect Manager.
3. Revisa la versión, las notas y la compatibilidad, y elige Install from Catalog.
4. Si tu administrador te proporciona el archivo oficial publicado, selecciónalo en Plugin ZIP y pulsa Upload Plugin ZIP.
5. Revisa el paquete instalado antes de activarlo.

Nuestro ejemplo utiliza el ZIP oficial publicado. Un plugin recién instalado aparece como Disabled. El CMS actual aplica los cambios de base de datos durante el ciclo de instalación y activación normal.

Abre los detalles de WebBlocks Redirect Manager y selecciona Enable Plugin. Confirma los estados Enabled, almacenamiento Healthy y Migrations Up to Date. Una instalación saludable indica que el almacenamiento de redirecciones está listo y el procesamiento público está activo.

Abre Maintenance → Redirects. En una instalación nueva, la lista muestra No redirects have been created yet. La acción Create redirect abre el formulario de la regla.

Si el menú no aparece inmediatamente después de la activación, vuelve a cargar el panel. Si el almacenamiento no está listo, resuelve la actualización de base de datos o el aviso de compatibilidad del plugin antes de crear reglas.

Redirect Manager separa la lectura de la lista de la modificación de reglas:

Quien gestione reglas suele necesitar ambos permisos. La instalación y el ciclo de vida del plugin siguen siendo tareas administrativas. Usa la guía Roles y permisos para asignar a tu equipo el acceso adecuado.

La lista del panel incluye todas las reglas de la instalación. Applies to determina qué solicitudes públicas coinciden con la regla; no limita qué reglas puede ver o administrar un operador del panel. Considera el permiso de administración de reglas como autoridad para cambiar redirecciones en toda la instalación. Las restricciones de sitio de la Internal API constituyen un control de integración independiente.

Selecciona Create redirect e introduce estos valores:

El formulario selecciona inicialmente All sites and domains, 301 permanent y Enabled. Cambia esos valores predeterminados deliberadamente para este ejemplo. Una regla no tiene un paso de publicación independiente: guardar una regla activa modifica la redirección pública en cuanto la solicitud llega al plugin activo.

Pulsa Create redirect. El mensaje de éxito confirma el registro; la nueva fila muestra el ámbito, origen, destino, estado, activación, Hits y Last hit. Una regla nueva comienza con cero accesos y un guion como hora del último acceso.

Si quieres preparar una regla sin activarla, desmarca Enabled antes de guardar. Podrás activarla después de revisar el origen, el ámbito y el destino.

Abre la URL pública antigua en el dominio real del sitio. En nuestro ejemplo, visitar /old-workshops conduce a /workshops, donde la nueva página se abre normalmente. Comprueba también la dirección del navegador, no solo el contenido: ver el destino no revela si la respuesta fue 301 o 302.

Vuelve a Maintenance → Redirects y actualiza la lista. El ejemplo muestra ahora 1 acceso y un valor en Last hit. Es una solicitud real que pasó por la redirección, no un contador escrito manualmente.

Para comprobar la respuesta exacta, usa el panel Network del navegador o un cliente HTTP que envíe la solicitud a tu propio sitio. Una solicitud HEAD permite revisar las cabeceras sin descargar la página de destino:

Sustituye el nombre de servidor de ejemplo por el tuyo. Para la regla anterior, espera un estado 302 y una cabecera Location que apunte a /workshops. El comando no sigue la redirección. Comprueba también el destino por separado para confirmar que devuelve la página deseada.

Las solicitudes GET y HEAD cuentan como accesos. Los monitores, bots del navegador y pruebas repetidas pueden aumentar el total. Los accesos son coincidencias de redirección que llegan a la aplicación; no representan personas únicas, visitas correctas al destino ni conversiones completadas.

El selector Applies to ofrece tres tipos de ámbito. Las opciones de sitio y dominio proceden de los registros del CMS. Si falta un dominio, configura primero los dominios activos del sitio correspondiente; el formulario de redirección no registra un nombre de servidor nuevo. Consulta Varios sitios.

Una regla global sirve como alternativa común para la ruta coincidente en toda la instalación. En este caso, /programme conduce a /contact cuando no gana una regla activa más específica.

Una regla de sitio coincide con los dominios activos registrados del sitio. Nuestra regla de sitio para /programme conduce a /workshops y tiene prioridad sobre la regla global en los dominios de Northstar Studio.

Este ámbito sigue los registros de dominios activos del sitio. Revisa la redirección cuando se añada, elimine o desactive un dominio. Un nombre de servidor desconocido no hereda las reglas del sitio solo porque ese sitio sea el predeterminado de la instalación.

Una regla de dominio solo coincide con el nombre de servidor seleccionado. Nuestra excepción para events.example.test envía /programme a /summer-workshops. studio.example.test, la variante www y otros subdominios no se incluyen automáticamente.

Estas tres reglas pueden coexistir porque la ruta de origen debe ser única dentro de su propio ámbito, no entre todos los ámbitos de la instalación.

Las reglas activas que coinciden con la misma ruta de origen se evalúan en este orden:

1. Dominio exacto.
2. Sitio vinculado al nombre de servidor entrante.
3. Todos los sitios y dominios.

Las tres reglas de ejemplo para /programme producen lo siguiente:

La última fila describe la coincidencia del plugin después de que la solicitud llegue al CMS; no configura DNS ni hace que un nombre no registrado sirva tu sitio. La configuración de alojamiento, dominio y dominio principal sigue aplicándose.

Después de probar los nombres de servidor correspondientes, los contadores separados muestran qué reglas procesaron las solicitudes. Desactivar una regla más específica puede dejar actuar a la regla activa más amplia. Comprueba las alternativas de sitio y global antes de desactivar una excepción de dominio.

Prueba el nombre de servidor público exacto, incluidos los alias y el comportamiento de dominio principal de tu despliegue. El servidor web, CDN o una redirección a nivel de dominio puede responder antes de que la solicitud llegue a Redirect Manager.

Source path es una ruta interna, no una URL completa. Introduce /old-workshops, no https://your-site.example/old-workshops. El plugin normaliza la barra inicial ausente y las barras finales; old-workshops, /old-workshops y /old-workshops/ indican el mismo origen.

Después de normalizar, la coincidencia es exacta. Una regla para /old-workshops no coincide con /old-workshops/photography. El formulario no ofrece comodines, expresiones regulares, sustitución de prefijos ni copia automática de sufijos. Mantén coherentes las mayúsculas; nuestro servidor de prueba no hizo coincidir /OLD-WORKSHOPS con el ejemplo en minúsculas.

Los parámetros de consulta entrantes se ignoran al comparar el origen. /old-workshops y /old-workshops?utm_source=newsletter coinciden con la misma regla. La consulta entrante no se copia automáticamente al destino. Si necesitas una consulta fija, inclúyela directamente en Target URL, por ejemplo /workshops?from=legacy.

El destino puede ser una ruta relativa a la raíz como /workshops o una URL http/https completa como https://destination.example/workshops. Un destino relativo conserva el nombre de servidor entrante; usa una URL completa para trasladar a otro dominio. Los destinos relativos al esquema como //destination.example/workshops se rechazan. Los fragmentos de URL pertenecen al navegador y no pueden diferenciar reglas de origen entrantes.

No uses el plugin para redirigir envíos de formularios ni escrituras de API. Inspecciona solicitudes públicas GET y HEAD; los demás métodos continúan hacia la aplicación del servidor. También omite los espacios reservados /admin, /api, /webadmin, /cms, /storage, /assets, /static, /build, /vendor y /webblocks-ui y sus subrutas. Los archivos servidos directamente por el servidor web quizá nunca lleguen a la redirección del CMS.

Una regla activa puede sustituir una página pública existente en la misma ruta. Antes de guardar, confirma que quieres retirar la página antigua de la navegación normal. Redirect Manager no exige que la página de origen devuelva primero un 404.

Si creas dos veces el mismo origen normalizado dentro del mismo ámbito, el formulario muestra The source path has already been taken. Edita la regla existente. Una regla desactivada también ocupa ese origen dentro del ámbito.

El plugin rechaza una redirección interna que apunte directamente a sí misma. /loop-check no puede conducir a /loop-check?from=legacy; la consulta no cambia la ruta base. El error indica The target must not redirect this path back to itself.

La protección contra bucles directos no sustituye la revisión de toda la cadena. Evita combinar /a → /b con /b → /a, o redirecciones entre dominios que otro sistema devuelve al origen. Envía las direcciones antiguas directamente al destino final y prueba toda la cadena.

Para trasladar una portada, introduce / como origen y elige un ámbito de sitio o dominio. Una regla global activa para la portada se rechaza con Choose a site or domain for a homepage redirect., lo que evita que una regla raíz global capture todas las portadas.

Revisa con cuidado los destinos de portada: un destino relativo permanece en el dominio actual. Prefiere el ámbito más estrecho y confirma que el destino no tenga una regla que devuelva al visitante a /.

Usa 302 temporary mientras compruebas el origen, nombre de servidor, destino y contador. Si el traslado será permanente y las pruebas han pasado:

1. Localiza la regla en Maintenance → Redirects.
2. Usa la acción del lápiz Edit redirect.
3. Comprueba Applies to, Source path y Target URL.
4. Cambia Status code a 301 permanent.
5. Mantén marcado Enabled y pulsa Save changes.

La lista muestra ahora 301 y un recordatorio sobre la caché del navegador. La edición conserva el total de accesos y el historial del último acceso.

Los navegadores pueden guardar una redirección 301 y reutilizarla sin llegar al CMS. Esto puede hacer que un destino modificado parezca sin cambios e impedir que se registre un nuevo acceso en el servidor. Comprueba con un cliente HTTP que haga una solicitud nueva o desactiva la caché en las herramientas de red del navegador. Desactivar la regla no puede retirar respuestas ya almacenadas por el cliente o una capa superior.

Para detener la redirección conservando su configuración e historial, edita la regla, desmarca Enabled y pulsa Save changes.

La fila permanece en la lista como Disabled. Las solicitudes nuevas ya no usan esta regla y el contador deja de aumentar. Si no existe otra regla de ámbito activa ni otra capa de redirección, el servidor devuelve la página normal o un 404. En el ejemplo, la dirección antigua sin uso devuelve 404 después de desactivar la regla.

Para volver a activarla, edita la misma fila, marca Enabled, comprueba el destino y guarda. Así evitas crear un origen duplicado y conservas el historial de la regla.

La acción de papelera Delete redirect elimina la regla y su historial de accesos. En 0.1.28 se ejecuta directamente; el plugin no incluye papelera ni pantalla de restauración. Registra la información necesaria antes de borrar y usa Disabled para una pausa reversible.

Desactivar el plugin completo desde System → Plugins detiene el procesamiento y oculta sus aportaciones. El ciclo de vida actual conserva las tablas del plugin. Es una acción más amplia que desactivar una regla y no borra las cachés del navegador ni de la CDN.

Redirect Manager 0.1.28 ofrece reglas individuales, dos códigos de estado, selección de ámbito e historial agregado de accesos. No añade bloques al constructor de páginas: cuando está activo, procesa directamente las solicitudes públicas coincidentes.

El panel no incluye reglas programadas, importación o exportación CSV masiva, comodines, análisis por visitante ni detección automática de enlaces rotos. Planifica esas necesidades aparte en vez de escribir patrones no admitidos en Source path. Esta versión tampoco incluye una acción para reiniciar el contador.

Si cambias la dirección de una página en el CMS, revisa tú mismo la URL anterior. Renombrar una página no añade automáticamente una regla a la lista del plugin. Actualiza la navegación y los enlaces internos a la dirección final, y conserva redirecciones antiguas deliberadas para marcadores externos y enlaces que no puedas modificar. Consulta Cambiar la dirección de una página.

Para automatización, el plugin expone su colección de reglas mediante la Internal Content API en /webadmin/api/redirect-manager/redirects. La lectura usa plugins.read; la escritura usa plugins.manage y las restricciones de sitio correspondientes. Usa el descubrimiento de API del CMS para revisar los endpoints instalados y el contrato de solicitudes. Los usuarios del panel no necesitan un token de API para seguir esta guía.

Antes de activar el traslado real, confirma que la nueva página está publicada y devuelve el contenido correcto en el servidor de destino. Empieza con 302; prueba la dirección anterior sin seguir la redirección para revisar el estado y la cabecera Location, y después síguela para comprobar la página final.

Comprueba todos los dominios relacionados, las reglas de ámbito más específicas, las barras finales y las expectativas sobre consultas. Confirma que el destino no redirige de vuelta y que las pruebas GET/HEAD producen el cambio de contador esperado. Cambia a 301 solo cuando el traslado permanente sea definitivo.

Después del lanzamiento, actualiza los enlaces que controles, documenta el ámbito y el objetivo de la regla y revisa periódicamente los totales. Para pausar, desactiva antes de eliminar. Así tendrás un proceso repetible que mantiene accesibles las URL antiguas y permite controlar dónde se aplica cada redirección.