Domain forwarding usually sends a browser from one address to another through an HTTP redirect. It can help people reach a renamed site or a relevant destination, but it does not transfer registration ownership or automatically import search performance.
Plan the purpose, redirect type and important page destinations before changing settings. DNS configuration and the forwarding service are related but different components.
Understand the service returning the redirect
A and CNAME records help locate services; a CNAME is a DNS alias rather than an HTTP redirect to another URL. Our DNS guide explains that distinction.
A registrar, host or another authorised service can provide forwarding. GoDaddy’s documentation supplies one current provider workflow. Check the actual service instructions and any required DNS changes.
Do not edit an inactive DNS panel and assume public behaviour changed. Identify the delegated provider and preserve intended email and verification records when changing service arrangements.
Choose permanent or temporary behaviour
Google’s redirect guidance distinguishes permanent signals such as HTTP 301 or 308 from temporary responses such as 302 or 307.
Use a permanent redirect for a move you intend to retain and a temporary one where the original location should remain the ongoing address. These are signals used in indexing, not a guarantee of a particular ranking outcome.
If a provider offers masking, read its behaviour separately. Keeping an old address displayed is not automatically equivalent to an ordinary redirect that sends the browser to the new URL.
Map important old pages to useful destinations
Decide whether a home-page forward is sufficient or whether individual paths need relevant destinations. Google’s site-move guidance covers planned URL mapping.
For a hypothetical moved guide, direct its old address to the corresponding new resource rather than sending every page to an unrelated home page. Acquiring an expired registration does not grant ownership of archived content.
Google’s spam policies remain relevant to manipulative repurposing. Forwarding should have an understandable purpose for visitors.
Check secure access at the source
An HTTPS request needs the source service’s secure connection setup before it can return the redirect. HTTP semantics define the HTTPS scheme and secure connection behaviour.
Do not assume the destination’s certificate automatically supplies secure access for the old address. Confirm the forwarding provider’s current HTTPS handling and test the actual source forms.
Configure and verify deliberately
- Confirm control of the source registration and authorised forwarding service.
- Record existing settings and the intended destination, including scheme and important paths.
- Choose the appropriate redirect type under the provider’s current instructions.
- Apply only the required service changes, preserving unrelated functions.
- Check public behaviour and the response, not only a dashboard confirmation.
Test the bare name, relevant subdomains, HTTP and HTTPS forms, and important old paths. Check whether the provider preserves, changes or discards path and query information. Avoid loops and unnecessary redirect chains.
Allow for relevant DNS and browser caching while inspecting results; no universal propagation deadline applies to every change.
Maintain registration and the forwarding record
The source name still needs renewal and service control. Record the destination, purpose and review date, updating important references where appropriate.
Our DNS handover guide connects forwarding with portfolio administration, and the management guide helps keep registration and service records separate.
Useful forwarding provides a verified route to relevant material. It does not by itself promise consolidated traffic, improved SEO or a completed website migration.