An HTTP status is the server's response to one specific request. During a URL move, inspect both the old URL's response and the final destination: a redirect response alone does not prove that the destination is correct or that every old URL has a replacement. This guide uses curl for direct checks and browser developer tools for what a real page load does.

Inspect one response with curl

Use a real URL you control or are authorized to inspect. This GET request prints response headers while discarding the response body:

curl -sS -o /dev/null -D - 'https://example.com/old-page'

Read the first status line and the Location header, if present. A HEAD request can be a quicker check, but some servers handle HEAD differently from GET; use the GET command above when the result is unexpected. Do not add -k to suppress certificate errors during an HTTPS migration check.

Follow and inspect the redirect chain

To follow redirects and print each response's headers, then report the final URL, final response code, and number of redirects:

curl -sS -L --max-redirs 10 -o /dev/null -D - \
  -w '\nFinal URL: %{url_effective}\nFinal status: %{http_code}\nRedirects: %{num_redirects}\n' \
  'https://example.com/old-page'

Check for a loop, an unexpected hostname or path, an HTTP downgrade, a missing destination, or more hops than intended. The maximum is a safety limit for this command, not a recommendation to build a ten-hop chain. Check representative URLs individually; one successful example does not verify every route.

Common statuses in a move or broken-link check

• 200 OK: the request succeeded. For a supposed redirect source, a 200 may mean the old page still serves content; check whether that is intentional. A page that displays a “not found” message with HTTP 200 can be a soft 404.
• 301 Moved Permanently / 308 Permanent Redirect: permanent redirection. Use a destination that replaces the old page. The HTTP standards differ in whether the request method may change; 308 preserves it, while clients can change a POST to GET after a 301.
• 302 Found / 307 Temporary Redirect: temporary redirection. 307 preserves the request method; 302 can permit a method change for POST. Choose based on whether the move is temporary and the request type.
• 404 Not Found: the server has no matching resource, or is not exposing it at that URL. Check spelling, case sensitivity where applicable, routing, deployment, and the intended redirect rule.
• 410 Gone: the resource is explicitly reported as gone. Use it only when removal is intended and there is no replacement destination; it does not repair incoming links.
• 5xx server errors: the server or an upstream service failed. Check origin and proxy logs, deployment health, and whether the issue is temporary before diagnosing a URL mapping problem.

Status codes describe an HTTP response, not the reason a user saw an error by themselves. Authentication, request method, cookies, geography, a proxy, or application behavior can change what a check observes. Compare the response headers and body with the browser's Network panel.

Migration checklist for old URLs

1. Export or otherwise list the old URLs that matter, then map each to its closest relevant live replacement. Do not send every missing URL to the home page as a substitute for a matching destination.
2. Request each old URL and confirm it returns the intended permanent redirect and a single useful destination. Update internal links on the new site to point directly to the new URLs.
3. Request the destination and confirm it loads successfully with the expected page, canonical URL, and hostname. Check both HTTP/HTTPS and host variants if your site intentionally redirects them.
4. Look for loops, chains, unrelated destinations, 404s, and 5xx errors. Retest after cache/CDN invalidation if an old response persists.
5. Submit the new sitemap and monitor Search Console for old and new URL behavior. Google advises keeping migration redirects for at least a year; the time needed to process a move varies, so a redirect is not an instant indexing guarantee.

What curl and browser cross-origin rules can tell you

curl runs from your terminal. It can make a request to a different domain and show the response visible from that network location; browser CORS rules do not restrict curl. A browser page's JavaScript may be prevented from reading a cross-origin response unless the other server grants access with CORS headers. That browser restriction is separate from whether a normal navigation or redirect works. Browser developer tools can show requests made by the page, but they cannot establish that a mapping works for every user, network, authenticated session, or crawler. This guide does not probe URLs automatically.

For related migration work, see the domain registrar transfer guide, HTTPS mixed-content troubleshooting guide, and host move checklist.

Sources checked November 3, 2026

• MDN: HTTP response status codes — definitions and redirect method behavior for common status codes.
• Google Search Central: Site moves with URL changes — URL mapping, redirects, sitemap updates, and migration monitoring.
• Google Search Central: HTTP status codes and Google Search — how Google crawlers interpret HTTP response classes.
• curl manual — options for following redirects, collecting response headers, and printing transfer details.
• MDN: Cross-Origin Resource Sharing — browser rules governing whether scripts can read cross-origin responses.