Introduction

A site migration can finish successfully while visitors still hit a username and password prompt that belonged to the old staging environment. The site itself may be live on the new server, but a leftover basic-auth rule, protected directory setting, or upstream access gate still makes production look like staging.

Treat this as an access-control problem instead of an application problem. Start by identifying exactly where the password prompt is generated, because a staging login can be enforced by the web server, control panel, reverse proxy, or CDN path in front of the migrated site.

Symptoms

  • The live site still shows a username and password prompt after migration
  • Production pages look correct only after entering old staging credentials
  • Some paths prompt for a password while others load normally
  • Browser tests differ depending on whether the user has cached credentials
  • The issue started after moving a site from staging to production or after a hosting migration
  • Teams removed the staging subdomain, but the prompt still appears on the live domain

Common Causes

  • A leftover .htaccess or web server basic-auth rule still protects the migrated site
  • The hosting panel still has directory privacy or password protection enabled
  • A reverse proxy, CDN rule, or upstream gateway still enforces staging access
  • The site was migrated from a protected staging path and inherited the same access controls
  • Cached browser credentials make the prompt behavior look inconsistent across devices
  • Migration cleanup removed the staging URL but not the protection layer behind it

Step-by-Step Fix

  1. Test the live site in a clean browser session and identify the exact hostname and path that trigger the password prompt, because you need to know whether the protection applies sitewide or only on a specific route.
  2. Check the destination server for leftover basic-auth rules such as .htaccess, web server config, or protected-directory settings, because staging protection often migrates with the site files or vhost configuration.
  3. Review hosting control panel directory privacy settings for the domain and public web root, because panel-level password protection can survive a migration even when the application was moved correctly.
  4. Compare direct-origin access with the normal public URL if a reverse proxy or CDN is involved, because the password prompt may be generated upstream rather than by the web server that now hosts the site.
  5. Inspect any redirect, rewrite, or path-mapping rules that still send production requests into an old staging directory, because the wrong document root can make only part of the site remain protected.
  6. Remove or update the stale protection rule at the real source and retest with a fresh browser session, because cached credentials can make an old prompt appear gone or still active when the configuration state has changed.
  7. Test multiple paths such as the homepage, admin area, and static assets after the fix, because staging protection is sometimes attached to only one directory tree.
  8. Verify that the staging environment, if still needed, remains protected on its own hostname or path, because removing the wrong rule can expose the old staging site instead of fixing production cleanly.
  9. Document where password protection is managed for the site going forward, because staging auth rules are easy to forget during future hosting migrations and launch checklists.