The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →To redirect one domain to another, point the old hostname at a service or server that can answer HTTP requests, then return a permanent 301 (or 308) response to the new URL. DNS alone cannot redirect a page: it only helps the request reach the redirecting service. For a temporary campaign or test, use a temporary status such as 302 instead. Preserve the old path and query string only when the new site has an equivalent URL.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What a domain redirect actually does
A browser follows a redirect in two stages. First, DNS resolves the old hostname, such as old.example, to an edge service or web server. That service receives the HTTP request and returns a response with a 3xx status code and a Location header. The browser then requests the destination URL. Search crawlers follow the same HTTP exchange.
As an Amazon Associate I earn from qualifying purchases.
Because DNS and HTTP perform different jobs, changing an A record to the new server does not by itself change the address shown in the browser. It merely serves the old hostname from another server. To make the browser and crawlers move to the new hostname, the old host must actively send a redirect response.
Keep the old domain registered and reachable for as long as users, bookmarks, advertising links and crawlers may still request it. The required retention period depends on the migration and your operational needs; there is no universal number of days that fits every site.
#1 Best Overall
Choose the right status code first
| Status | Meaning | Use it when | Method behavior and search signal |
|---|---|---|---|
| 301 | Moved permanently | A site, hostname or URL has a lasting replacement. | The conventional choice for a normal GET-oriented site move. Search engines treat it as a permanent signal. |
| 308 | Permanent redirect | The move is permanent and preserving the original HTTP method is important. | Permanent signal; unlike a method-changing redirect, it is designed to retain the method and request body. |
| 302 | Found/temporary redirect | A short campaign, maintenance event, experiment or temporary routing change. | Temporary signal. Do not use it for a migration you want indexed under the new URL. |
| 303 | See Other | A response should be followed with a retrieval request, commonly after form submission. | Temporary behavior; the follow-up request is normally a GET. |
| 307 | Temporary redirect | A temporary move must preserve the original method. | Temporary signal with method preservation. |
Google Search Central states that 301 and 308 mean a page has permanently moved, while 302, 303 and 307 are temporary signals. A permanent domain migration should therefore use a server-side 301 in most cases, or a 308 when retaining methods such as POST is a deliberate requirement.
Plan the URL mapping before changing DNS
A whole-domain move is safe only when you decide what happens to every important URL. Make a mapping for the home page, canonical content, language or category paths, trailing-slash variants, and URLs still present in external links.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhen to keep the path
Keep the request path when the new site has the same information architecture. For example, https://old.example/guides/controller can become https://new.example/guides/controller. Preserve the query string when parameters still have meaning, such as an internal search term or campaign identifier.
When to change or drop the path
Do not mechanically append an obsolete path to the new host. If a page was removed, map it to the closest useful replacement or, when no equivalent exists, deliberately send it to the new root. Cloudflare’s documented root-target example sends every old path to https://example.net/; its whole-domain example instead keeps a path such as /my/path/to/page.htm and the query ?q=term.
Prepare both hostnames and protocols
- Cover the apex name (for example,
example.com) and thewwwname if both have been published. - Handle both HTTP and HTTPS requests and make the final destination HTTPS.
- Decide whether a trailing slash is canonical and make the redirect rules consistent with that choice.
- List any subdomains that must remain on the old infrastructure instead of being redirected.
Redirect a domain with Cloudflare’s managed edge rules
A managed edge redirect is useful when you control DNS but do not want to keep the old origin server online. Cloudflare’s documented redirect products require the relevant DNS records to be proxied, so requests pass through its edge.
- Add the old domain. Add the old zone to Cloudflare and complete the registrar nameserver change required for that zone.
- Create proxied DNS records. Add proxied A or CNAME records for the apex hostname and, when needed,
www. The records must resolve through Cloudflare rather than being DNS-only. - Open Redirect Rules. Create a rule that matches the old hostname. A wildcard pattern such as
http*://example.com/*can match both protocols and paths for that host. - Set the destination. Use the new HTTPS hostname. When paths correspond, use a dynamic destination such as
https://new.example/${2}or concatenate the incoming request path according to the rule’s expression syntax. - Choose query-string handling. Enable query-string preservation when searches, campaigns or application parameters must survive. Disable or remove parameters that have no meaning on the new site.
- Publish and test. Test the apex and
wwwnames over HTTP and HTTPS, then inspect the response headers to verify one direct hop to the final URL.
If every old URL should land on one new landing page, target https://example.net/ explicitly instead of preserving paths that would be misleading. A path-preserving rule and a root-target rule are different migrations; do not combine them accidentally.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Cloudflare-specific failure modes
- Rule never runs: the DNS record is DNS-only, the hostname is not included in the match, or the rule is lower in priority than an earlier rule.
- HTTPS certificate error: the old hostname does not have a certificate available at the edge, or the TLS mode and origin configuration do not support the request. Correct the certificate/TLS setup before relying on the redirect.
- Unexpected path: the wildcard capture or expression is wrong. Test a deep URL, not only the home page, and inspect the exact
Locationvalue. - Parameters disappear: query-string preservation is disabled or a later rule rewrites the URL. Enable preservation only for parameters that remain valid.
Redirect with Apache
Apache can redirect before application code runs by using mod_alias or mod_rewrite. Put a simple path rule in the relevant virtual host or .htaccess file, and use a host-aware rule for a complete domain migration.
One path with mod_alias
Redirect permanent "/old" "https://example.com/new"This maps requests beginning at the configured path to the supplied destination. Confirm whether your Apache context appends the remainder of a longer path, and test both slash variants before using it for a large tree.
Whole-domain migration with mod_rewrite
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?old.example$ [NC]
RewriteRule ^(.*)$ https://new.example/$1 [R=301,L]The condition limits the rule to the old host, while the capture keeps the path. The query string is retained by default when the substitution does not add a new query string; make that behavior explicit in your own configuration if another rule changes parameters. If the old and new structures differ, replace the catch-all mapping with specific rules and send obsolete paths to useful replacements.
Place the rule where Apache will evaluate it before application routing, and ensure the rewrite module is enabled. A rule in the wrong virtual host can appear to work for one hostname while leaving the other untouched.
Recommended Free Tools
Rank #3
Redirect with Nginx
Nginx can issue a redirect directly from the server or location block. A specific path looks like this:
location = /service {
return 301 https://example.com/about/service;
}For a complete host move, create a server block that listens for the old names and returns the new HTTPS URL:
server {
listen 80;
server_name old.example www.old.example;
return 301 https://new.example$request_uri;
}$request_uri carries the original path and query string. Use an equivalent HTTPS server block as well if the old domain accepts TLS requests. The old HTTPS listener needs a valid certificate for the old names; a redirect cannot repair a certificate warning that occurs before Nginx can send its response.
Reload Nginx only after validating the configuration with the command appropriate to your installation. Keep host matching exact enough that unrelated sites on the same server are not redirected by mistake.
Redirect from application code
Application code is a fallback when you cannot change the web-server configuration. Send the headers before writing a response body and terminate execution immediately:
<?php
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();For a whole-domain move, build the destination from a validated allowlisted host and a correctly encoded path; never copy an arbitrary user-supplied URL into the Location header. Server-level redirects are generally faster, avoid booting the application, and reduce the chance that a route, cookie or error handler creates a loop.
Preserve paths and query strings deliberately
| Old request | Appropriate destination when structures match | When not to preserve it |
|---|---|---|
/ |
https://new.example/ |
Rarely; the home page normally has an equivalent. |
/game/arcade |
https://new.example/game/arcade |
If the section was renamed or removed, map to its real replacement. |
/search?q=term |
Same path and ?q=term when the new search endpoint supports it. |
Drop or translate the parameter if the new application interprets it differently. |
| An obsolete article URL | A specific replacement page. | Do not preserve a path that produces a blank, irrelevant or misleading page; use the new root only when it is genuinely useful. |
Preserving a string merely because it is technically possible can create soft-404s, incorrect analytics, broken searches or duplicate canonical URLs. URL equivalence is a content decision, not just a regular-expression decision.
Validate the redirect before announcing the move
Run a small but representative test matrix from outside the old server’s local network. A header request such as curl -I http://old.example/path?q=term should show a 301 or 308 and a single Location header. Follow it with curl -I -L http://old.example/path?q=term and confirm the final response is the intended HTTPS page.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Request the old apex home page over HTTP.
- Request the old
wwwhome page over HTTP and HTTPS. - Request a deep path that should keep its path.
- Request a trailing-slash variant.
- Request a URL containing a query string.
- Request an intentionally obsolete path and verify its deliberate replacement.
- Repeat the tests after DNS changes are visible from more than one network.
For each request, record the status, every intermediate Location, the final hostname, protocol, path and query string. The desired result is one clean hop from the old URL to the final HTTPS URL. Remove chains such as old domain to an intermediate domain to the new domain, and correct loops in which the destination rule redirects back to the old host.
During a migration, update internal links, canonical tags, XML sitemaps, feeds, API clients and external services you control. Submit representative old URLs to inspection tools and verify that Googlebot can access the new infrastructure. Keep monitoring server and edge logs for old paths that receive traffic; they reveal missing mappings that a home-page test will not find.
Best Value
Managed edge rules versus server configuration
| Decision factor | Managed edge redirect | Apache/Nginx or application redirect |
|---|---|---|
| DNS control | Requires the old zone to use the provider’s DNS and, for documented products, proxied records. | Requires the old hostname to resolve to infrastructure you control. |
| Old origin access | Can work without keeping the old web application online. | Needs a reachable server, virtual host or application endpoint. |
| Path/query handling | Convenient wildcard and expression-based mapping; verify capture syntax and query settings. | More direct control with rewrite rules and application logic; complexity grows with exceptions. |
| HTTPS certificate | The edge must be able to serve the old hostname’s certificate. | Your server must terminate TLS for the old hostname before it can redirect. |
| Observability | Edge analytics and rule logs, depending on the provider and plan. | Web-server access/error logs and application telemetry. |
| Recurring cost | Depends on the managed provider and enabled plan; no universal price is established here. | Uses your existing hosting resources, with no separate redirect service required. |
Choose the edge when DNS is under your control and you want a lightweight, origin-independent rule. Choose server configuration when you already operate the old host and need detailed conditional mappings or local logging.
Common problems and fixes
The browser reports too many redirects
Inspect the complete chain and identify which hop changes scheme, hostname or slash style. Typical causes are an HTTPS-enforcing rule on the new site that points back to an HTTP target, a rule that matches the new hostname as well as the old one, or separate apex and www rules that alternate. Make the destination canonical and exclude it from the old-host match.
Only the home page redirects
A root-only rule is active, or the path capture is missing. Replace it with a host-and-path rule that preserves the request path where equivalents exist, then add explicit exceptions for renamed or removed URLs.
One hostname works and the other does not
Check DNS records, certificate coverage, virtual-host/server-name declarations and rule conditions for both the apex and www names. Test each combination separately rather than assuming one record covers the other.
Query parameters vanish or are duplicated
Check the provider’s query-string setting and every rewrite rule in the chain. Preserve parameters only once, and remove tracking or legacy parameters intentionally instead of passing them through blindly.
Search results still show the old URLs
Search engines need time to recrawl. Keep the old domain and redirects available, ensure the new pages are crawlable, update sitemaps and canonical links, and inspect representative URLs. A 302 will not send the same permanent signal as a 301 or 308.
POST requests fail after the move
Use a 308 for a permanent move or a 307 for a temporary move when the original method and body must be retained. Test the specific client and endpoint; many ordinary page navigations are GET requests and do not expose this distinction.
Quick Recap
A practical cutover sequence
- Inventory old URLs and classify each as equivalent, renamed, removed or intentionally excluded.
- Build and test redirect rules on a staging hostname or isolated server block without changing public DNS.
- Obtain valid TLS coverage for every old HTTPS hostname that will answer requests.
- Deploy the rules, then test HTTP/HTTPS, apex/
www, deep paths, slash variants and query strings. - Change DNS or enable the managed rule, keeping the old service available while records and caches transition.
- Monitor logs, crawl reports and user-facing errors; add specific mappings for high-value misses.
- Leave the redirects in place for the operationally appropriate retention period and only retire the old domain after traffic and dependency checks support that decision.
Key takeaways
- DNS points a hostname to a service; the service must return the HTTP redirect.
- Use 301 or 308 for a permanent move and 302, 303 or 307 for a temporary one.
- Preserve paths and query strings only when the new URL has equivalent semantics.
- Cloudflare’s documented redirect products require proxied DNS records for the matched hostnames.
- Apache, Nginx and application code can all issue redirects, but server-level rules usually avoid unnecessary application work.
- Validate every hostname and representative URL, eliminate chains and loops, and keep the old domain available while users and crawlers transition.
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.
