What a 301 redirect does to a page request
When a browser opens a web address, it resolves the domain, connects to the server and sends an HTTP request. The reply determines whether the browser displays content, downloads a file, asks for credentials or moves to another address. A permanent redirect changes that first stage of the exchange rather than repairing the requested page itself.
A 301 redirect is the HTTP status used to state that a resource has a lasting new home. The response contains a Location header, and the browser normally follows it by making another request. That second request is where the final page, image or error comes from, which is why a redirect can appear to work even when the destination is unavailable.
What the server returns first
Suppose a visitor requests the path /guides/start on old.example.au. The server returns a 301 Moved Permanently response whose Location header points to the same path on www.example.au. The original URL does not deliver the guide directly at this point. Its job is to tell the user agent where the authoritative version now lives.
The response can also include caching instructions and a short HTML message for people whose software does not follow redirects. Relative locations are valid, although an absolute HTTPS address is often easier to audit. A carefully built redirect preserves the intended path and relevant query parameters while removing duplicate variants such as unnecessary trailing slashes or mismatched hostnames.
How the browser handles the new request
After following the Location value, the browser creates a fresh request for the destination. If that request receives a 200 response, the visitor sees the destination page and the address bar updates to the final URL. If the destination produces a 404, 500, timeout, security warning or redirect of its own, the visitor encounters that result instead of the content originally requested.
Redirects can also alter how data is sent. A 301 applied to a form submission may cause many clients to repeat the request as GET, exposing or dropping form fields. A 308 response is designed to preserve the method and body. Redirecting from HTTPS to HTTP introduces downgrade risks, while omitting the query string can discard campaign tags, filters or product identifiers that the destination needs.
Why redirect chains cause delays
A single redirect adds a network round trip, but a chain is more disruptive. A request might travel from a legacy domain to a campaign hostname, then to a regional host and finally to the current URL. Every hop adds latency and another chance for a cache, proxy or server to fail. Search crawlers and monitoring tools must process the entire path as well.
Cycles produce errors such as ERR_TOO_MANY_REDIRECTS. Even without a cycle, cached 301 responses can preserve an outdated route after a site migration. The permanence signal tells clients that the change is not temporary, so teams should test the complete chain before release and keep an accurate map of which source URLs point to which final destinations.
| Status | Core meaning | Request handling | Typical use |
|---|---|---|---|
| 301 | Permanent | May change POST to GET | Domain or URL migration |
| 302 | Temporary | Often changes POST to GET | Short tests or maintenance |
| 307 | Temporary | Preserves method and body | Temporary POST handover |
| 308 | Permanent | Preserves method and body | Permanent endpoint move |
What search engines and caches inherit
Search engines use a 301 as a strong signal that one address should replace another and that signals attached to the old URL should pass to the new one. It does not guarantee identical rankings or immediate index changes. The old URL may remain indexed for a while, and canonical tags, internal links, sitemaps and backlink quality still need to point consistently toward the preferred page.
Browser and proxy caches may retain the redirect longer than expected because permanent responses are cacheable by default. If a later correction replaces a cached route, some users may continue following the old response until it expires or is cleared. Good cache headers can control this behaviour, while developers should test in a private window and a normal window to expose both paths.
Checks that fit Australian internet conditions
Australian connection patterns add useful variables to diagnosis. The NBN reaches premises through several technologies, including fibre, fixed wireless, hybrid fibre coaxial and satellite, while some customers still rely on ADSL, mobile hotspots or business links with different service-level agreements. A route that succeeds on a fixed-line NBN connection in Sydney may behave differently on a mobile network in regional Australia, particularly when DNS, filtering or an international hosting route is involved.
Australian organisations commonly use .com.au or another .au domain, and domain eligibility is governed by rules from the Australian Domain Name Authority, auDA. Website migrations within the local market can still involve registrar changes, DNS cutovers, CDN settings and redirects from older campaign addresses. Cloud capacity and major internet exchanges around Sydney and Melbourne can shorten routes to local infrastructure, but a destination hosted farther away will add distance that no redirect can remove.
When the redirect itself works but the destination does not, separate the redirect from the final load. The concise basic troubleshooting guidance covers useful checks for network interruptions, filtering, cached copies and domain or hosting problems. Open the destination directly, compare it with the redirected address and inspect the Network panel to see whether the first response is genuinely a 301 and where the chain ends.
On a terminal, set target to the address being tested and run curl -IL "$target" to print response headers while following the chain. If the server rejects HEAD requests, use curl -L -o /dev/null -s -w '%{url_effective}\n' "$target" to print the final address instead. Compare the output across an Australian broadband connection and a mobile network.
A dependable redirect plan
A dependable redirect is deliberate, minimal and tested against real traffic. Begin with the source and destination addresses rather than the status code alone, because the status records permanence while the Location value determines where traffic actually goes.
- Map every old address to one final HTTPS destination, including paths, query parameters, locale variants and campaign links.
- Use 301 only when the move is genuinely permanent; choose 302 for a temporary test and 308 when a permanent move must preserve the request method.
- Redirect directly to the final page, avoiding chains, loops, irrelevant tracking parameters and accidental changes to POST submissions.
- Test response codes, headers, cookies, forms and analytics in a private browser before launch, then retest with normal browser caches.
- Record redirects in a migration sheet, monitor logs for 3xx responses and recheck key paths after DNS, hosting or CDN changes.
Review the most important addresses on your site now. Open the Network panel, follow each redirect and confirm that the final request returns the intended content without a warning, loop or extra hop. Then update internal links to the verified destination, so visitors reach it through one clear, durable path rather than relying on a stale chain.