Para aceptar una redirección de dominio en el portal del cliente, prueba la URL principal, una subpágina real y una URL con parámetros de campaña. Anota el destino final de cada una. Una página de inicio que funciona no demuestra que todos los enlaces antiguos lleguen al contenido correcto.
Esta lista es para vendedores de dominios y sus clientes. Propone una prueba de aceptación; no informa de una prueba realizada en una cuenta de cliente.
Comprobar los Requisitos del Portal
La documentación de Cloudflare de PayRequest describe la redirección desde la pestaña Forwarding de una suscripción de dominio. Requiere un producto de dominio con registro vinculado, una zona activa en Cloudflare y una integración conectada. El flujo de registro utiliza OpenProvider. Si falta la pestaña, pide al vendedor que revise esas condiciones antes de cambiar el DNS en otro lugar.
La documentación de Customer Portal agrupa los servicios compatibles en My services. Abre allí la gestión del dominio. Este portal de tienda es distinto del área de cuenta simplificada de una página de pago; no prometas los mismos controles en todas las cuentas.
Definir Primero los Destinos Esperados
En este ejemplo, old.example redirige a new.example. Utiliza dominios que controlas. Activa Preserve Path solo si existen las rutas correspondientes en el destino. Usa Preserve Query String cuando el destino necesite los parámetros entrantes. El portal documenta ambas opciones y redirecciones 301 o 302. Cloudflare también explica la conservación de parámetros.
| URL de origen | Destino final esperado | Qué revisar si falla |
|---|---|---|
| https://old.example/ | https://new.example/ | Destino incorrecto o redirección ausente |
| https://old.example/contact | https://new.example/contact | Ruta eliminada o página inexistente |
| https://old.example/?utm_source=invoice | https://new.example/?utm_source=invoice | Tratamiento de parámetros |
| https://old.example/contact?ref=client | Misma ruta y ref en new.example | Combinación de ruta y parámetros |
| https://www.old.example/contact | Destino www acordado | Cobertura del nombre de host |
La fila www es un requisito de prueba, no una promesa de configuración automática de todos los nombres de host. Para un único perfil social, conservar /contact puede ser inadecuado: acuerda la URL del perfil como destino.
Ejecutar Cinco Comprobaciones y Preparar la Recuperación
- Guarda el destino anterior, tipo de redirección y ambas opciones de conservación.
- Configura la redirección y abre cada URL de origen en una nueva sesión del navegador.
- Compara dirección y página real con la matriz. Una página de error en el destino no supera la prueba.
- Revisa HTTPS y www por separado. Si hay un bucle o un salto inesperado, pide al vendedor que inspeccione las reglas.
- Registra hora, URL final, resultado y responsable de cada fallo. Restaura los ajustes anteriores acordados si es necesario y vuelve a probar.
Utiliza valores de campaña ficticios sin datos sensibles. Conservar parámetros no demuestra atribución en analytics ni consentimiento para la medición.
Entregar un Resultado Concreto
Ejemplo: «La raíz y /contact funcionan; la prueba ref combinada funciona; www todavía falla en HTTPS. Mantener el cambio abierto hasta resolver la cobertura del host». En campañas temporales, anota fecha de fin y responsable de restauración. Una migración permanente necesita un plan de contenidos aparte: la configuración de redirección no garantiza posiciones de búsqueda ni el traslado de cada URL antigua.
Utiliza el portal del cliente de PayRequest para el flujo documentado de dominios compatibles, junto con esta matriz. Consulta Services & integrations para el catálogo de servicios admitidos.
Para la facturación general, consulta facturar a clientes de hosting.
¿Listo para configurarlo? Crea una cuenta de PayRequest.
Preparado por el equipo de PayRequest con ayuda de IA. Documentación revisada el 11 de octubre de 2026. Las URL y la matriz son ejemplos originales; no se atribuyen resultados a clientes.
