Quick answer
If the public URLs stay the same, verify them on the new host without inventing redirects. If URLs change, map each old address to its relevant replacement and check the entire response chain. A finite chain and a redirect loop are different problems.
Example: a chain versus a loop
A → B → C → 200 is a finite redirect chain that reaches content. Prefer a direct A → C redirect when appropriate. A → B → A is a cycle: the browser revisits an earlier address and never reaches the page. Record status codes and Location destinations, not just the browser’s final error.
If an old URL reaches an unrelated homepage with status 200, the chain has terminated but the mapping is still wrong. Check relevance as well as transport success; removed content may correctly return 404 or 410.
Decide whether the public URL changed
A provider change alone does not require redirects if public URLs remain unchanged. When the domain, path, scheme or preferred hostname changes, record the old and intended final URL before cutover and prepare the appropriate mappings.
Keep the old hosting and domain controls available while testing. Do not point an old domain away or cancel it before its inbound links and redirects are accounted for.
Prepare specific mappings for changed URLs
List high-value pages, navigation destinations, campaign landing pages and known external links. Give each changed old URL the closest relevant new URL. A blanket redirect of every old path to the homepage can strand visitors and hide missing content. Preserve query parameters where the application needs them, but do not copy sensitive tokens into public examples or logs. Check whether the site framework, web server or CDN owns redirects so you edit the right layer once.
If paths remain identical but the preferred host changes, a consistent host-level redirect may be appropriate. Verify the final canonical URL and HTTPS configuration before enabling it.
Follow the full response chain
Request representative old URLs with a browser or an authorised HTTP client that shows status codes and Location headers. Check for a single intended permanent redirect where the move is permanent, and that the final page returns useful content rather than a 404 or an unrelated homepage. Test lowercase and case-sensitive paths, trailing slashes, assets and both hostnames if relevant. A redirect sequence that cycles back or never reaches a final response is a loop; use the separate loop guide.
Check new internal links and sitemap URLs directly. Redirects should support old inbound URLs, not compensate for a newly published navigation that still points to the old site.
Correct only the broken mapping
If one route fails, compare the old and new path, redirect owner and rule order. Restore the previous rule or old hosting response for affected URLs if the new rule causes a loop or broad misdirection. Keep a table of tested URLs, observed statuses and the rule changed. If a new site has not been verified, pause the DNS cutover or use the recorded rollback path rather than publishing a large untested redirect set.
Frequently asked questions
Do I need redirects because I changed providers? Not if the public URLs remain the same and resolve correctly. Verify the host move instead.
Should all old 404s go to the homepage? No. Restore the relevant page or map it to its closest replacement; an intentional 404 or 410 can be appropriate for removed content after review.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.