Fix WordPress Staging Site Redirecting to Live Domain on Hostinger

You click your brand-new staging URL in Hostinger, and your browser immediately dumps you right back onto your live production site. It’s frustrating, and worse, dangerous: if you aren’t paying close attention to your address bar, you’ll start editing settings or testing code on production thinking you’re safely in a sandbox.

This exact scenario bit me on a client WooCommerce redesign last Thursday. Hostinger’s 1-click staging tool duplicated the site into a subdomain, but hitting staging.example.com/wp-admin fired a 301 redirect straight to example.com/wp-admin. Here is how to track down where that production URL is lingering and kill the redirect for good.

Why Hostinger Staging Copies Still Point to Production

When Hostinger hPanel creates a staging copy, it clones your file tree and duplicates the MySQL database. Normally, its internal script runs an SQL search-and-replace to swap your live domain for the staging subdomain. In practice, that automated pass regularly fails or leaves orphaned entries behind because of three things:

• Hardcoded constants in wp-config.php: If you or a previous developer defined WP_HOME and WP_SITEURL inside the config file, WordPress completely ignores whatever is written in the staging database.
• Serialized database objects: Themes, page builders like Elementor, and widgets stash full URLs inside PHP serialized strings. A naive replace corrupts them, so automated tools often skip them entirely.
• Aggressive caching: Active object caching via Redis or LiteSpeed server cache will gladly keep spitting out the old redirect headers created during provisioning.

Before you start digging through files, make sure your staging subdomain actually resolves to Hostinger’s servers. If you manage DNS elsewhere, you may need to point the subdomain to Hostinger using Namecheap DNS first so the server can pick up requests.

Step 1: Check and Override wp-config.php Constants

The quickest override lives at the filesystem layer. If wp-config.php hardcodes static URLs, WordPress won’t even look at the database. You need to inspect this file inside the staging directory—not your live site root.

Jump into Hostinger hPanel, go to Websites, pick your domain, and open File Manager. Navigate into your staging directory—usually domains/example.com/public_html/staging or a subdomain root like staging.example.com/public_html.

Open wp-config.php and check for existing WP_HOME or WP_SITEURL definitions. If they’re pointing to production, fix them. If they aren’t there at all, add them right above the line that says /* That's all, stop editing! Happy publishing. */:

define('WP_HOME', 'https://staging.example.com');
define('WP_SITEURL', 'https://staging.example.com');

Save changes and test the staging domain in an incognito window. If the bouncing stops, your staging site was just inheriting hardcoded strings from your live config. If it still redirects, the issue is down in the database or server rewrite rules.

Step 2: Inspect the wp_options Table via phpMyAdmin

If overriding the constants didn’t fix it—or you prefer to keep your config clean—you need to check the core URLs directly in the staging database.

1. In hPanel, head to Databases > phpMyAdmin.
2. Find the staging database. Hostinger usually appends a random string or _stag to the name. If you aren’t sure, check the DB_NAME inside your staging wp-config.php.
3. Open the wp_options table (watch out for custom prefixes like wp_a1b2_options).
4. Check the first two rows: siteurl and home.

If either row still says https://example.com instead of https://staging.example.com, double-click the option_value field in phpMyAdmin, change the URL to your staging domain, and hit Enter.

One quick gotcha while you’re in the database: watch out for SSL mismatches. If your staging subdomain hasn’t generated an SSL certificate yet, forcing https:// might bounce you back to production or throw a browser warning. Make sure you fix SSL installation failed on Hostinger WordPress before hardcoding HTTPS values here.

Step 3: Run a Clean Search-Replace with WP-CLI

Updating siteurl and home stops the login bounce, but internal links, menus, and Elementor assets will still point straight to production. Click any link on staging, and you’ll find yourself back on the live site. To fix this without breaking serialized arrays, use WP-CLI over SSH.

Grab your SSH credentials under Advanced > SSH Access in hPanel, connect to your server, and cd into your staging root.

Always do a dry run first to see what’s going to change:

cd ~/domains/example.com/public_html/staging
wp search-replace 'https://example.com' 'https://staging.example.com' --dry-run

Review the counts across your tables. Once you’re confident it won’t touch the wrong records, run the actual replacement:

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables

The WordPress WP-CLI search-replace documentation covers why this is : it safely unpacks PHP serialized data, swaps the string, recalculates string byte lengths, and reserializes everything. Running raw SQL UPDATE queries here will break widgets and page builder layouts.

Step 4: Fix Dirty .htaccess Rewrite Rules

Sometimes the database is clean, but LiteSpeed or Apache redirects the request before WordPress even touches it. When Hostinger clones a site, it copies the .htaccess file as-is. If your live site had hardcoded domain redirects or custom HTTPS rewrites, staging inherited them.

Open .htaccess in your staging root. Look for any rules referencing your live domain:

# Faulty redirect rule copied from production
RewriteCond %{HTTP_HOST} ^staging.example.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Wipe those domain-specific rules out. Reset your staging .htaccess back to standard WordPress defaults:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

While you have .htaccess open, remember to keep your staging environment sealed off from search engines and casual visitors. It’s a good idea to password protect WordPress staging in .htaccess so crawlers don’t index duplicate content.

Step 5: Purge Object Cache and Hostinger Server Cache

If you did steps 1 through 4 and still get redirected, you’re fighting cache. A 301 Moved Permanently gets aggressively cached by modern browsers, LiteSpeed, and Redis.

First, clear Hostinger’s server cache:

1. In hPanel, go to Performance > Page Speed (or find the LiteSpeed toggle).
2. Click Purge All.

Second, if you’re running Redis, old site options might still be living in memory. Flush it from WP-CLI or hPanel:

wp cache flush

If you set up Redis manually, check out how to enable Redis object cache on Hostinger so your staging site uses a distinct database prefix or index (like database 1 instead of 0), preventing cache collisions with production.

Third, purge your local browser redirect cache. In Chrome or Brave, open DevTools (F12), click the Network tab, check Disable cache, and reload. Or bypass the browser entirely and test with curl to see the raw headers:

curl -I https://staging.example.com

You want to see an HTTP/2 200 or a local 302 redirect pointing to your staging wp-login.php, not your live domain.

What I Ran: The Complete Fix in 90 Seconds

When this hit my client’s site, I didn’t want to hunt around hPanel menus. Here is the exact command sequence I ran over SSH to knock out the entire issue:

# 1. Jump to staging directory
cd ~/domains/example.com/public_html/staging # 2. Check current database values for home and siteurl
wp option get siteurl
wp option get home # 3. Update both options to the staging subdomain
wp option update siteurl 'https://staging.example.com'
wp option update home 'https://staging.example.com' # 4. Run deep search-replace for elementor/theme references
wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables # 5. Flush Redis and WordPress transients
wp cache flush
wp transient delete --all

Total time was under a minute from the initial SSH handshake to cache flush, and the redirect loop was completely gone.

Gotcha: Security Plugins Trapping the Staging Domain

Here’s an edge case that once cost me over an hour: security plugins like Wordfence, iThemes (Solid Security), or Defender. Many of these store the original domain during setup and enforce hard canonical checks.

Solid Security, for example, frequently injects rules into wp-config.php or creates config files in wp-content/uploads/ that check HTTP_HOST. If the host doesn’t match the live domain it expects, it fires a redirect or a 403 Forbidden.

To verify if a plugin is the culprit, temporarily rename your staging plugins folder over SSH:

# Temporarily rename plugins to bypass loading
mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins

If your staging site suddenly loads, you know a plugin is triggering the redirect. Rename the folder back and turn off your security or redirect plugins one by one until you pinpoint it:

rm -rf wp-content/plugins
mv wp-content/plugins-disabled wp-content/plugins
wp plugin deactivate redirection all-in-one-wp-migration ithemes-security-pro

Frequently Asked Questions

Why does Hostinger’s 1-click staging tool fail to update URLs?

Hostinger’s cloner uses an automated SQL search-and-replace script. If you have active object caching, hardcoded constants inside wp-config.php, or plugins using custom tables that aren’t registered via standard WordPress core APIs, the script simply misses them, leaving your live URLs behind.

Can I fix this without SSH access?

Yes. You can edit wp-config.php through hPanel’s File Manager to define WP_HOME and WP_SITEURL, then open phpMyAdmin under Databases to update siteurl and home in wp_options. Once you can log into staging /wp-admin, install the free Better Search Replace plugin to catch the rest of the database.

Will changing the staging site URL affect my live website?

No, as long as you are updating the staging database. Always check the DB_NAME in your staging wp-config.php before making edits in phpMyAdmin or running WP-CLI commands. Staging runs on its own isolated database instance.

Why does my browser keep redirecting even after fixing the database?

Browsers treat 301 Moved Permanently responses aggressively, caching them locally so future visits skip network checks entirely. Test in a private/incognito window, use an alternative browser, or open DevTools with “Disable cache” checked.

Next Steps

Now that your staging site is isolated and loading cleanly on its own domain, you can test plugins, theme changes, or PHP upgrades safely. If you notice broken images or styling bugs after getting logged in, see how to resolve WordPress mixed content with LiteSpeed and .htaccess on Hostinger.