Staging Site Redirects to Live Site: Causes & Fixes

If your WordPress staging site redirects to the live (production) site, the cause is almost always one of three things: disabled permalinks on the staging site, an .htaccess or server rewrite rule pointing at the production domain, or a plugin (SSL, redirect, security, or language) forcing the redirect. The fastest fix is to flush the staging site’s permalinks — set them to "Post name" and save.

Quick diagnosis — try these in order:

Why does your staging site redirect to the live site?

WordPress stores two URLs in the wp_options table — siteurl and home. When you clone or migrate a site, those values plus the permalink rules decide how WordPress builds and resolves links. A staging site redirects to production when one of these still points at, or rewrites toward, the live domain:

• Permalinks are disabled on the staging site, so WordPress falls back to plain links that don’t resolve in the staging folder.
• A rewrite rule in .htaccess (Apache) or nginx.conf (Nginx) still targets the production document root.
• A plugin (SSL, redirect, membership, security, or language) issues its own redirect to the live URL.

The sections below walk through each cause, starting with the one that resolves most cases.

Quick fix: activate permalinks on the staging site

By default, WP Staging sets the permalink structure to the plain type, so switching it to "Post name" and saving will often resolve link-redirect issues on its own. In our experience this is the single most effective first step — try it before anything else.

Read more: How to Activate WordPress Permalinks.

Fix redirects caused by URLs and .htaccess

Use absolute URLs instead of relative ones

Check the link structure that redirects back to the production website. WP Staging cannot search & replace relative links, so it needs absolute links to run an automatic search & replace.

For instance:

Working link: https://domain.com/path-to-page Not working link: /path-to-page

To resolve it, you have three options:

• A. Create a new staging site and use a subdomain for it. Then relative links have no side effects and work as intended.
• B. Use absolute URLs instead of relative links. Convert all relative links to absolute ones — do this first on the live site and then clone again, or change the staging site’s links after creating it.
• C. Ignore non-working relative links and open the admin dashboard pages directly if you want to edit them.

The recommended way is option A or B, as it makes working on the staging site far simpler than opening every page from the admin dashboard.

Remove or edit the .htaccess (Apache only)

This applies only if your site uses the Apache web server.

When you clone your website into a subfolder, WP Staging removes the .htaccess on the cloned site, because WordPress uses the .htaccess in the root folder of your production site. If a plugin recreates the .htaccess on the staging site, that file can overwrite the rewrite rules and break permalinks on staging.

If that happens, rename the .htaccess in the staging site to something else like .htaccess-disabled and try reloading the staging site. You can rename it with your FTP client, the cPanel file manager, or a file-manager plugin.

Server-level fixes for Bitnami and Nginx

Bitnami .htaccess settings

If you run WordPress in a Bitnami instance, you need extra steps. Post-name permalinks are not supported out of the box on Bitnami because it does not use an .htaccess file in the website’s root folder — it ignores any .htaccess there.

Instead, Bitnami keeps all .htaccess configuration in a file called /opt/bitnami/apps/APPNAME/conf/htaccess.conf. To make permalinks work, edit htaccess.conf and add the following:

<Directory /opt/bitnami/apps/wordpress/htdocs/STAGING>
 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /STAGING/
 RewriteRule ^index.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /STAGING/index.php [L]
 </IfModule>
 </Directory>

Another option is to keep permalinks on the plain setting — then you don’t need to change htaccess.conf at all.

Adjust nginx.conf for the Nginx web server

If you get a 404 "page not found" error and your web server is Nginx, you’ll need to adjust the nginx.conf of your web server. In that case, follow this article to do so.

Fix redirects from cloning options and plugin conflicts

Clone to a subdomain

If you can’t solve the redirection issue, clone your WordPress website to a subdomain and a separate folder using the custom target path and hostname option of WP STAGING | PRO:

We’ve written an extensive guide on cloning your WordPress site to a subdomain: https://wp-staging.com/docs/create-a-staging-site-clone-wordpress/#Clone_to_a_Subdomain

Language plugins like WPML or Polylang

If you use a language plugin like Polylang or WPML that adds a language slug to the URL — for instance https://example.com/en/page1 — you’ll need to activate post-name permalinks on your staging site. Otherwise, this can be another cause of a redirect to the live site.

Disable security & login plugins on the staging site

Create a new staging website and disable these plugins by excluding the plugin folders from the cloning process:

• Security plugins like Wordfence, iThemes Security, Cerber, WP Spamshield, etc.
• Cache plugins like W3 Total Cache, WP Rocket, etc.
• Language plugins like WPML, Polylang (or activate permalinks on the staging site)
• Redirection or "Hide my Login" plugins

If you already created a staging website and need to disable these plugins, you can disable a specific plugin by renaming its folder via FTP or a file-manager plugin. For instance, disable WP Spamshield by renaming stagingsite/wp-content/plugins/wp-spamshield to something else.

Disable redirect plugins on the staging site

Some plugins cause redirects — dedicated redirect plugins, membership plugins, or SSL plugins that force HTTPS when you open the site over HTTP. A few examples:

• Really Simple SSL
• Redirection
• Ultimate Member

If you use one of these on your staging site, create a new staging site but exclude that plugin from the cloning process. Alternatively, deactivate the offending plugin by renaming its folder over FTP to something like /wp-content/plugins/plugin-name-disabled.

Still redirecting to the production site?

Work through this short decision tree if the steps above didn’t resolve it:

1. Did you flush permalinks? Set them to "Post name" and save again — this clears stale rewrite rules.
2. Is the web server Apache or Nginx? Apache → check .htaccess; Nginx → check nginx.conf; Bitnami → check htaccess.conf.
3. Do siteurl and home in wp_options point at the staging URL? If they still hold the live domain, the staging site will keep redirecting. (For background, see WordPress’s guide to changing the site URL.)
4. Did you rule out plugins? Disable SSL, redirect, security, and language plugins one at a time.

If it still redirects after all of this, please open a support ticket and we’ll help you resolve the redirect issue.

Frequently asked questions

Why does my staging site go to the live domain instead of staging?

Because something still resolves to the production domain — usually disabled permalinks, an .htaccess/nginx.conf rewrite rule, or a redirect plugin. Flush permalinks first; if that doesn’t fix it, check the server rewrite rules and plugins.

What’s the very first thing I should try?

Set the staging site’s permalinks to "Post name" and save. This flush resolves the redirect in most cases and takes seconds.

My staging site shows 404 on every page except the homepage. What’s wrong?

That pattern points to rewrite rules. On Apache, rename or fix the staging .htaccess; on Nginx, adjust nginx.conf; on Bitnami, edit htaccess.conf. Then flush permalinks.

Can a security or SSL plugin cause the redirect?

Yes. SSL plugins that force HTTPS and redirect/security plugins can send staging requests to the live URL. Exclude or disable them on the staging site.