Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
To redirect one domain to another, point the old hostname to a service or server that can answer HTTP requests, then return a server-side 301 (or 308) response to the matching URL on the new domain. DNS alone cannot issue an HTTP redirect. Keep the old domain active, cover both the apex and www hostnames, preserve paths and query strings only when the new site has equivalent URLs, and test for a single hop without loops.
What a domain redirect actually does
When someone enters old.example, two separate operations occur:
Free tools Windows power users keep installed
One-click scans. No signup required.
- DNS resolution: DNS translates the hostname into an IP address or points it to a proxy or hosting service. DNS does not send an HTTP status code and cannot, by itself, tell a browser to open another URL.
- HTTP response: The service reached through DNS receives the request and returns a redirect status, such as
301 Moved Permanently, with aLocationheader containing the destination URL. The browser and search crawler then request that destination.
A complete redirect therefore needs a reachable endpoint for the old domain, an HTTPS certificate when HTTPS requests are expected, and a rule that chooses the correct destination. If the old domain has several hostnames, each one needs coverage. At minimum, decide what should happen to:
old.example(the apex or root domain)www.old.example- HTTP requests such as
http://old.example/page - HTTPS requests such as
https://old.example/page - Deep paths, trailing-slash variants, and URLs with query strings
Choose the right redirect status code
Google Search Central defines 301 and 308 as signals that a page has permanently moved. It describes 302, 303, and 307 as temporary signals. Use the status that matches the intent rather than choosing a code because it happens to work in a browser.
#1 Best Overall
| Status | Use it when | Important behavior |
|---|---|---|
| 301 | The old domain or URL has permanently moved and ordinary browser navigation uses GET. | The conventional choice for a site or domain migration. Search engines can transfer permanent-move signals to the target. |
| 308 | The move is permanent and the original HTTP method must be preserved. | Unlike a method-changing redirect, it is designed to retain the request method and body. Use it deliberately for APIs or non-GET requests. |
| 302 | A short-term campaign, outage workaround, experiment, or other temporary change. | Signals that the old URL remains the preferred location after the temporary condition ends. |
| 303 | A temporary response should be followed with a GET request. | Useful in application flows where the follow-up request should not repeat the original method. |
| 307 | A temporary redirect must preserve the original method. | Designed to retain the method and request body while the change is temporary. |
For a permanent domain migration, use 301 unless preserving the method is a requirement; choose 308 when that method-preservation requirement is real. Do not use a 302 merely because it is familiar: it tells crawlers that the move is temporary.
Decide how old URLs map to the new domain
Before writing a rule, establish whether the URL structures correspond. A whole-domain move commonly maps https://old.example/products/item-7 to https://new.example/products/item-7. In that case, preserving the path and query string is useful. If the new site has no equivalent for an old path, sending it to an unrelated page creates a poor user experience and can confuse crawlers.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use a one-to-one path mapping when structures match
Preserve the path when the same content exists at the new hostname. Preserve the query string when it carries meaningful search, campaign, filtering, session-independent application, or tracking parameters that the new site understands. Verify that the destination actually interprets those parameters; copying every parameter blindly can create duplicate or broken URLs.
Send obsolete paths to a deliberate destination
If an old path has no equivalent, map it to the closest useful replacement. When no replacement exists, the new root can be an intentional fallback. Do not preserve a path simply because a wildcard rule makes it easy: an old /legacy-download that becomes new.example/legacy-download may produce a misleading 404 or irrelevant page.
Choose one canonical hostname
Decide whether the new site uses the apex (new.example) or www.new.example, and whether HTTPS is mandatory. Every redirect should land on that canonical form. A rule that first redirects the old domain to HTTP and then HTTP to HTTPS creates an avoidable chain.
Redirect a domain with Cloudflare
Cloudflare can perform the redirect at its edge, before a request reaches the old web server. Its documented redirect products require the old hostname to be represented by proxied DNS records, so the request passes through Cloudflare.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11- Add the old domain: Add the old domain to the Cloudflare account and complete the domain’s nameserver setup as requested.
- Create proxied DNS records: Create proxied A or CNAME records for the apex domain. Add a proxied record for
wwwwhen that hostname can receive traffic. The record must resolve through Cloudflare rather than directly to an unproxied origin for the edge rule to run. - Open Redirect Rules: In the Cloudflare dashboard, create a Redirect Rule and choose a hostname match or a wildcard expression such as
http*://example.com/*. If both apex andwwware used, create conditions that cover both explicitly or use the appropriate host wildcard. - Set the target: Enter the canonical HTTPS hostname. For a matching path structure, use a dynamic target such as
https://new.example/${2}or concatenate the request path according to the expression format shown in the dashboard. The capture reference must correspond to the wildcard groups in the match. - Preserve query strings when needed: Enable query-string preservation if searches, campaigns, or application parameters must survive. Check the resulting URL with a test parameter rather than assuming every parameter is appropriate for the new application.
- Choose a root fallback when necessary: If the old paths have no equivalent, target
https://new.example/intentionally instead of appending the old path. - Place the rule correctly: Put the redirect rule ahead of competing rules that could rewrite, cache, authenticate, or otherwise handle the request first.
Cloudflare’s documented whole-domain example keeps a path such as /my/path/to/page.htm and a query such as ?q=term while changing the hostname. Its root-target example deliberately sends every old path to https://example.net/. Those are different outcomes: choose the one that reflects the new site’s information architecture.
Cloudflare-specific checks
- Confirm the apex and
wwwrecords both show the proxied status. - Make sure the old domain has a certificate that allows HTTPS requests to reach the edge. A redirect cannot repair a TLS failure that occurs before the HTTP request.
- Test the exact wildcard and capture groups with a harmless deep URL before enabling a broad migration rule.
- Check that a rule does not match the new hostname as well as the old one; an overbroad condition can create a loop.
Redirect with Apache
Apache can issue redirects in a virtual-host configuration or an enabled .htaccess file. The mod_alias module is simple for individual paths; mod_rewrite is more flexible for host-based, whole-domain migrations.
Redirect one path with mod_alias
Redirect permanent "/old" "https://new.example/new"This maps the old path to the specified new URL. Put the directive in the appropriate Apache configuration context and reload Apache after validating the syntax. For a handful of changed URLs, explicit rules are easier to audit than a broad wildcard.
Redirect every path while preserving the path
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?old.example$ [NC]
RewriteRule ^(.*)$ https://new.example/$1 [R=301,L,NE]In an .htaccess file, the pattern generally excludes the leading slash, so ^(.*)$ captures the requested path. Apache normally carries the original query string forward when the substitution has no new query string. If the new site should not receive the old query string, discard it deliberately with the appropriate rewrite syntax instead of relying on accidental behavior.
The host condition prevents this rule from redirecting requests for unrelated domains that share the same Apache configuration. If the canonical destination includes www, use that exact hostname in the substitution. Add a separate virtual-host or rule path for HTTPS if the old HTTPS hostname is served by a different configuration block.
Prevent Apache loops and chains
- Do not run the old-domain rule in the new-domain virtual host.
- Check that a later HTTPS-enforcement rule does not create an extra hop. Redirect directly from the old HTTP and HTTPS hostnames to the final HTTPS URL where possible.
- Ensure the old domain’s document root does not contain another application redirect that fires before or after the migration rule.
- Use a temporary status while testing if you need to change the destination repeatedly; browsers cache permanent redirects aggressively.
Redirect with Nginx
Nginx commonly handles a domain migration in a dedicated server block. A simple block for HTTP traffic can preserve the complete request URI, including the path and query string:
server {
listen 80;
server_name old.example www.old.example;
return 301 https://new.example$request_uri;
}$request_uri contains the original path and query string. Use it only when the new site has equivalent URL semantics. If every old URL should land on the new root, return the root explicitly instead:
server {
listen 80;
server_name old.example www.old.example;
return 301 https://new.example/;
}For a specific path, Nginx can use an exact location:
location = /service {
return 301 https://new.example/about/service;
}HTTPS requests require an HTTPS server block and a certificate valid for the old hostname. Configure the old HTTPS listener to return the same final destination, then test the configuration and reload Nginx using your distribution’s standard administrative commands. Keep the redirect block free of proxying or application processing unless those functions are genuinely needed.
Nginx pitfalls
- A
server_namethat omitswwwleaves that hostname to a default server, where it may return the wrong content or status. - Appending
$request_urito a destination that already contains a path can produce an unintended URL. Build the substitution carefully when prefixes change. - Do not redirect the new hostname with the same catch-all server block. Verify the selected block for both hostnames.
Redirect from application code
An application can send the redirect before writing a response body. For example, PHP can issue a permanent redirect like this:
<?php
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://new.example/newurl');
exit();
?>The exit() call matters: it prevents the application from continuing to render the old page after sending the redirect. Application-level redirects are useful when the destination depends on database data, authentication state, or a complex route map, but they consume application resources and can be harder to guarantee during an outage. For a simple domain-wide move, an edge, Apache, or Nginx rule is usually easier to observe and less dependent on the old application.
When redirecting a request whose method and body matter, select 308 for a permanent move or 307 for a temporary one. A generic 301 in a form or API flow can cause clients to retry with a different method, depending on the client.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Rank #4
Managed edge rules versus server configuration
| Decision factor | Managed edge rule | Apache or Nginx configuration |
|---|---|---|
| DNS control | Requires the old hostname’s DNS to point through the provider, commonly with proxied records. | Requires DNS to point to an accessible server that you control. |
| Access to the old origin | Can redirect even when the old application is unavailable, provided the edge and DNS are working. | Requires the web server and its configuration to be online and correctly loaded. |
| Path and query preservation | Supports wildcard captures and explicit query-string settings; expression syntax must be checked carefully. | Uses rewrite variables such as Apache captures or Nginx $request_uri; behavior is directly controlled in configuration. |
| HTTPS handling | The edge can accept the old hostname’s HTTPS traffic when its certificate is configured there. | You must maintain certificates and HTTPS listeners for every old hostname. |
| Rule complexity | Convenient for broad host and wildcard rules; complex maps can become difficult to debug in a dashboard. | Precise and scriptable, but syntax errors or rule ordering can take the site offline. |
| Observability | Usually offers edge logs and rule analytics, depending on the account and product. | Web-server access and error logs show the request, status, and selected host block. |
| Recurring cost | Depends on the provider’s plan and traffic terms; no amount is established here. | Uses the existing server and hosting arrangement; additional infrastructure costs depend on that arrangement. |
Choose the edge when you no longer trust or control the old origin, or when you need a redirect to work before the request reaches it. Choose server configuration when you have reliable access to the old host and need maximum control over route-specific behavior. Either approach can produce the same HTTP response; DNS and certificate ownership are the practical constraints.
Test the redirect before and after launch
Test with a command-line client that shows headers as well as with a normal browser. A browser may cache a 301 and hide a later rule change.
- Test both hostnames: Request the apex and
wwwforms of the old domain. - Test both schemes: Request HTTP and HTTPS. Confirm the final
Locationis the canonical HTTPS URL. - Test representative paths: Check the home page, a deep page, a path with and without a trailing slash, and at least one intentionally obsolete path.
- Test a query string: Use a harmless parameter such as
?q=termand verify whether it is preserved or deliberately removed. - Inspect the hop count: The old URL should normally return one redirect directly to the final URL. Follow the chain and remove intermediate HTTP-to-HTTPS, apex-to-
www, or old-path hops where they are not needed. - Check the final response: The destination should return the expected page status, normally 200 for an available page, rather than another redirect or an irrelevant 404.
- Check logs: Look for requests that hit a default virtual host, repeated redirects, malformed paths, or unexpected query-string growth.
After a migration, submit representative old URLs to the relevant inspection tools and verify that Googlebot can access the new infrastructure. Keep monitoring server and edge logs for high-traffic old paths that were missed by the initial map.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Migration checklist and retention
- Inventory important old URLs and classify each as equivalent, changed, or obsolete.
- Choose one canonical new hostname and HTTPS policy.
- Cover the apex and
wwwold hostnames, plus HTTP and HTTPS. - Use 301 or 308 only when the move is permanent; use 302, 303, or 307 for temporary behavior.
- Preserve paths and query strings only when the new application supports their meaning.
- Remove redirect chains and loops before announcing the move.
- Update internal links, canonical tags, XML sitemaps, advertising destinations, email links, and documented API endpoints to the new domain.
- Keep the old domain, DNS, certificates, and redirect service available while users and crawlers transition. There is no universal retention period: the right duration depends on traffic, backlink exposure, contractual obligations, and how completely the new URLs have replaced the old ones.
Common failures and fixes
The browser reports a DNS error
The old hostname does not resolve to the service that should issue the redirect. Correct the A, AAAA, or CNAME arrangement and wait for DNS changes to propagate. Check both the apex and www records.
HTTPS fails before a redirect appears
The old hostname lacks a valid certificate at the edge or old server. Install or enable a certificate covering every hostname users can request, then test HTTPS directly.
The path disappears
The rule targets only the new root or fails to include the captured path. Use the provider’s dynamic path expression, Apache’s captured rule value, or Nginx’s $request_uri only when the structures correspond.
The query string is missing or duplicated
Check the platform’s query-string setting and whether the substitution already contains a query component. Preserve it when the new site needs it; otherwise remove it deliberately and consistently.
A redirect loop occurs
The condition matches the destination hostname, or separate HTTP, HTTPS, apex, and www rules keep handing the request to one another. Log the Host header and each Location, then narrow the old-host match and point every branch directly at the final canonical URL.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesSearch engines retain the old URL
Permanent redirects do not change an index instantly. Make sure the destination is crawlable, equivalent old URLs return 301 or 308, internal links and canonical tags use the new URLs, and the old domain remains available during the transition.
Practical decision examples
A complete domain move with identical paths
Use a permanent 301 from both old hostnames and both schemes to the new HTTPS hostname, preserving the path and supported query string. This is the standard migration pattern when the new site mirrors the old URL structure.
A rebrand with a changed information architecture
Build an explicit map for high-value pages. Preserve paths only for pages that still mean the same thing; send retired sections to their closest replacement or the new root when no useful equivalent exists.
A two-week campaign
Use a 302. Do not make the campaign destination a permanent canonical signal if the old domain should resume serving its original content afterward.
An API endpoint moved permanently
Use 308 when clients must retain the original HTTP method and body. Test clients that send POST, PUT, or PATCH requests rather than validating only a browser GET.
Bottom line
A reliable domain redirect is a coordinated DNS, HTTPS, and HTTP configuration. Put the old host on a service that can answer requests, return a single direct 301 or 308 for a permanent move, preserve only URL components that remain valid, and validate every hostname, scheme, path, and query-string case before and after launch.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
