I have recently set up a second blog on my Wordpress multisite. The primary blog on the Multisite is www.example.com, and the second blog I have set up two days ago is www.example2.org.

Unfortunately, when going to www.example2.org, WordPress redirects to https://www.example.com/wp-signup.php?new=

On the same server, I have set up a corresponding test Multisite, with test.example.com being the primary blog and test.example2.org the second blog. It is working without a problem.

The Multisite-related .htaccess and wp-config.php settings are the same for both the test and the live Multisite, so that wouldn't be the problem. I've also verified that on the live Multisite I have www.example2.org correctly set in the wp_blogs table, and also it is correctly set as https://www.example2.org on the siteurl and home rows of the wp_2_options table (the _2_ part corresponding to the blog ID on the Multisite).

I would appreciate any suggestions on why this redirect is happening and/or how to resolve it. I don't even know which file is issuing the redirect (I don't think it's wp-signup.php) so I can't look at the relevant code to debug it further.

3 Answers 3


I can't comment so I'm leaving this answer. As a follow up to the fantastic research done by @Borislav there is another SE thread that is related, with several potential fixes:

Site Redirecting to wp-signup.php

Ultimately, most redirect issues with WordPress Multisite seem related to siteurl and home which even if properly hardcoded (e.g. using WP_HOME and WP_SITEURL in the wp-config.php file) will still result in redirect issues if the accompanying fields in wp_options table are not also correct. This is due to the way that WordPress Multisite processes the initial setup routine; while I haven't found any documentation on the reason for this, I believe it was probably done on purpose by a Core dev to ensure no conflicts arise later on in the functionality of the Multisite installation, which is more prone to issues than single sites.

Some have suggested implementing NOBLOGREDIRECT as a fix but this does not work per se, and does not address the underlying issue. That setting is only meant to redirect visitors who land on non-existent sub-sites of your Multisite network (e.g. if registration is disabled for new blogs).

Ref: https://www.sarahgebauer.com/today-i-learned-multisite-mystery-signup/

Ref: https://gist.github.com/dejanmarkovic/8323792

In conclusion:

Always ensure that your wp_options table has the siteurl and home settings updated to accurately reflect the main domain of your Multisite installation. In certain cases, running a search/replace across the entire MySQL database may be required (depending on the history of your domain changes and database cruft), including any incorrect entries in the wp_blogs and wp_site tables if you moved your Multisite to a new domain recently...

Update: by the way, you will likely also experience this redirect issue if you are trying to convert a single site to Multisite network without using the Tools > Network Setup patch:


  • 1
    This was a huge help!! I definitely found until I had updated the wp_blogs and wp_site tables, that the redirect would not go away. I wish this answer was ranked higher and also was on the other Stack Exchange answer you linked above which I had also gone to first and found nothing worked.
    – Trevor
    Oct 30, 2020 at 10:27
  • you saved my sanity. thanks for the great explanations. Wordpress can be a voodoo sorcerer.
    – Hirako
    Jul 20, 2021 at 11:26

After many hours of debugging and despair, the problem is now solved. It turned out to be a very obscure thing.

The redirect is issued by the function ms_load_current_site_and_network() inside /wp-includes/ms-load.php. It was issuing the redirect because /wp-includes/ms-settings.php was not able to set a domain. The reason it was not able to set a domain is because $_SERVER['HTTP_HOST'] was not set.

$_SERVER['HTTP_HOST'] not being set had to do with the PHP setting auto_globals_jit. It was set to On, resulting in the $_SERVER array not being set (as explained in this comment). Even though $_SERVER['HTTP_HOST'] and the rest were defined when loading a single php file with phpinfo(); in it, they were not defined when loading Wordpress's php files. And that led to the redirect.

Setting auto_globals_jit to Off in php.ini resolved it.

Bonus info:

The issue was additionally made more complicated by some form of caching (which I couldn't pin down or clear). So I had to rely on behavior that I saw occur only once and couldn't replicate afterwards. For example, I created a separate php file to just check if $_SERVER['HTTP_HOST'] is set - and initially it wasn't. Following the suggestion from the comment, I used $_SERVER['HTTP_HOST'] twice in the php file - and immediately saw that it was now set. However, when reverting the change and having $_SERVER['HTTP_HOST'] only once in the php file, it still remained set - suggesting I was seeing a cached response. I coulnd't get it to break again after I fixed it once.

Just documenting this here in case someone encounters similar behavior.

  • 1
    I want to thank you for doing the deep digging to find this bug. I have been wresting with the same issue for a while now and I was finally able to come across an answer that at least addressed the issue.
    – Brent
    Jul 17, 2018 at 16:26

Sifting through the entire MySQL is worth a shot for sure. I fixed mine in wp_domain_mapping table the id was out a digit.. probably from adding, deleting and adding the alias back in and out.

FYI. Domain Mapping code kindly supplied by Humanmade http://www.easywebdesigntutorials.com/how-to-point-a-top-level-domain-to-a-multisite-using-domain-mapping/

  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Oct 2, 2021 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.