Domain Redirects: How to Point One Domain at Another Properly

A domain redirect is simple only when the requirements are simple. Pointing example-old.com at example-new.com can involve DNS, certificates, path handling, status codes, and a decision about whether the old domain remains an active entry point.

The safest setup starts by choosing the layer that should answer the request, then testing more than the homepage. A redirect that works at the root but drops /pricing or query parameters is not finished.

The three ways to redirect a domain#

There are three common approaches. Registrar forwarding is convenient, DNS points the hostname to infrastructure that can answer the request, and a hosted redirect service handles the response and rules for you.

• •
  Registrar forwarding: fast to configure, but often limited in path and rule control.
• •
  DNS plus your server or edge layer: flexible, but you own certificates, routing, and operations.
• •
  Hosted redirects: central management and reporting, with provider configuration and account dependencies to manage.

Registrar forwarding: fast, free, and where it falls down#

Registrar forwarding is useful when the requirement is a basic domain-level move and the registrar supports the behavior you need. It can be a good first step for a parked or lightly used domain.

The limits appear when you need path preservation, custom rules, reliable HTTPS handling, analytics, or a controlled migration. Provider interfaces also differ, so verify the exact response rather than assuming a setting called forwarding behaves like a server-side redirect.

Preserving the path#

Path preservation means old.example.com/page reaches new.example.com/page, or an explicitly mapped equivalent. Without it, every deep link may arrive at the homepage, which is confusing for users and can undermine a carefully planned migration.

Test representative paths, including one with a query string. A recent example URL supplied for this campaign should be re-verified before publication; use the redirect checker to inspect the actual response chain rather than relying on a browser's final screen.

HTTPS on a redirected domain#

A visitor can request the old hostname over HTTPS even if every destination is elsewhere. The old hostname therefore needs valid certificate coverage and a response that can be reached securely before the redirect is returned.

Check both schemes, common host variants, and any certificate or DNS transition. A setup that succeeds only for http://old.example.com is incomplete if links, bookmarks, or search results use https://old.example.com.

301 versus 302#

Use a 301 when the old URL has moved permanently and a 302 when the move is temporary or still under test. The status code communicates intent to clients and crawlers; it is not a substitute for testing the destination and chain.

Avoid long chains. If old.example.com redirects to middle.example.com and then to new.example.com, every hop adds another place for a rule, certificate, or path mapping to fail. Where possible, point the old URL directly to its final destination.

Verifying that the redirect works#

Verify the root, a deep path, a path with a query string, HTTP, HTTPS, and any www or non-www variant you intend to support. Record the status code, Location header, number of hops, and final response. Repeat after DNS or certificate changes.

For a managed setup, the free redirect service can be the starting point. If the move is part of a larger migration, document the redirect inventory and keep ownership of the old domain and its DNS records until traffic has been checked.

The final checklist#

1. Choose registrar, server, or hosted redirects based on the required control.
2. Cover the old hostname over HTTPS and the variants you intend to support.
3. Preserve paths and decide how query parameters should behave.
4. Use 301 for permanent moves and 302 for temporary tests.
5. Test the response chain and keep the old domain under control during the transition.

A domain redirect is ready when users reach the intended page from every supported entry point and you can explain exactly what the server returned along the way.