Use a URL forward when visitors to one domain or host should go to another website address. This is separate from forwarding the domain’s email.

Check the domain and current website

Install and activate PD Domain & Email Forwarder, connect the provider that manages the domain, then open PD Modules → Forwarding → Domains. Confirm the intended domain and provider before opening Actions → Forwarding.

Review any existing website, address records and redirects for that host. The module can warn about conflicts, but the warning check is not a complete inventory. An absent warning does not prove that redirecting the host will leave an existing website unaffected.

Add the redirect

1. Choose Add URL forward.
2. In Forward this host, enter the intended full domain or subdomain. Confirm that you are changing the host the customer actually requested.
3. In To this URL, enter the complete destination, including its scheme. Check that it does not lead back to the source through another redirect.
4. Choose Redirect type. Use 301 — Permanent for an intended permanent move or 302 — Temporary for a temporary destination. Only choose another code when it is offered by the provider and fits the intended behaviour.
5. Review the available options. Also forward the www version covers an additional host. Keep the path is useful only when the destination will handle those paths as intended. Do not enable broad subdomain forwarding simply to resolve an unexplained failure.
6. Choose Create forward. If a coexistence warning appears, review the affected website and records before deciding whether the visible override option is appropriate. Do not tick it merely to suppress an error.

The options depend on the provider’s capabilities. Creating the rule does not itself prove that visitors are reaching the forwarding service or that the source hostname has a working HTTPS certificate.

Check the visitor’s result

Verify the intended source hostname and destination through your controlled testing process. If you selected www or path preservation, check those cases separately. Review the destination reached, not only the saved row. A permanent redirect can remain cached by a browser, so distinguish an older cached response from the current provider rule.

For Cloudflare, redirect rules require proxied DNS records. An existing DNS-only address record is not sufficient just because a rule was saved. Have the administrator responsible for the website review the record and its effect before changing proxy status. An HTTPS request also needs suitable certificate coverage for the source hostname before its redirect can be received normally.

If a list request fails, an empty table does not establish that no rule exists. If a save outcome is uncertain, inspect the current provider state with the authorised administrator before retrying; do not create another rule solely to clear an error.

Do not include provider credentials or private customer destinations.

See the PD Domain & Email Forwarder Blesta guide for the wider workflow, or explore the module.